Announcement

Collapse
No announcement yet.

The Linux Kernel Power Issues Continues To Bite Users

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

  • #11
    Originally posted by ioannis View Post
    Michael,

    Do you have any results on older kernels, like 2.6.24 for instance. This was the kernel on Hardy Haron 8.04 and also the one used by WebOS until now (recently switched to 2.6.29).

    Why? Just curious
    http://www.phoronix.com/vr.php?view=15943 plus more coming...
    Michael Larabel
    https://www.michaellarabel.com/

    Comment


    • #12
      Originally posted by johnc View Post
      Is this bug eventually going to find its way into Android smartphones and tablets or is the kernel over there so far branched off the main path that it'd be unlikely to pick up this problem?
      Android is still using 2.6.32 as far as I'm aware. 2.6.32 has a special place in a lot of big business' hearts. It just so happens that basically all the big players in the Linux ecosystem have at least one high-dollar product that is sitting on 2.6.32 with no sign of moving:

      RHEL: 2.6.32 (with a few sensible backports from 2.6.37)
      Ubuntu 10.04 LTS: 2.6.32
      Android 2.2/2.3: 2.6.32 (plus a tremendous amount of Android-specific work)
      Debian Stable: 2.6.32
      SUSE Enterprise 11 SP1: 2.6.32
      MeeGo: OK, they're using 2.6.37 in their git repo, but that doesn't mean 2.6.32 won't get picked up for product releases...


      Since 2.6.32 preceded this power regression, I don't think the big enterprise customers really care at this point. Sure, it affects the enthusiast distros like Fedora, but the money making product (RHEL) isn't affected. Same with Android. You can go to a Verizon or AT&T store today and buy a top of the line Android phone, and it'll be running a heavily hacked 2.6.32.

      Honestly, I'm more worried that we might start to see a very significant divergence in the kernel development community. The enterprise / embedded guys might decide they want to stick with 2.6.32 indefinitely, and just keep patching it until it looks nothing like vanilla 2.6.32, and is completely unmergeable between their fork and upstream. There's definitely a large enough pool of developers chasing money-making products built off of 2.6.32, and we are starting to see a decline in significant contributions to kernel upstream.

      Ever wonder why Linus keeps enjoying an "uneventful RC"? I want them to be eventful. Submit huge patches! Contribute big features! We want them! But sadly, it isn't happening lately. Even the merges during the merge window are becoming more and more conservative.

      Comment


      • #13
        Originally posted by Michael View Post
        Thanks Michael!

        Comment


        • #14
          @Michael
          Have you found both of the regressions, then, or just one of them?
          Also, will the fix be something that could be tacked into Linux 3.0, or is it large enough we'll probably have to wait for 3.1?

          Comment


          • #15
            /me guesses kms output polling or intel idle driver ;-)

            though hopefully its something less complicated like VFS lookups or cgroups.

            Comment


            • #16
              Originally posted by allquixotic View Post
              Honestly, I'm more worried that we might start to see a very significant divergence in the kernel development community. The enterprise / embedded guys might decide they want to stick with 2.6.32 indefinitely, and just keep patching it until it looks nothing like vanilla 2.6.32, and is completely unmergeable between their fork and upstream. There's definitely a large enough pool of developers chasing money-making products built off of 2.6.32, and we are starting to see a decline in significant contributions to kernel upstream.
              Honestly, I haven't noticed any of that. Stable distros have always been lagging behind. They currently use 2.6.32 because that was the most stable version during the time they started stabilizing for release.

              IF I remember correctly:

              Debian 5 uses 2.6.26 (also 2.6.31 was made available optionally)
              Debian 6 uses 2.6.32
              Next Debian will apparently use 2.6.38 (the version currently in testing)

              OpenWRT-git recently switched to 2.6.37 from 2.6.32

              Nobody knows what Google does, but at least the normal distros will switch to 2.6.37+ soon.

              Comment


              • #17
                It must be Linus's bitcoin maker.

                Comment


                • #18
                  Thanks for your work on this Michael.

                  Comment


                  • #19
                    Android 2.2 uses 2.6.32. Android 2.3 uses 2.6.35. Some custom kernels for AOSP ROMs are as new as 2.6.38, however. I am using a 2.6.38 kernel on my Droid Incredible, and its battery life is better than it was with 2.6.37, and many other users have said the same thing. Perhaps the battery life issue does not affect ARM?

                    Comment


                    • #20
                      Originally posted by dotancohen View Post
                      ... another 0.01% out of a server benchmark at the sacrifice of a large chunk of desktop usability. This issue is a perfect example.
                      Isn't power consumption also very important for servers? Should save companies big moneys by saving some wattage here and there in all their servers / farms

                      Comment

                      Working...
                      X