From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from bedivere.hansenpartnership.com ([66.63.167.143]:53428 "EHLO
        bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1752780AbdGUTaP (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Fri, 21 Jul 2017 15:30:15 -0400
Message-ID: <1500665412.2900.36.camel@HansenPartnership.com>
Subject: Re: [PATCH v2 3/4] fs/dcache: Enable automatic pruning of negative
 dentries
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Waiman Long <longman@redhat.com>,
        Alexander Viro <viro@zeniv.linux.org.uk>,
        Jonathan Corbet <corbet@lwn.net>
Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
        linux-fsdevel@vger.kernel.org,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Ingo Molnar <mingo@kernel.org>,
        Miklos Szeredi <mszeredi@redhat.com>,
        Matthew Wilcox <willy@infradead.org>,
        Larry Woodman <lwoodman@redhat.com>
Date: Fri, 21 Jul 2017 12:30:12 -0700
In-Reply-To: <1500644590-6599-4-git-send-email-longman@redhat.com>
References: <1500644590-6599-1-git-send-email-longman@redhat.com>
         <1500644590-6599-4-git-send-email-longman@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

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.

[...]
> @@ -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.

James