[Intel-gfx] [RFC i-g-t] tests/perf_pmu: Verify engine busyness accuracy
Chris Wilson
chris at chris-wilson.co.uk
Tue Dec 12 15:24:00 UTC 2017
Quoting Tvrtko Ursulin (2017-12-12 15:21:32)
>
> On 12/12/2017 15:05, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2017-12-12 14:53:00)
> >> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> >>
> >> A subtest to verify that the engine busyness is reported with expected
> >> accuracy on platforms where the feature is available.
> >>
> >> We test three patterns: 2%, 50% and 98% load per engine.
> >>
> >> Problematic part is we also rely on scheduling latencies and the no-op
> >> batch calibration accuracy. For these reasons we use a large-ish tolerance
> >> and also set the load emitting process to SCHED_FIFO.
> >>
> >> Load calibration is also moved to a subtest group fixture so the set-up
> >> time is shared between all subtests which use it.
> >>
> >> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> >> ---
> >> tests/perf_pmu.c | 125 ++++++++++++++++++++++++++++++++++++++++++++++++++-----
> >> 1 file changed, 115 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
> >> index db7696115a7b..ec6b0ee1cb86 100644
> >> --- a/tests/perf_pmu.c
> >> +++ b/tests/perf_pmu.c
> >> @@ -35,6 +35,7 @@
> >> #include <dirent.h>
> >> #include <time.h>
> >> #include <poll.h>
> >> +#include <sched.h>
> >>
> >> #include "igt.h"
> >> #include "igt_core.h"
> >> @@ -79,6 +80,17 @@ init(int gem_fd, const struct intel_execution_engine2 *e, uint8_t sample)
> >> close(fd);
> >> }
> >>
> >> +static uint64_t __pmu_read_single(int fd, uint64_t *ts)
> >> +{
> >> + uint64_t data[2];
> >> +
> >> + igt_assert_eq(read(fd, data, sizeof(data)), sizeof(data));
> >> +
> >> + *ts = data[1];
> >> +
> >> + return data[0];
> >> +}
> >> +
> >> static uint64_t pmu_read_single(int fd)
> >> {
> >> uint64_t data[2];
> >> @@ -665,6 +677,77 @@ multi_client(int gem_fd, const struct intel_execution_engine2 *e)
> >> assert_within_epsilon(val[1], slept, tolerance);
> >> }
> >>
> >> +static void
> >> +accuracy(int gem_fd, const struct intel_execution_engine2 *e,
> >> + unsigned long cal_ms_sz, unsigned long target_busy_pct)
> >> +{
> >> + const unsigned long busy_us = 2500;
> >> + const unsigned long idle_us = 100 * (busy_us - target_busy_pct *
> >> + busy_us / 100) / target_busy_pct;
> >> + const unsigned int test_us = 1e6;
> >> + double busy_r;
> >> + uint64_t val[2];
> >> + uint64_t ts[2];
> >> + int fd;
> >> +
> >> + igt_require(intel_gen(intel_get_drm_devid(gem_fd)) >= 8);
> >> +
> >> + assert_within_epsilon((double)busy_us / (busy_us + idle_us),
> >> + (double)target_busy_pct / 100.0, tolerance);
> >> +
> >> + /* Emit PWM pattern on the engine from a child. */
> >> + igt_fork(child, 1) {
> >> + struct sched_param rt = { .sched_priority = 99 };
> >> + const uint32_t bbe = MI_BATCH_BUFFER_END;
> >> + const unsigned long loops = test_us / (busy_us + idle_us);
> >> + const unsigned long sz = ALIGN(busy_us * cal_ms_sz / 1000,
> >> + sizeof(uint32_t));
> >> + struct drm_i915_gem_exec_object2 obj = { };
> >> + struct drm_i915_gem_execbuffer2 eb = {
> >> + .buffers_ptr = to_user_pointer(&obj),
> >> + .buffer_count = 1,
> >> + .flags = e2ring(gem_fd, e)
> >> + };
> >> + unsigned long i;
> >> +
> >> + /* We need the best sleep accuracy we can get. */
> >> + igt_require(sched_setscheduler(0,
> >> + SCHED_FIFO | SCHED_RESET_ON_FORK,
> >> + &rt) == 0);
> >> +
> >> + obj.handle = gem_create(gem_fd, sz);
> >> + gem_write(gem_fd, obj.handle, sz - sizeof(bbe), &bbe,
> >> + sizeof(bbe));
> >> +
> >> + for (i = 0; i < loops; i++) {
> >> + gem_execbuf(gem_fd, &eb);
> >> + gem_sync(gem_fd, obj.handle);
> >> + usleep(idle_us);
> >> + }
> >> +
> >> + gem_close(gem_fd, obj.handle);
> >> + }
> >
> > Wouldn't using a signaling thread and a igt_spin_t give you better
> > accuracy, with the bonus of not requiring calibration?
>
> Sounds like it could be better if main source of error is calibration
> and not the scheduler. I have no idea at the moment which one it is so
> I'll give it a try.
I think you'll still need a RT-99 thread, but it's worth a shot. :)
-Chris
More information about the Intel-gfx
mailing list