On 07/12/2017 10:35, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-12-07 10:25:36)
On 06/12/2017 23:12, Chris Wilson wrote:
Still CI remains obstinate that RC6 is not smoothly incrementing during
the sample period. Tweak the wait_for_rc6() to first wait for the
initial Evaluation Interval before polling.
Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
---
tests/perf_pmu.c | 15 +++++++++++----
tests/pm_rc6_residency.c | 15 +++++++++++----
2 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index ff6568221..917832d1b 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -1000,13 +1000,20 @@ static bool wait_for_rc6(int fd)
struct timespec tv = {};
uint64_t start, now;
- start = pmu_read_single(fd);
+ /* First wait for roughly an RC6 Evaluation Interval */
+ usleep(160 * 1000);
+
+ /* Then poll for RC6 to start ticking */
+ now = pmu_read_single(fd);
do {
- usleep(50);
+ start = now;
+ usleep(5000);
now = pmu_read_single(fd);
- } while (start == now && !igt_seconds_elapsed(&tv));
+ if (now - start > 2e6)
+ return true;
What is the thinking behind the 2ms of RC6 after 5ms of sleep criteria?
I was being worried about random fluctuations. The sleep before is
probably good enough, basically I'm guessing at what caused it to fail,
with the starting point being that we declared RC6 active before it was.
2ms was trying to guess at what the granularity of the counter was,
which is ~1us, not 1ms. Respin with 2us instead?
Hard for me to say since after the last patch I expected that once the
counter is running that it is running. Now I don't know anything any
longer. :/
No harm in trying since the current version is unreliable..
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
