Announcement

Collapse
No announcement yet.

Linux 3.1 Kernel Draws More Power With Another Regression

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

  • lgstoian
    replied
    Really another power regresion. The kernel is just sucking in more and more power with each release and noone seems to do anything about it. I got a new netmook that came with Windows 7 and the reason im sticking with the os is battery life. I get a hole extra hour. At this rate I'll have a better power consumption under Haiku Os.

    Leave a comment:


  • saski
    replied
    confirmed, i915_enable_rc6=1 reduces power drain about 30%.
    unfortunately i915_enable_rc6=1 causes the gpu to hang pretty often and to lock up the system entirely as soon as multiple OpenGL or vaapi apps are running

    Leave a comment:


  • ryszardzonk
    replied
    good thing there is linux-phc to help out with the situation

    If anyone is interested I curently use below values for AMD E-350 on E35M1-M Pro motherboard

    echo "26 28 51" > /sys/devices/system/cpu/cpu0/cpufreq/phc_vids

    over there defaults

    echo "20 21 42" > /sys/devices/system/cpu/cpu0/cpufreq/phc_vids

    Leave a comment:


  • Cyborg16
    replied
    Originally posted by anbog View Post
    That would be cool. I have an old Pentium M / Radeon Mobility X1300 laptop that I wouldn't mind dedicating to that! Even if it wasn't completely automatic, like getting a mail with instructions and script(s). Is anything like that in the plans Michael?
    There's a problem there: many (most?) people are interested in what happens on newer systems. But if the instructions are as simple as "download this ISO, burn to CD, and run overnight when you're not using the machine," then I for one would be willing to help out.

    A dedicated testing installation/live-CD is essential to avoid users' software tweaks having an effect, so automated testing would only be possible with dedicated machines (which I doubt many people would be willing to provide).

    Leave a comment:


  • bulletxt
    replied
    This is starting to be very serious now.

    Michael, thanks for sharing your discoveries in this area.

    Leave a comment:


  • anbog
    replied
    Originally posted by Cyborg16 View Post
    I wonder if openbenchmarking.org could be extended into a volunteer testing platform (like BOINC, but for testing)?
    That would be cool. I have an old Pentium M / Radeon Mobility X1300 laptop that I wouldn't mind dedicating to that! Even if it wasn't completely automatic, like getting a mail with instructions and script(s). Is anything like that in the plans Michael?

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


  • Cyborg16
    replied
    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)?

    Leave a comment:


  • Med_
    replied
    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, 10:20 AM. Reason: adding this is about 3.0, not 3.1

    Leave a comment:

Working...
X