lkml.org 
[lkml]   [2005]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-06-13 21:40    [W:0.062 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site