Re: Time sliced CFQ io scheduler

[Nick Piggin <nickpiggin@yahoo.com.au>]

On Wed, 2004-12-08 at 03:51 +0100, Andrea Arcangeli wrote:
> On Wed, Dec 08, 2004 at 01:33:33PM +1100, Nick Piggin wrote:
> > I think we could detect when a disk asks for more than, say, 4
> > concurrent requests, and in that case turn off read anticipation
> > and all the anti-starvation for TCQ by default (with the option
> > to force it back on).
> 
> What do you mean with "disk asks for more than 4 concurrent requests?"
> You mean checking the TCQ capability of the hardware storage?
> 

Yeah. Just check if there are more than 4 outstanding requests at once.

> > I think this would be a decent "it works" solution that would make
> > AS acceptable as a default.
> 
> Perhaps the code would be the same but if you disable it completely on
> certain hardware that's not AS anymore...
> 

Which is what we want on those system ;)

> Then I believe it would be better to switch to cfq for storage capable
> of more than 4 concurrent tagged queued requests instead of sticking
> with a "disabled AS". What's the point of AS if the features of AS are
> disabled?
> 

For everyone else, who do want the AS features (ie. not databases).

> One relevant feature of cfq is the fairness property of pid against pid
> or user against user. You don't get that fairness with the other I/O
> schedulers. It was designed for fairness since the first place. Fariness
> of writes against writes and reads against reads and write against reads
> and read against writes.

That is something, I'll grant you that.