On Wed, Jan 26, 2011 at 1:10 PM, Robert N. M. Watson
> On 26 Jan 2011, at 18:29, mdf@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
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.