Page 3 of 19 FirstFirst 1234513 ... LastLast
Results 21 to 30 of 185

Thread: The Huge Disaster Within The Linux 2.6.35 Kernel

  1. #21
    Join Date
    Jan 2010
    Location
    Transylvania
    Posts
    2

    Default

    Maybe Phoronix should work together with the kernel folks to test kernels and avoid such problems.

  2. #22
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    258

    Default

    This site is turning into a load of crap.

  3. #23
    Join Date
    Mar 2008
    Posts
    570

    Default

    Instead Michael is doing a great job. It's not his duty to say what's causing the regression. That's something the kernel developers must know. What he did is let people know that between may 20 and 26 the kernel git regressed in an impressive way.

    You guys pretend too much. Michael did his job, and for sure if this regression doesn't get fixed i'm not moving towards future kernels if things don't change, and you know what? I must say thanks to Michael.

    His work isn't crap for me.

  4. #24
    Join Date
    May 2008
    Posts
    41

    Default

    Michael's work isn't crap. But it could be improved.
    For instance, you don't name that a "huge disaster". There's nothing like a "disaster" in a regression before the release, so what to say when it is even before the first release candidate?

    Regression happens!

  5. #25
    Join Date
    Jun 2006
    Posts
    351

    Default

    the key is in the text:
    As we have already shown before, using the Phoronix Test Suite and its components we can also narrow down to the individual commit(s) that introduced these serious performance issues by layering the Phoronix Test Suite's automated support atop the git-bisect command to automatically traverse the tree and perform tests at each step of the process. We may do so again in this instance -- time or incentive permitting -- to track down this newest problem.
    ...
    We are also more than happy to work with the Linux kernel community or any other software project in establishing more robust test procedures and greater test coverage. We will work with other vendors too, via our commercial entity


    Don't forget that Phoronix Test Suite - is a business.

  6. #26
    Join Date
    Mar 2009
    Posts
    141

    Default

    Quote Originally Posted by bulletxt View Post
    Instead Michael is doing a great job. It's not his duty to say what's causing the regression. That's something the kernel developers must know. What he did is let people know that between may 20 and 26 the kernel git regressed in an impressive way.

    You guys pretend too much. Michael did his job, and for sure if this regression doesn't get fixed i'm not moving towards future kernels if things don't change, and you know what? I must say thanks to Michael.

    His work isn't crap for me.
    Right but the language of calling it a disaster implies that this is unexpected for the early merging process when that isn't actually the case. It's not like someone wasn't doing their job properly which caused a regression. I've little doubt this will be sorted out well before 2.6.35 goes gold unless the regressions were caused by some necessary change (as was the case for EXT4).

  7. #27
    Join Date
    Jul 2008
    Location
    Wrocław/Poland
    Posts
    37

    Thumbs up

    I highly respect Michael's efforts to detect kernel performance issue as early as possible. Keep it up, great work!

  8. #28
    Join Date
    Nov 2009
    Posts
    328

    Default

    @bulletxt write "The Huge Disaster Within The Linux 2.6.35 Kernel" when the kernel is in a very alpha stage isn't fair. Maybe in rc8 or final 2.6.35 would be fine but not now.

    I don't like the quality of this article too, too dramatic, as if not solution exists, I would find it more useful if only points that a regression was found, showing benchmark charts and pointing the bad commit.

    @Creak I agree, a lot of articles seem to be based only on looking at git development tree of some projects (mesa, kernel...), then write a little description of latest changes, based on commits titles. There is not a deep understanding or explanation of how the things works. I think it is not Michael fault and perhaps phoronix lacks of man power to write more decent quality articles.

  9. #29
    Join Date
    Dec 2008
    Posts
    983

    Default

    Quote Originally Posted by bulletxt View Post
    Instead Michael is doing a great job. It's not his duty to say what's causing the regression. That's something the kernel developers must know. What he did is let people know that between may 20 and 26 the kernel git regressed in an impressive way.
    Funny. I always thought that the proper way was to first let the people involved know about it (i.e. filing a bug report) I didn't see anything about that in the lengthy article. Bugs and regressions are part of every large software project. No need to make such drama about it, unless there's unwillingness to fix.

  10. #30
    Join Date
    Mar 2008
    Posts
    570

    Default

    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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •