[RFC 08/14] drm/sched: Add deadline policy

[Tvrtko Ursulin]

On 03/01/2025 12:59, Philipp Stanner wrote:
> On Fri, 2025-01-03 at 12:40 +0000, Tvrtko Ursulin wrote:
>>
>> On 02/01/2025 13:11, Philipp Stanner wrote:
>>> On Mon, 2024-12-30 at 16:52 +0000, Tvrtko Ursulin wrote:
>>>> From: Tvrtko Ursulin <tvrtko.ursulin at igalia.com>
>>>>
>>>> Deadline scheduling policy should be a fairer flavour of FIFO
>>>> with
>>>> two
>>>> main advantages being that it can naturally connect with the dma-
>>>> fence
>>>> deadlines, and secondly that it can get away with multiple run
>>>> queues
>>>> per
>>>> scheduler.
>>>>
>>>>   From the latter comes the fairness advantage. Where the current
>>>> FIFO
>>>> policy will always starve low priority entities by normal, and
>>>> normal
>>>> by high etc, deadline tracks all runnable entities in a single
>>>> run
>>>> queue
>>>> and assigns them deadlines based on priority. Instead of being
>>>> ordered
>>>> strictly by priority, jobs and entities become ordered by
>>>> deadlines.
>>>>
>>>> This means that a later higher priority submission can still
>>>> overtake
>>>> an
>>>> earlier lower priority one, but eventually the lower priority
>>>> will
>>>> get its
>>>> turn even if high priority is constantly feeding new work.
>>>
>>> So, as you're aware of, this is a major change in behavior. FIFO's
>>> purpose actually is to be unfair, and my understanding has always
>>> been
>>> that it is on purpose that the higher priority will with absolute
>>> certainty take precedence.
>>>
>>> Reason being that on the high priority things like configuring
>>> memory /
>>> mappings are done, which you want to be prioritized.
>>
>> Right. For the kernel priority for instance I could make them get a
>> very
>> early deadline ensuring they still run first.
> 
> That definitely sounds reasonable to me.
> I saw that you already gave the kernel quite a low deadline value.
> 
>>
>>> IOW in which scenario would you want the low priorities to be able
>>> to
>>> overtake the higher ones?
>>
>> I would say always. I don't see it as overtaking but avoiding
>> complete
>> starvation. In the CPU world if you run:
>>
>> $ game & nice computation
>>
>> You don't expect the computation to get zero CPU time while the game
>> is
>> running.
> 
> I expect exactly that *if* game is scheduled with SCHED_FIFO :)

:))

> That's why the process scheduler also has SCHED_DEADLINE since a few
> years, to address basically exactly the problem you're addressing he >
>> Although I am not saying with the current DRM scheduler it is
>> guaranteed
>> to get zero GPU time. It will still get scheduled in cases when the
>> priority run queues happen to be temporarily empty. But if someone
>> would
>> be submitting work very efficiently low priority would never run.
>>
>> Deadline in its current form is not perfect or immune to all
>> submission
>> patterns either, which is why this is RFC.
> 
> Will have to think about that, thx.
> 
> I'd definitely be more interested in why the priority levels were
> exposed to userspace and what applications most typically do with them.

EGL_IMG_context_priority and VK_KHR_global_priority. But both are just 
hints and definitely do not prescribe or require SCHED_FIFO like behaviour.

> As you're describing it it sounds as if they're not intending to use it
> like in the classic process scheduler with SCHED_FIFO, but that they
> are more on the default (SCHED_OTHER) and are trying to set the
> *niceness*

Yes exactly. I don't think DRM scheduler _needs_ to be like SCHED_FIFO. 
More like SCHED_OTHER would I think work better if we were to (finally) 
expose some external control (see 
https://blogs.igalia.com/tursulin/drm-scheduling-cgroup-controller/ for 
one related example).

Regards,

Tvrtko