On Tue, 2005-01-18 at 22:37 -0800, Tony Lindgren wrote: > * Benjamin Herrenschmidt <[EMAIL PROTECTED]> [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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
