From owner-freebsd-current@FreeBSD.ORG Thu Mar 4 03:56:17 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 E806816A4CE; Thu, 4 Mar 2004 03:56:17 -0800 (PST) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8017043D1D; Thu, 4 Mar 2004 03:56:14 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i24BuCUe007545; Thu, 4 Mar 2004 22:56:12 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i24BuAsJ022722; Thu, 4 Mar 2004 22:56:11 +1100 Date: Thu, 4 Mar 2004 22:56:10 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Don Lewis In-Reply-To: <200403040938.i249cU7E003667@gw.catspoiler.org> Message-ID: <20040304224900.K8400@gamplex.bde.org> References: <200403040938.i249cU7E003667@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 11:56:18 -0000 On Thu, 4 Mar 2004, Don Lewis wrote: > Hmn, it looks like vm_page_max_wired is dynamically set to one third of > free system memory in vm_pageout(). > > /* XXX does not really belong here */ > if (vm_page_max_wired == 0) > vm_page_max_wired = cnt.v_free_count / 3; > > I was under the impression that it was one third of physical memory. The variable is only set on system startup, and then the free memory is not very different from physical memory (except on machines with too little memory, and then the free memory is even more relevant for setting memory limits). > Should the failure to wire the buffer be mapped to a different errno? I think so (at least for very large requests). > There may be cases when it is valid to retry the request. > > The code that loops on EAGAIN was added in the rev 1.63 of > kern_sysctl.c. I think EAGAIN was only meant for retrying after transient changes to the data. Bruce