From owner-svn-src-all@FreeBSD.ORG Wed Jan 26 21:19:19 2011 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DADE106564A; Wed, 26 Jan 2011 21:19:19 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E4A428FC1B; Wed, 26 Jan 2011 21:19:18 +0000 (UTC) Received: from [192.168.2.112] (host86-161-238-243.range86-161.btcentralplus.com [86.161.238.243]) by cyrus.watson.org (Postfix) with ESMTPSA id 7B13A46B29; Wed, 26 Jan 2011 16:19:17 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: Date: Wed, 26 Jan 2011 21:19:15 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201101251739.p0PHdqKX044842@svn.freebsd.org> <12EB1BEA-F0AF-4B2A-AFEB-9C38C7994FA8@freebsd.org> <161C86E9-A24C-4E71-90C6-26C3B47ACC1B@freebsd.org> To: mdf@FreeBSD.org X-Mailer: Apple Mail (2.1082) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r217830 - head/share/man/man9 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 21:19:19 -0000 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=