Re: [PATCH 1/2] mm/rmap: use vm_pgoff for anonymous VMAs in linear_anon_page_index()

[Pedro Falcato <pfalcato@suse.de>]

On Mon, Nov 09, 2026 at 06:00:01PM -0600, Seunghyun An wrote:
> __vm_anon_pgoff_hi sits right after vm_refcnt in the vm_refcnt
> cacheline. Since commit 93c0c8dc87f6 ("mm/rmap: use anon pgoff to track
> MAP_PRIVATE file-backed anon folios"), which made anon rmap use it,
> __folio_set_anon() reads it on every new anonymous folio, i.e. once per
> fault that maps a new anonymous page, between vma_start_read() and
> vma_end_read().
> 
> When several threads fault on the same VMA, the other CPUs keep writing
> vm_refcnt from vma_start_read()/vma_end_read(), so this read often
> misses and pulls the line over. The extra load can force a coherence
> transfer and makes the following vm_refcnt updates more expensive.
> 
> For anonymous VMAs the anonymous page offset is always equal to vm_pgoff
> (linear_anon_page_index() already asserts this under CONFIG_DEBUG_VM;
> it holds for MAP_PRIVATE /dev/zero too since commit e59c9a971a9f
> ("mm/vma: make MAP_PRIVATE-mapped /dev/zero mappings truly anonymous")),
> so compute the index from vm_pgoff as before. That brings back the
> pre-series behaviour for the hot path; MAP_PRIVATE file-backed VMAs still
> read the split field. Keep the assertion, the other way round.
> 
> Moving __vm_anon_pgoff_hi out of the line does not work without growing
> vm_area_struct. With e.g. CONFIG_ANON_VMA_NAME=y the struct is exactly
> 192 bytes, cachelines 0 and 1 have no hole, and the only 4-byte fields
> that could fill the slot next to vm_refcnt are vm_lock_seq and the lo/hi
> halves. vm_lock_seq is read before vm_refcnt is taken in vma_start_read(),
> so it would just move the miss.
> 

I trust Lorenzo knows more about his plans to use anon_pgoff than I do,
so I'll let him reply. A comment though:

> Measured on an AMD EPYC 9634 (84 cores, 12 CCDs, CONFIG_DEBUG_VM=n), on
> mainline after v7.4-rc1 (the base of this series). Threads share one
> anonymous VMA, each faults its own slice and zaps it with MADV_DONTNEED;
> faults/s, median of 3:
> 
>   CPUs                      base      patched
>   1 CCD,   7 threads        2.360M    2.369M   +0.4%
>   7 CCDs,  1 thread each    1.738M    1.982M  +14.0%

This is not particularly surprising. CCDs have their own L3 cache. I'm not
surprised the coherency penalty is much higher cross-CCD.

-- 
Pedro