2018-10-01 21:47:54 +07:00
|
|
|
/*
|
|
|
|
* SPDX-License-Identifier: MIT
|
|
|
|
*
|
|
|
|
* Copyright © 2018 Intel Corporation
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/mutex.h>
|
|
|
|
|
|
|
|
#include "i915_drv.h"
|
2019-03-06 04:38:30 +07:00
|
|
|
#include "i915_globals.h"
|
2018-10-01 21:47:54 +07:00
|
|
|
#include "i915_request.h"
|
|
|
|
#include "i915_scheduler.h"
|
|
|
|
|
2019-02-28 17:20:33 +07:00
|
|
|
static struct i915_global_scheduler {
|
2019-03-06 04:38:30 +07:00
|
|
|
struct i915_global base;
|
2019-02-28 17:20:33 +07:00
|
|
|
struct kmem_cache *slab_dependencies;
|
|
|
|
struct kmem_cache *slab_priorities;
|
|
|
|
} global;
|
|
|
|
|
2018-10-01 21:47:54 +07:00
|
|
|
static DEFINE_SPINLOCK(schedule_lock);
|
|
|
|
|
|
|
|
static const struct i915_request *
|
|
|
|
node_to_request(const struct i915_sched_node *node)
|
|
|
|
{
|
|
|
|
return container_of(node, const struct i915_request, sched);
|
|
|
|
}
|
|
|
|
|
2019-02-26 17:23:54 +07:00
|
|
|
static inline bool node_started(const struct i915_sched_node *node)
|
|
|
|
{
|
|
|
|
return i915_request_started(node_to_request(node));
|
|
|
|
}
|
|
|
|
|
2018-10-01 21:47:54 +07:00
|
|
|
static inline bool node_signaled(const struct i915_sched_node *node)
|
|
|
|
{
|
|
|
|
return i915_request_completed(node_to_request(node));
|
|
|
|
}
|
|
|
|
|
|
|
|
void i915_sched_node_init(struct i915_sched_node *node)
|
|
|
|
{
|
|
|
|
INIT_LIST_HEAD(&node->signalers_list);
|
|
|
|
INIT_LIST_HEAD(&node->waiters_list);
|
|
|
|
INIT_LIST_HEAD(&node->link);
|
|
|
|
node->attr.priority = I915_PRIORITY_INVALID;
|
2019-04-01 23:26:41 +07:00
|
|
|
node->semaphores = 0;
|
2019-03-02 00:09:01 +07:00
|
|
|
node->flags = 0;
|
2018-10-01 21:47:54 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct i915_dependency *
|
2019-02-28 17:20:33 +07:00
|
|
|
i915_dependency_alloc(void)
|
2018-10-01 21:47:54 +07:00
|
|
|
{
|
2019-02-28 17:20:33 +07:00
|
|
|
return kmem_cache_alloc(global.slab_dependencies, GFP_KERNEL);
|
2018-10-01 21:47:54 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2019-02-28 17:20:33 +07:00
|
|
|
i915_dependency_free(struct i915_dependency *dep)
|
2018-10-01 21:47:54 +07:00
|
|
|
{
|
2019-02-28 17:20:33 +07:00
|
|
|
kmem_cache_free(global.slab_dependencies, dep);
|
2018-10-01 21:47:54 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
bool __i915_sched_node_add_dependency(struct i915_sched_node *node,
|
|
|
|
struct i915_sched_node *signal,
|
|
|
|
struct i915_dependency *dep,
|
|
|
|
unsigned long flags)
|
|
|
|
{
|
|
|
|
bool ret = false;
|
|
|
|
|
drm/i915: Bump ready tasks ahead of busywaits
Consider two tasks that are running in parallel on a pair of engines
(vcs0, vcs1), but then must complete on a shared engine (rcs0). To
maximise throughput, we want to run the first ready task on rcs0 (i.e.
the first task that completes on either of vcs0 or vcs1). When using
semaphores, however, we will instead queue onto rcs in submission order.
To resolve this incorrect ordering, we want to re-evaluate the priority
queue when each of the request is ready. Normally this happens because
we only insert into the priority queue requests that are ready, but with
semaphores we are inserting ahead of their readiness and to compensate
we penalize those tasks with reduced priority (so that tasks that do not
need to busywait should naturally be run first). However, given a series
of tasks that each use semaphores, the queue degrades into submission
fifo rather than readiness fifo, and so to counter this we give a small
boost to semaphore users as their dependent tasks are completed (and so
we no longer require any busywait prior to running the user task as they
are then ready themselves).
v2: Fixup irqsave for schedule_lock (Tvrtko)
Testcase: igt/gem_exec_schedule/semaphore-codependency
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>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190409152922.23894-1-chris@chris-wilson.co.uk
2019-04-09 22:29:22 +07:00
|
|
|
spin_lock_irq(&schedule_lock);
|
2018-10-01 21:47:54 +07:00
|
|
|
|
|
|
|
if (!node_signaled(signal)) {
|
|
|
|
INIT_LIST_HEAD(&dep->dfs_link);
|
|
|
|
list_add(&dep->wait_link, &signal->waiters_list);
|
|
|
|
list_add(&dep->signal_link, &node->signalers_list);
|
|
|
|
dep->signaler = signal;
|
|
|
|
dep->flags = flags;
|
|
|
|
|
2019-03-02 00:09:01 +07:00
|
|
|
/* Keep track of whether anyone on this chain has a semaphore */
|
2019-04-01 23:26:41 +07:00
|
|
|
if (signal->flags & I915_SCHED_HAS_SEMAPHORE_CHAIN &&
|
2019-03-02 00:09:01 +07:00
|
|
|
!node_started(signal))
|
2019-04-01 23:26:41 +07:00
|
|
|
node->flags |= I915_SCHED_HAS_SEMAPHORE_CHAIN;
|
2019-03-02 00:09:01 +07:00
|
|
|
|
2018-10-01 21:47:54 +07:00
|
|
|
ret = true;
|
|
|
|
}
|
|
|
|
|
drm/i915: Bump ready tasks ahead of busywaits
Consider two tasks that are running in parallel on a pair of engines
(vcs0, vcs1), but then must complete on a shared engine (rcs0). To
maximise throughput, we want to run the first ready task on rcs0 (i.e.
the first task that completes on either of vcs0 or vcs1). When using
semaphores, however, we will instead queue onto rcs in submission order.
To resolve this incorrect ordering, we want to re-evaluate the priority
queue when each of the request is ready. Normally this happens because
we only insert into the priority queue requests that are ready, but with
semaphores we are inserting ahead of their readiness and to compensate
we penalize those tasks with reduced priority (so that tasks that do not
need to busywait should naturally be run first). However, given a series
of tasks that each use semaphores, the queue degrades into submission
fifo rather than readiness fifo, and so to counter this we give a small
boost to semaphore users as their dependent tasks are completed (and so
we no longer require any busywait prior to running the user task as they
are then ready themselves).
v2: Fixup irqsave for schedule_lock (Tvrtko)
Testcase: igt/gem_exec_schedule/semaphore-codependency
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>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190409152922.23894-1-chris@chris-wilson.co.uk
2019-04-09 22:29:22 +07:00
|
|
|
spin_unlock_irq(&schedule_lock);
|
2018-10-01 21:47:54 +07:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2019-02-28 17:20:33 +07:00
|
|
|
int i915_sched_node_add_dependency(struct i915_sched_node *node,
|
2018-10-01 21:47:54 +07:00
|
|
|
struct i915_sched_node *signal)
|
|
|
|
{
|
|
|
|
struct i915_dependency *dep;
|
|
|
|
|
2019-02-28 17:20:33 +07:00
|
|
|
dep = i915_dependency_alloc();
|
2018-10-01 21:47:54 +07:00
|
|
|
if (!dep)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
if (!__i915_sched_node_add_dependency(node, signal, dep,
|
|
|
|
I915_DEPENDENCY_ALLOC))
|
2019-02-28 17:20:33 +07:00
|
|
|
i915_dependency_free(dep);
|
2018-10-01 21:47:54 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-02-28 17:20:33 +07:00
|
|
|
void i915_sched_node_fini(struct i915_sched_node *node)
|
2018-10-01 21:47:54 +07:00
|
|
|
{
|
|
|
|
struct i915_dependency *dep, *tmp;
|
|
|
|
|
|
|
|
GEM_BUG_ON(!list_empty(&node->link));
|
|
|
|
|
drm/i915: Bump ready tasks ahead of busywaits
Consider two tasks that are running in parallel on a pair of engines
(vcs0, vcs1), but then must complete on a shared engine (rcs0). To
maximise throughput, we want to run the first ready task on rcs0 (i.e.
the first task that completes on either of vcs0 or vcs1). When using
semaphores, however, we will instead queue onto rcs in submission order.
To resolve this incorrect ordering, we want to re-evaluate the priority
queue when each of the request is ready. Normally this happens because
we only insert into the priority queue requests that are ready, but with
semaphores we are inserting ahead of their readiness and to compensate
we penalize those tasks with reduced priority (so that tasks that do not
need to busywait should naturally be run first). However, given a series
of tasks that each use semaphores, the queue degrades into submission
fifo rather than readiness fifo, and so to counter this we give a small
boost to semaphore users as their dependent tasks are completed (and so
we no longer require any busywait prior to running the user task as they
are then ready themselves).
v2: Fixup irqsave for schedule_lock (Tvrtko)
Testcase: igt/gem_exec_schedule/semaphore-codependency
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>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190409152922.23894-1-chris@chris-wilson.co.uk
2019-04-09 22:29:22 +07:00
|
|
|
spin_lock_irq(&schedule_lock);
|
2018-10-01 21:47:54 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Everyone we depended upon (the fences we wait to be signaled)
|
|
|
|
* should retire before us and remove themselves from our list.
|
|
|
|
* However, retirement is run independently on each timeline and
|
|
|
|
* so we may be called out-of-order.
|
|
|
|
*/
|
|
|
|
list_for_each_entry_safe(dep, tmp, &node->signalers_list, signal_link) {
|
|
|
|
GEM_BUG_ON(!node_signaled(dep->signaler));
|
|
|
|
GEM_BUG_ON(!list_empty(&dep->dfs_link));
|
|
|
|
|
|
|
|
list_del(&dep->wait_link);
|
|
|
|
if (dep->flags & I915_DEPENDENCY_ALLOC)
|
2019-02-28 17:20:33 +07:00
|
|
|
i915_dependency_free(dep);
|
2018-10-01 21:47:54 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Remove ourselves from everyone who depends upon us */
|
|
|
|
list_for_each_entry_safe(dep, tmp, &node->waiters_list, wait_link) {
|
|
|
|
GEM_BUG_ON(dep->signaler != node);
|
|
|
|
GEM_BUG_ON(!list_empty(&dep->dfs_link));
|
|
|
|
|
|
|
|
list_del(&dep->signal_link);
|
|
|
|
if (dep->flags & I915_DEPENDENCY_ALLOC)
|
2019-02-28 17:20:33 +07:00
|
|
|
i915_dependency_free(dep);
|
2018-10-01 21:47:54 +07:00
|
|
|
}
|
|
|
|
|
drm/i915: Bump ready tasks ahead of busywaits
Consider two tasks that are running in parallel on a pair of engines
(vcs0, vcs1), but then must complete on a shared engine (rcs0). To
maximise throughput, we want to run the first ready task on rcs0 (i.e.
the first task that completes on either of vcs0 or vcs1). When using
semaphores, however, we will instead queue onto rcs in submission order.
To resolve this incorrect ordering, we want to re-evaluate the priority
queue when each of the request is ready. Normally this happens because
we only insert into the priority queue requests that are ready, but with
semaphores we are inserting ahead of their readiness and to compensate
we penalize those tasks with reduced priority (so that tasks that do not
need to busywait should naturally be run first). However, given a series
of tasks that each use semaphores, the queue degrades into submission
fifo rather than readiness fifo, and so to counter this we give a small
boost to semaphore users as their dependent tasks are completed (and so
we no longer require any busywait prior to running the user task as they
are then ready themselves).
v2: Fixup irqsave for schedule_lock (Tvrtko)
Testcase: igt/gem_exec_schedule/semaphore-codependency
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>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190409152922.23894-1-chris@chris-wilson.co.uk
2019-04-09 22:29:22 +07:00
|
|
|
spin_unlock_irq(&schedule_lock);
|
2018-10-01 21:47:54 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct i915_priolist *to_priolist(struct rb_node *rb)
|
|
|
|
{
|
|
|
|
return rb_entry(rb, struct i915_priolist, node);
|
|
|
|
}
|
|
|
|
|
2019-01-30 01:54:51 +07:00
|
|
|
static void assert_priolists(struct intel_engine_execlists * const execlists)
|
2018-10-01 21:47:54 +07:00
|
|
|
{
|
|
|
|
struct rb_node *rb;
|
|
|
|
long last_prio, i;
|
|
|
|
|
|
|
|
if (!IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
|
|
|
|
return;
|
|
|
|
|
|
|
|
GEM_BUG_ON(rb_first_cached(&execlists->queue) !=
|
|
|
|
rb_first(&execlists->queue.rb_root));
|
|
|
|
|
2019-01-30 01:54:51 +07:00
|
|
|
last_prio = (INT_MAX >> I915_USER_PRIORITY_SHIFT) + 1;
|
2018-10-01 21:47:54 +07:00
|
|
|
for (rb = rb_first_cached(&execlists->queue); rb; rb = rb_next(rb)) {
|
|
|
|
const struct i915_priolist *p = to_priolist(rb);
|
|
|
|
|
|
|
|
GEM_BUG_ON(p->priority >= last_prio);
|
|
|
|
last_prio = p->priority;
|
|
|
|
|
|
|
|
GEM_BUG_ON(!p->used);
|
|
|
|
for (i = 0; i < ARRAY_SIZE(p->requests); i++) {
|
|
|
|
if (list_empty(&p->requests[i]))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
GEM_BUG_ON(!(p->used & BIT(i)));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
struct list_head *
|
|
|
|
i915_sched_lookup_priolist(struct intel_engine_cs *engine, int prio)
|
|
|
|
{
|
|
|
|
struct intel_engine_execlists * const execlists = &engine->execlists;
|
|
|
|
struct i915_priolist *p;
|
|
|
|
struct rb_node **parent, *rb;
|
|
|
|
bool first = true;
|
|
|
|
int idx, i;
|
|
|
|
|
|
|
|
lockdep_assert_held(&engine->timeline.lock);
|
2019-01-30 01:54:51 +07:00
|
|
|
assert_priolists(execlists);
|
2018-10-01 21:47:54 +07:00
|
|
|
|
|
|
|
/* buckets sorted from highest [in slot 0] to lowest priority */
|
|
|
|
idx = I915_PRIORITY_COUNT - (prio & I915_PRIORITY_MASK) - 1;
|
|
|
|
prio >>= I915_USER_PRIORITY_SHIFT;
|
|
|
|
if (unlikely(execlists->no_priolist))
|
|
|
|
prio = I915_PRIORITY_NORMAL;
|
|
|
|
|
|
|
|
find_priolist:
|
|
|
|
/* most positive priority is scheduled first, equal priorities fifo */
|
|
|
|
rb = NULL;
|
|
|
|
parent = &execlists->queue.rb_root.rb_node;
|
|
|
|
while (*parent) {
|
|
|
|
rb = *parent;
|
|
|
|
p = to_priolist(rb);
|
|
|
|
if (prio > p->priority) {
|
|
|
|
parent = &rb->rb_left;
|
|
|
|
} else if (prio < p->priority) {
|
|
|
|
parent = &rb->rb_right;
|
|
|
|
first = false;
|
|
|
|
} else {
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (prio == I915_PRIORITY_NORMAL) {
|
|
|
|
p = &execlists->default_priolist;
|
|
|
|
} else {
|
2019-02-28 17:20:33 +07:00
|
|
|
p = kmem_cache_alloc(global.slab_priorities, GFP_ATOMIC);
|
2018-10-01 21:47:54 +07:00
|
|
|
/* Convert an allocation failure to a priority bump */
|
|
|
|
if (unlikely(!p)) {
|
|
|
|
prio = I915_PRIORITY_NORMAL; /* recurses just once */
|
|
|
|
|
|
|
|
/* To maintain ordering with all rendering, after an
|
|
|
|
* allocation failure we have to disable all scheduling.
|
|
|
|
* Requests will then be executed in fifo, and schedule
|
|
|
|
* will ensure that dependencies are emitted in fifo.
|
|
|
|
* There will be still some reordering with existing
|
|
|
|
* requests, so if userspace lied about their
|
|
|
|
* dependencies that reordering may be visible.
|
|
|
|
*/
|
|
|
|
execlists->no_priolist = true;
|
|
|
|
goto find_priolist;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
p->priority = prio;
|
|
|
|
for (i = 0; i < ARRAY_SIZE(p->requests); i++)
|
|
|
|
INIT_LIST_HEAD(&p->requests[i]);
|
|
|
|
rb_link_node(&p->node, rb, parent);
|
|
|
|
rb_insert_color_cached(&p->node, &execlists->queue, first);
|
|
|
|
p->used = 0;
|
|
|
|
|
|
|
|
out:
|
|
|
|
p->used |= BIT(idx);
|
|
|
|
return &p->requests[idx];
|
|
|
|
}
|
|
|
|
|
2019-02-12 03:46:47 +07:00
|
|
|
struct sched_cache {
|
|
|
|
struct list_head *priolist;
|
|
|
|
};
|
|
|
|
|
2018-10-01 21:47:54 +07:00
|
|
|
static struct intel_engine_cs *
|
2019-02-12 03:46:47 +07:00
|
|
|
sched_lock_engine(const struct i915_sched_node *node,
|
|
|
|
struct intel_engine_cs *locked,
|
|
|
|
struct sched_cache *cache)
|
2018-10-01 21:47:54 +07:00
|
|
|
{
|
|
|
|
struct intel_engine_cs *engine = node_to_request(node)->engine;
|
|
|
|
|
|
|
|
GEM_BUG_ON(!locked);
|
|
|
|
|
|
|
|
if (engine != locked) {
|
|
|
|
spin_unlock(&locked->timeline.lock);
|
2019-02-12 03:46:47 +07:00
|
|
|
memset(cache, 0, sizeof(*cache));
|
2018-10-01 21:47:54 +07:00
|
|
|
spin_lock(&engine->timeline.lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
return engine;
|
|
|
|
}
|
|
|
|
|
drm/i915/execlists: Suppress preempting self
In order to avoid preempting ourselves, we currently refuse to schedule
the tasklet if we reschedule an inflight context. However, this glosses
over a few issues such as what happens after a CS completion event and
we then preempt the newly executing context with itself, or if something
else causes a tasklet_schedule triggering the same evaluation to
preempt the active context with itself.
However, when we avoid preempting ELSP[0], we still retain the preemption
value as it may match a second preemption request within the same time period
that we need to resolve after the next CS event. However, since we only
store the maximum preemption priority seen, it may not match the
subsequent event and so we should double check whether or not we
actually do need to trigger a preempt-to-idle by comparing the top
priorities from each queue. Later, this gives us a hook for finer
control over deciding whether the preempt-to-idle is justified.
The sequence of events where we end up preempting for no avail is:
1. Queue requests/contexts A, B
2. Priority boost A; no preemption as it is executing, but keep hint
3. After CS switch, B is less than hint, force preempt-to-idle
4. Resubmit B after idling
v2: We can simplify a bunch of tests based on the knowledge that PI will
ensure that earlier requests along the same context will have the highest
priority.
v3: Demonstrate the stale preemption hint with a selftest
References: a2bf92e8cc16 ("drm/i915/execlists: Avoid kicking priority on the current context")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190129185452.20989-4-chris@chris-wilson.co.uk
2019-01-30 01:54:52 +07:00
|
|
|
static bool inflight(const struct i915_request *rq,
|
|
|
|
const struct intel_engine_cs *engine)
|
|
|
|
{
|
|
|
|
const struct i915_request *active;
|
|
|
|
|
drm/i915: Replace global breadcrumbs with per-context interrupt tracking
A few years ago, see commit 688e6c725816 ("drm/i915: Slaughter the
thundering i915_wait_request herd"), the issue of handling multiple
clients waiting in parallel was brought to our attention. The
requirement was that every client should be woken immediately upon its
request being signaled, without incurring any cpu overhead.
To handle certain fragility of our hw meant that we could not do a
simple check inside the irq handler (some generations required almost
unbounded delays before we could be sure of seqno coherency) and so
request completion checking required delegation.
Before commit 688e6c725816, the solution was simple. Every client
waiting on a request would be woken on every interrupt and each would do
a heavyweight check to see if their request was complete. Commit
688e6c725816 introduced an rbtree so that only the earliest waiter on
the global timeline would woken, and would wake the next and so on.
(Along with various complications to handle requests being reordered
along the global timeline, and also a requirement for kthread to provide
a delegate for fence signaling that had no process context.)
The global rbtree depends on knowing the execution timeline (and global
seqno). Without knowing that order, we must instead check all contexts
queued to the HW to see which may have advanced. We trim that list by
only checking queued contexts that are being waited on, but still we
keep a list of all active contexts and their active signalers that we
inspect from inside the irq handler. By moving the waiters onto the fence
signal list, we can combine the client wakeup with the dma_fence
signaling (a dramatic reduction in complexity, but does require the HW
being coherent, the seqno must be visible from the cpu before the
interrupt is raised - we keep a timer backup just in case).
Having previously fixed all the issues with irq-seqno serialisation (by
inserting delays onto the GPU after each request instead of random delays
on the CPU after each interrupt), we can rely on the seqno state to
perfom direct wakeups from the interrupt handler. This allows us to
preserve our single context switch behaviour of the current routine,
with the only downside that we lose the RT priority sorting of wakeups.
In general, direct wakeup latency of multiple clients is about the same
(about 10% better in most cases) with a reduction in total CPU time spent
in the waiter (about 20-50% depending on gen). Average herd behaviour is
improved, but at the cost of not delegating wakeups on task_prio.
v2: Capture fence signaling state for error state and add comments to
warm even the most cold of hearts.
v3: Check if the request is still active before busywaiting
v4: Reduce the amount of pointer misdirection with list_for_each_safe
and using a local i915_request variable inside the loops
v5: Add a missing pluralisation to a purely informative selftest message.
References: 688e6c725816 ("drm/i915: Slaughter the thundering i915_wait_request herd")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190129205230.19056-2-chris@chris-wilson.co.uk
2019-01-30 03:52:29 +07:00
|
|
|
if (!i915_request_is_active(rq))
|
drm/i915/execlists: Suppress preempting self
In order to avoid preempting ourselves, we currently refuse to schedule
the tasklet if we reschedule an inflight context. However, this glosses
over a few issues such as what happens after a CS completion event and
we then preempt the newly executing context with itself, or if something
else causes a tasklet_schedule triggering the same evaluation to
preempt the active context with itself.
However, when we avoid preempting ELSP[0], we still retain the preemption
value as it may match a second preemption request within the same time period
that we need to resolve after the next CS event. However, since we only
store the maximum preemption priority seen, it may not match the
subsequent event and so we should double check whether or not we
actually do need to trigger a preempt-to-idle by comparing the top
priorities from each queue. Later, this gives us a hook for finer
control over deciding whether the preempt-to-idle is justified.
The sequence of events where we end up preempting for no avail is:
1. Queue requests/contexts A, B
2. Priority boost A; no preemption as it is executing, but keep hint
3. After CS switch, B is less than hint, force preempt-to-idle
4. Resubmit B after idling
v2: We can simplify a bunch of tests based on the knowledge that PI will
ensure that earlier requests along the same context will have the highest
priority.
v3: Demonstrate the stale preemption hint with a selftest
References: a2bf92e8cc16 ("drm/i915/execlists: Avoid kicking priority on the current context")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190129185452.20989-4-chris@chris-wilson.co.uk
2019-01-30 01:54:52 +07:00
|
|
|
return false;
|
|
|
|
|
|
|
|
active = port_request(engine->execlists.port);
|
|
|
|
return active->hw_context == rq->hw_context;
|
|
|
|
}
|
|
|
|
|
2018-10-01 21:47:55 +07:00
|
|
|
static void __i915_schedule(struct i915_request *rq,
|
|
|
|
const struct i915_sched_attr *attr)
|
2018-10-01 21:47:54 +07:00
|
|
|
{
|
2019-02-12 03:46:47 +07:00
|
|
|
struct intel_engine_cs *engine;
|
2018-10-01 21:47:54 +07:00
|
|
|
struct i915_dependency *dep, *p;
|
|
|
|
struct i915_dependency stack;
|
|
|
|
const int prio = attr->priority;
|
2019-02-12 03:46:47 +07:00
|
|
|
struct sched_cache cache;
|
2018-10-01 21:47:54 +07:00
|
|
|
LIST_HEAD(dfs);
|
|
|
|
|
2018-10-01 21:47:55 +07:00
|
|
|
/* Needed in order to use the temporary link inside i915_dependency */
|
|
|
|
lockdep_assert_held(&schedule_lock);
|
2018-10-01 21:47:54 +07:00
|
|
|
GEM_BUG_ON(prio == I915_PRIORITY_INVALID);
|
|
|
|
|
|
|
|
if (i915_request_completed(rq))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (prio <= READ_ONCE(rq->sched.attr.priority))
|
|
|
|
return;
|
|
|
|
|
|
|
|
stack.signaler = &rq->sched;
|
|
|
|
list_add(&stack.dfs_link, &dfs);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Recursively bump all dependent priorities to match the new request.
|
|
|
|
*
|
|
|
|
* A naive approach would be to use recursion:
|
|
|
|
* static void update_priorities(struct i915_sched_node *node, prio) {
|
|
|
|
* list_for_each_entry(dep, &node->signalers_list, signal_link)
|
|
|
|
* update_priorities(dep->signal, prio)
|
|
|
|
* queue_request(node);
|
|
|
|
* }
|
|
|
|
* but that may have unlimited recursion depth and so runs a very
|
|
|
|
* real risk of overunning the kernel stack. Instead, we build
|
|
|
|
* a flat list of all dependencies starting with the current request.
|
|
|
|
* As we walk the list of dependencies, we add all of its dependencies
|
|
|
|
* to the end of the list (this may include an already visited
|
|
|
|
* request) and continue to walk onwards onto the new dependencies. The
|
|
|
|
* end result is a topological list of requests in reverse order, the
|
|
|
|
* last element in the list is the request we must execute first.
|
|
|
|
*/
|
|
|
|
list_for_each_entry(dep, &dfs, dfs_link) {
|
|
|
|
struct i915_sched_node *node = dep->signaler;
|
|
|
|
|
2019-02-26 17:23:54 +07:00
|
|
|
/* If we are already flying, we know we have no signalers */
|
|
|
|
if (node_started(node))
|
|
|
|
continue;
|
|
|
|
|
2018-10-01 21:47:54 +07:00
|
|
|
/*
|
|
|
|
* Within an engine, there can be no cycle, but we may
|
|
|
|
* refer to the same dependency chain multiple times
|
|
|
|
* (redundant dependencies are not eliminated) and across
|
|
|
|
* engines.
|
|
|
|
*/
|
|
|
|
list_for_each_entry(p, &node->signalers_list, signal_link) {
|
|
|
|
GEM_BUG_ON(p == dep); /* no cycles! */
|
|
|
|
|
|
|
|
if (node_signaled(p->signaler))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (prio > READ_ONCE(p->signaler->attr.priority))
|
|
|
|
list_move_tail(&p->dfs_link, &dfs);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we didn't need to bump any existing priorities, and we haven't
|
|
|
|
* yet submitted this request (i.e. there is no potential race with
|
|
|
|
* execlists_submit_request()), we can set our own priority and skip
|
|
|
|
* acquiring the engine locks.
|
|
|
|
*/
|
|
|
|
if (rq->sched.attr.priority == I915_PRIORITY_INVALID) {
|
|
|
|
GEM_BUG_ON(!list_empty(&rq->sched.link));
|
|
|
|
rq->sched.attr = *attr;
|
|
|
|
|
|
|
|
if (stack.dfs_link.next == stack.dfs_link.prev)
|
2018-10-01 21:47:55 +07:00
|
|
|
return;
|
2018-10-01 21:47:54 +07:00
|
|
|
|
|
|
|
__list_del_entry(&stack.dfs_link);
|
|
|
|
}
|
|
|
|
|
2019-02-12 03:46:47 +07:00
|
|
|
memset(&cache, 0, sizeof(cache));
|
2018-10-01 21:47:54 +07:00
|
|
|
engine = rq->engine;
|
drm/i915: Bump ready tasks ahead of busywaits
Consider two tasks that are running in parallel on a pair of engines
(vcs0, vcs1), but then must complete on a shared engine (rcs0). To
maximise throughput, we want to run the first ready task on rcs0 (i.e.
the first task that completes on either of vcs0 or vcs1). When using
semaphores, however, we will instead queue onto rcs in submission order.
To resolve this incorrect ordering, we want to re-evaluate the priority
queue when each of the request is ready. Normally this happens because
we only insert into the priority queue requests that are ready, but with
semaphores we are inserting ahead of their readiness and to compensate
we penalize those tasks with reduced priority (so that tasks that do not
need to busywait should naturally be run first). However, given a series
of tasks that each use semaphores, the queue degrades into submission
fifo rather than readiness fifo, and so to counter this we give a small
boost to semaphore users as their dependent tasks are completed (and so
we no longer require any busywait prior to running the user task as they
are then ready themselves).
v2: Fixup irqsave for schedule_lock (Tvrtko)
Testcase: igt/gem_exec_schedule/semaphore-codependency
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>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190409152922.23894-1-chris@chris-wilson.co.uk
2019-04-09 22:29:22 +07:00
|
|
|
spin_lock(&engine->timeline.lock);
|
2018-10-01 21:47:54 +07:00
|
|
|
|
|
|
|
/* Fifo and depth-first replacement ensure our deps execute before us */
|
|
|
|
list_for_each_entry_safe_reverse(dep, p, &dfs, dfs_link) {
|
|
|
|
struct i915_sched_node *node = dep->signaler;
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&dep->dfs_link);
|
|
|
|
|
2019-02-12 03:46:47 +07:00
|
|
|
engine = sched_lock_engine(node, engine, &cache);
|
drm/i915/execlists: Suppress preempting self
In order to avoid preempting ourselves, we currently refuse to schedule
the tasklet if we reschedule an inflight context. However, this glosses
over a few issues such as what happens after a CS completion event and
we then preempt the newly executing context with itself, or if something
else causes a tasklet_schedule triggering the same evaluation to
preempt the active context with itself.
However, when we avoid preempting ELSP[0], we still retain the preemption
value as it may match a second preemption request within the same time period
that we need to resolve after the next CS event. However, since we only
store the maximum preemption priority seen, it may not match the
subsequent event and so we should double check whether or not we
actually do need to trigger a preempt-to-idle by comparing the top
priorities from each queue. Later, this gives us a hook for finer
control over deciding whether the preempt-to-idle is justified.
The sequence of events where we end up preempting for no avail is:
1. Queue requests/contexts A, B
2. Priority boost A; no preemption as it is executing, but keep hint
3. After CS switch, B is less than hint, force preempt-to-idle
4. Resubmit B after idling
v2: We can simplify a bunch of tests based on the knowledge that PI will
ensure that earlier requests along the same context will have the highest
priority.
v3: Demonstrate the stale preemption hint with a selftest
References: a2bf92e8cc16 ("drm/i915/execlists: Avoid kicking priority on the current context")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190129185452.20989-4-chris@chris-wilson.co.uk
2019-01-30 01:54:52 +07:00
|
|
|
lockdep_assert_held(&engine->timeline.lock);
|
2018-10-01 21:47:54 +07:00
|
|
|
|
|
|
|
/* Recheck after acquiring the engine->timeline.lock */
|
|
|
|
if (prio <= node->attr.priority || node_signaled(node))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
node->attr.priority = prio;
|
|
|
|
if (!list_empty(&node->link)) {
|
2019-02-12 03:46:47 +07:00
|
|
|
if (!cache.priolist)
|
|
|
|
cache.priolist =
|
|
|
|
i915_sched_lookup_priolist(engine,
|
|
|
|
prio);
|
|
|
|
list_move_tail(&node->link, cache.priolist);
|
2018-10-01 21:47:54 +07:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* If the request is not in the priolist queue because
|
|
|
|
* it is not yet runnable, then it doesn't contribute
|
|
|
|
* to our preemption decisions. On the other hand,
|
|
|
|
* if the request is on the HW, it too is not in the
|
|
|
|
* queue; but in that case we may still need to reorder
|
|
|
|
* the inflight requests.
|
|
|
|
*/
|
|
|
|
if (!i915_sw_fence_done(&node_to_request(node)->submit))
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2019-01-30 01:54:51 +07:00
|
|
|
if (prio <= engine->execlists.queue_priority_hint)
|
2018-10-01 21:47:54 +07:00
|
|
|
continue;
|
|
|
|
|
drm/i915/execlists: Suppress preempting self
In order to avoid preempting ourselves, we currently refuse to schedule
the tasklet if we reschedule an inflight context. However, this glosses
over a few issues such as what happens after a CS completion event and
we then preempt the newly executing context with itself, or if something
else causes a tasklet_schedule triggering the same evaluation to
preempt the active context with itself.
However, when we avoid preempting ELSP[0], we still retain the preemption
value as it may match a second preemption request within the same time period
that we need to resolve after the next CS event. However, since we only
store the maximum preemption priority seen, it may not match the
subsequent event and so we should double check whether or not we
actually do need to trigger a preempt-to-idle by comparing the top
priorities from each queue. Later, this gives us a hook for finer
control over deciding whether the preempt-to-idle is justified.
The sequence of events where we end up preempting for no avail is:
1. Queue requests/contexts A, B
2. Priority boost A; no preemption as it is executing, but keep hint
3. After CS switch, B is less than hint, force preempt-to-idle
4. Resubmit B after idling
v2: We can simplify a bunch of tests based on the knowledge that PI will
ensure that earlier requests along the same context will have the highest
priority.
v3: Demonstrate the stale preemption hint with a selftest
References: a2bf92e8cc16 ("drm/i915/execlists: Avoid kicking priority on the current context")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190129185452.20989-4-chris@chris-wilson.co.uk
2019-01-30 01:54:52 +07:00
|
|
|
engine->execlists.queue_priority_hint = prio;
|
|
|
|
|
2018-10-01 21:47:54 +07:00
|
|
|
/*
|
|
|
|
* If we are already the currently executing context, don't
|
|
|
|
* bother evaluating if we should preempt ourselves.
|
|
|
|
*/
|
drm/i915/execlists: Suppress preempting self
In order to avoid preempting ourselves, we currently refuse to schedule
the tasklet if we reschedule an inflight context. However, this glosses
over a few issues such as what happens after a CS completion event and
we then preempt the newly executing context with itself, or if something
else causes a tasklet_schedule triggering the same evaluation to
preempt the active context with itself.
However, when we avoid preempting ELSP[0], we still retain the preemption
value as it may match a second preemption request within the same time period
that we need to resolve after the next CS event. However, since we only
store the maximum preemption priority seen, it may not match the
subsequent event and so we should double check whether or not we
actually do need to trigger a preempt-to-idle by comparing the top
priorities from each queue. Later, this gives us a hook for finer
control over deciding whether the preempt-to-idle is justified.
The sequence of events where we end up preempting for no avail is:
1. Queue requests/contexts A, B
2. Priority boost A; no preemption as it is executing, but keep hint
3. After CS switch, B is less than hint, force preempt-to-idle
4. Resubmit B after idling
v2: We can simplify a bunch of tests based on the knowledge that PI will
ensure that earlier requests along the same context will have the highest
priority.
v3: Demonstrate the stale preemption hint with a selftest
References: a2bf92e8cc16 ("drm/i915/execlists: Avoid kicking priority on the current context")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190129185452.20989-4-chris@chris-wilson.co.uk
2019-01-30 01:54:52 +07:00
|
|
|
if (inflight(node_to_request(node), engine))
|
2018-10-01 21:47:54 +07:00
|
|
|
continue;
|
|
|
|
|
|
|
|
/* Defer (tasklet) submission until after all of our updates. */
|
|
|
|
tasklet_hi_schedule(&engine->execlists.tasklet);
|
|
|
|
}
|
|
|
|
|
drm/i915: Bump ready tasks ahead of busywaits
Consider two tasks that are running in parallel on a pair of engines
(vcs0, vcs1), but then must complete on a shared engine (rcs0). To
maximise throughput, we want to run the first ready task on rcs0 (i.e.
the first task that completes on either of vcs0 or vcs1). When using
semaphores, however, we will instead queue onto rcs in submission order.
To resolve this incorrect ordering, we want to re-evaluate the priority
queue when each of the request is ready. Normally this happens because
we only insert into the priority queue requests that are ready, but with
semaphores we are inserting ahead of their readiness and to compensate
we penalize those tasks with reduced priority (so that tasks that do not
need to busywait should naturally be run first). However, given a series
of tasks that each use semaphores, the queue degrades into submission
fifo rather than readiness fifo, and so to counter this we give a small
boost to semaphore users as their dependent tasks are completed (and so
we no longer require any busywait prior to running the user task as they
are then ready themselves).
v2: Fixup irqsave for schedule_lock (Tvrtko)
Testcase: igt/gem_exec_schedule/semaphore-codependency
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>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190409152922.23894-1-chris@chris-wilson.co.uk
2019-04-09 22:29:22 +07:00
|
|
|
spin_unlock(&engine->timeline.lock);
|
2018-10-01 21:47:55 +07:00
|
|
|
}
|
2018-10-01 21:47:54 +07:00
|
|
|
|
2018-10-01 21:47:55 +07:00
|
|
|
void i915_schedule(struct i915_request *rq, const struct i915_sched_attr *attr)
|
|
|
|
{
|
drm/i915: Bump ready tasks ahead of busywaits
Consider two tasks that are running in parallel on a pair of engines
(vcs0, vcs1), but then must complete on a shared engine (rcs0). To
maximise throughput, we want to run the first ready task on rcs0 (i.e.
the first task that completes on either of vcs0 or vcs1). When using
semaphores, however, we will instead queue onto rcs in submission order.
To resolve this incorrect ordering, we want to re-evaluate the priority
queue when each of the request is ready. Normally this happens because
we only insert into the priority queue requests that are ready, but with
semaphores we are inserting ahead of their readiness and to compensate
we penalize those tasks with reduced priority (so that tasks that do not
need to busywait should naturally be run first). However, given a series
of tasks that each use semaphores, the queue degrades into submission
fifo rather than readiness fifo, and so to counter this we give a small
boost to semaphore users as their dependent tasks are completed (and so
we no longer require any busywait prior to running the user task as they
are then ready themselves).
v2: Fixup irqsave for schedule_lock (Tvrtko)
Testcase: igt/gem_exec_schedule/semaphore-codependency
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>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190409152922.23894-1-chris@chris-wilson.co.uk
2019-04-09 22:29:22 +07:00
|
|
|
spin_lock_irq(&schedule_lock);
|
2018-10-01 21:47:55 +07:00
|
|
|
__i915_schedule(rq, attr);
|
drm/i915: Bump ready tasks ahead of busywaits
Consider two tasks that are running in parallel on a pair of engines
(vcs0, vcs1), but then must complete on a shared engine (rcs0). To
maximise throughput, we want to run the first ready task on rcs0 (i.e.
the first task that completes on either of vcs0 or vcs1). When using
semaphores, however, we will instead queue onto rcs in submission order.
To resolve this incorrect ordering, we want to re-evaluate the priority
queue when each of the request is ready. Normally this happens because
we only insert into the priority queue requests that are ready, but with
semaphores we are inserting ahead of their readiness and to compensate
we penalize those tasks with reduced priority (so that tasks that do not
need to busywait should naturally be run first). However, given a series
of tasks that each use semaphores, the queue degrades into submission
fifo rather than readiness fifo, and so to counter this we give a small
boost to semaphore users as their dependent tasks are completed (and so
we no longer require any busywait prior to running the user task as they
are then ready themselves).
v2: Fixup irqsave for schedule_lock (Tvrtko)
Testcase: igt/gem_exec_schedule/semaphore-codependency
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>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190409152922.23894-1-chris@chris-wilson.co.uk
2019-04-09 22:29:22 +07:00
|
|
|
spin_unlock_irq(&schedule_lock);
|
2018-10-01 21:47:54 +07:00
|
|
|
}
|
2018-10-01 21:47:55 +07:00
|
|
|
|
|
|
|
void i915_schedule_bump_priority(struct i915_request *rq, unsigned int bump)
|
|
|
|
{
|
|
|
|
struct i915_sched_attr attr;
|
drm/i915: Bump ready tasks ahead of busywaits
Consider two tasks that are running in parallel on a pair of engines
(vcs0, vcs1), but then must complete on a shared engine (rcs0). To
maximise throughput, we want to run the first ready task on rcs0 (i.e.
the first task that completes on either of vcs0 or vcs1). When using
semaphores, however, we will instead queue onto rcs in submission order.
To resolve this incorrect ordering, we want to re-evaluate the priority
queue when each of the request is ready. Normally this happens because
we only insert into the priority queue requests that are ready, but with
semaphores we are inserting ahead of their readiness and to compensate
we penalize those tasks with reduced priority (so that tasks that do not
need to busywait should naturally be run first). However, given a series
of tasks that each use semaphores, the queue degrades into submission
fifo rather than readiness fifo, and so to counter this we give a small
boost to semaphore users as their dependent tasks are completed (and so
we no longer require any busywait prior to running the user task as they
are then ready themselves).
v2: Fixup irqsave for schedule_lock (Tvrtko)
Testcase: igt/gem_exec_schedule/semaphore-codependency
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>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190409152922.23894-1-chris@chris-wilson.co.uk
2019-04-09 22:29:22 +07:00
|
|
|
unsigned long flags;
|
2018-10-01 21:47:55 +07:00
|
|
|
|
|
|
|
GEM_BUG_ON(bump & ~I915_PRIORITY_MASK);
|
|
|
|
|
|
|
|
if (READ_ONCE(rq->sched.attr.priority) == I915_PRIORITY_INVALID)
|
|
|
|
return;
|
|
|
|
|
drm/i915: Bump ready tasks ahead of busywaits
Consider two tasks that are running in parallel on a pair of engines
(vcs0, vcs1), but then must complete on a shared engine (rcs0). To
maximise throughput, we want to run the first ready task on rcs0 (i.e.
the first task that completes on either of vcs0 or vcs1). When using
semaphores, however, we will instead queue onto rcs in submission order.
To resolve this incorrect ordering, we want to re-evaluate the priority
queue when each of the request is ready. Normally this happens because
we only insert into the priority queue requests that are ready, but with
semaphores we are inserting ahead of their readiness and to compensate
we penalize those tasks with reduced priority (so that tasks that do not
need to busywait should naturally be run first). However, given a series
of tasks that each use semaphores, the queue degrades into submission
fifo rather than readiness fifo, and so to counter this we give a small
boost to semaphore users as their dependent tasks are completed (and so
we no longer require any busywait prior to running the user task as they
are then ready themselves).
v2: Fixup irqsave for schedule_lock (Tvrtko)
Testcase: igt/gem_exec_schedule/semaphore-codependency
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>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190409152922.23894-1-chris@chris-wilson.co.uk
2019-04-09 22:29:22 +07:00
|
|
|
spin_lock_irqsave(&schedule_lock, flags);
|
2018-10-01 21:47:55 +07:00
|
|
|
|
|
|
|
attr = rq->sched.attr;
|
|
|
|
attr.priority |= bump;
|
|
|
|
__i915_schedule(rq, &attr);
|
|
|
|
|
drm/i915: Bump ready tasks ahead of busywaits
Consider two tasks that are running in parallel on a pair of engines
(vcs0, vcs1), but then must complete on a shared engine (rcs0). To
maximise throughput, we want to run the first ready task on rcs0 (i.e.
the first task that completes on either of vcs0 or vcs1). When using
semaphores, however, we will instead queue onto rcs in submission order.
To resolve this incorrect ordering, we want to re-evaluate the priority
queue when each of the request is ready. Normally this happens because
we only insert into the priority queue requests that are ready, but with
semaphores we are inserting ahead of their readiness and to compensate
we penalize those tasks with reduced priority (so that tasks that do not
need to busywait should naturally be run first). However, given a series
of tasks that each use semaphores, the queue degrades into submission
fifo rather than readiness fifo, and so to counter this we give a small
boost to semaphore users as their dependent tasks are completed (and so
we no longer require any busywait prior to running the user task as they
are then ready themselves).
v2: Fixup irqsave for schedule_lock (Tvrtko)
Testcase: igt/gem_exec_schedule/semaphore-codependency
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>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190409152922.23894-1-chris@chris-wilson.co.uk
2019-04-09 22:29:22 +07:00
|
|
|
spin_unlock_irqrestore(&schedule_lock, flags);
|
2018-10-01 21:47:55 +07:00
|
|
|
}
|
2019-02-28 17:20:33 +07:00
|
|
|
|
|
|
|
void __i915_priolist_free(struct i915_priolist *p)
|
|
|
|
{
|
|
|
|
kmem_cache_free(global.slab_priorities, p);
|
|
|
|
}
|
|
|
|
|
2019-03-06 04:38:30 +07:00
|
|
|
static void i915_global_scheduler_shrink(void)
|
|
|
|
{
|
|
|
|
kmem_cache_shrink(global.slab_dependencies);
|
|
|
|
kmem_cache_shrink(global.slab_priorities);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void i915_global_scheduler_exit(void)
|
|
|
|
{
|
|
|
|
kmem_cache_destroy(global.slab_dependencies);
|
|
|
|
kmem_cache_destroy(global.slab_priorities);
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct i915_global_scheduler global = { {
|
|
|
|
.shrink = i915_global_scheduler_shrink,
|
|
|
|
.exit = i915_global_scheduler_exit,
|
|
|
|
} };
|
|
|
|
|
2019-02-28 17:20:33 +07:00
|
|
|
int __init i915_global_scheduler_init(void)
|
|
|
|
{
|
|
|
|
global.slab_dependencies = KMEM_CACHE(i915_dependency,
|
|
|
|
SLAB_HWCACHE_ALIGN);
|
|
|
|
if (!global.slab_dependencies)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
global.slab_priorities = KMEM_CACHE(i915_priolist,
|
|
|
|
SLAB_HWCACHE_ALIGN);
|
|
|
|
if (!global.slab_priorities)
|
|
|
|
goto err_priorities;
|
|
|
|
|
2019-03-06 04:38:30 +07:00
|
|
|
i915_global_register(&global.base);
|
2019-02-28 17:20:33 +07:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
err_priorities:
|
|
|
|
kmem_cache_destroy(global.slab_priorities);
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|