From owner-svn-src-all@FreeBSD.ORG Wed Jan 26 22:05:41 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 809DE1065670; Wed, 26 Jan 2011 22:05:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4DD988FC14; Wed, 26 Jan 2011 22:05:41 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id EE5CB46B2C; Wed, 26 Jan 2011 17:05:40 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1AC608A01D; Wed, 26 Jan 2011 17:05:40 -0500 (EST) From: John Baldwin To: mdf@freebsd.org Date: Wed, 26 Jan 2011 16:56:23 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <201101251739.p0PHdqKX044842@svn.freebsd.org> <161C86E9-A24C-4E71-90C6-26C3B47ACC1B@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101261656.24021.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 26 Jan 2011 17:05:40 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, "Robert N. M. Watson" 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 22:05:41 -0000 On Wednesday, January 26, 2011 4:14:15 pm mdf@freebsd.org wrote: > On Wed, Jan 26, 2011 at 1:10 PM, Robert N. M. Watson > wrote: > > > > 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 > seen use. Not always. I think in the case of the inpcb's what happens is that we hold enough references on objects that we can drop the locks while calling SYSCTL_OUT() without requiring us to 1) allocate a full duplicate of the buffer in KVM, or 2) wire the entire userland buffer. -- John Baldwin