Re: dynamic-hz

[Tony Lindgren]

* Tony Lindgren <tony@xxxxxxxxxxx> [041214 16:22]:
> * linux-os <linux-os@xxxxxxxxxxxxxxxxxx> [041214 15:04]:
> > On Tue, 14 Dec 2004, Pavel Machek wrote:
> > 
> > >Hi!
> > >
> > >>>>The patch in question is at:
> > >>>>
> > >>>>http://linux-omap.bkbits.net:8080/main/user=tmlind/patch@xxxxxxxxxxx?nav=!-|index.html|stats|!+|index.html|ChangeSet@-12w|cset@xxxxxxxxxxx
> > >>>
> > >>>Wow, that's basically 8 lines of code plus driver for new
> > >>>hardware... Is it really that simple?
> > >>
> > >>Yeah, the key things are reprogramming the timer in the idle loop
> > >>based on next_timer_interrupt(), and calling timer_interrupt from
> > >>other interrupts as well :)
> > >>
> > >>Should we try a similar patch for x86/amd64? I'm not sure which timers
> > >>to use though? One should be programmable length for the interrupt,
> > >>and the other continuous for the timekeeping.
> > >
> > >Yes, it would certainly be interesting. 5% power savings, and no
> > >singing capacitors, while keeping HZ=1000. Sounds good to me.
> > >
> > >There are about 1000 timers available in PC, each having its own
> > >quirks. CMOS clock should be able to generate 1024Hz periodic timer
> > >(we currently do not use) and TSC we currently use for periodic timer
> > >should be usable in single-shot mode.
> > >								Pavel
> > >--
> > 
> > If you use that RTC timer, it needs to be something that can be
> > turned OFF. Many embedded applications use that because its the
> > only timer that the OS doesn't muck with. It also has very low
> > noise which makes in a good timing source for IIR filters for
> > high precision, low data-rate data acquisition (like 24 bits).
> 
> OK, thanks for the information. That could be the continuous timer
> then, and TSC the periodic timer.
> 
> > Since it generates an edge, its interrupt can't be shared.
> > I certainly hope that you don't use it. One can read the
> > time without disturbing the interrupt rate. One just
> > needs to use the existing rtc_lock and not spin with
> > the lock being held.
> 
> Yeah, the timer update would be just a read from the RTC timer.
> 
> > Currently the kernel RTC software allocates the RTC interrupt
> > even though it doesn't use it. This makes it necessary to
> > compile the RTC as a module and then remove it when another
> > driver needs to use the RTC interrupt source.
> 
> The interrupt could be used for timer wrap only.

Well just to follow up, I did some experiments over the weekend on
my old athlon box, and looks like it's doable. I'll set up something
common where various timers can register their no-tick functions.

So far I have APIC timer doing the no-tick interrupts, and nothing
yet for the timer to update time from. The code will using whatever
timers as long as they implement the right functions.

I'll post some patches when I have something working... Probably
after the holidays.

Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/