Re: pid_t range question

[ebiederm@xmission.com (Eric W. Biederman)]

Ulrich Drepper <drepper@gmail.com> writes:

> On 2/7/06, Eric W. Biederman <ebiederm@xmission.com> wrote:
>> 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.
>
> Is this still the case?  For the 100,000 threads tests Ingo and I were
> running Ingo certainly came up with some patches to make /proc behave
> better.  This was before we had subdirs for thread groups.

It isn't too hard to change but it is still the case.  Truth is proc
really doesn't use inodes internally it is just a reporting thing.
So /proc will work but user space might get terribly confused.

> Anyway, I think we should put a reasonable top on the number of bits
> for the PIDs.  One reason is that the current (and fastest) design for
> more complex mutexes needs to encode more information than the PID in
> an 'int'.  See the latest robust mutex patches for an example.  If the
> limit could be, say, 28 bits that would still enable using more
> processes and threads then anybody wants so far.  Who know, when we
> hit this limit, maybe we have separate namespaces.  If not, we can
> still fix the existing limits but this would come at a cost which is
> why I think it's not worth doing now.

>From 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:
>  */
> #define PID_MAX_LIMIT (CONFIG_BASE_SMALL ? PAGE_SIZE * 8 : \
> 	(sizeof(long) > 4 ? 4 * 1024 * 1024 : PID_MAX_DEFAULT))
> 

So I think as long as this is a kernel implementation things should work ok.
I hate to have user space make assumptions about how many bits are in a pid
though.

Eric