* John Baldwin <j...@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 <e...@80386.nl> WWW: http://80386.nl/
pgpoN9a9RYCSv.pgp
Description: PGP signature
