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

[Tvrtko Ursulin]

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?

And tasklet kick from intel_enable_engine_stats, hm yep. But wouldn't 
taking the timeline lock around active state reconstruction solve that 
simpler?

Regards,

Tvrtko