aboutsummaryrefslogtreecommitdiffstats
path: root/net/sunrpc/xprt.c
diff options
context:
space:
mode:
authorChuck Lever <chuck.lever@oracle.com>2007-03-29 16:47:53 -0400
committerTrond Myklebust <Trond.Myklebust@netapp.com>2007-04-30 22:17:10 -0700
commit2bea90d43a050bbc4021d44e59beb34f384438db (patch)
tree2dd3f15bd9df537166a82777b0c95243b90b17e1 /net/sunrpc/xprt.c
parent511d2e8855a065c8251d0c140ebc353854f1929e (diff)
downloadkernel_samsung_smdk4412-2bea90d43a050bbc4021d44e59beb34f384438db.zip
kernel_samsung_smdk4412-2bea90d43a050bbc4021d44e59beb34f384438db.tar.gz
kernel_samsung_smdk4412-2bea90d43a050bbc4021d44e59beb34f384438db.tar.bz2
SUNRPC: RPC buffer size estimates are too large
The RPC buffer size estimation logic in net/sunrpc/clnt.c always significantly overestimates the requirements for the buffer size. A little instrumentation demonstrated that in fact rpc_malloc was never allocating the buffer from the mempool, but almost always called kmalloc. To compute the size of the RPC buffer more precisely, split p_bufsiz into two fields; one for the argument size, and one for the result size. Then, compute the sum of the exact call and reply header sizes, and split the RPC buffer precisely between the two. That should keep almost all RPC buffers within the 2KiB buffer mempool limit. And, we can finally be rid of RPC_SLACK_SPACE! Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Diffstat (limited to 'net/sunrpc/xprt.c')
-rw-r--r--net/sunrpc/xprt.c1
1 files changed, 0 insertions, 1 deletions
diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
index 456a145..432ee92 100644
--- a/net/sunrpc/xprt.c
+++ b/net/sunrpc/xprt.c
@@ -823,7 +823,6 @@ static void xprt_request_init(struct rpc_task *task, struct rpc_xprt *xprt)
req->rq_task = task;
req->rq_xprt = xprt;
req->rq_buffer = NULL;
- req->rq_bufsize = 0;
req->rq_xid = xprt_alloc_xid(xprt);
req->rq_release_snd_buf = NULL;
xprt_reset_majortimeo(req);