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
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?
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
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.
> 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