From owner-freebsd-current@FreeBSD.ORG  Tue May 19 11:25:18 2009
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 A7A491065670;
	Tue, 19 May 2009 11:25:18 +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 23CAB8FC13;
	Tue, 19 May 2009 11:25:17 +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 n4JBPD9x025791
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 19 May 2009 11:25:13 GMT (envelope-from ben@wanderview.com)
Message-Id: <4A88C71B-B338-4031-B591-FED323E067DC@wanderview.com>
From: Ben Kelly <ben@wanderview.com>
To: Kip Macy <kmacy@freebsd.org>
In-Reply-To: <3c1674c90905182012g63c3010bjf9cd7f0a2104966c@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: Tue, 19 May 2009 07:25:13 -0400
References: <20090518145614.GF82547@egr.msu.edu>
	<alpine.BSF.2.00.0905181031240.35767@thebighonker.lerctr.org>
	<alpine.BSF.2.00.0905181830490.1756@borg>
	<3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com>
	<alpine.BSF.2.00.0905181906001.2008@borg>
	<20090519012202.GR82547@egr.msu.edu>
	<3c1674c90905181826p787a346cie90429324444a9c4@mail.gmail.com>
	<1F20825F-BD11-40D1-9024-07F6E707DD08@wanderview.com>
	<3c1674c90905181945g179173b9rb064e8b37ba7148@mail.gmail.com>
	<68B339AA-75CF-41FC-9E09-81D20D6F1FBA@wanderview.com>
	<3c1674c90905182012g63c3010bjf9cd7f0a2104966c@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 <mcdouga9@egr.msu.edu>, current@freebsd.org,
	Larry Rosenman <ler@lerctr.org>
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
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 19 May 2009 11:25:18 -0000

On May 18, 2009, at 11:12 PM, Kip Macy wrote:
>>  http://www.wanderview.com/svn/public/misc/zfs/zfs_kmem_limit.diff
>>
>> But I trigger it based on kmem thresholds.  See arc_reclaim_pages().
>>
>> I can try to put together a smaller patch tomorrow evening that  
>> signals the
>> pager based on size vs. c target.  The main reason I didn't  
>> implement it in
>> my previous patch was because I was concerned with the arc being  
>> prevented
>> from growing at all once its been shrunk.  It only grows when size  
>> exceeds
>> its current target by a certain amount.  This may require some  
>> careful
>> balancing or hysteresis or something.
>>
>
> I was actually referring to your comment about telling the ARC to tell
> ZFS to reclaim cached vnodes. Not that the kmem changes aren't good,
> but I don't think they're necessary on amd64.

I thought I was referring to that too.  :-)  I guess I thought  
signaling the pageout daemon to move vnodes from active to inactive  
was the way to do that.  Are you saying there is another caching layer  
of vnodes going on in zfs?  I'll look around for that this evening.

Thanks.

- Ben