From owner-svn-src-all@FreeBSD.ORG Wed Jan 26 23:41:18 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 6194B106566B; Wed, 26 Jan 2011 23:41:18 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id EB5358FC15; Wed, 26 Jan 2011 23:41:17 +0000 (UTC) Received: by iyb26 with SMTP id 26so936077iyb.13 for ; Wed, 26 Jan 2011 15:41:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=D37Jt+SkX27bIFkbKT6pt1W05jYEHnAJqz3d/MUIpRk=; b=v5ZGINwTcjP/YrimWN5WM899H35VeN8JmxFGa3pHDFMhW6gVSDC0vgV0wDRz1G4Npr vaml+bQvhe2N900TFncpN0DEBu2R60X/PVjsLSttC+UDpA5qLjv8dY/4UeLe0FkTPre2 KueTA/Fo/G7ue1HLF64unYgfqlTmwaktpIb04= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=TiUnggtdrZYitP8B2wwEXvF72LDT8/zoPDeVf3/Nwl83GOF6XG7v5jHEnJiuA06gDn W+Jaux2MJmaZcu4OnOnDNamRppAM5z3HKWIXYohYtWhNlFOfXlEoP8NAnOeixKtnsYcU gYVMkYP/eYrglpZcZLL8iwuByHOfQ2bExDhng= MIME-Version: 1.0 Received: by 10.231.31.131 with SMTP id y3mr71804ibc.179.1296085276931; Wed, 26 Jan 2011 15:41:16 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.231.160.147 with HTTP; Wed, 26 Jan 2011 15:41:16 -0800 (PST) In-Reply-To: References: <201101251739.p0PHdqKX044842@svn.freebsd.org> <12EB1BEA-F0AF-4B2A-AFEB-9C38C7994FA8@freebsd.org> <161C86E9-A24C-4E71-90C6-26C3B47ACC1B@freebsd.org> Date: Wed, 26 Jan 2011 15:41:16 -0800 X-Google-Sender-Auth: yTP2uW50pqvslJsIZCkVI04WEPs Message-ID: From: mdf@FreeBSD.org To: "Robert N. M. Watson" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 23:41:18 -0000 On Wed, Jan 26, 2011 at 1:19 PM, Robert N. M. Watson 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