Messages in this thread | | | Date | Tue, 24 Feb 1998 15:32:14 -0600 | From | Steven Suson <> | Subject | Re: 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
| |