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

[wangtao]

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

Thank you very much for your reply.

As I am not very good at english, I haven't participated much in community discussions before and I'm still not very familiar with the usual process.
I realize now that I should probably have started with a discussion thread first, and that this patch series would have been more appropriate with an RFC tag. 
I apologize for that.

I will read the discussion in [1] more carefully. I also noticed the related code here:
https://git.kernel.org/pub/scm/linux/kernel/git/ljs/linux.git/log/?h=project/cow-context

Many years ago I had already noticed that data structures such as vma, page_table, and anon_vma consume a significant amount of memory.
However, since the mm subsystem is quite complex, I didn't look into it in depth at the time.
Recently, with memory costs increasing, I revisited these structures and analyzed their memory usage again. 
Since anon_vma seems to have a relatively smaller impact compared to vma and page tables, I started by exploring possible optimizations for anon_vma first.

Although anon_vma is relatively simple, there are still quite a few uncertainties.
So I waited until the basic functionality was implemented before sending the patches for discussion.

Thanks again for taking the time to reply.

--
Tao