[RFC 2/2] drm/i915: Avoid stalling on GuC send mutex lock

[John.C.Harrison@Intel.com]

From: John Harrison <John.C.Harrison@Intel.com>

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