Re: [RFC PATCH] sched: add CONFIG_SCHED_EXT_RT_EXPERIMENTAL to move SCHED_EXT above SCHED_RR/SCHED_FIFO

[Christian Loehle <christian.loehle@arm.com>]

On 9/21/26 08:47, Tengfei Fan wrote:
> 
> On 4/15/2026 1:23 AM, Tejun Heo wrote:
>> Hello,
>>
>> On Tue, Apr 14, 2026 at 02:59:33PM +0200, Fredrik Boettger Bratberg wrote:
>>> A recent paper published in the 2025 Real-Time Systems Symposium (RTSS)
>>> "Enabling Flexible Scheduling in ROS 2", would presumably also benefint
>>> from this feature. The paper aims to address and improve the real-time
>>> capabilities of Robot Operating System 2 (ROS2). As part of their paper
>>> they implement an EDF using sched_ext. They do not explicitly address the
>>> issue of their EDF SCHED_EXT tasks effectively having a lower priority than
>>> SCHED_NORMAL, but it is a known limitation of the current sched_ext class
>>> placement
>> Isn't that mostly solvable by just not putting tasks in DL/RT and enabling
>> switching_all?
> 
> Sched_ext is an enhancement mechanism rather than a replacement for RT scheduling. RT scheduling continues to provide the latency guarantees, safety properties, and forward-progress guarantees required by the system. Additionally, the system must remain fully functional if sched_ext exits and falls back to the in-kernel scheduler. As a result, in real-world systems, assuming that RT workloads can simply be eliminated is often not practical.
>>
>>> This change conditionally reorders sched_class selection such that, when
>>> enabled:
>>>
>>>    STOP > DL > EXT > RT > FAIR > IDLE
>> The problem is that RT being above EXT is required for safety as EXT depends
>> on RT superceding it for enable/disable path forward progress guarantee. If
>> you put EXT on top of RT, it's relatively easy to stall out the whole system
>> without any way to recover it.
> 
> Rather than requiring all RT tasks to be isolated from sched_ext, it may
> be beneficial to distinguish between recovery-critical RT tasks and
> non-critical RT tasks. Recovery-critical RT tasks would remain outside
> sched_ext control to guarantee safety and recoverability, while
> non-critical RT tasks could optionally be handed over to sched_ext.
> 
> This would provide a balance between robustness and flexibility. In
> practice, many RT tasks, particularly those with lower priorities, are
> used to satisfy latency requirements while still being tightly coupled
> with the scheduling behavior of other workloads. Allowing sched_ext to
> coordinate these tasks may result in better overall scheduling outcomes
> and workload-aware optimizations.
> 

And what's stopping users from doing this today?
I don't think the kernel would be able to decide which RT tasks are
'more critical' than others, and therefore the system administrator can
already downgrade those 'non-critical' RT tasks?