concurrent sysctl implementation

[Ed Schouten]

* 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.

-- 
 Ed Schouten <ed at 80386.nl>
 WWW: http://80386.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090514/5df5fe94/attachment.pgp