Messages in this thread | | | Date | Wed, 8 Dec 2004 03:09:23 +0100 | From | Andrea Arcangeli <> | Subject | Re: 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 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). - 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/
| |