idea to enhance get_pid()

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?

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