Messages in this thread | | | Subject | Re: pid_t range question | From | (Eric W. Biederman) | Date | Tue, 07 Feb 2006 15:16:28 -0700 |
| |
"linux-os \(Dick Johnson\)" <linux-os@analogic.com> 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.
Eric
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |