[Intel-gfx] [PATCH v5 2/5] drm/i915: Watchdog timeout: IRQ handler for gen8+

[Tvrtko Ursulin]

On 27/03/2019 01:58, Carlos Santa wrote:

[snip]

>>> v13: Rebase
>>> v14: Rebase, skip checking for the guilty seqno in the tasklet
>>> (Tvrtko)
>>
>> IIRC I only asked about it so I guess you tried it and it works well?
>>
>> Can you also post the IGTs so we can see the test coverage?
>>
>> Regards,
>>
>> Tvrtko
> 
> Yeah, the unit test works but it's still the very simple one (updated
> for the uAPI mods) I started with last August, I still need to add more
> to it though...
> 
> 
> https://lists.freedesktop.org/archives/igt-dev/2018-September/005834.html
> 
> Right now, I am on the hrtimer workaround to see how that works, will
> get back to the test coverage after that...

It may be tricky though so it may make sense to extend the test first 
until you can make a test which fails with the hw watchdog 
implementation. :)

What are the test cases I can think of..

Probably could use fence status to figure out which context was reset, 
and could use spin batches with userspace timers to control durations. 
And corking to control ordering. Then you need some preemption 
(priorities). A mix of batches on contexts with and without the watchdog 
and checking the expected one was reset.

ctx = create_context

long batch -> executed

ctx.set_watchdog

ctx.long batch -> canceled

ctx2.long_batch
ctx.long_batch

  -> executed, canceled

ctx.long_batch
ctx2.long_batch

  -> canceled, executed

(Hm maybe you end up having to use nop calibrated batches to make the 
last one work.)

ctx.batch_just_below_threshold -> executed

(Try a few times in a loop, or a bunch of batches like this one 
submitted at once and check all executed.)

Then expand and submit one random one of them as over threshold and 
check only that one was canceled.

Flavour of the above with two contexts, one with watchdog, one without.

Flavour where watchdog is set only on some engines. Single context, 
batches on different engines = different watchog behaviour.

Then preemption handling.. submit a long batch and after half of 
expected runtime submit a higher prio batch with half duration. Check 
the latter was executed. Then check the status of the former. What 
should it be? (Don't know, open to define the semantics..)

Submit a low prio long batch, wo/ watchdog, then a higher prio with 
watchdog and check it was canceled before the low prio one completed.

This is how much I can think of right now, but should be a good start.

Regards,

Tvrtko