Re: [PATCH 0/15] mm: introduce ANON_VMA_LAZY for deferred anon_vma creation

[Pedro Falcato]

On Wed, May 27, 2026 at 07:01:32PM +0800, tao wrote:
> TL;DR
> -----
> 
> This series introduces ANON_VMA_LAZY, which defers anon_vma creation
> until it is actually required.
> 
> - anon_vma memory reduced by ~92-97%, anon_vma_chain reduced by ~50-57%  
> - rmap operations on ANON_VMA_LAZY VMAs do not require anon_vma locking
> 
> Background
> ----------
> 
> Currently anon_vma structures are created eagerly when anonymous VMAs
> are initialized. However, many VMAs never participate in fork or rmap

This is not true, they are created on fault + a few other places.

> operations that require anon_vma chains, so the allocated anon_vma and
> anon_vma_chain objects are often unnecessary.
> 
> Design overview
> ---------------
> 
> ANON_VMA_LAZY defers anon_vma allocation until it is actually needed
> (for example during fork). VMAs that never participate in sharing can
> avoid creating anon_vma structures entirely.
> 
> Before an anon_vma exists, rmap operations rely directly on VMA
> information, so no anon_vma locking is required. An anon_vma is created
> and linked only when sharing semantics are required.
> 
> This series introduces anon_rmap helpers to make rmap less dependent on
> direct anon_vma access. It also introduces anon_vma_tree_t as a container
> to support both the lazy and the existing anon_vma layouts.
> 
> Once a VMA becomes associated with an anon_vma, the normal behavior
> remains unchanged.
> 
> Memory impact
> -------------
> 
> Preliminary measurements show significant reductions in anon_vma-related
> slab allocations.
> 
> After boot:
> 
> Object            | Before (active KB) | After (active KB) | Change
> vm_area_struct    | 117035             | 118176            | +1.0%
> anon_vma_chain    | 18865.8            | 8112.06           | -57.0%
> anon_vma          | 20426.4            | 613.75            | -97.0%
> 
> After launching 24 apps:
> 
> Object            | Before (active KB) | After (active KB) | Change
> vm_area_struct    | 196873             | 197345            | +0.2%
> anon_vma_chain    | 31477.1            | 15576.8           | -50.5%
> anon_vma          | 33280              | 2648.12           | -92.0%
> 
> Simple fork microbenchmarks also show a slight improvement in fork
> performance, since child VMAs do not need to allocate anon_vma
> structures during fork.
> 
> Feedback and suggestions are welcome.

I'm afraid, per previous discussions[1], that no one is really willing to
maintain extra complexity for the current state of anon rmap and anon vmas.
Sorry :/

Also, please don't send series this large without previous discussion and
_at least_ an RFC tag.

[1] https://lore.kernel.org/all/aec533b2-37a7-4f44-a279-c4aa604206ac@lucifer.local/

-- 
Pedro