Hi,
I guess when it comes down to it I don't see how this solves the
problem. Even with a maximum permissable latency we're certain to get
into a pathological case eventually where requests are being
generated faster than they can be processed. As long as that state
remains (i.e. generating them too fast) then we're guaranteed to
start starving some requests. It cannot be helped. Sorry to
reiterate, but I really want to be clear here. If requests are being
generated at a sustained rate faster than they can be processed then
eventually something has to give and that something is likely to be
the latency and something is gonna starve.
Please keep in mind that I have no idea if my idea is feasible or
even possible. It's the germ of an idea and perhaps it's time for me
to get off my duff and actually attempt to implement something. If
there is some way for the driver to say "I'm too busy right now, you
may not submit your request now" via a high and low watermark on the
request queue length then the starvation issue simply cannot occur.
We can then handle short bursts of requests being generated faster
than they can be processed, but we've got a defined threshold when we
stop accepting new requests before handling the backlog. _That's_
what appears to be missing now, that guaranteed threshold where we
say "Enough!" and handle what's on our plate before accepting any
more.
I really hope I'm not missing something obvious here...
Cheers,
Bruce.
At 17:19 +0100 02/11/2000, Andrea Arcangeli wrote:
>On Fri, 11 Feb 2000, Bruce Thompson wrote:
>
>> It need not be a case of "The driver can handle X MB/sec so give
>>the other one X/2 MB/sec of requesting ability". One thought that
>
>Well it's not so trivial to know the drivers run at X MB/sec. You should
>calculate also in function of the seeks and in function of the underlying
>LVM physical volumes.
>
>>process. Once the counter exceeds some particular highwater mark the
>>process is blocked from entering more requests until the counter
>>drops to some lowwater mark. Hmm. ANother thought. Make the counter
>
>You never generate I/O from tasks. It's when the buffer is too old that
>kupdate flushes writes to disk. At that time the process is just exited
>and the user just run another program that gets stalled due the write
>flood.
>
>Also kupdate feed at the maximal speed in one chunk all the requests we
>got in the last 5 seconds even if the task written at slower frequencey
>and that looks fine for CPU icache optimizations, coalescing and elevating
>the requests to reduce the global load.
>
>> Either way, it's an interesting problem, and I truly do believe
>>that attacking it via mods to the elevator algorithm is merely
>>putting off the inevitable whereas attacking the root cause will
>>allow us to degrade much more gracefully in the face of massive I/O
>>activity.
>
>The starvation problem can be reproduced perfectly fine with 30000 tasks
>that write 1 request per task and they are writing all at 1/30000 of the
>max throughtput that the I/O can handle. But the 30001 task gets starved
>for two days. See? The bug is definitly into the elevator and I think the
>best way to fix that is with a per-request maximal latency as I just did.
>Trying to hide it in the other layers is wrong IMHO.
>
>I believe the theory we studied was missing the basic point I got in the
>last weeks. It looked correct to me too at first. But then I understood it
>simply doesn't apply in practice and so I designed a way to enforce a max
>latency per-request and the longstanding problem got now finally fixed in
>practice as far I can tell.
>
>BTW the elevator bug is not only a latency issue, it's also a reliability
>issue, a write request can be delayed for too long time too.
>
>Andrea
--
--
------------------------------------------------------------------------
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:21 EST