Date: Wed, 26 Jan 2011 21:19:15 +0000 From: "Robert N. M. Watson" <rwatson@freebsd.org> To: mdf@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: <D7364835-5441-4C0E-8CA0-A82C2F99441A@freebsd.org> In-Reply-To: <AANLkTim3M7GzNmV-M9%2BPhtVRv5EK3u9AsPz=YaESv7y5@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26 Jan 2011, at 21:14, mdf@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. >=20 > 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. >=20 > 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. Robert=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D7364835-5441-4C0E-8CA0-A82C2F99441A>