[Intel-gfx] [PATCH 07/31] drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd)

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-06-28 12:56:56)
> 
> On 27/06/2018 16:28, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-06-27 16:21:24)
> >>
> >> On 27/06/2018 14:29, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2018-06-27 14:15:22)
> >>>>
> >>>> On 27/06/2018 11:58, Chris Wilson wrote:
> >>>>> That tasklets get kicked randomly, I think was the culprit.
> >>>>
> >>>> What do you mean? I hope we have busy-idle quite controlled and we know
> >>>> when we should and should expect a tasklet. If we synced them when
> >>>> transitioning to idle they cannot happen. Otherwise we better be active!
> >>>> GEM_BUG_ON(!engine->i915->gt.awake) instead? Does that trigger?!
> >>>
> >>> tasklet_schedule() is called off the main path, without locking, so
> >>> unsynchronized to parking. Just because.
> >>
> >> I need to understand this - which main path? Submission - we will be
> >> mark_busy. After last request - we will idle the engines and sync the
> >> tasklet.
> > 
> > There's a bonus kick in intel_engine_is_idle() (behind an unprotected
> > read of active, so still possible to race), and I've added an
> > unconditional kick to pmu_enable because we play games with
> > tasklet_disable there that may cause us to miss a direct submission.
> 
> intel_engine_is_idle form the idle work handler is before awake is 
> cleared, so not that?

intel_engine_is_idle() may be called at any time though, and will race.
 
> And tasklet kick from intel_enable_engine_stats, hm yep. But wouldn't 
> taking the timeline lock around active state reconstruction solve that 
> simpler?

Can you? We probably can. (That one was a very recent discovery and
quick fix.)

Since that was a very recent discovery, my fallible memory says the
GEM_BUG_ON() popped up from intel_engine_is_idle. Not that everything
has changed since then, ofc.
-Chris