Date: Thu, 29 Jan 2004 12:04:42 -0800 From: David Schultz <das@FreeBSD.ORG> To: Xin LI <delphij@frontfree.net> Cc: junsu@delphij.net Subject: Re: Call for testers: New PID allocator patch for -CURRENT Message-ID: <20040129200442.GA52780@VARK.homeunix.com> In-Reply-To: <20040129134121.GB53644@frontfree.net> References: <20040129134121.GB53644@frontfree.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@ and hackers@ 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@ 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040129200442.GA52780>