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

[Pedro Falcato]

On Fri, Apr 10, 2026 at 05:59:58AM +0800, Barry Song wrote:
> On Wed, Apr 8, 2026 at 4:09 PM David Hildenbrand (Arm) <david@xxxxxxxxxx> 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.
> 
> About 2–3 years ago, I had the impression that we might need
> separate LRU locks for file and anon. This could reduce
> contention in real-world scenarios, especially when memcg is
> not enabled, but I never built a prototype for it.

Honestly, I don't think this would work. You will still contend hard.
Having a lock for file and a lock for anon just makes two very large
locks, instead of one gigalarge lock.

I think the real solution is either sharding lruvecs harder[1], percpu-caching
super-harder, or fully reworking reclaim such that we don't need to maintain
such a global list.

Alas, maybe we'll get there one day :)

For MADV_POPULATE there might be a straightforward solution, though. Using
something akin to blk_plug, maintain a per-cpu (or per-task?) list of pages
that need to be queued. reclaim would drain these lists if needed, or the
task doing MADV_POPULATE drains them at the end. It should drastically
reduce lruvec lock traffic (though yes, possibly just another bandaid).

I say "For MADV_POPULATE" simply because I suspect this idea might not be
useful or effective for regular page faulting.

[1] say, maintain a superpageblock concept that is a lot larger than a pageblock
(1GB could work? though maybe too small for large machines) and maintain LRU
ordering between those pages. though later approximating LRU order between
the superpageblocks is tricky.
-- 
Pedro