All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Cc: igt-dev@lists.freedesktop.org
Subject: Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/4] i915/gem_exec_balancer: Measure timeslicing fairness
Date: Mon, 14 Dec 2020 16:02:20 +0000	[thread overview]
Message-ID: <160796174068.13039.12669154062922128761@build.alporthouse.com> (raw)
In-Reply-To: <8a85eb50-1591-583d-30ae-18264774ae2a@linux.intel.com>

Quoting Tvrtko Ursulin (2020-12-14 15:51:24)
> 
> On 14/12/2020 10:51, Chris Wilson wrote:
> > Oversaturate the virtual engines on the system and check that each
> > workload receives a fair share of the available GPU time.
> 
> A simpler one to start with, I support that.
> 
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > ---
> >   tests/i915/gem_exec_balancer.c | 154 +++++++++++++++++++++++++++++++++
> >   1 file changed, 154 insertions(+)
> > 
> > diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
> > index 35a032ccb..5efd586ad 100644
> > --- a/tests/i915/gem_exec_balancer.c
> > +++ b/tests/i915/gem_exec_balancer.c
> > @@ -2763,6 +2763,157 @@ static void smoketest(int i915, int timeout)
> >       gem_close(i915, batch[0].handle);
> >   }
> >   
> > +static uint32_t read_ctx_timestamp(int i915, uint32_t ctx)
> > +{
> > +     struct drm_i915_gem_relocation_entry reloc;
> > +     struct drm_i915_gem_exec_object2 obj = {
> > +             .handle = gem_create(i915, 4096),
> > +             .offset = 32 << 20,
> > +             .relocs_ptr = to_user_pointer(&reloc),
> > +             .relocation_count = 1,
> > +     };
> > +     struct drm_i915_gem_execbuffer2 execbuf = {
> > +             .buffers_ptr = to_user_pointer(&obj),
> > +             .buffer_count = 1,
> > +             .rsvd1 = ctx,
> > +     };
> > +     uint32_t *map, *cs;
> > +     uint32_t ts;
> > +
> > +     cs = map = gem_mmap__device_coherent(i915, obj.handle,
> > +                                          0, 4096, PROT_WRITE);
> > +
> > +     *cs++ = 0x24 << 23 | 1 << 19 | 2; /* relative SRM */
> > +     *cs++ = 0x3a8; /* CTX_TIMESTAMP */
> > +     memset(&reloc, 0, sizeof(reloc));
> > +     reloc.target_handle = obj.handle;
> > +     reloc.presumed_offset = obj.offset;
> > +     reloc.offset = offset_in_page(cs);
> > +     reloc.delta = 4000;
> > +     *cs++ = obj.offset + 4000;
> > +     *cs++ = obj.offset >> 32;
> > +
> > +     *cs++ = MI_BATCH_BUFFER_END;
> > +
> > +     gem_execbuf(i915, &execbuf);
> > +     gem_sync(i915, obj.handle);
> > +     gem_close(i915, obj.handle);
> > +
> > +     ts = map[1000];
> > +     munmap(map, 4096);
> > +
> > +     return ts;
> > +}
> > +
> > +static int cmp_u32(const void *A, const void *B)
> > +{
> > +     const uint32_t *a = A, *b = B;
> > +
> > +     if (*a < *b)
> > +             return -1;
> > +     else if (*a > *b)
> > +             return 1;
> > +     else
> > +             return 0;
> > +}
> > +
> > +static int read_ctx_timestamp_frequency(int i915)
> > +{
> > +     int value = 12500000; /* icl!!! are you feeling alright? CTX vs CS */
> > +     drm_i915_getparam_t gp = {
> > +             .value = &value,
> > +             .param = I915_PARAM_CS_TIMESTAMP_FREQUENCY,
> > +     };
> > +     if (intel_gen(intel_get_drm_devid(i915)) != 11)
> > +             ioctl(i915, DRM_IOCTL_I915_GETPARAM, &gp);
> > +     return value;
> > +}
> > +
> > +static uint64_t div64_u64_round_up(uint64_t x, uint64_t y)
> > +{
> > +     return (x + y - 1) / y;
> > +}
> > +
> > +static uint64_t ticks_to_ns(int i915, uint64_t ticks)
> > +{
> > +     return div64_u64_round_up(ticks * NSEC_PER_SEC,
> > +                               read_ctx_timestamp_frequency(i915));
> > +}
> > +
> > +static void __fairslice(int i915,
> > +                     const struct i915_engine_class_instance *ci,
> > +                     unsigned int count)
> > +{
> > +     igt_spin_t *spin = NULL;
> > +     uint32_t ctx[count + 1];
> > +     uint32_t ts[count + 1];
> > +
> > +     igt_debug("Launching %zd spinners on %s\n",
> > +               ARRAY_SIZE(ctx), class_to_str(ci->engine_class));
> > +     igt_assert(ARRAY_SIZE(ctx) >= 3);
> > +
> > +     for (int i = 0; i < ARRAY_SIZE(ctx); i++) {
> > +             ctx[i] = load_balancer_create(i915, ci, count);
> > +             if (spin == NULL) {
> > +                     spin = __igt_spin_new(i915, .ctx = ctx[i]);
> > +             } else {
> > +                     struct drm_i915_gem_execbuffer2 eb = {
> > +                             .buffer_count = 1,
> > +                             .buffers_ptr = to_user_pointer(&spin->obj[IGT_SPIN_BATCH]),
> > +                             .rsvd1 = ctx[i],
> > +                     };
> > +                     gem_execbuf(i915, &eb);
> > +             }
> > +     }
> > +
> > +     sleep(2); /* over the course of many timeslices */
> > +
> > +     igt_assert(gem_bo_busy(i915, spin->handle));
> > +     igt_spin_end(spin);
> > +     igt_debug("Cancelled spinners\n");
> > +
> > +     for (int i = 0; i < ARRAY_SIZE(ctx); i++)
> > +             ts[i] = read_ctx_timestamp(i915, ctx[i]);
> 
> Now if we had context stats ioctl. :)
> 
> > +
> > +     for (int i = 0; i < ARRAY_SIZE(ctx); i++)
> > +             gem_context_destroy(i915, ctx[i]);
> > +     igt_spin_free(i915, spin);
> > +
> > +     qsort(ts, ARRAY_SIZE(ctx), sizeof(*ts), cmp_u32);
> > +     igt_info("%s: [%.1f, %.1f, %.1f] ms, expect %1.fms\n",
> > +              class_to_str(ci->engine_class),
> > +              1e-6 * ticks_to_ns(i915, ts[0]),
> > +              1e-6 * ticks_to_ns(i915, ts[(count + 1) / 2]),
> > +              1e-6 * ticks_to_ns(i915, ts[count]),
> > +              2e3 * count / ARRAY_SIZE(ctx));
> > +
> > +     igt_assert_f(ts[count], "CTX_TIMESTAMP not reported!\n");
> > +     igt_assert_f((ts[count] - ts[0]) * 6 < ts[(count + 1) / 2],
> > +                  "Range of timeslices greater than tolerable: %.2fms > %.2fms; unfair!\n",
> > +                  1e-6 * ticks_to_ns(i915, ts[count] - ts[0]),
> > +                  1e-6 * ticks_to_ns(i915, ts[(count  + 1) / 2]) / 6);
> 
> Just put a comment saying what is the criteria please. Six ranges vs 
> median, must be some statistical thing but that's not my forte.

The usual ballpark estimate for a test that should be reliable in CI.

I guess if we model it as a drunken walk, the range would scale with the
square-root of the number of timeslices. That would suggest we should not
expect deviations more than +-50ms. I plucked ~200ms out of the air,
which is turns out to be not too terrible a safety factor. :)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-12-14 16:02 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-14 10:51 [Intel-gfx] [PATCH i-g-t 1/4] i915/perf_pmu: Verify RC6 measurements before/after suspend Chris Wilson
2020-12-14 10:51 ` [igt-dev] " Chris Wilson
2020-12-14 10:51 ` [Intel-gfx] [PATCH i-g-t 2/4] i915/gem_exec_balancer: Measure timeslicing fairness Chris Wilson
2020-12-14 10:51   ` [igt-dev] " Chris Wilson
2020-12-14 15:51   ` [Intel-gfx] " Tvrtko Ursulin
2020-12-14 15:51     ` Tvrtko Ursulin
2020-12-14 16:02     ` Chris Wilson [this message]
2020-12-14 10:51 ` [Intel-gfx] [PATCH i-g-t 3/4] i915/gem_shrink: Refactor allocation sizing based on available memory Chris Wilson
2020-12-14 10:51   ` [igt-dev] " Chris Wilson
2020-12-14 15:57   ` [Intel-gfx] " Tvrtko Ursulin
2020-12-14 15:57     ` Tvrtko Ursulin
2020-12-14 16:21     ` [Intel-gfx] " Chris Wilson
2020-12-14 16:21       ` Chris Wilson
2020-12-14 16:24       ` [Intel-gfx] " Chris Wilson
2020-12-14 10:51 ` [Intel-gfx] [PATCH i-g-t 4/4] i915/gem_exec_schedule: Try to spot unfairness Chris Wilson
2020-12-14 10:51   ` [igt-dev] " Chris Wilson
2020-12-14 11:30 ` [igt-dev] ✓ Fi.CI.BAT: success for series starting with [i-g-t,1/4] i915/perf_pmu: Verify RC6 measurements before/after suspend Patchwork
2020-12-14 13:55 ` [igt-dev] ✗ Fi.CI.IGT: failure " Patchwork
2020-12-14 15:42 ` [Intel-gfx] [igt-dev] [PATCH i-g-t 1/4] " Tvrtko Ursulin
2020-12-14 15:42   ` Tvrtko Ursulin
2020-12-14 15:49   ` [Intel-gfx] " Chris Wilson
2020-12-14 15:49     ` Chris Wilson
2020-12-14 16:08     ` [Intel-gfx] " Tvrtko Ursulin
2020-12-14 16:08       ` Tvrtko Ursulin
2020-12-14 16:17       ` [Intel-gfx] " Chris Wilson
2020-12-14 16:17         ` Chris Wilson
2020-12-14 16:18         ` [Intel-gfx] " Chris Wilson
2020-12-14 16:18           ` Chris Wilson

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=160796174068.13039.12669154062922128761@build.alporthouse.com \
    --to=chris@chris-wilson.co.uk \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=tvrtko.ursulin@linux.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 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.