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
Cc: Dmitry Ermilov <dmitry.ermilov@intel.com>
Subject: Re: [PATCH 08/26] drm/i915: Make the semaphore saturation mask global
Date: Wed, 19 Jun 2019 11:45:47 +0100	[thread overview]
Message-ID: <bfb5ef57-187d-766e-b88c-c2a7d684f54d@linux.intel.com> (raw)
In-Reply-To: <20190618074153.16055-8-chris@chris-wilson.co.uk>


On 18/06/2019 08:41, Chris Wilson wrote:
> The idea behind keeping the saturation mask local to a context backfired
> spectacularly. The premise with the local mask was that we would be more
> proactive in attempting to use semaphores after each time the context
> idled, and that all new contexts would attempt to use semaphores
> ignoring the current state of the system. This turns out to be horribly
> optimistic. If the system state is still oversaturated and the existing
> workloads have all stopped using semaphores, the new workloads would
> attempt to use semaphores and be deprioritised behind real work. The
> new contexts would not switch off using semaphores until their initial
> batch of low priority work had completed. Given sufficient backload load
> of equal user priority, this would completely starve the new work of any
> GPU time.
> 
> To compensate, remove the local tracking in favour of keeping it as
> global state on the engine -- once the system is saturated and
> semaphores are disabled, everyone stops attempting to use semaphores
> until the system is idle again. One of the reason for preferring local
> context tracking was that it worked with virtual engines, so for
> switching to global state we could either do a complete check of all the
> virtual siblings or simply disable semaphores for those requests. This
> takes the simpler approach of disabling semaphores on virtual engines.
> 
> The downside is that the decision that the engine is saturated is a
> local measure -- we are only checking whether or not this context was
> scheduled in a timely fashion, it may be legitimately delayed due to user
> priorities. We still have the same dilemma though, that we do not want
> to employ the semaphore poll unless it will be used.
> 
> Fixes: ca6e56f654e7 ("drm/i915: Disable semaphore busywaits on saturated systems")
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
> Cc: Dmitry Ermilov <dmitry.ermilov@intel.com>
> ---
>   drivers/gpu/drm/i915/gt/intel_context.c       | 2 --
>   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           | 2 +-
>   drivers/gpu/drm/i915/i915_request.c           | 4 ++--
>   6 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.c b/drivers/gpu/drm/i915/gt/intel_context.c
> index 42f45744d859..2c454f227c2e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.c
> +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> @@ -142,7 +142,6 @@ intel_context_init(struct intel_context *ce,
>   	ce->engine = engine;
>   	ce->ops = engine->cops;
>   	ce->sseu = engine->sseu;
> -	ce->saturated = 0;
>   
>   	INIT_LIST_HEAD(&ce->signal_link);
>   	INIT_LIST_HEAD(&ce->signals);
> @@ -223,7 +222,6 @@ void intel_context_enter_engine(struct intel_context *ce)
>   
>   void intel_context_exit_engine(struct intel_context *ce)
>   {
> -	ce->saturated = 0;
>   	intel_engine_pm_put(ce->engine);
>   }
>   
> diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h b/drivers/gpu/drm/i915/gt/intel_context_types.h
> index b565c3ff4378..4c0e211c715d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> @@ -58,8 +58,6 @@ struct intel_context {
>   	atomic_t pin_count;
>   	struct mutex pin_mutex; /* guards pinning and associated on-gpuing */
>   
> -	intel_engine_mask_t saturated; /* submitting semaphores too late? */
> -
>   	/**
>   	 * active: Active tracker for the rq activity (inc. external) on this
>   	 * intel_context object.
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> index d14e352b0b17..2ce00d3dc42a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> @@ -100,6 +100,8 @@ 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 11a25f060fed..1cbe10a0fec7 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> @@ -258,6 +258,8 @@ struct intel_engine_cs {
>   	struct intel_context *kernel_context; /* pinned */
>   	struct intel_context *preempt_context; /* pinned; optional */
>   
> +	intel_engine_mask_t saturated; /* submitting semaphores too late? */
> +
>   	unsigned long serial;
>   
>   	unsigned long wakeref_serial;
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 0563fe8398c5..bbbdc63906c6 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -3198,7 +3198,6 @@ static void virtual_context_exit(struct intel_context *ce)
>   	struct virtual_engine *ve = container_of(ce, typeof(*ve), context);
>   	unsigned int n;
>   
> -	ce->saturated = 0;
>   	for (n = 0; n < ve->num_siblings; n++)
>   		intel_engine_pm_put(ve->siblings[n]);
>   }
> @@ -3397,6 +3396,7 @@ intel_execlists_create_virtual(struct i915_gem_context *ctx,
>   	ve->base.uabi_class = I915_ENGINE_CLASS_INVALID;
>   	ve->base.instance = I915_ENGINE_CLASS_INVALID_VIRTUAL;
>   	ve->base.flags = I915_ENGINE_IS_VIRTUAL;
> +	ve->base.saturated = ALL_ENGINES;

This could use a comment.

>   
>   	snprintf(ve->base.name, sizeof(ve->base.name), "virtual");
>   
> diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> index 98e4743b03be..27b9893fa8e3 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -418,7 +418,7 @@ void __i915_request_submit(struct i915_request *request)
>   	 */
>   	if (request->sched.semaphores &&
>   	    i915_sw_fence_signaled(&request->semaphore))
> -		request->hw_context->saturated |= request->sched.semaphores;
> +		engine->saturated |= request->sched.semaphores;
>   
>   	/* We may be recursing from the signal callback of another i915 fence */
>   	spin_lock_nested(&request->lock, SINGLE_DEPTH_NESTING);
> @@ -798,7 +798,7 @@ already_busywaiting(struct i915_request *rq)
>   	 *
>   	 * See the are-we-too-late? check in __i915_request_submit().
>   	 */
> -	return rq->sched.semaphores | rq->hw_context->saturated;
> +	return rq->sched.semaphores | rq->engine->saturated;
>   }
>   
>   static int
> 

Otherwise:

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

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

  reply	other threads:[~2019-06-19 10:45 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-18  7:41 [PATCH 01/26] drm/i915: Keep engine alive as we retire the context Chris Wilson
2019-06-18  7:41 ` [PATCH 02/26] drm/i915: Skip shrinking already freed pages Chris Wilson
2019-06-18 11:59   ` Chris Wilson
2019-06-18 16:06   ` Mika Kuoppala
2019-06-18 16:22     ` Chris Wilson
2019-06-18  7:41 ` [PATCH 03/26] drm/i915: Stop passing I915_WAIT_LOCKED to i915_request_wait() Chris Wilson
2019-06-19 11:44   ` Mika Kuoppala
2019-06-18  7:41 ` [PATCH 04/26] drm/i915: Flush the execution-callbacks on retiring Chris Wilson
2019-06-19 13:12   ` Mika Kuoppala
2019-06-19 13:18     ` Chris Wilson
2019-06-18  7:41 ` [PATCH 05/26] drm/i915/execlists: Preempt-to-busy Chris Wilson
2019-06-18  7:41 ` [PATCH 06/26] drm/i915/execlists: Minimalistic timeslicing Chris Wilson
2019-06-18  7:41 ` [PATCH 07/26] drm/i915/execlists: Force preemption Chris Wilson
2019-06-18  7:41 ` [PATCH 08/26] drm/i915: Make the semaphore saturation mask global Chris Wilson
2019-06-19 10:45   ` Tvrtko Ursulin [this message]
2019-06-18  7:41 ` [PATCH 09/26] dma-fence: Propagate errors to dma-fence-array container Chris Wilson
2019-06-18  7:41 ` [PATCH 10/26] dma-fence: Report the composite sync_file status Chris Wilson
2019-06-18  7:41 ` [PATCH 11/26] dma-fence: Refactor signaling for manual invocation Chris Wilson
2019-06-18  7:41 ` [PATCH 12/26] dma-fence: Always execute signal callbacks Chris Wilson
2019-06-18  7:41 ` [PATCH 13/26] drm/i915: Track i915_active using debugobjects Chris Wilson
2019-06-18  7:41 ` [PATCH 14/26] drm/i915: Signal fence completion from i915_request_wait Chris Wilson
2019-06-18  7:41 ` [PATCH 15/26] drm/i915: Remove waiting & retiring from shrinker paths Chris Wilson
2019-06-18  7:41 ` [PATCH 16/26] drm/i915: Throw away the active object retirement complexity Chris Wilson
2019-06-18  7:41 ` [PATCH 17/26] drm/i915: Provide an i915_active.acquire callback Chris Wilson
2019-06-18  7:41 ` [PATCH 18/26] drm/i915: Push the i915_active.retire into a worker Chris Wilson
2019-06-18  7:41 ` [PATCH 19/26] drm/i915/overlay: Switch to using i915_active tracking Chris Wilson
2019-06-18  7:41 ` [PATCH 20/26] drm/i915: Forgo last_fence active request tracking Chris Wilson
2019-06-18  7:41 ` [PATCH 21/26] drm/i915: Extract intel_frontbuffer active tracking Chris Wilson
2019-06-18  7:41 ` [PATCH 22/26] drm/i915: Coordinate i915_active with its own mutex Chris Wilson
2019-06-18  7:41 ` [PATCH 23/26] drm/i915: Rename intel_wakeref_[is]_active Chris Wilson
2019-06-18  8:14   ` Chris Wilson
2019-06-18  7:41 ` [PATCH 24/26] drm/i915: Teach execbuffer to take the engine wakeref not GT Chris Wilson
2019-06-18  7:41 ` [PATCH 25/26] drm/i915: Replace struct_mutex for batch pool serialisation Chris Wilson
2019-06-18  7:41 ` [PATCH 26/26] drm/i915: Move idle barrier cleanup into engine-pm Chris Wilson
2019-06-18  8:57 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/26] drm/i915: Keep engine alive as we retire the context Patchwork
2019-06-18  9:09 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-06-18  9:18 ` ✓ Fi.CI.BAT: success " Patchwork
2019-06-18 13:45 ` [PATCH 01/26] " Mika Kuoppala
2019-06-18 13:59   ` Chris Wilson
2019-06-18 14:03     ` Chris Wilson
2019-06-18 14:08     ` Mika Kuoppala
2019-06-18 19:15 ` ✗ Fi.CI.IGT: failure for series starting with [01/26] " 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=bfb5ef57-187d-766e-b88c-c2a7d684f54d@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=dmitry.ermilov@intel.com \
    --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.