On 23/11/2017 00:08, Chris Wilson wrote:
Since the legacy ringbuffer uses a sampling technique, it is limited to
an accuracy based on a 200Hz timer, or 5ms. We assert that measurements
are within 5%, so with a 100ms duration that gives us no room for the
systemmatic error in our sampling. Bump the duration to 500ms to give us
plenty of safety margin, if it then fails, it should not be due to the
sampling.
Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
---
tests/perf_pmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index 61da224e..50ca7895 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -44,7 +44,7 @@
IGT_TEST_DESCRIPTION("Test the i915 pmu perf interface");
const double tolerance = 0.05f;
-const unsigned long batch_duration_ns = 100e6;
+const unsigned long batch_duration_ns = 500e6;
static int open_pmu(uint64_t config)
{
Hm, it is definitely too short in sampling mode as you describe in the
commit.
I am only a bit unhappy that 5x increase makes the total test run much
longer. Embedding knowledge in the test on what counters are sampling
and what not would be too bad?
Or perhaps a compromise on those by extending the batch duration a
little bit less, and increasing the tolerance a bit?
That would mean adding variables like sampling_batch_duration_ns and
sampling_tolerance and busyness based tests would also pick based on gen.
If you would be happy with that I'll implement it.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
