linux-kernel - Re: Article in Phoronix about loss of performance in 2.6.35 release candidates

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1275370694.9751.58.camel@marge.simson.net>
Date:	Tue, 01 Jun 2010 07:38:14 +0200
From:	Mike Galbraith <efault@....de>
To:	Robert Hancock <hancockrwd@...il.com>
Cc:	Bill Davidsen <davidsen@....com>, alex.buell@...ted.org.uk,
	Mailing Lists - Kernel Developers 
	<linux-kernel@...r.kernel.org>, Dave Airlie <airlied@...il.com>
Subject: Re: Article in Phoronix about loss of performance in 2.6.35
 release candidates

On Mon, 2010-05-31 at 21:22 -0600, Robert Hancock wrote:
> On Mon, May 31, 2010 at 9:15 PM, Bill Davidsen <davidsen@....com> wrote:
> > 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?
> 
> Of course they shouldn't keep it quiet. The problem is they went and
> wrote an article that was basically "OMG HUGE PERFORMANCE LOSS!!1!!"
> without reporting the problem to people that can actually do something
> about it, and also didn't provide any very useful details like dmesg,
> config, etc. that might let someone figure out what's going on.

Shrug.  If eggshells land in our omelet, they can make a buck telling
people about it.  Who cares?  If tasty bacon bits land, they'll make a
buck on that event.  Either way, we get some test coverage.

	-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/