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. The scan phase builds the bitmap (if mthp sizes are enabled). I tried to think if there were any similar checks we could perform; the only one that came to mind is whether the current folio size exceeds the highest enabled folio size. Is that worth checking? Cheers, -- Nico > > -- > Cheers, > > David >
