Re: 2.4.1pre8 slowdown on dbench tests

[Jens Axboe <axboe@suse.de>]

On Wed, Jan 24 2001, Steven Cole wrote:
> > Thanks! Could I talk you into doing one last run? pre8 with
> > include/linux/elevator.h having these values set for
> > ELEVATOR_LINUS:
> >
> Here are two sets of dbench 48 runs with that mod. I can't explain why the
> second set is faster.  The second set was performed with no reboot after the 
> first set.  The individual runs were performed with no wait in-between.

Was this the 2.4.1-pre8x tree? Regardless, it's about back to the
same dbench performance that we saw earlier with the more unfair
setup. The blk-xx changes in recent 2.4.1-pre were not meant (and
never claimed :-) to boost dbench performance. That's actually
quite easy to do: let one thread completely finish I/O, _then_
move on to the next one. This isn't what we want in Real Life.

The fact that dbench performance remains pretty good from stock
kernel against the changes I told you to do is excellent and
mainly due to the batch freeing changes.

In most real life situations, throughput on account of no care for
latency is not ideal. Even though dbench performance drops a bit,
you will see better distribution of the bandwidth between the
threads. Think file serving.

-- 
* Jens Axboe <axboe@suse.de>
* SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/