Re: [PATCH v3 16/33] drm/xe: Back off beneficial-order reclaim under defrag pressure

[Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>]

On Fri, Jul 10, 2026 at 07:56:02PM -0700, Matthew Brost wrote:
>Once a meaningful number of BOs are already tracked as being backed at a
>sub-optimal order, continuing to push hard for beneficial-order pages
>during populate mostly wastes time in reclaim/compaction.
>
>In xe_ttm_tt_populate(), set ctx->beneficial_reclaim_backoff when the
>device defrag count reaches XE_BO_DEFRAG_RECLAIM_BACKOFF_THRESHOLD (2)
>so the TTM pool backs off and allocations make forward progress. The
>deferred defrag pass is responsible for upgrading these objects to
>beneficial order later.
>
>Cc: Carlos Santa <carlos.santa@intel.com>
>Cc: Ryan Neph <ryanneph@google.com>
>Cc: Christian Koenig <christian.koenig@amd.com>
>Cc: Huang Rui <ray.huang@amd.com>
>Cc: Matthew Auld <matthew.auld@intel.com>
>Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>Cc: Maxime Ripard <mripard@kernel.org>
>Cc: Thomas Zimmermann <tzimmermann@suse.de>
>Cc: David Airlie <airlied@gmail.com>
>Cc: Simona Vetter <simona@ffwll.ch>
>Cc: dri-devel@lists.freedesktop.org
>Cc: linux-kernel@vger.kernel.org
>Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>Assisted-by: GitHub_Copilot:claude-opus-4.8
>Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>---
> drivers/gpu/drm/xe/xe_bo.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
>diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
>index ff324caab6da..02395968d613 100644
>--- a/drivers/gpu/drm/xe/xe_bo.c
>+++ b/drivers/gpu/drm/xe/xe_bo.c
>@@ -41,6 +41,14 @@
> #include "xe_vm.h"
> #include "xe_vram_types.h"
>
>+/*
>+ * Once this many BOs are tracked on the device defrag list (i.e. were backed
>+ * with a sub-optimal page order), request that the TTM pool backs off from
>+ * aggressive reclaim at the beneficial order during populate, so that
>+ * allocations make forward progress instead of stalling.
>+ */
>+#define XE_BO_DEFRAG_RECLAIM_BACKOFF_THRESHOLD	2
>+
> const char *const xe_mem_type_to_name[TTM_NUM_MEM_TYPES]  = {
> 	[XE_PL_SYSTEM] = "system",
> 	[XE_PL_TT] = "gtt",
>@@ -598,6 +606,12 @@ static int xe_ttm_tt_populate(struct ttm_device *ttm_dev, struct ttm_tt *tt,
> 	if (ttm_tt_is_backed_up(tt) && !xe_tt->purgeable) {
> 		err = ttm_tt_restore(ttm_dev, tt, ctx);

Assisted-by: LLM

Don't we need to to backoff in restore path also? If it is intentional,
probably add a comment?

> 	} else {
>+		struct xe_device *xe = ttm_to_xe_device(ttm_dev);
>+
>+		if (atomic_read(&xe->mem.defrag.count) >=
>+		    XE_BO_DEFRAG_RECLAIM_BACKOFF_THRESHOLD)
>+			ctx->beneficial_reclaim_backoff = true;
>+

- beneficial_reclaim_backoff is not cleared if count comes below
threshold. If the same ctx is used for multiple BOs, they all
will backoff even when count has moved below threshold.

- Looks like self-reinforcing feedback loop causes spike in backoff.

count ≥ 2 → backoff on → new populates land sub-optimal → BENEFICIAL_ORDER_FAILED
→ added to defrag list → count stays ≥ 2 → backoff stays on → ...

Is it intentional? If so, may be a comment explaining it would be helpful?

- Will there be any value is heuristically adjusting threshold instead
of using static value (2)?

Niranjana

> 		ttm_tt_clear_backed_up(tt);
> 		err = ttm_pool_alloc(&ttm_dev->pool, tt, ctx);
> 	}
>-- 
>2.34.1
>