On 08.07.25 16:46, Zi Yan wrote:
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.
Works for me as well.
--
Cheers,
David / dhildenb
