From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 8 23:01:26 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BEBF7EC1 for ; Tue, 8 Oct 2013 23:01:26 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7BC22292A for ; Tue, 8 Oct 2013 23:01:26 +0000 (UTC) Received: by mail-vc0-f178.google.com with SMTP id lh4so1274vcb.9 for ; Tue, 08 Oct 2013 16:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yh5BQDMb1OeZZaHXM9RQqVbHeqyF5+4vb2/t6fi1WBc=; b=dlRoS+h30mDG+smAChyku1wxCKw5Dbhoc/HA4n9EYqfBHVR+0ABBb4RAs8GkVYYcyt vhN3iF7pLXJT+UMoZsAntDd/UGQ5X7cWCAq/ackvZFHhLJZk3r8BJY7zJI8qwlaTDmyk pvh/I9RKLhm1mrUXJbvwyXPnlwwhlSakv3z6fn8tEQNC1UXvmV94bBSCAQMeKbWaOxSS uwL6sSpw9gzbe+eocYYoGlkFE5KNapF5nVDZ4zPPw+Z+Q+JF6kTmgt5X0dD+Mm5NAt1I Vo3sT+avHKGceqaFVHTDvby4x+HVpHuhgUyjlIDfEbRt6vdWjnmri8jZ2xmkF9J6DmMb qfQQ== MIME-Version: 1.0 X-Received: by 10.52.52.137 with SMTP id t9mr2483725vdo.22.1381273285407; Tue, 08 Oct 2013 16:01:25 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.94.71 with HTTP; Tue, 8 Oct 2013 16:01:25 -0700 (PDT) In-Reply-To: <20131008233806.54bb0483@gumby.homeunix.com> References: <20130828181228.0d3618dd@ernst.home> <201309031507.33098.jhb@freebsd.org> <20131008063433.GA47506@x2.osted.lan> <20131008233806.54bb0483@gumby.homeunix.com> Date: Tue, 8 Oct 2013 16:01:25 -0700 X-Google-Sender-Auth: qCAiEZ0ubH3_wnZF8BN_S23LQIY Message-ID: Subject: Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage? From: Davide Italiano To: RW Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers 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 23:01:26 -0000 On Tue, Oct 8, 2013 at 3:38 PM, RW wrote: > 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. > Hi (RW..?), This could be probably changed -- from what | see even under high memory pressure this wasn't a problem but all in all I agree with you that we shouldn't loop forever but limit the number of pass on the list to a somewhat constant number, to prevent pathological cases. > 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. Well, no. Here you can set the threshold to a more aggressive value so that you reclaim more memory every time. Note that this was not possible in the previous version, so, if you could have a situation where all your cache entries were not touched for 15 or even 30 seconds they would have kept around, and you can destroy up to 10% of them everytime lowmem event is called. Thanks, -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare