Date: Thu, 4 Mar 2004 05:07:25 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: bde@zeta.org.au Cc: rwatson@FreeBSD.org Subject: Re: sysctl spinning (was: Re: ps Causes Hard Hang) Message-ID: <200403041307.i24D7P7E004328@gw.catspoiler.org> In-Reply-To: <20040304224900.K8400@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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))) >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403041307.i24D7P7E004328>