Chris Wilson <ch...@chris-wilson.co.uk> writes: > When called from process context tasklet_schedule() defers itself to > ksoftirqd. From experience this may cause unacceptable latencies of over > 200ms in executing the submission tasklet, our goal is to reprioritise > the HW execution queue and trigger preemption immediately, so convert
I would add 'execlists preemption' even tho the context points to it, as we are also quite intimately entangled here with kernel preemption too. > the rcu protection over to include a kick of the tasklet. > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com> > --- > drivers/gpu/drm/i915/i915_gem.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 5ece6ae4bdff..03cd30001b5d 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -578,10 +578,10 @@ static void __fence_set_priority(struct dma_fence > *fence, > rq = to_request(fence); > engine = rq->engine; > > - rcu_read_lock(); > + local_bh_disable(); /* RCU serialisation for set-wedged protection */ > if (engine->schedule) > engine->schedule(rq, attr); > - rcu_read_unlock(); > + local_bh_enable(); /* kick the tasklets if queues were reprioritised */ Do we end up calling the tasklet->func() explicitly on the end of engine->schedule()? Reviewed-by: Mika Kuoppala <mika.kuopp...@linux.intel.com> > } > > static void fence_set_priority(struct dma_fence *fence, > -- > 2.17.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
