intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Jeff McGee <jeff.mcgee@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 4/5] drm/i915: Split execlists/guc reset prepartions
Date: Thu, 22 Mar 2018 08:28:47 -0700	[thread overview]
Message-ID: <20180322152847.GK19343@jeffdesk> (raw)
In-Reply-To: <20180320001848.4405-4-chris@chris-wilson.co.uk>

On Tue, Mar 20, 2018 at 12:18:47AM +0000, Chris Wilson wrote:
> In the next patch, we will make the execlists reset prepare callback
> take into account preemption by flushing the context-switch handler.
> This is not applicable to the GuC submission backend, so split the two
> into their own backend callbacks.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Michał Winiarski <michal.winiarski@intel.com>
> CC: Michel Thierry <michel.thierry@intel.com>
> Cc: Jeff McGee <jeff.mcgee@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_guc_submission.c | 39 +++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/intel_lrc.c            | 11 +-------
>  2 files changed, 40 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c b/drivers/gpu/drm/i915/intel_guc_submission.c
> index 207cda062626..779c8d3156e5 100644
> --- a/drivers/gpu/drm/i915/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/intel_guc_submission.c
> @@ -776,6 +776,44 @@ static void guc_submission_tasklet(unsigned long data)
>  		guc_dequeue(engine);
>  }
>  
> +static struct i915_request *
> +guc_reset_prepare(struct intel_engine_cs *engine)
> +{
> +	struct intel_engine_execlists * const execlists = &engine->execlists;
> +
> +	/*
> +	 * Prevent request submission to the hardware until we have
> +	 * completed the reset in i915_gem_reset_finish(). If a request
> +	 * is completed by one engine, it may then queue a request
> +	 * to a second via its execlists->tasklet *just* as we are
> +	 * calling engine->init_hw() and also writing the ELSP.
> +	 * Turning off the execlists->tasklet until the reset is over
> +	 * prevents the race.
> +	 *
> +	 * Note that this needs to be a single atomic operation on the
> +	 * tasklet (flush existing tasks, prevent new tasks) to prevent
> +	 * a race between reset and set-wedged. It is not, so we do the best
> +	 * we can atm and make sure we don't lock the machine up in the more
> +	 * common case of recursively being called from set-wedged from inside
> +	 * i915_reset.
> +	 */
> +	if (!atomic_read(&execlists->tasklet.count))
> +		tasklet_kill(&execlists->tasklet);
> +	tasklet_disable(&execlists->tasklet);
> +
> +	/*
> +	 * We're using worker to queue preemption requests from the tasklet in
> +	 * GuC submission mode.
> +	 * Even though tasklet was disabled, we may still have a worker queued.
> +	 * Let's make sure that all workers scheduled before disabling the
> +	 * tasklet are completed before continuing with the reset.
> +	 */
> +	if (engine->i915->guc.preempt_wq)
> +		flush_workqueue(engine->i915->guc.preempt_wq);
> +
> +	return i915_gem_find_active_request(engine);
> +}
> +
>  /*
>   * Everything below here is concerned with setup & teardown, and is
>   * therefore not part of the somewhat time-critical batch-submission
> @@ -1235,6 +1273,7 @@ int intel_guc_submission_enable(struct intel_guc *guc)
>  			&engine->execlists;
>  
>  		execlists->tasklet.func = guc_submission_tasklet;
> +		engine->reset.prepare = guc_reset_prepare;
>  		engine->park = guc_submission_park;
>  		engine->unpark = guc_submission_unpark;
>  
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
> index f662a9524233..e5a3ffbc273a 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1688,16 +1688,6 @@ execlists_reset_prepare(struct intel_engine_cs *engine)
>  		tasklet_kill(&execlists->tasklet);
>  	tasklet_disable(&execlists->tasklet);
>  
> -	/*
> -	 * We're using worker to queue preemption requests from the tasklet in
> -	 * GuC submission mode.
> -	 * Even though tasklet was disabled, we may still have a worker queued.
> -	 * Let's make sure that all workers scheduled before disabling the
> -	 * tasklet are completed before continuing with the reset.
> -	 */
> -	if (engine->i915->guc.preempt_wq)
> -		flush_workqueue(engine->i915->guc.preempt_wq);
> -
>  	return i915_gem_find_active_request(engine);
>  }
>  
> @@ -2115,6 +2105,7 @@ static void execlists_set_default_submission(struct intel_engine_cs *engine)
>  	engine->cancel_requests = execlists_cancel_requests;
>  	engine->schedule = execlists_schedule;
>  	engine->execlists.tasklet.func = execlists_submission_tasklet;
> +	engine->reset.prepare = execlists_reset_prepare;
>  
>  	engine->park = NULL;
>  	engine->unpark = NULL;
> -- 
> 2.16.2
> 

Reviewed-by: Jeff McGee <jeff.mcgee@intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-03-22 15:43 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-20  0:18 [PATCH 1/5] drm/i915: Add control flags to i915_handle_error() Chris Wilson
2018-03-20  0:18 ` [PATCH 2/5] drm/i915/execlists: Refactor out complete_preempt_context() Chris Wilson
2018-03-22 15:26   ` Jeff McGee
2018-03-20  0:18 ` [PATCH 3/5] drm/i915: Move engine reset prepare/finish to backends Chris Wilson
2018-03-22 15:28   ` Jeff McGee
2018-03-20  0:18 ` [PATCH 4/5] drm/i915: Split execlists/guc reset prepartions Chris Wilson
2018-03-22 15:28   ` Jeff McGee [this message]
2018-03-20  0:18 ` [PATCH 5/5] drm/i915/execlists: Flush pending preemption events during reset Chris Wilson
2018-03-21  0:17   ` Jeff McGee
2018-03-22 15:14     ` Jeff McGee
2018-03-26 11:28       ` Chris Wilson
2018-03-20  0:39 ` [PATCH 1/5] drm/i915: Add control flags to i915_handle_error() Michel Thierry
2018-03-20  0:44   ` Chris Wilson
2018-03-20  0:56     ` Michel Thierry
2018-03-20  1:09       ` Chris Wilson
2018-03-20  1:24 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/5] " Patchwork
2018-03-20  1:25 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-03-20  1:41 ` ✓ Fi.CI.BAT: success " Patchwork
2018-03-20  6:45 ` ✗ Fi.CI.IGT: failure " Patchwork

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=20180322152847.GK19343@jeffdesk \
    --to=jeff.mcgee@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).