Announcement

Collapse
No announcement yet.

The Huge Disaster Within The Linux 2.6.35 Kernel

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

  • The Huge Disaster Within The Linux 2.6.35 Kernel

    Phoronix: The Huge Disaster Within The Linux 2.6.35 Kernel

    For the past six months we have been monitoring the performance of the very latest Linux kernel code on a daily basis across multiple systems. We have spotted a few regressions -- both positive and negative -- on occasion using our automated daily testing of the Linux kernel, but nothing like what we have encountered the past few days: the Linux 2.6.35 kernel performance has fallen hard. In fact, the performance has fallen very hard in a number of tests and right now, we would consider it a disaster. While the 2.6.35 code has not even seen its first release candidate yet, there are some massive performance drops in a variety of different tests that have yet to be corrected and nothing like we have encountered with previous kernel release cycles especially for a regression that has lived now for about one week.

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

  • #2
    very curious what caused it- anybody know specifically?

    Comment


    • #3
      Did I ever post my code for determining whether it was CPU or I/O bound? I'm in the middle of another project at the moment, but meanwhile, here's the algorithm:

      http://borasky-research.net/2010/02/...neck-analysis/

      Comment


      • #4
        you know, i thought that the purpose of kernel regression tracker was not to make 5 pages of graphs and drama but pinpoint the offending commits.

        Comment


        • #5
          It's almost certainly not io bound, given some of those benchmarks. That's what makes it a lot more interesting than some of the previous "regressions" Phoronix has reported on that were just safer defaults on the file system.

          If this was my own software, I'd be looking for a new lock somewhere that's coming under a lot of contention and starving the other running threads, but I suppose with a kernel it could be just about anything.

          I agree that this article would have been a lot better if Michael just ran the git bisect and at least narrowed it down a little. It sounds like he's had plenty of time to look into it. That line near the end of the article almost sounds like he's fishing for money from someone to pay him to do it.

          Comment


          • #6
            Originally posted by smitty3268 View Post
            I agree that this article would have been a lot better if Michael just ran the git bisect and at least narrowed it down a little. It sounds like he's had plenty of time to look into it.
            I suspect he wants to stretch this out into 4 or 5 articles. He can't do that if he figures it all out ahead of time.

            Seriously, is the edit timeout thing never ever going to be fixed?

            Comment


            • #7
              We waited nearly a week to see if these regressions would be organically caught and addressed, but they have not been at least of the Linux 2.6 Git state as of 2010-05-26.
              What nonsense ...
              Seriously when you find bugs report them and not just wait and assume that they get magically fixed.

              Comment


              • #8
                OMG what drama

                this is a .35-rc1 kernel for crying out loud!

                beside that, the quality of articles here on phoronix has been nose diving for a while now. I'm even beginning to get annoyed.

                Michael, you have to do better and you can because it was good in the beginning. Articles like this are total crap and do you and your site no service at all

                Comment


                • #9
                  Originally posted by drago01 View Post
                  What nonsense ...
                  Seriously when you find bugs report them and not just wait and assume that they get magically fixed.
                  Exactly. I'm getting sick of these articles boasting "we've found a problem, but we've kept it a secret".

                  Michael, have you contacted Linus? Have you reported it as a bug? Phoronix would get a lot more credit if the articles were more like: "We found a regression and it's already fixed in Linus' tree thanks to Phoronix".

                  Comment


                  • #10
                    http://lkml.org/lkml/2010/5/22/150

                    Comment


                    • #11
                      Originally posted by Kazade View Post
                      Phoronix would get a lot more credit if the articles were more like: "We found a regression and it's already fixed in Linus' tree thanks to Phoronix".
                      That would be more like ego tripping "Hey look at us we are so fscking awesome! There was some issue, but it doesn't exist anymore because we fixed it!".

                      Should be more like "We reported this bug but it hasn't been fixed as of publishing this article".

                      But why do you guys even follow Phoronix if it isn't for staying up to date with development? I mean imagine you would like to test out the latest r600g with the latest kernel and found that the performance would be 50% less?

                      A kernel going skydiving from pretty good performance down to Windows levels in the earlier days is pretty much core news IMO.

                      Comment


                      • #12
                        it's inexplicable that a regression like this or change in behavior can even be accepted into the mainline Git tree at any point in the development cycle for such a mature project. That it can not only enter the kernel tree, but it can live for a week or more without either being corrected or the problematic commit being reverted. This is such a glaring performance issue across so many different tests and differently configured systems that it calls to question the current development practices and test procedures of the Linux kernel.
                        Says it all.

                        Comment


                        • #13
                          Why would you find a regression, keep it a secret for a week, then blog about it without reporting a bug upstream? This isn't even RC1 and the purpose of this phase is for testing. Regressions are expected.

                          Calling it a release candidate might be a bit inappropriate though. I consider the kernel RCs to be beta quality, not RC quality. RC usually implies previous beta testing which doesn't exist in the kernel release cycle.

                          Also doing a kernel bisect doesn't take that long. I've done it with zen-sources to track down some weird crashing problems.

                          Comment


                          • #14
                            Why hasn't anyone asked the obvious question yet?

                            "Have you tried running a 'git bisect' to find the first offending commit?"

                            Isn't this how everyone fixes their bugs these days ;-)?

                            Comment


                            • #15
                              Would you please stop testing PRE-RELEASE software, and then fussing about
                              "Huge Disaster" or something alike ?
                              The same did happen with the BETA NVidia driver.

                              I really like phoronix, as it provides lots of interesting articles. However this kind of news confuses me.

                              paravoid.

                              Comment

                              Working...
                              X