Re: [PATCH] mm: Add RWH_RMAP_EXCLUDE flag to exclude files from rmap sharing

[Lorenzo Stoakes <ljs@kernel.org>]

NAK obviously.

I hate to keep saying this to people, but you've got no excuse at this stage
it's been a year or so since we added mm maintainers/reviewers and you're not
sending this to the right people.

How hard is doing:

$ scripts/get_maintainer.pl --no-git fs/fcntl.c fs/open.c include/linux/fs.h \
	include/uapi/linux/fcntl.h mm/mmap.c mm/vma.c
Jeff Layton <jlayton@kernel.org> (maintainer:FILE LOCKING (flock() and fcntl()/lockf()))
Chuck Lever <chuck.lever@oracle.com> (maintainer:FILE LOCKING (flock() and fcntl()/lockf()))
Alexander Aring <alex.aring@gmail.com> (reviewer:FILE LOCKING (flock() and fcntl()/lockf()))
Alexander Viro <viro@zeniv.linux.org.uk> (maintainer:FILESYSTEMS (VFS and infrastructure))
Christian Brauner <brauner@kernel.org> (maintainer:FILESYSTEMS (VFS and infrastructure))
Jan Kara <jack@suse.cz> (reviewer:FILESYSTEMS (VFS and infrastructure))
Andrew Morton <akpm@linux-foundation.org> (maintainer:MEMORY MAPPING)
"Liam R. Howlett" <Liam.Howlett@oracle.com> (maintainer:MEMORY MAPPING)
Lorenzo Stoakes <ljs@kernel.org> (maintainer:MEMORY MAPPING)
Vlastimil Babka <vbabka@kernel.org> (reviewer:MEMORY MAPPING)
Jann Horn <jannh@google.com> (reviewer:MEMORY MAPPING)
Pedro Falcato <pfalcato@suse.de> (reviewer:MEMORY MAPPING)
linux-fsdevel@vger.kernel.org (open list:FILE LOCKING (flock() and fcntl()/lockf()))
linux-kernel@vger.kernel.org (open list)
linux-mm@kvack.org (open list:MEMORY MAPPING)

?

You're sending an insane patch that breaks core mm and you can't even send it to
the right people...

(And yet Mateusz is somehow cc'd (he loves that :))

This kind of craziness should be an RFC also as David said.

Both of these things are just rude and not helpful wrt upstream.

On Tue, Apr 21, 2026 at 10:09:32AM +0800, Yibin Liu wrote:
> UnixBench execl/shellscript (dynamically linked binaries) at 64+ cores are
> bottlenecked on the i_mmap_rwsem semaphore due to heavy vma insert/remove
> operations on the i_mmap tree, where libc.so.6 is the most frequent,
> followed by ld-linux-x86-64.so.2 and the test executable itself.

OK that's good to know, but please provide _actual data_. Hand waving isn't ok.

>
> This patch marks such files to skip rmap operations, avoiding frequent
> interval tree insert/remove that cause i_mmap_rwsem lock contention.

OK that's totally insane.

This is a classic example of 'I have problem X, therefore <do something insane
that happens to addess X>'.

> The downside is these files can no longer be reclaimed (along with compact
> and ksm), but since they are small and resident anyway, it's acceptable.
> When all mapping processes exit, files can still be reclaimed normally.
>

Yeah, that's quite the bloody downside. And 'they're small and resident
anyway'... err what on earth makes that a thing?

Also as Matthew points out, you're impacting _everybody else_, you're giving
avenues for unprivileged users to trigger total kernel lockups, you're breaking
migration, you're breaking reclaim, you're breaking basically all of rmap to fix
a performance issue.

> Performance testing shows ~80% improvement in UnixBench execl/shellscript
> scores on Hygon 7490, AMD zen4 9754 and Intel emerald rapids platform.

Yeah ok, I'm sure if I remove rmap altogether I'll get even better numbers :)

I can also take the oxygen system out of a plane and make it way more fuel
efficient!

>
> Signed-off-by: Yibin Liu <liuyibin@hygon.cn>
> ---
>  fs/fcntl.c                 | 1 +
>  fs/open.c                  | 6 ++++++
>  include/linux/fs.h         | 3 +++
>  include/uapi/linux/fcntl.h | 1 +
>  mm/mmap.c                  | 3 ++-
>  mm/vma.c                   | 8 +++++---
>  6 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/fs/fcntl.c b/fs/fcntl.c
> index beab8080badf..9b7cc1544735 100644
> --- a/fs/fcntl.c
> +++ b/fs/fcntl.c
> @@ -349,6 +349,7 @@ static bool rw_hint_valid(u64 hint)
>  	case RWH_WRITE_LIFE_MEDIUM:
>  	case RWH_WRITE_LIFE_LONG:
>  	case RWH_WRITE_LIFE_EXTREME:
> +	case RWH_RMAP_EXCLUDE:
>  		return true;
>  	default:
>  		return false;
> diff --git a/fs/open.c b/fs/open.c
> index 681d405bc61e..643ab7c6b461 100644
> --- a/fs/open.c
> +++ b/fs/open.c
> @@ -46,6 +46,10 @@ int do_truncate(struct mnt_idmap *idmap, struct dentry *dentry,
>  	if (length < 0)
>  		return -EINVAL;
>
> +	/* Prevent truncate on files marked as RMAP_EXCLUDE (e.g., libc, ld.so) */

Prevent truncation :)

RMAP_EXCLUDE :)))

Seriously no.

> +	if (filp && (filp->f_mode & FMODE_RMAP_EXCLUDE))
> +		return -EPERM;
> +
>  	newattrs.ia_size = length;
>  	newattrs.ia_valid = ATTR_SIZE | time_attrs;
>  	if (filp) {
> @@ -892,6 +896,8 @@ static int do_dentry_open(struct file *f,
>  	path_get(&f->f_path);
>  	f->f_inode = inode;
>  	f->f_mapping = inode->i_mapping;
> +	if (inode->i_write_hint == RWH_RMAP_EXCLUDE)
> +		f->f_mode |= FMODE_RMAP_EXCLUDE;
>  	f->f_wb_err = filemap_sample_wb_err(f->f_mapping);
>  	f->f_sb_err = file_sample_sb_err(f);
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 11559c513dfb..d5c9e5a4c2b9 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -189,6 +189,9 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t offset,
>  /* File does not contribute to nr_files count */
>  #define FMODE_NOACCOUNT		((__force fmode_t)(1 << 29))
>
> +/* File should exclude vma from rmap interval tree */
> +#define FMODE_RMAP_EXCLUDE	((__force fmode_t)(1 << 30))
> +
>  /*
>   * The two FMODE_NONOTIFY* define which fsnotify events should not be generated
>   * for an open file. These are the possible values of
> diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h
> index aadfbf6e0cb3..4969b4762071 100644
> --- a/include/uapi/linux/fcntl.h
> +++ b/include/uapi/linux/fcntl.h
> @@ -72,6 +72,7 @@
>  #define RWH_WRITE_LIFE_MEDIUM	3
>  #define RWH_WRITE_LIFE_LONG	4
>  #define RWH_WRITE_LIFE_EXTREME	5
> +#define RWH_RMAP_EXCLUDE	6

As others have pointed out, rmap is not a user API, and it will NEVER be.

>
>  /*
>   * The originally introduced spelling is remained from the first
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 2311ae7c2ff4..3eb00997e86a 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1830,7 +1830,8 @@ __latent_entropy int dup_mmap(struct mm_struct *mm, struct mm_struct *oldmm)
>  				mapping_allow_writable(mapping);
>  			flush_dcache_mmap_lock(mapping);
>  			/* insert tmp into the share list, just after mpnt */
> -			vma_interval_tree_insert_after(tmp, mpnt,
> +			if (!(file->f_mode & FMODE_RMAP_EXCLUDE))
> +				vma_interval_tree_insert_after(tmp, mpnt,

Yeah this is just... this seems completely broken?

I'd be curious to see what sashiko finds for this lord :)

>  					&mapping->i_mmap);
>  			flush_dcache_mmap_unlock(mapping);
>  			i_mmap_unlock_write(mapping);
> diff --git a/mm/vma.c b/mm/vma.c
> index 377321b48734..f1e36e6a8702 100644
> --- a/mm/vma.c
> +++ b/mm/vma.c
> @@ -234,7 +234,8 @@ static void __vma_link_file(struct vm_area_struct *vma,
>  		mapping_allow_writable(mapping);
>
>  	flush_dcache_mmap_lock(mapping);
> -	vma_interval_tree_insert(vma, &mapping->i_mmap);
> +	if (!(vma->vm_file->f_mode & FMODE_RMAP_EXCLUDE))
> +		vma_interval_tree_insert(vma, &mapping->i_mmap);
>  	flush_dcache_mmap_unlock(mapping);
>  }
>
> @@ -339,10 +340,11 @@ static void vma_complete(struct vma_prepare *vp, struct vma_iterator *vmi,
>  			 struct mm_struct *mm)
>  {
>  	if (vp->file) {
> -		if (vp->adj_next)
> +		if (vp->adj_next && !(vp->adj_next->vm_file->f_mode & FMODE_RMAP_EXCLUDE))
>  			vma_interval_tree_insert(vp->adj_next,
>  						 &vp->mapping->i_mmap);
> -		vma_interval_tree_insert(vp->vma, &vp->mapping->i_mmap);
> +		if (!(vp->vma->vm_file->f_mode & FMODE_RMAP_EXCLUDE))
> +			vma_interval_tree_insert(vp->vma, &vp->mapping->i_mmap);

Hang on, this is struct file * state that impacts folio-granularity behaviour?

I mean ugh anyway.

>  		flush_dcache_mmap_unlock(vp->mapping);
>  	}
>
> --
> 2.34.1
>
>
>

This idea is totally broken.

If you want to contribute usefully, PLEASE drop this silly idea, come back with
some NUMBERS about the contention you see, and let's have a sensible discussion
about what we can do to address that?

Also follow standard upstream kernel procedures - figure out who to email
properly, RFC insane ideas, etc.

Thanks, Lorenzo