Announcement

Collapse
No announcement yet.

Linux Kernel Power Consumption Is Lowered, But Regressions Remain

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Linux Kernel Power Consumption Is Lowered, But Regressions Remain

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

    As discovered by a Phoronix reader, there is a patch in the Linux 2.6.39.1 kernel that can partially improve the system's power performance. The patch by a Nokia engineer is entitled "cpuidle: menu: fixed wrapping timers at 4.294 seconds" and initial reports have said that it will lower the power consumption compared to the stock 2.6.39 kernel.

    http://www.phoronix.com/vr.php?view=16104

  • curaga
    replied
    Tom's confirms the issue:
    http://www.tomshardware.com/reviews/...l,2943-13.html

    Several weeks ago, Michael Larabel of Phoronix reported that Ubuntu 11.04 suffers serious battery life regressions from previous versions of the distribution. His findings were originally specific to the kernel, and he received a lot of feedback on Slashdot and other forums asking whether or not this would manifest in real-world usage.


    We not only confirm his findings, but also demonstrate that this issue has very significant implications in actual use. It also appears that the Unity interface is not the root cause. In fact, Ubuntu 11.04 with Unity gets more than 20 minutes additional battery life than Ubuntu 11.04 Classic. The previous release, Ubuntu 10.10 Maverick Meerkat gets over two hours more battery life than Natty Narwhal, regardless of the user interface. This was probably the main deciding factor for Asus when it recently chose to ship Ubuntu 10.10 Maverick Meerkat as opposed to 11.04 Natty Narwhal on the new Eee netbooks


    Mobile users are urged to seriously consider these results, and possibly even avoid the Natty Narwhal. On the other hand, Lucid has serious issues with hibernation, as does Maverick, making this a difficult choice for road warriors. I hate to say it, especially in an Ubuntu review, but the mobile edge goes to Windows for now.

    Leave a comment:


  • spiff
    replied
    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.

    Leave a comment:


  • gns-ank
    replied
    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?

    Leave a comment:


  • Uncle Warthog
    replied
    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

    Leave a comment:


  • Jimmy
    replied
    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

    Leave a comment:


  • V!NCENT
    replied
    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, 02:39 PM.

    Leave a comment:


  • Jimmy
    replied
    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.

    Leave a comment:


  • Jimmy
    replied
    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
    ?

    Leave a comment:


  • djtm
    replied
    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.

    Leave a comment:

Working...
X