Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[announce] Intel announces the PowerTOP utility for Linux

3 views
Skip to first unread message

Arjan van de Ven

unread,
May 11, 2007, 7:08:47 PM5/11/07
to Linux Kernel Mailing List

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Matt Mackall

unread,
May 11, 2007, 8:17:42 PM5/11/07
to Arjan van de Ven
On Fri, May 11, 2007 at 04:07:18PM -0700, Arjan van de Ven wrote:
>
> 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.

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.

Jose Celestino

unread,
May 11, 2007, 9:41:02 PM5/11/07
to Matt Mackall
Words by Matt Mackall [Fri, May 11, 2007 at 07:17:19PM -0500]:

> On Fri, May 11, 2007 at 04:07:18PM -0700, Arjan van de Ven wrote:
> >
> > 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.
>
> I get:
>
> No detailed statistics available; please enable the CONFIG_TIMER_STATS
> kernel option
>

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

Matt Mackall

unread,
May 11, 2007, 10:39:32 PM5/11/07
to Arjan van de Ven, Linux Kernel Mailing List, linux...@vger.kernel.org
On Sat, May 12, 2007 at 02:40:52AM +0100, Jose Celestino wrote:
> Words by Matt Mackall [Fri, May 11, 2007 at 07:17:19PM -0500]:
> > On Fri, May 11, 2007 at 04:07:18PM -0700, Arjan van de Ven wrote:
> > >
> > > 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.
> >
> > I get:
> >
> > No detailed statistics available; please enable the CONFIG_TIMER_STATS
> > kernel option
> >
>
> Must run as root (rw to /proc/timer_stats is needed).

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

--
Mathematics is the supreme nostalgia of our time.

Jose Celestino

unread,
May 12, 2007, 12:09:45 AM5/12/07
to Matt Mackall
Words by Matt Mackall [Fri, May 11, 2007 at 09:39:05PM -0500]:

> On Sat, May 12, 2007 at 02:40:52AM +0100, Jose Celestino wrote:
> > Words by Matt Mackall [Fri, May 11, 2007 at 07:17:19PM -0500]:
> > > On Fri, May 11, 2007 at 04:07:18PM -0700, Arjan van de Ven wrote:
> > > >
> > > > 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.
> > >
> > > I get:
> > >
> > > No detailed statistics available; please enable the CONFIG_TIMER_STATS
> > > kernel option
> > >
> >
> > Must run as root (rw to /proc/timer_stats is needed).
>
> That file doesn't exist, despite CONFIG_TIMER_STATS being in
> /proc/config.gz.
>

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

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

--- powertop/powertop.c 2007-05-12 05:01:15.000000000 +0100
+++ powertop_new/powertop.c 2007-05-12 05:08:46.000000000 +0100
@@ -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

Jan Engelhardt

unread,
May 12, 2007, 7:01:32 AM5/12/07
to Arjan van de Ven

On May 11 2007 16:07, Arjan van de Ven wrote:
>
> 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!

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
--

Arjan van de Ven

unread,
May 12, 2007, 1:56:55 PM5/12/07
to Jan Engelhardt
On Sat, 2007-05-12 at 13:00 +0200, Jan Engelhardt wrote:
> On May 11 2007 16:07, Arjan van de Ven wrote:
> >
> > 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!
>
> Yeah, hal happily wakes up every two seconds. So much for
> the effectivity of NO_HZ.


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

Alistair John Strachan

unread,
May 12, 2007, 5:13:03 PM5/12/07
to Arjan van de Ven
On Saturday 12 May 2007 00:07:18 Arjan van de Ven wrote:
> 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.

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.

Jan Engelhardt

unread,
May 14, 2007, 4:24:42 PM5/14/07
to Alistair John Strachan

On May 12 2007 22:12, Alistair John Strachan wrote:
>On Saturday 12 May 2007 00:07:18 Arjan van de Ven wrote:
>> 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.
>
>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?

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
--

Alistair John Strachan

unread,
May 14, 2007, 4:42:47 PM5/14/07
to Jan Engelhardt
On Monday 14 May 2007 21:22:50 Jan Engelhardt wrote:
> On May 12 2007 22:12, Alistair John Strachan wrote:
> >On Saturday 12 May 2007 00:07:18 Arjan van de Ven wrote:
> >> 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.
> >
> >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?
>
> 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.

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.

Robert Hancock

unread,
May 14, 2007, 8:14:00 PM5/14/07
to Arjan van de Ven
Looks like the radeon driver has the same problem as the i915 driver
mentioned on the known problems page - I get 60 wakeups/sec from it on
my Compaq X1000 laptop (Radeon 9000 graphics) while in X, which
essentially prevents entry into C3.

--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hanc...@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Ondrej Zary

unread,
May 15, 2007, 12:30:31 PM5/15/07
to Robert Hancock
On Tuesday 15 May 2007 02:13:15 Robert Hancock wrote:
> Looks like the radeon driver has the same problem as the i915 driver
> mentioned on the known problems page - I get 60 wakeups/sec from it on
> my Compaq X1000 laptop (Radeon 9000 graphics) while in X, which
> essentially prevents entry into C3.

And Rage 128 too.

--
Ondrej Zary

Schmidt Michal

unread,
May 16, 2007, 3:53:51 AM5/16/07
to Ondrej Zary
Ondrej Zary wrote:
> On Tuesday 15 May 2007 02:13:15 Robert Hancock wrote:
>> Looks like the radeon driver has the same problem as the i915 driver
>> mentioned on the known problems page - I get 60 wakeups/sec from it on
>> my Compaq X1000 laptop (Radeon 9000 graphics) while in X, which
>> essentially prevents entry into C3.
>
> And Rage 128 too.
>

I have a Radeon 7500 in my laptop. The attached hack to disable the
VBLANK interrupt works for me. I don't know if it breaks 3D, I've only
tried 2D.

Michal

radeon-no-vblank-int.diff

Pavel Machek

unread,
May 16, 2007, 3:20:03 PM5/16/07
to Schmidt Michal
Hi!

Hmm, you should probably find where it is used, and only enable irq
when neccessary. Disabling it always will break something.

> diff --git a/drivers/char/drm/radeon_irq.c b/drivers/char/drm/radeon_irq.c
> index 3ff0baa..a990bb6 100644
> --- a/drivers/char/drm/radeon_irq.c
> +++ b/drivers/char/drm/radeon_irq.c
> @@ -227,9 +227,8 @@ void radeon_driver_irq_postinstall(drm_device_t * dev)
> atomic_set(&dev_priv->swi_emitted, 0);
> DRM_INIT_WAITQUEUE(&dev_priv->swi_queue);
>
> - /* Turn on SW and VBL ints */
> - RADEON_WRITE(RADEON_GEN_INT_CNTL,
> - RADEON_CRTC_VBLANK_MASK | RADEON_SW_INT_ENABLE);
> + /* Turn on the SW interrupt */
> + RADEON_WRITE(RADEON_GEN_INT_CNTL, RADEON_SW_INT_ENABLE);
> }
>
> void radeon_driver_irq_uninstall(drm_device_t * dev)


--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

0 new messages