Robert Love wrote:
>
> ...
> > Benchmarks are well and good, but until we have a solid explanation for
> > the throughput changes which people are seeing, it's risky to claim
> > that there is a general benefit.
>
> I have an explanation. We can schedule quicker off a woken task. When
> an event occurs that allows an I/O-blocked task to run, its time-to-run
> is shorter. Same event/response improvement that helps interactivity.
>
Sounds more like handwaving that an explanation :)
The way to speed up dbench is to allow the processes which want to delete
files to actually do that. This reduces the total amount of IO which the
test performs. Another way is to increase usable memory (or at least to
delay the onset of balance_dirty going synchronous). Possibly it's something
to do with letting kswapd schedule earlier. Or bdflush.
In the swapstorm case, it's again not clear to me. Perhaps it's due to prompter
kswapd activity, perhaps due somehow to improved request merging.
As I say, without a precise and detailed understanding of the mechanisms
I wouldn't be prepared to claim more than "speeds up dbench and swapstorms
for some reason".
(I'd _like_ to know the complete reason - that way we can stare at it
and maybe make things even better. Doing a binary search through the
various chunks of the mini-ll patch would be instructive).
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jan 15 2002 - 21:00:41 EST