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

[Harry Yoo <harry@kernel.org>]

[-- Attachment #1.1: Type: text/plain, Size: 3099 bytes --]



On 6/2/26 11:15 AM, 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
The cover letter and commit messages should have been elaborated to a
much greater degree instead of making people guess the design and intent
from the code.

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

No. What it is trying to achieve is ambitious, but the idea itself is
not worth exploring further as-is unless the correctness and complexity
concerns are addressed.

> I'm looking forward to seeing a v2 RFC with a cleaner and simpler
> implementation while preserving the core concept.

I'm afraid this encouragement would mislead us in the wrong direction,
where all of us end up wasting time.

There isn't much point in posting v2 without addressing fundamental
questions about the design.

> Regardless of whether it ultimately gets merged, I hope the discussion
> can continue.

Regarding the "improving the reverse mapping subsystem" topic, a more
constructive direction would be to carefully revisit the design
decisions and discuss what we can do about them (that's exactly what
Lorenzo has been doing).

But that's not the first thing I would recommend to a relatively new
contributor given that it's really complicated and even the people who
have designed and reworked the reverse mapping subsystem over the past
20+ years haven't come up with a fundamentally better design.

Reverse mapping is a frustratingly complicated subsystem. Without
carefully revisiting the current design, there is not much hope of
improving things at the design level, even slightly.

What I would recommend to new people instead is:

1) starting by reviewing other people's work, so that you have enough
time to learn the historical context and subtleties of the subsystem
without making intrusive changes (which also keeps in touch with the
community), and

2) making progress on smaller tasks with less intrusive changes, to
gradually build trust and be able to do more valuable work.

Unfortunately, looking at how this thread went, I see that the author is
now in a worse position than an entirely new contributor.

-- 
Cheers,
Harry / Hyeonggon

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]