From owner-freebsd-current@FreeBSD.ORG Tue May 19 02:35:03 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 8FDE8106566B; Tue, 19 May 2009 02:35:03 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id 107A58FC0C; Tue, 19 May 2009 02:35:02 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from harkness.in.wanderview.com (harkness.in.wanderview.com [10.76.10.150]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id n4J2Yxi9018393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 May 2009 02:34:59 GMT (envelope-from ben@wanderview.com) Message-Id: <1F20825F-BD11-40D1-9024-07F6E707DD08@wanderview.com> From: Ben Kelly To: Kip Macy In-Reply-To: <3c1674c90905181826p787a346cie90429324444a9c4@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 18 May 2009 22:34:58 -0400 References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> <20090519012202.GR82547@egr.msu.edu> <3c1674c90905181826p787a346cie90429324444a9c4@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.64 on 10.76.20.1 Cc: Adam McDougall , 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 02:35:03 -0000 On May 18, 2009, at 9:26 PM, 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. Isn't there already a vm_lowmem event for the arc that triggers reclamation? On the low memory front it seems like the arc needs a way to tell the pager to mark some vnodes inactive. I've seen many cases where the arc size greatly exceeded the target, but it couldn't evict any memory because all its buffers were still referenced. This seems to behave a little better with code that increments vm_pageout_deficit and signals the pageout daemon when the arc is too far above its target. The normal buffer cache seems to do this as well when its low on memory. - Ben