Announcement

Collapse
No announcement yet.

The Huge Disaster Within The Linux 2.6.35 Kernel

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

  • #31
    Looks like all tests use files and the test systems are configured to use BTRFS so I'm guessing this is a change in BTRFS performance.
    Perhaps it's simply a change in the default configuration?

    Comment


    • #32
      Agree with most of the commenters here. At least this piece is a change from the normal stream of articles bitching about X11 / mesa.

      Comment


      • #33
        Originally posted by bulletxt View Post
        You guys seem more afraid of Michael words rather than a real possible Linux kernel regression. I know it's not even an RC, but how many of you would put 100$ on a table saying that the regression will be fixed(if it actually can) by the final realease??
        I won't.
        I would. Now that the regression is known, thanks to Phoronix, I'm sure some developper is already tracking the source of the problem right now. And if not, I can still do the tracking (thanks to free software) just to win the bet

        Comment


        • #34
          It might have something to do with udev constantly respawning and using 100% cpu during the benchmarks for the past few days in upstream linux-2.6..

          Comment


          • #35
            Micheal, have you or have you not inform the kernel developers of this regression as soon as you discovered it?

            Comment


            • #36
              Originally posted by Creak View Post
              I've got to say I'm glad to see that I'm not the only one to be upset with this kind of drama articles.

              Honestly, showing a graph and just saying "it's better" or "it's worst" isn't journalism. For these kind of articles I expect to have some explanations. For example, I often hear about the mesa stack, but wtf is this stack? It seems to be almost as hard to understand as the sound stack in Linux!

              I also often read articles title like "DRI2 has improved", "Xinput2 is released", "yet another DRM problem", "new version of this", "new version of that"... But all of us aren't Linux gurus, it'd be great to simply _explain_ what all these technos are (isn't it the main purpose of journalism?)

              And finally, here is some kind of articles I'd like to see in Phoronix: https://www.linuxfr.org/2010/05/17/26852.html
              I'm sorry, it's in french, maybe you can google-translate it?
              patrick_g does this kind of articles at each kernel release. And even if I don't understand everything in Linux kernel, patrick_g explains RC by RC what are the improvements and what are the issues the developers had, he even interviews few developers to know how they got involved in the kernel or to explain what they have done in the kernel. It's important to say that despite the very good quality of patrick_g's articles, he doesn't know anything about coding.
              I totally agree with you. I love reading phoronix but I often get disappointed with the articles. It's not that I think it give us the right to rant or complain, but giving an honest and respectful opinion shouldn't hurt.
              I do agree the approach used in the articles isn't the right one... like you said it's drama inflated and most of the time lacks for introductory explanations. I had learn a lot with Phoronix, but not directly from it, but searching around trying to understand some of the things discussed here.

              The articles quality is ok, but it could be improved. For instance, in this article, using "concerning" instead of "huge disaster", pointing some extra information about the origin of the problem itself and showing that there was made some kind of effort to contribute to the fix besides just pointing it in your own site would definitely reduce the amount of rant in this topic.

              I think the key word here is tabloid. Phoronix seems to be going that way and personally, that's not how journalism should be done.

              Comment


              • #37
                Michael, good work!

                Comment


                • #38
                  Originally posted by bulletxt View Post
                  Ok it seems you guys got upset of his way of writing a drama article Yes he did that and it was exagerated. But i'm a Linux user, so what I care isn't about michael's drama | not drama. I care about Linux. If Michael shows that in 6 days the Linux kernel became a toilet performance, then I must think: "hey what the hell happened? that's not a small regression, that's a total mess!".

                  You guys seem more afraid of Michael words rather than a real possible Linux kernel regression. I know it's not even an RC, but how many of you would put 100$ on a table saying that the regression will be fixed(if it actually can) by the final realease??
                  I won't.
                  Bullshit! If one found a regression in a software, then everyone will happily accept patches or at least a proper bug report. This, instead, is just stupid complaining about experimental software not meant to be shipped to users at all!

                  Comment


                  • #39
                    Originally posted by paravoid View Post
                    Bullshit! If one found a regression in a software, then everyone will happily accept patches or at least a proper bug report.
                    That though wouldn't go towards addressing the fundamental problem that this article is about: how such a glaringly severe regression can be pulled into the tree in the first place and then live there for days. Improving the status quo is what this article is intended to be about more than this bug per se.
                    Michael Larabel
                    http://www.michaellarabel.com/

                    Comment


                    • #40
                      Originally posted by Michael View Post
                      That though wouldn't go towards addressing the fundamental problem that this article is about: how such a glaringly severe regression can be pulled into the tree in the first place and then live there for days. Improving the status quo is what this article is intended to be about more than this bug per se.
                      I really appreciate the work you do, but the ways of communication you elected are inappropriate (IMHO, of course). Publishing preliminary results and using harsh words like "huge disaster" makes people upset, and
                      sometimes confused

                      Why don't you just perform tests with release versions ? I.e. vanilla kernels and distro releases ? I am pretty sure, you will find regressions compared to precursor kernels ... *that* would be indeed interesting!

                      Comment


                      • #41
                        Originally posted by paravoid View Post
                        Bullshit! If one found a regression in a software, then everyone will happily accept patches or at least a proper bug report. This, instead, is just stupid complaining about experimental software not meant to be shipped to users at all!
                        People like you deserve to have a toilet kernel, and then I'de love to see you saying: "hey michael, you do 24/h benchmarks and didn't say anything to us!!!"

                        That's what all of you complaining of Michael's work deserve.

                        Comment


                        • #42
                          more relevant journalism, less "PTS will write this for me and i will trow in some generic text".

                          yes, PTS is great in acquiring test result, but author is the one that should interpret them and their causes and make them closer to wider audience.

                          quality over quantity FTW

                          P.S. titles like this one are definitely not necessary

                          Comment


                          • #43
                            Why not let people do what they are good in?

                            Michael's extensive benchmarks are important and needs to be done, but they are also very time consuming.
                            So what, now it's up to him to communicate with the developers / report bugs as well? That would also take up a lot of time, which means less benchmarking.

                            And even if he would report the bug and pinpoint the problem people will probably be complaining why he didn't fix it yet... Come on people it isn't a one man job...

                            All the info needed to create a bug report is here so almost any reader could do it. So why haven't YOU done it yet? (or me for that matter).


                            He could cut on the drama though. Specially the headers, but that probably gets him more hits, which i guess also mean more benchmarking in the end.


                            Keep up the great benchmarking Michael!

                            Comment


                            • #44
                              Really. This discussion is old.

                              http://kerneltrap.org/Linux/Active_Merge_Windows

                              This was discussed over and over.... I'm disappointed of this article.

                              The reasons for this?

                              Well. You're actually doing something that is in my opinion bashing - since the discussion I pointed out above, it is clear that the merge windows are not a time for testing. If everything builds, everyones happy. When the merge window has closed, the time for squashing bugs and eliminating the most troublesome stuff has come. And when that is finished, there is normally an rc... And when there is an rc, it is time to test for regression, and trying to find out what has gone wrong.

                              However. It is disappointing when someone simply bashes that something has gone wrong even before there was a rc (point 1), second point is very simple: Instead of questioning the development model and the work of the developer, use your shiny perfect software not for bashing, instead if u like benchmarking this lot, do it to aid the developers.

                              Comment


                              • #45
                                i agree with the sentiments that the language and title in the article should be toned down, because it certainly isn't a "huge disaster" and just sounds like sensationalism.

                                and it should be toned down because the real point of the article gets lost with the overdramatic language. the point is that it would be better to not have large regressions be able to enter the kernel _at all_. it'd be better to weed these out before they get committed, because even if they get fixed before the stable kernel release a) they will almost certainly take longer to fix and b) the fixes are more likely to be less effective than if designed properly in the first place. this seems like a valid point based on the evidence in the article.

                                Comment

                                Working...
                                X