Messages in this thread | | | Date | Mon, 23 Feb 1998 17:17:03 -0800 | From | "David S. Miller" <> | 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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |