Messages in this thread |  | | Date | Thu, 24 Aug 2000 09:52:09 +0200 (CEST) | From | Giuliano Pochini <> | Subject | Re: ll_rw_blk.c fails to merge requests. Help! |
| |
> 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.
Hmm, I haven't tried your patch yet (my 2.4 machine is at home, I'll try this evening), but I thing there is a better solution. I believe the point is that
if (!MERGE_NEW_REQ(rq)) ADD_NEW(rq);
is not atomic then the queue is full because it needs to release the lock while waiting. Perhaps we can workaroung the problem by allocating a new request first and then we lock, see if our rq is still here, and scan the list to look for an old rq to coalesce with. If we find one, we can free the rq, otherwise we simply leave the rq on the list. Finally we unlock the list.
> I noticed the possibility for this in the code a few days ago but > thought "that could never happen".
:)) Murphy's law.
Bye. Giuliano Pochini ->)|(<- Shiny Corporation {AS6665} ->)|(<-
- 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/
|  |