linux-kernel - Re: 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]

Message-Id: <1219025114.25933.6.camel@ymzhang>
Date:	Mon, 18 Aug 2008 10:05:14 +0800
From:	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>
To:	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
Cc:	David Miller <davem@...emloft.net>, cl@...ux-foundation.org,
	Netdev <netdev@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: tbench regression on each kernel release from 2.6.22 -> 2.6.28


On Tue, 2008-08-12 at 11:13 +0300, Ilpo Järvinen wrote: 
> On Mon, 11 Aug 2008, David Miller wrote:
> 
> > From: Christoph Lameter <cl@...ux-foundation.org>
> > Date: Mon, 11 Aug 2008 13:36:38 -0500
> > 
> > > It seems that the network stack becomes slower over time? Here is a list of
> > > tbench results with various kernel versions:
> > > 
> > > 2.6.22		3207.77 mb/sec
> > > 2.6.24		3185.66
> > > 2.6.25		2848.83
> > > 2.6.26		2706.09
> > > 2.6.27(rc2)	2571.03
> > > 
> > > And linux-next is:
> > > 
> > > 2.6.28(l-next)	2568.74
> > > 
> > > It shows that there is still have work to be done on linux-next. Too close to
> > > upstream in performance.
> > > 
> > > Note the KT event between 2.6.24 and 2.6.25. Why is that?
> > 
> > Isn't that when some major scheduler changes went in?  I'm not blaming
> > the scheduler, but rather I'm making the point that there are other
> > subsystems in the kernel that the networking interacts with that
> > influences performance at such a low level.
> 
> ...IIRC, somebody in the past did even bisect his (probably netperf) 
> 2.6.24-25 regression to some scheduler change (obviously it might or might 
> not be related to this case of yours)...
I did find much regression with netperf TCP-RR-1/UDP-RR-1/UDP-RR-512. I start
1 serve and 1 client while binding them to a different logical processor in
different physical cpu.

Comparing with 2.6.22, the regression of TCP-RR-1 on 16-core tigerton is:
2.6.23		6%
2.6.24		6%
2.6.25		9.7%
2.6.26		14.5%
2.6.27-rc1	22%

Other regressions on other machines are similar.

yanmin


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