On Wed, Mar 9, 2011 at 5:54 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Wed, 9 Mar 2011 16:01:30 -0600 > Steve French <smfrench@xxxxxxxxx> wrote: > >> >> Except we don't need to wait that long with the page locked >> ie for a response from the cifs server (such as Samba or Windows >> or NetApp), just need to wait for it to get on the wire. >> Waiting for us to get the server response would >> take 10 or 100 times longer. In any case we can't resend >> the same request to the server (the signature changes on the >> resend since the sequence number is incremented on every >> request/response so we have to recalc the checksum anyway) and >> cifs requests can't get lost (as with nfs over udp). Keeping >> a page locked for 10milliseconds seems like a bad idea - but >> it is a little more complicated to implement (for the cifs case) >> so that we end page writeback (for the non-WB_SYNC) >> as quickly as reasonably possible so we don't kill perf. >> > > The problem here is that the socket layer doesn't have a mechanism > to notify us of a TCP ACK. So, we have to wait for the next-best thing > -- a response from the server. But ... we can stop writeback as soon as kernel_sendmsg returns - once we return from kernel_sendmsg the buffers can (and often will) be freed so we know those pages could not still be used by tcp (below cifs) once kernel_sendmsg returns. We can minimize the delay further by making sure we set TCP_NODELAY on the socket (we probably ought to make that the default instead of an option). -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
