Messages in this thread | | | Date | Mon, 13 Jun 2005 12:35:03 -0700 | From | Tony Lindgren <> | Subject | Re: [PATCH] Dynamic tick for x86 version 050609-2 |
| |
* Andi Kleen <ak@muc.de> [050613 11:51]: > On Mon, Jun 13, 2005 at 11:37:16AM -0700, Tony Lindgren wrote: > > * Andi Kleen <ak@muc.de> [050613 10:57]: > > > Srivatsa Vaddagiri <vatsa@in.ibm.com> writes: > > > > > > > > 2. reprogram_apic_timer seems to reprogram the count-down > > > > APIC timer (APIC_TMICT) with an integral number of apic_timer_val. > > > > How accurate will this be? Shouldnt this take into account > > > > that we may not be reprogramming the timer on exactly "jiffy" > > > > boundary? > > > > > > All PIT based reprogramming schemes will lose time. > > > > Not true if the timesource is different from interrupt source. > > > > Consider PM timer for timesource, and PIT for interrupt source. Reprogamming > > PIT should not affect PM timer. Time is always updated from PM timer. > > PM timer is not really suitable for this because it overflows > too quickly (several times a second).
It's longer than PIT overflow, which means it can be used.
> Also you still lose time in timers (e.g. your internal timers slowly drift) > unless you regularly sync with the time source, but that has other > drawbacks. > > > > > > > Actually there is a small reason - RCU currently does not get > > > updated by a fully idle CPU and can stall other CPUs. But that is in > > > practice not too big an issue yet because so many subsystems > > > cause ticks now and then, so the CPUs tend to wake up often > > > enough to not stall the rest of the system too badly. > > > > I guess it should be safe to reprogram timer even if other CPUs are not > > idle, assuming the busy CPUs reprogramming timer will also wake up the idle > > CPUs. > > > > There's one thing that should be considered though; Reprogamming > > timers should be avoided if the system is busy as it causes > > performance issues. Especially reprogramming PIT. > > Just forget about reprogramming with PIT. IMHO that should > be never used in production. The right way for this > is HPET.
PIT + PM timer / TSC is already working quite nicely. Of course it does not allow long sleeps, but it still helps in bringing down the HZ to about 35HZ.
> The main issue with HPET is that many BIOS even though the chipsets > have it don't set up the HPET table because Windows doesn't use > it right now. However that can be avoided with some chipset > specific code.
I don't have any x86 HPET hardware right now. But it sounds like it should allow multisecond skipping of ticks.
Regards,
Tony - 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/
| |