Linuxeden开源社区
早在 2019 年，systemd 就默认增加了同时允许的最大进程 ID 数量的pid_max可调。但是，这一增加打破了某些用户空间软件长期以来的假设，即 pid_max 或进程 ID 不会大于 65,535。为了更好地解决此类过时的用户空间软件，Linux 6.14 内核的一组补丁将允许根据每个 PID 命名空间调整 pid_max 限制，以帮助应对此类软件达到此类人为限制，而不必降低整体系统限制。
Microsoft 的 Christian Brauner 在本周末 Linux 6.14 合并窗口打开之前发出了 PID 命名空间拉取请求。他解释了此更改的问题和动机，以允许基于每个 PID 命名空间设置 pid_max：
“pid_max sysctl 是一个全局值。长期以来，默认值一直是 65535，在 pidfd 讨论期间，Linus 建议默认 pid_max 碰撞。基于这个讨论，systemd 开始将 pid_max 提高到 2^22。因此，所有新系统现在都以非常高的 pid_max 限制运行，一些发行版也向后移植了该更改。撞pid_max的决定显然是正确的。现在强制执行如此低的 pid 数字已经没有多大意义了。有足够的工具可以选择特定的进程，而无需键入非常大的可用 pid 编号。
无论如何，有些工作负载对它们接受的 pid 数字有多大有 [期望]。要么是历史原因，要么是建筑原因。一个 [具体] 示例是 Android 的 32 位版本的 bionic libc，它要求 pid 编号小于 65536。在一些工作负载中，它在 64 位内核上的 32 位容器中运行。如果主机的 pid_max 值大于 65535，则 libc 将中止线程创建，因为大小假设为 pthread_mutex_t。
这是一个相当具体的用例，但是，通常，移动到在具有新内核和新 systemd 的主机上运行的容器中的特定工作负载可能会遇到 pid_max 值过大的问题。显然，对分配的 pid 的大小做出假设是次优的，但我们有可以做到这一点的用户空间。
当然，让容器能够通过 pid_max 限制其各自 pid 命名空间中的 [独立于] 全局限制的进程数量本身就是可取的，并且通常会派上用场。
除了激励用例之外，pid 命名空间的存在也使这也是一个很好的语义扩展，并且之前已经有提案朝着类似的方向发展。这里的诀窍是将回归的风险降至最低，我认为这是可行的。pid 命名空间是分层的这一事实将在这里帮助我们。
…
总而言之，这意味着 pid_max 继续对进程数量实施系统范围的限制，但允许 pid 命名空间在处理假设 pid 值的工作负载时有足够的回旋余地，并允许容器通过 pid_max 接口限制 pid 命名空间中的进程数。
此拉取请求中的更多详细信息。假设 Linus Torvalds 没有发现对更改的反对意见，它将成为即将到来的 Linux 6.14 合并窗口的一部分。
转自 Linux To Allow Adjusting pid_max Per PID Namespace – Helping Old Software – Phoronix