Hi,
On Sun, Apr 16, 2000 at 04:59:52PM +0100, Steve Dodd wrote:
>
> Hmmm, I'm not clear on the working of the request queue stuff, but I don't
> see why the comment above would apply to block-backed but not file-backed
> loops. Surely the issue is that you can end up in a sitation where you need
> one or more free requests to complete a request, there are no free
> requests, and the only way to free one is to complete a request..
The code you mentioned simply restricts the loop device to use only
half of the available requests. _All_ of the other requests are
available to anyone wanting to complete an operation. Any single
loop request can use as many other requests as it wants: if the bit
of the queue reserved for loop requests is full, it will just end
up using a shorter remaining queue for its own requests.
The request mechanism is supposed to be deadlock-free no matter how
big or small the request table is. Quite simply, if you submit more
IOs than there are requests available, then there is an implicit
unplug of the existing requests to let some IO proceed until one of
the requests completes.
Loop drivers effectively have a smaller number of guaranteed available
requests than other drivers: they can only assume that the half of the
request table which is not usable by loop requests can be used to
satisfy their own requests to the underlying drivers. However, that
half of the table is still enough to let the auto-unplug mechanism
work. I can't see how there can be any deadlock here.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:10 EST