Intel announces the PowerTOP utility for Linux

What's eating the battery life of my laptop? Why isn't it many more hours? Which software component causes the most power to be burned? These are important questions without a good answer... until now.

The Linux 2.6.21 kernel introduces the so called tickless-idle feature. This feature allows the processor to be really idle for long periods of time, rather than having to wake up every millisecond for the timer tick. Current processors save a lot of power if they are idle for long periods, which translates into a longer battery life for your laptop, or a lower energy bill for your datacenter. However, a Linux system consists of more software than just the kernel, and there are many tunables involved. It's not easy to see what is going on, and as a result the behavior is sometimes far from optimal, and a lot of power is wasted.

Intel is proud to announce the PowerTOP tool (http://www.linuxpowertop.org), a program that collects the various pieces of information from your system and presents an overview of how well your laptop is doing in terms of power savings. In addition, PowerTOP will provide an indication of which tunables and software components are the biggest offenders in slurping up your battery time. PowerTOP will update it's display frequently so that you can directly see the impact of any changes you are making.

A typical Linux distribution has many components that wake the processor up frequently for no good reason. In our testing with PowerTOP, we have seen many cases where with some simple fixes, the battery life of typical laptops was increased by one hour or more!

We are providing fixes for several of the issues we identified, and we encourage the Linux community to help us in this quest to get the maximum battery life out of your (hopefully Intel based) laptops. Try the PowerTOP tool, join the mailing list or the IRC channel and provide feedback, problem reports or fixes!

Website:      http://www.linuxpowertop.org
IRC:          irc.oftc.net    #powertop channel
Mailing list: http://www.bughost.org/mailman/listinfo/power

I get:

No detailed statistics available; please enable the CONFIG_TIMER_STATS kernel option

with:

$ zgrep STATS /proc/config.gz 
# CONFIG_TASKSTATS is not set
# CONFIG_SCHEDSTATS is not set
CONFIG_TIMER_STATS=y

Mathematics is the supreme nostalgia of our time.

Words by Matt Mackall [Fri, May 11, 2007 at 07:17:19PM -0500]:

Must run as root (rw to /proc/timer_stats is needed).

Jose Celestino
----------------------------------------------------------------
http://www.msversus.org/     ; http://techp.org/petition/show/1
http://www.vinc17.org/noswpat.en.html
----------------------------------------------------------------
"And on the trillionth day, Man created Gods." -- Thomas D. Pate

That file doesn't exist, despite CONFIG_TIMER_STATS being in /proc/config.gz.

Mathematics is the supreme nostalgia of our time.

Words by Matt Mackall [Fri, May 11, 2007 at 09:39:05PM -0500]:

Then again, perhaps you have /proc/tstats instead.

If so apply this (well, you get the idea):

@@ -212,8 +212,8 @@
 void stop_timerstats(void)
 {
        FILE *file;
-       file = fopen("/proc/timer_stats","w");
-       if (!file) {
+       if (!(file = fopen("/proc/timer_stats","w")) &&
+               !(file = fopen("/proc/stats","w")) ) {
                nostats = 1;
                return;
        }

@@ -223,8 +223,8 @@
 void start_timerstats(void)
 {
        FILE *file;
-       file = fopen("/proc/timer_stats","w");
-       if (!file) {
+       if (!(file = fopen("/proc/timer_stats","w")) &&
+               !(file = fopen("/proc/stats","w")) ) {
                nostats = 1;
                return;
        }

@@ -388,7 +388,7 @@
                i = 0;
                totalticks = 0;
                if (!nostats)
-                       file = popen("cat /proc/timer_stats | sort -n | tail -190", "r");
+                       file = popen("cat /proc/timer_stats 2>>/dev/null|| cat /proc/tstats | sort -n | tail -190", "r");
                while (file && !feof(file) && i<190) {
                        char *count, *pid, *process, *func;
                        int cnt;

Jose Celestino
----------------------------------------------------------------
http://www.msversus.org/     ; http://techp.org/petition/show/1
http://www.vinc17.org/noswpat.en.html
----------------------------------------------------------------
"And on the trillionth day, Man created Gods." -- Thomas D. Pate

Yeah, hal happily wakes up every two seconds. So much for the effectivity of NO_HZ.

# ps afx | grep hal
 ...
 3003 ?        S      0:00      \_ hald-addon-storage: polling /dev/hdb
 ...
# strace -p 3003
Process 3003 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>) = 0
open("/dev/hdb", O_RDONLY|O_NONBLOCK|O_EXCL|O_LARGEFILE) = 4
ioctl(4, CDROM_DRIVE_STATUS, 0x7fffffff) = 1
close(4)                                = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({2, 0}, {2, 0})               = 0
open("/dev/hdb", O_RDONLY|O_NONBLOCK|O_EXCL|O_LARGEFILE) = 4
ioctl(4, CDROM_DRIVE_STATUS, 0x7fffffff) = 1
close(4)                                = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({2, 0}, {2, 0})               = 0
open("/dev/hdb", O_RDONLY|O_NONBLOCK|O_EXCL|O_LARGEFILE) = 4
ioctl(4, CDROM_DRIVE_STATUS, 0x7fffffff) = 1
close(4)                                = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({2, 0},  <unfinished ...>

Jan

The AN patches that Kristen posted a few days ago will fix this part of hal for real... assuming you have hardware with AN support that is.

they are in -mm now... should go mainline in like 2.6.23

This is a really great tool and presents a very intuitive alternative to the timer stats file..

On a Core 2 Duo Macbook, Linux always gets around 3.2h battery, OS X about 4.2h. This tool has identified that uhci_hcd is where 75% of the ticks are going when X is not loaded. Unloading uhci_hcd drops the battery life back to around 4.2h, but I lose the keyboard.

Is there any way to find out what USB driver is causing usb_uhci to be this busy?

(BTW, the link to Keith's patch for dhcdbd seems to be broken on your homepage.)

Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

At its worst, it _is_ the USB chip that draws the power when it is active (when uhci_hcd is loaded); does not need to be usbhid or so.

Jan

This is certainly true, and to a significant extent it _was_ the uhci_hcd, but it turns out the main contributor to HZ here were the appletouch and hci_usb drivers. Disabling both drops the ticks down from about 850 to 150.

Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.