Re: [PATCH igt] igt/gem_exec_schedule: Exercise preemption timeout

From: Chris Wilson <chris@chris-wilson.co.uk>
To: Antonio Argenziano <antonio.argenziano@intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH igt] igt/gem_exec_schedule: Exercise preemption timeout
Date: Fri, 13 Apr 2018 18:28:08 +0100	[thread overview]
Message-ID: <152364048823.2662.3311147004608569929@mail.alporthouse.com> (raw)
In-Reply-To: <eb86f8da-7ce9-4348-c546-c3f639b9c678@intel.com>

Quoting Antonio Argenziano (2018-04-13 18:20:02)
> 
> 
> On 13/04/18 08:59, Chris Wilson wrote:
> > die. What we expect to happen is spin[0] is (more or less, there is still
> > dmesg) silently killed by the preempt timeout. If that timeout doesn't
> 
> The silent part is interesting, how do we make sure that during normal 
> preemption operations (e.g. preempt on an ARB_CHECK) we didn't silently 
> discard the preempted batch? Do we care?

Not particularly. From our point of view, the goal is that the high
priority spin[2] runs, no matter what. If the other requests cooperate,
that works out best for them.

The challenge for the test itself is detecting when the timeout was hit.
We aren't particularly good at demonstrating the spinner doesn't block
preemption, it is demonstrated in other tests, but we don't assert that
it is so.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx