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
