[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?



> 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