From owner-freebsd-stable@FreeBSD.ORG Sat Feb 1 19:15:09 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5527A874 for ; Sat, 1 Feb 2014 19:15:09 +0000 (UTC) Received: from ln.servalan.com (ln.servalan.com [IPv6:2600:3c00::f03c:91ff:fe96:62f5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2B7FC1681 for ; Sat, 1 Feb 2014 19:15:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=servalan.com; s=rsadkim; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:From:References:Subject:Cc:To; bh=Yw4e7OS8LWbYk/beiYXnId3bAWJjHzp5stxjKzsY7JQ=; b=Qu8RNpCyP2M/KskIULtyiTuTW6ZTcmjESDX7REASGMHplBhXjy7x+mwnOnuAcrI7r+1qPC1Yz6np8VH+2lGd462mk2GWUvijdabq1zcJRObbWEo53BfqSnfwZ9mhxtaKQQI91zFT/FxU9736yvbCgtG1ZX+AApEMafGi++pMAeA=; Received: from uucp by ln.servalan.com with local-rmail (Exim 4.76) (envelope-from ) id 1W9g20-00017J-5V for freebsd-stable@freebsd.org; Sat, 01 Feb 2014 13:15:08 -0600 Received: from rmtodd by servalan.servalan.com with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1W9fqW-000B0K-He; Sat, 01 Feb 2014 13:03:16 -0600 To: Matthew Rezny Subject: Re: Tuning kern.maxswzone References: <20140201070912.00007971@unknown> From: Richard Todd Date: Sat, 01 Feb 2014 13:03:15 -0600 In-Reply-To: <20140201070912.00007971@unknown> (Matthew Rezny's message of "Sat, 1 Feb 2014 07:09:12 +0100") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.5-b28 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 19:15:09 -0000 Matthew Rezny writes: > So, as best I can tell, the actual effective number used for > kern.maxswzone is indeed approximately 8x available RAM. If there is > some need to turn it down (using substantially less swap) then that is > possible, but turning it up (as suggested by the warning message) is > not possible. Setting any value higher does not appear to actually Yeah, IIRC I ran into that when configing some VMs with really big swap space for benefit of tmpfs. This is the quick hack I used to get around that, you might give it a try. # HG changeset patch # Parent e4dd7df011139e2b224835aa6e330c90afcf9a55 patch swap_pager to unconditionally use maxswzone tunable if it is set -- helpful for our tbvm VMs with large swap space for tmpfs diff -r e4dd7df01113 sys/vm/swap_pager.c --- a/sys/vm/swap_pager.c Wed Feb 20 00:15:49 2013 -0600 +++ b/sys/vm/swap_pager.c Sat Feb 23 13:08:54 2013 -0600 @@ -546,7 +546,7 @@ * is typically limited to around 32MB by default. */ n = cnt.v_page_count / 2; - if (maxswzone && n > maxswzone / sizeof(struct swblock)) + if (maxswzone) n = maxswzone / sizeof(struct swblock); n2 = n; swap_zone = uma_zcreate("SWAPMETA", sizeof(struct swblock), NULL, NULL, Also, > With /usr/src cleared (and after running fsck) I booted back into > 10-PRERELEASE to try to fetch the 10-STABLE sources again. I started > svnlite co and find it hung shortly thereafter. I tried a few times but > each time I see it does a couple hundred files at best and just stops. > When it stops, I can't login to another terminal. If I have a spare > console logged in, I can't run anything. After a few tries, I manged to > catch it where I had top running in one VT, started the checkout, and > then switched back just in time. I never could even get top up with rm > running (it probably blows over some limit faster). When the checkout > hangs, the state of svnlite is "kmem a" according to top. I can only > guess that is short for kmem alloc, I guess some syscall is waiting on > an allocation that will never happen because something already is using > or has leaked everything that could satisfy that allocation. It looks > like activity on too many files within a short period runs something > out. No, it's just a new bit of debugging code that causes the system to spend lots of CPU time verifying integrity of some of its internal data structures, especially on wimpy hardware (e.g., my dual PII/400 box, which is where I noticed this recently.) You'll find if you're patient that it isn't a complete hang, it will actually get work done in between the debug passes. Set sysctl debug.vmem_check=0 to disable the check. This is I think completely independent from the maxswzone stuff, it's just you were seeing it for the first time since the debug code in question was only recently added to 10-STABLE. Richard