Linux – Why is the maximum PID in a 64-bit Linux system 2^22

linuxprocess

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

What is the maximum value of the Process ID?

Best Answer

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.

Related Question