Announcement

Collapse
No announcement yet.

Linux Kernel Power Consumption Is Lowered, But Regressions Remain

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

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

    Comment


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

      Comment


      • #13
        Originally posted by Qaridarium
        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
        ?

        Comment


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



          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.

          Comment


          • #15
            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; 09 June 2011, 02:39 PM.

            Comment


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


              Comment


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


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


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


                    • #20
                      Tom's confirms the issue:
                      Ubuntu 11.04 (Natty Narwhal) has arrived, and we have the scoop on everything you need to know about Canonical's latest Linux, along with the usual review and benchmarks. Is this the change we've been waiting for, or is the Natty Narwhal a fail whale?


                      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