Re: [PATCH v6 2/2] drm/xe/shrinker: Take a runtime PM ref before shrinking non-system memory

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Premature termination of shrinker scan due to treating -EBUSY on individual BOs as a fatal error.
--

commit b598ba1dc223459e465dd240779b658d7d771f73
Author: Shuicheng Lin <shuicheng.lin@intel.com>
drm/xe/shrinker: Take a runtime PM ref before shrinking non-system memory

This commit takes a runtime PM reference before walking memory types other
than XE_PL_SYSTEM in the shrinker to prevent GPU page table zap from
tripping an assert when the device is suspended. It reuses the shrinker's
existing acquire path to resume the device directly or queues a worker if
needed.

> diff --git a/drivers/gpu/drm/xe/xe_shrinker.c b/drivers/gpu/drm/xe/xe_shrinker.c
> index 89445cd202380..13f49ac873b4b 100644
> --- a/drivers/gpu/drm/xe/xe_shrinker.c
> +++ b/drivers/gpu/drm/xe/xe_shrinker.c

[ ... ]

> @@ -75,23 +95,36 @@ static int __xe_shrinker_walk(struct xe_device *xe,
>  		if (!man || !man->use_tt)
>  			continue;
>  
> +		if (mem_type != XE_PL_SYSTEM && !rpm &&
> +		    xe_device_is_l2_flush_optimized(xe)) {
> +			if (!__xe_shrinker_runtime_pm_get(shrinker))
> +				break;
> +			rpm = true;
> +		}
> +
>  		ttm_bo_lru_for_each_reserved_guarded(&curs, man, &arg, ttm_bo) {
>  			if (!ttm_bo_shrink_suitable(ttm_bo, ctx))
>  				continue;
>  
>  			lret = xe_bo_shrink(ctx, ttm_bo, flags, scanned);
> -			if (lret < 0)
> -				return lret;
> +			if (lret < 0) {
> +				ret = lret;
> +				goto out;
> +			}

[Severity: High]
This isn't a bug introduced by this patch, but it carries forward a severe
pre-existing issue in the new error path. Does treating non-fatal
object-level errors as scan-fatal errors prematurely abort the memory
reclaim process?

When the system is under memory pressure, __xe_shrinker_walk() iterates
over the BO LRU list in drivers/gpu/drm/xe/xe_shrinker.c. If it encounters
a BO that is not purgeable or not eviction-valuable, xe_bo_shrink()
correctly returns -EBUSY for that object:

drivers/gpu/drm/xe/xe_bo.c:xe_bo_shrink() {
    if (!(tt->page_flags & TTM_TT_FLAG_EXTERNAL_MAPPABLE) ||
        (flags.purge && !xe_tt->purgeable))
        return -EBUSY;

    if (!xe_bo_eviction_valuable(bo, &place))
        return -EBUSY;
    ...
}

Because lret < 0 triggers an immediate loop break (now via the goto out
statement), encountering a single unshrinkable BO permanently halts the
shrinker scan for that memory type. This prevents the shrinker from
reaching valid evictable objects further down the LRU list, effectively
disabling memory reclaim. Should this loop skip the busy BO and continue
instead of aborting the entire scan?

>  			*freed += lret;
>  			if (*scanned >= to_scan)
> -				break;
> +				goto out;
>  		}
>  		/* Trylocks should never error, just fail. */
>  		xe_assert(xe, !IS_ERR(ttm_bo));
>  	}
>  
> -	return 0;
> +out:
> +	if (rpm)
> +		xe_pm_runtime_put(xe);
> +
> +	return ret;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260904215049.543535-1-shuicheng.lin@intel.com?part=2