On Oct 23, 2008, at 22:06, "Steve French" <smfrench@xxxxxxxxx> wrote:
On Thu, Oct 23, 2008 at 8:52 PM, Trond Myklebust
<trond.myklebust@xxxxxxxxxx> wrote:
On Thu, 2008-10-23 at 20:18 -0500, Steve French wrote:
Jim & co are talking about the _server_ side, which has very
different
requirements when compared to a client. One of the NFS kernel
server's
main tasks is to manage its own resources, and for that reason one of
the design constraints is that it only starts reading the next
request
from a socket when it knows that it has enough resources to send a
reply
without blocking.
Look rather at the NFS client: that uses non-blocking modes together
with an aio engine (a.k.a. rpciod) to shove stuff as quickly as
possible
out of the socket's skbufs and into the page cache/inode metadata
caches. No locking of TCP socket buffer sizes needed or used...
That brings us back to what started this discussion though (blocking
vs.
non-blocking sends) ... on the send path in the cifs client,
Shirish's testing
shows improvements when we change from non-blocking sends
with retry to blocking sends:
- smb_msg.msg_flags = MSG_DONTWAIT + MSG_NOSIGNAL;
+ smb_msg.msg_flags = MSG_NOSIGNAL;
So, what triggers the retry in your case? In NFS, we use a
sk_writespace callback to initiate another attempt. That's pretty much
the mechanism used by the non-blocking sendmsg() too.
Trond
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
