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

[Lorenzo Stoakes]

On Fri, May 29, 2026 at 02:20:38AM +0000, wangzicheng wrote:
> Hi Barry,
>
> Thank you for your guidance, it is very much appreciated.
>
> I work with Tao at Honor. The motivation behind this work is genuine and practical.
> The memory cost has increased significantly, and we have spent real effort investigating
> and prototyping solutions to reduce it.

Thanks, appreciate the input from your side Zicheng.

The series is unmergeable as-is, regardless of provenance.

What's unfortunate is that early discussion could have saved effort (and/or
tokens :). This is often the case with firms that develop something in-house in
isolation then present it to the community suddenly.

And as I said to Barry (+ Tao previously), the circumstances surrounding
this series are additionally very suspicious, and while we are fine with
LLM assistance where the authors fully understand it, it feels that this is
not the case here.

>
> We're happy to join "constructive" discussions and learn from the community.

So with the negativity above said, I'd really like us to move to a more
positive and constructive situation :)

One thing that is clear is that - we all want the same thing.

Reduced memory usage, reduced lock contention in the anon rmap.

So one thing that could be very useful is for you guys to help assist me
with testing of my anon rmap approach as it develops, and also provide
input, critique, and review.

I'd also love to be made aware of any testing you guys have done or input
on that, also any workloads where you have observed particularly
problematic memory usage or lock contention.

Please note that my work is currently under heavy development so the
proof-of-concept code provided is incomplete and not yet functional (it's
just there to give a sense of the shape).

I will likely provide a pre-RFC series to interested parties prior to
sending an RFC on-list.

I'd be more than happy to include you guys in that.

And as I said previously, I'm more than happy to engage in discussion
on-list or privately regarding this work :)

>
> Thanks,
> Zicheng

Cheers, Lorenzo