From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754707AbdGUURp convert rfc822-to-8bit (ORCPT ); Fri, 21 Jul 2017 16:17:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44418 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753904AbdGUURn (ORCPT ); Fri, 21 Jul 2017 16:17:43 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9CE6363314 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=longman@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 9CE6363314 Subject: Re: [PATCH v2 3/4] fs/dcache: Enable automatic pruning of negative dentries To: James Bottomley , Alexander Viro , Jonathan Corbet Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, "Paul E. McKenney" , Andrew Morton , Ingo Molnar , Miklos Szeredi , Matthew Wilcox , Larry Woodman References: <1500644590-6599-1-git-send-email-longman@redhat.com> <1500644590-6599-4-git-send-email-longman@redhat.com> <1500665412.2900.36.camel@HansenPartnership.com> From: Waiman Long Organization: Red Hat Message-ID: <346a2d51-9d4e-ce11-9075-138319c0ec0c@redhat.com> Date: Fri, 21 Jul 2017 16:17:40 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <1500665412.2900.36.camel@HansenPartnership.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 21 Jul 2017 20:17:42 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/21/2017 03:30 PM, James Bottomley wrote: > On Fri, 2017-07-21 at 09:43 -0400, Waiman Long wrote: >> Having a limit for the number of negative dentries does have an >> undesirable side effect that no new negative dentries will be allowed >> when the limit is reached. This will have performance implication >> for some types of workloads. > This really seems like a significant problem: negative dentries should > be released in strict lru order because the chances are no-one cares > about the least recently used one, but they may care about having the > most recently created one. This should not happen under normal circumstances as the asynchronous shrinker should be able to keep enough free negative dentry available in the pool that direct negative dentry killing will rarely happen. > [...] >> @@ -323,6 +329,16 @@ static void __neg_dentry_inc(struct dentry >> *dentry) >> */ >> if (!cnt) >> dentry->d_flags |= DCACHE_KILL_NEGATIVE; >> + >> + /* >> + * Initiate negative dentry pruning if free pool has less >> than >> + * 1/4 of its initial value. >> + */ >> + if (READ_ONCE(ndblk.nfree) < neg_dentry_nfree_init/4) { >> + WRITE_ONCE(ndblk.prune_sb, dentry->d_sb); >> + schedule_delayed_work(&prune_neg_dentry_work, >> + NEG_PRUNING_DELAY); >> + } > So here, why not run the negative dentry shrinker synchronously to see > if we can shrink the cache and avoid killing the current negative > dentry. If there are context problems doing that, we should at least > make the effort to track down the least recently used negative dentry > and mark that for killing instead. Only one CPU will be calling the asynchronous shrinker. So its effect on the overall performance of the system should be negligible. Allowing all CPUs to potentially do synchronous shrinking can cause a lot of lock and cacheline contention. I will look further to see if there is opportunity to do some optimistic synchronous shrinking. If that fails because of a contended lock, for example, we will need to fall back to killing the dentry. That should only happen under the worst case situation, like when a malicious process is running. Cheers, Longman