From: Jim Rees <rees@umich.edu>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Ben Myers <bpm@sgi.com>, Olga Kornievskaia <aglo@citi.umich.edu>,
linux-nfs@vger.kernel.org
Subject: Re: sunrpc: socket buffer size tuneable
Date: Fri, 25 Jan 2013 14:16:20 -0500 [thread overview]
Message-ID: <20130125191620.GA12925@umich.edu> (raw)
In-Reply-To: <20130125185748.GC29596@fieldses.org>
J. Bruce Fields wrote:
On Thu, Jan 24, 2013 at 06:59:30PM -0600, Ben Myers wrote:
> At 1020 threads the send buffer size wraps and becomes negative causing
> the nfs server to grind to a halt. Rather than setting bufsize based
> upon the number of nfsd threads, make the buffer sizes tuneable via
> module parameters.
>
> Set the buffer sizes in terms of the number of rpcs you want to fit into
> the buffer.
From private communication, my understanding is that the original
problem here was due to memory pressure forcing the tcp send buffer size
below the size required to hold a single rpc.
In which case the important variable here is lock_bufsize, as that's
what prevents the buffer size from going too low.
Cc'ing Jim Rees in case he remembers: I seem to recall discussing this
possibility, wondering whether we needed a special interface to the
network layer allowing us to set a minimum, and deciding it wasn't
really necessary at the time as we didn't think the network layer would
actually do this. Is that right? In which case either we were wrong,
or something changed.
I do remember discussing this. My memory is that we needed it but no one
wanted to implement it and it never happened. But I could be
mis-remembering. Maybe ask Olga, she's the one who put the bufsize
autotuning patch in, commit 96604398.
I'll go back through my old mail and see if I can figure out what happened
with this.
next prev parent reply other threads:[~2013-01-25 19:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-25 0:59 sunrpc: socket buffer size tuneable Ben Myers
2013-01-25 18:45 ` J. Bruce Fields
2013-01-25 19:10 ` Ben Myers
2013-01-25 18:57 ` J. Bruce Fields
2013-01-25 19:16 ` Jim Rees [this message]
2013-01-25 19:29 ` Ben Myers
2013-01-25 20:21 ` J. Bruce Fields
2013-01-25 20:35 ` Ben Myers
2013-01-25 21:12 ` Myklebust, Trond
2013-01-25 21:21 ` J. Bruce Fields
2013-01-25 21:29 ` Myklebust, Trond
2013-01-25 21:35 ` J. Bruce Fields
2013-01-25 21:45 ` Myklebust, Trond
2013-01-25 21:57 ` J. Bruce Fields
2013-01-25 22:02 ` Ben Myers
2013-01-25 22:20 ` Myklebust, Trond
2013-01-25 22:34 ` J. Bruce Fields
2013-01-25 23:00 ` Myklebust, Trond
2013-01-25 20:35 ` J. Bruce Fields
2013-01-25 20:51 ` J. Bruce Fields
2013-01-25 21:13 ` Ben Myers
2013-01-25 21:02 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130125191620.GA12925@umich.edu \
--to=rees@umich.edu \
--cc=aglo@citi.umich.edu \
--cc=bfields@fieldses.org \
--cc=bpm@sgi.com \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.