From: jeff.mcgee@intel.com
To: intel-gfx@lists.freedesktop.org
Cc: ben@bwidawsk.net, kalyan.kondapally@intel.com
Subject: [RFC 5/8] drm/i915: Consider preemption when finding the active request
Date: Fri, 16 Mar 2018 11:31:02 -0700 [thread overview]
Message-ID: <20180316183105.16027-6-jeff.mcgee@intel.com> (raw)
In-Reply-To: <20180316183105.16027-1-jeff.mcgee@intel.com>
From: Jeff McGee <jeff.mcgee@intel.com>
The active request is found by scanning the engine timeline for the
request that follows the last completed request. That method is accurate
if there is no preemption in progress, because the engine will certainly
have started that request. If there is a preemption in progress, it could
have completed leaving the engine idle. In this case the request we
identified with the above method is not active and may not even have been
started. We must check for this condition to avoid fingering an innocent
request during reset.
This patch is required to support the force preemption feature.
Test: Run IGT gem_exec_fpreempt repeatedly.
Change-Id: I63a9f64446e24d4ee36b4af32854699bda006ddd
Signed-off-by: Jeff McGee <jeff.mcgee@intel.com>
---
drivers/gpu/drm/i915/i915_gem.c | 49 +++++++++++++++++++++++++++++++++++++----
1 file changed, 45 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e2961e3913b8..9780d9026ce6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2739,9 +2739,9 @@ static void i915_gem_context_mark_innocent(struct i915_gem_context *ctx)
}
struct drm_i915_gem_request *
-i915_gem_find_active_request(struct intel_engine_cs *engine)
+i915_gem_find_pending_request(struct intel_engine_cs *engine)
{
- struct drm_i915_gem_request *request, *active = NULL;
+ struct drm_i915_gem_request *request, *pending = NULL;
unsigned long flags;
/* We are called by the error capture and reset at a random
@@ -2762,12 +2762,53 @@ i915_gem_find_active_request(struct intel_engine_cs *engine)
GEM_BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
&request->fence.flags));
- active = request;
+ pending = request;
break;
}
spin_unlock_irqrestore(&engine->timeline->lock, flags);
- return active;
+ return pending;
+}
+
+struct drm_i915_gem_request *
+i915_gem_find_active_request(struct intel_engine_cs *engine)
+{
+ struct intel_engine_execlists * const execlists = &engine->execlists;
+ struct drm_i915_gem_request *request;
+
+ /* The pending request is active if no preemption is in progress */
+ if (!execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT))
+ return i915_gem_find_pending_request(engine);
+
+ /* Preemption has finished. Engine idle. */
+ if (intel_engine_preempt_finished(engine))
+ return NULL;
+
+ request = i915_gem_find_pending_request(engine);
+
+ /* Preemption has flushed all requests off the engine. Engine idle. */
+ if (!request)
+ return NULL;
+
+ /* The pending request likely is active and blocking the in-progress
+ * preemption. But there is a race in our previous checks. The request
+ * that was actually blocking preemption could have completed (a batch-
+ * boundary preemption) such that the engine is idle and the pending
+ * request we have identified was the next in line. We must wait for
+ * at least as long as it would take for the preempt-to-idle context
+ * to mark the preemption done to verify this. We use 500 usecs to
+ * account for a worst case delay from the seqno write of the
+ * completing request and the preempt finished write.
+ */
+ if (!_wait_for_exact(intel_engine_preempt_finished(engine), 500, 10, 50))
+ return NULL;
+
+ /*
+ * We didn't see the preemption done after a sufficient wait. Thus the
+ * pending request we sampled above was in fact active and blocking
+ * the preemption.
+ */
+ return request;
}
static bool engine_stalled(struct intel_engine_cs *engine)
--
2.16.2
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-03-16 18:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-16 18:30 [RFC 0/8] Force preemption jeff.mcgee
2018-03-16 18:30 ` [RFC 1/8] drm/i915: Downgrade tasklet GEM_BUG_ON for request not completed jeff.mcgee
2018-03-16 20:30 ` Chris Wilson
2018-03-16 18:30 ` [RFC 2/8] drm/i915: Skip CSB processing on invalid CSB tail jeff.mcgee
2018-03-16 20:30 ` Chris Wilson
2018-03-16 18:31 ` [RFC 3/8] drm/i915: Execlists to mark the HWSP upon preemption finished jeff.mcgee
2018-03-16 18:31 ` [RFC 4/8] drm/i915: Add a wait_for routine with more exact timeout jeff.mcgee
2018-03-16 18:31 ` jeff.mcgee [this message]
2018-03-16 18:31 ` [RFC 6/8] drm/i915: Repair the preemption context if hit by reset jeff.mcgee
2018-03-16 18:31 ` [RFC 7/8] drm/i915: Allow reset without error capture jeff.mcgee
2018-03-16 20:33 ` Chris Wilson
2018-03-16 18:31 ` [RFC 8/8] drm/i915: Force preemption to complete via engine reset jeff.mcgee
2018-03-16 20:39 ` Chris Wilson
2018-03-16 20:44 ` Chris Wilson
2018-03-16 18:59 ` ✗ Fi.CI.BAT: failure for Force preemption Patchwork
2018-03-16 20:53 ` [RFC 0/8] " Chris Wilson
2018-03-16 21:03 ` Chris Wilson
2018-03-16 23:04 ` [PATCH] force-preempt-reset Chris Wilson
2018-03-16 23:45 ` ✗ Fi.CI.BAT: failure for force-preempt-reset Patchwork
2018-03-16 22:34 ` [RFC 0/8] Force preemption Chris Wilson
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=20180316183105.16027-6-jeff.mcgee@intel.com \
--to=jeff.mcgee@intel.com \
--cc=ben@bwidawsk.net \
--cc=intel-gfx@lists.freedesktop.org \
--cc=kalyan.kondapally@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox