Re: Call for testers: New PID allocator patch for -CURRENT

From: David Schultz <das_at_FreeBSD.ORG>
Date: Thu, 29 Jan 2004 12:04:42 -0800
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.


[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.
Received on Thu Jan 29 2004 - 11:05:02 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:40 UTC