All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Subject: [Intel-gfx] [PATCH 13/20] drm/i915: Move saturated workload detection back to the context
Date: Mon, 11 May 2020 08:57:15 +0100	[thread overview]
Message-ID: <20200511075722.13483-13-chris@chris-wilson.co.uk> (raw)
In-Reply-To: <20200511075722.13483-1-chris@chris-wilson.co.uk>

When we introduced the saturated workload detection to tell us to back
off from semaphore usage [semaphores have a noticeable impact on
contended bus cycles with the CPU for some heavy workloads], we first
introduced it as a per-context tracker. This allows individual contexts
to try and optimise their own usage, but we found that with the local
tracking and the no-semaphore boosting, the first context to disable
semaphores got a massive priority boost and so would starve the rest and
all new contexts (as they started with semaphores enabled and lower
priority). Hence we moved the saturated workload detection to the
engine, and a consequence had to disable semaphores on virtual engines.

Now that we do not have semaphore priority boosting, we can move the
tracking back to the context and virtual engines can now utilise the
faster inter-engine synchronisation.

References: 44d89409a12e ("drm/i915: Make the semaphore saturation mask global")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/gt/intel_context.c       |  1 +
 drivers/gpu/drm/i915/gt/intel_context_types.h |  2 ++
 drivers/gpu/drm/i915/gt/intel_engine_pm.c     |  2 --
 drivers/gpu/drm/i915/gt/intel_engine_types.h  |  2 --
 drivers/gpu/drm/i915/gt/intel_lrc.c           | 15 ---------------
 drivers/gpu/drm/i915/i915_request.c           |  4 ++--
 6 files changed, 5 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c b/drivers/gpu/drm/i915/gt/intel_context.c
index e4aece20bc80..762a251d553b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -268,6 +268,7 @@ static int __intel_context_active(struct i915_active *active)
 	if (err)
 		goto err_timeline;
 
+	ce->saturated = 0;
 	return 0;
 
 err_timeline:
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 4954b0df4864..aed26d93c2ca 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -78,6 +78,8 @@ struct intel_context {
 	} lrc;
 	u32 tag; /* cookie passed to HW to track this context on submission */
 
+	intel_engine_mask_t saturated; /* submitting semaphores too late? */
+
 	/* Time on GPU as tracked by the hw. */
 	struct {
 		struct ewma_runtime avg;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index d0a1078ef632..6d7fdba5adef 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -229,8 +229,6 @@ static int __engine_park(struct intel_wakeref *wf)
 	struct intel_engine_cs *engine =
 		container_of(wf, typeof(*engine), wakeref);
 
-	engine->saturated = 0;
-
 	/*
 	 * If one and only one request is completed between pm events,
 	 * we know that we are inside the kernel context and it is
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index c113b7805e65..2b1232a233bc 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -332,8 +332,6 @@ struct intel_engine_cs {
 
 	struct intel_context *kernel_context; /* pinned */
 
-	intel_engine_mask_t saturated; /* submitting semaphores too late? */
-
 	struct {
 		struct delayed_work work;
 		struct i915_request *systole;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 382969c1c7ca..730f639a4477 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -5591,21 +5591,6 @@ intel_execlists_create_virtual(struct intel_engine_cs **siblings,
 	ve->base.instance = I915_ENGINE_CLASS_INVALID_VIRTUAL;
 	ve->base.uabi_instance = I915_ENGINE_CLASS_INVALID_VIRTUAL;
 
-	/*
-	 * The decision on whether to submit a request using semaphores
-	 * depends on the saturated state of the engine. We only compute
-	 * this during HW submission of the request, and we need for this
-	 * state to be globally applied to all requests being submitted
-	 * to this engine. Virtual engines encompass more than one physical
-	 * engine and so we cannot accurately tell in advance if one of those
-	 * engines is already saturated and so cannot afford to use a semaphore
-	 * and be pessimized in priority for doing so -- if we are the only
-	 * context using semaphores after all other clients have stopped, we
-	 * will be starved on the saturated system. Such a global switch for
-	 * semaphores is less than ideal, but alas is the current compromise.
-	 */
-	ve->base.saturated = ALL_ENGINES;
-
 	snprintf(ve->base.name, sizeof(ve->base.name), "virtual");
 
 	intel_engine_init_active(&ve->base, ENGINE_VIRTUAL);
diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index 9738dab5a9f6..dae0b2c44951 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -469,7 +469,7 @@ bool __i915_request_submit(struct i915_request *request)
 	 */
 	if (request->sched.semaphores &&
 	    i915_sw_fence_signaled(&request->semaphore))
-		engine->saturated |= request->sched.semaphores;
+		request->context->saturated |= request->sched.semaphores;
 
 	engine->emit_fini_breadcrumb(request,
 				     request->ring->vaddr + request->postfix);
@@ -921,7 +921,7 @@ already_busywaiting(struct i915_request *rq)
 	 *
 	 * See the are-we-too-late? check in __i915_request_submit().
 	 */
-	return rq->sched.semaphores | READ_ONCE(rq->engine->saturated);
+	return rq->sched.semaphores | READ_ONCE(rq->context->saturated);
 }
 
 static int
-- 
2.20.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2020-05-11  7:58 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-11  7:57 [Intel-gfx] [PATCH 01/20] drm/i915/gt: Mark up the racy read of execlists->context_tag Chris Wilson
2020-05-11  7:57 ` [Intel-gfx] [PATCH 02/20] drm/i915/gt: Couple up old virtual breadcrumb on new sibling Chris Wilson
2020-05-12  8:41   ` Tvrtko Ursulin
2020-05-12  8:49     ` Chris Wilson
2020-05-12 10:12       ` Tvrtko Ursulin
2020-05-12 10:28         ` Chris Wilson
2020-05-11  7:57 ` [Intel-gfx] [PATCH 03/20] dma-buf: Use atomic_fetch_add() for the context id Chris Wilson
2020-05-11  7:57 ` [Intel-gfx] [PATCH 04/20] drm/i915: Mark the addition of the initial-breadcrumb in the request Chris Wilson
2020-05-11 11:21   ` Mika Kuoppala
2020-05-11 11:30     ` Chris Wilson
2020-05-11  7:57 ` [Intel-gfx] [PATCH 05/20] drm/i915: Tidy awaiting on dma-fences Chris Wilson
2020-05-11 11:30   ` Mika Kuoppala
2020-05-11  7:57 ` [Intel-gfx] [PATCH 06/20] dma-buf: Proxy fence, an unsignaled fence placeholder Chris Wilson
2020-05-11  7:57 ` [Intel-gfx] [PATCH 07/20] drm/syncobj: Allow use of dma-fence-proxy Chris Wilson
2020-05-11  7:57 ` [Intel-gfx] [PATCH 08/20] drm/i915/gem: Teach execbuf how to wait on future syncobj Chris Wilson
2020-05-11  7:57 ` [Intel-gfx] [PATCH 09/20] drm/i915/gem: Allow combining submit-fences with syncobj Chris Wilson
2020-05-11  7:57 ` [Intel-gfx] [PATCH 10/20] drm/i915/gt: Declare when we enabled timeslicing Chris Wilson
2020-05-11  7:57 ` [Intel-gfx] [PATCH 11/20] drm/i915/gem: Remove redundant exec_fence Chris Wilson
2020-05-11  7:57 ` [Intel-gfx] [PATCH 12/20] drm/i915: Drop no-semaphore boosting Chris Wilson
2020-05-11  7:57 ` Chris Wilson [this message]
2020-05-11  7:57 ` [Intel-gfx] [PATCH 14/20] drm/i915: Remove the saturation backoff for HW semaphores Chris Wilson
2020-05-11  7:57 ` [Intel-gfx] [PATCH 15/20] drm/i915/gt: Use built-in active intel_context reference Chris Wilson
2020-05-11  7:57 ` [Intel-gfx] [PATCH 16/20] drm/i915: Drop I915_RESET_TIMEOUT and friends Chris Wilson
2020-05-11  7:57 ` [Intel-gfx] [PATCH 17/20] drm/i915: Drop I915_IDLE_ENGINES_TIMEOUT Chris Wilson
2020-05-11  7:57 ` [Intel-gfx] [PATCH 18/20] drm/i915/selftests: Always call the provided engine->emit_init_breadcrumb Chris Wilson
2020-05-11  7:57 ` [Intel-gfx] [PATCH 19/20] drm/i915: Emit await(batch) before MI_BB_START Chris Wilson
2020-05-11  7:57 ` [Intel-gfx] [PATCH 20/20] drm/i915/selftests: Always flush before unpining after writing Chris Wilson
2020-05-11  8:05 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/20] drm/i915/gt: Mark up the racy read of execlists->context_tag Patchwork
2020-05-11  8:32 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2020-05-11  9:07 ` [Intel-gfx] [PATCH 01/20] " Mika Kuoppala

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200511075722.13483-13-chris@chris-wilson.co.uk \
    --to=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.