[lkml]   [2006]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: pid_t range question
    "linux-os \(Dick Johnson\)" <> writes:

    > On Linux, type pid_t is defined as an int if you look
    > through all the intermediate definitions such as S32_T,
    > etc. However, it wraps at 32767, the next value being 300.
    > Does anybody know why it doesn't go to 0x7fffffff and
    > then wrap to the first unused pid value? I know the
    > code "reserves" the first 300 pids. That's not the
    > question. I wonder why. Also I see the code setting
    > the upper limit as well. I want to know why it is
    > set within the range of a short and is not allowed
    > to use the full range of an int. Nothing I see in
    > the kernel, related to the pid, ever uses a short
    > and no 'C' runtime interface limits this either!

    I have a vague memory about some old kernel interfaces
    where pid was a short. That said 32768 is also the number
    of bits in a page so it is a very good number for the bitmap
    allocator we currently have.

    I know for certain that proc assumes it can fit pid in
    the upper bits of an ino_t taking the low 16bits for itself
    so that may the entire reason for the limit.

    > Also, attempts to change /proc/sys/kernel/pid_max fail
    > if I attempt to increase it, but I can decrease it
    > to where I don't have enough pids available to fork()
    > the next command! Is this the correct behavior?

    You can increase pid_max if you have a 64bit kernel.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-02-07 23:19    [W:0.020 / U:8.680 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site