Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Matthew Brost" <matthew.brost@intel.com>,
	intel-xe@lists.freedesktop.org
Subject: Re: [PATCH] drm/xe: Add a minimum age gate to the shrinker
Date: Thu, 15 Oct 2026 23:27:46 +0000	[thread overview]
Message-ID: <sashiko-outbox-173463@kernel.org> (raw)
In-Reply-To: <20261015231733.624746-1-matthew.brost@intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/xe: early exit on young BOs during non-blocking shrinker pass skips wait and writeback passes
--

commit 6b83dedb1afbfc65819c5071643ac8eea0a4a7d4
Author: Matthew Brost <matthew.brost@intel.com>

drm/xe: Add a minimum age gate to the shrinker

This patch introduces a minimum age threshold for the BO shrinker to
avoid evicting recently used buffers, providing a sysfs attribute for
the delay. It implements an early exit mechanism when encountering young
BOs during the shrinker walk to prevent thrashing.

> diff --git a/drivers/gpu/drm/xe/xe_shrinker.c b/drivers/gpu/drm/xe/xe_shrinker.c
> --- a/drivers/gpu/drm/xe/xe_shrinker.c
> +++ b/drivers/gpu/drm/xe/xe_shrinker.c

[ ... ]

> @@ -112,6 +116,16 @@ static int __xe_shrinker_walk(struct xe_shrinker *shrinker,
>  			if (!ttm_bo_shrink_suitable(ttm_bo, ctx))
>  				continue;
>  
> +			/*
> +			 * The LRU is roughly age ordered, so everything past
> +			 * the first young BO is most likely young too. Stop
> +			 * here.
> +			 */
> +			if (xe_bo_shrink_too_young(ttm_bo, min_age)) {
> +				*young = true;
> +				goto out;
> +			}
> +

[Severity: High]
This logic sets the young flag to true on the first young idle BO. During the
initial non-blocking pass, older BOs that are currently busy on the GPU are
skipped because ttm_bo_shrink_suitable() returns false. Will this cause the
walk to abort prematurely if it encounters a young idle BO immediately after
skipping older busy BOs?

>  			lret = xe_bo_shrink(ctx, ttm_bo, flags, scanned);

[ ... ]

> @@ -155,16 +165,16 @@ static int xe_shrinker_walk(struct xe_shrinker *shrinker,
>  	swap(no_wait_gpu, ctx->no_wait_gpu);
>  	save_flags.writeback = false;
> -	ret = __xe_shrinker_walk(shrinker, ctx, save_flags, to_scan, scanned,
> -				 freed);
> +	ret = __xe_shrinker_walk(shrinker, ctx, save_flags, min_age, &young,
> +				 to_scan, scanned, freed);
>  	swap(no_wait_gpu, ctx->no_wait_gpu);
> -	if (ret || *scanned >= to_scan)
> +	if (ret || young || *scanned >= to_scan)
>  		return ret;

[Severity: High]
Does this early return prevent the subsequent blocking and writeback passes
from executing?

If the first non-blocking pass was truncated by a young BO, returning here
means the shrinker completely bypasses the second pass (which waits for the
skipped, older busy BOs) and the third pass (which writes back older dirty
BOs).

Could this break the multi-pass shrinker escalation design and severely
restrict memory reclaim, leading to premature OOM under memory pressure?

>  
>  	if (!ctx->no_wait_gpu) {
> -		ret = __xe_shrinker_walk(shrinker, ctx, save_flags, to_scan, scanned,
> -					 freed);
> -		if (ret || *scanned >= to_scan)
> +		ret = __xe_shrinker_walk(shrinker, ctx, save_flags, min_age,
> +					 &young, to_scan, scanned, freed);
> +		if (ret || young || *scanned >= to_scan)
>  			return ret;
>  	}

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

  parent reply	other threads:[~2026-10-15 23:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15 23:17 [PATCH] drm/xe: Add a minimum age gate to the shrinker Matthew Brost
2026-10-15 23:25 ` ✓ CI.KUnit: success for " Patchwork
2026-10-15 23:27 ` sashiko-bot [this message]
2026-10-16  0:04 ` ✓ Xe.CI.BAT: " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-173463@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.brost@intel.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox