mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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
 };
 
_

  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