Messages in this thread | | | Subject | Re: pid_t range question | From | (Eric W. Biederman) | Date | Wed, 15 Feb 2006 14:00:50 -0700 |
| |
David Lang <dlang@digitalinsight.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |