Hello,
I'd like to reaffirm Valve and Igalia's backing for the sched_ext
proposal.
Let's delve into the context first. Valve, in collaboration with
Igalia and other firms, has been dedicated to enhancing the
gaming experience on Linux. Our endeavor involves utilizing
a standard Linux distribution (SteamOS) to execute unaltered
Windows games on the Linux kernel with the aid of Wine and
various other software components. The overarching objective is
to refine the Linux desktop environment for gaming and
interactive purposes. As part of our commitment, we adhere to an
"upstream everything" policy, contributing to the Linux kernel
and numerous open-source projects. For those interested, you can
explore the details of our contributions through the following
link:
https://osseu2023.sched.com/event/1Qv8y/how-steamos-is-contributing-to-the-linux-ecosystem-alberto-garcia-igalia
From our perspective, sched_ext holds significant promise and
utility, particularly in facilitating rapid experimentation with
new ideas. Our experimental ideas may or may not align with the
existing scheduler designs, be it CFS or EEVDF.
Specifically, our research into the characteristics of gaming
workloads for schedulers has unveiled intriguing insights that
could inform better scheduling decisions. For instance, tasks
within the gaming software stack, such as game engines, Wine, and
graphics drivers, often exhibit very short duration when
scheduled, necessitating frequent scheduling activities.
Moreover, multiple tasks across software layers collaborate to
complete a single application-level task, forming task chains.
Inadequate scheduling decisions within these chains can lead to
high tail latency, commonly known as "stuttering" in the gaming
community.
Witness the metric ton of toy schedulers written for it, that's all
effort not put into improving the existing code.
While these properties offer valuable insights for improving
scheduling decisions for gaming workloads, their applicability to
general-purpose schedulers like EEVDF remains uncertain. The most
effective means to evaluate their broader utility is through
practical experimentation. In this regard, sched_ext provides an
excellent platform for rapid testing of new ideas.
One may question why not just experiment out-of-tree? In reality,
we can’t just trivially patch _general-purpose_ EEVDF (and CFS
too) to be better for _all_ use cases, especially when upstream
has resisted tons of niche complexity in the upstream scheduler.
It is a very hard problem, and we believe having the sched_ext
upstream for more users/distros will encourage more progress. Our
case of Linux gaming demonstrates that working on the existing
code is neither always possible nor effective. Further details of
our findings can be found through the following link:
https://ossna2024.sched.com/event/1aBOT/optimizing-scheduler-for-linux-gaming-changwoo-min-igalia
situation that's been created is solved. And even then, I fundamentally
believe the approach to be detrimental to the scheduler eco-system.
Contrary to the notion that sched_ext might prove detrimental to
the scheduler ecosystem, we hold a different view. The successful
implementation of sched_ext enriches the scheduler community with
fresh insights, ideas, and code. For instance, our adoption of
a virtual deadline-based approach in designing LAVD
(Latency-criticality Aware Virtual Deadline), our sched_ext-based
scheduler for gaming, represents a deliberate design choice.
Aligning our heuristics and findings with EEVDF through a similar
virtual deadline-based approach enables us to contribute our
discoveries to EEVDF in the future once proven to be more
universally applicable. Notably, the concept of "latency
criticality" in LAVD holds promise beyond gaming workloads,
potentially benefiting various interactive workloads. If you are
interested in, you can find the source code of LAVD in the
following link:
https://github.com/sched-ext/scx/tree/main/scheds/rust/scx_lavd
In essence, I envision sched_ext and its community as an
incubator for new ideas, invigorating the scheduler ecosystem.
Some of the "toy" schedulers may evolve into specialized
solutions tailored for specific problem domains, such as HPC,
AI/ML, or gaming. Lessons learned from these experimental
schedulers will invariably contribute, directly or indirectly, to
the evolution of the EEVDF scheduler.
Sincerely,
Changwoo Min
