Messages in this thread | | | Date | Tue, 7 Feb 2006 16:19:56 -0800 | From | Ulrich Drepper <> | Subject | Re: pid_t range question |
| |
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/
| |