[lkml]   [2004]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Time sliced CFQ io scheduler
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

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


> 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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:08    [W:0.115 / U:40.120 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site