Messages in this thread | | | Subject | PID_MAX_LIMIT limit on ia32? | From | Davy Durham <> | Date | Wed, 24 Nov 2010 14:22:37 -0600 |
| |
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/
| |