On Sun, May 31, 2026 at 10:18:16PM +0200, David Hildenbrand (Arm) wrote: > On 5/22/26 17:00, Nico Pache wrote: > > Add collapse_allowable_orders() to generalize THP order eligibility. The > > function determines which THP orders are permitted based on collapse > > context (khugepaged vs madv_collapse). > > > > This consolidates collapse configuration logic and provides a clean > > interface for future mTHP collapse support where the orders may be > > different. > > It would have been good to describe here that, for now, it only ever returns > PMDs, and that it will be extended next. > > Logically, this patch belongs to #12, not #11 ... so seeing it before #11 was > a bit > > ... and there, it is clear that we don't even want to know the orders? > > So can we just call this function > > "collapse_possible" and make it return a boolean?
Yeah agreed. But I also don't love the naming, we now have thp_vma_allowable_orders(), __thp_vma_allowable_orders(), and then collapse_allowable_orders() and we also have 3 different ways of collapsing, one of which we call MADV_... COLLAPSE, and the other khugepaged + fault-in too for laughs. It's like a big circle of confusion. And of course we call THP collapse 'collapse' in general, so :) Anyway I'm fine with collapse_possible() so we can move on and then maybe cleanup later. Also - if I look at khugepaged.c I see thp_vma_allowable_orders() still used in hugepage_vma_revalidate(). Wouldn't it be better then to do the abstraction once mTHP order checking is properly introduced and change this also and have _every_ order check be consistent in khugepaged.c? > > > > > Reviewed-by: Baolin Wang <[email protected]> > > Signed-off-by: Nico Pache <[email protected]> > > --- > > mm/khugepaged.c | 15 ++++++++++++--- > > 1 file changed, 12 insertions(+), 3 deletions(-) > > > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c > > index 4534025bc81d..64ceebc9d8a7 100644 > > --- a/mm/khugepaged.c > > +++ b/mm/khugepaged.c > > @@ -552,12 +552,21 @@ void __khugepaged_enter(struct mm_struct *mm) > > wake_up_interruptible(&khugepaged_wait); > > } > > > > +/* Check what orders are allowed based on the vma and collapse type */ I'd expand this comment to explain that it's explicitly for accounting for whether mTHP is used, but that also argues for this to be moved to a later commit as David says. Otherwise the comment is useless. > > +static unsigned long collapse_allowable_orders(struct vm_area_struct *vma, > > + vm_flags_t vm_flags, enum tva_type tva_flags) > > +{ > > + unsigned long orders = BIT(HPAGE_PMD_ORDER); Could be a const also. > > + > > + return thp_vma_allowable_orders(vma, vm_flags, tva_flags, orders); > > +} > > + > > void khugepaged_enter_vma(struct vm_area_struct *vma, > > vm_flags_t vm_flags) > > { > > if (!mm_flags_test(MMF_VM_HUGEPAGE, vma->vm_mm) && > > hugepage_pmd_enabled()) { > > - if (thp_vma_allowable_order(vma, vm_flags, TVA_KHUGEPAGED, > > PMD_ORDER)) > > + if (collapse_allowable_orders(vma, vm_flags, TVA_KHUGEPAGED)) I hate that we separate out the VMA flags like this just for this case, but that's something for a follow up probably from me as part of a VMA flags conversion series... > > __khugepaged_enter(vma->vm_mm); > > } > > } > > @@ -2680,7 +2689,7 @@ static void collapse_scan_mm_slot(unsigned int > > progress_max, > > cc->progress++; > > break; > > } > > - if (!thp_vma_allowable_order(vma, vma->vm_flags, > > TVA_KHUGEPAGED, PMD_ORDER)) { > > + if (!collapse_allowable_orders(vma, vma->vm_flags, > > TVA_KHUGEPAGED)) { > > cc->progress++; > > continue; > > } > > @@ -2989,7 +2998,7 @@ int madvise_collapse(struct vm_area_struct *vma, > > unsigned long start, > > BUG_ON(vma->vm_start > start); > > BUG_ON(vma->vm_end < end); > > > > - if (!thp_vma_allowable_order(vma, vma->vm_flags, TVA_FORCED_COLLAPSE, > > PMD_ORDER)) > > + if (!collapse_allowable_orders(vma, vma->vm_flags, TVA_FORCED_COLLAPSE)) > > return -EINVAL; > > > > cc = kmalloc_obj(*cc); > > Having a simple > > static bool collapse_possible(...) > { > return collapse_allowable_orders(...) > } > > Would make the above slightly more readable. Yup. > > Acked-by: David Hildenbrand (Arm) <[email protected]> > > -- > Cheers, > > David Cheers, Lorenzo
