[Intel-gfx] [PATCH i-g-t] i915/perf_pmu: Check on the health of the spinner while waiting
Tvrtko Ursulin
tvrtko.ursulin at linux.intel.com
Mon Sep 9 09:34:11 UTC 2019
On 09/09/2019 10:23, Chris Wilson wrote:
> 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.
Yeah as guessed then - agreed.
Regards,
Tvrtko
More information about the Intel-gfx
mailing list