Re: [PATCH 0/15] mm: introduce ANON_VMA_LAZY for deferred anon_vma creation
From: David Hildenbrand (Arm)
Date: Fri Jun 05 2026 - 06:59:50 EST
On 6/5/26 12:07, Lorenzo Stoakes wrote:
> On Fri, Jun 05, 2026 at 11:38:52AM +0200, David Hildenbrand (Arm) wrote:
>> On 6/4/26 05:10, xu.xin16@xxxxxxxxxx wrote:
>>>
>>> Indeed, it's very complex, but having the changes of 15 patches scattered across
>>> various subsystems is really frustrating for reviewers. It took me a whole day to
>>> read through the entire patch set, which made an already complicated matter even
>>> more complex (maintaining such complex code in the future will be a pain).
>>>
>>> However, overall, I think the original intention behind Tao's patch is innovative
>>> and valuable, and Tao could definitely make this patch set simpler and more
>>> readable, because the core changes actually start from PATCH 10.
>>>
>>> I believe that if Tao had done the following, things might have gone better and easier
>>> for reviewing. In fact, I understand the motivation behind the patch is quite simple
>>> at its core (just wanting to avoid allocating the anon_vma structure when a VMA hasn't
>>> been truly forked, and instead put the VMA information directly into folio->mapping):
>>>
>>> 1) You could actually simplify your patch significantly — without adding a lot of wrappers
>>> and helper functions that introduce extra review overhead — and keep only the most essential elements.
>>>
>>> 2) Provide complete test code (in tools/testing/selftest) that covers the affected functionality,
>>> such as VMA, huge pages, KSM, etc.
>>>
>>> 3) Use the RFC tag to start a discussion.
>>>
>>>
>>> I would be very glad to see if Tao could post a simpler v2 version that does not alter the rmap
>>> core data structures too much and does not introduce excessive complexity, no matter whether
>>> it can be merged finaly.
>>
>> I'm afraid, the overall complexity would increase in any case.
>>
>> So to quote myself "But fundamentally, I think we want to find a new design that
>> is just naturally simpler."
>
> In general I'm prioritising my work, and hope to ship something within the next
> month, even if it might just be some early bits of work on this to plumb stuff
> in, and certainly the main ting will be an RFC :)
Cool, I'll cover your back on upstream review as much as you need :)
--
Cheers,
David