Re: [RESEND RFC] sched_ext: Support RT task within sched_ext
From: Tengfei Fan
Date: Fri Oct 23 2026 - 06:32:53 EST
On 10/16/2026 12:37 AM, Tejun Heo wrote:
Hello, Tengfei.
On Thu, Oct 15, 2026 at 08:47:12PM +0800, Tengfei Fan wrote:
Possible optionsIsn't an obvious option to just make them non-RT? The load tracking aside,
----------------
One option is to let sched_ext schedule some explicitly selected RT
threads together with SCX tasks.
This could let one scheduler choose CPUs for both selected RT
threads and SCX tasks.
For example, if other cpu is idle, or running a low priority scx task,
or running a low load scx task, an RT task could use that CPU instead
of a CPU running an important high load SCX task. This could reduce CPU
contention for the frame important KPI and help balance RT and SCX tasks
across CPUs.
Such placement should remain a preference rather than a fixed
rule. It must respect the RT task's priority, timing needs, and
allowed CPU mask. The other CPU must also have enough capacity.
It could also allow RT and SCX tasks to use the same utilization
model. We would like to study whether this can make the load
signal more stable and reduce late CPU frequency changes.
Another option is to keep all RT tasks in the native RT
class, but provide enough information for the two schedulers
to better coordinate CPU placement. However, this would also require
placement and load synchronization between the RT scheduling class
and the sched_ext class.
After the LPC discussion, we'd like to explore option 1 and use
BPF-only hooks to achieve current needed RT tasks within scx class.
One option is to have all RT tasks with a priority lower than the SCX
helper thread go into sched_ext.
Migration thread, sched-ext enable/disable threads and IRQ threads need
to remain outside sched_ext. With this option, we will need to verify
more common scenarios. We can explore the first option first.
the fundamental problem seems like you don't want these threads to be always
prioritized over some of the OTHER class tasks, which definitionally means
that they shouldn't be RT, no?
Thanks.
We still want these selected RT application threads to retain their RT behavior. For example, if an important SCX task is running on one CPU while another suitable CPU is running a less important SCX task, we would prefer the selected RT task to preempt the less important SCX task. However, this is only a placement preference. If there is no better CPU available, the selected RT task should still be able to preempt an important SCX task.
Following Andrea's suggestion, we will first explore preserving the requested RT policy/priority as metadata, making these selected application threads non-RT, and handling them within sched_ext using this metadata for scheduling decisions. We will evaluate whether this can provide the behavior we need while keeping threads that require native RT behavior in the RT class.