Quoting Tvrtko Ursulin (2018-09-24 11:29:52)
>
> On 19/09/2018 20:55, Chris Wilson wrote:
> > Taken from an idea used for FQ_CODEL, we give the first request of a
> > new request flows a small priority boost. These flows are likely to
> > correspond with short, interactive tasks and so be more latency sensitive
> > than the longer free running queues. As soon as the client has more than
> > one request in the queue, further requests are not boosted and it settles
> > down into ordinary steady state behaviour. Such small kicks dramatically
> > help combat the starvation issue, by allowing each client the opportunity
> > to run even when the system is under heavy throughput load (within the
> > constraints of the user selected priority).
> >
> > v2: Mark the preempted request as the start of a new flow, to prevent a
> > single client being continually gazumped by its peers.
> >
> > Testcase: igt/benchmarks/rrul
> > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
> > Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
> > ---
> > drivers/gpu/drm/i915/i915_request.c | 16 ++++++++++++++--
> > drivers/gpu/drm/i915/i915_scheduler.h | 4 +++-
> > drivers/gpu/drm/i915/intel_lrc.c | 25 +++++++++++++++++++------
> > 3 files changed, 36 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> > index a492385b2089..56140ca054e8 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -1127,8 +1127,20 @@ void i915_request_add(struct i915_request *request)
> > */
> > local_bh_disable();
> > rcu_read_lock(); /* RCU serialisation for set-wedged protection */
> > - if (engine->schedule)
> > - engine->schedule(request, &request->gem_context->sched);
> > + if (engine->schedule) {
> > + struct i915_sched_attr attr = request->gem_context->sched;
> > +
> > + /*
> > + * Boost priorities to new clients (new request flows).
> > + *
> > + * Allow interactive/synchronous clients to jump ahead of
> > + * the bulk clients. (FQ_CODEL)
> > + */
> > + if (!prev || i915_request_completed(prev))
> > + attr.priority |= I915_PRIORITY_NEWCLIENT;
> > +
> > + engine->schedule(request, &attr);
> > + }
> > rcu_read_unlock();
> > i915_sw_fence_commit(&request->submit);
> > local_bh_enable(); /* Kick the execlists tasklet if just scheduled */
> > diff --git a/drivers/gpu/drm/i915/i915_scheduler.h b/drivers/gpu/drm/i915/i915_scheduler.h
> > index 7edfad0abfd7..93e43e263d8c 100644
> > --- a/drivers/gpu/drm/i915/i915_scheduler.h
> > +++ b/drivers/gpu/drm/i915/i915_scheduler.h
> > @@ -19,12 +19,14 @@ enum {
> > I915_PRIORITY_INVALID = INT_MIN
> > };
> >
> > -#define I915_USER_PRIORITY_SHIFT 0
> > +#define I915_USER_PRIORITY_SHIFT 1
> > #define I915_USER_PRIORITY(x) ((x) << I915_USER_PRIORITY_SHIFT)
> >
> > #define I915_PRIORITY_COUNT BIT(I915_USER_PRIORITY_SHIFT)
> > #define I915_PRIORITY_MASK (-I915_PRIORITY_COUNT)
> >
> > +#define I915_PRIORITY_NEWCLIENT ((u8)BIT(0))
>
> Is the cast important and why?
Unreliable memory says there was something iffy about the code generation
at one point.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
