On Thu, Dec 3, 2020 at 12:35 PM Jan Kara <jack@xxxxxxx> wrote:
>
> On Wed 02-12-20 14:07:13, Amir Goldstein wrote:
> > fsnotify() tries to merge marks on all object types (sb, mount, inode)
> > even if the object's mask shows no interest in the specific event type.
> >
> > This is done for the case that the object has marks with the event type
> > in their ignored mask, but the common case is that an object does not
> > have any marks with ignored mask.
> >
> > Set a bit in object's fsnotify mask during fsnotify_recalc_mask() to
> > indicate the existence of any marks with ignored masks.
> >
> > Instead of merging marks of all object types, only merge marks from
> > objects that either showed interest in the specific event type or have
> > any marks with ignored mask.
> >
> > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx>
>
> The idea looks sound to me and the patch fine (besides one bug noted
> below). I'd be interested if an actual performance impact of this and
> previous change could be noticed. Maybe some careful microbenchmark could
> reveal it...
Yeh, as I wrote in the cover letter. I don't know what to do with this.
By all accounts we should not merge unless we can prove benefit.
The reason I brought this back is I was thinking of a way to avoid
having to look up subtree marks on ancestors if sb had no subtree marks
that are interested in the event (or have an ignored mask).
So the benefit may become apparent when we add subtree marks
and then there is no harm to keep the same logic for other mark types.
>
> > + /*
> > + * Consider only marks that care about this type of event and marks with
> > + * an ignored mask.
> > + */
> > + test_mask |= FS_HAS_IGNORED_MASK;
> > + if (test_mask && sb->s_fsnotify_mask) {
> ^^ Just '&' here.
>
Heh! oops :)
Thanks,
Amir.
