Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Mel Gorman <mgorman@techsingularity.net>
Subject: Re: fsnotify: minimise overhead when there are no marks with ignore mask
Date: Thu, 9 Jul 2020 20:56:35 +0300 [thread overview]
Message-ID: <CAOQ4uxi5Zpp7rCKdOkdw9Nkd=uGC-K2AuLqOFc0WQc_CgJQP2Q@mail.gmail.com> (raw)
In-Reply-To: <20200706110526.GA3913@quack2.suse.cz>
> > > 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.
next prev parent reply other threads:[~2020-07-09 17:56 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-12 9:33 [PATCH 00/20] Prep work for fanotify named events Amir Goldstein
2020-06-12 9:33 ` [PATCH 01/20] fsnotify: Rearrange fast path to minimise overhead when there is no watcher Amir Goldstein
2020-07-03 14:03 ` Jan Kara
2020-07-04 9:30 ` Amir Goldstein
2020-07-06 11:05 ` Jan Kara
2020-07-09 17:56 ` Amir Goldstein [this message]
2020-07-26 15:20 ` fsnotify: minimise overhead when there are no marks related to sb Amir Goldstein
2020-07-27 7:44 ` Jan Kara
2020-07-27 10:02 ` Amir Goldstein
2020-06-12 9:33 ` [PATCH 02/20] fsnotify: fold fsnotify() call into fsnotify_parent() Amir Goldstein
2020-06-12 9:33 ` [PATCH 03/20] fsnotify: return non const from fsnotify_data_inode() Amir Goldstein
2020-06-12 9:33 ` [PATCH 04/20] nfsd: use fsnotify_data_inode() to get the unlinked inode Amir Goldstein
2020-06-12 10:25 ` Amir Goldstein
2020-06-12 9:33 ` [PATCH 05/20] kernfs: do not call fsnotify() with name without a parent Amir Goldstein
2020-06-29 13:27 ` Tejun Heo
2020-06-29 16:11 ` Greg Kroah-Hartman
2020-06-12 9:33 ` [PATCH 06/20] inotify: do not use objectid when comparing events Amir Goldstein
2020-06-12 9:33 ` [PATCH 07/20] fanotify: create overflow event type Amir Goldstein
2020-06-12 9:33 ` [PATCH 08/20] fanotify: break up fanotify_alloc_event() Amir Goldstein
2020-06-12 9:33 ` [PATCH 09/20] fsnotify: pass dir argument to handle_event() callback Amir Goldstein
2020-07-03 14:49 ` Jan Kara
2020-06-12 9:33 ` [PATCH 10/20] fanotify: generalize the handling of extra event flags Amir Goldstein
2020-06-12 9:33 ` [PATCH 11/20] fanotify: generalize merge logic of events on dir Amir Goldstein
2020-06-12 9:33 ` [PATCH 12/20] fanotify: distinguish between fid encode error and null fid Amir Goldstein
2020-06-12 9:33 ` [PATCH 13/20] fanotify: generalize test for FAN_REPORT_FID Amir Goldstein
2020-06-12 9:33 ` [PATCH 14/20] fanotify: mask out special event flags from ignored mask Amir Goldstein
2020-06-12 9:33 ` [PATCH 15/20] fanotify: prepare for implicit event flags in mark mask Amir Goldstein
2020-06-12 9:33 ` [PATCH 16/20] fanotify: use FAN_EVENT_ON_CHILD as implicit flag on sb/mount/non-dir marks Amir Goldstein
2020-06-12 9:33 ` [PATCH 17/20] fanotify: remove event FAN_DIR_MODIFY Amir Goldstein
2020-06-12 9:33 ` [PATCH 18/20] fsnotify: add object type "child" to object type iterator Amir Goldstein
2020-06-12 9:33 ` [PATCH 19/20] fanotify: move event name into fanotify_fh Amir Goldstein
2020-07-03 16:02 ` Jan Kara
2020-07-06 8:21 ` Amir Goldstein
2020-07-06 15:24 ` Jan Kara
2020-06-12 9:33 ` [PATCH 20/20] fanotify: no external fh buffer in fanotify_name_event Amir Goldstein
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='CAOQ4uxi5Zpp7rCKdOkdw9Nkd=uGC-K2AuLqOFc0WQc_CgJQP2Q@mail.gmail.com' \
--to=amir73il@gmail.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mgorman@techsingularity.net \
--subject='Re: fsnotify: minimise overhead when there are no marks with ignore mask' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).