While this looks like a step in the right direction to provide user-space per-process control of the latency VS throughput tradeoffs (lower runqueue latency at

While this looks like a step in the right direction to provide user-space per-process control of the latency VS throughput tradeoffs (lower runqueue latency at the expense of shorter timeslices), I'd rather see the SCHED_EXT patch [1] merged, so there's a lower barrier to entry when it comes to implementing alternative scheduling policies (eBPF vs in-kernel). It's also much faster to iterate user-space if you don't have to upgrade kernels every time, especially in large fleet deployment setups where AB testing is available. On a more controversial note, I trust more Meta & Google engineers proposing alternative schedulers that have been properly AB tested on millions of servers running a wide range of heterogeneous software VS small-scale synthetic benchmarks even when run by experts/maintainers. [1]: https://lwn.net/ml/linux-kernel/20221130082313.3241517-1-tj@kernel.org/ https://lwn.net/ml/linux-kernel/20221130082313.3241517-1-tj@...