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 kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
