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

[wangtao]

> > Previously, I also considered converting anon_vma's rb_tree to a
> > mapletree. If one entry records a single VMA, the average overhead
> > could be less than two longs per VMA.
> >
> > However, unlike rb_tree, mapletree does not support storing multiple
> > elements under a single key. The key would need to look like
> > (vma_id/mm_id + pgoff). On 32-bit platforms, since 64-bit mapletree
> > keys are not supported yet, the remaining
> > 12 bits are not enough for vma_id/mm_id.
> >
> > Because of this limitation, I later started thinking about ways to
> > reduce anon_vma allocations instead.
> >
> > I will try to find some time next week to analyze the cow-context
> > design and code more thoroughly, and then write up a summary.
> 
> Tao,
> 
> This response is so full of misunderstandings it's not really worth me
> responding to any of it. You've even hallucinated an imaginary field which is
> REALLY suspicious.
> 
> You've no mm expertise or history and came up with this in a few hours. I
> asked Claude to analyse it and it puts it at 75-80% chance of being solely LLM-
> generated from cow_context.c.
> 
> I simply don't have the time to deal with this, so unfortunately I'm going to
> have to withdraw the suggestion of further discussion with you on this topic.
> 
> I am working on the scalable CoW project and will solicit opinions of those
> with relevant expertise.
> 
> We are not interested in your approach or analysis.
> 
> Thanks, Lorenzo

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.

Consider the following test case:
Process P creates 1000 VMAs with mmap, named vma_1, vma_2, ...,  
vma_1000.

Then it forks child processes C_1, C_2, ..., C_1000. Each child  
process C_k keeps only vma_k and munmaps all other vma_i.

With the current anon_vma, reclaim walking each page only needs  
to handle two VMAs (vma_k in process P and vma_k in process C_k).

But under the CoW approach, reclaiming each page needs to walk  
1000 processes, then spend O(log(#remap_entries)) time to check  
whether a remap_entry exists, and then O(log(#vmas)) time to  
locate the VMA.

Both the code complexity and the time complexity of the reverse  
walk are much higher than the current anon_vma approach.