On Mon, Jun 15, 2020 at 07:26:38PM +0300, Amir Goldstein wrote: > On Mon, Jun 15, 2020 at 3:14 PM Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> wrote: > > > > Changelog since v1 > > o Updated changelog > > Slipped to commit message > It's habit, it's the layout I generally use for mm even though others prefer having it below ---. I wasn't sure of fsnotify's preferred format for tracking major differences between versions. > > > > The kernel uses internal mounts created by kern_mount() and populated > > with files with no lookup path by alloc_file_pseudo for a variety of > > reasons. An example of such a mount is for anonymous pipes. For pipes, > > every vfs_write regardless of filesystem, fsnotify_modify() is called to > > notify of any changes which incurs a small amount of overhead in fsnotify > > even when there are no watchers. It can also trigger for reads and readv > > and writev, it was simply vfs_write() that was noticed first. > > > > A patch is pending that reduces, but does not eliminte, the overhead of > > typo: eliminte > Yes. > > fsnotify but for files that cannot be looked up via a path, even that > > small overhead is unnecessary. The user API for fanotify is based on > > the pathname and a dirfd and proc entries appear to be the only visible > > representation of the files. Proc does not have the same pathname as the > > internal entry and the proc inode is not the same as the internal inode > > so even if fanotify is used on a file under /proc/XX/fd, no useful events > > are notified. > > > > Note that fanotify is not the only uapi to add marks, but this is fine by me > I suppose if Jan wants to he can make small corrections on commit. > True but I didn't think inotify was materially different as it also takes a path. Is that wrong or are there others that matter and can attach to a file that cannot be looked up via a path? > > The difference is small but in some cases it's outside the noise so > > while marginal, there is still some small benefit to ignoring fsnotify > > for files allocated via alloc_file_pseudo in some cases. > > > > Signed-off-by: Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> > > Reviewed-by: Amir Goldstein <amir73il@xxxxxxxxx> > Thanks! -- Mel Gorman SUSE Labs
