Messages in this thread | | | Date | Tue, 7 Nov 2006 09:18:39 +0100 | From | Andreas Mohr <> | Subject | Re: CONFIG_NO_HZ: missed ticks, stall (keyb IRQ required) [2.6.18-rc4-mm1] |
| |
Hi,
On Tue, Nov 07, 2006 at 01:41:16AM -0500, Len Brown wrote: > On Monday 06 November 2006 15:58, Andreas Mohr wrote: > > > > > How useful would it be to simply disable C2 operation (but not C1) > > > > in CONFIG_NO_HZ mode after's been determined to kill APIC timer?: > > If the goal is saving power, then disabling dynticks will likely > be more attractive than disabling C2. Perhaps you can measure it? > eg. simply run "bltk -I" to measure idle battery life (http://sourceforge.net/projects/bltk)
Surely the CMOS battery?? Seriously, no battery here anywhere ;)
Anyway, I was already afraid that I didn't have any of my *two* different power measurement devices here, but then I found one in the drawer (Conrad EKM 265, to be precise).
The results are (waited for values to settle down each time):
-dyntick4, C1, CONFIG_NO_HZ: 83.9W KDE idle, 95.2W bash while 1 -dyntick4, C2 (C1-only hack disabled, kernel rebuilt), CONFIG_NO_HZ off: 84.4W KDE idle, 95.4W bash while 1 -dyntick4, acpi=off (i.e. APM active), -dynticks: 85.5W KDE idle, 95.5W bash while 1
Bet you didn't see this coming...
Again, this is Athlon 1200 *desktop*, with some EPOX VIA motherboard ("8K5A3+" ??).
Note that even with dynticks disabled did I have a pause on boot where I had to fiddle with the keyboard once to continue booting, IOW our APIC timer probing disrupts normal interrupt processing due to C2 -> C3 AMD BIOS bug. We might want to fix probing to not require manual generation of the next interrupt event due to APIC timer temporarily being "dead".
> But this is even more true when talking about C3 -- it certainly saves more > power than dynticks does. This is true for the example system here: > http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/doc/OLS2006-bltk-paper.pdf > > So given that C3 on every known system that has shipped to date > breaks the LAPIC timer (and apparently this applies to C2 on these AMD boxes), > dynticks needs a solid story for co-existing with C3.
Indeed, we need a good and flexible fallback mechanism. However I would slightly slant dynticks towards being active even in cases where it actually happens to consume *slightly* more power due to C2 disabled, since it *seems* that CPU load is lower with dynticks (less timer background load) / desktop timing is slightly more precise. And we all want fast desktops that are waaaaay better than XP, right?
Andreas Mohr - 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/
| |