Thread (94 messages) 94 messages, 17 authors, 2008-11-04

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

From: Andrew Morton <akpm@linux-foundation.org>
Date: 2008-10-26 09:35:28
Also in: lkml

On Sun, 26 Oct 2008 12:27:22 +0300 Evgeniy Polyakov [off-list ref] wrote:
Hi.

On Sun, Oct 26, 2008 at 02:11:53AM -0700, Andrew Morton (akpm@linux-foundation.org) wrote:
quoted
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help