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