David Hildenbrand
2025-Jul-08 14:38 UTC
[RFC 08/11] mm/thp: add split during migration support
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 unmappedIsolated -> 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
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 at nvidia.com/. I will make some polish and send it out properly. Best Regards, Yan, Zi