From: Mike Travis <travis@sgi.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>
Cc: Pavel Machek <pavel@ucw.cz>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Greg KH <gregkh@suse.de>, Rik van Riel <riel@redhat.com>,
John Stoffel <john@stoffel.org>, Hedi Berriche <hedi@sgi.com>,
Jack Steiner <steiner@sgi.com>,
Andrew Morton <akpm@linux-foundation.org>,
Robin Holt <holt@sgi.com>, LKML <linux-kernel@vger.kernel.org>
Subject: [Patch 1/1] init: Increase pid_max based on num_possible_cpus v4
Date: Mon, 26 Apr 2010 17:42:00 -0700 [thread overview]
Message-ID: <4BD632D8.4040209@sgi.com> (raw)
In-Reply-To: <4BD5EDF9.6030504@sgi.com>
Subject: [Patch 1/1] init: Increase pid_max based on num_possible_cpus v4
From: Hedi Berriche <hedi@sgi.com>
On a system with a substantial number of processors, the early default pid_max
of 32k will not be enough. A system with 1664 CPU's, there are 25163 processes
started before the login prompt. It's estimated that with 2048 CPU's we will pass
the 32k limit. With 4096, we'll reach that limit very early during the boot cycle,
and processes would stall waiting for an available pid.
This patch increases the early maximum number of pids available, and increases
the minimum number of pids that can be set during runtime.
Signed-off-by: Hedi Berriche <hedi@sgi.com>
Signed-off-by: Mike Travis <travis@sgi.com>
Signed-off-by: Robin Holt <holt@sgi.com>
---
Version 4: Fix subject line
Version 3: Automatically increase pid_max based on number of cpus instead of
adding a cmdline option for the operator to set it.
---
include/linux/threads.h | 9 +++++++++
kernel/pid.c | 7 +++++++
2 files changed, 16 insertions(+)
--- linux-2.6.32.orig/include/linux/threads.h
+++ linux-2.6.32/include/linux/threads.h
@@ -33,4 +33,13 @@
#define PID_MAX_LIMIT (CONFIG_BASE_SMALL ? PAGE_SIZE * 8 : \
(sizeof(long) > 4 ? 4 * 1024 * 1024 : PID_MAX_DEFAULT))
+/*
+ * Define a minimum number of pids per cpu. Heuristically based
+ * on original pid max of 32k for 32 cpus. Also, increase the
+ * minimum settable value for pid_max on the running system based
+ * on similar defaults. See kernel/pid.c:pidmap_init() for details.
+ */
+#define PIDS_PER_CPU_DEFAULT 1024
+#define PIDS_PER_CPU_MIN 8
+
#endif
--- linux-2.6.32.orig/kernel/pid.c
+++ linux-2.6.32/kernel/pid.c
@@ -511,6 +511,13 @@ void __init pidhash_init(void)
void __init pidmap_init(void)
{
+ /* bump default and minimum pid_max based on number of cpus */
+ pid_max = min(pid_max_max, max(pid_max,
+ PIDS_PER_CPU_DEFAULT * num_possible_cpus()));
+ pid_max_min = max(pid_max_min,
+ PIDS_PER_CPU_MIN * num_possible_cpus());
+ pr_info("pid_max: default: %u minimum: %u\n", pid_max, pid_max_min);
+
init_pid_ns.pidmap[0].page = kzalloc(PAGE_SIZE, GFP_KERNEL);
/* Reserve PID 0. We never call free_pidmap(0) */
set_bit(0, init_pid_ns.pidmap[0].page);
next prev parent reply other threads:[~2010-04-27 0:42 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-21 1:40 [Patch 1/1] init: Provide a kernel start parameter to increase pid_max Mike Travis
2010-04-21 1:52 ` [Patch 1/1] init: Provide a kernel start parameter to increase pid_max v2 Mike Travis
2010-04-21 9:23 ` Alan Cox
2010-04-21 16:59 ` Hedi Berriche
2010-04-21 17:18 ` Rik van Riel
2010-04-21 17:54 ` Mike Travis
2010-04-21 19:14 ` John Stoffel
2010-04-21 19:33 ` Hedi Berriche
2010-04-21 20:10 ` John Stoffel
2010-04-21 22:24 ` Greg KH
2010-04-21 22:49 ` Rik van Riel
2010-04-21 23:22 ` Greg KH
2010-04-22 9:28 ` Alan Cox
2010-04-22 12:58 ` Jack Steiner
2010-04-22 13:57 ` Robin Holt
2010-04-22 14:48 ` Linus Torvalds
2010-04-22 17:08 ` Robin Holt
2010-04-22 18:10 ` John Stoffel
2010-04-22 20:35 ` Andrew Morton
2010-04-25 7:16 ` Pavel Machek
2010-04-25 17:15 ` Linus Torvalds
2010-04-25 17:27 ` Linus Torvalds
2010-04-25 12:13 ` Pavel Machek
2010-04-26 19:48 ` [Patch 1/1] init: Provide a kernel start parameter to increase pid_max v3 Mike Travis
2010-04-26 20:46 ` Greg KH
2010-04-27 0:43 ` Mike Travis
2010-04-27 0:42 ` Mike Travis [this message]
2010-04-21 17:58 ` [Patch 1/1] init: Provide a kernel start parameter to increase pid_max v2 Alan Cox
2010-04-21 19:12 ` Hedi Berriche
2010-04-21 19:51 ` Greg KH
2010-04-21 20:12 ` Hedi Berriche
2010-04-21 22:05 ` Jack Steiner
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=4BD632D8.4040209@sgi.com \
--to=travis@sgi.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=gregkh@suse.de \
--cc=hedi@sgi.com \
--cc=holt@sgi.com \
--cc=john@stoffel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pavel@ucw.cz \
--cc=riel@redhat.com \
--cc=steiner@sgi.com \
--cc=torvalds@linux-foundation.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 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).