Re: [PATCH] mm/vma: predicate vma_assert_stabilised() on CONFIG_DEBUG_VM

[Pedro Falcato]

On Tue, Nov 10, 2026 at 05:37:27PM +0000, Lorenzo Stoakes (ARM) wrote:
> On Tue, Nov 10, 2026 at 05:32:17PM +0000, Seunghyun An wrote:
> > On Tue, Nov 10, 2026 at 03:10:40PM +0000, Lorenzo Stoakes (ARM) wrote:
> > > I introduced commit 17fd82c3abe0 ("mm/vma: add and use
> > > vma_assert_stabilised()") with the intent of picking up programmatic bugs
> >
> > Tested on an AMD EPYC 9634 (84 cores, 12 CCDs), CONFIG_DEBUG_VM=n.
> > Applied on d48723711bae; base and patched were measured on the same day.
> > Throughput figures are in faults/s; JVM pretouch time is in ms.
> >
> >                               base      patched
> >   shared-VMA faults, 7 CCDs   1.776M    1.917M   +7.9%
> >   shared-VMA faults, 12 CCDs  2.303M    2.431M   +5.6%
> >   pft, 7 CCDs                 1.910M    2.126M  +11.3%
> >   pft, 84 cores               4.201M    5.028M  +19.7%
> >   JVM G1 pretouch (32G)       1877 ms   1672 ms -10.9%
> >
> > Tested-by: Seunghyun An <san55@xxxxxxxx>
> 
> Thanks!
> 
> >
> > As a follow-up, I also checked whether avoiding the __vm_anon_pgoff_hi
> > read in __folio_set_anon() provides any further benefit. For comparison,
> > I tested my earlier patch 1 on top, which computes the index from
> > vm_pgoff for anonymous VMAs and avoids that read:
> >
> >                               this patch  + patch 1
> >   shared-VMA faults, 12 CCDs  2.431M      2.941M   +21%
> >   pft, 12 CCDs                2.434M      3.474M   +43%
> >
> > With pft on 12 CCDs, this patch alone is essentially unchanged from
> > base (2.442M faults/s). The additional improvement with patch 1 suggests
> > that avoiding the __vm_anon_pgoff_hi read may be worth investigating on
> > CPUs with high coherency costs between L3 cache domains.
> 
> OK that suggests there are cases other than the one you mentioned that have
> an issue.
> 
> I'm disinclined to do something like that patch, as it's rather a hack.
> 
> Cna you give me the workload you're actually exercising here? Ideally
> something that's easy for me to run + analyse locally.
> 
> I have a zen 5 with 8 CCDs so can probably exercise some stuff over here.

FWIW, some thoughts:

I don't think this is worth worrying about. For starters, the vm_refcnt
cacheline will _always_ be a point of contention, and in extreme page
faulting cases (like the benchmarks Senghyun is running) it will be
dirtied to hell. Say you want to naively get this refcount its own cacheline.
Ok, fine. You're now wasting 56 bytes of a VMA just for padding. Can we fit
more stuff in there? Ehh, kind of, but not really. In theory, perhaps struct
{} shared or the anon_vma_chain that can sometimes change. But those aren't
written to often anyway (certainly not the AVC).

On the other hand, can we get rid of this contention completely? Probably!
But also maybe not. You could try and replace the vm_refcnt with a percpu
counter. That could work, but the percpu allocator does not scale. That would
need to be addressed first.

Theoretically, were per-vma locking structured differently, you could try and
resolve page faults fully under RCU, without needing to write anywhere. It's
a nice thought, but atm is super unfeasible.

Finally, since this is a microbenchmark, I'm not sure this is worth thinking
about. Do we have (many? any?) cases where real world benchmarks hammer
page faults hard (especially on one single VMA) enough where you can see
cacheline contention? I would wager that's not very common.

-- 
Pedro