> > > 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 :). > You know me ;-) FS_MODIFY optimization pushed to fsnotify_pre_modify branch. Only tested that LTP tests pass. Note that this is only expected to improve performance in case there *are* marks, but not marks with ignore mask, because there is an earlier optimization in fsnotify() for the no marks case. Sorry for bombarding you with more patches (I should let you finish with fanotify_prep and fanotify_name_fid), but if you get a chance and can take a quick look at these 2 patches on fsnotify_pre_modify branch: 1. fsnotify: replace igrab() with ihold() on attach connector 2. fsnotify: allow adding an inode mark without pinning inode They are very small and simple, but I am afraid I may be missing something. Why did we use igrab() there in the first place? Is there a reason or is it relic from old code? As for the second patch, I won't get into why I need the evictable inode marks right now, but I was wondering if there was some inherent reason that I am missing why that cannot be done and inodes *have* to be pinned if you attach a mark to them (besides functionality of course)? Thanks, Amir.
