27

Why not 2^62, or 2^31 or anything else?

What is the maximum value of the Process ID?

Community
  • 1
grandma
  • 273
  • 2
    It is? What's your source? – muru Sep 24 '15 at 04:16
  • http://unix.stackexchange.com/questions/16883/what-is-the-maximum-value-of-the-pid-of-a-process – grandma Sep 24 '15 at 04:22
  • That's very specific to Linux. It does not apply to Unix in general. – muru Sep 24 '15 at 04:24
  • I would have preferred using a full 64 bit integer, that way you could guarantee than they never get reused. Reuse leads to race conditions where the meaning of an ID changes between the time you obtain it and use it. – CodesInChaos Sep 24 '15 at 12:37

1 Answers1

41

It seems to be a purely arbitrary choice. It could be anything, but somebody1 felt 4 million is enough. Use the source:

/*
 * A maximum of 4 million PIDs should be enough for a while.
 * [NOTE: PID/TIDs are limited to 2^29 ~= 500+ million, see futex.h.]
 */
#define PID_MAX_LIMIT (CONFIG_BASE_SMALL ? PAGE_SIZE * 8 : \
    (sizeof(long) > 4 ? 4 * 1024 * 1024 : PID_MAX_DEFAULT))

The history on git only seems to go back as far as 2005, and the value has been that at least as long.

1The manpage says that /proc/sys/kernel/pid_max was added in 2.5.34, and looking at the changelog, it looks like the somebody was Ingo Molnár:

<mingo@elte.hu>
    [PATCH] pid-max-2.5.33-A0

    This is the pid-max patch, the one i sent for 2.5.31 was botched.  I
    have removed the 'once' debugging stupidity - now PIDs start at 0 again.
    Also, for an unknown reason the previous patch missed the hunk that had
    the declaration of 'DEFAULT_PID_MAX' which made it not compile ...

However, Ingo only added DEFAULT_PID_MAX. PID_MAX_LIMIT was added by Linus Torvalds in 2.5.37:

<torvalds@home.transmeta.com>
    Make pid_max grow dynamically as needed.

Turns out, I misread the changelog.

The changes are in the 2.5.37 patchset:

diff -Nru a/include/linux/threads.h b/include/linux/threads.h
--- a/include/linux/threads.h   Fri Sep 20 08:20:41 2002
+++ b/include/linux/threads.h   Fri Sep 20 08:20:41 2002
@@ -17,8 +17,13 @@
 #define MIN_THREADS_LEFT_FOR_ROOT 4

 /*
- * This controls the maximum pid allocated to a process
+ * This controls the default maximum pid allocated to a process
  */
-#define DEFAULT_PID_MAX 0x8000
+#define PID_MAX_DEFAULT 0x8000
+
+/*
+ * A maximum of 4 million PIDs should be enough for a while:
+ */
+#define PID_MAX_LIMIT (4*1024*1024)

 #endif

That's as far as my search skills get me.

Thanks to @hobbs, it seems Ingo is the somebody after all. The patch I quoted above was first sent by him. From the LKML post accompanying it:

memory footprint of the new PID allocator scales dynamically with /proc/sys/kernel/pid_max: the default 32K PIDs cause a 4K allocation, a pid_max of 1 million causes a 128K footprint. The current absolute limit for pid_max is 4 million PIDs - this does not cause any allocation in the kernel, the bitmaps are demand-allocated runtime. The pidmap table takes up 512 bytes.

There was a heated discussion about having higher limits, but it seems nothing came out of it in the end.

muru
  • 72,889
  • 3
    You can get a git repo with a deeper history of Linux, suitable for archaeology, using the instructions at http://stackoverflow.com/questions/3264283/linux-kernel-historical-git-repository-with-full-history . That turns up a5b5f6a "[PATCH] generic-pidhash-2.5.36-J2, BK-curr" by Ingo Molnar, viewable here on LWN. – hobbs Sep 24 '15 at 07:43
  • @hobbs awesome! So it is from Ingo Molnar after all. I wonder why Linus took ownership in the changelog. – muru Sep 24 '15 at 07:44
  • 1
    @muru: I believe BitKeeper doesn't support the distinction between committer and author, that was one of the lessons Linus applied when he designed Git. IIRC, Ingo refused to use BitKeeper, so he sent patches per mail, and they got misattributed in the auto-generated ChangeLogs to the committer, because BitKeeper has no separate notion of authorship. That's my guess anyway. – Jörg W Mittag Sep 24 '15 at 08:38
  • @JörgWMittag possible. Now I'm thinking I misread the changelog and that bit might be about a different patch. – muru Sep 24 '15 at 08:40
  • 4
    The quote near the end of this answer indicates that the reason for not picking an arbitrarily large value is memory constraints. At 128 KB RAM per 1M PIDs, using even 63 bits (leaving the sign bit) would, if I didn't botch the math, require a million TB of RAM for just the PID table. A little on the high side for current systems. – user Sep 24 '15 at 13:04
  • @MichaelKjörling there was plenty of argument on LKML about that. An immediate reply by Andries Brouwer said using a 2^30 shouldn't be a problem. I'd botched the link to the LKML post in the answer, and fixed it now. Have a read! – muru Sep 24 '15 at 13:09