On Sat 04-07-20 12:30:10, Amir Goldstein wrote:
> On Fri, Jul 3, 2020 at 5:03 PM Jan Kara <jack@xxxxxxx> wrote:
> > > /* Notify this dentry's parent about a child's events. */
> > > -int fsnotify_parent(struct dentry *dentry, __u32 mask, const void *data,
> > > +int __fsnotify_parent(struct dentry *dentry, __u32 mask, const void *data,
> > > int data_type)
> > > {
> > > struct dentry *parent;
> >
> > Hum, should we actually remove the DCACHE_FSNOTIFY_PARENT_WATCHED check
> > from here when it's moved to fsnotify_parent() inline helper?
>
> No point.
> It is making a comeback on:
> fsnotify: send event with parent/name info to sb/mount/non-dir marks
Right, I've noticed that later as well.
> > > @@ -337,13 +331,22 @@ int fsnotify(struct inode *to_tell, __u32 mask, const void *data, int data_is,
> > > if (!to_tell->i_fsnotify_marks && !sb->s_fsnotify_marks &&
> > > (!mnt || !mnt->mnt_fsnotify_marks))
> > > return 0;
> > > +
> > > + /* An event "on child" is not intended for a mount/sb mark */
> > > + marks_mask = to_tell->i_fsnotify_mask;
> > > + if (!(mask & FS_EVENT_ON_CHILD)) {
> > > + marks_mask |= sb->s_fsnotify_mask;
> > > + if (mnt)
> > > + marks_mask |= mnt->mnt_fsnotify_mask;
> > > + }
> > > +
> > > /*
> > > * if this is a modify event we may need to clear the ignored masks
> > > * otherwise return if neither the inode nor the vfsmount/sb care about
> > > * this type of event.
> > > */
> > > - if (!(mask & FS_MODIFY) &&
> > > - !(test_mask & (to_tell->i_fsnotify_mask | mnt_or_sb_mask)))
> > > + test_mask = (mask & ALL_FSNOTIFY_EVENTS);
> > > + if (!(mask & FS_MODIFY) && !(test_mask & marks_mask))
> > > return 0;
> >
> > Otherwise the patch looks good. One observation though: The (mask &
> > FS_MODIFY) check means that all vfs_write() calls end up going through the
> > "slower" path iterating all mark types and checking whether there are marks
> > anyway. That could be relatively simply optimized using a hidden mask flag
> > like FS_ALWAYS_RECEIVE_MODIFY which would be set when there's some mark
> > needing special handling of FS_MODIFY... Not sure if we care enough at this
> > point...
>
> Yeh that sounds low hanging.
> Actually, I Don't think we need to define a flag for that.
> __fsnotify_recalc_mask() can add FS_MODIFY to the object's mask if needed.
Yes, that would be even more elegant.
> I will take a look at that as part of FS_PRE_MODIFY work.
> But in general, we should fight the urge to optimize theoretic
> performance issues...
Agreed. I just suspect this may bring measurable benefit for hackbench pipe
or tiny tmpfs writes after seeing Mel's results. But as I wrote this is a
separate idea and without some numbers confirming my suspicion I don't
think the complication is worth it so I don't want you to burn time on this
unless you're really interested :).
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
