In article <tkrhf5cmxd6.fsf@parity-error.sm.sony.co.jp>,
enami tsugutomo  <enami@sm.sony.co.jp> wrote:
> Jason R Thorpe <thorpej@zembu.com> writes:
> 
> > On Mon, Nov 13, 2000 at 12:34:28PM +1100, Simon Burge wrote:
> > 
> >  > How is proc address allocation done?  LRU?  Just thinking of repeating
> >  > monte carlo similutions that run in less than a second that do
> > 
> > Well, procs are allocated from a pool (pool_get()).  So, a new
> > proc is going to have the same address as the last one freed.
> 
> It's not a strict LRU.  The next one will be allocated from the
> ``curpage'' and a page the last one freed put back may be a different
> page than the ``curpage''.

Ick.

Increasing the PID space considerably just to have them repeat more
frequently seems...  bad.  Also, I suspect lots of software assumes PIDs
won't repeat for a while, either as in the example of srand(getpid()),
or by assuming entries for different program runs will be able to be
extracted from logfiles by pid, or in other ways. Also, lots of
sysadmins I'm sure have the same assumption that pids won't repeat for a
while. It could even mask problems (program keeps coring and restarting,
yet every time I do a ps or top updates, there it is with the same pid!)

Long PIDs are also a pain (from IRIX experience).  Just a few extra
digits make eyeball relational joins across logfiles and monitoring
screens much harder, a bad thing in an emergency. 

Short of getting some *major* win out of a pid rules change (like
implementing clustering and encoding a machine-within-cluser ID in the
upper 16 bits of a pid, as that fellow on tech-kern proposed) I
would like to see things stay just as they are.