Hi Stephen,
Then I'm confused. If request overrun has been addressed then how
can the oft quoted "cat /dev/zero > /foo/bar" trick cause a problem?
Am I completely missing how this messes everything up?
As I understood it, the problem with the /dev/zero example was
that until the disk filled up the process would add requests faster
than the driver could service them resulting in a request queue that
the normal elevator algorithm would have to churn through until it
had reached the end of the platter. If on the other hand there was
some sort of flow control that actually prevented requests from
overrunning the driver's ability to keep up then at some point in
time the driver would get past the /dev/zero example and the normal
elevator rules would result in reasonably fair allocation of the
resource. I think that there still is an issue of fair use of the
resource as mentioned previously by Giuliano, and perhaps we need
some sort of priority/time slicing of IO requests as he suggests.
Perhaps it is the bdflush layer that needs to be cognizant of the
queue length on the driver then it could ensure that when there are a
lot of outstanding requests it doesn't queue any more. Eventually
everything will stall waiting for the IO to complete (which it will)
and all will be well.
Cheers,
Bruce.
At 20:27 +0000 02/14/2000, Stephen C. Tweedie wrote:
>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
--
--
------------------------------------------------------------------------
Bruce Thompson | "Pinky! Are you pondering what I'm
Palm Computing, Inc. | pondering?"
| "Uh, I think so Brain, but where will
| we find a duck and a hose at this
bruce@otherother.com | hour?"
My opinions are strictly my own.
PGP Fingerprint: 8F48 7FEF EE22 14FB 1F2E 3BF2 0D40 9628 53E8 72EB
-
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:28 EST