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

[Barry Song]

On Fri, Apr 10, 2026 at 6:30 PM Pedro Falcato <pfalcato@xxxxxxx> wrote:
>
> 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.

This is true, but I feel this might be the low-hanging fruit that should
at least be able to halve the contention, since the implementation would
be small.

>
> 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).

For MADV_POPULATE, I guess your idea can work. But I assume
MADV_POPULATE is not that widely used?

>
> 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.

We already have this concept in MGLRU, where each zone has its own
LRU lists (but all zones still share the same LRU lock).

With superpageblock, I feel the difficulty is how to balance between
different superpageblocks, and how to compare the aging of folios
across them.

Thanks
Barry