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

On Thu, May 28, 2026 at 06:45:07AM +0000, wangtao wrote:
> > >
> > > 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.

Thanks, appreciate it.

It's also for your benefit - regardless of AI usage or not, you've spent time on
this needlessly, which a discussion could have avoided.

Also as I said, going this way has damaged trust, which also doesn't benefit
anybody.

mm is a welcoming and open community, the best approach when looking at
something like this is to engage with us :)

>
> 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, I am more than happy to discuss my approach. You can also see slides
from my talk on this at LSF/MM at https://ljs.io/talks

(Note that the code linked is an incomplete implementation, simply some early
code to give a sense of the approach taken!)

I would ask, however, in general that you hold off on anything code-wise before
I am able to issue my own RFC implementing this approach so we can avoid any
overlap/confusion.

>
> Thanks again for taking the time to reply.
>
> --
> Tao
>

Cheers, lorenzo