Linux/EVMK2H: Max pthread_create() limit for root user process

Hi Bob,

Looking at the kernel sources (pid.c), you can see that the maximum pid is set as:
int pid_max = PID_MAX_DEFAULT;

Tracking further, you can see how PID_MAX_DEFAULT is set in include/linux/threads.h:
/*
* This controls the default maximum pid allocated to a process
*/
#define PID_MAX_DEFAULT (CONFIG_BASE_SMALL ? 0x1000 : 0x8000)

/*
* 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))

Then arch/arm/configs/tisdk_k2g-evm_defconfig sets CONFIG_BASE_SMALL=0, so the PID_MAX_DEFAULT is set to 0x8000.

From user space point of view, you can track the sysctl settings for pid_max:
sysctl kernel.pid_max

Hope this helps.

Best Regards,
Yordan

Hi Yordan,

Thank you much for your effort on this.
I don't think the issue I am having relates to the value of "pid_max" in the kernel source code.

Instead it has to do with the default setting given to the pid_max parameter under the dynamically created cgroup related to dropbear.

When I ssh to the EVMK2H arm processor the following entry is created under the cgroup/pids hierarchy:
/sys/fs/cgroup/pids/system.slice/system-dropbear.slice/dropbear@0-10.10.10.24:22-10.10.10.2:46408.service/pids.max

Note that the ip address portion (0-10.10.10.24:22-10.10.10.2) and the process id portion (46408) is unique to this session.

When the contents of this entry is examined it is found to be equal to 512.

$ cat /sys/fs/cgroup/pids/system.slice/system-dropbear.slice/dropbear@0-10.10.10.24:22-10.10.10.2:46408.service/pids.max
512

At this point if I run my thread create program the maximum number of threads it is able to create is 509.

If I change this value to a larger value, or "max", my thread create program is able to create many more threads.

$ echo "max" > /sys/fs/cgroup/pids/system.slice/system-dropbear.slice/dropbear@0-10.10.10.24:22-10.10.10.2:46408.service/pids.max

I was able to determine this was the issue by debugging the kernel, which led to this call trace:

do_fork() - /kernel/fork.c
_do_fork() - /kernel/fork.c
copy_process() - /kernel/fork.c
cgroup_can_fork() - /kernel/cgroup.c
pids_can_fork() - /kernel/cgroup_pids.c
pids_try_charge() - /kernel/cgroup_pids.c
return -EAGAIN

At this point I am trying to figure out if there is some configuration setting or something I can update such that when the dropbear cgroup entry is created such that the value of pids.max is set to a value of my choosing. So far I have been unable to determine how this can be done, but I do not think a change to kernel source code is required.

Thank you much,
Bob

Hi Bob,

Sorry for the delay. I'm looking into this.

Best Regards,
Yordan