[lkml]   [2002]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [ENBD] [Fwd: Re: [PATCH] 2.5.8 IDE 36]

> 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.
(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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:25    [W:0.038 / U:0.424 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site