[Intel-gfx] [PATCH i-g-t v2] tests/perf_pmu: Test busyness reporting in face of GPU hangs
Tvrtko Ursulin
tvrtko.ursulin at linux.intel.com
Thu Mar 1 09:21:52 UTC 2018
On 01/03/2018 08:08, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-02-28 17:15:19)
>> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>>
>> Verify that the reported busyness is in line with what would we expect
>> from a batch which causes a hang and gets kicked out from the engine.
>>
>> v2: Change to explicit igt_force_gpu_reset instead of guessing when a spin
>> batch will hang. (Chris Wilson)
>>
>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>
> It's nice and quick, yes. However, sometime the opposite is true and you
> have to wait for the batch you want to start before pulling the trigger.
>
> I'd put a usleep(100) in there /* Wait for batch to execute */ and we
Hm, but reset is triggered after the first sleep (which checks for 100%
busy). So even the non-hanging test flavour could be affect if the delay
before execution is so long. So by this logic this usleep(100) (or more
for small core CI) should then go to many tests. Only difference in the
hang flavour is that if it completely failed to run until after the
reset, then the idle assert would fail. So maybe I should just add an
assert that the batch is idle before sampling pmu after reset?
Regards,
Tvrtko
> should put the wait-for-execution ability in igt_spin_t. Unfortunately
> that requires MI_STORE_DWORD_IMM (or more creativity) limiting it's
> availability.
>
> With the sleep issue addressed (commented upon if nothing else),
> Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
> -Chris
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
More information about the Intel-gfx
mailing list