On 4/25/24 17:28, Joel Fernandes wrote:
But if I understand, sched_ext is below CFS at the moment, so that should not be an issue. [1] By the way, now that I brought up the higher priority class thing, I might as well discuss it here :-D : One of my use cases is about scheduling high priority latency sensitive threads: I think if sched_ext could have 2 classes, one lower than CFS and one above CFS, that would be beneficial to those who want a gradual transition to use scx, instead of switching all tasks to scx at once.
The way we initially went with Ghost (which is the Google project similar to sched_ext) was to run Ghost below CFS. That was a "safety first" approach, where we didn't have a lot of faith in the schedulers we were writing and wanted to convince people (including ourselves) that we wouldn't completely hose a machine.
For the same reason you pointed out, we eventually wanted to run our schedulers above CFS. Currently, Ghost has the option to run above or below CFS, and we're pretty close to being able to run all of our schedulers above CFS. Once we do that, I imagine we'll drop the "above or below" aspect, since it's a bit more complicated.
It's actually even more complicated than that - ghost also has a separate "ghost agent" sched class above CFS, even if ghost itself is below CFS. This lets us run a single userspace "agent task" on a cpu to make a scheduling decision.
Anyway, when we port Ghost to run on sched_ext instead of our custom ghost sched class(es), we'll be running sched_ext above CFS, and I doubt we'll want to run below CFS at all. Though whether that's a local patch we carry, or the default upstream probably depends on what everyone else wants too.
Thanks, Barret
