All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH v4] tools/xenconsoled: Increase file descriptor limit
Date: Fri, 27 Feb 2015 16:26:36 +0000	[thread overview]
Message-ID: <54F09ABC.30208@citrix.com> (raw)
In-Reply-To: <21744.38837.455720.204222@mariner.uk.xensource.com>

On 27/02/15 16:13, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH v4] tools/xenconsoled: Increase file descriptor limit"):
>> XenServer's VM density testing uncovered a regression when moving from
>> sysvinit to systemd where the file descriptor limit dropped from 4096 to
>> 1024. (XenServer had previously inserted a ulimit statement into its
>> initscripts.)
>>
>> One solution is to use LimitNOFILE=4096 in xenconsoled.service to match the
>> lost ulimit, but that is only a stopgap solution.
>>
>> As Xenconsoled genuinely needs a large number of file descriptors if a large
>> number of domains are running, attempt to increase the limit.
> ...
>
> There's still a lot of code here I think we can do without.
>
> Why do we care about the system maximum ?

In the case that the system maximum is less than 132008 but greater than
the current hard limit, we want to grab as many FDs as we can.

I can drop it completely if you are happy that noone is really going to
xenconsoled on a Linux system with nr_open less than 1M.

>
>> +	/*
>> +	 * Will min_fds fit within our current hard limit?
>> +	 * (likely on *BSD, unlikely on Linux)
>> +	 * If so, raise our soft limit.
>> +	 */
>> +	if (min_fds <= lim.rlim_max) {
>> +		struct rlimit new = {
>> +			.rlim_cur = min_fds,
>> +			.rlim_max = lim.rlim_max,
>> +		};
>> +
>> +		if (setrlimit(RLIMIT_NOFILE, &new) < 0)
>> +			syslog(LOG_WARNING,
>> +			       "Unable to increase fd soft limit: %lu -> %u, "
>> +			       "hard %lu (%s) - May run out with lots of domains",
>> +			       lim.rlim_cur, min_fds, lim.rlim_max,
>> +			       strerror(errno));
>> +	} else {
>> +		/*
>> +		 * Lets hope that, as a root process, we have sufficient
>> +		 * privilege to up the hard limit.
>> +		 */
>> +		struct rlimit new = { .rlim_cur = min_fds, .rlim_max = min_fds };
>> +
>> +		if (setrlimit(RLIMIT_NOFILE, &new) < 0)
>> +			syslog(LOG_WARNING,
>> +			       "Unable to increase fd hard limit: %lu -> %u (%s)"
>> +			       " - May run out with lots of domains",
>> +			       lim.rlim_max, min_fds, strerror(errno));
>> +	}
> This is very repetitive.  The only difference between the two branches
> is (a) the value of .rlim_max and (b) the log message.  (b) can be
> dealt with by making the log message depend only on the contents of
> new.

I will see what I can do.

~Andrew

      reply	other threads:[~2015-02-27 16:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-27 16:04 [PATCH v4] tools/xenconsoled: Increase file descriptor limit Andrew Cooper
2015-02-27 16:13 ` Ian Jackson
2015-02-27 16:26   ` Andrew Cooper [this message]

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=54F09ABC.30208@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.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.