Re: [RFC 08/11] mm/thp: add split during migration support

[David Hildenbrand <david@redhat.com>]

On 06.03.25 05:42, Balbir Singh wrote:
> Support splitting pages during THP zone device migration as needed.
> The common case that arises is that after setup, during migrate
> the destination might not be able to allocate MIGRATE_PFN_COMPOUND
> pages.
> 
> Add a new routine migrate_vma_split_pages() to support the splitting
> of already isolated pages. The pages being migrated are already unmapped
> and marked for migration during setup (via unmap). folio_split() and
> __split_unmapped_folio() take additional isolated arguments, to avoid
> unmapping and remaping these pages and unlocking/putting the folio.
> 
> Since unmap/remap is avoided in these code paths, an extra reference
> count is added to the split folio pages, which will be dropped in
> the finalize phase.
> 
> Signed-off-by: Balbir Singh <balbirs@nvidia.com>
> ---

[...]

>   	remap_page(origin_folio, 1 << order,
>   			folio_test_anon(origin_folio) ?
>   				RMP_USE_SHARED_ZEROPAGE : 0);
> @@ -3808,6 +3823,7 @@ bool uniform_split_supported(struct folio *folio, unsigned int new_order,
>    * @lock_at: a page within @folio to be left locked to caller
>    * @list: after-split folios will be put on it if non NULL
>    * @uniform_split: perform uniform split or not (non-uniform split)
> + * @isolated: The pages are already unmapped

Isolated -> unmapped? Huh?

Can we just detect that state from the folio so we don't have to pass 
random boolean variables around?

For example, folio_mapped() can tell you if the folio is currently mapped.

-- 
Cheers,

David / dhildenb