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

[Joseph Salisbury <joseph.salisbury@oracle.com>]

On 4/8/26 4:09 AM, David Hildenbrand (Arm) wrote:
>>> 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.
>
Currently this is only showing up with that particular stress test. We 
will try John's patch and provide feedback.

Thanks for all the feedback, everyone!