All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 01/16] drm/i915: Don't set queue_priority_hint if we don't kick the submission
Date: Mon, 21 Oct 2019 12:49:14 +0300	[thread overview]
Message-ID: <87pniq8m3p.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <20191021080226.537-1-chris@chris-wilson.co.uk>

Chris Wilson <chris@chris-wilson.co.uk> writes:

> If we change the priority of the active context, then it has no impact
> on the decision of whether to preempt the active context -- we don't
> preempt the context with itself. In this situation, we elide the tasklet
> rescheduling and should *not* be marking up the queue_priority_hint as
> that may mask a later submission where we decide we don't have to kick
> the tasklet as a higher priority submission is pending (spoiler alert,
> it was not).
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/i915_scheduler.c | 37 ++++++++++++++++-----------
>  1 file changed, 22 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_scheduler.c b/drivers/gpu/drm/i915/i915_scheduler.c
> index 0ca40f6bf08c..d2edb527dcb8 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler.c
> +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> @@ -189,22 +189,34 @@ static inline bool need_preempt(int prio, int active)
>  	return prio >= max(I915_PRIORITY_NORMAL, active);
>  }
>  
> -static void kick_submission(struct intel_engine_cs *engine, int prio)
> +static void kick_submission(struct intel_engine_cs *engine,
> +			    const struct i915_request *rq,
> +			    int prio)
>  {
> -	const struct i915_request *inflight =
> -		execlists_active(&engine->execlists);
> +	const struct i915_request *inflight;
> +
> +	/*
> +	 * We only need to kick the tasklet once for the high priority
> +	 * new context we add into the queue.
> +	 */
> +	if (prio <= engine->execlists.queue_priority_hint)
> +		return;
> +
> +	/* Nothing currently active? We're overdue for a submission! */
> +	inflight = execlists_active(&engine->execlists);
> +	if (!inflight)
> +		return;
>  
>  	/*
>  	 * If we are already the currently executing context, don't
> -	 * bother evaluating if we should preempt ourselves, or if
> -	 * we expect nothing to change as a result of running the
> -	 * tasklet, i.e. we have not change the priority queue
> -	 * sufficiently to oust the running context.
> +	 * bother evaluating if we should preempt ourselves.
>  	 */
> -	if (!inflight || !need_preempt(prio, rq_prio(inflight)))
> +	if (inflight->hw_context == rq->hw_context)

If there is a tail update at this moment, does the hardware
take it into account or do we need to kick?

-Mika


>  		return;
>  
> -	tasklet_hi_schedule(&engine->execlists.tasklet);
> +	engine->execlists.queue_priority_hint = prio;
> +	if (need_preempt(prio, rq_prio(inflight)))
> +		tasklet_hi_schedule(&engine->execlists.tasklet);
>  }
>  
>  static void __i915_schedule(struct i915_sched_node *node,
> @@ -330,13 +342,8 @@ static void __i915_schedule(struct i915_sched_node *node,
>  			list_move_tail(&node->link, cache.priolist);
>  		}
>  
> -		if (prio <= engine->execlists.queue_priority_hint)
> -			continue;
> -
> -		engine->execlists.queue_priority_hint = prio;
> -
>  		/* Defer (tasklet) submission until after all of our updates. */
> -		kick_submission(engine, prio);
> +		kick_submission(engine, node_to_request(node), prio);
>  	}
>  
>  	spin_unlock(&engine->active.lock);
> -- 
> 2.24.0.rc0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2019-10-21  9:50 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-21  8:02 [PATCH 01/16] drm/i915: Don't set queue_priority_hint if we don't kick the submission Chris Wilson
2019-10-21  8:02 ` [PATCH 02/16] drm/i915: Drop assertion that ce->pin_mutex guards state updates Chris Wilson
2019-10-22 12:25   ` Mika Kuoppala
2019-10-21  8:02 ` [PATCH 03/16] drm/i915/selftests: Add coverage of mocs registers Chris Wilson
2019-10-21  8:02 ` [PATCH 04/16] drm/i915/selftests: Teach igt_flush_test and igt_live_test to take intel_gt Chris Wilson
2019-10-21  8:02 ` [PATCH 05/16] drm/i915/selftests: Force ordering of context switches Chris Wilson
2019-10-21  8:02 ` [PATCH 06/16] drm/i915: Expose engine properties via sysfs Chris Wilson
2019-10-21  8:02 ` [PATCH 07/16] drm/i915: Expose engine->mmio_base " Chris Wilson
2019-10-21  8:02 ` [PATCH 08/16] drm/i915: Expose timeslice duration to sysfs Chris Wilson
2019-10-21  8:02 ` [PATCH 09/16] drm/i915/execlists: Force preemption Chris Wilson
2019-10-21  8:02 ` [PATCH 10/16] drm/i915/gt: Introduce barrier pulses along engines Chris Wilson
2019-10-21  8:02 ` [PATCH 11/16] drm/i915/execlists: Cancel banned contexts on schedule-out Chris Wilson
2019-10-21  8:02 ` [PATCH 12/16] drm/i915/gem: Cancel contexts when hangchecking is disabled Chris Wilson
2019-10-21  8:02 ` [PATCH 13/16] drm/i915: Replace hangcheck by heartbeats Chris Wilson
2019-10-21  8:02 ` [PATCH 14/16] drm/i915/gem: Make context persistence optional Chris Wilson
2019-10-21  8:02 ` [PATCH 15/16] drm/i915/gem: Distinguish each object type Chris Wilson
2019-10-22 14:30   ` Matthew Auld
2019-11-04 17:51     ` Daniel Vetter
2019-11-04 17:51       ` [Intel-gfx] " Daniel Vetter
2019-10-21  8:02 ` [PATCH 16/16] drm/i915: Flush idle barriers when waiting Chris Wilson
2019-10-21  8:54 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/16] drm/i915: Don't set queue_priority_hint if we don't kick the submission Patchwork
2019-10-21  9:01 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-10-21  9:18 ` ✗ Fi.CI.BAT: failure " Patchwork
2019-10-21  9:49 ` Mika Kuoppala [this message]
2019-10-21  9:56   ` [PATCH 01/16] " Chris Wilson
2019-10-21 10:01     ` Mika Kuoppala

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=87pniq8m3p.fsf@gaia.fi.intel.com \
    --to=mika.kuoppala@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.