[igt-dev] [Intel-gfx] [PATCH i-g-t 2/3] tests/gem_eio: Speed up test execution

[Tvrtko Ursulin]

On 22/03/2018 18:14, Chris Wilson wrote:
> Quoting Antonio Argenziano (2018-03-22 17:32:46)
>>
>>
>> On 22/03/18 05:42, Chris Wilson wrote:
>>> Quoting Tvrtko Ursulin (2018-03-22 12:36:58)
>>>>
>>>> On 22/03/2018 11:39, Chris Wilson wrote:
>>>>> Quoting Tvrtko Ursulin (2018-03-22 11:17:11)
>>>>>
>>>>>>            trigger_reset(fd);
>>>>>> +
>>>>>> +       /* HACK for CI */
>>>>>> +       igt_assert(igt_nsec_elapsed(&ts) < 5e9);
>>>>>
>>>>> igt_seconds_elapsed() the approximation is worth the readability.
>>>>>
>>>>> In this case you might like to try igt_set_timeout(), as I think each
>>>>> subtest and exithandlers are in place to make them robust against
>>>>> premature failures.
>>>>
>>>> Well this was just to see that will happen on the shards here. As
>>>> mentioned in the commit I get that yet unexplained GPU hang at subtest
>>>> exit here. So the assert above is just to notice if the same happens on
>>>> shards.
>>>
>>> And I was thinking it was a reasonable enhancement :) Probably more so
>>> for igt/gem_wait itself to ask that if we reset the request we are
>>> waiting upon it completes in a timely manner. (We don't care about
>>> wedged handling there, just reset handling.)
>>
>> How about checking for reset when we do gem_test_engine(), which seems
>> to not fail on reset, (crudely https://paste.debian.net/1016059/)?
> 
> I was thinking that the timeout would be good around the test as a
> whole, because it is now meant to be uberfast.

Whole subtests with igt_set_timeout, or alternatively I was thinking to 
just time the trigger_reset helper. Since other bits are covered by 
short timeout gem_wait now, I think tigger_reset is the only one which I 
need to additionally cover. If we stick with signals for delayed hangs, 
that also might be simpler than to find a different signal than SIGALARM 
for it (so it doesn't clash with igt_set_timeout).

Regards,

Tvrtko