Messages in this thread | | | Date | Sun, 12 Sep 2004 16:06:17 -0700 | From | William Lee Irwin III <> | Subject | Re: /proc/sys/kernel/pid_max issues |
| |
On Sun, Sep 12, 2004 at 10:13:19AM -0700, William Lee Irwin III wrote: >> I presumed it was merely cosmetic, so daemons around system startup >> will get low pid numbers recognizable by sysadmins. Maybe filtering >> process listings for pids < 300 is/was used to find daemons that may >> have crashed? I'm not particularly attached to the feature, and have >> never used it myself, but merely noticed its implementation was off.
On Sun, Sep 12, 2004 at 11:02:29AM -0700, Chris Wedgwood wrote: > I always assumed it was an optimization when looking for a new PID > after a wrap by trying to skip over the kernel threads. Arguably 300 > is way too small for larger systems (which might have several thousand > kernel threads) and should probably be sized on boot (or when starting > userspace) if anyone really cares.
There's no reason it couldn't be made tunable, though we may want to place restrictions on what values are allowed, e.g. reserved_pids > 0 and reserved_pids < min(BITS_PER_PAGE, pid_max). For that matter, we should likely be using proc_dointvec_minmax() for pid_max or otherwise a custom strategy function if we need to update bounds on reserved_pids and/or reserved_pids in tandem. I suspect this is obscure enough I should leave it alone unless someone develops a strong opinion about it.
-- wli - 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/
| |