A realtime developer's checklist

Posted Nov 17, 2020 3:58 UTC (Tue) by glenn (subscriber, #102223)
Parent article: A realtime developer's checklist

> ...mixing scheduling classes is "strange".

On the RT kernel as-is, this is strange. However, you should be able to schedule unrelated threads on disjoint sets of CPUs under different scheduling policies (i.e., a SCHED_FIFO cluster and a SCHED_DEADLINE cluster).

There are theoretical grounds for mixing SCHED_FIFO- and SCHED_DEADLINE-style schedulers on shared CPUs. This technique is used in some mixed-criticality schedulers. These schedulers also consider the application-level importance of real-time threads, in addition to scheduling priority (application importance != scheduling priority!!). For example, a simple mixed-criticality scheduler might schedule application-critical threads with fixed-priorities (e.g., SCHED_FIFO) on single CPUs, while scheduling less-application-critical, but still real-time, threads with SCHED_DEADLINE and let these migrate among all CPUs. We can't do this today with the current Linux scheduler, since SCHED_DEADLINE preempts SCHED_FIFO. This could be done if we were able to reorder the relative priority of the scheduling classes, or simply let SCHED_FIFO preempt SCHED_DEADLINE. This would weaken (violate) the SCHED_DEADLINE admission test guarantees, but I find this feature less compelling than support for a flavor of mixed-criticality.

A realtime developer's checklist

Posted Nov 17, 2020 14:21 UTC (Tue) by Wol (subscriber, #4433) [Link] (2 responses)

> This would weaken (violate) the SCHED_DEADLINE admission test guarantees, but I find this feature less compelling than support for a flavor of mixed-criticality.

So you're quite happy for a nuclear power plant to blow up because an operator wanted to play a shoot-em-up game on the same computer?

The whole point of Real Time is that deadlines are deadlines.As in "you're dead if they're missed".

I agree mixed criticality would be lovely, but not at the expense of true real-time operation.

Cheers,
Wol

A realtime developer's checklist

Posted Nov 17, 2020 15:46 UTC (Tue) by gus3 (guest, #61103) [Link]

> So you're quite happy for a nuclear power plant to blow up because an operator wanted to play a shoot-em-up game on the same computer?

If the operator wants to play a shoot-em-up while on duty, then the priority inversion is taking place within the operator, not the computer.

> mixed criticality would be lovely, but not at the expense of true real-time operation.

If the constraints of RT can be satisfied in two different domains, whether cores or hosts, it's still RT. Just because they have different scheduling requirements, doesn't make either of them "fake RT".

A realtime developer's checklist

Posted Nov 17, 2020 17:20 UTC (Tue) by glenn (subscriber, #102223) [Link]

> So you're quite happy for a nuclear power plant to blow up because an operator wanted to play a shoot-em-up game on the same computer?

Actually, no. Quite the opposite. I make no such argument.

Mixed-criticality scheduling is a real field of study in real-time systems. It has wide applications in hard real-time environments. In the scheme I described, where SCHED_FIFO can preempt SCHED_DEADLINE, threads with hard real-time requirements are scheduled by SCHED_FIFO, while threads with soft real-time requirements (bounded deadline tardiness, in this case), are scheduled by SCHED_DEADLINE. These ideas are backed by solid real-time scheduling theory.

Mixed-criticality scheduling is not widely supported outside of research kernels, but it is becoming a centerpiece feature of the seL4 microkernel.

Let me defend my specific claim that the SCHED_DEADLINE admissions tests is not useful for many users. An admissions test is useful in an "open system," where the sysadmin (or system designer) cannot predict or control what what is run under the SCHED_DEADLINE policy. If I had to guess at who could benefit from an open linux-rt system, I would guess multi-media and gaming. Contrast this with a "closed system," where the sysadmin/system-designer controls everything that runs on the system. Who are these users? Robots (including autonomous vehicles), high-frequency trading systems, and I would argue pro-audio tools. Admissions tests are less useful in a closed system because the system-designer can account for CPU requirements ahead of time. After all, they already know enough about their execution time requirements provide execution-time parameters to SCHED_DEADLINE. In short, there is no need for an admissions test in a closed system. And this is where it gets in the way of more robust real-time scheduling: Linux could support a flavor of mixed-criticality scheduling if it did away with the admissions test that no one is really using!

Please note that elimination of the admissions test does not mean eliminating budget enforcement. Budget enforcement can still be used to isolate run-away threads.

A realtime developer's checklist

Posted Nov 17, 2020 16:21 UTC (Tue) by Jonno (subscriber, #49613) [Link]

> We can't do this today with the current Linux scheduler, since SCHED_DEADLINE preempts SCHED_FIFO. This could be done if we were able to reorder the relative priority of the scheduling classes, or simply let SCHED_FIFO preempt SCHED_DEADLINE. This would weaken (violate) the SCHED_DEADLINE admission test guarantees, but I find this feature less compelling than support for a flavor of mixed-criticality.

In an ideal world, the scheduler would be able to tell whether it would be possible to meet all deadlines even if no SCHED_DEADLINE tasks gets scheduled until the next scheduler tick, and if so give priority to SCHED_FIFO, while still giving priority to SCHED_DEADLINE when necessary to meet deadlines.

Unfortunately that would require doing admission control every time the scheduler has to pick a task (rather than just when changing the scheduling policy of a task) which would probably have a prohibitively high overhead.