Re: [PATCH v3] drm/i915: Use exponential backoff for wait_for()

["Michal Wajdeczko" <michal.wajdeczko@intel.com>]

On Wed, 22 Nov 2017 10:36:15 +0100, Chris Wilson  
<chris@chris-wilson.co.uk> wrote:

> Quoting Sagar Arun Kamble (2017-11-22 07:41:02)
>>
>>
>> On 11/22/2017 2:29 AM, Chris Wilson wrote:
>> > Instead of sleeping for a fixed 1ms (roughly, depending on timer  
>> slack),
>> > start with a small sleep and exponentially increase the sleep on each
>> > cycle.
>> >
>> > A good example of a beneficiary is the guc mmio communication channel.
>> As Tvrtko said, for the current GuC communication (guc_send_mmio) we
>> will need to update fast timeout of
>> __intel_wait_for_register to 20us. Improvement this patch proposes
>> through wait_for will
>> certainly be seen once we switch over to GuC CT. May be specifying "GuC
>> CT channel" here is apt.
>
> guc mmio comm falls off the fastpath hitting the sleeping wait_for, and
> *is* improved by this patch. As far as the latency experienced by
> gem_exec_latency, there is no difference between a 10us sleep and
> spinning for 20us.  Changing the spin length to 20us!!! is
> something that you should talk to the guc about, at that point we really
> need an asynchronous communication channel (ct is still being used
> synchronously).

FYI: updated series with asynchronous CT will be posted soon, delay is due
to planned changes of commands format in GuC firmware.

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