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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
