From owner-freebsd-current@FreeBSD.ORG Thu Mar 4 01:42:29 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 A1B9016A4CE; Thu, 4 Mar 2004 01:42:29 -0800 (PST) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5DCF43D1F; Thu, 4 Mar 2004 01:42:27 -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 i249gI7E003684; Thu, 4 Mar 2004 01:42:22 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200403040942.i249gI7E003684@gw.catspoiler.org> Date: Thu, 4 Mar 2004 01:42:18 -0800 (PST) From: Don Lewis To: rwatson@FreeBSD.org In-Reply-To: <200403040938.i249cU7E003667@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@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 09:42:29 -0000 On 4 Mar, Don Lewis wrote: > On 3 Mar, Robert Watson wrote: >> >> On Wed, 3 Mar 2004, Cy Schubert wrote: >> >>> I'm running 5 -CURRENT systems. My firewall system, using IPF, hard >>> hangs every time ps is entered -- totally unresponsive, requiring either >>> a power cycle or reset switch to bring it back to life. >>> >>> Before I start digging into this seriously I'd like to possibly get info >>> from anyone who may have experienced this before. >> >> Alan Cox and I have both experienced this -- it's actually only a hard >> hang if you're trying to use the syscons break to debugger, serial break >> to debugger can get into DDB fine. It looks like the sysctl code is >> spinning in kernel, possibly due to looping waiting for a response other >> than EAGAIN. I'm wonder if it was the recent limits on locked memory >> changes in sysctl, although at first we thought it might be the sleepq >> changes (seems less likely now). Because sysctl holds Giant, the other >> CPUs are locked out of Giant-protected bits of the kernel (many of them), >> including Syscons. > > That sounds quite possible, though I would only expect it to happen if > userland passed a large output buffer to the sysctl call. In the > current implementation, EAGAIN will only be returned when this condition > is true: > > if (atop(size) + cnt.v_wire_count > vm_page_max_wired) > return (EAGAIN); > > 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. > > I think there are three problems here: > > vm_page_max_wired is probably the wrong value. I forgot to mention that before my commit to add the wired memory limit to the sysctl code, we blindly wired the requested amount of memory even if it was more that vm_page_max_wired.