linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Neil Brown <neilb@suse.de>
Cc: Steve Dickson <steved@redhat.com>, linux-nfs@vger.kernel.org
Subject: Re: [PATCH 3/3] gssd: base the size of the fd array on the RLIMIT_NOFILE limit.
Date: Wed, 28 Nov 2012 08:10:55 -0500	[thread overview]
Message-ID: <20121128131054.GB11651@fieldses.org> (raw)
In-Reply-To: <20121128011123.2475.13691.stgit@notabene.brown>

On Wed, Nov 28, 2012 at 12:11:23PM +1100, Neil Brown wrote:
> We have previously raised the size of the 'pollarray' once (32 -> 256)
> and I have had another request to make it bigger.
> Rather than changing the hard-coded value, make it depend on
> RLIMIT_NOFILE.  This is an upper limit on the size of the array
> that can be passed to poll() anyway.

Sounds like a good idea.

Just out of curiosity: how does it fail?  I guess mounts just start
failing at some point--how do people find the workaround?

--b.

> 
> Signed-off-by: NeilBrown <neilb@suse.de>
> ---
>  utils/gssd/gssd_proc.c |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/utils/gssd/gssd_proc.c b/utils/gssd/gssd_proc.c
> index 425b582..e32b2f0 100644
> --- a/utils/gssd/gssd_proc.c
> +++ b/utils/gssd/gssd_proc.c
> @@ -52,6 +52,7 @@
>  #include <sys/socket.h>
>  #include <arpa/inet.h>
>  #include <sys/fsuid.h>
> +#include <sys/resource.h>
>  
>  #include <stdio.h>
>  #include <stdlib.h>
> @@ -483,9 +484,13 @@ fail_keep_client:
>  void
>  init_client_list(void)
>  {
> +	struct rlimit rlim;
>  	TAILQ_INIT(&clnt_list);
>  	/* Eventually plan to grow/shrink poll array: */
>  	pollsize = FD_ALLOC_BLOCK;
> +	if (getrlimit(RLIMIT_NOFILE, &rlim) < 0 &&
> +	    rlim.rlim_cur != RLIM_INFINITY)
> +		pollsize = rlim.rlim_cur;
>  	pollarray = calloc(pollsize, sizeof(struct pollfd));
>  }
>  
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2012-11-28 13:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-28  1:11 [PATCH 0/3] Make size of gssd_proc fd array a little more dynamic Neil Brown
2012-11-28  1:11 ` [PATCH 1/3] gssd_proc: use pollsize, not FD_ALLOC_BLOCK, in get_poll_index() Neil Brown
2012-11-28  1:11 ` [PATCH 2/3] gssd_proc: remove pointless test against FD_ALLOC_BLOCK in process_pipedir Neil Brown
2012-11-28  1:11 ` [PATCH 3/3] gssd: base the size of the fd array on the RLIMIT_NOFILE limit Neil Brown
2012-11-28 13:10   ` J. Bruce Fields [this message]
2012-11-29  0:30     ` NeilBrown
2012-12-11  0:02       ` NeilBrown
2012-12-11 16:16         ` J. Bruce Fields
2012-12-13  6:03           ` NeilBrown
2012-12-13 19:21             ` J. Bruce Fields
2012-11-28 19:54 ` [PATCH 0/3] Make size of gssd_proc fd array a little more dynamic Steve Dickson

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=20121128131054.GB11651@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=steved@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).