From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C2744C47095 for ; Mon, 7 Jun 2021 18:27:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A7B026101A for ; Mon, 7 Jun 2021 18:27:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231253AbhFGS3s (ORCPT ); Mon, 7 Jun 2021 14:29:48 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:34210 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231171AbhFGS3o (ORCPT ); Mon, 7 Jun 2021 14:29:44 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]) by out02.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lqJya-00GKWZ-4h; Mon, 07 Jun 2021 12:27:52 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=email.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lqJyK-009rTo-DI; Mon, 07 Jun 2021 12:27:51 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Ian Kent Cc: Greg Kroah-Hartman , Tejun Heo , Eric Sandeen , Fox Chen , Brice Goglin , Al Viro , Rick Lindsley , David Howells , Miklos Szeredi , Marcelo Tosatti , Carlos Maiolino , linux-fsdevel , Kernel Mailing List References: <162306058093.69474.2367505736322611930.stgit@web.messagingengine.com> <162306072498.69474.16160057168984328507.stgit@web.messagingengine.com> Date: Mon, 07 Jun 2021 13:27:29 -0500 In-Reply-To: <162306072498.69474.16160057168984328507.stgit@web.messagingengine.com> (Ian Kent's message of "Mon, 07 Jun 2021 18:12:05 +0800") Message-ID: <87lf7lil7y.fsf@disp2133> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1lqJyK-009rTo-DI;;;mid=<87lf7lil7y.fsf@disp2133>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+BKBqvpHqVOC8NchFOFOsF2zTFLLCvskI= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH v5 3/6] kernfs: use VFS negative dentry caching X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ian Kent writes: > If there are many lookups for non-existent paths these negative lookups > can lead to a lot of overhead during path walks. > > The VFS allows dentries to be created as negative and hashed, and caches > them so they can be used to reduce the fairly high overhead alloc/free > cycle that occurs during these lookups. > > Use the kernfs node parent revision to identify if a change has been > made to the containing directory so that the negative dentry can be > discarded and the lookup redone. > > Signed-off-by: Ian Kent > --- > fs/kernfs/dir.c | 53 +++++++++++++++++++++++++++++++---------------------- > 1 file changed, 31 insertions(+), 22 deletions(-) > > diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c > index b88432c48851f..5ae95e8d1aea1 100644 > --- a/fs/kernfs/dir.c > +++ b/fs/kernfs/dir.c > @@ -1039,13 +1039,32 @@ static int kernfs_dop_revalidate(struct dentry *dentry, unsigned int flags) > if (flags & LOOKUP_RCU) > return -ECHILD; > > - /* Always perform fresh lookup for negatives */ > - if (d_really_is_negative(dentry)) > - goto out_bad_unlocked; > - > kn = kernfs_dentry_node(dentry); > mutex_lock(&kernfs_mutex); > > + /* Negative hashed dentry? */ > + if (!kn) { > + struct dentry *d_parent = dget_parent(dentry); > + struct kernfs_node *parent; > + > + /* If the kernfs parent node has changed discard and > + * proceed to ->lookup. > + */ > + parent = kernfs_dentry_node(d_parent); > + if (parent) { > + if (kernfs_dir_changed(parent, dentry)) { > + dput(d_parent); > + goto out_bad; > + } > + } > + dput(d_parent); > + > + /* The kernfs node doesn't exist, leave the dentry > + * negative and return success. > + */ > + goto out; > + } What part of this new negative hashed dentry check needs the kernfs_mutex? I guess it is the reading of kn->dir.rev. Since all you are doing is comparing if two fields are equal it really should not matter. Maybe somewhere there needs to be a sprinkling of primitives like READ_ONCE. It just seems like such a waste to put all of that under kernfs_mutex on the off chance kn->dir.rev will change while it is being read. Eric