Re: Time sliced CFQ io scheduler

[Andrea Arcangeli <andrea@suse.de>]

On Wed, Dec 08, 2004 at 11:54:13AM +1100, Nick Piggin wrote:
> That is synch write bandwidth. Yes that seems to be a problem.

It's not just sync write, it's a write in general, blkdev doesn't know
if the one waiting is pdflush or some other task. Once this will be
fixed I will have to reconsider my opinion of course, but I guess after
it gets fixed the benefit of "as" on the desktop will as well decrease
compared to cfq. The desktop is ok with "as" simply because it's
normally optimal to stop writes completely, since there are few apps
doing write journaling or heavy writes, and there's normally no
contigous read happening in the background. Desktop just needs a
temporary peak read max bandwidth when you click on openoffice or
similar app (and "as" provides it). But on a mixed server doing some
significant read and write (i.e.  somebody downloading the kernel from
kernel.org and installing it on some application server) I don't think
"as" is general purpose enough. Another example is the multiuser usage
with one user reading a big mbox folder in mutt, whole the other user
s exiting mutt at the same time. The one exiting will pratically have to
wait the first user to finish its read I/O. All I/O becomes sync when it
exceeds the max size of the writeback cache.

"as" is clearly the best for the common case of the very desktop usage
(i.e. machine 99.9% idle and without any I/O except when starting an app
or saving a file, and the user noticing delay only while waiting the
window to open up after he clicked the button).  But I believe cfq is
better for a general purpose usage where we cannot assume how the kernel
will be used.