答复: [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]

First of all, I am truly sorry for not using RFC.
Secondly, I omitted many maintainers because I wanted to “not disturb too many people”, 
and I apologize deeply for that. I will fully follow these two rules from now on.

As for this patch, indeed, as Matthew said, the truncate part is not feasible. 
My original intention was to apply this to frequently used library files like libc and ld.
Contention on the i_mmap_rwsem lock (which eventually turns into osq_lock) caused by
these two files alone reaches up to 70% in the “256-core execl” case, as observed from
flame graphs. Besides, no one performs truncate operations on libc and ld anyway.

So I wanted to try skipping rmap for them. Since they are small, even if they cannot
be reclaimed or migrated, I assumed it would not cause much trouble. Of course,
this idea was totally wrong, and I will definitely mark such insane proposals with RFC in the future.

These ideas are inspired by Mateusz’s work and thoughts
(https://lore.kernel.org/linux-mm/CAGudoHEfiOPJ2VGEV3fDT9cDsuoHB-wk8jg-k-EK6JhWgiHkWw@mail.gmail.com/),
so I specifically CC’d him to seek more opinions and insights.

Lastly, I sincerely apologize for the trouble I have caused the community.
I will strictly follow community conventions when sending patches in the future.

> 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.
> ... ...
> ... ...
> 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

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

[Lorenzo Stoakes]

On Wed, Apr 22, 2026 at 12:51:06PM +0000, Yibin Liu wrote:
> First of all, I am truly sorry for not using RFC.
> Secondly, I omitted many maintainers because I wanted to “not disturb too many people”,
> and I apologize deeply for that. I will fully follow these two rules from now on.
>
> As for this patch, indeed, as Matthew said, the truncate part is not feasible.
> My original intention was to apply this to frequently used library files like libc and ld.
> Contention on the i_mmap_rwsem lock (which eventually turns into osq_lock) caused by
> these two files alone reaches up to 70% in the “256-core execl” case, as observed from
> flame graphs. Besides, no one performs truncate operations on libc and ld anyway.

Interesting, would be good to see these? And more details on the scenario?

What workloads are contending that exactly?

>
> So I wanted to try skipping rmap for them. Since they are small, even if they cannot
> be reclaimed or migrated, I assumed it would not cause much trouble. Of course,
> this idea was totally wrong, and I will definitely mark such insane proposals with RFC in the future.
>
> These ideas are inspired by Mateusz’s work and thoughts
> (https://lore.kernel.org/linux-mm/CAGudoHEfiOPJ2VGEV3fDT9cDsuoHB-wk8jg-k-EK6JhWgiHkWw@mail.gmail.com/),
> so I specifically CC’d him to seek more opinions and insights.

I think the best thing in general going forwards is to bring up this issues in
advance, we're more than happy to look into things and very interested in issues
with lock contention, latency, etc.

And that way you can discuss ideas you might have to tackle up front and we can
give you early feedback, which should save time all round and help get us to a
good solution :)

Just send with a [DISCUSSION] preface and cc- people you feel are relevant (use
MAINTAINERS to figure out e.g. maintainers of relevant things, like rmap, mmap,
etc.)

>
> Lastly, I sincerely apologize for the trouble I have caused the community.
> I will strictly follow community conventions when sending patches in the future.

It's no problem, better to be direct about this - it's more useful to discuss
rather than to jump to a solution without community involvement, which might not
work out/conflict with other stuff etc.

Thanks, Lorenzo

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

[Yibin Liu]

> 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.
> 
Thank you for your opnions and advices, I'll try this way
> 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.
OK. I understand it now.
> 
> 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.
>