Re: [RFC] mm: stress-ng --mremap triggers severe lruvec lock contention in populate/unmap paths

[David Hildenbrand (Arm)]

>>
>> It was also found that adding '--mremap-numa' changes the behavior
>> substantially:
> 
> "assign memory mapped pages to randomly selected NUMA nodes. This is
> disabled for systems that do not support NUMA."
> 
> so this is just sharding your lock contention across your NUMA nodes (you
> have an lruvec per node).
> 
>>
>> stress-ng --mremap 8192 --mremap-bytes 4K --timeout 30 --mremap-numa
>> --metrics-brief
>>
>> mremap 2570798 29.39 8.06 106.23 87466.50 22494.74
>>
>> So it's possible that either actual swapping, or the mbind(...,
>> MPOL_MF_MOVE) path used by '--mremap-numa', removes most of the excessive
>> system time.
>>
>> Does this look like a known MM scalability issue around short-lived
>> MAP_POPULATE / munmap churn?
> 
> Yes. Is this an actual issue on some workload?

Same thought, it's unclear to me why we should care here. In particular,
when talking about excessive use of zero-filled pages.

-- 
Cheers,

David