Con Kolivas <conman@kolivas.net> wrote:
>
> I do believe these show that sequential reads are indeed scheduled before
> writes with this kernel. The question is, how long should they be scheduled
> for?
No, Nick has some logic in there which remembers the last-submitted sector
and treats that as an insertion candidate as well. That's unrelated to
the anticipatory code.
Which is all fine, but it needs some taming to prevent the obvious starvation
which can happen.
I'm going to nobble that for now. There have been enormous gyrations in the
behaviour of the IO scheduler in recent months and I wish to get it settled
down to good all-round behaviour _without_ the anticipatory scheduler in
place. Because there are fairly hairy issues surrounding the anticipatory
scheduler and device drivers - anticipatory scheduling may not get there.
I have spent some time this week tuning up and fixing the non-anticipatory
I/O scheduler and I'd like to stabilise that code for a while, to provide a
decent baseline against which to continue the anticipatory development.
In fact, the tuned-up scheduler performs respectably against the anticipatory
code. Which isn't theoretically correct, and indicates that the anticipatory
code can be optimised further.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jan 31 2003 - 22:00:25 EST