All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2 10/15] drm/i915: Remove the preempted request from the execution queue
Date: Wed, 22 Feb 2017 13:33:22 +0000	[thread overview]
Message-ID: <ea75554f-5e47-85cd-36af-97c913c422fc@linux.intel.com> (raw)
In-Reply-To: <20170222114610.5819-11-chris@chris-wilson.co.uk>


On 22/02/2017 11:46, Chris Wilson wrote:
> After the request is cancelled, we then need to remove it from the
> global execution timeline and return it to the context timeline, the
> inverse of submit_request().
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>  drivers/gpu/drm/i915/i915_gem_request.c            | 58 +++++++++++++++++++++-
>  drivers/gpu/drm/i915/i915_gem_request.h            |  3 ++
>  drivers/gpu/drm/i915/intel_breadcrumbs.c           | 19 ++++++-
>  drivers/gpu/drm/i915/intel_ringbuffer.h            |  6 ---
>  drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c |  6 +++
>  5 files changed, 83 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c b/drivers/gpu/drm/i915/i915_gem_request.c
> index d18f450977e0..97116e492d01 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -441,6 +441,55 @@ void i915_gem_request_submit(struct drm_i915_gem_request *request)
>  	spin_unlock_irqrestore(&engine->timeline->lock, flags);
>  }
>
> +void __i915_gem_request_unsubmit(struct drm_i915_gem_request *request)
> +{
> +	struct intel_engine_cs *engine = request->engine;
> +	struct intel_timeline *timeline;
> +
> +	assert_spin_locked(&engine->timeline->lock);
> +
> +	/* Only unwind in reverse order, required so that the per-context list
> +	 * is kept in seqno/ring order.
> +	 */
> +	GEM_BUG_ON(request->global_seqno != engine->timeline->seqno);
> +	engine->timeline->seqno--;
> +
> +	/* We may be recursing from the signal callback of another i915 fence */

Copy-paste of the comment of there will really be preemption triggered 
from the signal callback?

> +	spin_lock_nested(&request->lock, SINGLE_DEPTH_NESTING);
> +	request->global_seqno = 0;
> +	if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &request->fence.flags))
> +		intel_engine_cancel_signaling(request);
> +	spin_unlock(&request->lock);
> +
> +	/* Transfer back from the global per-engine timeline to per-context */
> +	timeline = request->timeline;
> +	GEM_BUG_ON(timeline == engine->timeline);
> +
> +	spin_lock(&timeline->lock);
> +	list_move(&request->link, &timeline->requests);
> +	spin_unlock(&timeline->lock);
> +
> +	/* We don't need to wake_up any waiters on request->execute, they
> +	 * will get woken by any other event or us re-adding this request
> +	 * to the engine timeline (__i915_gem_request_submit()). The waiters
> +	 * should be quite adapt at finding that the request now has a new
> +	 * global_seqno to the one they went to sleep on.
> +	 */
> +}
> +
> +void i915_gem_request_unsubmit(struct drm_i915_gem_request *request)
> +{
> +	struct intel_engine_cs *engine = request->engine;
> +	unsigned long flags;
> +
> +	/* Will be called from irq-context when using foreign fences. */
> +	spin_lock_irqsave(&engine->timeline->lock, flags);
> +
> +	__i915_gem_request_unsubmit(request);
> +
> +	spin_unlock_irqrestore(&engine->timeline->lock, flags);
> +}
> +
>  static int __i915_sw_fence_call
>  submit_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state)
>  {
> @@ -1034,9 +1083,11 @@ long i915_wait_request(struct drm_i915_gem_request *req,
>  	if (flags & I915_WAIT_LOCKED)
>  		add_wait_queue(errq, &reset);
>
> -	intel_wait_init(&wait, i915_gem_request_global_seqno(req));
> +	wait.tsk = current;
>
> +restart:
>  	reset_wait_queue(&req->execute, &exec);
> +	wait.seqno = i915_gem_request_global_seqno(req);

Not sure if it is worth dropping intel_wait_init, I presume to avoid 
assigning the task twice? It will still be the same task so just moving 
the intel_wait_init here would be clearer.

>  	if (!wait.seqno) {
>  		do {
>  			set_current_state(state);
> @@ -1135,6 +1186,11 @@ long i915_wait_request(struct drm_i915_gem_request *req,
>  		/* Only spin if we know the GPU is processing this request */
>  		if (i915_spin_request(req, state, 2))
>  			break;
> +
> +		if (i915_gem_request_global_seqno(req) != wait.seqno) {
> +			intel_engine_remove_wait(req->engine, &wait);
> +			goto restart;
> +		}
>  	}
>
>  	intel_engine_remove_wait(req->engine, &wait);
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.h b/drivers/gpu/drm/i915/i915_gem_request.h
> index b81f6709905c..5f73d8c0a38a 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.h
> +++ b/drivers/gpu/drm/i915/i915_gem_request.h
> @@ -274,6 +274,9 @@ void __i915_add_request(struct drm_i915_gem_request *req, bool flush_caches);
>  void __i915_gem_request_submit(struct drm_i915_gem_request *request);
>  void i915_gem_request_submit(struct drm_i915_gem_request *request);
>
> +void __i915_gem_request_unsubmit(struct drm_i915_gem_request *request);
> +void i915_gem_request_unsubmit(struct drm_i915_gem_request *request);
> +
>  struct intel_rps_client;
>  #define NO_WAITBOOST ERR_PTR(-1)
>  #define IS_RPS_CLIENT(p) (!IS_ERR(p))
> diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> index 882e601ebb09..5bcad7872c08 100644
> --- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
> +++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> @@ -453,7 +453,14 @@ void intel_engine_remove_wait(struct intel_engine_cs *engine,
>  	spin_unlock_irq(&b->lock);
>  }
>
> -static bool signal_complete(struct drm_i915_gem_request *request)
> +static bool signal_valid(const struct drm_i915_gem_request *request)
> +{
> +	u32 seqno = READ_ONCE(request->global_seqno);
> +
> +	return seqno == request->signaling.wait.seqno;
> +}
> +
> +static bool signal_complete(const struct drm_i915_gem_request *request)
>  {
>  	if (!request)
>  		return false;
> @@ -462,7 +469,7 @@ static bool signal_complete(struct drm_i915_gem_request *request)
>  	 * signalled that this wait is already completed.
>  	 */
>  	if (intel_wait_complete(&request->signaling.wait))
> -		return true;
> +		return signal_valid(request);
>
>  	/* Carefully check if the request is complete, giving time for the
>  	 * seqno to be visible or if the GPU hung.
> @@ -542,13 +549,21 @@ static int intel_breadcrumbs_signaler(void *arg)
>
>  			i915_gem_request_put(request);
>  		} else {
> +			DEFINE_WAIT(exec);
> +
>  			if (kthread_should_stop()) {
>  				GEM_BUG_ON(request);
>  				break;
>  			}
>
> +			if (request)
> +				add_wait_queue(&request->execute, &exec);
> +
>  			schedule();
>
> +			if (request)
> +				remove_wait_queue(&request->execute, &exec);
> +

Not directly related but made me think why we are using 
TASK_INTERRUPTIBLE in the signallers? Shouldn't it be 
TASK_UNINTERRUPTIBLE and io_schedule? Sounds a bit deja vu though, maybe 
we have talked about it before..

>  			if (kthread_should_park())
>  				kthread_parkme();
>  		}
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index 45d2c2fa946e..97fde79167a6 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -582,12 +582,6 @@ static inline u32 intel_hws_seqno_address(struct intel_engine_cs *engine)
>  /* intel_breadcrumbs.c -- user interrupt bottom-half for waiters */
>  int intel_engine_init_breadcrumbs(struct intel_engine_cs *engine);
>
> -static inline void intel_wait_init(struct intel_wait *wait, u32 seqno)
> -{
> -	wait->tsk = current;
> -	wait->seqno = seqno;
> -}
> -
>  static inline bool intel_wait_complete(const struct intel_wait *wait)
>  {
>  	return RB_EMPTY_NODE(&wait->node);
> diff --git a/drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c b/drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c
> index 6426acc9fdca..62c020c7ea80 100644
> --- a/drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c
> +++ b/drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c
> @@ -28,6 +28,12 @@
>  #include "mock_gem_device.h"
>  #include "mock_engine.h"
>
> +static inline void intel_wait_init(struct intel_wait *wait, u32 seqno)
> +{
> +	wait->tsk = current;
> +	wait->seqno = seqno;
> +}
> +
>  static int check_rbtree(struct intel_engine_cs *engine,
>  			const unsigned long *bitmap,
>  			const struct intel_wait *waiters,
>

Regards,

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

  reply	other threads:[~2017-02-22 13:33 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-22 11:45 Pre-emption pre-enablement Chris Wilson
2017-02-22 11:45 ` [PATCH v2 01/15] drm/i915: Keep a global seqno per-engine Chris Wilson
2017-02-22 12:24   ` Tvrtko Ursulin
2017-02-22 11:45 ` [PATCH v2 02/15] drm/i915: Move reeerve_seqno() next to unreserve_seqno() Chris Wilson
2017-02-22 12:23   ` Joonas Lahtinen
2017-02-22 11:45 ` [PATCH v2 03/15] drm/i915: Use a local to shorten req->i915->gpu_error.wait_queue Chris Wilson
2017-02-22 11:45 ` [PATCH v2 04/15] drm/i915: Add ourselves to the gpu error waitqueue for the entire wait Chris Wilson
2017-02-22 11:46 ` [PATCH v2 05/15] drm/i915: Inline __i915_gem_request_wait_for_execute() Chris Wilson
2017-02-22 11:46 ` [PATCH v2 06/15] drm/i915: Deconstruct execute fence Chris Wilson
2017-02-22 11:46 ` [PATCH v2 07/15] drm/i915: Protect the request->global_seqno with the engine->timeline lock Chris Wilson
2017-02-22 12:29   ` Tvrtko Ursulin
2017-02-22 12:45     ` Chris Wilson
2017-02-22 13:13       ` Tvrtko Ursulin
2017-02-22 11:46 ` [PATCH v2 08/15] drm/i915: Take a reference whilst processing the signaler request Chris Wilson
2017-02-22 12:35   ` Tvrtko Ursulin
2017-02-22 11:46 ` [PATCH v2 09/15] drm/i915: Allow an request to be cancelled Chris Wilson
2017-02-22 13:08   ` Tvrtko Ursulin
2017-02-22 11:46 ` [PATCH v2 10/15] drm/i915: Remove the preempted request from the execution queue Chris Wilson
2017-02-22 13:33   ` Tvrtko Ursulin [this message]
2017-02-22 13:40     ` Chris Wilson
2017-02-22 13:50       ` Tvrtko Ursulin
2017-02-22 18:53     ` [PATCH v3] " Chris Wilson
2017-02-22 11:46 ` [PATCH v2 11/15] drm/i915: Exercise request cancellation using a mock selftest Chris Wilson
2017-02-22 13:46   ` Tvrtko Ursulin
2017-02-22 13:59     ` Chris Wilson
2017-02-22 14:03       ` Chris Wilson
2017-02-22 14:05       ` Tvrtko Ursulin
2017-02-22 11:46 ` [PATCH v2 12/15] drm/i915: Replace reset_wait_queue with default_wake_function Chris Wilson
2017-02-22 14:13   ` Tvrtko Ursulin
2017-02-22 11:46 ` [PATCH v2 13/15] drm/i915: Refactor direct GPU reset from request waiters Chris Wilson
2017-02-22 14:16   ` Tvrtko Ursulin
2017-02-22 14:26     ` Chris Wilson
2017-02-22 15:07       ` Tvrtko Ursulin
2017-02-22 11:46 ` [PATCH v2 14/15] drm/i915: Immediately process a reset before starting waiting Chris Wilson
2017-02-22 11:46 ` [PATCH v2 15/15] drm/i915: Remove one level of indention from wait-for-execute Chris Wilson
2017-02-22 14:22   ` Tvrtko Ursulin
2017-02-22 13:22 ` ✗ Fi.CI.BAT: failure for series starting with [v2,01/15] drm/i915: Keep a global seqno per-engine Patchwork
2017-02-22 20:52 ` ✗ Fi.CI.BAT: warning for series starting with [v2,01/15] drm/i915: Keep a global seqno per-engine (rev2) Patchwork
2017-02-22 20:56   ` 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=ea75554f-5e47-85cd-36af-97c913c422fc@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=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.