[Intel-gfx] [PATCH] drm/i915/gt: execlists->active is serialised by the tasklet

[Chris Wilson]

Quoting Tvrtko Ursulin (2019-10-09 17:37:42)
> 
> On 09/10/2019 16:59, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-10-09 16:53:53)
> >>
> >> On 09/10/2019 11:26, Chris Wilson wrote:
> >>> +static inline void
> >>> +execlists_active_lock(struct intel_engine_execlists *execlists)
> >>> +{
> >>> +     tasklet_lock(&execlists->tasklet);
> >>> +}
> >>> +
> >>> +static inline void
> >>> +execlists_active_unlock(struct intel_engine_execlists *execlists)
> >>> +{
> >>> +     tasklet_unlock(&execlists->tasklet);
> >>> +}
> >>
> >> After we stop preventing the tasklet from running should we maybe kick
> >> ksoftirqd? I am thinking if a tasklet gets scheduled and ran during us
> >> holding the lock here, it won't lose the "scheduled" status, but not
> >> sure at what next opportunity it would get re-run.
> > 
> > If we call tasklet_schedule() while we hold tasklet_lock, ksoftirqd (on
> > another thread, hmm, we need local_bh_disable() to stop ourselves
> > entering the softirq processing), then that tasklet_action will spin on
> > tasklet_trylock.
> 
> I don't see it spinning, I see it unlinking the tasklet is trylock fails 
> and going onto the next one. So even what I implied before seems wrong - 
> it doesn't look like it would get re-run on next tasklet processing run. 
> Where do you see the retry?

It puts it back onto the list of taskets to run. Then sees it still has
tasklets to run and reschedules itself.

tasklet_action_common:
	1. sets list of pending tasklets to NULL
	2. iterates over current list
	3. if not executed (trylock failed, or disabled) then appends
	   the tasklet to the list of pending for next time, and
	   re-raises the softirq, thereby rescheduling the
	   softirq/ksoftirqd.

-Chris