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. What 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_HR_TIMERS CONFIG_HPET CONFIG_CPU_FREQ_GOV_ONDEMAND CONFIG_USB_SUSPEND What kernel options should I disable inside the kernel? CONFIG_IRQBALANCE Which modules are known to reduce battery life? snd_intel8x0m fglrx radeon ipw* bcm* hdaps 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 highlighted in a particular colour. You should then start looking at the top list of applications causing your wakeups and either turn them off if they are unneeded, 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 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 bioses hide c3/c4 when on AC power, and some bioses only show a C3 which is really a C4 underneath when on battery. Do I have to compile a custom kernel? There are a couple of known ready made packages for the following distributions: openSuSE: http://www.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 encouraged 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 ICH4M and ICH5M chipsets I have an causing lots of wakeups. How can I know which device is causing the interrupt? First start by reducing the amount of activity you are doing on your machine to reduce bias of measurements. Remove the modules used by that interrupt one bye 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.