Messages in this thread | | | Date | Sun, 21 Apr 2002 22:53:12 +0200 | From | Pavel Machek <> | Subject | Re: [ENBD] [Fwd: Re: [PATCH] 2.5.8 IDE 36] |
| |
Hi!
> With it, the protocol in the client daemon will ack the kernel _before_ > it gets an ack from the remote server. That should help relieve the > deadlock. Things then go like this: > > kernel runs low on memory > kernel flushes buffers to device drivers under pressure > nbd client daemon sends to the net > * client acks kernel and releases buffers in kernel > server on the _same machine_ receives request over the net > server tries to write request to disk > server process needs buffers to write to > * server gets buffers released by client in kernel > > At least, potentially. If I recall right, there's still a deadlock > window in-kernel, but it's small. I don't recall the details. Oh - > well, the request still hangs around in the driver until the client > daemon acks .. maybe the client daemon can't ack without being swapped > in first, and that'd be deadlock. > > Well, there's a "-s" flag (for swap devices) that does an mlockall() > that might take care of that. So "-a -s" might do it. Really needs > a "-aa" option (release write request in kernel asap).
Well, with mlockall(), I'd believe it could be made to work. Okay. Pavel -- (about SSSCA) "I don't say this lightly. However, I really think that the U.S. no longer is classifiable as a democracy, but rather as a plutocracy." --hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |