On Sun, Sep 17, 2000 at 05:38:17PM -0300, Rik van Riel wrote:
> Yes, I run my system with elvtune -r 250 -w 500.
Ok (sorry for asking, it was just to be sure).
> But even with -r 5 -w 5, I saw starvation. This, and
I'd call it "too high latency", not starvation. Well, strictly speaking it's
not even correct to call starvation the behaviour of 2.2.15 because the latency
provided by CSCAN (without any additional I/O scheduler logic) have an high
bound that depends on the size of the disk and on the speed of the disk, but
the higher possible latency of the old elevator was so big that calling it
"starvation" was not so badly wrong :).
> the code, is a clear sign to me that Peter is absolutely
> right and his corrections to the code should be merged.
Peter correction can improve performance but it shouldn't decrease the latency
significantly. Of course I see that running the I/O faster you have a chance to
reduce also the latency but as said not of a significant factor (not at the
levels of 2.2.16 or 2.4.0-test1).
The fact is that to reduce the latency of a pagein while a background
write is happening, we have to generate seeks at higher frequency. If we do
that we hurt the performance of the write and we change the tiotest numbers
(that's what happens in 2.2.16 for example). If you increase the latency
then tiotest returns to run fast as before. I don't see an easy solution
to apply to a global algorithm that doesn't know the semantics of the I/O
(so that doesn't know when somebody (human) is waiting I/O completion while
looking the screen).
Andrea
-
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/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:15 EST