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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] `beneficial_reclaim_backoff` unintentionally disables reclaim for all non-zero orders if the pool has no beneficial order.
--

--- Patch [1]: [PATCH v2 01/33] drm/ttm/pool: Allow backing off reclaim at the beneficial order ---
commit 33813073a08d456967f60dbd0f79ceb761550bda
Author: Matthew Brost <matthew.brost@intel.com>

drm/ttm/pool: Allow backing off reclaim at the beneficial order

This commit adds a beneficial_reclaim_backoff flag to struct
ttm_operation_ctx. When set, it allows the allocator to skip reclaim and
compaction at the pool's beneficial order, falling back to smaller orders
quickly instead of stalling.

> diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
> index 3d5f2ae0a4564..dbe977412a811 100644
> --- a/drivers/gpu/drm/ttm/ttm_pool.c
> +++ b/drivers/gpu/drm/ttm/ttm_pool.c
[ ... ]
> @@ -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;

[Severity: Medium]
Does this unintentionally disable reclaim for all non-zero orders if the
pool has no configured beneficial order?

If a caller sets ctx->beneficial_reclaim_backoff = true for an allocation
on a TTM pool where ttm_pool_beneficial_order(pool) == 0, the condition
above evaluates to true for any order > 0. This unconditionally clears
__GFP_RECLAIM.

High-order page allocations would then completely skip direct and kswapd
reclaim, causing them to fail prematurely and fall back to order-0
allocations. This seems to defeat the purpose of high-order pools when
no beneficial order is specified.

Should this condition explicitly require beneficial_order to be non-zero
when evaluating beneficial_reclaim_backoff?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710215442.2444235-1-matthew.brost@intel.com?part=1