lkml.org 
[lkml]   [2010]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectPID_MAX_LIMIT limit on ia32?
From
Date
I have searched around without a definitive answer to my question.

PID_MAX_LIMIT is currently defined as:

/*
* A maximum of 4 million PIDs should be enough for a while.
* [NOTE: PID/TIDs are limited to 2^29 ~= 500+ million, see
futex.h.]
*/
#define PID_MAX_LIMIT (CONFIG_BASE_SMALL ? PAGE_SIZE * 8 :
(sizeof(long) > 4 ? 4 * 1024 * 1024 : PID_MAX_DEFAULT))


And PID_MAX_DEFAULT is normally 32k.

I found a comment on the net:

“When recycling PID numbers, the kernel must manage a
pidmap_array bitmap that denotes which are the PIDs currently
assigned and which are the free ones. Because a page frame
contains 32,768 bits, in 32-bit architectures the pidmap_array
bitmap is stored in a single page. In 64-bit architectures,
however, additional pages can be added to the bitmap when the
kernel assigns a PID number too large for the current bitmap
size. These pages are never released.”


Which may seem to indicate that PID_MAX_DEFAULT cannot be more than 1
memory page on 32bit archs.

Can the PID_MAX_LIMIT #define be increased safely on the ia32 arch which
would cause pidmap_array to use more than one memory page? (say 4 pages
or so).

I thought about just compiling it and testing things, but was unsure if
I would run into problems long-term.

[Please CC me on the response as I'm not currently subscribed]

TIA,
Davy

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

\
 
 \ /
  Last update: 2010-11-24 21:25    [W:0.041 / U:25.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site