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@xxxxxxxxxx>
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
