RE: [PATCH] mm/vma: avoid redundant file rmap tree re-insert on new_below=0 split

[Deng, Pan]

> -----Original Message-----
> From: Lorenzo Stoakes (ARM) <ljs@xxxxxxxxxx>
> Sent: Saturday, September 26, 2026 12:09 AM
> To: Pedro Falcato <pfalcato@xxxxxxx>
> Cc: Deng, Pan <pan.deng@xxxxxxxxx>; akpm@xxxxxxxxxxxxxxxxxxxx;
> liam@xxxxxxxxxxxxx; vbabka@xxxxxxxxxx; jannh@xxxxxxxxxx; linux-
> mm@xxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Li, Tianyou
> <tianyou.li@xxxxxxxxx>; Guo, Wangyang <wangyang.guo@xxxxxxxxx>; Zhou,
> Zhiguo <zhiguo.zhou@xxxxxxxxx>; Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>
> Subject: Re: [PATCH] mm/vma: avoid redundant file rmap tree re-insert on
> new_below=0 split
> 
> On Fri, Sep 25, 2026 at 04:43:37PM +0100, Pedro Falcato wrote:
> > On Fri, Sep 25, 2026 at 04:27:44PM +0100, Lorenzo Stoakes (ARM) wrote:
> > > > This change skips the re-insert for that case.  vma_prepare() no longer
> > > > removes vp->vma from the tree; instead vma_complete() detects that case
> and
> > > > only recomputes shared.rb_subtree_last up the ancestor chain.  Everything
> > > > else keeps the remove + re-insert path.
> > >
> > > This could really do with a diagram and a simple explanation.
> > >
> > > In general you should rewrite the entire commit message yourself and not
> > > use the LLM output at all.
> >
> > +1 on this. Even with the Assisted-by, this needs to be understandable by
> > hoomans.
> 
> Yes.
> 
> > > >
> > > > Measured on v7.3-rc4, on a 2-socket 192C/384T system running
> UnixBench
> > > > execl (384 concurrent execve of the same binary), dropping the redundant
> > > > remove + re-insert yields ~14% higher throughput by shortening the
> > > > i_mmap_rwsem write-side critical section during the file VMA splits that
> > > > execve performs on the shared libraries.
> >
> > For what it's worth, I'm vaguely accepting of a similar change, but this needs
> > to be _really_ well commented out, and ideally in file rmap code, _not_
> > spaghetti'd in VMAs. The interval tree is complicated and some bits are not
> > very intuitive. This needs to be robust. Not LLM'd into existence.
> >
> > This also reminds me that I should reboot the sharded file rmap effort...
> 
> Indeed, which is why I'm treating this as a report rather than a patch.
> 
> A member of the core team can do the actual work.

Thanks everyone for your patience and time to review this patch.

You're right that I should not use the LLM output for commit message. As a non-native speaker, I used it to generate commit message and comments to make it read more natively, unfortunately it had an opposite effect. I'm writing by myself, from now on :)

I just saw Lorenzo has picked over this work in https://lore.kernel.org/all/20260925-speed-up-inplace-rmap-v1-1-babc48ce7c83@xxxxxxxxxx/. I've read through the new patch, which extends the scope to anonymous and covers merge and shrink scenario, more complete than I just sent, it is great. I fully agree that it is a very subtle and fragile part of the kernel, I did spend time and struggled with the patch, very appreciate your help.

One last thing, and please read it as a question rather than a request. I read submitting-patches.rst, and it says "Reported-by" tag is intended for bugs. While I wasn't reporting a bug, so would you consider "Suggested-by" instead (or even "co-developed-by") if you feel that describes it better? I'm fine with which tag you think is accurate, and I'm not trying to reopen the decision to take the work over. Again, very appreciate your review and looking forward to your help in the future.

Best Regards
Pan