Re: Time sliced CFQ io scheduler

From: Andrea Arcangeli
Date: Tue Dec 07 2004 - 21:53:18 EST


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?

> 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...

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?

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/