drm/i915/execlists: Avoid kicking priority on the current context
authorChris Wilson <chris@chris-wilson.co.uk>
Tue, 25 Sep 2018 08:31:59 +0000 (09:31 +0100)
committerChris Wilson <chris@chris-wilson.co.uk>
Thu, 27 Sep 2018 12:45:20 +0000 (13:45 +0100)
commita2bf92e8cc16f6bf33bc8053c776630c79ad0325
tree4aa41c5e65e07df64c90552deec2533c896b2ca0
parent7fe78985cd0881ab60b13320f74df0ed6655f2fe
drm/i915/execlists: Avoid kicking priority on the current context

If the request is currently on the HW (in port 0), then we do not need
to kick the submission tasklet to evaluate whether we should be
preempting itself in order to execute it again.

In the case that was annoying me:

   execlists_schedule: rq(18:211173).prio=0 -> 2
   need_preempt: last(18:211174).prio=0, queue.prio=2

We are bumping the priority of the first of a pair of requests running
in the current context. Then when evaluating preempt, we would see that
that our priority request is higher than the last executing request in
ELSP0 and so trigger preemption, not realising that our intended request
was already executing.

v2: As we assume state of the execlists->port[] that is only valid while
we hold the timeline lock we have to repeat some earlier tests that on
the validity of the node.
v3: Wrap guc submission under the timeline.lock as is now the way of all
things.

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/20180925083205.2229-2-chris@chris-wilson.co.uk
drivers/gpu/drm/i915/intel_guc_submission.c
drivers/gpu/drm/i915/intel_lrc.c