summaryrefslogtreecommitdiff
path: root/fs/nfsd/nfs4xdr.c
diff options
context:
space:
mode:
authorChuck Lever <chuck.lever@oracle.com>2020-12-18 20:28:41 +0300
committerChuck Lever <chuck.lever@oracle.com>2020-12-18 20:28:41 +0300
commit4a85a6a3320b4a622315d2e0ea91a1d2b013bce4 (patch)
tree4e8eb4d04dc1ce578fe05f0903f85d79578b5c36 /fs/nfsd/nfs4xdr.c
parentd6c9e4368cc6a61bf25c9c72437ced509c854563 (diff)
downloadlinux-4a85a6a3320b4a622315d2e0ea91a1d2b013bce4.tar.xz
SUNRPC: Handle TCP socket sends with kernel_sendpage() again
Daire Byrne reports a ~50% aggregrate throughput regression on his Linux NFS server after commit da1661b93bf4 ("SUNRPC: Teach server to use xprt_sock_sendmsg for socket sends"), which replaced kernel_send_page() calls in NFSD's socket send path with calls to sock_sendmsg() using iov_iter. Investigation showed that tcp_sendmsg() was not using zero-copy to send the xdr_buf's bvec pages, but instead was relying on memcpy. This means copying every byte of a large NFS READ payload. It looks like TLS sockets do indeed support a ->sendpage method, so it's really not necessary to use xprt_sock_sendmsg() to support TLS fully on the server. A mechanical reversion of da1661b93bf4 is not possible at this point, but we can re-implement the server's TCP socket sendmsg path using kernel_sendpage(). Reported-by: Daire Byrne <daire@dneg.com> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209439 Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Diffstat (limited to 'fs/nfsd/nfs4xdr.c')
0 files changed, 0 insertions, 0 deletions