[Bug 222639] fork: Time it takes to allocate random PID approach infinity as num_processes approach PID_MAX (related to: sysctl kern.randompid)

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Sun Sep 9 20:16:21 UTC 2018


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222639

Conrad Meyer <cem at freebsd.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjoras at freebsd.org

--- Comment #2 from Conrad Meyer <cem at freebsd.org> ---
(In reply to Marie Helene Kvello-Aune from comment #0)

> Prequisite: Change how PIDs are tracked and allocated. Implement a bitmap of PIDs
> (I'm currently working on this) which is updated whenever anything in the PID
> namespace changes (a new PID/session ID/etc is created, or a PID/session ID/etc
> is considered available again).
> The bitmap should be an array of 4096 uint32_t where each bit represents a PID.
> A set (on) bit indicates an available PID.

IIRC, there was some earlier effort to bitmap-ify PIDs.  I'm not sure where
that went.  CC'ing Matt, who might remember if there is any work that can be
reused (or if I am misremembering and the work got committed already).

If not, we have some abstractions for bitmaps in the kernel already which
should probably be used in place of a raw u32 array — see BITSET(9) (if fixed
size is ok) or vmem(9) (which in spite of the name is actually a general
purpose allocater of integers in some range).  Apologies if you have already
thought of this or discovered it since the 2017-09 description I responded to
:-).

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list