public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
To: Matthew Brost <matthew.brost@intel.com>,
	intel-gfx@lists.freedesktop.org,
	 dri-devel@lists.freedesktop.org
Cc: jason.ekstrand@intel.com
Subject: Re: [Intel-gfx] [PATCH 6/8] drm/i915: Add kick_backend function to i915_sched_engine
Date: Mon, 14 Jun 2021 16:44:26 -0700	[thread overview]
Message-ID: <6e19f52e-372d-af5c-1035-fd149246e909@intel.com> (raw)
In-Reply-To: <20210608191754.127059-7-matthew.brost@intel.com>



On 6/8/2021 12:17 PM, Matthew Brost wrote:
> Rather than touching execlist specific structures in the generic
> scheduling code, add a callback function in the backend.

I think this could do with a better wording to explain the reasoning 
more, something like: "Not all back-ends require a kick after a 
scheduling update, so make the kick a call-back function that the 
back-end can opt-in to. Also move the current kick function from the 
scheduler to the execlists file as it is specific to that back-end". 
With something like that:

Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>

Daniele


>
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> ---
>   .../drm/i915/gt/intel_execlists_submission.c  | 52 ++++++++++++++++
>   drivers/gpu/drm/i915/i915_scheduler.c         | 62 +------------------
>   drivers/gpu/drm/i915/i915_scheduler_types.h   |  6 ++
>   3 files changed, 60 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index 8a3d4014fd2c..9487d9e0be62 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -3116,10 +3116,61 @@ static bool can_preempt(struct intel_engine_cs *engine)
>   	return engine->class != RENDER_CLASS;
>   }
>   
> +static void kick_execlists(const struct i915_request *rq, int prio)
> +{
> +	struct intel_engine_cs *engine = rq->engine;
> +	struct i915_sched_engine *sched_engine = engine->sched_engine;
> +	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 <= sched_engine->queue_priority_hint)
> +		return;
> +
> +	rcu_read_lock();
> +
> +	/* Nothing currently active? We're overdue for a submission! */
> +	inflight = execlists_active(&engine->execlists);
> +	if (!inflight)
> +		goto unlock;
> +
> +	/*
> +	 * If we are already the currently executing context, don't
> +	 * bother evaluating if we should preempt ourselves.
> +	 */
> +	if (inflight->context == rq->context)
> +		goto unlock;
> +
> +	ENGINE_TRACE(engine,
> +		     "bumping queue-priority-hint:%d for rq:%llx:%lld, inflight:%llx:%lld prio %d\n",
> +		     prio,
> +		     rq->fence.context, rq->fence.seqno,
> +		     inflight->fence.context, inflight->fence.seqno,
> +		     inflight->sched.attr.priority);
> +
> +	sched_engine->queue_priority_hint = prio;
> +
> +	/*
> +	 * Allow preemption of low -> normal -> high, but we do
> +	 * not allow low priority tasks to preempt other low priority
> +	 * tasks under the impression that latency for low priority
> +	 * tasks does not matter (as much as background throughput),
> +	 * so kiss.
> +	 */
> +	if (prio >= max(I915_PRIORITY_NORMAL, rq_prio(inflight)))
> +		tasklet_hi_schedule(&engine->execlists.tasklet);
> +
> +unlock:
> +	rcu_read_unlock();
> +}
> +
>   static void execlists_set_default_submission(struct intel_engine_cs *engine)
>   {
>   	engine->submit_request = execlists_submit_request;
>   	engine->sched_engine->schedule = i915_schedule;
> +	engine->sched_engine->kick_backend = kick_execlists;
>   	engine->execlists.tasklet.callback = execlists_submission_tasklet;
>   }
>   
> @@ -3702,6 +3753,7 @@ intel_execlists_create_virtual(struct intel_engine_cs **siblings,
>   	ve->base.request_alloc = execlists_request_alloc;
>   
>   	ve->base.sched_engine->schedule = i915_schedule;
> +	ve->base.sched_engine->kick_backend = kick_execlists;
>   	ve->base.submit_request = virtual_submit_request;
>   	ve->base.bond_execute = virtual_bond_execute;
>   
> diff --git a/drivers/gpu/drm/i915/i915_scheduler.c b/drivers/gpu/drm/i915/i915_scheduler.c
> index 4bc6969f6a97..035b88f2e4aa 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler.c
> +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> @@ -157,65 +157,6 @@ sched_lock_engine(const struct i915_sched_node *node,
>   	return locked;
>   }
>   
> -static inline int rq_prio(const struct i915_request *rq)
> -{
> -	return rq->sched.attr.priority;
> -}
> -
> -static inline bool need_preempt(int prio, int active)
> -{
> -	/*
> -	 * Allow preemption of low -> normal -> high, but we do
> -	 * not allow low priority tasks to preempt other low priority
> -	 * tasks under the impression that latency for low priority
> -	 * tasks does not matter (as much as background throughput),
> -	 * so kiss.
> -	 */
> -	return prio >= max(I915_PRIORITY_NORMAL, active);
> -}
> -
> -static void kick_submission(struct intel_engine_cs *engine,
> -			    const struct i915_request *rq,
> -			    int prio)
> -{
> -	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->sched_engine->queue_priority_hint)
> -		return;
> -
> -	rcu_read_lock();
> -
> -	/* Nothing currently active? We're overdue for a submission! */
> -	inflight = execlists_active(&engine->execlists);
> -	if (!inflight)
> -		goto unlock;
> -
> -	/*
> -	 * If we are already the currently executing context, don't
> -	 * bother evaluating if we should preempt ourselves.
> -	 */
> -	if (inflight->context == rq->context)
> -		goto unlock;
> -
> -	ENGINE_TRACE(engine,
> -		     "bumping queue-priority-hint:%d for rq:%llx:%lld, inflight:%llx:%lld prio %d\n",
> -		     prio,
> -		     rq->fence.context, rq->fence.seqno,
> -		     inflight->fence.context, inflight->fence.seqno,
> -		     inflight->sched.attr.priority);
> -
> -	engine->sched_engine->queue_priority_hint = prio;
> -	if (need_preempt(prio, rq_prio(inflight)))
> -		tasklet_hi_schedule(&engine->execlists.tasklet);
> -
> -unlock:
> -	rcu_read_unlock();
> -}
> -
>   static void __i915_schedule(struct i915_sched_node *node,
>   			    const struct i915_sched_attr *attr)
>   {
> @@ -335,7 +276,8 @@ static void __i915_schedule(struct i915_sched_node *node,
>   		}
>   
>   		/* Defer (tasklet) submission until after all of our updates. */
> -		kick_submission(engine, node_to_request(node), prio);
> +		if (engine->sched_engine->kick_backend)
> +			engine->sched_engine->kick_backend(node_to_request(node), prio);
>   	}
>   
>   	spin_unlock(&engine->sched_engine->lock);
> diff --git a/drivers/gpu/drm/i915/i915_scheduler_types.h b/drivers/gpu/drm/i915/i915_scheduler_types.h
> index 0c1e417b0164..8bd07d0c27e1 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler_types.h
> +++ b/drivers/gpu/drm/i915/i915_scheduler_types.h
> @@ -153,6 +153,12 @@ struct i915_sched_engine {
>   	 */
>   	bool no_priolist;
>   
> +	/**
> +	 * @kick_backend: kick backend after a request's priority has changed
> +	 */
> +	void	(*kick_backend)(const struct i915_request *rq,
> +				int prio);
> +
>   	/**
>   	 * @schedule: adjust priority of request
>   	 *

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

  reply	other threads:[~2021-06-14 23:44 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-08 19:17 [Intel-gfx] [PATCH 0/8] Introduce i915_sched_engine object Matthew Brost
2021-06-08 19:17 ` [Intel-gfx] [PATCH 1/8] drm/i915: Move priolist to new " Matthew Brost
2021-06-14 22:53   ` Daniele Ceraolo Spurio
2021-06-08 19:17 ` [Intel-gfx] [PATCH 2/8] drm/i915: Add i915_sched_engine_is_empty function Matthew Brost
2021-06-08 19:17 ` [Intel-gfx] [PATCH 3/8] drm/i915: Reset sched_engine.no_priolist immediately after dequeue Matthew Brost
2021-06-08 19:17 ` [Intel-gfx] [PATCH 4/8] drm/i915: Move active tracking to i915_sched_engine Matthew Brost
2021-06-14 23:29   ` Daniele Ceraolo Spurio
2021-06-08 19:17 ` [Intel-gfx] [PATCH 5/8] drm/i915: Move engine->schedule " Matthew Brost
2021-06-14 23:32   ` Daniele Ceraolo Spurio
2021-06-08 19:17 ` [Intel-gfx] [PATCH 6/8] drm/i915: Add kick_backend function " Matthew Brost
2021-06-14 23:44   ` Daniele Ceraolo Spurio [this message]
2021-06-08 19:17 ` [Intel-gfx] [PATCH 7/8] drm/i915: Update i915_scheduler to operate on i915_sched_engine Matthew Brost
2021-06-08 19:17 ` [Intel-gfx] [PATCH 8/8] drm/i915: Move submission tasklet to i915_sched_engine Matthew Brost
2021-06-15  1:05   ` Daniele Ceraolo Spurio
2021-06-15  3:34     ` Matthew Brost
2021-06-08 20:42 ` [Intel-gfx] ✓ Fi.CI.BAT: success for Introduce i915_sched_engine object (rev3) Patchwork
2021-06-08 20:42 ` [Intel-gfx] ✗ Fi.CI.BUILD: warning " Patchwork
2021-06-09  1:26 ` [Intel-gfx] ✓ Fi.CI.IGT: success " Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2021-06-15 20:58 [Intel-gfx] [PATCH 0/8] Introduce i915_sched_engine object Matthew Brost
2021-06-15 20:58 ` [Intel-gfx] [PATCH 6/8] drm/i915: Add kick_backend function to i915_sched_engine Matthew Brost
2021-06-15 22:43 [Intel-gfx] [PATCH 0/8] Introduce i915_sched_engine object Matthew Brost
2021-06-15 22:43 ` [Intel-gfx] [PATCH 6/8] drm/i915: Add kick_backend function to i915_sched_engine Matthew Brost
2021-06-18  1:06 [Intel-gfx] [PATCH 0/8] Introduce i915_sched_engine object Matthew Brost
2021-06-18  1:06 ` [Intel-gfx] [PATCH 6/8] drm/i915: Add kick_backend function to i915_sched_engine Matthew Brost

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=6e19f52e-372d-af5c-1035-fd149246e909@intel.com \
    --to=daniele.ceraolospurio@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jason.ekstrand@intel.com \
    --cc=matthew.brost@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