All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Robert Hancock <hancockrwd@gmail.com>
Cc: alex.buell@munted.org.uk,
	Mailing Lists - Kernel Developers  <linux-kernel@vger.kernel.org>,
	Dave Airlie <airlied@gmail.com>
Subject: Re: Article in Phoronix about loss of performance in 2.6.35 release candidates
Date: Mon, 31 May 2010 23:15:04 -0400	[thread overview]
Message-ID: <4C047B38.9050506@tmr.com> (raw)
In-Reply-To: <4C0448B5.7090904@gmail.com>

Robert Hancock wrote:
> On 05/31/2010 05:19 PM, Alex Buell wrote:
>> http://www.phoronix.com/vr.php?view=14976
>>
>> Question: Why?
> 
> Good question.. I guess it would too much to ask of them to try to 
> figure out what area the problem lies in (even to the point of figuring 
> out if it's a CPU or IO-bound problem), or try to bisect, or at least 
> report it to LKML before going to the trouble of creating 5 pages of 
> graphs.. Given the 20x slowdown in some of the benchmarks you'd think it 
> wouldn't be too hard to narrow down.

That's true, but 20x should be too hard for people to detect when they do QA 
after creating a patch, before sending it to LKML in the first place, either. If 
such a regression made it to an -rc1 then it really is kind of a big deal. Of 
course Phoronics running the tests on netbook processors is probably a good 
thing, I doubt many developers and testers are compiling kernels on a rig like 
that, or doing much of anything else demanding.

I guess I would expect people to react with dismay to the fact that such a 
problem made it undetected to rc stage, but perhaps I have too much respect for 
developers. This looks more like "how dare they not keep it quiet and just tell 
us" indignation. In the end I doubt it makes a lot of difference, if someone 
posted to LKML and Slashdot picked it up, be sure it would have hit the media 
anyway.

Should any media keep a defect quiet when they make their living informing the 
readers? I see a lot of glee among Linux users every few days when a new Windows 
bug becomes public. Phoronics tested and reported, why is that less honorable 
than Tom's Hardware telling us a new CPU sucks?


-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

  parent reply	other threads:[~2010-06-01  3:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-31 23:19 Article in Phoronix about loss of performance in 2.6.35 release candidates Alex Buell
2010-05-31 23:39 ` Robert Hancock
2010-06-01  0:46   ` Alex Buell
2010-06-01  0:52     ` Dave Airlie
2010-06-01  3:15   ` Bill Davidsen [this message]
2010-06-01  3:22     ` Robert Hancock
2010-06-01  5:38       ` Mike Galbraith
2010-06-01  4:10 ` tytso
2010-06-01  5:00   ` Pekka Enberg
2010-06-01  6:17     ` Ingo Molnar
2010-06-01  6:25       ` Ingo Molnar
2010-06-01  6:53       ` Ingo Molnar
2010-06-01 12:44     ` Chris Mason
2010-06-01  6:35   ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C047B38.9050506@tmr.com \
    --to=davidsen@tmr.com \
    --cc=airlied@gmail.com \
    --cc=alex.buell@munted.org.uk \
    --cc=hancockrwd@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.