Re: [LSM/MM/BPF TOPIC] The Future of the Anonymous Reverse Mapping

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

On Thu, Feb 19, 2026 at 12:25:47PM -0800, Suren Baghdasaryan wrote:
> On Thu, Feb 19, 2026 at 11:28 AM Lorenzo Stoakes
> <lorenzo.stoakes@oracle.com> wrote:
> >
> > Currently we track the reverse mapping between folios and VMAs at a VMA level,
> > utilising a complicated and confusing combination of anon_vma objects and
> > anon_vma_chain's linking them, which must be updated when VMAs are split,
> > merged, remapped or forked.
> >
> > It's further complicated by various optimisations intended to avoid scalability
> > issues in locking and memory allocation.
> >
> > I have done recent work to improve the situation [0] which has also lead to a
> > reported improvement in lock scalability [1], but fundamentally the situation
> > remains the same.
> >
> > The logic is actually, when you think hard enough about it, is a fairly
> > reasonable means of implementing the reverse mapping at a VMA level.
> >
> > It is, however, a very broken abstraction as it stands. In order to work with
> > the logic, you have to essentially keep a broad understanding of the entire
> > implementation in your head at one time - that is, not much is really
> > abstracted.
> >
> > This results in confusion, mistakes, and bit rot. It's also very time-consuming
> > to work with - personally I've gone to the lengths of writing a private set of
> > slides for myself on the topic as a reminder each time I come back to it.
> >
> > There are also issues with lock scalability - the use of interval trees to
> > maintain a connection between an anon_vma and AVCs connected to VMAs requires
> > that a lock must be held across the entire 'CoW hierarchy' of parent and child
> > VMAs whenever performing an rmap walk or performing a merge, split, remap or
> > fork.
> >
> > This is because we tear down all interval tree mappings and reestablish them
> > each time we might see changes in VMA geometry. This is an issue Barry Song
> > identified as problematic in a real world use case [2].
> >
> > So what do we do to improve the situation?
> >
> > Recently I have been working on an experimental new approach to the anonymous
> > reverse mapping, in which we instead track anonymous remaps, and then use the
> > VMA's virtual page offset to locate VMAs from the folio.
> >
> > I have got the implementation working to the point where it tracks the exact
> > same VMAs as the anon_vma implementation, and it seems a lot of it can be done
> > under RCU.
>
> Do you have a link to the code we can look at before the discussion?

The code is in a really early stage and being constantly changed so _not yet_
but I'll put it somewhere public once it's settled down.

It's also currently just a case of the implementation is side-by-side the
existing anon_vma stuff, with code in rmap_walk_anon() also kicking off a cow
context walk then comparing the count of discovered matching folios.

The code will of course eventually

>
> >
> > It avoids the need to maintain expensive mappings at a VMA level, though it
> > incurs a cost in tracking remaps, and MAP_PRIVATE files are very much a TODO
> > (they maintain a file vma->vm_pgoff, even when CoW'd, so the remap tracking is
> > pretty sub-optimal).
> >
> > I am investigating whether I can change how MAP_PRIVATE file-backed mappings
> > work to avoid this issue, and will be developing tests to see how lock
> > scalability, throughput and memory usage compare to the anon_vma approach under
> > different workloads.
> >
> > This experiment may or may not work out, either way it will be interesting to
> > discuss it.
>
> I'm interested in this discussion. Hopefully this will result in
> simpler rmap code and reduced lock contention.
> Thanks,
> Suren.

Thanks, I am keen to extract numbers from this and use that to guide the
implementation - I want this to be an evidence-based improvement rather than
simply a rework of some kind :)

If the proposed solution causes meaningful regressions then I will look to an
alternative approach, either way I think it's important to base as much as
possible on actual observed numbers.

I hope to implement benchmarking/test code as part of this work which should be
useful regardless of the approach taken.

When I have this more developed I may ask people to help test this on different
hardware/clusters/etc. to ensure stability and assess impact, so don't be
surprised if I ask for a favour at this point :)

>
> >
> > By the time LSF/MM comes around I may even have already decided on a different
> > approach but that's what makes things interesting :)
> >
> > [0]:https://lore.kernel.org/all/cover.1767711638.git.lorenzo.stoakes@oracle.com/
> > [1]:https://lore.kernel.org/all/202602061747.855f053f-lkp@intel.com/
> > [2]:https://lore.kernel.org/linux-mm/CAGsJ_4x=YsQR=nNcHA-q=0vg0b7ok=81C_qQqKmoJ+BZ+HVduQ@mail.gmail.com/
> >
> > Cheers, Lorenzo
>

Cheers, Lorenzo