On 4/13/26 03:38, Nico Pache wrote: > On Thu, Mar 12, 2026 at 3:00 PM David Hildenbrand (Arm) > <[email protected]> wrote: >> >> On 2/26/26 04:24, Nico Pache wrote: >>> khugepaged may try to collapse a mTHP to a smaller mTHP, resulting in >>> some pages being unmapped. Skip these cases until we have a way to check >>> if its ok to collapse to a smaller mTHP size (like in the case of a >>> partially mapped folio). >>> >>> This patch is inspired by Dev Jain's work on khugepaged mTHP support [1]. >>> >>> [1] https://lore.kernel.org/lkml/[email protected]/ >>> >>> Reviewed-by: Lorenzo Stoakes <[email protected]> >>> Reviewed-by: Baolin Wang <[email protected]> >>> Co-developed-by: Dev Jain <[email protected]> >>> Signed-off-by: Dev Jain <[email protected]> >>> Signed-off-by: Nico Pache <[email protected]> >>> --- >>> mm/khugepaged.c | 8 ++++++++ >>> 1 file changed, 8 insertions(+) >>> >>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c >>> index fb3ba8fe5a6c..c739f26dd61e 100644 >>> --- a/mm/khugepaged.c >>> +++ b/mm/khugepaged.c >>> @@ -638,6 +638,14 @@ static enum scan_result >>> __collapse_huge_page_isolate(struct vm_area_struct *vma, >>> goto out; >>> } >>> } >>> + /* >>> + * TODO: In some cases of partially-mapped folios, we'd >>> actually >>> + * want to collapse. >>> + */ >>> + if (!is_pmd_order(order) && folio_order(folio) >= order) { >>> + result = SCAN_PTE_MAPPED_HUGEPAGE; >>> + goto out; >>> + } >>> >>> if (folio_test_large(folio)) { >>> struct folio *f; >> >> Why aren't we doing the same in hpage_collapse_scan_pmd() ? > > We can't do this in the scan phase because we are not yet aware of the > order we want to collapse to.
Yes, realized that myself later. It's confusing, try documenting that in the patch description. -- Cheers, David
