Re: [PATCH mm-unstable v18 12/14] mm/khugepaged: avoid unnecessary mTHP collapse attempts

[Lance Yang]

On 2026/6/1 04:02, David Hildenbrand (Arm) wrote:
> On 5/31/26 09:31, Lance Yang wrote:
> > On Fri, May 22, 2026 at 09:00:07AM -0600, Nico Pache wrote:
> > > There are cases where, if an attempted collapse fails, all subsequent
> > > orders are guaranteed to also fail. Avoid these collapse attempts by
> > > bailing out early.
> > >
> > > Reviewed-by: Lorenzo Stoakes <ljs@xxxxxxxxxx>
> > > Acked-by: Usama Arif <usama.arif@xxxxxxxxx>
> > > Acked-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>
> > > Signed-off-by: Nico Pache <npache@xxxxxxxxxx>
> > > ---
> > > mm/khugepaged.c | 24 +++++++++++++++++++++++-
> > > 1 file changed, 23 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > > index d3d7db8be26c..15b7298bc225 100644
> > > --- a/mm/khugepaged.c
> > > +++ b/mm/khugepaged.c
> > > @@ -1535,9 +1535,31 @@ static int mthp_collapse(struct mm_struct *mm, struct vm_area_struct *vma,
> > > 			collapse_address = address + offset * PAGE_SIZE;
> > > 			ret = collapse_huge_page(mm, collapse_address, referenced,
> > > 						 unmapped, cc, order);
> > > -			if (ret == SCAN_SUCCEED) {
> > > +
> > > +			switch (ret) {
> > > +			/* Cases where we continue to next collapse candidate */
> > > +			case SCAN_SUCCEED:
> > > 				collapsed += nr_ptes;
> > > +				fallthrough;
> > > +			case SCAN_PTE_MAPPED_HUGEPAGE:
> > > 				continue;
> > > +			/* Cases where lower orders might still succeed */
> > > +			case SCAN_LACK_REFERENCED_PAGE:
> > > +			case SCAN_EXCEED_NONE_PTE:
> > > +			case SCAN_EXCEED_SWAP_PTE:
> > > +			case SCAN_EXCEED_SHARED_PTE:
> > > +			case SCAN_PAGE_LOCK:
> > > +			case SCAN_PAGE_COUNT:
> > > +			case SCAN_PAGE_NULL:
> > > +			case SCAN_DEL_PAGE_LRU:
> > > +			case SCAN_PTE_NON_PRESENT:
> > > +			case SCAN_PTE_UFFD_WP:
> > > +			case SCAN_ALLOC_HUGE_PAGE_FAIL:
> >
> > Nit: shouldn't SCAN_CGROUP_CHARGE_FAIL go with SCAN_ALLOC_HUGE_PAGE_FAIL
> > here?
> >
> > If charging the current order fails, a smaller order might still fit :)
>
> I think the reasoning was here, that if we are already that close to our mem
> limit, we should just give up instead of trying to squeeze it in .. :)

Fair point. Just a nit, nevermind :)