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

From: Joseph Salisbury

Date: Wed Apr 08 2026 - 10:38:43 EST



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!