Re: idea to enhance get_pid()

Re: idea to enhance get_pid()

[Dan Kegel]

 	
 	
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dan Aloni wrote:
> The last time I checked, the only thing that stops the move back to
> 32-bit pids is a bug in the bash shell, and just a few workable IPC
> interfaces and libc breakages.

I'd like to know more about that bash bug; do you have a URL for it?
(Is there even a bug tracking system for bash?)
I looked a bit on gnu.bash.bugs, and found two possibly related
patches; do these have anything to do with the bug?
http://groups.google.com/groups?selm=200104130734.AAA12931%40shade.twinsun.com
http://groups.google.com/groups?selm=200104130854.BAA18368%40shade.twinsun.com

Thanks,
Dan

32-bit process ids (was: Re: idea to enhance get_pid())

[Dan Aloni]

On Sat, 2002-04-20 at 20:50, Dan Kegel wrote:

> I'd like to know more about that bash bug; do you have a URL for it?
> (Is there even a bug tracking system for bash?)
> I looked a bit on gnu.bash.bugs, and found two possibly related
> patches; do these have anything to do with the bug?
> http://groups.google.com/groups?selm=200104130734.AAA12931%40shade.twinsun.com
> http://groups.google.com/groups?selm=200104130854.BAA18368%40shade.twinsun.com

In a post by Linus from 2 years ago, concerning the bash bug 
( http://lwn.net/2000/0120/a/lt-pid.html ), he also writes about
what holds from switching to 32 bit pids. and it's mainly 
because it's unclear about the way pids should be handled in 
a clustering environment.

According to the kernel patch made by the people at Cluster
Infrastructure ( http://ci-linux.sourceforge.net/ ), today 
it is clear that the upper 16 bits of the pid are used for the node
number. 

Linus should consider applying Andries Brouwer's patch from October:
( http://marc.theaimsgroup.com/?l=linux-kernel&m=100274734125520&w=2 )
This is really 2.5 material, but it slipped away for no apparent reason.

Re: 32-bit process ids (was: Re: idea to enhance get_pid())

[Eric Brunner-Williams in Portland Maine]

> According to the kernel patch made by the people at Cluster
> Infrastructure ( http://ci-linux.sourceforge.net/ ), today 
> it is clear that the upper 16 bits of the pid are used for the node
> number. 

This is the one thing I let through back in 1984. Nixdorff wanted to use
parts of the processID for processorID. Now I don't have my authors' copy
of XPG/1 CAE anymore, but I still have a lasting sense of chagrin that as
trivially exhausted resource as a pid had bits shaved off for mid-80s SMP
machines. Granted, our pid_t of the time was 16 bits, and an Intel HyperCube
made a big dent in the remaining bits-for-pid'ing, and current pid_t's on
32-bit boxen is is 32 bits, and MPP boxes are few and far between -- but
really large clusters are possible.

$.02

Eric

idea to enhance get_pid()

[lenny lv]

Hi there,

I've got an idea to speed up linux/kernel/fork.c/get_pid(). Why not use 
bitmap to alloc/free the pids? Is it because 4KB(32K/8) memory scanning is 
slower than the current get_pid() version? Does anyone benchmark them?

Thanks,
Lenny

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

Re: idea to enhance get_pid()

[Dan Aloni]

On Sat, 2002-04-20 at 12:15, lenny lv wrote:

> I've got an idea to speed up linux/kernel/fork.c/get_pid(). Why not use 
> bitmap to alloc/free the pids? Is it because 4KB(32K/8) memory scanning is 
> slower than the current get_pid() version? Does anyone benchmark them?

This could have been a good idea if Linux was to stay with 15-bit pids
forever. The code you are suggesting will have to be rewritten sometime
to support 32 bit pids. 

The last time I checked, the only thing that stops the move back to
32-bit pids is a bug in the bash shell, and just a few workable IPC
interfaces and libc breakages.

Are 32 bit pids planned for 2.5?