concurrent sysctl implementation
ed at 80386.nl
Thu May 14 21:34:27 UTC 2009
* 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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090514/5df5fe94/attachment.pgp
More information about the freebsd-hackers