On Sat, Jun 17, 2000 at 05:44:31PM +0200, Mike Galbraith wrote:
> I still think that it's reentering to service the same blocks it's already
> trying to service, but am not sure about that.
No, that shouldn't happen - the buffer will get locked when we start I/O on it.
I believe the problem is this:
We have various resources that are needed, generally, for loop to perform I/O:
buffers, buffer heads, requests, and pages. All of these except requests
boil down to "memory"; requests are different because we have a fixed number
of them.
i) When the kernel runs out of memory, one of the things it does is to try to
free buffers by writing out those that are dirty. If these happen to be loop
buffers, we can deadlock, because loop may well end up sleeping, waiting for
a memory related resource to become free.
ii) When the kernel runs out of requests, it starts I/O on queued requests.
If these happen to be loop requests, we can deadlock, because loop may well
end up sleeping waiting for a free request.
In 2.2, (ii) is avoided by ensuring the maximum number of pending loop requests
is half of the total, as loop will only need one additional request to fulfill
a request (loop in 2.2 only ever uses bmap() to read file data). I'm not
sure whether this holds in 2.3.
I've just tested loop on 2.2, and I couldn't deadlock it. I didn't understand
how it avoided situation (i), until I checked the 2.2 version of buffer.c:
it has loop-specific hacks in refile_buffer() and bdflush() to avoid deadlock.
They went in between 2.2.8 and 2.2.14, and seem to be Andrea's work (see
<Pine.LNX.4.10.9907081932180.7126-100000@laser.random>,
"[patch] 2.2.10 buffer patch"). AFAICS, 2.3 doesn't have anything like this,
and I'm not convinced they're sufficient anyway, now that we do I/O through
the page cache and the underlying filesystem.
Comments?
-
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 : Fri Jun 23 2000 - 21:00:15 EST