[igt-dev] [Intel-gfx] [PATCH i-g-t] i915/perf_pmu: Check on the health of the spinner while waiting
Chris Wilson
chris at chris-wilson.co.uk
Mon Sep 9 09:23:42 UTC 2019
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 at chris-wilson.co.uk>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> > ---
> > 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
More information about the igt-dev
mailing list