lkml.org 
[lkml]   [2000]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: ll_rw_blk.c fails to merge requests. Help!
Date
In article <14756.25889.655254.332719@notabene.cse.unsw.edu.au>,
Neil Brown <neilb@cse.unsw.edu.au> wrote:
>
>Not necessarily. When a request is freed, the oldest waiting thread
>is woken, but it might not actually get to run before some other
>thread steals the request. You could force a strict ordering if you
>really wanted to, but I don't know how much it would help. See
>STRICT_REQUEST_ORDERING in the patch below.

Neil, I suspect the request ordering is secondary, and the real problem
is that at some point we get into this awful steady state where we
create new requests at the same pace as we get rid of old ones, and we
always end up waiting for the next request to be free'd.

The "always end up waiting" thing means that we won't do a good job on
read-ahead etc (because suddenly all our request stuff will be
synchronous wrt the disk), so it _would_ impact performace. I think.

Making the request ordering stricter won't help with this situation - it
just makes it more fairly badly behaved. What _should_ help is to
"batch" the freeing of requests, so that you don't end up waking up
anybody (and everybody blocks on the requests being empty) until you've
free'd up, say, half of the request queue again.

Ie something like
- when you free an entry, and there is somebody waiting for entries,
you don't actually put it directly on the "free request" list. You
put it on the "pending to-be-freed" list.
- when the pending-to-be-freed list grows past a certain size, you free
them all in one go and wake up all waiters.

Why is read-ahead important? It not only improves through-put, it also
improves the bad behaviour when you have multiple "streams" that go to
different parts of the disk. Without read-ahead, you'll have the disk
seeking back and forth for every request. With read-ahead, you can
avoid that.

The normal elevator thing obviously tries to merge first, so truly
contiguous entries should get merged regardless of whether there are any
free requests or not. However, we should try to get the "not quite
contiguous" case right too. And I'm not convinced my theory above is
valid, but I can see that there could indeed be some bad behaviour
patterns if we only have one request free at any particular time..

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.145 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site