Frequently Asked Questions

If you have any ideas or suggestions for this page, please send them to me--Margie--at margie.foster@intel.com. Thanks!

Do I need a laptop to profile an application?

No, the only missing information will be the power usage based on the battery drain. That will vary anyway from laptop to laptop based on display size, components, and general ambient temperature.

How do I reduce power consumption on my machine?

When a CPU is idle, it is possible for the processor to go into a sleep mode (C state). Changing C states involves power. What we are trying to measure is how many times your machine manages to sleep, how long it takes to sleep, and what is causing it to wake up from sleep.

What distribution is required?

Any distribution that supports kernel 2.6.21 or newer with dynticks enabled.

What kernel options should I enable inside the kernel?

CONFIG_NO_HZ
CONFIG_HIGH_RES_TIMERS
CONFIG_HPET_TIMER
CONFIG_CPU_FREQ_GOV_ONDEMAND
CONFIG_USB_SUSPEND
CONFIG_SND_AC97_POWER_SAVE
CONFIG_TIMER_STATS

What kernel options should I disable inside the kernel?

CONFIG_IRQBALANCE
CONFIG_ACPI_DEBUG

Which modules are known to reduce battery life?

snd_intel8x0m
fglrx
radeon
ipw*
bcm*
hdaps
ibm_acpi
i8042
nvidia

What numbers should I look for?

You should generally manage to lower the amount of wakeups per second. A total list of wakeups is provided for you; each type highlighted in a specific color. You should then start looking at the top applications that are causing the wakeups and either turn them off if they aren't being used, or file bugs (with possibly a patch) to the maintainer of that software, if possible. You should aim for around 95% average time in C3 or C4 with residency of 20ms to 30ms+.

I see only C0, C1, and C2. Why don't the other C-states show?

It's mostly a BIOS thing. Some BIOS hide C3/C4 when on AC power, and others show only C3 which is really a C4 underneath when on battery. Note that the 'max_cstate:C8' value in /proc/acpi/processor/*/power tells the maximum number of C-states the Linux kernel can handle, not the number of C-states implemented in your hardware.

Do I have to compile a custom kernel?

There are a couple of known ready-made packages for the following distributions:

open SuSE: http://bughost.org/pipermail/power/2007-May/000066.html
Ubuntu: the gutsy kernel has timer stats on and should boot a Feisty system

Otherwise, YES! You probably need to do that since 2.6.21 is fairly recent. We also encourage you to use the available patches for 2.6.21 or 2.6.22-rc1 including support for HPET timers.

Which chipsets support HPET timers?

If you have an ICH6 or higher chipset, you should be fine. Some support exists on ICH5 chipsets.

How do I know if HPET is really active on my system?

First, HPET must be compiled in the kernel. However, having HPET compiled in the kernel and a hardware chipset supporting HPET doesn't guarantee that HPET is active. You can verify this with the command:

grep hpet /proc/timer_list

If this doesn't show the word "hpet" then it's not active. The BIOS may hide this functionality as well. You should try the force-enable HPET patch from http://linuxpowertop.org/known.php.

I have an interrupt causing lots of wakeups. How can I know which device is causing the interrupt?

Start by reducing the amount of activity on the machine to reduce bias of measurement. Remove the modules used by that interrupt one by one. Annotate the amount of wakeups on your system after each removal to find the biggest culprit. If the drivers are compiled inside the kernel, recompile your kernel with the driver as a module and try again.

Why did my power usage increase with dynticks? Why do I never reach sleep states deeper than C2?

The current ACPI sleep function requires wakeups to reach deeper sleep states. Certain drivers, such as ipw2200, limit the initial sleep state to C2 due to DMA activity. With dynticks, which tries to sleep as long as possible, this means that your processor will, most of the time, only reach C2 and thus waste power compared to a non-dynticks kernel if it is mostly idle. This will be solved by an upcoming cpuidle patch. Until this hits mainline, you should compare your power usage with and without dynticks (and maybe with different HZ values) to figure out which is currently the best for your workload.

What exactly is the number in parentheses in "39.4% (115.6) foo: bar"?

It's the number of wakeups per second and per CPU core.

Should "Wakeups-from-idle per second" equal the sum of the wakeups/second/core listed on the "Top causes for wakeups" list?

It should be higher, since there are some causes for wakeups that are nearly impossible to detect by software.

What is i8042 in "(interrupt) :i8042?"

i8042 is the kernel driver for keyboard and mouse controllers.

Why do I see many "(interrupt) :ide1" or libata or ide0?

Something (maybe hald) may be polling your CDROM regularly (ide1, the second IDE controller, is often where the CDROM is attached on many laptops). Try disabling hal. Otherwise, the kernel's laptop_mode helps to reduce hard drive activity.

What is "(interrupt) : extra timer interrupt"?

Even with a tickless kernel, there are some timer ticks still happening:

1.) For userspace events (also shown in the lower "top 10 events" list).
2.) The kernel still has timer ticks when userspace is executing code, to sample and get data for the "top" program.
3.) Hardware timers have a maximum time they can be set for, for the PIT timer (the one used if you don't have HPET active). This is around 27 milliseconds. If you would have longer sleep times than the maximum, the kernel has no choice but to set the timer to the maximum repeatedly until the actual event is approaching.

The "extra timer interrupts" data is a combination fo 1 and 3.

Why do I see many "do_setitimer"?

"itimer" are userspace timers; a program has requested to be delivered a signal after a certain amount of time.

Disk activity drains a lot of power. How can I trace block I/O?

The blktrace and iostat tools are helpful. We plan to add this functionality to an upcoming version of PowerTOP.

Would the 'Option "NoDRI"' workaround help to reduce interrupts with non-Intel 915 graphic chipsets drivers?

It is reported that deactivating 3D acceleration by adding 'Option "NoDRI"' on the "Device" section of /etc/X11/xorg.conf (as recommended in http://linuxpowertop.org/known.php) helps Radeon drivers.

Why is "ondemand" kernel's CPU governor more efficient than the "conservative" one (or than manually lowering CPU freq)?

At lower freqs, your CPU may take more time to execute heavy tasks, so will spend less time in idle (power saving) state. The "ondemand" governor solves this by elevating the CPU to full speed when needed, so it can go back to idle state quickly.

What exactly is schedule_timeout?

It's a kernel function that is there to create a non-busy-looping delay. If you see it in PowerTOP, it is usually because the program calls select() or poll() with a short timeout. One way to find out what your application is doing is strace -tt -p $(pidof yourapplication). If it shows select() or poll() a lot, it's doing really short timeout polls. Also look at http://primates.ximian.com/~federico/news-2006-09.html#polling and http://blogs.gnome.org/view/ryanl/2006/07/27/0.

How do I know why the userland application XXX is keeping my CPU busy?

You might trace your application while running to see what it's doing:

strace -tt -p$(pidof XXX)
and/or
ltrace -p$(pidof XXX)

I get '/usr/bin/ld: cannot find -lncursesw' as an error when compiling.

If you are using Debian or Ubuntu Feisty, install the libncursesw5-dev package.

What are the polling intervals of various cx88 cards?

These are polling intervals for cards supported by this driver, according to drivers/media/video/cx88/cx88-input.c:

* Cards with no ir polling in driver:
   - CX88_BOARD_TERRATEC_CINERGY_1400_DVB_T1
   - CX88_BOARD_TERRATEC_CINERGY_1400_DVB_T1
   - CX88_BOARD_HAUPPAUGE
   - CX88_BOARD_HAUPPAUGE_DVB_T1
   - CX88_BOARD_HAUPPAUGE_NOVASE2_S1
   - CX88_BOARD_HAUPPAUGE_NOVASPLUS_S1
   - CX88_BOARD_HAUPPAUGE_HVR1100
   - CX88_BOARD_HAUPPAUGE_HVR1300
   - CX88_BOARD_HAUPPAUGE_HVR3000
   - CX88_BOARD_DNTV_LIVE_DVB_T_PRO

* Cards with polling every 50 ms:
   - CX88_BOARD_NPGTECH_REALTV_TOP10FM
   - CX88_BOARD_NORWOOD_MICRO
   - CX88_BOARD_AVERTV_303
   - CX88_BOARD_AVERTV_STUDIO_303
   - CX88_BOARD_ADSTECH_DVB_T_PCI
   - CX88_BOARD_WINFAST_DTV2000H
   - CX88_BOARD_DNTV_LIVE_DVB_T
   - CX88_BOARD_KWORLD_DVB_T
   - CX88_BOARD_KWORLD_DVB_T_CX22702

* Cards with polling every 5 ms:
   - CX88_BOARD_IODATA_GVBCTV7E

* Cards with polling every 1 ms:
   - CX88_BOARD_PROLINK_PLAYTVPVR:
   - CX88_BOARD_PIXELVIEW_PLAYTV_ULTRA_PRO:
   - CX88_BOARD_KWORLD_LTV883:
   - CX88_BOARD_MSI_TVANYWHERE_MASTER:
   - CX88_BOARD_WINFAST2000XP_EXPERT:

What is tickless, how does it work?

To explain this I need to go back 15 years in time; at that time a PC had only the PIT timer chip, which was good at doing a periodic interrupt. Basically all operating systems started using this periodic timer (since it was there) to do their "perform this action X milliseconds in the future" functionality. So every time the PIT created an interrupt, the OS would check the queue of "future work" for stuff to be done, and there was something, it would do that work. If there is no work (which is the common case), it was no big deal; the hardware of the time didn't have a huge penalty for this.

Now, fast forward 15 years, PC's have more options for timer chips, notably the HPET chip and the local APIC timer. These two chips can be used more easily in a flexible manner. Another thing that changed is that the current processors have a lot of power saving features that kick in if there is no work to do; doing this kind of regular "no-work" really hurts. So this is where tickless comes in. On the surface, it's a really simple concept: Instead of doing the "interrupt every 1 millisecond" thing, Linux looks at the future works and sets the hardware to fire an interrupt exactly at the right time... and conceptually it really is that simple. It just took a long time since over those 15 years, Linux grew several assumptions about the presence of the regular tick interrupt that had to be weeded out, and in addition various funky hardware and BIOS issues had to be weeded out.