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
next prev 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