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
next prev parent 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