linux-kernel - Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

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]

Date:	Tue, 16 Sep 2008 17:07:53 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Mike Galbraith <efault@....de>
cc:	Christoph Lameter <cl@...ux-foundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	LKML <linux-kernel@...r.kernel.org>,
	kernel-testers@...r.kernel.org
Subject: Re: [Bug #11308] tbench regression on each kernel release from 2.6.22
 -&gt; 2.6.28

On Tue, 16 Sep 2008, Mike Galbraith wrote:

> On Mon, 2008-09-15 at 12:44 +0200, Mike Galbraith wrote:
> > On Sun, 2008-09-14 at 21:51 +0200, Mike Galbraith wrote:
> > 
> > Since 2.6.22.19-cfs-v24.1 and 2.6.23.17-cfs-v24.1 schedulers are
> > identical, and these are essentially identical with 2.6.24.7, what I
> > read from numbers below is that cfs in 2.6.23 was somewhat less than
> > wonderful for either netperf or tbench,  Something happened somewhere
> > other than the scheduler at 23->24 which cost us some performance, and
> > another something happened at 26->27.  I'll likely go looking again..
> > and likely regret it again ;-)
> 
> Bisecting 26->27 yet again turned up a repeatable downturn in netperf
> throughput.  There is no difference at this point with tbench. 
> 
> Bisect says first bad commit is 847106f, a security merge.  Post
> bisection sanity checkouts say...
> 
> v2.6.26-21-g2069f45
> 16384  87380  1        1       60.00    98435.13
> 16384  87380  1        1       60.01    99259.90
> 16384  87380  1        1       60.01    99325.61
> 16384  87380  1        1       60.00    99039.84
> 
> v2.6.26-343-g847106f
> 16384  87380  1        1       60.00    94764.59
> 16384  87380  1        1       60.00    94909.89
> 16384  87380  1        1       60.00    94858.63
> 16384  87380  1        1       60.00    94801.12
> 
> ...every time.  I knew I'd regret doing this.

I assume that c142bda458a gave a good results as well...

One additional sanity check could be to rebase security 6f0f0fd4963 on top 
of the c142bda458a and then see if bisection among those security commits 
on top yields to the the same result... Though I doubt it can change much 
because there was not that much relevant non-security things in the merge 
in question.

-- 
 i.

--
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/