From: Dave Hansen <dave@sr71.net>
To: dave@sr71.net
Cc: jack@suse.cz, viro@zeniv.linux.org.uk,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
paulmck@linux.vnet.ibm.com, tim.c.chen@linux.intel.com,
ak@linux.intel.com, dave.hansen@linux.intel.com
Subject: [RFCv2][PATCH 7/7] fsnotify: track when ignored mask clearing is needed
Date: Wed, 24 Jun 2015 17:16:08 -0700 [thread overview]
Message-ID: <20150625001608.830BD5CA@viggo.jf.intel.com> (raw)
In-Reply-To: <20150625001605.72553909@viggo.jf.intel.com>
From: Dave Hansen <dave.hansen@linux.intel.com>
According to Jan Kara:
You can have ignored mask set without any of the
notification masks set and you are expected to clear the
ignored mask on the first IN_MODIFY event.
But, the only way we currently have to go and find if we need to
do this ignored-mask-clearing is to go through the mark lists
and look for them. That mark list iteration requires an
srcu_read_lock() which has a memory barrier and can be expensive.
The calculation of 'has_ignore' is pretty cheap because we store
it next to another value which we are updating and we do it
inside of a loop we were already running.
This patch will really only matter when we have a workload where
a file is being modified often _and_ there is an active fsnotify
mark on it. Otherwise the checks against *_fsnotify.marks.first
will keep us out of the expensive srcu_read_lock() call.
Cc: Jan Kara <jack@suse.cz>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
---
b/fs/notify/fsnotify.c | 44 ++++++++++++++++++++++++++++++++++------
b/fs/notify/mark.c | 8 +++++--
b/include/linux/fsnotify_head.h | 1
3 files changed, 45 insertions(+), 8 deletions(-)
diff -puN fs/notify/fsnotify.c~fsnotify-ignore-present fs/notify/fsnotify.c
--- a/fs/notify/fsnotify.c~fsnotify-ignore-present 2015-06-24 17:14:37.187226743 -0700
+++ b/fs/notify/fsnotify.c 2015-06-24 17:14:37.194227057 -0700
@@ -183,6 +183,34 @@ static int send_to_group(struct inode *t
}
/*
+ * The "logical or" of all of the marks' ->mask is kept in the
+ * i/mnt_fsnotify.mask. We can check it instead of going
+ * through all of the marks. fsnotify_recalc_mask() does the
+ * updates.
+ */
+static int some_mark_is_interested(__u32 mask, struct inode *inode, struct mount *mnt)
+{
+ if (mask & inode->i_fsnotify.mask)
+ return 1;
+ if (mnt && (mask & mnt->mnt_fsnotify.mask))
+ return 1;
+ return 0;
+}
+
+/*
+ * fsnotify_recalc_mask() recalculates "has_ignore" whenever any
+ * mark's flags change.
+ */
+static int some_mark_needs_ignore_clear(struct inode *inode, struct mount *mnt)
+{
+ if (inode->i_fsnotify.has_ignore)
+ return 1;
+ if (mnt && mnt->mnt_fsnotify.has_ignore)
+ return 1;
+ return 0;
+}
+
+/*
* This is the main call to fsnotify. The VFS calls into hook specific functions
* in linux/fsnotify.h. Those functions then in turn call here. Here will call
* out to all of the registered fsnotify_group. Those groups can then use the
@@ -205,14 +233,18 @@ int fsnotify(struct inode *to_tell, __u3
mnt = NULL;
/*
- * if this is a modify event we may need to clear the ignored masks
- * otherwise return if neither the inode nor the vfsmount care about
- * this type of event.
+ * We must clear the (user-visible) ignored mask on the first IN_MODIFY
+ * event despite the 'mask' which is passed in here. But we can safely
+ * skip that step if we know there are no marks which need this action.
+ *
+ * We can also skip looking at the list of marks if we know that none
+ * of the marks are interested in the events in our 'mask'.
*/
- if (!(mask & FS_MODIFY) &&
- !(test_mask & to_tell->i_fsnotify.mask) &&
- !(mnt && test_mask & mnt->mnt_fsnotify.mask))
+ if ((mask & FS_MODIFY) && !some_mark_needs_ignore_clear(to_tell, mnt))
+ return 0;
+ else if (!some_mark_is_interested(test_mask, to_tell, mnt))
return 0;
+
/*
* Optimization: srcu_read_lock() has a memory barrier which can
* be expensive. It protects walking the *_fsnotify_marks lists.
diff -puN fs/notify/mark.c~fsnotify-ignore-present fs/notify/mark.c
--- a/fs/notify/mark.c~fsnotify-ignore-present 2015-06-24 17:14:37.189226832 -0700
+++ b/fs/notify/mark.c 2015-06-24 17:14:37.194227057 -0700
@@ -116,10 +116,14 @@ void fsnotify_recalc_mask(struct fsnotif
{
u32 new_mask = 0;
struct fsnotify_mark *mark;
+ u32 has_ignore = 0;
- hlist_for_each_entry(mark, &fsn->marks, obj_list)
+ hlist_for_each_entry(mark, &fsn->marks, obj_list) {
+ if (mark->flags & FSNOTIFY_MARK_FLAG_IGNORED_SURV_MODIFY)
+ has_ignore = 1;
new_mask |= mark->mask;
-
+ }
+ fsn->has_ignore = has_ignore;
fsn->mask = new_mask;
}
diff -puN include/linux/fsnotify_head.h~fsnotify-ignore-present include/linux/fsnotify_head.h
--- a/include/linux/fsnotify_head.h~fsnotify-ignore-present 2015-06-24 17:14:37.190226877 -0700
+++ b/include/linux/fsnotify_head.h 2015-06-24 17:14:37.193227012 -0700
@@ -11,6 +11,7 @@ struct fsnotify_head {
#ifdef CONFIG_FSNOTIFY
__u32 mask; /* all events this object cares about */
struct hlist_head marks;
+ __u32 has_ignore; /* any marks has ignore set */
#endif
};
_
next prev parent reply other threads:[~2015-06-25 0:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-25 0:16 [RFCv2][PATCH 1/7] fs: optimize inotify/fsnotify code for unwatched files Dave Hansen
2015-06-25 0:16 ` [RFCv2][PATCH 2/7] fs: use RCU for free_super() vs. __sb_start_write() Dave Hansen
2015-06-26 12:59 ` Jan Kara
2015-06-25 0:16 ` [RFCv2][PATCH 3/7] fs: fsnotify: replace memory barrier in __sb_end_write() with RCU Dave Hansen
2015-06-26 13:07 ` Jan Kara
2015-06-25 0:16 ` [RFCv2][PATCH 4/7] fsnotify: encapsulate embedded fsnotify data in a single spot Dave Hansen
2015-06-26 13:19 ` Jan Kara
2015-06-25 0:16 ` [RFCv2][PATCH 5/7] fsnotify: use fsnotify_head for vfsmount data Dave Hansen
2015-06-25 0:16 ` [RFCv2][PATCH 6/7] fsnotify: change fsnotify_recalc_mask() conventions Dave Hansen
2015-06-25 0:16 ` Dave Hansen [this message]
2015-06-26 13:26 ` [RFCv2][PATCH 7/7] fsnotify: track when ignored mask clearing is needed Jan Kara
2015-06-25 0:57 ` [RFCv2][PATCH 1/7] fs: optimize inotify/fsnotify code for unwatched files Eric Paris
2015-06-25 16:28 ` Dave Hansen
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=20150625001608.830BD5CA@viggo.jf.intel.com \
--to=dave@sr71.net \
--cc=ak@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=tim.c.chen@linux.intel.com \
--cc=viro@zeniv.linux.org.uk \
/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
Powered by JetHome