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

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

[Yibin Liu]

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.

This patch marks such files to skip rmap operations, avoiding frequent
interval tree insert/remove that cause i_mmap_rwsem lock contention.
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.

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

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) */
+	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
 
 /*
  * 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,
 					&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);
 		flush_dcache_mmap_unlock(vp->mapping);
 	}
 
-- 
2.34.1

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

[Matthew Wilcox]

On Tue, Apr 21, 2026 at 10:09:32AM +0800, Yibin Liu wrote:
> +	/* Prevent truncate on files marked as RMAP_EXCLUDE (e.g., libc, ld.so) */
> +	if (filp && (filp->f_mode & FMODE_RMAP_EXCLUDE))
> +		return -EPERM;

You can't do this.  It means I can prevent anybody else from truncating
a file which I can open.

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

[Pedro Falcato]

I'm not sure how you're using get_maintainer.pl, but PLEASE CC people
correctly.

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.
> 
> This patch marks such files to skip rmap operations, avoiding frequent
> interval tree insert/remove that cause i_mmap_rwsem lock contention.
> The downside is these files can no longer be reclaimed (along with compact

This does not work.

> and ksm), but since they are small and resident anyway, it's acceptable.

Which ones? ELF executables commonly have a lot of padding. How do you know
what to mark as !no_rmap? Who has permissions for that? This patch allows
any user to create a full DoS of the system by simply marking a really large
file as no-reclaim.

> When all mapping processes exit, files can still be reclaimed normally.
> 
> Performance testing shows ~80% improvement in UnixBench execl/shellscript
> scores on Hygon 7490, AMD zen4 9754 and Intel emerald rapids platform.
> 
> 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) */
> +	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

Userspace does not know what "rmap" is, nor does it need to know. Even if you
found a workable solution for the permission side, this is not a good solution,
and it's not a good interface. It also might solve it for you, but definitely
does not solve the whole issue with having a lock there (which you are, for
the record, still acquiring).

-- 
Pedro

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

[Mateusz Guzik]

On Tue, Apr 21, 2026 at 4:11 AM Yibin Liu <liuyibin@hygon.cn> 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.
>
> This patch marks such files to skip rmap operations, avoiding frequent
> interval tree insert/remove that cause i_mmap_rwsem lock contention.
> 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.
>
> Performance testing shows ~80% improvement in UnixBench execl/shellscript
> scores on Hygon 7490, AMD zen4 9754 and Intel emerald rapids platform.
>

The other responders have been a little harsh and despite raising
valid points I don't think they gave a proper review.

The bigger picture is that the problematic rwsem is taken several
times during fork + exec + exit cycle. Normally you end up with 5
distinct mappings per binary/so, each created with a separate lock
acquire.

Some time ago I patched exit to batch processing, leaving 1 acquire in
that codepath. fork can and should be patched in a similar vein, but I
don't know if unixbench runs it in this benchmark (i.e., real
workloads certainly suffer from it, I don't know if this particular
bench includes that aspect). This is on top of forking itself being
avoidable should the kernel grow a better interface for executing
binaries.

This leaves us with mapping creation on exec. This problem is
unfixable without introduction of better APIs for userspace, which
constitutes quite a challenge.

The end result is the absolutely horrible case of multiple acquires of
the same lock per iteration.

One common idea how to reduce contention boils down to shortening lock
hold time. This has very limited effect in face of the aforementioned
multiple acquires and is at best a stop gap -- no matter what, the
ceiling is dictated by the extra acquires and it is incredibly low.

Your patch keeps the problematic acquire pattern intact and while the
80% win might sound encouraging, the end result is still severely
underperforming even a state where the lock is taken once in total
during exec.

Besides that, the internally-visible side effect of non-functional
rmap is pretty bad (and thus e.g., truncate) is pretty bad in its own
right, but let's ignore it. The primary problem here is that the patch
exposes a mechanism for userspace to dictate this in the first place.
Even ignoring the question of who should be using it and when, the
real solution to the problem would be confined to the kernel. Suppose
this patch lands and such a solution is implemented later -- now the
kernel is stuck having to support a now-useless (if not outright
harmful) feature.

What will fix the problem is sharding the state in some capacity,
provided no unfixable stopgap shows up.

Any other approach is putting small bandaids on it and can be a
consideration only if the decentralizing locking is proven too
problematic.

Pedro apparently volunteered to do the work, so I think we can wait to
see what he is going to end up cooking.

I hope this helps.