On Thursday 14 May 2009 5:34:26 pm Ed Schouten wrote: > * 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.
Yes, I can commit it. -- John Baldwin _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
