All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: intel-gfx@lists.freedesktop.org
Cc: igt-dev@lists.freedesktop.org
Subject: [PATCH i-g-t 1/9] i915/gem_exec_schedule: Split pi-ringfull into two tests
Date: Wed, 13 Nov 2019 12:52:32 +0000	[thread overview]
Message-ID: <20191113125240.3781-1-chris@chris-wilson.co.uk> (raw)

pi-ringfull uses 2 contexts that share a buffer. The intent was that the
contexts were independent, but it was the effect of the global lock held
by the low priority client that prevented the high priority client from
executing. I began to add a second variant where there was a shared
resource which may induce a priority inversion, only to notice the
existing test already imposed a shared resource. Hence adding a second
test to rerun pi-ringfull in both unshared and shared resource modes.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
 tests/i915/gem_exec_schedule.c | 38 +++++++++++++++++++++++++++++++---
 1 file changed, 35 insertions(+), 3 deletions(-)

diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 5c15f1770..84581bffe 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -1468,7 +1468,8 @@ static void bind_to_cpu(int cpu)
 	igt_assert(sched_setaffinity(getpid(), sizeof(cpu_set_t), &allowed) == 0);
 }
 
-static void test_pi_ringfull(int fd, unsigned int engine)
+static void test_pi_ringfull(int fd, unsigned int engine, unsigned int flags)
+#define SHARED BIT(0)
 {
 	const uint32_t bbe = MI_BATCH_BUFFER_END;
 	struct sigaction sa = { .sa_handler = alarm_handler };
@@ -1480,6 +1481,24 @@ static void test_pi_ringfull(int fd, unsigned int engine)
 	uint32_t vip;
 	bool *result;
 
+	/*
+	 * We start simple. A low priority client should never prevent a high
+	 * priority client from submitting their work; even if the low priority
+	 * client exhausts their ringbuffer and so is throttled.
+	 *
+	 * SHARED: A variant on the above rule is that even is the 2 clients
+	 * share a read-only resource, the blocked low priority client should
+	 * not prevent the high priority client from executing. A buffer,
+	 * e.g. the batch buffer, that is shared only for reads (no write
+	 * hazard, so the reads can be executed in parallel or in any order),
+	 * so not cause priority inversion due to the resource conflict.
+	 *
+	 * First, we have the low priority context who fills their ring and so
+	 * blocks. As soon as that context blocks, we try to submit a high
+	 * priority batch, which should be executed immediately before the low
+	 * priority context is unblocked.
+	 */
+
 	result = mmap(NULL, 4096, PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0);
 	igt_assert(result != MAP_FAILED);
 
@@ -1545,6 +1564,12 @@ static void test_pi_ringfull(int fd, unsigned int engine)
 	igt_fork(child, 1) {
 		int err;
 
+		/* Replace our batch to avoid conflicts over shared resources? */
+		if (!(flags & SHARED)) {
+			obj[1].handle = gem_create(fd, 4096);
+			gem_write(fd, obj[1].handle, 0, &bbe, sizeof(bbe));
+		}
+
 		result[0] = vip != execbuf.rsvd1;
 
 		igt_debug("Waking parent\n");
@@ -1557,7 +1582,8 @@ static void test_pi_ringfull(int fd, unsigned int engine)
 		itv.it_value.tv_usec = 10000;
 		setitimer(ITIMER_REAL, &itv, NULL);
 
-		/* Since we are the high priority task, we expect to be
+		/*
+		 * Since we are the high priority task, we expect to be
 		 * able to add ourselves to *our* ring without interruption.
 		 */
 		igt_debug("HP child executing\n");
@@ -1569,6 +1595,9 @@ static void test_pi_ringfull(int fd, unsigned int engine)
 		setitimer(ITIMER_REAL, &itv, NULL);
 
 		result[2] = err == 0;
+
+		if (!(flags & SHARED))
+			gem_close(fd, obj[1].handle);
 	}
 
 	/* Relinquish CPU just to allow child to create a context */
@@ -1831,7 +1860,10 @@ igt_main
 				}
 
 				igt_subtest_f("pi-ringfull-%s", e->name)
-					test_pi_ringfull(fd, eb_ring(e));
+					test_pi_ringfull(fd, eb_ring(e), 0);
+
+				igt_subtest_f("pi-common-%s", e->name)
+					test_pi_ringfull(fd, eb_ring(e), SHARED);
 			}
 		}
 	}
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Chris Wilson <chris@chris-wilson.co.uk>
To: intel-gfx@lists.freedesktop.org
Cc: igt-dev@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH i-g-t 1/9] i915/gem_exec_schedule: Split pi-ringfull into two tests
Date: Wed, 13 Nov 2019 12:52:32 +0000	[thread overview]
Message-ID: <20191113125240.3781-1-chris@chris-wilson.co.uk> (raw)
Message-ID: <20191113125232.4Klmt8Mgv3cnCGVQrePRIM0-6cSFOc98QfaAtFViv5k@z> (raw)

pi-ringfull uses 2 contexts that share a buffer. The intent was that the
contexts were independent, but it was the effect of the global lock held
by the low priority client that prevented the high priority client from
executing. I began to add a second variant where there was a shared
resource which may induce a priority inversion, only to notice the
existing test already imposed a shared resource. Hence adding a second
test to rerun pi-ringfull in both unshared and shared resource modes.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
 tests/i915/gem_exec_schedule.c | 38 +++++++++++++++++++++++++++++++---
 1 file changed, 35 insertions(+), 3 deletions(-)

diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 5c15f1770..84581bffe 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -1468,7 +1468,8 @@ static void bind_to_cpu(int cpu)
 	igt_assert(sched_setaffinity(getpid(), sizeof(cpu_set_t), &allowed) == 0);
 }
 
-static void test_pi_ringfull(int fd, unsigned int engine)
+static void test_pi_ringfull(int fd, unsigned int engine, unsigned int flags)
+#define SHARED BIT(0)
 {
 	const uint32_t bbe = MI_BATCH_BUFFER_END;
 	struct sigaction sa = { .sa_handler = alarm_handler };
@@ -1480,6 +1481,24 @@ static void test_pi_ringfull(int fd, unsigned int engine)
 	uint32_t vip;
 	bool *result;
 
+	/*
+	 * We start simple. A low priority client should never prevent a high
+	 * priority client from submitting their work; even if the low priority
+	 * client exhausts their ringbuffer and so is throttled.
+	 *
+	 * SHARED: A variant on the above rule is that even is the 2 clients
+	 * share a read-only resource, the blocked low priority client should
+	 * not prevent the high priority client from executing. A buffer,
+	 * e.g. the batch buffer, that is shared only for reads (no write
+	 * hazard, so the reads can be executed in parallel or in any order),
+	 * so not cause priority inversion due to the resource conflict.
+	 *
+	 * First, we have the low priority context who fills their ring and so
+	 * blocks. As soon as that context blocks, we try to submit a high
+	 * priority batch, which should be executed immediately before the low
+	 * priority context is unblocked.
+	 */
+
 	result = mmap(NULL, 4096, PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0);
 	igt_assert(result != MAP_FAILED);
 
@@ -1545,6 +1564,12 @@ static void test_pi_ringfull(int fd, unsigned int engine)
 	igt_fork(child, 1) {
 		int err;
 
+		/* Replace our batch to avoid conflicts over shared resources? */
+		if (!(flags & SHARED)) {
+			obj[1].handle = gem_create(fd, 4096);
+			gem_write(fd, obj[1].handle, 0, &bbe, sizeof(bbe));
+		}
+
 		result[0] = vip != execbuf.rsvd1;
 
 		igt_debug("Waking parent\n");
@@ -1557,7 +1582,8 @@ static void test_pi_ringfull(int fd, unsigned int engine)
 		itv.it_value.tv_usec = 10000;
 		setitimer(ITIMER_REAL, &itv, NULL);
 
-		/* Since we are the high priority task, we expect to be
+		/*
+		 * Since we are the high priority task, we expect to be
 		 * able to add ourselves to *our* ring without interruption.
 		 */
 		igt_debug("HP child executing\n");
@@ -1569,6 +1595,9 @@ static void test_pi_ringfull(int fd, unsigned int engine)
 		setitimer(ITIMER_REAL, &itv, NULL);
 
 		result[2] = err == 0;
+
+		if (!(flags & SHARED))
+			gem_close(fd, obj[1].handle);
 	}
 
 	/* Relinquish CPU just to allow child to create a context */
@@ -1831,7 +1860,10 @@ igt_main
 				}
 
 				igt_subtest_f("pi-ringfull-%s", e->name)
-					test_pi_ringfull(fd, eb_ring(e));
+					test_pi_ringfull(fd, eb_ring(e), 0);
+
+				igt_subtest_f("pi-common-%s", e->name)
+					test_pi_ringfull(fd, eb_ring(e), SHARED);
 			}
 		}
 	}
-- 
2.24.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

             reply	other threads:[~2019-11-13 12:52 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-13 12:52 Chris Wilson [this message]
2019-11-13 12:52 ` [Intel-gfx] [PATCH i-g-t 1/9] i915/gem_exec_schedule: Split pi-ringfull into two tests Chris Wilson
2019-11-13 12:52 ` [PATCH i-g-t 2/9] i915/gem_exec_schedule: Exercise priority inversion from resource contention Chris Wilson
2019-11-13 12:52   ` [igt-dev] " Chris Wilson
2019-11-13 12:52   ` [Intel-gfx] " Chris Wilson
2019-11-13 12:52 ` [PATCH i-g-t 3/9] i915/gem_exec_schedule: Beware priority inversion from iova faults Chris Wilson
2019-11-13 12:52   ` [igt-dev] " Chris Wilson
2019-11-13 12:52   ` [Intel-gfx] " Chris Wilson
2019-11-13 12:52 ` [PATCH i-g-t 4/9] i915: Start putting the mmio_base to wider use Chris Wilson
2019-11-13 12:52   ` [igt-dev] " Chris Wilson
2019-11-13 12:52   ` [Intel-gfx] " Chris Wilson
2019-11-21 12:04   ` [igt-dev] " Lionel Landwerlin
2019-11-21 12:04     ` Lionel Landwerlin
2019-11-21 12:04     ` [Intel-gfx] " Lionel Landwerlin
2019-11-21 12:11     ` Chris Wilson
2019-11-21 12:11       ` Chris Wilson
2019-11-21 12:11       ` [Intel-gfx] " Chris Wilson
2019-11-21 13:11       ` Lionel Landwerlin
2019-11-21 13:11         ` Lionel Landwerlin
2019-11-21 13:11         ` [Intel-gfx] " Lionel Landwerlin
2019-11-13 12:52 ` [PATCH i-g-t 5/9] i915/gem_ctx_isolation: Check engine relative registers Chris Wilson
2019-11-13 12:52   ` [Intel-gfx] " Chris Wilson
2019-11-21 21:07   ` Tang, CQ
2019-11-21 21:07     ` [igt-dev] [Intel-gfx] " Tang, CQ
2019-11-21 21:07     ` Tang, CQ
2019-11-21 23:44     ` Chris Wilson
2019-11-21 23:44       ` [igt-dev] [Intel-gfx] " Chris Wilson
2019-11-21 23:44       ` Chris Wilson
2019-11-21 23:56       ` Tang, CQ
2019-11-21 23:56         ` [igt-dev] [Intel-gfx] " Tang, CQ
2019-11-21 23:56         ` Tang, CQ
2019-11-25 19:13   ` Tang, CQ
2019-11-25 19:13     ` [Intel-gfx] " Tang, CQ
2019-11-13 12:52 ` [PATCH i-g-t 6/9] i915: Exercise preemption timeout controls in sysfs Chris Wilson
2019-11-13 12:52   ` [Intel-gfx] " Chris Wilson
2019-11-13 12:52 ` [PATCH i-g-t 7/9] i915: Exercise sysfs heartbeat controls Chris Wilson
2019-11-13 12:52   ` [igt-dev] " Chris Wilson
2019-11-13 12:52   ` [Intel-gfx] " Chris Wilson
2019-11-13 12:52 ` [PATCH i-g-t 8/9] i915: Exercise timeslice sysfs property Chris Wilson
2019-11-13 12:52   ` [igt-dev] " Chris Wilson
2019-11-13 12:52   ` [Intel-gfx] " Chris Wilson
2019-11-13 12:52 ` [PATCH i-g-t 9/9] i915: Exercise I915_CONTEXT_PARAM_RINGSIZE Chris Wilson
2019-11-13 12:52   ` [igt-dev] " Chris Wilson
2019-11-13 12:52   ` [Intel-gfx] " Chris Wilson
2019-12-02 14:42   ` [igt-dev] " Janusz Krzysztofik
2019-12-02 14:42     ` Janusz Krzysztofik
2019-12-02 14:42     ` [Intel-gfx] " Janusz Krzysztofik
2019-12-02 14:59     ` Chris Wilson
2019-12-02 14:59       ` Chris Wilson
2019-12-02 14:59       ` [Intel-gfx] " Chris Wilson
2020-02-20 15:57       ` Janusz Krzysztofik
2020-02-20 15:57         ` Janusz Krzysztofik
2020-02-20 16:00         ` [Intel-gfx] " Chris Wilson
2020-02-20 16:00           ` Chris Wilson
2019-11-13 14:30 ` [igt-dev] ✓ Fi.CI.BAT: success for series starting with [i-g-t,1/9] i915/gem_exec_schedule: Split pi-ringfull into two tests Patchwork
2019-11-13 14:40 ` [igt-dev] ✗ GitLab.Pipeline: warning " Patchwork
2019-11-14  2:10 ` [igt-dev] ✓ Fi.CI.IGT: success " 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=20191113125240.3781-1-chris@chris-wilson.co.uk \
    --to=chris@chris-wilson.co.uk \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=intel-gfx@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.