When Fairness is the Wrong Goal
CFS is excellent for general desktop and server use. But sometimes, fairness is exactly the wrong property.
Consider a computer controlling the anti-lock brakes of a car. When the brake sensor fires, the control process must respond within microseconds — not "whenever it's fair to do so." If the music player process happens to have a lower vruntime at that moment, the car's braking algorithm cannot wait its turn. Missing that deadline is not a performance problem; it is a safety failure.
For these scenarios, Linux provides Real-Time (RT) Scheduling Classes: SCHED_FIFO, SCHED_RR, and SCHED_DEADLINE. Any process in an RT class has absolute priority over any CFS process. The moment an RT process becomes runnable (e.g., woken by a hardware interrupt), the kernel immediately preempts whatever CFS process is running and hands the CPU to the RT process.
RT processes are assigned a static priority from 1 (lowest RT) to 99 (highest RT). A SCHED_FIFO process at priority 50 will always preempt a SCHED_OTHER process, and will always be preempted by a SCHED_FIFO process at priority 51.
The RT Throttle: A Safety Net
A runaway RT process (e.g., an infinite loop in SCHED_FIFO) can starve all CFS processes and make the system appear frozen. Linux has a safety mechanism: RT throttling. By default, RT tasks are limited to 95% of CPU time per second (/proc/sys/kernel/sched_rt_runtime_us = 950000 out of sched_rt_period_us = 1000000). The remaining 5% is reserved for CFS tasks, ensuring you can still log in and kill the runaway process. This can be disabled (set to -1) on dedicated real-time systems.