Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 26 Jan 2011 15:41:16 -0800
From:      mdf@FreeBSD.org
To:        "Robert N. M. Watson" <rwatson@freebsd.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r217830 - head/share/man/man9
Message-ID:  <AANLkTinX5woy2kVo-gui9v2WQ=2LbTviJAa8aK9ET_10@mail.gmail.com>
In-Reply-To: <D7364835-5441-4C0E-8CA0-A82C2F99441A@freebsd.org>
References:  <201101251739.p0PHdqKX044842@svn.freebsd.org> <alpine.BSF.2.00.1101260929430.44308@fledge.watson.org> <AANLkTimqyPYah5=yWHVxf3Us4=cBYKGkb0oyAE%2B7R-%2Bt@mail.gmail.com> <12EB1BEA-F0AF-4B2A-AFEB-9C38C7994FA8@freebsd.org> <AANLkTimn0te0NKR%2BusYC6CzxUVVaP%2BnpZKstsw1mWC7o@mail.gmail.com> <161C86E9-A24C-4E71-90C6-26C3B47ACC1B@freebsd.org> <AANLkTim3M7GzNmV-M9%2BPhtVRv5EK3u9AsPz=YaESv7y5@mail.gmail.com> <D7364835-5441-4C0E-8CA0-A82C2F99441A@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 26, 2011 at 1:19 PM, Robert N. M. Watson
<rwatson@freebsd.org> wrote:
>
> On 26 Jan 2011, at 21:14, mdf@FreeBSD.org wrote:
>
>>> The kinds of cases I worry about are things like the tcp connection mon=
itoring sysctls. Most systems have a dozen, hundred, or a thousand connecti=
ons. Some have half a million or a million. If we switched to requiring wir=
ing every page needed to store that list, it would do terrible things to th=
e system. So really what I have in mind is: either we handle cases like tha=
t well, or we put in a clear warning and have obvious failure modes to catc=
h the cases where it didn't work out. In practice, I think we would not wan=
t 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 deb=
ug problems when they do arise.
>>
>> But I think that problem exists today using sysctl for output, since
>> it's non-iterative. =A0In 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) pro=
per error handling. The sbuf routine looks convenient, easy to use, and exa=
ctly the semantic that I want in most cases. However, sometimes, it may sil=
ently break based on something rather abstract getting "too big". We need u=
sers of the KPI to be aware of that limitation and hence not use it when th=
at could occur, and when it does occur, generate a clear notice of some sor=
t 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinX5woy2kVo-gui9v2WQ=2LbTviJAa8aK9ET_10>