[Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Force timeslicing of the virtual request
Chris Wilson
chris at chris-wilson.co.uk
Thu May 14 11:29:41 UTC 2020
Investigate the impact of timeslicing on the virtal request, both with
independent and dependent workloads.
Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
---
tests/i915/gem_exec_balancer.c | 101 +++++++++++++++++++++++++++++++++
1 file changed, 101 insertions(+)
diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
index d4944e3f1..607f1dc38 100644
--- a/tests/i915/gem_exec_balancer.c
+++ b/tests/i915/gem_exec_balancer.c
@@ -1531,6 +1531,104 @@ static void full(int i915, unsigned int flags)
gem_quiescent_gpu(i915);
}
+static void sliced(int i915)
+{
+ /*
+ * Let's investigate what happens when the virtual request is
+ * timesliced away.
+ *
+ * If the engine is busy with independent work, we want the virtual
+ * request to hop over to an idle engine (within its balancing set).
+ * However, if the work is dependent upon the virtual request,
+ * we most certainly do not want to reschedule that work ahead of
+ * the virtual request. [If we did, we should still have the saving
+ * grace of being able to move the virual request to another engine
+ * and so run both in parallel.] If we do neither, and get stuck
+ * on the dependent work and never run the virtual request, we hang.
+ */
+
+ igt_require(gem_scheduler_has_preemption(i915));
+ igt_require(gem_scheduler_has_semaphores(i915));
+
+ for (int class = 0; class < 32; class++) {
+ struct i915_engine_class_instance *ci;
+ int64_t timeout = NSEC_PER_SEC;
+ igt_spin_t *virtual, **load;
+ unsigned int count;
+ uint32_t ctx;
+
+ ci = list_engines(i915, 1u << class, &count);
+ if (!ci)
+ continue;
+
+ if (count < 2) {
+ free(ci);
+ continue;
+ }
+
+ load = calloc(count, sizeof(*load));
+ igt_assert(load);
+
+ ctx = load_balancer_create(i915, ci, count);
+
+ /* Independent load */
+ virtual = igt_spin_new(i915, ctx,
+ .flags = IGT_SPIN_POLL_RUN);
+ igt_spin_busywait_until_started(virtual);
+ for (int i = 0; i < count; i++) {
+ load[i] = igt_spin_new(i915, ctx,
+ .engine = i + 1,
+ .flags = IGT_SPIN_POLL_RUN);
+ igt_spin_busywait_until_started(load[i]);
+ }
+ /*
+ * As we waited until all requests started, and we
+ * oversubscribed the engines, we know that we must have
+ * forced the virtual request to be timesliced away.
+ *
+ * We then expect for it to receive a timeslice on congested
+ * engines, so that the spinned completes quickly.
+ */
+ igt_spin_end(virtual);
+ igt_assert_eq(gem_wait(i915, virtual->handle, &timeout), 0);
+
+ for (int i = 0; i < count; i++)
+ igt_spin_free(i915, load[i]);
+ igt_spin_free(i915, virtual);
+
+ /* Dependent load */
+ virtual = igt_spin_new(i915, ctx, .engine = 0,
+ .flags = (IGT_SPIN_FENCE_OUT |
+ IGT_SPIN_POLL_RUN));
+ for (int i = 0; i < count; i++) {
+ load[i] = igt_spin_new(i915, ctx,
+ .engine = i + 1,
+ .fence = virtual->out_fence,
+ .flags = IGT_SPIN_FENCE_IN);
+ /*
+ * We could wait until load[i] starts, but we do not
+ * want to mandate that the scheduler must evict
+ * the virtual request, as load[i] depends on
+ * the virtual request.
+ */
+ }
+
+ /* Wait long enough for the virtual timeslice [ms] to expire */
+ igt_spin_busywait_until_started(virtual);
+ usleep(250 * 1000); /* 250ms */
+
+ igt_spin_end(virtual);
+ igt_assert_eq(sync_fence_wait(virtual->out_fence, 1000), 0);
+ igt_assert_eq(sync_fence_status(virtual->out_fence), 1);
+
+ gem_context_destroy(i915, ctx);
+ free(load);
+ free(ci);
+ }
+
+ gem_quiescent_gpu(i915);
+}
+
static void nop(int i915)
{
struct drm_i915_gem_exec_object2 batch = {
@@ -2014,6 +2112,9 @@ igt_main
igt_subtest("semaphore")
semaphore(i915);
+ igt_subtest("sliced")
+ sliced(i915);
+
igt_subtest("smoke")
smoketest(i915, 20);
--
2.26.2
More information about the Intel-gfx
mailing list