Announcement

Collapse
No announcement yet.

Another Major Linux Power Regression Spotted

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

  • Another Major Linux Power Regression Spotted

    Phoronix: Another Major Linux Power Regression Spotted

    Since Friday there's been a number of Phoronix articles about a very bad power regression in the mainline Linux kernel, which is widespread, Ubuntu 11.04 is one of the affected distributions, and has been deemed a bug of high importance. This yet-to-be-resolved issue is affected Linux 2.6.38 and 2.6.39 kernels and for many desktop and notebook systems is causing a 10~30% increase in power consumption. Nevertheless, this is not the only major outstanding power regression in the mainline tree, there is another dramatic regression now spotted as well that is yet-to-be-fixed.

    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
    Any word on AMD processors?

    And would that be a Dunkles Wei?bier?

    Comment


    • #3
      Jees, the difference between 2.6.28 and 2.6.38 could easily mean an extra hour or two battery power. We are indeed going backwards.

      Comment


      • #4
        Originally posted by FunkyRider View Post
        Jees, the difference between 2.6.28 and 2.6.38 could easily mean an extra hour or two battery power. We are indeed going backwards.
        But performance, flexibility and features are going up at the same time. Hmmm.

        Sounds like we need to option-out the stuff that sucks power the most, and maybe over time we'll have a linux-lowpower package in Ubuntu.

        Normally, using more power, to the extent that it's correlated with increased performance, is a "good thing" for servers and other computers running on A/C power. This usually means that you are seeing increased utilization of your hardware. A very hot chip is a busy chip, and if you get corresponding performance increases, that just confirms that you're getting what you paid for.

        But I don't think we need to have any kind of stand-off between those who want performance (energy be damned) and those who want to get 8+ hours of battery life on a ThinkPad X-Series. Instead, we should just isolate those particular things that are most pivotal in determining the power consumption, and then: if they are performance-enhancing things, we should keep them (generally speaking), but provide an option to disable them, ideally at runtime, for power savings. But if it turns out that we're surrendering energy consumption without any performance benefit, that's bad for everyone, so that needs to be fixed, of course.

        Simple non-kernel example: if you're running a composited desktop, it's going to use way more energy than a non-composited desktop, because not only will the display output be awake all the time, but the GPU will always be awake, processing the frames of the composited pipeline. On most laptops with a discrete GPU, keeping this beast awake constantly is a huge drain on battery life. With a pure 2D environment, you use less energy because the GPU (if you even have one) can go to sleep since it has no OpenGL contexts open against it. You just rasterize off the CPU and go to sleep. And since we usually expect much less (in terms of rendering complexity) from a rasterized scene, we significantly save on the number of computations overall, so of course we'll use less power!

        But does that mean we should get rid of composited desktops? No -- because they provide much-desired features and eye candy, and (sometimes) increased performance on certain drivers/workloads. They do consume more power, and the computations that go into compositing are more complex than rastering a simple desktop, but we think the cost is worth it. Or at least, we think the cost is worth providing the user with the option of running with or without a compositor, rather than just going one way.

        Recognizing the pivot points in the kernel that most dramatically affect power usage will help the kernel more closely resemble the desktop in terms of allowing users to trade off performance/features and power. We just have to make sure that, at each pivot, that we're actually getting some kind of benefit from it -- otherwise it's a bug and should be fixed, no option needed.

        Comment


        • #5
          Normally, using more power, to the extent that it's correlated with increased performance, is a "good thing" for servers and other computers running on A/C power...
          Most probably this is not the case here, we are under a regression that affects power consumption. If there is power consumption increase is because your computer resources are used more frequently, unnecessarily, so there is less resources for user applications.

          My opinion here is that correctly solving those regressions will give a "little" more performance to user applications.

          Comment


          • #6
            Are we absolutely sure this is a kernel bug and it isn't a piece of user space that's not talking to the kernel properly like udev or the like

            I compile my own minimal kernels (about 2MB) with everything I don't use switched of and everything I do use compiled in (rather than compiled as a module)

            I'm tempted to see if I'm as effected by this bug on my laptop as everyone else

            Comment


            • #7
              Is it possible to search for this regression at home with pts?
              Can't we just upload the tests to openbenchmarking.org and see which distributions and kernel configurations are affected?

              Comment


              • #8
                Those facts shows us that Phoronix Test Suite is very useful thing and that it's vital for good development. I think this tool should be developed further and maintained cause it is everybody's interest.

                Comment


                • #9
                  Originally posted by FireBurn View Post
                  Are we absolutely sure this is a kernel bug and it isn't a piece of user space that's not talking to the kernel properly like udev or the like

                  I compile my own minimal kernels (about 2MB) with everything I don't use switched of and everything I do use compiled in (rather than compiled as a module)

                  I'm tempted to see if I'm as effected by this bug on my laptop as everyone else
                  Since it was reproduced on the 8.04 userspace which is now 3 years old the answer is no. And if it's a piece of userspace that "isn't talking to the kernel properly" then that points to a kernel bug since the new kernel broke the old userspace code.

                  Comment


                  • #10
                    Originally posted by DeiF View Post
                    Is it possible to search for this regression at home with pts?
                    Can't we just upload the tests to openbenchmarking.org and see which distributions and kernel configurations are affected?
                    Normally, yes, but for this power testing there's lots of uncommitted code as of right now. I don't think I'll have the improvements merged in the public repository this week, unfortunately, since I have to leave on Thursday and have lots of work to still take care of prior to that.
                    Michael Larabel
                    https://www.michaellarabel.com/

                    Comment

                    Working...
                    X