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

[wangtao <tao.wangtao@honor.com>]

> >
> > Even if we could be convinced that most of this here is correct, how
> > should we reasonably maintain this increasing level of complexity here?
> 
> 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.
> 
Yes, initially it was basically patches 9, 10, and 13. Because without
distinguishing the anon_rmap and anon_vma topology, some fundamental code
logic is hard to understand, I added these two logical layers when
preparing to submit it to the community. However, this also significantly
increased the amount of code, which is not ideal.

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