Messages in this thread |  | | From | (Linus Torvalds) | Subject | Re: ll_rw_blk.c fails to merge requests. Help! | Date | 23 Aug 2000 20:32:07 -0700 |
| |
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/
|  |