Re: [PATCH] dynamic tick patch

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Tue, 2005-01-18 at 22:37 -0800, Tony Lindgren wrote:
> * Benjamin Herrenschmidt <benh@kernel.crashing.org> [050118 21:29]:
> > Hrm... reading more of the patch & Martin's previous work, I'm not sure
> > I like the idea too much in the end... The main problem is that you are
> > just "replaying" the ticks afterward, which I see as a problem for
> > things like sched_clock() which returns the real current time, no ?
> 
> Well so far I haven't found problems with time. Since sched_clock()
> returns the hw time, how does it cause a problem? Do you have some
> example in mind? Maybe there's something I haven't even considered
> yet.
> 
> > I'll toy a bit with my own implementation directly using Martin's work
> > and see what kind of improvement I really get on ppc laptops.
> 
> I'd be interested in what you come up with :)

Well, I did a very simple implementation entirely local to
arch/ppc/kernel, that basically calls timer_interrupt on every do_IRQ, I
don't change timer_interrupt (our implementation already knows how to
"catch up" already if missed ticks and knows how to deal beeing called
to early as well). Then, when going to idle loop, I "override" the
decrementer interrupt setting to be further in the future if
next_timer_interrupt() returns more than 1.

Strangely, I got not measurable improvement on power consumption despite
putting the CPU longer into NAP mode. Note that this may be very
different with earlier (G3 notably) CPUs, since G3 users repeately
reported me havign a significant loss in battery life with HZ=1000

Later, I'll do some stats to check how long I really slept, and see if
it's worth, when I predict a long sleep, flushing the cache and going
into a deeper PM mode where cache coherency is disabled too.

Ben.