Page 1 of 6 123 ... LastLast
Results 1 to 10 of 55

Thread: Linux 3.1 Kernel Draws More Power With Another Regression

  1. #1
    Join Date
    Jan 2007
    Posts
    15,438

    Default 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.

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

  2. #2
    Join Date
    Aug 2011
    Posts
    2

    Default

    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

  3. #3
    Join Date
    Feb 2011
    Posts
    55

    Default

    Any chance of bisecting these bugs using PTS?

  4. #4
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    540

    Default

    Quote 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?

  5. #5
    Join Date
    Jan 2010
    Location
    Somewhere in Kansas.
    Posts
    291

    Unhappy 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.

  6. #6
    Join Date
    Dec 2007
    Location
    Edinburgh, Scotland
    Posts
    593

    Default

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

  7. #7
    Join Date
    Aug 2008
    Posts
    22

    Default 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_; 08-22-2011 at 11:20 AM. Reason: adding this is about 3.0, not 3.1

  8. #8
    Join Date
    Jul 2009
    Posts
    221

    Default

    Quote 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)?

  9. #9
    Join Date
    Dec 2009
    Posts
    28

    Default

    Quote 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.

  10. #10
    Join Date
    Dec 2007
    Location
    Edinburgh, Scotland
    Posts
    593

    Default

    Quote 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...

Posting Permissions

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