Re: [PATCH v2 01/33] drm/ttm/pool: Allow backing off reclaim at the beneficial order

[Matthew Brost <matthew.brost@intel.com>]

On Sat, Jul 11, 2026 at 12:38:10PM +0200, Christian König wrote:
> On 7/10/26 23:54, Matthew Brost wrote:
> > Allocating at the pool's beneficial order normally uses
> > __GFP_RETRY_MAYFAIL to push hard for a contiguous high-order page. When
> > beneficial-order allocations have recently been failing, this retry just
> > burns CPU cycles in reclaim/compaction before falling back to a smaller
> > order anyway.
> > 
> > Add a beneficial_reclaim_backoff flag to struct ttm_operation_ctx and
> > plumb it through to ttm_pool_alloc_page(). When set, the beneficial
> > order is treated like the orders we already consider not worth stalling
> > for: __GFP_RECLAIM is cleared so the allocation skips reclaim/compaction
> > entirely, and the __GFP_NORETRY clearing / __GFP_RETRY_MAYFAIL promotion
> > is skipped. Together this makes the allocator back off quickly to a
> > smaller order instead of stalling.
> 
> That makes no sense at all.
>
> You first give a beneficial order from the driver and then later overwrite it.
> 
> What could be done is to make the beneficial order part of the context in the first place, but I don't get what the use case for this should be.
> 

In this series, the use case is that BOs have already ended up in the
driver-side defragmenter due to suboptimal placement for one reason or another.
In my testing, it is fairly easy for higher-order allocations using
GFP_RETRY_MAYFAIL to still fail. If the defragmenter already has several BOs
queued, there is little point in continuing to try aggressively for higher-order
allocations. In that case, it makes sense to back off, accept smaller pages, and
fix things up later through defragmentation.

I could drop this part, but in my opinion it does make a reasonable amount of
sense.

> It looks like you propose that TTM should accept smaller chunks of memory initially and then comes back later on and re-allocates things in huge pages.
> 
> If that is really the case then I would clearly reject the whole idea. De-fragmentation of smaller pages into larger ones is the job of the core memory management and *not* TTM.
>

Of course the core MM subsystem defragments memory. However, the driver-side
defragmenter serves a different purpose. It relies on the core MM making larger
allocations available, then coordinates TTM state updates, asynchronous copies,
and mapping updates within the execution pipeline using fences.

What the defragmenter solves is the "once placed badly, forever placed badly"
problem. Without it, allocations that end up fragmented or otherwise suboptimal
tend to remain that way indefinitely. The defragmenter allows those allocations
to be reorganized over time as better placement opportunities become available.

TTM is simply a transaction layer that does what the policy layer (the driver)
instructs it to do. It is not responsible for making policy decisions itself,
nor should it attempt to impose them on individual drivers.

Matt
 
> Regards,
> Christian.
> 
> > 
> > This is a no-op until a caller opts in.
> > 
> > Cc: Carlos Santa <carlos.santa@intel.com>
> > Cc: Ryan Neph <ryanneph@google.com>
> > Cc: Christian Koenig <christian.koenig@amd.com>
> > Cc: Huang Rui <ray.huang@amd.com>
> > Cc: Matthew Auld <matthew.auld@intel.com>
> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Cc: Maxime Ripard <mripard@kernel.org>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: David Airlie <airlied@gmail.com>
> > Cc: Simona Vetter <simona@ffwll.ch>
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: linux-kernel@vger.kernel.org
> > Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > Assisted-by: GitHub_Copilot:claude-opus-4.8
> > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > ---
> >  drivers/gpu/drm/ttm/ttm_pool.c | 12 ++++++++----
> >  include/drm/ttm/ttm_bo.h       |  7 +++++++
> >  2 files changed, 15 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
> > index 3d5f2ae0a456..dbe977412a81 100644
> > --- a/drivers/gpu/drm/ttm/ttm_pool.c
> > +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> > @@ -145,7 +145,8 @@ static int ttm_pool_nid(struct ttm_pool *pool)
> >  
> >  /* Allocate pages of size 1 << order with the given gfp_flags */
> >  static struct page *ttm_pool_alloc_page(struct ttm_pool *pool, gfp_t gfp_flags,
> > -					unsigned int order)
> > +					unsigned int order,
> > +					bool beneficial_reclaim_backoff)
> >  {
> >  	const unsigned int beneficial_order = ttm_pool_beneficial_order(pool);
> >  	unsigned long attr = DMA_ATTR_FORCE_CONTIGUOUS;
> > @@ -165,10 +166,12 @@ static struct page *ttm_pool_alloc_page(struct ttm_pool *pool, gfp_t gfp_flags,
> >  	 * Do not add latency to the allocation path for allocations orders
> >  	 * device tolds us do not bring them additional performance gains.
> >  	 */
> > -	if (order && beneficial_order && order != beneficial_order)
> > +	if (order && (beneficial_reclaim_backoff ||
> > +		      (beneficial_order && order != beneficial_order)))
> >  		gfp_flags &= ~__GFP_RECLAIM;
> >  
> > -	if (beneficial_order && order == beneficial_order) {
> > +	if (!beneficial_reclaim_backoff &&
> > +	    beneficial_order && order == beneficial_order) {
> >  		gfp_flags &= ~__GFP_NORETRY;
> >  		gfp_flags |= __GFP_RETRY_MAYFAIL;
> >  	}
> > @@ -814,7 +817,8 @@ static int __ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt *tt,
> >  		if (!p) {
> >  			page_caching = ttm_cached;
> >  			allow_pools = false;
> > -			p = ttm_pool_alloc_page(pool, gfp_flags, order);
> > +			p = ttm_pool_alloc_page(pool, gfp_flags, order,
> > +						ctx->beneficial_reclaim_backoff);
> >  		}
> >  		/* If that fails, lower the order if possible and retry. */
> >  		if (!p) {
> > diff --git a/include/drm/ttm/ttm_bo.h b/include/drm/ttm/ttm_bo.h
> > index 8310bc3d55f9..fd814b5cf535 100644
> > --- a/include/drm/ttm/ttm_bo.h
> > +++ b/include/drm/ttm/ttm_bo.h
> > @@ -187,6 +187,13 @@ struct ttm_operation_ctx {
> >  	 * when multiple BOs share the same reservation object @resv.
> >  	 */
> >  	bool allow_res_evict;
> > +	/**
> > +	 * @beneficial_reclaim_backoff: Back off from direct reclaim at the
> > +	 * pool's beneficial order. Useful when beneficial-order allocation has
> > +	 * recently been failing, to avoid burning CPU cycles in
> > +	 * reclaim/compaction before falling back to a smaller order anyway.
> > +	 */
> > +	bool beneficial_reclaim_backoff;
> >  	/**
> >  	 * @resv: Reservation object to be used together with
> >  	 * @allow_res_evict.
>