Powertop BOF at Linuxworld 2007 (Shallow Thoughts)

Powertop BOF at Linuxworld 2007

The best thing at Linuxworld was the Powertop BOF, despite the fact that it ended up stuck in a room with no projector. The presenter, Arjan van de Ven, coped well with the setback and managed just fine.

The main goal of Powertop is to find applications that are polling or otherwise waking the CPU unnecessarily, draining power when they don't need to. Most of the BOF focused on "stupid stuff": programs that wake up too often for no reason. Some examples he gave (many of these will be fixed in upcoming versions of the software):

• gnome-screensaver checked every 2 sec to see if the mouse moved (rather than using the X notification for mouse move);
• gnome volume checked 10 times a second whether the volume has changed;
• gnome-clock woke up once a second to see if the minute had rolled over, rather than checking once a minute;
• firefox in an ssl layer polled 10 times a second in case there was a notification;
• the gnome file monitor woke up 40 times a second to check a queue even if there was nothing in the queue;
• evolution woke up 10 times a second;
• the fedora desktop checked 10 times a second for a smartcard;
• gksu used a 10000x/sec loop (he figures someone mistook milliseconds/microseconds: this alone used up 45 min on one battery test run)
• Adobe's closed-source flash browser plugin woke up 2.5 times a second, and acroread had similar problems (this has been reported to Adobe but it's not clear if a fix is coming any time soon).

And that's all just the desktop stuff, without getting into other polling culprits like hal and the kernel's USB system. The kernel itself is often a significant culprit: until recently, kernels woke up once a millisecond whether they needed to or not. With the recent "tickless" option that appeared in the most recent kernel, 2.6.22, the CPU won't wake up unless it needs to.

A KDE user asked if the KDE desktop was similarly bad. The answer was yes, with a caveat: Arjan said he gave a presentation a while back to a group of KDE developers, and halfway through, one of the developers interrupted him when he pointed out a problem to say "That's not true any more -- I just checked in a fix while you were talking." It's nice to hear that at least some developers care about this stuff! Arjan said most developers responded very well to patches he'd contributed to fix the polling issues.

(Of course, those of us who use lightweight window managers like openbox or fvwm have already cut out most of these gnome and kde power-suckers. The browser issues were the only ones that applied to me, and I certainly do notice firefox' polling: when the laptop gets slow, firefox is almost always the culprit, and killing it usually brings performance back.)

As for hardware, he mentioned that some linux LCD drivers don't really dim the backlight when you reduce brightness -- they just make all the pixels darker. (I've been making a point of dimming my screen when running off batteries; time to use that Kill-A-Watt and find out if it actually matters!) Wireless cards like the ipw100 use a lot of power even when not transmitting -- sometimes even more than when they're transmitting -- so turning them off can be a big help. Using a USB mouse can cut as much as half an hour off a battery. The 2.6.23 kernel has lots of new USB power saving code, which should help. Many devices have activity every millisecond, so there's lots of room to improve.

Another issue is that even if you get rid of the 10x/sec misbehavers, some applications really do need to wake up every second or so. That's not so bad by itself, but if you have lots of daemons all waking up at different times, you end up with a CPU that never gets to sleep.

The solution is to synchronize them by rounding the wakeup times to the nearest second, so that they all wake up at about the same time, and the CPU can deal with them all then go back to sleep. But there's a trick: each machine has to round to a different value. You don't want every networking application on every machine across the internet all waking up at once -- that's a good way to flood your network servers. Arjan's phrase: "You don't want to round the entire internet" [to the same value].

The solution is a new routine in glib: timeout_add_seconds. It takes a hash of the hostname (and maybe other values) and uses that to decide where to round timeouts for the current machine. If you write programs that wake up on a regular basis, check it out. In the kernel, round_jiffies does something similar.

After all the theory, we were treated to a demo of powertop in action. Not surprisingly, it looks a bit like top. High on the screen is summary information telling you how much time your CPU is spending in the various sleep states. Getting into the deeper sleep states is generally best, but it's not quite that simple: if you're only getting there for short periods, it takes longer and uses more power to get back to a running state than it would from higher sleep states.

Below that is the list of culprits: who is waking your CPU up most often? This updates every few seconds, much like the top program. Some of it's clear (names of programs or library routines); other lines are more obscure if you're not a kernel hacker, but I'm sure they can all be tracked down.

At the bottom of the screen is a geat feature: a short hint telling you how you could eliminate the current top offender (e.g. kill the process that's polling). Not only that, but in many cases powertop will do it for you at the touch of a key. Very nice! You can try disabling things and see right away whether it helped.

Arjan stepped through killing several processes and showing the power saving benefits of each one. (I couldn't help but notice, when he was done, that the remaining top offender, right above nautilus, was gnome-power-manager. Oh, the irony!)

It's all very nifty and I'm looking forward to trying it myself. Unfortunately, I can't do that on the laptop where I really care about battery life. Powertop requires a kernel API that went in with the "tickless" option, meaning it's in 2.6.22 (and I believe it's available as a patch for 2.6.21). My laptop is stuck back on 2.6.18 because of an IRQ handling bug (bug 7264). Powertop also requires ACPI, which I have to disable because of an infinite loop in kacpid (bug 8274, Ubuntu bug 75174). It's frustrating to have great performance tools like powertop available, yet not be able to use them because of kernel regressions. But at least I can experiment with it on my desktop machine.