On Wed, 22 Nov 2017 10:36:15 +0100, Chris Wilson
<chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
