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

[Lorenzo Stoakes <ljs@kernel.org>]

On Wed, Jun 03, 2026 at 07:03:53AM +0800, Barry Song wrote:
> On Tue, Jun 2, 2026 at 11:37 PM Lorenzo Stoakes <ljs@kernel.org> wrote:
> >
> > On Tue, Jun 02, 2026 at 10:46:35AM +0800, Lance Yang wrote:
> > >
> > >
> > > On 2026/6/2 10:15, Barry Song wrote:
> > > > On Mon, Jun 1, 2026 at 9:46 AM wangtao <tao.wangtao@honor.com> wrote:
> > > > [...]
> > > > >
> > > > > You said discussion was welcome, yet when someone offered even a
> > > > > small comment, you refused to continue the discussion.
> > > > >
> > > > > If I had known you would be this inconsistent, I would not have
> > > > > replied to you in the first place.
> > > > >
> > > > > This will be my last reply to you. I will not respond again.
> > > > >
> > > >
> > > > Hi Tao,
> > > >
> > > > Please don't walk away from the linux-mm community. I read your
> > > > patchset and found it quite valuable. It not only reduces memory
> > > > overhead, but also eliminates rmap costs for exclusive folios.
> > > >
> > > > Since I'm not very confident discussing technical topics in English,
> > > > I wrote a blog post in Chinese about your patchset:
> > > >
> > > > https://mp.weixin.qq.com/s/k00tzhTl8HbL3k4G6ev4SA
> > > >
> > > > I have to admit that I found the implementation quite complex and
> > > > in need of significant improvement. However, I think the underlying
> > > > idea is very interesting and worth exploring further.
> > > >
> > > > I'm looking forward to seeing a v2 RFC with a cleaner and simpler
> > > > implementation while preserving the core concept.
> > > >
> > > > Regardless of whether it ultimately gets merged, I hope the discussion
> > > > can continue.
> > >
> > > Same here :)
> > >
> > > Tao, please don't let this thread get you down. No first RFC is
> > > perfect, and the idea still looks worth discussing :)
> > >
> > > Thanks for working on this!
> >
> > Guys, this isn't helpful.
> >
> > We aren't extending anon_vma, and I am working on replacing it, that's the
> > bottom line.
>
> Not trying to challenge your bottom line. As explained to Harry, I
> have no doubt about your expertise in rmap and many other mm
> areas, and I deeply respect your work on rmap.

Thanks I appreciate that.

I don't mean to be 'mean' here, I'm only acting in what I feel are the best
interests of mm and the kernel.

>
> With more discussion, we might gain additional insight and
> inspiration. What Tao has inspired me with is the idea that if we
> assume most real-world processes are leaf processes, could we
> simplify parts of the design?

Maybe I didn't express it clearly enough at LSF, but this is entirely a key
point of my CoW context design :)

It's true most stuff is leaf, and yes we can take advantage of this, and CoW
context allows us to do it while also unravelling the issues with anon_vma.

I am actually thinking of doing some incremental changes as part of my work
possibly if I can.

I maybe need to expedite that to bring some clarity to things here...

>
> This is why I suggested a v2, to improve the clarity of the cover
> letter and make the code easier to understand, and to see whether
> there is something worth considering further, even if it is not
> suitable for merging.

Right, I see. Again I'm really trying to tread a fine line here between the
technical discussion and not pouring more and more time into a discussion that's
not useful to me or the community.

See [0] as to my reasoning on this :)

[0]:https://lore.kernel.org/all/ah887A5VkXOcmq-g@lucifer/

>
> >
> > I have presented compelling evidence suggesting this is AI generated. In
> > response I got more AI-generated nonsense. There's no trust, the code and
> > analysis are all wrong, end of discussion.
>
> I am not an AI expert, and I do not really use AI in kernel work,
> so I am not really sure what counts as AI versus non-AI. Sorry.

No worries!

>
> >
> > >
> > > Cheers, Lance
> > >
> >
> > Thanks, Lorenzo
> >
> > P.S. maintainership is utterly thankless, and I don't really expect much in
> > return, but honestly reading this, given the case I've made here, was
> > really quite disappointing.
>
> Understood. I see your position, and I personally have great
> respect and appreciation for your work on maintenance. Sorry if
> my words came across as disappointing.

Thanks, appreciate it. And no worries!

>
> Best Regards
> Barry

Cheers, Lorenzo