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 <email@example.com> * SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org Please read the FAQ at http://www.tux.org/lkml/