I understand the difference between
/proc/sys/kernel/threads-max. There's a good explanation at the answer to
Understanding the differences between pid_max, ulimit -u and thread_max:
/proc/sys/kernel/pid_maxhas nothing to do with the maximum number of processes that can be run at any given time. It is, in fact, the maximum numerical PROCESS IDENTIFIER than can be assigned by the kernel.
In the Linux kernel, a process and a thread are one and the same. They're handled the same way by the kernel. They both occupy a slot in the task_struct data structure. A thread, by common terminology, is in Linux a process that shares resources with another process (they will also share a thread group ID). A thread in the Linux kernel is largely a conceptual construct as far as the scheduler is concerned.
Now that you understand that the kernel largely does not differentiate between a thread and a process, it should make more sense that
/proc/sys/kernel/threads-maxis actually the maximum number of elements contained in the data structure task_struct. Which is the data structure that contains the list of processes, or as they can be called, tasks.
However, effectively, both limit the maximum number of concurrent threads on a host. This number will be - to my understanding - the minimum of
threads-max. So why are both needed?
I understand that the default value
pid_max is based on the number of possible CPUs of the machine while the default of
threads-max is derived from the number of pages. But since both have the same effect, couldn't Linux just have one value that would be the minimum of both?