Revisiting the kernel's preemption models (part 1)

Posted Sep 22, 2023 18:11 UTC (Fri) by cloehle (subscriber, #128160)
In reply to: Revisiting the kernel's preemption models (part 1) by Wol
Parent article: Revisiting the kernel's preemption models (part 1)

I'm aware of the distinction, but maybe my imagination is just lacking, but if the system is always used in 'non-RT'-mode until RT mode is needed, but that switch cannot be bound by a latency, what use case is there?

The critical path for the RT reaction just increased from signal -> RT reaction (with a defined latency upper bound for RT systems) to signal -> switch to RT-mode -> RT reaction (no upper bound anymore).

Or how does the system know when to be in RT-mode?

Revisiting the kernel's preemption models (part 1)

Posted Sep 22, 2023 18:41 UTC (Fri) by mb (subscriber, #50428) [Link]

> Or how does the system know when to be in RT-mode?

There is no such thing as a "system RT mode".

The kernel just provides mechanisms for tasks to be scheduled with various RT properties (e.g. RT-Fifo, RT-RR, deadline sched, locking latency guarantees, etc..).
But that does *not* mean that every task suddenly becomes a RT task. In fact, in a RT system almost all tasks usually still run in normal scheduling mode.
Normal tasks on a RT kernel basically just behave like tasks on a full-preempt kernel. Just with a little bit more overhead here and there. (I'm simplifying for the sake of briefness)

A task has to opt-in to being RT. (And selecting a RT sched class is only part of that. There are many many many more things to consider.)

And that's why it doesn't make sense at all to switch between full-preempt and RT-preempt during runtime. That would just add even more overhead with no added benefit. If your task doesn't need RT, then don't schedule it in a RT class.