All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Ben Myers <bpm@sgi.com>
Cc: Olga Kornievskaia <aglo@citi.umich.edu>,
	linux-nfs@vger.kernel.org, Jim Rees <rees@umich.edu>
Subject: Re: sunrpc: socket buffer size tuneable
Date: Fri, 25 Jan 2013 15:21:07 -0500	[thread overview]
Message-ID: <20130125202107.GD29596@fieldses.org> (raw)
In-Reply-To: <20130125192935.GA32470@sgi.com>


> On Fri, Jan 25, 2013 at 01:29:35PM -0600, Ben Myers wrote:
> > Hey Bruce & Jim & Olga,
> > 
> > On Fri, Jan 25, 2013 at 02:16:20PM -0500, Jim Rees wrote:
> > > 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.
> > 
> > Years ago I did see wrapping of the buffer size when tcp was used with many
> > threads.  Today's problem is timeouts on a cluster with a heavy read
> > workload... and I seem to remember seeing that the send buffer size was too
> > small.
> > 
> > >   In which case the important variable here is lock_bufsize, as that's
> > >   what prevents the buffer size from going too low.
> > 
> > I tested removing the lock of bufsize and did hit the timeouts, so the overflow
> > is starting to look less relevant.  I will test your minimal overflow fix to
> > see if this is the case.
> 
> The minimal overflow fix did not resolve the timeouts.

OK, thanks, that's expected.

> I will test with this to see if it resolves the timeouts:

And I'd expect that to do the job--but at the expense of some tcp
bandwidth.  So you end up needing your other module parameters to get
the performance back.

--b.

> 
> ---
>  net/sunrpc/svcsock.c |    7 +++++++
>  1 file changed, 7 insertions(+)
> 
> Index: b/net/sunrpc/svcsock.c
> ===================================================================
> --- a/net/sunrpc/svcsock.c	2013-01-25 13:48:05.000000000 -0600
> +++ b/net/sunrpc/svcsock.c	2013-01-25 13:49:42.000000000 -0600
> @@ -435,6 +435,13 @@ static void svc_sock_setbufsize(struct s
>  	lock_sock(sock->sk);
>  	sock->sk->sk_sndbuf = snd * 2;
>  	sock->sk->sk_rcvbuf = rcv * 2;
> +
> +	/*
> +	 * The socket buffer can be resized by the networking code
> +	 * unless you specify that this is not to be done.
> +	 */
> +	sock->sk->sk_userlocks |= SOCK_SNDBUF_LOCK|SOCK_RCVBUF_LOCK;
> +
>  	sock->sk->sk_write_space(sock->sk);
>  	release_sock(sock->sk);
>  #endif
> 
> Thanks,
> Ben

  reply	other threads:[~2013-01-25 20:21 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
2013-01-25 19:29     ` Ben Myers
2013-01-25 20:21       ` J. Bruce Fields [this message]
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=20130125202107.GD29596@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=aglo@citi.umich.edu \
    --cc=bpm@sgi.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=rees@umich.edu \
    /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.