Announcement

Collapse
No announcement yet.

The Big Linux 2.6.35 Kernel Problem Is Fixed

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

  • The Big Linux 2.6.35 Kernel Problem Is Fixed

    Phoronix: The Big Linux 2.6.35 Kernel Problem Is Fixed

    Last week we reported on a disastrous bug within the Linux 2.6.35 kernel that while this kernel is still months from being officially released, a major regression was introduced that slaughtered the Linux system's performance. This was experienced across multiple systems, architectures, and file-systems. Today we can officially report that this problem has been resolved...

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

  • #2
    "To us at least, it still is a real problem that such a regression can be introduced in the mainline kernel and live there for a number of days without being addressed -- especially when it negatively affects the operating system's performance in so many different areas."

    Well, I strongly disagree. It's not a "problem" that such regressions can be introduced. Of course, it's a bug that must be solved, but there is nothing strange or atypical with finding such bugs in a pre-rc1 git snapshot. That's why -rcx releases exist. That's why there are three months of kernel development. To find such bugs. So there is nothing "unexpected" here, a bug was found (which, BTW, is far from being a critical bug), and it was fixed. Big deal.

    In fact, if you _really_ follow the kernel development (which phoronix editors don't seem to do), there are always several reverts of commits that introduce bugs that are detected in -rc releases. If you need a tree that merges bug fixes immediately then the Linus tree is not for you, because Linus may take a week off to go to some conference or because of holidays or things like that. It's also not strange that an important fix may get delayed just because people is discussing how it must be fixed. At this stage, you are expected to report bugs, test and apply the corresponding bugfix patches yourself.

    In other words. Can Phoronix stop doing ridiculous claims the next time? You _will_ find performance regressions and bugs in 2.6.26-pre-rc1 if you search them, and in 2.6.27-pre-rc1, and in 2.6.28-pre-rc1. It's a good thing if you want to become a kernel tester, but they aren't interesting news.

    Comment


    • #3
      Don't see how you can't complain about that, since was intended for testing so there is room for other priorities. Yet, that could be a major problem if we're talking about a stable release - and in that situation a fix would be 1'st priority, are wouldn't be marked as stable in the 1'st place.

      Comment


      • #4
        Hmm

        The kernel was not even in RC state and you already cried out for a "2.6.35 desaster". No wonder the kernel guys reacted the way they did, and in fact Ingo Molnar summed the situation up quite good.

        - Clemens

        Comment


        • #5
          Originally posted by diegocg View Post
          In other words. Can Phoronix stop doing ridiculous claims the next time? You _will_ find performance regressions and bugs in 2.6.26-pre-rc1 if you search them, and in 2.6.27-pre-rc1, and in 2.6.28-pre-rc1. It's a good thing if you want to become a kernel tester, but they aren't interesting news.
          I can't agree more.

          Comment


          • #6
            FUD

            This seems like another case just like the VIA article last week where Phoronix does it's best to spread FUD.

            Comment


            • #7
              Linus actually discourages people paying too much attention to his branch if you listen to his Git talk on youtube. Linus' branch shouldn't be considered somehow the most "official" one and therefore always bug free all the time. That's too much for one developer to handle.

              Comment


              • #8
                These sensationalist, self-advertising, paparazzi-style articles have backfired and are giving Phoronix a bad reputation among developers and informed users. Keep that up and no one will be paying attention to anything said here.

                My two cents.

                Comment


                • #9
                  Add "self-glorifying" to the list.

                  Comment


                  • #10
                    this article already has come to first "fruition":

                    the evilness that is 2.6.35...

                    so STOP THE FUD please

                    IBM, Oracle, Intel, Red Hat and several other big players DO HAVE testing rigs - and that's for sure

                    after the regression wouldn't have been found until 2.6.35-rc2 you guys could have written the article but NOT in the transition phase

                    Comment


                    • #11
                      Here's a tip Michael, try running the PTS on older kernels (I'm talking 2.6.0, 2.6.5, etc..) and see if there are any regressions that came unnoticed.
                      Would also be an interesting read to see how the kernel has matured, whether they are adding stuff at the cost of performance or the performance keeps improving too(or at least not degrading as much).

                      Comment


                      • #12
                        I'm getting sick of people complaining about Michael's work.
                        They really don't realize how is work somehow contributes to the Linux world.

                        I'm sure though that the Linux Kernel developers appreciate his work, and that's the only thing that matters.

                        Comment


                        • #13
                          Originally posted by bulletxt View Post
                          I'm getting sick of people complaining about Michael's work.
                          They really don't realize how is work somehow contributes to the Linux world.

                          I'm sure though that the Linux Kernel developers appreciate his work, and that's the only thing that matters.
                          Amen. Michael's work is a great service to the kernel devs as it highlights issues that negatively impact the kernel long before it goes live

                          Comment


                          • #14
                            Just Don't Claim the Sky Is Falling

                            Originally posted by DeepDayze View Post
                            Amen. Michael's work is a great service to the kernel devs as it highlights issues that negatively impact the kernel long before it goes live
                            Michael's work is fine. Highlighting issues that negatively impact the kernel before it goes live is great. Claiming that the sky is falling when such issues pop up in a pre-release seems a bit silly. Issues like this at alpha/beta stages are par for the course. Point them out in a matter of fact manner and nobody will call you out for it; the issues will just get fixed.

                            Comment


                            • #15
                              Originally posted by diegocg View Post
                              "To us at least, it still is a real problem that such a regression can be introduced in the mainline kernel and live there for a number of days without being addressed -- especially when it negatively affects the operating system's performance in so many different areas."

                              Well, I strongly disagree. It's not a "problem" that such regressions can be introduced. Of course, it's a bug that must be solved, but there is nothing strange or atypical with finding such bugs in a pre-rc1 git snapshot. That's why -rcx releases exist. That's why there are three months of kernel development. To find such bugs. So there is nothing "unexpected" here, a bug was found (which, BTW, is far from being a critical bug), and it was fixed. Big deal.

                              In fact, if you _really_ follow the kernel development (which phoronix editors don't seem to do), there are always several reverts of commits that introduce bugs that are detected in -rc releases. If you need a tree that merges bug fixes immediately then the Linus tree is not for you, because Linus may take a week off to go to some conference or because of holidays or things like that. It's also not strange that an important fix may get delayed just because people is discussing how it must be fixed. At this stage, you are expected to report bugs, test and apply the corresponding bugfix patches yourself.

                              In other words. Can Phoronix stop doing ridiculous claims the next time? You _will_ find performance regressions and bugs in 2.6.26-pre-rc1 if you search them, and in 2.6.27-pre-rc1, and in 2.6.28-pre-rc1. It's a good thing if you want to become a kernel tester, but they aren't interesting news.
                              to make matter worse, Phoronix didn't care to report the bug. It was fixed because OTHER people found and reported it. Really, Phoronix failed hard and blames devs for a bug that didn't even survived -rc1. That is low.

                              Comment

                              Working...
                              X