Re: [Bug #11308] tbench regression on each kernel release from2.6.22 -> 2.6.28
From: Mike Galbraith
Date: Tue Sep 16 2008 - 08:28:45 EST
On Mon, 2008-09-15 at 12:44 +0200, Mike Galbraith wrote:
> On Sun, 2008-09-14 at 21:51 +0200, Mike Galbraith wrote:
> > On Sun, 2008-09-14 at 09:18 -0500, Christoph Lameter wrote:
> > > Mike Galbraith wrote:
> > > > Numbers from my Q6600 Aldi supermarket box (hm, your box is from different shelf)
> > > >
> > > My box is an 8p with recent quad core processors. 8G, 32bit Linux.
> >
> > Don't hold your breath, but after putting my network config of a very
> > severe diet, I'm starting to see something resembling sensible results.
>
> Turns off all netfilter options except tables, etc.
>
> 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.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/