Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Tales A. Mendonça" <talesam@gmail.com>
To: intel-xe@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org, matthew.brost@intel.com,
	thomas.hellstrom@linux.intel.com, rodrigo.vivi@intel.com,
	"Tales A. Mendonça" <talesam@gmail.com>
Subject: [PATCH v1 4/4] drm/xe: Raise hw_tlb_timeout to cover observed GuC ack latency
Date: Tue, 21 Jul 2026 21:46:54 -0300	[thread overview]
Message-ID: <20260722004654.744249-5-talesam@gmail.com> (raw)
In-Reply-To: <20260722004654.744249-1-talesam@gmail.com>

On ARL-H (Arrow Lake-H) under sustained load, TLB invalidation acks can
arrive slightly later than the current fence timeout budget:

  tlb_inval_timeout_delay() = hw_tlb_timeout (HZ/4)
                            + 2 * xe_guc_ct_queue_proc_time_jiffies()

which with the 4K H2G buffer works out to 2.25s. When that happens the
fence is force-signalled with -ETIME even though the invalidation
completes an instant later:

  xe 0000:00:02.0: [drm] *ERROR* TLB invalidation fence timeout,
      seqno=15519 recv=15518

Local instrumentation that records the request and timeout times of a
timed-out invalidation and logs the deltas when its ack finally lands
measured, over ~24h of heavy use (kernel builds, 3 VMs, browser; ~311k
invalidations at ~7.4/s):

  - 34 fence timeouts, every one followed by its ack
  - request-to-ack: 2254-2355 ms (mean 2306 ms)
  - timeout-to-ack: 2-59 ms (mean 25 ms)

i.e. the ack always arrives, and always within tens of milliseconds of
the deadline - there is no firmware stall (nothing arrives seconds
late). A prior change guaranteeing a G2H CTB drain in the timeout path
confirmed the acks are genuinely not yet delivered when the timeout
fires, ruling out lost interrupts or an unprocessed CTB entry.

Signalling -ETIME on an invalidation that completes ~25 ms later is
worse than waiting a little longer: waiters see a spurious error for an
operation that succeeds. Raise hw_tlb_timeout to HZ/2, extending the
budget to 2.5s, which covers the observed worst case (2.355s) with
~150 ms of margin and eliminated all spurious timeouts in testing on
this workload.

Signed-off-by: Tales A. Mendonça <talesam@gmail.com>
---
 drivers/gpu/drm/xe/xe_guc_tlb_inval.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
index 91960dc4ba9..c5ceac5ab86 100644
--- a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
+++ b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
@@ -335,7 +335,7 @@ static long tlb_inval_timeout_delay(struct xe_tlb_inval *tlb_inval)
 	struct xe_guc *guc = tlb_inval->private;
 
 	/* this reflects what HW/GuC needs to process TLB inv request */
-	const long hw_tlb_timeout = HZ / 4;
+	const long hw_tlb_timeout = HZ / 2;
 
 	/* this estimates actual delay caused by the CTB transport */
 	long delay = xe_guc_ct_queue_proc_time_jiffies(&guc->ct);
-- 
2.55.0


  parent reply	other threads:[~2026-07-22 13:42 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-22  0:46 [PATCH v1 0/4] drm/xe: MCR semaphore and TLB invalidation timeout fixes for ARL Tales A. Mendonça
2026-07-22  0:46 ` [PATCH v1 1/4] drm/xe/mcr: Keep GT forcewake during MCR steering Tales A. Mendonça
2026-07-22 17:45   ` Tales A. Mendonça
2026-07-22 18:10   ` Matt Roper
2026-07-22 18:39     ` Tales A. Mendonça
2026-07-22  0:46 ` [PATCH v1 2/4] drm/xe/mcr: Sanitize steering semaphore on GT resume Tales A. Mendonça
2026-07-22 17:47   ` Tales A. Mendonça
2026-07-22  0:46 ` [PATCH v1 3/4] drm/xe/guc/ct: Queue G2H worker before flushing it in timeout paths Tales A. Mendonça
2026-07-22 17:48   ` Tales A. Mendonça
2026-07-22 21:10   ` Matthew Brost
2026-07-22 22:03     ` Matthew Brost
2026-07-22 23:28       ` Tales A. Mendonça
2026-07-23  0:26         ` Matthew Brost
2026-07-23  2:08           ` Tales A. Mendonça
2026-07-22  0:46 ` Tales A. Mendonça [this message]
2026-07-22 17:27 ` ✗ LGCI.VerificationFailed: failure for drm/xe: MCR semaphore and TLB invalidation timeout fixes for ARL 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=20260722004654.744249-5-talesam@gmail.com \
    --to=talesam@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.brost@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=thomas.hellstrom@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox