netdev - Re: [tbench regression fixes]: digging out smelly deadmen.

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: <20081026023439.c6cf4e94.akpm@linux-foundation.org>
Date:	Sun, 26 Oct 2008 02:34:39 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Evgeniy Polyakov <zbr@...emap.net>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Mike Galbraith <efault@....de>, Jiri Kosina <jkosina@...e.cz>,
	David Miller <davem@...emloft.net>, rjw@...k.pl,
	Ingo Molnar <mingo@...e.hu>, s0mbre@...rvice.net.ru,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [tbench regression fixes]: digging out smelly deadmen.

On Sun, 26 Oct 2008 12:27:22 +0300 Evgeniy Polyakov <zbr@...emap.net> wrote:

> Hi.
> 
> On Sun, Oct 26, 2008 at 02:11:53AM -0700, Andrew Morton (akpm@...ux-foundation.org) wrote:
> > > Andrew said recently:
> > >   "dbench is pretty chaotic and it could be that a good change causes
> > > dbench to get worse.  That's happened plenty of times in the past."
> > > 
> > > So I'm not inclined to worry too much about dbench in any way shape or
> > > form.
> > 
> > Well.  If there is a consistent change in dbench throughput, it is
> > important that we at least understand the reasons for it.  But we
> > don't necessarily want to optimise for dbench throughput.
> 
> Sorry, but such excuses do not deserve to be said. No matter how
> ugly, wrong, unusual or whatever else you might say about some test, but
> it shows the problem, which has to be fixed.

Not necessarily.  There are times when we have made changes which we
knew full well reduced dbench's throughput, because we believed them to
be of overall benefit.  I referred to one of them above.

> There is no 'dbench tune',
> there is fair number of problems, and at least several of them dbench
> already helped to narrow down and precisely locate. The same regressions
> were also observed in other benchmarks, originally reported before I
> started this thread.

You seem to be saying what I said.
--
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