Re: [PATCH 11/25] drm/i915: Spin after waking up for an interrupt

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 28/06/16 10:17, Chris Wilson wrote:
> On Tue, Jun 28, 2016 at 09:55:17AM +0100, Chris Wilson wrote:
>> On Mon, Jun 27, 2016 at 11:32:10AM +0100, Tvrtko Ursulin wrote:
>>>
>>> On 25/06/16 11:12, Chris Wilson wrote:
>>>> When waiting for an interrupt (waiting for the GPU to complete some
>>>> work), we know we are the single waiter for the GPU. We also know when
>>>
>>> You mean we know we were the first waiter, if we have been woken up?
>>> Or perhaps the single waiter for this request? (more or less, maybe
>>> close enough) Or also s/", we know we are/, and we know we are" ?
>>
>> Single waiter for the engine. s/and//; it follows from and is not
>> conditional. To be here we know we are the only piece of code performing
>> this check. There may be threads entering i915_wait_request that also
>> get to spin before adding themselves to the waitqueue, but of all waiters,
>> we are the only one allowed to spin on this engine.
>
> Changed to:
>
> When waiting for an interrupt (waiting for the engine to complete some
> work), we know we are the only waiter to be woken on this engine. We also
> know when the GPU has nearly completed our request (or at least started
> processing it), so after being woken and we detect that the GPU is
> active and working on our request, allow us the bottom-half (the first
> waiter who wakes up to handle checking the seqno after the interrupt) to
> spin for a very short while to reduce client latencies.
>
> The impact is minimal, there was an improvement to the realtime-vs-many
> clients case, but exporting the function proves useful later. However,
> it is tempting to adjust irq_seqno_barrier to include the spin. The
> problem is first ensuring that the "start-of-request" seqno is coherent
> as we use that as our basis for judging when it is ok to spin. If we
> could, spinning there could dramatically shorten some sleeps, and allow
> us to make the barriers more conservative to handle missed seqno writes
> on more platforms (all gen7+ are known to have the occasional issue, at
> least).

Super clear now;

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx