Re: pid_t range question

[Ulrich Drepper <drepper@gmail.com>]

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.

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.
-
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/