From: Matthew Brost <matthew.brost@intel.com>
To: intel-xe@lists.freedesktop.org
Cc: Wang Xin <x.wang@intel.com>, Jia Yao <jia.yao@intel.com>,
Jonathan Cavitt <jonathan.cavitt@intel.com>
Subject: [CI] drm/xe: Disable scheduling early on FD close to avoid CAT error cascade
Date: Tue, 25 Aug 2026 13:11:48 -0700 [thread overview]
Message-ID: <20260825201148.1780176-1-matthew.brost@intel.com> (raw)
When an FD is closed with many exec queues, teardown relies on the TDR
path to clean up scheduling. However, the TDR handling is serialized
(i.e., only one exec queue is processed at a time), which can make it
too slow compared to GuC scheduling activity.
In this window, GuC may continue to schedule contexts backed by
invalid page tables, leading to a cascade of CAT errors and repeated
engine resets. This significantly increases recovery time and can
degrade system stability.
To mitigate this, eagerly disable scheduling by sending a self-message
outside of the TDR path. This prevents further scheduling of invalid
contexts and avoids the CAT error/reset cascade.
This change improves robustness and reduces recovery latency in
multiple queue teardown scenarios.
Cc: Wang Xin <x.wang@intel.com>
Cc: Jia Yao <jia.yao@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Tested-by: Jia Yao <jia.yao@intel.com>
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
---
drivers/gpu/drm/xe/xe_guc_exec_queue_types.h | 2 +-
drivers/gpu/drm/xe/xe_guc_submit.c | 45 ++++++++++++++++++--
2 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_guc_exec_queue_types.h b/drivers/gpu/drm/xe/xe_guc_exec_queue_types.h
index d27826b36649..a46cde5ed81f 100644
--- a/drivers/gpu/drm/xe/xe_guc_exec_queue_types.h
+++ b/drivers/gpu/drm/xe/xe_guc_exec_queue_types.h
@@ -36,7 +36,7 @@ struct xe_guc_exec_queue {
* a message needs to sent through the GPU scheduler but memory
* allocations are not allowed.
*/
-#define MAX_STATIC_MSG_TYPE 4
+#define MAX_STATIC_MSG_TYPE 5
struct xe_sched_msg static_msgs[MAX_STATIC_MSG_TYPE];
/** @destroy_async: do final destroy async from this worker */
struct work_struct destroy_async;
diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c b/drivers/gpu/drm/xe/xe_guc_submit.c
index 99d8c807ff05..8b8972b2ebea 100644
--- a/drivers/gpu/drm/xe/xe_guc_submit.c
+++ b/drivers/gpu/drm/xe/xe_guc_submit.c
@@ -1969,12 +1969,22 @@ static void __guc_exec_queue_process_msg_cgp_sync(struct xe_sched_msg *msg,
guc_exec_queue_send_cgp_sync(q, 0);
}
+static void __guc_exec_queue_process_msg_kill(struct xe_sched_msg *msg)
+{
+ struct xe_exec_queue *q = msg->private_data;
+ struct xe_exec_queue *primary = xe_exec_queue_multi_queue_primary(q);
+
+ if (exec_queue_enabled(primary))
+ disable_scheduling(primary, true);
+}
+
#define CLEANUP 1 /* Non-zero values to catch uninitialized msg */
#define SET_SCHED_PROPS 2
#define SUSPEND 3
#define RESUME 4
#define SET_MULTI_QUEUE_PRIORITY 5
#define CGP_SYNC_MSG 6
+#define KILL 7
#define OPCODE_MASK 0xf
#define MSG_LOCKED BIT(8)
#define MSG_HEAD BIT(9)
@@ -2008,6 +2018,9 @@ static void guc_exec_queue_process_msg(struct xe_sched_msg *msg)
case CGP_SYNC_MSG:
__guc_exec_queue_process_msg_cgp_sync(msg, bound);
break;
+ case KILL:
+ __guc_exec_queue_process_msg_kill(msg);
+ break;
default:
XE_WARN_ON("Unknown message type");
}
@@ -2130,11 +2143,39 @@ static int guc_exec_queue_init(struct xe_exec_queue *q)
return err;
}
+static bool guc_exec_queue_try_add_msg(struct xe_exec_queue *q,
+ struct xe_sched_msg *msg,
+ u32 opcode);
+
+#define STATIC_MSG_CLEANUP 0
+#define STATIC_MSG_SUSPEND 1
+#define STATIC_MSG_RESUME 2
+#define STATIC_MSG_CGP_SYNC 3
+#define STATIC_MSG_KILL 4
static void guc_exec_queue_kill(struct xe_exec_queue *q)
{
+ struct xe_sched_msg *msg = q->guc->static_msgs + STATIC_MSG_KILL;
+
trace_xe_exec_queue_kill(q);
set_exec_queue_killed(q);
__suspend_fence_signal(q);
+
+ /*
+ * We eagerly send a message to ourselves to disable scheduling, as the
+ * TDR is serialized (i.e., only one exec queue is processed at a time).
+ * If an FD is closed with many exec queues, the TDR can be slower than
+ * the GuC scheduling contexts with invalid page tables, creating a
+ * cascade of CAT errors and engine resets, which is quite slow. Avoid
+ * this by immediately disabling scheduling outside of the TDR.
+ */
+ if (kref_read(&q->refcount) && !exec_queue_wedged(q)) {
+ struct xe_gpu_scheduler *sched = &q->guc->sched;
+
+ xe_sched_msg_lock(sched);
+ guc_exec_queue_try_add_msg(q, msg, KILL);
+ xe_sched_msg_unlock(sched);
+ }
+
xe_guc_exec_queue_trigger_cleanup(q);
}
@@ -2187,10 +2228,6 @@ static bool guc_exec_queue_try_add_msg(struct xe_exec_queue *q,
return true;
}
-#define STATIC_MSG_CLEANUP 0
-#define STATIC_MSG_SUSPEND 1
-#define STATIC_MSG_RESUME 2
-#define STATIC_MSG_CGP_SYNC 3
static void guc_exec_queue_destroy(struct xe_exec_queue *q)
{
struct xe_sched_msg *msg = q->guc->static_msgs + STATIC_MSG_CLEANUP;
--
2.34.1
next reply other threads:[~2026-08-25 20:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 20:11 Matthew Brost [this message]
2026-08-25 20:21 ` ✓ CI.KUnit: success for drm/xe: Disable scheduling early on FD close to avoid CAT error cascade (rev5) Patchwork
2026-08-25 20:29 ` [CI] drm/xe: Disable scheduling early on FD close to avoid CAT error cascade sashiko-bot
2026-08-25 21:04 ` ✓ Xe.CI.BAT: success for drm/xe: Disable scheduling early on FD close to avoid CAT error cascade (rev5) Patchwork
-- strict thread matches above, loose matches on Subject: below --
2026-08-25 20:35 [CI] drm/xe: Disable scheduling early on FD close to avoid CAT error cascade Matthew Brost
2026-08-25 20:54 ` sashiko-bot
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=20260825201148.1780176-1-matthew.brost@intel.com \
--to=matthew.brost@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=jia.yao@intel.com \
--cc=jonathan.cavitt@intel.com \
--cc=x.wang@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