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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux