From: John Harrison <John.C.Harrison@xxxxxxxxx> There is a mutex_lock in the GuC send action code path to ensure serialised access to the host-to-GuC mechanism. Acquiring the lock apparently sees random stalls of around 6ms. That is even when the lock is definitely not acquired by any other thread. In the case of sending pre-emption requests, a 6ms delay can really damage performance of the high priority task requiring pre-emption. It seems that using a mutex_trylock call first prevents this delay from occurring. Without the trylock, one particular test showed about one stall hit for every 1,500 pre-emption requests. With the trylock, no stalls in 3,200,000 pre-emptions. Signed-off-by: John Harrison <John.C.Harrison@xxxxxxxxx> --- drivers/gpu/drm/i915/intel_uc.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 680290ac36d6..e38eceb456c5 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -54,7 +54,10 @@ int intel_guc_send(struct intel_guc *guc, const u32 *action, u32 len, bool urgen if (WARN_ON(len < 1 || len > 15)) return -EINVAL; - mutex_lock(&guc->send_mutex); + /* Use a trylock first to avoid a ~6ms random stall when + * calling mutex_lock() directly!? */ + if (!mutex_trylock(&guc->send_mutex)) + mutex_lock(&guc->send_mutex); intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL); dev_priv->guc.action_count += 1; -- 2.13.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
