Announcement

Collapse
No announcement yet.

Linux 3.1 Kernel Draws More Power With Another Regression

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

  • Linux 3.1 Kernel Draws More Power With Another Regression

    Phoronix: Linux 3.1 Kernel Draws More Power With Another Regression

    If you were hoping that the Linux 3.1 kernel would fix the big power regression problem that's caused by PCI Express Active State Power Management (ASPM) being disabled on more systems since the release of the Linux 2.6.38 kernel, you're not in luck. There has not been any active work in this area. Making things worse though for mobile Linux users interested in a long lasting battery is another new regression in the Linux 3.1 kernel. Affected systems can easily see a 30% increase in power consumption simply when comparing the Linux 3.0 kernel to the current code being assembled for Linux 3.1. For an Intel Sandy Bridge notebook, the power consumption is up by 76% just over the course of this year from Linux kernel regressions.

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Luckily the power regression on sandybridge hardware can be worked around easily by adding i915.i915_enable_rc6=1 to the kernel command line.
    See bug report for fedora 15: https://bugzilla.redhat.com/show_bug.cgi?id=727579

    Comment


    • #3
      Any chance of bisecting these bugs using PTS?

      Comment


      • #4
        Originally posted by Welsh Dwarf View Post
        Any chance of bisecting these bugs using PTS?
        Yes, probably he will do that. But why some of biggest Linux players don't do that. IBM, Google, RedHat? Where are you?

        Comment


        • #5
          Arg

          I sometimes wonder what the guys in charge of the kernel think. Do they think that battery powered devices are such a small segment of the market that they shouldn't bother with critical bug issues involving power consumption? ARRggggg. It is sad that I'm having to use windows when I'm on the go because of battery life under Linux is shrinking.

          Comment


          • #6
            Michael runs tests on a per commit basis so he should already know exactly which commit caused the issue...

            Comment


            • #7
              Graphics card regression

              On Sandy Bridge, the regression in the 3.0 kernel is probably caused by the graphics card. If you add i915.i915_enable_rc6=1 to the boot kernel options the power consumption goes back to previous levels. At least it is the case for my SB laptop. This whole thing is caused by this commit. http://git.kernel.org/?p=linux/kerne...2b3272f5ac7caa
              Last edited by Med_; 22 August 2011, 10:20 AM. Reason: adding this is about 3.0, not 3.1

              Comment


              • #8
                Originally posted by ua=42 View Post
                I sometimes wonder what the guys in charge of the kernel think. Do they think that battery powered devices are such a small segment of the market that they shouldn't bother with critical bug issues involving power consumption? ARRggggg. It is sad that I'm having to use windows when I'm on the go because of battery life under Linux is shrinking.
                I expect it's got more to do with testing. This article clearly shows the new kernels don't increase power consumption on all platforms.

                Q1: did the work-load increase (e.g. higher frames per second) with the updates? The graphics driver seems an obvious candidate for the effect since it's changed considerably lately.
                Q2: Which systems exactly are affected? I'm pretty sure the ASPM thing Michael keeps talking about doesn't affect all laptops, unfortunately he doesn't have enough machines to test all common platforms. I wonder if openbenchmarking.org could be extended into a volunteer testing platform (like BOINC, but for testing)?

                Comment


                • #9
                  Originally posted by FireBurn View Post
                  Michael runs tests on a per commit basis so he should already know exactly which commit caused the issue...
                  I believe he tested latest Linux 3.1 RC and found the regression, he didn't check every commit between Linux 3.0 and 3.1. I also believe he will bisect it now, although the kernel developers should do that.

                  Comment


                  • #10
                    Originally posted by Fazer View Post
                    I believe he tested latest Linux 3.1 RC and found the regression, he didn't check every commit between Linux 3.0 and 3.1. I also believe he will bisect it now, although the kernel developers should do that.
                    I'm sorry but the kernel developers do their own testing, if you find a bug and report it they will usually request you bi-sect it. It's a relatively easy process, saves the developer time (that won't be the only bug in their queue) and pin point the commit on your machine which is exhibiting the problem - it could be hardware or bios specific rather than a problem that affects everyone

                    Michael generates revenue from these articles, he makes a living from the opensource ecosystem, reporting these issues really aught to be his way of "paying back" the community.

                    I've reported quite a few problems in the past, both in the kernel and in user space. Git-bisect is a great tool for users to help developers fix issues. If you can't code or submit patches then it's one of the easiest ways to give back to the community

                    Oh dear now I sound like I'm ranting - oh well...

                    Comment

                    Working...
                    X