lkml.org 
[lkml]   [2004]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: /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/

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.039 / U:0.420 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site