> 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/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:12 EST