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 <[email protected]> >> --- > > [...] > >> 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/[email protected]/. I will make some polish and send it out properly. Best Regards, Yan, Zi
