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; -- Thanks, Steve -- 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
