From owner-svn-src-all@FreeBSD.ORG Wed Jan 26 21:10:11 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 414E3106564A; Wed, 26 Jan 2011 21:10:11 +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 176C58FC14; Wed, 26 Jan 2011 21:10:11 +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 8ABEB46B03; Wed, 26 Jan 2011 16:10:09 -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:10:07 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <161C86E9-A24C-4E71-90C6-26C3B47ACC1B@freebsd.org> References: <201101251739.p0PHdqKX044842@svn.freebsd.org> <12EB1BEA-F0AF-4B2A-AFEB-9C38C7994FA8@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:10:11 -0000 On 26 Jan 2011, at 18:29, mdf@FreeBSD.org wrote: >> I suppose an important question is now often we see this actually = failing >=20 > 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. Robert=