Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 26 Jan 2011 16:56:23 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        mdf@freebsd.org
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, "Robert N. M. Watson" <rwatson@freebsd.org>
Subject:   Re: svn commit: r217830 - head/share/man/man9
Message-ID:  <201101261656.24021.jhb@freebsd.org>
In-Reply-To: <AANLkTim3M7GzNmV-M9%2BPhtVRv5EK3u9AsPz=YaESv7y5@mail.gmail.com>
References:  <201101251739.p0PHdqKX044842@svn.freebsd.org> <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 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
> <rwatson@freebsd.org> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201101261656.24021.jhb>