On Wed, Jan 26, 2011 at 1:10 PM, Robert N. M. Watson <rwat...@freebsd.org> wrote: > > On 26 Jan 2011, at 18:29, m...@freebsd.org wrote: > >>> I suppose an important question is now often we see this actually failing >> >> I don't believe we've ever seen a memory failure relating to sysctls >> at Isilon and we've been using the equivalent of this code for a few >> years. Our machines aren't low memory but they are under memory >> pressure sometimes. > > The kinds of cases I worry about are things like the tcp connection > monitoring sysctls. Most systems have a dozen, hundred, or a thousand > connections. Some have half a million or a million. If we switched to > requiring wiring every page needed to store that list, it would do terrible > things to the system. So really what I have in mind is: either we handle > cases like that well, or we put in a clear warning and have obvious failure > modes to catch the cases where it didn't work out. In practice, I think we > would not want to switch the tcpcb/inpcb sysctl for this reason, but as > people say "ah, this is convenient" we need to make sure it's handled well, > and easy to debug problems when they do arise. >
But I think that problem exists today using sysctl for output, since it's non-iterative. In fact, it's often worse today, because in addition to the user-space buffer that needs to be large enough to hold the output, the kernel needs to malloc(9) a buffer to hold it before doing the one SYSCTL_OUT at the end that most routines I've seen use. For situations like this where there is a lot of output but it doesn't need to be serialized by a lock held across the whole data fetch, then yes, using sbuf_new_for_sysctl() would wire more memory. Thanks, matthew _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
