Hi,
On Fri, 11 Feb 2000 06:10:37 -0800, Bruce Thompson
<bruce@otherother.com> said:
> Well, yes and no. I guess my fundamental claim is that if
> userland is able to generate requests faster than the driver can
> fulfill them for an extended period of time then we've got a larger
> problem than worrying about a particular request taking a long time to
> satisfy. Indeed, I claim that as long as the driver cannot keep up
> there will always be a pathological case where a particular request is
> unreasonably delayed.
> I'm not saying I have any idea what the correct solution is, but I
> feel that tackling the request scheduling problem is less meaningful
> if we haven't at least taken a whack at solving the request overrun
> problem.
But we _have_ addressed request overrun. You are confusing two related
but quite distinct things: the flow control you refer to is simply not
done at the request layer at all, but rather at a higher level
entirely.
First of all, user space generally does not create unbounded oustanding
IO request. It can generate unbounded dirty data, but that's something
different. Dirty data is cached for future writeback to disk, but that
writeback is not under the application's control (unless the user is
doing synchronous IO, in which case we have an obvious flow control
mechanism through which the application's performance will be
throttled).
So, when an application is doing a lot of writing, we need to perform
flow control to throttle the amount of dirty data allowed at once. That
is already done, but it has nothing to do with the IO scheduling.
Once the writeback of that dirty data commences, _then_ we need to do IO
scheduling. In fact, Linux does this in two stages: the bdflush code
queues IO for dirty buffers without any fancy elevator sorting at all;
and then the IO layer services those outstanding IO requests using the
elevator sort.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:27 EST