[lkml]   [2000]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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))

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.

Giuliano Pochini ->)|(<- Shiny Corporation {AS6665} ->)|(<-

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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