[RFC 08/11] mm/thp: add split during migration support
Zi Yan
ziy at nvidia.com
Tue Jul 8 14:46:24 UTC 2025
On 8 Jul 2025, at 10:38, David Hildenbrand wrote:
> 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 at 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.
My proposal is to clean up __split_unmapped_folio() to not include
remap(), folio_ref_unfreeze(), lru_add_split_folio(), so that Balbir
can use __split_unmapped_folio() directly. Since the folio is
unmapped and all page table entries are migration entries, __folio_split()
code could be avoided.
My clean up patch is at: https://lore.kernel.org/linux-mm/660F3BCC-0360-458F-BFF5-92C797E165CC@nvidia.com/. I will make some polish and send it out properly.
Best Regards,
Yan, Zi
More information about the dri-devel
mailing list