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

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