svn commit: r217830 - head/share/man/man9

[mdf at FreeBSD.org]

On Wed, Jan 26, 2011 at 1:19 PM, Robert N. M. Watson
<rwatson at freebsd.org> wrote:
>
> On 26 Jan 2011, at 21:14, mdf at 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