From owner-freebsd-current@FreeBSD.ORG Thu Mar 4 05:07:40 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 508F516A4CE; Thu, 4 Mar 2004 05:07:40 -0800 (PST) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81D4743D31; Thu, 4 Mar 2004 05:07:39 -0800 (PST) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i24D7P7E004328; Thu, 4 Mar 2004 05:07:32 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200403041307.i24D7P7E004328@gw.catspoiler.org> Date: Thu, 4 Mar 2004 05:07:25 -0800 (PST) From: Don Lewis To: bde@zeta.org.au In-Reply-To: <20040304224900.K8400@gamplex.bde.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 13:07:40 -0000 On 4 Mar, Bruce Evans wrote: > 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). 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. >> 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. 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. The handler might be in a better position to retry after the data changes. For instance, sysctl_handle_opaque() has its own retry mechanism, but I just noticed that it doesn't return an error if it gets preempted too many times. Try the following patch: Index: sys/vm/vm_mmap.c =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_mmap.c,v retrieving revision 1.180 diff -u -r1.180 vm_mmap.c --- sys/vm/vm_mmap.c 27 Feb 2004 22:02:15 -0000 1.180 +++ sys/vm/vm_mmap.c 4 Mar 2004 13:04:43 -0000 @@ -926,7 +926,7 @@ return (EINVAL); if (atop(size) + cnt.v_wire_count > vm_page_max_wired) - return (EAGAIN); + return (ENOMEM); PROC_LOCK(proc); if (size + ptoa(pmap_wired_count(vm_map_pmap(&proc->p_vmspace->vm_map))) >