lkml.org 
[lkml]   [1998]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PID sequences
> From: "David S. Miller" <davem@dm.cobaltmicro.com>
> Date: Mon, 23 Feb 1998 17:17:03 -0800
> Subject: Re: PID sequences
>
> Date: Mon, 23 Feb 1998 17:49:07 -0500
> From: Jim Nance <jlnance@avanticorp.com>
>
> halfpint> bash -c 'for x in 1 2 3 4 5; do /bin/sh -c '\''echo $$'\''; done'
> 4476
> 4300
> 3707
> 4243
> 3843
>
> This looks almost random, and it does not seem to break anything.
> I just wanted to let people know that if we wanted to use some other
> scheme for generating PIDs, there is some precident for doing so.
>
> I did consider this issue when I was optimizing and making SMP safe
> the current PID allocation scheme. If the above you say is true,
> there is a fantastically efficient way we can allocate PIDs, and an
> entire SMP lock in fork.c is removed.
>
> Pass in the return value from find_empty_process() to get_pid() as
> it's second argument, remove all the existing code in that function,
> and the lastpid_lock, make it then:
>
> static int get_pid(unsigned long flags, int tslot_index)
> {
> if(flags & CLONE_PID)
> return current->pid;
> return tslot_index;
> }
>
> wheee... it should work, any brave testers out there? ;-))) For
> those of you brave enough, a before and after set of results for
> lat_proc from lmbench would be incredibly interesting.
>
> I think there would be only one last issue, 'last_pid'. Only
> fs/proc/array.c uses it, so maybe change the last line of get_pid()
> to:
>
> return last_pid = tslot_index;
>
> Comments?
>
> Later,
> David S. Miller
> davem@dm.cobaltmicro.com

We have recently ported from LynxOS. This is the only flavor of unices that I've worked with that reused PID's. I can tell you
that (although you wouldn't think it was a big deal) it can be a real pain. So unless there's an appreciable performance
increase, I'd vote against it...

Steve Suson
"Keep the faith."



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

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