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

[Lorenzo Stoakes]

On Thu, May 28, 2026 at 07:11:19AM +0000, wangtao wrote:
>
>
> > Subject: Re: [PATCH 0/15] mm: introduce ANON_VMA_LAZY for deferred
> > anon_vma creation
> >
> > I'm sorry but this is not how kernel development is done.
> >
> > You're sending a series that's very invasive, that you've not coordinated with
> > anybody else, nor have you mentioned it at a conference, nor engaged with
> > in discussion with anybody else in the community in any way.
> >
> > And you've sent it without an RFC, at -rc5 is... quite something.
> >
> > We do NOT want to extend or expand or hack in anything like this on top of
> > the existing anon_vma machinery. It's a mess that requires replacement, not
> > more hacks or expansion.
> >
> > I've been working on a replacement for the anonymous rmap, recently
> > presenting at LSF/MM, and all of that has been very public.
> >
> > In fact I have engaged in recent work which reduced lock contention in
> > anon_vma, it's really quite discourteous for you not to have contacted me or
> > the community in addition to the above.
> >
> First of all, thank you very much for your reply.
>
> I'm also glad to learn that you have been working on optimizations
> related to anon_vma. I noticed your work from another email in the
> thread.
>
> I apologize if my approach caused any inconvenience. My English is not
> very good, and I have rarely participated in community discussions
> before, so I'm still learning how things are usually done in the
> kernel community. If anything I did came across as discourteous, please
> understand that it was not my intention.
>
> Recently, due to increasing memory costs, I revisited the memory usage
> of anon_vma and found that it might be possible to reduce its
> overhead.
>
> My original intention was simply to experiment with an anon_vma_lazy
> mechanism to reduce the memory footprint of anon_vma. However, while
> working on it I realized that anon_vma handling is quite complex. In
> particular, after multiple levels of fork the topology of anonymous
> pages can become quite complicated, and it also interacts with other
> subsystems such as reclaim, KSM, and migration.
>
> Because of this, I tried separating the functionality of anon_vma
> into two parts: anon_rmap_t for anonymous page reverse mapping, and
> anon_vma_tree_t for topology management.
>
> anon_rmap_t provides the reverse mapping interface used by reclaim,
> KSM, migration, and similar components.
>
> anon_vma_tree_t manages the topology internally for operations such
> as fork, clone, split, and merge, and can also indicate whether a
> VMA has experienced page faults.
>
> My hope is that by separating these responsibilities, it may become
> easier to reason about and further improve the anon_vma design in the
> future.

I understand your approach, as discussed it's not viable.

As mentioned elsewhere, please refrain from further code contributions to
rmap, as there is now a trust issue due to a high likelihood of undeclared
AI-generated code.

You are, however, welcome to engage in discussion, and I'm happy to discuss
the approach publicly on list or via private email whichever you prefer :)

You are also welcome to engage in discussion/review/critique once I produce
my RFC for this.

Thanks, Lorenzo