Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 21

Thread: Linux Kernel Power Consumption Is Lowered, But Regressions Remain

  1. #11
    Join Date
    Nov 2009
    Posts
    328

    Default

    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)

  2. #12
    Join Date
    May 2011
    Posts
    1

    Default Howto bisecting

    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?

  3. #13
    Join Date
    Jun 2008
    Posts
    28

    Default

    Quote Originally Posted by Michael View Post
    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.

  4. #14
    Join Date
    Feb 2008
    Location
    USA
    Posts
    192

    Default

    Quote Originally Posted by Qaridarium View Post
    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?
    Code:
    $ git bisect skip
    ?

  5. #15
    Join Date
    Feb 2008
    Location
    USA
    Posts
    192

    Default

    Quote Originally Posted by djtm View Post
    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.

  6. #16
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    Quote Originally Posted by Michael View Post
    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...
    Last edited by V!NCENT; 06-09-2011 at 02:39 PM.

  7. #17
    Join Date
    Feb 2008
    Location
    USA
    Posts
    192

    Default

    Quote Originally Posted by V!NCENT View Post
    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

  8. #18

    Default Here's a thought.

    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

  9. #19
    Join Date
    Jun 2011
    Posts
    3

    Default Have a thinkpad? Might be easier to do everything...

    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:
    Code:
     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:
    Code:
     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
    Code:
     git bisect skip
    you could avoid the non-working kernel versions as well.

    So guys, what do you think?

  10. #20
    Join Date
    Jun 2011
    Posts
    1

    Default

    Quote Originally Posted by zoomblab View Post
    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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •