Re: [RFC i-g-t] tests/perf_pmu: Verify engine busyness accuracy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 12/12/2017 15:05, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-12-12 14:53:00)
From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>

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@xxxxxxxxx>
---
  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.

Regards,

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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux