| 1 |
On 9/16/06, darren kirby <bulliver@×××××××××××.org> wrote: |
| 2 |
> # sysctl -p |
| 3 |
> error: "Invalid argument" setting key "kernel.pid_max" |
| 4 |
|
| 5 |
You can find the answer in /usr/include/linux/threads.h. |
| 6 |
PID_MAX_DEFAULT is defined as 0x8000 (32768) for most systems, and |
| 7 |
PID_MAX_LIMIT is set to 4194304 *if* longs are larger than 4 bytes, or |
| 8 |
PID_MAX_DEFAULT otherwise. |
| 9 |
|
| 10 |
So if you are on a 32-bit system, you cannot set pid_max any larger |
| 11 |
than PID_MAX_DEFAULT. |
| 12 |
|
| 13 |
As far as "cool" factor goes, I don't see any coolness there. All |
| 14 |
that really happens when setting this is that the kernel uses more |
| 15 |
memory for the process table, and it takes longer for the process IDs |
| 16 |
to wrap. But unless you really need to run more than 32k processes at |
| 17 |
the same time, all you are really doing is wasting memory by |
| 18 |
increasing this. |
| 19 |
|
| 20 |
> Also, assuming you can help me get this sorted does anyone know which programs |
| 21 |
> this may break? |
| 22 |
|
| 23 |
Well anything compiled assuming pid_t was an unsigned 16-bit integer |
| 24 |
value would probably crash. This is probably unlikely....pid_t is |
| 25 |
defined as an int, or a signed 32-bit value on any platform that |
| 26 |
matters today. But if you've got some ancient programs hanging around |
| 27 |
or that you brought over from another system, they could have a |
| 28 |
problem. |
| 29 |
|
| 30 |
-Richard |
| 31 |
-- |
| 32 |
gentoo-user@g.o mailing list |
Archives