From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: intel-xe@lists.freedesktop.org
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Matthew Brost" <matthew.brost@intel.com>,
"Matthew Auld" <matthew.auld@intel.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>
Subject: [PATCH v2 2/2] drm/xe: Update shrinker batch size based on average BO size
Date: Fri, 14 Aug 2026 16:37:37 +0200 [thread overview]
Message-ID: <20260814143737.49684-3-thomas.hellstrom@linux.intel.com> (raw)
In-Reply-To: <20260814143737.49684-1-thomas.hellstrom@linux.intel.com>
Update our preferred vmscan batch size on each count pass to avoid
invoking scan_objects for requests too small to free even a single
average-sized GEM object. Our rough estimate for an effective batch
is twice the average number of pages per populated ttm_tt across all
shrinkable and purgeable objects. The factor of two provides headroom
so that most scan invocations can free at least one GEM object despite
variability in object sizes.
The batch value is updated as an exponential moving average,
(old_batch + avg) / 2, to smooth out sudden changes in the
object population. It is floored at 128 pages, the kernel default
SHRINK_BATCH, to ensure the shrinker remains responsive when there
are very few objects.
The populated_tts counter introduced in the previous commit provides
the object count needed for the average. We inherit the same
justification as the analogous mechanism in i915: shrinking a GEM
object has non-trivial locking overhead, so firing the shrinker for
requests smaller than a single object is wasteful.
v2:
- Fix the average object size estimate to account for the full
shrinkable and purgeable population.
Assisted-by: GitHub_Copilot:claude-sonnet-4.6
Assisted-by: GitHub_Copilot:claude-sonnet-5
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
drivers/gpu/drm/xe/xe_shrinker.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_shrinker.c b/drivers/gpu/drm/xe/xe_shrinker.c
index cded230f5459..284fce207705 100644
--- a/drivers/gpu/drm/xe/xe_shrinker.c
+++ b/drivers/gpu/drm/xe/xe_shrinker.c
@@ -146,6 +146,8 @@ xe_shrinker_count(struct shrinker *shrink, struct shrink_control *sc)
{
struct xe_shrinker *shrinker = to_xe_shrinker(shrink);
unsigned long num_pages;
+ unsigned long total_pages;
+ unsigned long populated_tts;
bool can_backup = !!(sc->gfp_mask & __GFP_FS);
num_pages = ttm_backup_bytes_avail() >> PAGE_SHIFT;
@@ -157,8 +159,32 @@ xe_shrinker_count(struct shrinker *shrink, struct shrink_control *sc)
num_pages = 0;
num_pages += shrinker->purgeable_pages;
+ total_pages = shrinker->shrinkable_pages + shrinker->purgeable_pages;
+ populated_tts = shrinker->populated_tts;
read_unlock(&shrinker->lock);
+ /*
+ * Update our preferred vmscan batch size for the next pass.
+ * Our rough guess for an effective batch size is twice the average
+ * number of pages per GEM object. That is, we don't want the
+ * shrinker to fire until the request is large enough to justify
+ * the overhead of freeing at least one GEM object.
+ *
+ * Base the average on the full shrinkable + purgeable population
+ * (total_pages), not on num_pages, which is reduced to just the
+ * purgeable pages whenever the gfp mask disallows backup (can_backup
+ * false). Otherwise the estimate would systematically undershoot in
+ * exactly the GFP_NOFS / GFP_NOIO reclaim paths where avoiding
+ * excessive scan_objects() calls matters most.
+ */
+ if (populated_tts) {
+ unsigned long avg = 2 * total_pages / populated_tts;
+
+ shrinker->shrink->batch =
+ max((shrinker->shrink->batch + avg) >> 1,
+ 128UL /* default SHRINK_BATCH */);
+ }
+
return num_pages ? num_pages : SHRINK_EMPTY;
}
--
2.55.0
next prev parent reply other threads:[~2026-08-14 14:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 14:37 [PATCH v2 0/2] drm/xe: Adjust the bo shrinker batch size Thomas Hellström
2026-08-14 14:37 ` [PATCH v2 1/2] drm/xe: Track number of populated ttm_tts in the shrinker Thomas Hellström
2026-08-14 14:56 ` sashiko-bot
2026-08-14 14:37 ` Thomas Hellström [this message]
2026-08-14 14:45 ` [PATCH v2 2/2] drm/xe: Update shrinker batch size based on average BO size sashiko-bot
2026-08-14 15:17 ` ✓ CI.KUnit: success for drm/xe: Adjust the bo shrinker batch size (rev2) Patchwork
2026-08-14 16:14 ` ✗ Xe.CI.BAT: failure " Patchwork
2026-08-14 18:07 ` ✓ Xe.CI.FULL: success " 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=20260814143737.49684-3-thomas.hellstrom@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthew.auld@intel.com \
--cc=matthew.brost@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.