Quoting Chris Wilson (2018-02-19 16:19:21)
> During igt, we frequently call into the driver to reset both HW and
> driver state (idling the device, waiting for it to become idle and
> freeing off old objects) to ensure that we start each test/subtest/pass
> from known state. This process incurs an RCU barrier or two to ensure
> that any such pending frees are indeed flushed before we return.
> However, unconditionally waiting on the RCU barrier adds needless delay
> to many callers, which adds up to several seconds when repeated thousands
> of times. We can skip the rcu_barrier() if by tracking how many outstanding
> frees we have, we know there are none.
> The same path is used along suspend, where we may be able to save the
> unconditional RCU barrier.

To put it into perspective with a completely meaningless
microbenchmark, igt/gem_sync/idle is improved from 50ms to 30us on bdw.

> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com>
> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
Intel-gfx mailing list

Reply via email to