Re: Time sliced CFQ io scheduler

[Andrea Arcangeli <andrea@suse.de>]

On Wed, Dec 08, 2004 at 12:47:08PM +1100, Nick Piggin wrote:
> Buffered writes don't suffer the same problem obviously because the
> disk can can easily be kept fed from cache. Any read vs buffered write

This is true for very small buffered writes, which is the case for
desktop usage, but for more server oriented usage if the write isn't so
small, and you flush the writeback cache to disk very slowly, eventually
it will become a _sync_ write. So I agree that as long as the write
doesn't become synchronous "as" provides better behaviour.

One hidden side effect of "as" is that by writing so slowly (and
64KiB/sec really is slow), it increases the time it will take for a
dirty page to be flushed to disk (with tons of ram and lot of continous
readers I wouldn't be surprised if it could take hours for the data to
hit disk in an artificial testcase, you can do the math and find how
long it would take to the last page in the list to hit disk at
64KiB/sec).

> starvation you see will mainly be due to the /sys tunables that give
> more priority to reads (which isn't a bad idea, generally).

sure.

> Maybe. CFQ may be a bit closer to a traditional elevator behaviour,
> while AS uses some significantly different concepts which I guess
> aren't as well tested and optimised for.

It's already the best for desktop usage (even the 64KiB/sec is the best
on desktop), but as you said above it uses significantly different
concepts and that makes it by definition not general purpose (and
definitely a no-way for database, while cfq isn't a no-way on the
desktop).