On Thu, 29 Jan 2004, David Schultz wrote: > On Thu, Jan 29, 2004, Xin LI wrote: > > Greetings, everyone > > > > A friend of mine has ported NetBSD's new PID allocation[1] code to FreeBSD, > > you can obtain the patch here: > > > > http://www.arbornet.org/~junsu/pid.diff > > > > Some of you may be already aware of this for he has posted[2] this to both > > current_at_ and hackers_at_ last September. > > > > Currently the patchset has been updated to make it applicable to -HEAD. > > > > A number of problems were found and fixed after the first post with many > > from the FreeBSD community, and we think it's time to post it again and, > > if you are interested, please give it a chance to run on your own (test) > > box. > > Thanks for the reminder. Your patch uses a very clever idea. I > messed around with the original patch in your PR a few months ago. > It would take more work to prove that your proposed patch improves > performance[1] and is a good approach, and to review and clean up > the implementation. For instance, it isn't immediately obvious > that the accelerated pid reuse is acceptable, so that needs to be > looked into further[2]. I don't have the time at the moment to go > over the patch with a fine-toothed comb, and jhb_at_ could do a > better job than me anyway if he has time, but I wanted to let you > know that it's floating around on at least one person's TODO list. > > Some low-hanging fruit: The patch needs to be cleaned up to > conform to style(9). It also changes the meaning of PID_MAX and > fails to enforce a 5-digit limit on pids. I don't know if it is in the patch but we need a sysctl for pid_max because it needs to be set back to 60000 if yuo want to run a FreeBSD 1.x environment.. (you should see a make world fly on a 3GHz machine in a FreeBSD 1.1 chroot) > > [1] That shouldn't be hard, given that the present algorithm takes > O(N) amortized time in the worst case, and can examine as many > as PID_MAX^2 pids if the number of processes in the system is > close to PID_MAX. > > [2] Many systems have a high enough fork rate that pids recycle > every few minutes or hours with the present algorithm. These > systems don't necessarily have lots of processes running at any > given time, so the table (and thus the cycle length) in your > patch could remain relatively small if I'm interpreting the > code correctly. I think the code would have to be changed to > prevent reuse from happening too quickly in wall time. > _______________________________________________ > freebsd-hackers_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe_at_freebsd.org" >Received on Thu Jan 29 2004 - 13:04:48 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:40 UTC