Re: Time sliced CFQ io scheduler

[Jens Axboe <axboe@suse.de>]

On Wed, Dec 08 2004, Helge Hafting wrote:
> >>AS needs another iteration of development to fix these things.  Right now
> >>it's probably the case that we need CFQ or deadline for servers and AS for
> >>desktops.   That's awkward.
> >>   
> >>
> >
> >Currently I think the time sliced cfq is the best all around. There's
> >still a few kinks to be shaken out, but generally I think the concept is
> >sounder than AS.
> > 
> >
> I wonder, would it make sense to add some limited anticipation
> to the cfq scheduler?  It seems to me that there is room to
> get some of the AS benefit without getting too unfair:
> 
> AS does a wait that is short compared to a seek, getting some
> more locality almost for free.  Consider if CFQ did this, with
> the added limitation that it only let a few extra read requests
> in this way before doing the next seek anyway.  For example,
> allowing up to 3 extra anticipated read requests before
> seeking could quadruple read bandwith in some cases.  This is
> clearly not as fair, but the extra reads will be almost free
> because those few reads take little time compared to the seek
> that follows anyway.  Therefore, the latency for other requests
> shouldn't change much and we get the best of both AS and CFQ.
> Or have I made a broken assumption?

This is basically what time sliced cfq does. For sync requests, cfq
allows a definable idle period where we give the process a chance to
submit a new request if it has enough time slice to do so. This
'anticipation' then is just an artifact of the design of time sliced
cfq, where we do assign a finite time period where a given process owns
the disk.

See my initial posting on time sliced cfq. That is why time sliced cfq
does as well (or better) then AS for the many client cases, while still
being fair.

-- 
Jens Axboe