Quoting Tvrtko Ursulin (2019-09-09 10:19:08) > > On 09/09/2019 08:12, Chris Wilson wrote: > > And give up if we never even make it to the start. > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111592 > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > > --- > > tests/perf_pmu.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c > > index d392a67d4..8a06e5d44 100644 > > --- a/tests/perf_pmu.c > > +++ b/tests/perf_pmu.c > > @@ -191,10 +191,12 @@ static unsigned long __spin_wait(int fd, igt_spin_t *spin) > > while (!igt_spin_has_started(spin)) { > > unsigned long t = igt_nsec_elapsed(&start); > > > > + igt_assert(gem_bo_busy(fd, spin->handle)); > > if ((t - timeout) > 250e6) { > > timeout = t; > > igt_warn("Spinner not running after %.2fms\n", > > (double)t / 1e6); > + igt_assert(t < 2e9); > > } > > } > > } else { > > @@ -202,6 +204,7 @@ static unsigned long __spin_wait(int fd, igt_spin_t *spin) > > usleep(500e3); /* Better than nothing! */ > > } > > > > + igt_assert(gem_bo_busy(fd, spin->handle)); > > return igt_nsec_elapsed(&start); > > } > > > > > > The 2s timeout for batch to start executing sounds okay. > > I'd pull up and consolidate the bo_busy checks into one at the top of > the function, since it is only telling us batch has been submitted. Or > you are thinking the second check brings value in checking batch is > still executing, hasn't failed or something? The thinking is to catch if we terminate the batch via hangcheck before writing the dword. I think there's value in knowing if we are slow vs dead. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
