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

[wangtao <tao.wangtao@honor.com>]

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