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"

Reply via email to