From owner-freebsd-current@FreeBSD.ORG Thu Mar 4 06:41:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92DCE16A4CE; Thu, 4 Mar 2004 06:41:39 -0800 (PST) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7B2A43D45; Thu, 4 Mar 2004 06:41:36 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i24EfZnX012672; Fri, 5 Mar 2004 01:41:35 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i24EfXsJ011749; Fri, 5 Mar 2004 01:41:34 +1100 Date: Fri, 5 Mar 2004 01:41:32 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Don Lewis In-Reply-To: <200403041307.i24D7P7E004328@gw.catspoiler.org> Message-ID: <20040305012433.B9033@gamplex.bde.org> References: <200403041307.i24D7P7E004328@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: rwatson@freebsd.org Subject: Re: sysctl spinning (was: Re: ps Causes Hard Hang) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2004 14:41:39 -0000 On Thu, 4 Mar 2004, Don Lewis wrote: > I just checked the mlock() man page in the Single UNIX Specification > Version 3. Our mlock() implementation is broken. We should be > returning ENOMEM here, though this will result in some sort of user > visible sysctl breakage instead of a tight loop. POSIX is more authoritative. It says that ENOMEM may be returned if an implementation-defined limit would be exceeded, and that EAGAIN shall be returned if some or all of the memory could not be locked when the call was made. So it literally requires returning EAGAIN even when the limit would be exceeded, but it doesn't mean to require that. > > I think EAGAIN was only meant for retrying after transient changes > > to the data. > > I think there may be legitimate cases where our memory wiring > implementation would legitimately want to return EAGAIN and not cause a > tight loop, but there is currently no way to distinguish this from the > case that you mention. I think it should return EAGAIN except when certain limits including the rlimit would be exceeded. The rlimit is often large or infinity, so it must be easy to exceed the system-wide limit if lots of processes uses locked memory. Perhaps every process should be guaranteed a few pages of locked memory so that most systctls always work. This is like guaranteeing that a minimum number of files (20 or so) can be opened, but I don't believe we even guarantee that, especially when the files are pipes wanting 64K of wired memory each. Bruce