Another Major Linux Power Regression Spotted

[alien]

Any news regarding the git bisect?

It would be nice if both regressions (introduced in 2.6.35 and 2.6.38)could be spotted and fixed easily, then back-ported into the stable kernels so servers could also benefit from this research and lot of CO2 would be saved all around the world.

[stevea]

I just did some tests w/ my Lenovo Thinkpad T510, i5-560M. The system was lightly loaded ith poewrto pa nd a script to record power at 5 second intervals. firefox was running, and webpages refresseh 4 times through the tes.t The system was allowed to idel to a screen-dim state for one ~ 5 second interval.

Power consumption was measured by access to the smart-battery smapi interface.

Under Linux 2.6.35.12 -
average power: 14.674W
lowest recorded: 12.731W (display dimmed)
highest recorded: 19.103W (broswer update)

Under Linux 2.6.38.4 - (same config with default 'make oldconfig' defaults).
average power: 13423W
lowest recorded: 11.752W (display dimmed)
highest recorded: 17.979W (broswer update)

My causal observation viewing powertop is that both kernels typically had 130-140 wakups per second, however the 2.6.35.12 showed a few infrequent very high peaks.

My impression is that Linux 2.6.38.4 has considerably lower power use on my thinkpad, saving perhaps 1. - -1.2 Watts on average.

There may well be power regression on some kernels for some hardware, but the extrapolated implication that this is widespead or applies to many/most systems is not justified by the evidence.

[stevea]

Apologies for the typos.. Should read

130-140 wakups per 5 second interval, the default for powertop.

[wstorm]

My impression is that Linux 2.6.38.4 has considerably lower power use on my thinkpad, saving perhaps 1. - -1.2 Watts on average.

I had noticed this improvement too on asus k42jv i3 350 using Archlinux.
Last time, i was able to comfortably work almost 2hrs in Matlab, on battery power.
2.6.38.4, idle: ~12W, load: ~20-21W, with nvidia turned off ( nvidia optimus is worst choice for linux notebook, eh ). Custom kernel may be better, but 2 hours long battery life is quite enough for me

[0laf]

Hi guys,

I have been unable to reproduce this bug as well
I compared kernel 2.6.32 with 2.6.38 on Debian Squeeze but nothing spectacular happened.

I ve posted my results here: =>Link
It's written in german, unfortunately, but I guess the graphs should be pretty self-explaning

[wstorm]

I had noticed this improvement too on asus k42jv i3 350 using Archlinux.
Last time, i was able to comfortably work almost 2hrs in Matlab, on battery power.
2.6.38.4, idle: ~12W, load: ~20-21W, with nvidia turned off ( nvidia optimus is worst choice for linux notebook, eh ). Custom kernel may be better, but 2 hours long battery life is quite enough for me

_but_, after upgrading to 38.5, i had suddenly caught that "major regression" 12-13->17-18 Watts, omg. BTW, I suppose, that i successfully turned off my nvidia optimus card (according to acpi_call script output) and i didn't run any gui (i had "up"graded to gnome3 that time).

[Thetargos]

I can confirm that this problem is present at least in the 2.6.38.6 kernel as found in Fedora 15 Beta. What is odd is that apparently in numbers, this version does seem to use less watts, however, the battery life-time has been reduced in more than 30 minutes from what it was in the previous release (Fedora 14 and 2.6.35.x), which was still lagging behind for about 20 minutes the power-performance that Windows Vista achieved in this particular setup.

I'm using an AMD Turion X2 (TL-58) based system with the SB600 chipset and RS690M graphics. At most, I can manage to get about one hour worth of power after a full recharge of the battery (prior making sure it was totally drained before the full charge).

The battery is not damaged, as I can test with a twin system with the 2.6.35 kernel and it yields almost twice the time worth of power than this. So for me, this time around numbers are being deceiving... There must be something using more power than is actually being reported back to the OS... Plus the fan seems to be on much more, and I DO feel the difference on the keyboard, as it is quite noticeably hotter.

[palitre]

I have a toshiba laptop with an AMD Turion 64 tl56 supposed to run at 1.8 ghz in windows 7 and vista it is stuck at 800 mhz i assume it is a driver issue but i cant seem to find any updates. I have updated bios and checked all settings also i have changed all power settings to high performance any ideas would be appreciated.

[amphigory]

I have a toshiba laptop with an AMD Turion 64 tl56 supposed to run at 1.8 ghz in windows 7 and vista it is stuck at 800 mhz i assume it is a driver issue but i cant seem to find any updates. I have updated bios and checked all settings also i have changed all power settings to high performance any ideas would be appreciated.

Use 'cpufreq-info' to check CPU governor being used. In my case output looks like this:

eherr@quark:~$ cpufreq-info 
cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: powernow-k8
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 8.0 us.
  hardware limits: 800 MHz - 1.70 GHz
  available frequency steps: 1.70 GHz, 1.30 GHz, 800 MHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance
  current policy: frequency should be within 800 MHz and 1.70 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz.
  cpufreq stats: 1.70 GHz:4.11%, 1.30 GHz:0.27%, 800 MHz:95.62%  (1362)

If command is not available you should install package 'cpufrequtils' (that is the name in Debian anyway).

To change CPU governors and other parameters you can use the complimentary command 'cpufreq-set'.

For laptop use you probably do not want to use the 'performance' governor as it will have an adverse effect on battery drain.