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 Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
