From owner-freebsd-current@FreeBSD.ORG Tue May 19 01:57:14 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85E12106566B; Tue, 19 May 2009 01:57:14 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id 470328FC1B; Tue, 19 May 2009 01:57:13 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id 8387471F3EA; Mon, 18 May 2009 21:57:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGhWa6itjn4p; Mon, 18 May 2009 21:57:13 -0400 (EDT) Received: from localhost (daemon.egr.msu.edu [35.9.44.65]) by mx.egr.msu.edu (Postfix) with ESMTP id 6037671F3D6; Mon, 18 May 2009 21:57:13 -0400 (EDT) Received: by localhost (Postfix, from userid 21281) id 5C107743; Mon, 18 May 2009 21:57:13 -0400 (EDT) Date: Mon, 18 May 2009 21:57:13 -0400 From: Adam McDougall To: Kip Macy Message-ID: <20090519015713.GS82547@egr.msu.edu> References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> <20090519012202.GR82547@egr.msu.edu> <3c1674c90905181826p787a346cie90429324444a9c4@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3c1674c90905181826p787a346cie90429324444a9c4@mail.gmail.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: current@freebsd.org, Larry Rosenman Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Tue, 19 May 2009 01:57:14 -0000 On Mon, May 18, 2009 at 06:26:51PM -0700, Kip Macy wrote: On Mon, May 18, 2009 at 6:22 PM, Adam McDougall wrote: > On Mon, May 18, 2009 at 07:06:57PM -0500, Larry Rosenman wrote: > > ?On Mon, 18 May 2009, Kip Macy wrote: > > ?> The ARC cache allocates wired memory. The ARC will grow until there is > ?> vm pressure. > ?My crash this AM was with 4G real, and the ARC seemed to grow and grow, then > ?we started paging, and then crashed. > > ?Even with the VM pressure it seemed to grow out of control. > > ?Ideas? > > > Before that but since 191902 I was having the opposite problem, > my ARC and thus Wired would grow up to approx arc_max until my > Inactive memory put pressure on ARC making it shrink back down > to ~450M where some aspects of performance degraded. ?A partial > workaround was to add a arc_min which isn't entirely successful > and I found I could restore ZFS performance by temporarily squeezing > down Inactive memory by allocating a bunch of it myself; after > freeing that, ARC had no pressure and could grow towards arc_max > again until Inactive eventually rose. ?Reported to Kip last night > and some cvs commit lists. ?I never did run into Swap. > That is a separate issue. I'm going to try adding a vm_lowmem event handler to drive reclamation instead of the current paging target. That shouldn't cause inactive pages to shrink the ARC. Most people consider out of the box stability more import than getting the maximum ARC. However, for people like you who want the safety catches removed I should make it possible to disable back-pressure. -Kip Thanks, I appreciate all this work. Not allowing inactive pages to shrink the ARC sounds great as an option. I would be willing to bet that allowing inactive pages to shrink the arc would be far less detrimental to most people who aren't running a constant busy file server load, and its definitely important to try to protect untuned boxes. Do you have any suggestions for increasing the amount of memory ARC can use? I've had difficulty increasing kmem past a few gigs on any of my recent builds (all past where kmem was changed so it could be more than ~2g) because at some point the kernel would stop booting. If I increase them too far, a few lines of the booting kernel would print, followed by a long stream of page fault panics or something with a sudden reboot. With the recent change allowing the use of direct mem, the ARC could easily use ample memory except it turned out not to be stable. Thanks again.