All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org,
	Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Subject: [PATCH 4/7] drm/i915: Handle async cancellation in sentinel assert
Date: Wed, 24 Mar 2021 12:13:32 +0000	[thread overview]
Message-ID: <20210324121335.2307063-5-tvrtko.ursulin@linux.intel.com> (raw)
In-Reply-To: <20210324121335.2307063-1-tvrtko.ursulin@linux.intel.com>

From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

With the watchdog cancelling requests asynchronously to preempt-to-busy we
need to relax one assert making it apply only to requests not in error.

v2:
 * Check against the correct request!

v3:
 * Simplify the check to avoid the question of when to sample the fence
   error vs sentinel bit.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
 drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 4b870eca9693..9d264d4ffa75 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -700,9 +700,8 @@ assert_pending_valid(const struct intel_engine_execlists *execlists,
 {
 	struct intel_engine_cs *engine =
 		container_of(execlists, typeof(*engine), execlists);
-	struct i915_request * const *port, *rq;
+	struct i915_request * const *port, *rq, *prev = NULL;
 	struct intel_context *ce = NULL;
-	bool sentinel = false;
 	u32 ccid = -1;
 
 	trace_ports(execlists, msg, execlists->pending);
@@ -752,15 +751,20 @@ assert_pending_valid(const struct intel_engine_execlists *execlists,
 		 * Sentinels are supposed to be the last request so they flush
 		 * the current execution off the HW. Check that they are the only
 		 * request in the pending submission.
+		 *
+		 * NB: Due to the async nature of preempt-to-busy and request
+		 * cancellation we need to handle the case where request
+		 * becomes a sentinel in parallel to CSB processing.
 		 */
-		if (sentinel) {
+		if (prev && i915_request_has_sentinel(prev) &&
+		    !READ_ONCE(prev->fence.error)) {
 			GEM_TRACE_ERR("%s: context:%llx after sentinel in pending[%zd]\n",
 				      engine->name,
 				      ce->timeline->fence_context,
 				      port - execlists->pending);
 			return false;
 		}
-		sentinel = i915_request_has_sentinel(rq);
+		prev = rq;
 
 		/*
 		 * We want virtual requests to only be in the first slot so
-- 
2.27.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 4/7] drm/i915: Handle async cancellation in sentinel assert
Date: Wed, 24 Mar 2021 12:13:32 +0000	[thread overview]
Message-ID: <20210324121335.2307063-5-tvrtko.ursulin@linux.intel.com> (raw)
In-Reply-To: <20210324121335.2307063-1-tvrtko.ursulin@linux.intel.com>

From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

With the watchdog cancelling requests asynchronously to preempt-to-busy we
need to relax one assert making it apply only to requests not in error.

v2:
 * Check against the correct request!

v3:
 * Simplify the check to avoid the question of when to sample the fence
   error vs sentinel bit.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
 drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 4b870eca9693..9d264d4ffa75 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -700,9 +700,8 @@ assert_pending_valid(const struct intel_engine_execlists *execlists,
 {
 	struct intel_engine_cs *engine =
 		container_of(execlists, typeof(*engine), execlists);
-	struct i915_request * const *port, *rq;
+	struct i915_request * const *port, *rq, *prev = NULL;
 	struct intel_context *ce = NULL;
-	bool sentinel = false;
 	u32 ccid = -1;
 
 	trace_ports(execlists, msg, execlists->pending);
@@ -752,15 +751,20 @@ assert_pending_valid(const struct intel_engine_execlists *execlists,
 		 * Sentinels are supposed to be the last request so they flush
 		 * the current execution off the HW. Check that they are the only
 		 * request in the pending submission.
+		 *
+		 * NB: Due to the async nature of preempt-to-busy and request
+		 * cancellation we need to handle the case where request
+		 * becomes a sentinel in parallel to CSB processing.
 		 */
-		if (sentinel) {
+		if (prev && i915_request_has_sentinel(prev) &&
+		    !READ_ONCE(prev->fence.error)) {
 			GEM_TRACE_ERR("%s: context:%llx after sentinel in pending[%zd]\n",
 				      engine->name,
 				      ce->timeline->fence_context,
 				      port - execlists->pending);
 			return false;
 		}
-		sentinel = i915_request_has_sentinel(rq);
+		prev = rq;
 
 		/*
 		 * We want virtual requests to only be in the first slot so
-- 
2.27.0

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

  parent reply	other threads:[~2021-03-24 12:14 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-24 12:13 [PATCH v4 0/7] Default request/fence expiry + watchdog Tvrtko Ursulin
2021-03-24 12:13 ` [Intel-gfx] " Tvrtko Ursulin
2021-03-24 12:13 ` [PATCH 1/7] drm/i915: Extract active lookup engine to a helper Tvrtko Ursulin
2021-03-24 12:13   ` [Intel-gfx] " Tvrtko Ursulin
2021-03-24 12:21   ` Matthew Auld
2021-03-24 12:21     ` Matthew Auld
2021-03-24 12:13 ` [PATCH 2/7] drm/i915: Individual request cancellation Tvrtko Ursulin
2021-03-24 12:13   ` [Intel-gfx] " Tvrtko Ursulin
2021-03-24 15:24   ` Matthew Auld
2021-03-24 15:24     ` Matthew Auld
2021-03-24 12:13 ` [PATCH 3/7] drm/i915: Restrict sentinel requests further Tvrtko Ursulin
2021-03-24 12:13   ` [Intel-gfx] " Tvrtko Ursulin
2021-03-24 15:25   ` Matthew Auld
2021-03-24 15:25     ` [Intel-gfx] " Matthew Auld
2021-03-26  0:01     ` Daniel Vetter
2021-03-26  0:01       ` Daniel Vetter
2021-03-24 12:13 ` Tvrtko Ursulin [this message]
2021-03-24 12:13   ` [Intel-gfx] [PATCH 4/7] drm/i915: Handle async cancellation in sentinel assert Tvrtko Ursulin
2021-03-24 17:22   ` Matthew Auld
2021-03-24 17:22     ` Matthew Auld
2021-03-24 12:13 ` [PATCH 5/7] drm/i915: Request watchdog infrastructure Tvrtko Ursulin
2021-03-24 12:13   ` [Intel-gfx] " Tvrtko Ursulin
2021-03-26  0:00   ` Daniel Vetter
2021-03-26  0:00     ` [Intel-gfx] " Daniel Vetter
2021-03-26 10:32     ` Tvrtko Ursulin
2021-03-26 10:32       ` [Intel-gfx] " Tvrtko Ursulin
2021-03-24 12:13 ` [PATCH 6/7] drm/i915: Fail too long user submissions by default Tvrtko Ursulin
2021-03-24 12:13   ` [Intel-gfx] " Tvrtko Ursulin
2021-03-24 12:13 ` [PATCH 7/7] drm/i915: Allow configuring default request expiry via modparam Tvrtko Ursulin
2021-03-24 12:13   ` [Intel-gfx] " Tvrtko Ursulin
2021-03-26  0:25   ` Daniel Vetter
2021-03-26  0:25     ` [Intel-gfx] " Daniel Vetter
2021-03-24 13:16 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Default request/fence expiry + watchdog (rev5) Patchwork
2021-03-24 13:21 ` [Intel-gfx] ✗ Fi.CI.DOCS: " Patchwork
2021-03-24 13:48 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-03-24 23:29 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2021-03-26  9:10 ` [Intel-gfx] [PATCH v4 0/7] Default request/fence expiry + watchdog Daniel Vetter
2021-03-26  9:10   ` Daniel Vetter
2021-03-26 10:31   ` Tvrtko Ursulin
2021-03-26 10:31     ` Tvrtko Ursulin
2021-04-08 10:18     ` Daniel Vetter
2021-04-08 10:18       ` Daniel Vetter

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=20210324121335.2307063-5-tvrtko.ursulin@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=Intel-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=tvrtko.ursulin@intel.com \
    /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.