From: Amir Goldstein <amir73il@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: Jens Axboe <axboe@kernel.dk>,
Christian Brauner <brauner@kernel.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: [RFC][PATCH v2] fsnotify: optimize the case of no content event watchers
Date: Mon, 15 Jan 2024 21:42:44 +0200 [thread overview]
Message-ID: <CAOQ4uxhLum65Nou=DRaAT6W5xTvWjjP4+5mxYv2K3j4PB89s1A@mail.gmail.com> (raw)
In-Reply-To: <20240115183758.6yq6wjqjvhreyqnu@quack3>
[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]
> > So at this time, we have patch v2 which looks like a clear win.
> > It uses a slightly hackish SB_I_CONTENT_WATCHED to work around
> > the fact that real_mount() is not accessible to the inlined call sites.
>
> But won't it be better to move mnt_fsnotify_mask and perhaps
> mnt_fsnotify_marks (to keep things in one place) into struct vfsmount in
> that case?
I am afraid to even bring this up to Al and Christian ;-)
> IMHO working around this visibility problem with extra flag (and
> the code maintaining it) is not a great tradeoff...
I agree.
>
> As I wrote in my email to Jens I think your v3 patch just makes the real
> cost of fsnotify checks visible in fsnotify_path() instead of being hidden
> in the cost of read / write.
There is a flaw in that argument -
Assuming that in Jens' test no parent/mnt/sb are watching,
all the reads/write on regular file would end up calling __fsnotify_parent()
in upstream code - there is nothing to optimize away this call.
But now that I am looking closer at __fsnotify_parent(), I see what you
were trying to say - if I move the checks from fsnotify_path() to the
beginning of __fsnotify_parent(), it should get most of the performance
from v3 patch, so this is all that should be needed is this simple patch
attached.
I cannot really understand why we did not do this sooner...
Jens, if you have time for another round please test.
My expectation would be to see something like
+1.46% [kernel.vmlinux] [k] __fsnotify_parent
Thanks,
Amir.
+
+ if (!(mask & marks_mask))
+ return 0;
+ }
[-- Attachment #2: 0001-fsnotify-optimize-the-case-of-no-parent-watcher.patch --]
[-- Type: text/x-patch, Size: 1455 bytes --]
From 43bbeff601ed510936ac51b572d24388107f033b Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il@gmail.com>
Date: Fri, 9 Dec 2022 11:50:26 +0200
Subject: [PATCH] fsnotify: optimize the case of no parent watcher
If parent inode is not watching, check for the event in masks of
sb/mount/inode masks early to optimize out most of the code in
__fsnotify_parent() and fsnotify().
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
fs/notify/fsnotify.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/fs/notify/fsnotify.c b/fs/notify/fsnotify.c
index 8bfd690e9f10..ae74f6e60c64 100644
--- a/fs/notify/fsnotify.c
+++ b/fs/notify/fsnotify.c
@@ -190,13 +190,15 @@ int __fsnotify_parent(struct dentry *dentry, __u32 mask, const void *data,
struct qstr *file_name = NULL;
int ret = 0;
- /*
- * Do inode/sb/mount care about parent and name info on non-dir?
- * Do they care about any event at all?
- */
- if (!inode->i_fsnotify_marks && !inode->i_sb->s_fsnotify_marks &&
- (!mnt || !mnt->mnt_fsnotify_marks) && !parent_watched)
- return 0;
+ /* Optimize the likely case of parent not watching */
+ if (likely(!parent_watched)) {
+ __u32 marks_mask = inode->i_fsnotify_mask |
+ inode->i_sb->s_fsnotify_mask |
+ (mnt ? mnt->mnt_fsnotify_mask : 0);
+
+ if (!(mask & marks_mask))
+ return 0;
+ }
parent = NULL;
parent_needed = fsnotify_event_needs_parent(inode, mnt, mask);
--
2.34.1
next prev parent reply other threads:[~2024-01-15 19:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-11 15:22 [RFC][PATCH v2] fsnotify: optimize the case of no content event watchers Amir Goldstein
2024-01-11 16:46 ` Jens Axboe
2024-01-12 11:09 ` Jan Kara
2024-01-12 13:00 ` Amir Goldstein
2024-01-12 13:58 ` Jens Axboe
2024-01-12 14:11 ` Jens Axboe
2024-01-12 14:36 ` Amir Goldstein
2024-01-15 18:37 ` Jan Kara
2024-01-15 19:42 ` Amir Goldstein [this message]
2024-01-15 20:48 ` Jens Axboe
2024-01-15 16:11 ` Jan Kara
2024-01-15 16:14 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAOQ4uxhLum65Nou=DRaAT6W5xTvWjjP4+5mxYv2K3j4PB89s1A@mail.gmail.com' \
--to=amir73il@gmail.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).