Re: [PATCH v2] mm: page_alloc: make defrag_mode retries follow the promoted order

[Kiryl Shutsemau]

On Wed, Oct 07, 2026 at 08:53:14AM -0700, Usama Arif wrote:
> >  @@ -5007,14 +5034,20 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
> >  	 * of free memory (see __compaction_suitable)
> >  	 */
> >  	if (did_some_progress > 0 && can_compact &&
> > -	    should_compact_retry(gfp_mask, ac, order, alloc_flags,
> > -				 compact_result, &compact_priority,
> > +	    should_compact_retry(gfp_mask, ac, order, reclaim_order,
> > +				 alloc_flags, compact_result, &compact_priority,
> >  				 &compaction_retries))
> >  		goto retry;
> >  
> > -	/* Reclaim/compaction failed to prevent the fallback */
> > +	/*
> > +	 * Reclaim/compaction failed to prevent the fallback. The retry
> > +	 * budget was spent on making blocks, not on the request itself;
> > +	 * give the fallback a fresh one before considering OOM.
> > +	 */
> >  	if (defrag_mode && (alloc_flags & ALLOC_NOFRAGMENT)) {
> >  		alloc_flags &= ~ALLOC_NOFRAGMENT;
> > +		no_progress_loops = 0;
> > +		compaction_retries = 0;
> 
> Should these counters be reset only when the work order was actually
> promoted?
> 
> For movable requests, and requests already at or above pageblock
> order, `reclaim_order == order`. Their retry budget was therefore
> spent on the request itself rather than on promoted pageblock
> production. Resetting the counters here can give those requests
> another 17 no-progress reclaim attempts, plus additional
> compaction-success retries, before OOM or allocation failure.
> 
> How about:
> 	if (reclaim_order != order) {
> 		no_progress_loops = 0;
> 		compaction_retries = 0;
> 	}
> 
> instead?

Fair enough.

A movable request only gets here after 16 rounds without progress at its
own order, so the reset would just delay the OOM kill.

Will restrict it to reclaim_order != order in v3.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov