Messages in this thread | | | Date | Wed, 24 Jan 2001 17:44:39 +0100 | From | Jens Axboe <> | Subject | Re: 2.4.1pre8 slowdown on dbench tests |
| |
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/
| |