lkml.org 
[lkml]   [2000]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PID Wrap <strangeness>
On Wed, 23 Feb 2000, Richard B. Johnson wrote:

> > On Tue, Feb 22, 2000 at 05:31:51PM -0500, Richard B. Johnson wrote:
> > > On Linux 2.3.41 (haven't checked others) when the PID wraps past
> > > 32,767 the next PID is 300. It is not the next-available low one.
> > >
> > > Does anybody know why?
> >
> > For speed, since a lot of pids lower than 300 are used by daemons,
> > there's no need to check them. This will speedup the get_pid
> > function after a wrap.
> >
> > me
> >
>
> The lowest numbered pid, not currently in use, can be readily obtained
> when a task exits. The task exit is currently the slowest thing to do
> because of the wait-for-status requirement. Adding a variable and
> a comparison at process exit would get the number for free.
>
> A hard-coded number of 300 is an eye-opener.

It is also kind of silly. The only PID that should probably be
left alone is 1. Perhaps below 10 as those seem to be kernel threads, but
300? On my systems when I upgrade daemons I tend to restart them, and so
they end up with a higher PID. When the machine is servicing other items
just fine there seems little reason to reboot the machine for a simple
upgrade to one of the daemons. In this situation (which would seem
reasonably common to me), the hardcoding to 300 doesn't actually get you
anything except less PID space.

Stephen


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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