Re: [PATCH v4 14/20] mm/rmap: use anon pgoff to track MAP_PRIVATE file-backed anon folios

On 8/6/26 22:21, Lorenzo Stoakes (ARM) wrote:
> Currently anonymous folios belonging to CoW'd MAP_PRIVATE file-backed
> mappings are indexed by their page offset within the file in which they
> were originally mapped.
> 
> This differs from anonymous folios belonging to pure anon mappings which
> are indexed by their anonymous page offset (the address at which they'd
> belong in the VMA when first faulted).
> 
> This change fixes this inconsistency, always indexing anonymous folios by
> their anonymous page offset regardless of the VMA to which they belong.
> 
> The foundations have been laid such that we need only switch this
> functionality on such by:
> 
> * Using linear_anon_page_index() in __folio_set_anon() to assign the
>   folio's index to the anonymous linear index rather than the file-backed
>   one.
> 
> * Otherwise using linear_anon_page_index() in all instances where
>   anonymous folios are being referenced or manipulated.
> 
> * Replacing vma_address() with vma_filebacked_address() or
>   vma_anon_address() as appropriate.
> 
> * Updating the merging logic to check that anonymous page offsets are
>   aligned as well as filebacked ones for MAP_PRIVATE file-backed VMAs,
>   introducing needs_adjacent_anon_pgoff() to figure out when this is
>   required.
> 
> * Updating linear_folio_page_index() to invoke linear_anon_page_index()
>   if the folio is anonymous.
> 
> * Updating vma_address_end() to use the VMA's anonymous page offset when
>   pvmw->pgoff is anonymous.
> 
> * Correcting folio_within_range() to use anonymous page offset for
>   anonymous folios.
> 
> This will have no impact on merging of anonymous VMAs, whose page offset
> and anonymous page offset are identical, nor will it impact shared
> file-backed VMAs, which will continue to be merged based on the file-backed
> page offset.
> 
> However, MAP_PRIVATE file-backed mappings must now be aligned on anonymous
> page offset as well.
> 
> In most instances this should have no impact on merging of file-backed
> mappings, which are usually not merged all that often, let alone
> MAP_PRIVATE mapped ones, and rarely remapped and faulted before being moved
> back in place (the case in which a merge may now fail).
> 
> One subtle impact of this change is in NUMA interleaving - since commit
> 88c91dc58582 ("mempolicy: migration attempt to match interleave nodes"),
> migration heuristically tries to maintain interleaving behaviour matching
> the policy using folio indices.
> 
> When doing migration of CoW'd MAP_PRIVATE-file backed ranges, the 'base'
> upon which the interleaving behaviour is performed will vary for these
> ranges. However the commit notes that ranges spanning multiple VMAs will
> already cause varying bases, and that this is an acceptable approximation.
> 
> It is very unlikely real world use-cases will be impacted by
> this (MAP_PRIVATE file-backed mappings are already an edge case), and all
> that will happen is that such ranges will cause interleaving to be rotated
> over the CoW'd range, with little to no impact.
> 
> This commit lays the foundations for future scalable CoW work which needs
> to track some remaps, meaning that most remap tracking can be avoided, and
> in nearly all cases the anonymous page offset will be able to be used to
> quickly find the VMA in an mm.
> 
> Note that the need_rmap_locks check doesn't need to be updated, as any
> remapping will offset both the anonymous and file-backed page offset, so it
> suffices to check only one.
> 
> Signed-off-by: Lorenzo Stoakes (ARM) <[email protected]>
> ---

Acked-by: David Hildenbrand (Arm) <[email protected]>

-- 
Cheers,

David