Announcement

Collapse
No announcement yet.

Linux Kernel Power Consumption Is Lowered, But Regressions Remain

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

  • #16
    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.

    Comment


    • #17
      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

      Comment


      • #18
        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

        Comment


        • #19
          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?

          Comment


          • #20
            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.

            Comment


            • #21
              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.

              Comment

              Working...
              X