[PATCH 15/57] drm/i915: Introduce the scheduling mode

[Tvrtko Ursulin]

On 05/02/2021 17:04, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2021-02-05 16:47:37)
>>
>> On 05/02/2021 01:18, Chris Wilson wrote:
>>> +/**
>>> + * enum i915_sched_mode - how the scheduler may reorder requests
>>> + *
>>> + * The foundational principle of scheduling is that it controls the order
>>> + * of execution of tasks within the system. Given a set of ready requests,
>>> + * we may choose not to reorder them [FIFO] or submit them in a priority
>>> + * order. The basic ordering is by user assigned priority [PRIORITY], the
>>> + * highest priority requests are executed first. A revision of that is
>>> + * to execute them in order of a virtual deadline, which is a fair, budget
>>> + * conserving exection order [DEADLINE]. In both PRIORITY and DEADLINE, we
>>> + * have to consider priority inversion that may arise when higher priority
>>> + * work depends on low priority work, and so we track the work dependencies
>>> + * and when we need to execute higher priority work, we raise the priority
>>> + * of all of its dependecies so that it is not block.
>>> + *
>>> + * With no active scheduler [NONE], the execution order is fixed by order of
>>> + * submission, due to ordering via a global resource such as the legacy
>>> + * shared ringbuffer. Since we cannot reorder the requests at all, we
>>> + * mark this as an inactive scheduler, and do not track any dependencies.
>>> + */
>>> +enum i915_sched_mode {
>>> +     I915_SCHED_MODE_NONE = -1, /* inactive, no bubble prevention */
>>> +     I915_SCHED_MODE_FIFO, /* pass-through of ready, first in first out */
>>> +     I915_SCHED_MODE_PRIORITY, /* reorder strictly by priority */
>>> +};
>>
>> No deadline yet (mentioned in the comment), however would deadline even
>> be the right enum to use. What would you set it as GuC?
> 
> GuC, at the moment, would select FIFO. Since it is just using the queue
> to passthrough requests, so we only use the extra lists if we want to
> suspend submission using the scheduler, or if we exhaust the guc and
> need to queue while waiting for resources.
> 
> (I put a couple of bypasses into the scheduler so we opt out of either
> the DFS for deadlines or priorities.)
> 
> Now I remember that I need to separate the caps reported to userspace
> from the mode.
> 
>> And why would userspace need to know anything more than FIFO or "some
>> smarter reordering"? Maybe timeslicing. Those three sound like generic
>> concepts. Can scheduler re-order, can it timeslice. And actually if it
>> can't re-order then it is FIFO by implication so two flags might be enough.
> 
> Currently, we use the scheduler.caps & PRIORITY as the switch for
> allowing gem_context_set_priority(). That does make sense, as we use
> that also to determine if we support context priorities in GL and
> Vulkan. I think compute gained something similar.
> 
> Priority seems useful.

Yes, okay.
> Timeslicing (as the superset of preemption + semaphores) I thought was
> useful as it is the indicator as to whether or not it is truly safe to
> use semaphores in userspace.

Agreed.

>> I am definitely not sure about deadline flag later in the series. I mean
>> as exposed to userspace at any level more serious than debugfs.
> 
> I called the cap FAIR to try not to say anything about the implementation
> but the intention. This was just a nice to know (i.e. something we
> advertise to big tenant customers for them to quickly check if all is ok),
> I don't have a plan on how to use it, apart from including it in bug
> reports just in case. Other than I foresee the guc seeing that flag as an
> excuse to skip gem_exec_fair :(

Can we then have a final flag called re-order? So no fair or deadline, 
just re-order with actual flavour of re-ordering to be implementation 
dependent and only exposed semantics being "it's not fifo".

Regards,

Tvrtko