concurrent sysctl implementation

[John Baldwin]

On Thursday 14 May 2009 5:34:26 pm Ed Schouten wrote:
> * John Baldwin <jhb at freebsd.org> wrote:
> > Well, in theory a bunch of "small" requests to SYSCTL_PROC() nodes that 
used 
> > sysctl_wire_old() (or whatever it is called) could cause the amount of 
user 
> > memory wired for sysctls to grow unbounded.  Thus, allowing this limited 
> > concurrency is a tradeoff as there is a minimal (perhaps only theoretical 
at 
> > the moment) risk of removing the safety net.
> > 
> > The patch is quite small, btw, because the locking for the sysctl tree 
already 
> > exists, and by using read locks, one can already allow concurrent sysctl 
> > requests.  There is no need to add any new locks or restructure the sysctl 
> > tree, just to adjust the locking that is already present.  It might be 
> > clearer, in fact, to split the sysctl memory lock back out into a separate 
> > lock.  This would allow "small" sysctl requests to run concurrently with a 
> > single "large" request whereas in my suggestion in the earlier e-mail, 
> > the "large" request will block all other user requests until it finishes.
> > 
> > I've actually gone ahead and done this below.
> 
> Boohoo. I actually wanted jt to work on this, as a small exercise to
> figure out the way locking primitives work in the kernel. No problem,
> because I can think of dozens of other things.
> 
> Is there a chance we can see this patch in 8.0? I like it that the
> memlock is being picked up before we pick up the sysctl lock itself,
> which makes a lot of sense.

Yes, I can commit it.

-- 
John Baldwin