这似乎是纯粹的任意选择。可以是任何东西，但有人1认为400万就足够了。使用来源：
/*
* 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))
git的历史似乎可以追溯到2005年，而且价值至少已经到了2005年。
1该联机帮助页说它/proc/sys/kernel/pid_max是在2.5.34中添加的，并查看更改日志，看起来有人是IngoMolná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 ...
但是，Ingo仅添加了DEFAULT_PID_MAX。PID_MAX_LIMIT是Linus Torvalds在2.5.37中添加的：
<torvalds@home.transmeta.com>
Make pid_max grow dynamically as needed.
原来，我误读了变更日志。
更改在2.5.37补丁集中：
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
这是我的搜索技能所能做到的。
多亏@hobbs，看来Ingo 毕竟是那个人。我上面引用的补丁是他首先发送的。从随附的LKML帖子中：
新的PID分配器的内存占用量可通过/ proc / sys / kernel / pid_max动态扩展：默认的32K PID产生4K分配，100万的pid_max导致128K占用。pid_max的当前绝对限制为4百万个PID-这不会在内核中引起任何分配，位图是按需分配的运行时。pidmap表占用512个字节。
对于更高的限制进行了激烈的讨论，但最终似乎没有任何结果。