[igt-dev] [Intel-gfx] [PATCH i-g-t] i915/perf_pmu: Check on the health of the spinner while waiting

[Tvrtko Ursulin]

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