On Wed, Jan 26, 2011 at 1:19 PM, Robert N. M. Watson <rwat...@freebsd.org> wrote: > > On 26 Jan 2011, at 21:14, m...@freebsd.org wrote: > >>> 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. > > Right -- hence my concern about (a) appropriate documentation and (b) proper > error handling. The sbuf routine looks convenient, easy to use, and exactly > the semantic that I want in most cases. However, sometimes, it may silently > break based on something rather abstract getting "too big". We need users of > the KPI to be aware of that limitation and hence not use it when that could > occur, and when it does occur, generate a clear notice of some sort so that > it can be tracked down. >
Upon further consideration, I don't think sbuf_new_for_sysctl() should be doing the wire. Whether the buffer needs to be wired or not is up to the implementation of the individual sysctl; *most* of them will be holding a lock when doing sbuf_print, but there's no guarantee. It's simpler to just leave this in the hands of the implementor, and it also enables better error reporting. Thanks, matthew _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"