[lkml]   [2004]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Time sliced CFQ io scheduler
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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:08    [W:0.080 / U:0.076 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site