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

Part Number: EVMK2H

Tool/software: Linux

Hello,

We are using a EVMK2H REV4.0 board with SDK ti-processor-sdk-linux-k2hk-evm-03.02.00.05-Linux-x86.

We submitted an earlier question regarding a limit we ran against in creating threads within a single root process, where we were

limited to creating 509 threads.  It turns out the issue is not related to virtual memory.

We traced that the problem is related to the fact that we are running our thread creation program under a root ssh shell.
It turns out that we are being limited by a pids cgroup limit associated with dropbear.
We found that if we set the dropbear entry that is created under /sys/fs/cgroup/pids/system.slice/system-dropbear.slice to "max" we are then able to create thousands of threads.


Example:  In this example the pid of our ssh session was 46408.  If we execute the following command:
    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
we are then able to create the number of threads we need.

Before we make the change the pids.max limit for this entry is 512.
So far we have been unable to find out how to change this default value.

How can this default value of 512 be changed?

If necessary I can post this to the Linux group as well but it seems closely related to the k2hk-evm SDK.

All help is appreciated.

Thank you,

Bob

  • 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

     


     Please make sure you read the forum guidelines first.

  • In reply to Yordan Kovachev:

    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
  • In reply to Bob Lewis:

    Hi Bob,

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

    Best Regards,
    Yordan

     


     Please make sure you read the forum guidelines first.

  • In reply to Bob Lewis:

    Hi Bob,

    I am still looking if there is anything limiting the number of threads, upon starting the service..

    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


    As a workaround, have you tried creating a service file which sets the number of pids you need? See how a systemd service is created here:
    e2e.ti.com/.../561065
    This way the service will configure:
    echo "number_of_pids" > /sys/fs/cgroup/pids/system.slice/system-dropbear.slice/dropbear@0-10.10.10.24:22-10.10.10.2:46408.service/pids.max
    On each kernel bootup.

    Best Regards,
    Yordan

     


     Please make sure you read the forum guidelines first.