lkml.org 
[lkml]   [1998]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

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