Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Mon, 14 Feb 2000 20:27:19 +0000 (GMT) | Subject | Re: elevator-starvation-4 (2.2.14 && 2.3.42) |
| |
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/
| |