From: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
To: igt-dev@lists.freedesktop.org
Subject: [PATCH] tests/perf_pmu: Fix busy-double-start for GuC backend
Date: Mon, 5 Oct 2026 16:33:56 -0700 [thread overview]
Message-ID: <20261005233355.3452017-2-umesh.nerlige.ramappa@intel.com> (raw)
On GuC-based platforms, backend could switch work at a very fast rate
determined by "timeslice_duration_ms". For a default value of 1 ms, the
switching latencies could add up really quickly over the test duration.
While this works fine, workaround and other factors that may kick in for
some platforms at context switches add to the context switch latencies.
Choose a reasonable timeslice for this test so that expected and actual
busyness is within acceptable threshold. A 10ms timeslice works well for
this specific use case.
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/4349
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
---
tests/intel/perf_pmu.c | 44 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/tests/intel/perf_pmu.c b/tests/intel/perf_pmu.c
index 3a7f3410961f..b20f9bba1f9a 100644
--- a/tests/intel/perf_pmu.c
+++ b/tests/intel/perf_pmu.c
@@ -405,6 +405,33 @@ busy_start(int gem_fd, const intel_ctx_t *ctx,
gem_quiescent_gpu(gem_fd);
}
+static void set_timeslice(int cs, unsigned int value)
+{
+ unsigned int delay;
+
+ igt_debug("setting timeslice to %u ms\n", value);
+ igt_assert_lte(0, igt_sysfs_printf(cs, "timeslice_duration_ms", "%u", value));
+ igt_sysfs_scanf(cs, "timeslice_duration_ms", "%u", &delay);
+ igt_assert_eq(delay, value);
+}
+
+static int timeslice_fd(int fd, const struct intel_execution_engine2 *e)
+{
+ int sys, cs = -1;
+ char buf[32];
+
+ sys = igt_sysfs_open(fd);
+ igt_require(sys != -1);
+
+ snprintf(buf, sizeof(buf), "engine/%s", e->name);
+ cs = openat(sys, buf, O_RDONLY);
+ igt_require(cs != -1);
+
+ close(sys);
+
+ return cs;
+}
+
/*
* This test has a potentially low rate of catching the issue it is trying to
* catch. Or in other words, quite high rate of false negative successes. We
@@ -420,6 +447,18 @@ busy_double_start(int gem_fd, const intel_ctx_t *ctx,
const intel_ctx_t *tmp_ctx;
int fd;
uint64_t ahnd = get_reloc_ahnd(gem_fd, ctx->id), ahndN;
+ unsigned int saved, cs;
+
+ /*
+ * Set a larger timeslice to minimize the engine busyness differences
+ * due to context switch times
+ */
+ if (gem_using_guc_submission(gem_fd)) {
+ cs = timeslice_fd(gem_fd, e);
+ igt_assert(igt_sysfs_scanf(cs, "timeslice_duration_ms", "%u", &saved) == 1);
+ igt_debug("initial timeslice %u ms\n", saved);
+ set_timeslice(cs, 10);
+ }
tmp_ctx = intel_ctx_create(gem_fd, &ctx->cfg);
ahndN = get_reloc_ahnd(gem_fd, tmp_ctx->id);
@@ -474,6 +513,11 @@ busy_double_start(int gem_fd, const intel_ctx_t *ctx,
put_ahnd(ahnd);
put_ahnd(ahndN);
+ if (gem_using_guc_submission(gem_fd)) {
+ set_timeslice(cs, saved);
+ close(cs);
+ }
+
assert_within_epsilon(val, ts[1] - ts[0], tolerance);
igt_assert_eq(val2, 0);
--
2.55.0
next reply other threads:[~2026-10-05 23:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-05 23:33 Umesh Nerlige Ramappa [this message]
2026-10-06 0:28 ` ✓ Xe.CI.BAT: success for tests/perf_pmu: Fix busy-double-start for GuC backend (rev2) Patchwork
2026-10-06 0:39 ` ✓ i915.CI.BAT: " Patchwork
2026-10-06 8:12 ` ✗ i915.CI.Full: failure " Patchwork
2026-10-06 9:42 ` ✗ Xe.CI.FULL: " 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=20261005233355.3452017-2-umesh.nerlige.ramappa@intel.com \
--to=umesh.nerlige.ramappa@intel.com \
--cc=igt-dev@lists.freedesktop.org \
/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.