Linux Kernel Power Consumption Is Lowered, But Regressions Remain

[Jimbo]

kernel is still up by an approximate 18~20% over older (Linux 2.6.34 era)

ufffff!!! Michael, bisecting this shouldn't be your task. You already pointed the problem.

Linux is not so small, there is certain amount of manpower, linux foundations, consortium... I cannot accept that nobody is taking care of this awful regression. I even don't understand why they released a kernel which has 10-20% more power consumption?? this makes me seriously doubt about Linux kernel overall quality (until now I have been very confident about it)

[lienox]

Hi michael , I would love you to write a small howto on how i and others can help this, i have a small amount of sparetime and a spare x60 i can do some testing on. But i need help getting startet.

Which releases and commits do you take and build and test?

[djtm]

Reasons why it's taking so long to bisect:
1. Needing to manually plug/unplug power adapter...
2. Still haven't received (or otherwise figured out) any sub-$100 USB UPS/power-meter units for automatic power monitoring so fast desktop/workstations can be used for bisecting in a fully automated manner...

Why don't you do the bisecting and compiling on one sytem (64 core) and the testing on a normal notebook with battery? That should speed it up a lot.

But yes, it would be great to have power performance testing systems!

Why doesn't Linuxfoundation pay for some of the costs? And you could try to raise the money with donations, too.

[Jimmy]

micheael wrote it on zwitter some kernel versions are broken and this stops you in bisecting.

bisecting is only fast if every version you generate works but what is if you only generate not working versions?

$ git bisect skip

?

[Jimmy]

Why don't you do the bisecting and compiling on one sytem (64 core) and the testing on a normal notebook with battery? That should speed it up a lot.

But yes, it would be great to have power performance testing systems!

Why doesn't Linuxfoundation pay for some of the costs? And you could try to raise the money with donations, too.

I don't know the details but, distcc has been used to compile the Linux kernel. If you must run the build process from the laptop then at least you could leverage the processing power of other machines while building.

http://code.google.com/p/distcc/

Again I don't know the details, but it would seem that you could build the kernel quickly even on a laptop machine if you have a few machines running distcc for it.

[V!NCENT]

Reasons why it's taking so long to bisect:

[...]

OK, fair enough. But still making very large jumps instead of 'compile->commit+1->compile again' should still narrow it down very fast, right?

If you suspect a sequence of 10.000 commits, you start with:
-commit 1 and 5.000... change in voltage... no? (2 commits, narrowed down to 5.000 commits)
-commit 7.500 and 10.000... change in voltage... no? (4 commits, narrowed down to 2.500 commits)
-commit 5.000 (already tested) and 6.250... change in voltage... yes? (5 commits, narrowed down to 1.250 commits)

Etc...

EDIT: If you already have a reference voltage it's even faster...

[Jimmy]

OK, fair enough. But still making very large jumps instead of 'compile->commit+1->compile again' should still narrow it down very fast, right?

That's the whole point of using git bisect. You take a large set of commits, split them in half, test, repeat. Each time you test you effectively eliminate half the commits.

http://en.wikipedia.org/wiki/Binary_search_algorithm
http://www.kernel.org/pub/software/s...it-bisect.html

[Uncle Warthog]

Michael,

Here's a thought: What version of 2.6.37 are you using for testing? If it's the base 2.6.37 kernel, it might also be worth checking the most recent "stable" version, 2.6.37.6, vs. the base 2.6.37 version to see if the problem is something that might have worked its way in as part of a fix for something else. If the problem shows up in 2.6.37.6 but not 2.6.37, it might be possible to narrow down the problem via testing the other stable versions .1 through .5 without having to go through a complete bisect of everything between 2.6.37 and 2.6.38

[gns-ank]

I have an idea (actually I registered here just on purpose to say it )

I now that Michael had some Thinkpads to test (W500? and T61p?) or am I wrong? And they have tp_smapi module which lets you to configure lots of things about your battery. For example if one does:

 echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge

then the battery will discharge irrespectively whether the power cable is pluged in or not and the consumed power can be monitored as:

 cat /sys/devices/platform/smapi/BAT0/power_avg

The only drawback of this method is that the module is not in the mainline kernel, but building it together with the kernel every time (although, I do not think, that it might be 100% necessary) wouldn't very time consuming. And, overall, the bisecting could be easier, because one could write a simple script for that. And with Jimmy's suggestion to use

 git bisect skip

you could avoid the non-working kernel versions as well.

So guys, what do you think?

[spiff]

This is very disappointing. I would expect such issues to be a top priority for companies like Google (Android) and Canonical and Red Hat.

I would think that Canonical would care, but Google probably doesn't. It's not even know if ARM is affected, and ARM systems usually don't use the very newest kernels. Android only changes kernels once every so often, typically skipping a few releases each time.

For example: currently, my Android 2.3.4 phone (latest version for phones), is running on 2.6.32.41 - so they are definitely in no real rush to fix it.