[Intel-gfx] [PATCH 5/5] drm/i915: Prioritise non-busywait semaphore workloads

[Chris Wilson]

Quoting Tvrtko Ursulin (2019-03-01 11:48:25)
> 
> On 01/03/2019 11:05, Chris Wilson wrote:
> > @@ -69,6 +70,10 @@ bool __i915_sched_node_add_dependency(struct i915_sched_node *node,
> >               dep->signaler = signal;
> >               dep->flags = flags;
> >   
> > +             /* Keep track of whether anyone on this chain has a semaphore */
> > +             if (signal->semaphore && !node_started(signal))
> > +                     node->semaphore |= signal->semaphore << 1;
> 
> Maybe I am confused.. this moves the bit flag to the left. Can't it fall 
> off the end and we end up with zero after a deep enough chain?

Yup. I was working on the likelihood of that happening being small
enough to below the level of care :)

The semaphore being 64 requests ago and still not retired? That's like
igt levels of stress :)

Hmm, at one point I was using the history to determine whether this
request itself had a semaphore, but that's gone. So we can just use

if (signal->semaphore && !node_started(signal))
	node->semaphore |= signal->semaphore;

> > @@ -74,6 +75,8 @@ struct i915_sched_node {
> >       struct list_head waiters_list; /* those after us, they depend upon us */
> >       struct list_head link;
> >       struct i915_sched_attr attr;
> > +     unsigned long semaphore;
> > +#define I915_SCHED_HAS_SEMAPHORE     BIT(0)
> 
> unsigned int?

Everything is/will-be aligned to a pointer, and this gave us a deeper
chain :)

However, the chain is moot, so unsigned int is fine. And we can call it
flags if we aren't keeping the chain.
-Chris