From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 8 22:38:11 2013 Return-Path: Delivered-To: freebsd-hackers@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 ESMTP id 18A433E7 for ; Tue, 8 Oct 2013 22:38:11 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A591327AD for ; Tue, 8 Oct 2013 22:38:10 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id w62so7921050wes.35 for ; Tue, 08 Oct 2013 15:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=IK8qxveOG4eD/zjxHDHG2xLG3LV1XBTrUXfFumvyChs=; b=eFGKdgqj+TLybgP75oHjjl9k5yJXbdPWd3yKBbgjsGNtaRGe4GgYIAyX1Vc+93nyPf Raxx0jSRjWA+iWP9o3RwTBGJbuab9tY/D+3uzHmFbw+a/XPiag8yNvkUyUxS05QBM0fJ b96YlyDVMGvPY4ECaA8Oeb9TEwGmh2yaM8jvkMttGcmz74oWFDpFa3mPrdI9bJyl2Bdb /6pr974mdESHvomxjYgmqSKYy3UgMqyMlMtqCziVuX8xM/bzsPER+Vc7/tjC6CNvjjSb lMvCkirsTsKqz5Qj02IyI3Qxmx3GrFHWhcyOp1LrlS4eY++WD1Hyb0HfMt11lOTO505f RHIA== X-Received: by 10.194.193.4 with SMTP id hk4mr3850065wjc.29.1381271888641; Tue, 08 Oct 2013 15:38:08 -0700 (PDT) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk. [87.194.105.247]) by mx.google.com with ESMTPSA id k4sm5777120wic.0.1969.12.31.16.00.00 (version=SSLv3 cipher=RC4-SHA bits=128/128); Tue, 08 Oct 2013 15:38:08 -0700 (PDT) Date: Tue, 8 Oct 2013 23:38:06 +0100 From: RW To: freebsd-hackers@freebsd.org Subject: Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage? Message-ID: <20131008233806.54bb0483@gumby.homeunix.com> In-Reply-To: References: <20130828181228.0d3618dd@ernst.home> <201309031507.33098.jhb@freebsd.org> <20131008063433.GA47506@x2.osted.lan> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 22:38:11 -0000 On Tue, 8 Oct 2013 13:32:58 +0200 Davide Italiano wrote: > On Tue, Oct 8, 2013 at 1:25 PM, Adrian Chadd > wrote: > > Hi, > > > > Hi Adrian, > > > Please try it out on a -10 VM with something RAM limited - say, > > 128mb w/ GENERIC. See how it behaves. Be aware that any test that doesn't cause vfs.ufs.dirhash_lowmemcount to increment isn't testing the change at all. > This is not supposed to hit 10-STABLE, at least not before proper > review. This is the reason why it was proposed on mailing lists. Also, > if you read the patch you'll end up with realizing this should behave > better on low memory environment because it unconditionally cleans 10% > of the cache every time. The current version deletes anything older than the time limit and if this doesn't reclaim 10% it makes a second pass through the list until the target is met. Your version tries to delete 10% (or whatever) by looping around the list until this is achieved. And if there aren't enough unlocked entries it will loop indefinitely until there are. I hope you know what you are doing because that looks very wrong. The original version looks better to me given that it already tries to free a minimum of 10%. The low-memory handler is called under very low memory conditions when the system is probably thrashing or even on the verge of killing processes. Holding on to entries that haven't been used for a minute seems like a luxury. > Previous changes in this area just did the > opposite keeping a lot more of memory around. I don't believe that's true. Under most circustances the existing scheme free more memory. The only case when yours frees more is when 90% of the entries are locked.