Re: [PATCH] i386 No-Idle-Hz aka Dynamic-Ticks 3

From: Srivatsa Vaddagiri (vatsa_at_in.ibm.com)
Date: 08/08/05

  • Next message: Mathieu Chouquet-Stringer: "Re: cifs kernel module and MS DFS shares [2.6.12-1.1411_FC4]" 
    Date:	Mon, 8 Aug 2005 20:24:21 +0530
To: Tony Lindgren <tony@atomide.com>

    On Mon, Aug 08, 2005 at 12:26:01AM -0700, Tony Lindgren wrote:
    > Good point, and it would be nice to have it resolved for systems that support
    > idling individual CPUs. The current setup was done because when I was tinkering
    > with the amd76x_pm patch a while a back, I noticed that idling the cpu
    > disconnects all cpus from the bus. (As far as I remember)
    > So this may need to be configured depending on the system.

    What do you mean by "idling" a cpu? Is it reprogramming the timer source
    to skip ticks? Or putting the cpu actually in some low-power state?
    And what do you mean by "disconnect all CPUs from the bus"? Is it
    the system bus? And what happens if the CPUs are disconnected from
    the bus like this while it is executing?

    Both requirements (idling all CPUs together vs individually) I think
    will make the patch more complex. Are such systems (which require having to
    idle all CPUs together) pretty common that we have to care about?!

    > > - All CPUs seem to cut off the same number of ticks (dyn_tick->skip). Isn't
    > > this wrong, considering that the timer list is per-CPU? This will cause
    > > some timers to be serviced much later than usual.
    >
    > Yes if it's done on per-CPU basis. In the current setup the first interrupt
    > will kick the system off the dyn-tick state and the timers get checked again.

    But that may be too late on some CPUs. If dyn_tick->skip = 100, all
    CPUs skip 100 ticks. However some CPUs may have timers that need to be
    service much before that.

    > > - The fact that dyn_tick_state is global and accessed from all CPUs
    > > is probably a scalability concern, especially if we allow the ticks
    > > to be cut off on per-CPU basis.
    >
    > >From idling devices point of view, we still need some global variable I
    > believe. How else would you be able to tell all devices that the whole
    > system does not have any timers for next 2 seconds?

    Why would anyone want to know that? Moreover, when we enable this
    per-CPU, the no-timer-interval is also distributed across CPUs.

    > But in any case on P4 systems the APIC timer is not the bottleneck as
    > stopping or reprogramming PIT also kills APIC. (This does not happen on P3
    > systems). So the bottleneck most likely is the length of PIT.

    On these systems, do you disabled APIC (dyntick=noapic)?

    > HRT + VST depend on APIC only, and does not use next_timer_interrupt().

    AFAIK, it supports pm timer too and yes it has its own implementation
    of next_timer_interrupt, which makes it more work for merging.
    At this point, looks like dyn-tick is gaining more momentum and is
    more likely a candidate for merging. I will send out my SMP-support
    changes to dynamic tick soon.

    > You may also want to check out the ARM implementation as it does not have
    > the issues listed above, which are mostly x86 specific issues.

    Thanks for the pointer. Will look at it. 

    -- 
Thanks and Regards,
Srivatsa Vaddagiri,
Linux Technology Center,
IBM Software Labs,
Bangalore, INDIA - 560017
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
  • Next message: Mathieu Chouquet-Stringer: "Re: cifs kernel module and MS DFS shares [2.6.12-1.1411_FC4]"

    Relevant Pages

    • [RFC PATCH 0/4] timers: Timer migration
      ... This is a re-work of the earlier patch which i had sent. ... that such hrtimers are ignored during migration of timers. ... Here's a brief introduction as to why we need timer migration. ... idle cpus onto lesser idle cpus is necessary. ...
      (Linux-Kernel)
    • Re: [RFC PATCH 0/4] timers: framework for migration between CPU
      ... This is a good idea to automatically bias the timers. ... I think the basic timer migration policy should exist in user ... lesser number of CPUs would make a whole lot of sense. ... It recommends policies in user space that can affect power savings ...
      (Linux-Kernel)
    • Re: [RFC PATCH 0/1]: timers: Timer Migration
      ... frequently woken up to service the timers. ... timers from idle cpus onto lesser idle cpus is necessary. ... this patch implements a lightweight timer migration ... have all the timers firing on the cpus present in the same package. ...
      (Linux-Kernel)
    • Re: [PATCH] i386 No-Idle-Hz aka Dynamic-Ticks 3
      ... > This is the dynamic ticks patch for i386 as written by Tony Lindgen ... virtualization benefit if idle CPUs can cut off useless timer ticks. ...
      (Linux-Kernel)
    • [RFC] Patch: dynticks: idle load balancing
      ... there is no idle load balancing being done. ... Appended patch takes a third route which nominates an owner among ... the idle cpus, which does the idle load balancing on behalf of the other ... Track the cpus for which ticks are stopped and one among these cpus will ...
      (Linux-Kernel)