Re: [PATCH v6 2/2] drm/xe: Make use of shrink_control::opportunistic_compaction hint

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Spurious runtime PM wakeups during opportunistic compaction reclaim.
--

commit 9d2dcd5b46c4108efa18e04768837bf386796338
Author: Matthew Brost <matthew.brost@intel.com>

drm/xe: Make use of shrink_control::opportunistic_compaction hint

This patch uses the new opportunistic_compaction hint in the Xe shrinker
to avoid backing up GPU memory during high-order fragmentation-driven
reclaim attempts. This prevents reclaim/rebind ping-pong behavior
without affecting order-0 reclaim.

> diff --git a/drivers/gpu/drm/xe/xe_shrinker.c b/drivers/gpu/drm/xe/xe_shrinker.c
> index 83374cd576608..198149f266c60 100644
> --- a/drivers/gpu/drm/xe/xe_shrinker.c
> +++ b/drivers/gpu/drm/xe/xe_shrinker.c
[ ... ]
> @@ -233,7 +240,14 @@ static unsigned long xe_shrinker_scan(struct shrinker *shrink, struct shrink_con
>  	}
>  
>  	sc->nr_scanned = nr_scanned;
> -	if (nr_scanned >= nr_to_scan || !can_backup)
> +	/*
> +	 * Stop after the purge pass for opportunistic high-order reclaim:
> +	 * the subsequent backup/writeback pass works at native page order
> +	 * and is unlikely to free a contiguous high-order block, so doing
> +	 * it here would just churn working sets for no compaction benefit.
> +	 */
> +	if (nr_scanned >= nr_to_scan || !can_backup ||
> +	    sc->opportunistic_compaction)
>  		goto out;

[Severity: Medium]
Does this cause a spurious runtime PM wakeup during opportunistic compaction?

Looking earlier in xe_shrinker_scan(), xe_shrinker_runtime_pm_get() is called
to eagerly wake up the device based on the can_backup flag:

	/* Might need runtime PM. Try to wake early if it looks like it. */
	runtime_pm = xe_shrinker_runtime_pm_get(shrinker, false, nr_to_scan, can_backup);

Since the early exit above skips the backup phase when opportunistic compaction
is requested, an asynchronous worker might still be queued to wake the GPU
from suspend even though the backup pass will never run.

Could the can_backup flag be updated to also incorporate the
sc->opportunistic_compaction state to prevent these wakeups?

>  
>  	/* If we didn't wake before, try to do it now if needed. */

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