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
next 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: linkBe 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.