Re: pid_t range question

[Eric W. Biederman]

David Lang <dlang@xxxxxxxxxxxxxxxxxx> writes:

> On Fri, 10 Feb 2006, Jan Engelhardt wrote:
>
>>> Any of those 3 scheemes should keep pids below 6 digits as much as
>>> possible. We can still hit the cosmetic problem on boxes where more
>>> than 99999 processes are actually running at the same time, but most
>>> users will never encounter that.
>>>
>> I'd say let's remain doing whatever we're doing now. That is, a maximum of
>> 32768 concurrent pids, and whoever needs more (e.g. Sourceforge shell,
>> etc.) can always raise it to their needs.
>
> when you say 'continue doing what we are doing now' do you mean to include the
> hard-coded limit of 32K pids? or do you mean to not worry about the cosmetic
> issue and change the code to not hard-code the limit, but instead honor a
> max_pid >32K?

We actually do honor a max_pid > 32K but only if we are 64bit.

We need to fix /proc and resolve the issue that 32K pids takes about 320M
of RAM.  Which is 1/2 to 1/3 of all of low memory, on a 32bit box, if
we want a hight max_pid than 32K.  Of course 32K is also a very nice
number for the pid bitmap allocator as it is only 1 page.

With about 80K task structures+stack the machine goes 00M, because you
have exhausted all of low memory.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/