svn commit: r280495 - head/sys/kern
Gleb Smirnoff
glebius at FreeBSD.org
Wed Mar 25 11:14:36 UTC 2015
On Wed, Mar 25, 2015 at 12:06:46PM +0100, Hans Petter Selasky wrote:
H> On 03/25/15 11:54, Gleb Smirnoff wrote:
H> > On Wed, Mar 25, 2015 at 08:55:35AM +0000, Hans Petter Selasky wrote:
H> > H> Author: hselasky
H> > H> Date: Wed Mar 25 08:55:34 2015
H> > H> New Revision: 280495
H> > H> URL: https://svnweb.freebsd.org/changeset/base/280495
H> > H>
H> > H> Log:
H> > H> Implement a simple OID number garbage collector. Given the increasing
H> > H> number of dynamically created and destroyed SYSCTLs during runtime it
H> > H> is very likely that the current new OID number limit of 0x7fffffff can
H> > H> be reached. Especially if dynamic OID creation and destruction results
H> > H> from automatic tests. Additional changes:
H> > H>
H> > H> - Optimize the typical use case by decrementing the next automatic OID
H> > H> sequence number instead of incrementing it. This saves searching time
H> > H> when inserting new OIDs into a fresh parent OID node.
H> > H>
H> > H> - Add simple check for duplicate non-automatic OID numbers.
H> >
H> > Why didn't you use alloc_unr(9) for that?
H> >
H>
H> Hi Gleb,
H>
H> I thought about using alloc_unr(). The problem is that sysctls have no
H> clear concept of freeing. For example in some existing code sysctl are
H> unregistered and registered again assuming that the oid_number will be
H> preserved. I didn't want touch those parts. Also, hence we are already
H> traversing a list to insert an SYSCTL object in an ordered fashion, the
H> benefit of alloc_unr() is not that big. What do you think?
Is it possible to split the space into two halves: one for static OIDs and
other for dynamic ones? The latter allocated via alloc_unr?
--
Totus tuus, Glebius.
More information about the svn-src-all
mailing list