Revisiting the kernel's preemption models (part 1)

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

> > However, I can see the need for that, i.e. in changing a battleship's computer's mode from "normal operation" in which performance and computing efficiency is preferred to a "battle mode" or "condition red" where latency would be a paramount for ship's survival.

> Either you're application is real-time critical or it's not. Even in your case "Switching to battle mode" would be time-critical, wouldn't it?

Actually if you really mean real-time, no it wouldn't.

The term "real-time" is, sadly, horribly abused and often confused with "online".

We basically have three - conflicting - targets we may want to optimise for.

(1) Batch: Do as much work as possible, as efficiently as possible, and if some jobs take forever, well they do.

(2) Online: Don't keep the user waiting. If that means background tasks get held up because we're wasting time checking to see if the user wants anything, well so be it.

(3) Real time: We have deadlines. They MUST be met. We might have a job that only takes 20 minutes, but it needs to be completed AT midnight tomorrow. Or say we're making jam. Finish too early, and the jam will run away off the toast. Finish too late and we won't be able to get it out of the pan and into the jars. Basically, for real-time it doesn't matter when the deadline is, it matters that you can't move it.

So take your battleship. Real-time doesn't mean the transition will happen quickly. Real-time means you know that if you engage real-time mode, the cascade of actions to change OS state will take, say. pretty much exactly five minutes (or whatever time that is).

Cheers,
Wol

Revisiting the kernel's preemption models (part 1)

Posted Sep 22, 2023 18:11 UTC (Fri) by cloehle (subscriber, #128160) [Link] (1 responses)

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.