netdev - Re: AIM9 regression

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:	Wed, 24 Sep 2008 12:36:57 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	shemminger@...tta.com
Cc:	herbert@...dor.apana.org.au, cl@...ux-foundation.org,
	netdev@...r.kernel.org
Subject: Re: AIM9 regression

From: Stephen Hemminger <shemminger@...tta.com>
Date: Wed, 24 Sep 2008 08:16:03 -0700

> On Tue, 23 Sep 2008 22:18:31 -0700 (PDT)
> David Miller <davem@...emloft.net> wrote:
> 
> > From: Herbert Xu <herbert@...dor.apana.org.au>
> > Date: Wed, 24 Sep 2008 13:12:37 +0800
> > 
> > > On Tue, Sep 23, 2008 at 01:14:27PM -0500, Christoph Lameter wrote:
> > > > I just dont seem to be able to get 2.6.27 to behave in a speedy way network
> > > > wise. Configured out various components (netfilter, etc etc) but I still keep
> > > > getting these aim9 result against 2.6.22:
> > > 
> > > Could you please compare this against something less ancient,
> > > like 2.6.26 perhaps?
> > 
> > Herbert, this is part of the tbench regression issues.  Christoph
> > took tbench from 2.6.22 until 2.6.27 and at basically every release
> > tbench performance suffered noticably.
> > 
> > Now, he's taking the AIM9 benchmark networking numbers and showing
> > that the same exact effect is seen there too.
> > 
> > It really behooves us to start doing something proactive about this
> > blindingly obvious set of networking performance regressions through
> > the past 6 or so releases instead of barking at the reporters saying
> > things like "try this, try that, what's your config" etc.
> > 
> > :-)
> 
> These loopback benchmarks are often more sensitive to scheduler than networking
> changes.

When it gets to %20, I strong start to doubt that, and this is exactly
what's happening here.

What is it going to take to actually get someone to start profiling and
analyzing this?  :-)

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html