← Previous Lecture
|
Next Lecture →

What You Will Learn

• What Linux scheduler classes are and why the scheduler was made modular
• All six scheduler classes in modern kernels and their strict priority order
• How scheduling policies like SCHED_FIFO, SCHED_RR, SCHED_DEADLINE, SCHED_OTHER, and SCHED_EXT map onto scheduler classes
• What changed since older kernels: EEVDF replacing CFS, and sched_ext arriving in kernel 6.12
• How to inspect and change a thread’s scheduling policy from the command line

Prerequisites

• Basic C programming and comfort reading kernel-style code
• Understanding of processes and threads in Linux (covered earlier in this free Linux kernel development course)
• A Linux machine (any recent distribution with kernel 6.x or newer) to try the commands

Why Linux Scheduler Classes Exist: The Modular Design

Back in October 2007, kernel release 2.6.23 restructured the scheduler around a simple but powerful idea: instead of one giant algorithm trying to satisfy every kind of workload, the core scheduler became a thin dispatcher sitting on top of several self-contained scheduler classes. Each class implements its own policy logic behind a common interface. This work, led by Ingo Molnar and other core developers, is the foundation the scheduler still stands on today.

The design is essentially object-oriented, even though the kernel is written in C. Each class is described by a struct sched_class containing function pointers – methods such as “enqueue a task”, “dequeue a task”, and “pick the next task to run”. The core scheduler never needs to know how a class chooses its next thread; it simply asks each class in priority order.

One word of caution about the term modular here: it means the scheduler code is cleanly separated into pluggable class implementations compiled into the kernel image. It has nothing to do with loadable kernel modules (LKMs). You cannot insmod a scheduler class. Interestingly though, the newest class, sched_ext, gets remarkably close to that dream by letting you load scheduling policies as BPF programs at runtime – more on that below.

The Six Linux Scheduler Classes in Modern Kernels

Older material (based on kernels around 5.4) lists five classes. Modern kernels – from 6.12 onwards, including the current 6.18 LTS and 7.x stable series – have six scheduler classes when the extensible scheduler is enabled. Here they are, from highest to lowest priority:

The corresponding declarations live in the scheduler’s internal header. A simplified view from a current kernel source tree:

/* kernel/sched/sched.h (simplified, modern 6.x/7.x kernels) */
extern const struct sched_class stop_sched_class;
extern const struct sched_class dl_sched_class;
extern const struct sched_class rt_sched_class;
extern const struct sched_class fair_sched_class;
extern const struct sched_class ext_sched_class;   /* kernel 6.12+, CONFIG_SCHED_CLASS_EXT */
extern const struct sched_class idle_sched_class;

What Changed Since Kernel 5.4? A Quick Modernization Table

If you learned Linux scheduler classes from older books, the following table summarizes exactly what has moved on. This is one of the most important sections of this free Linux kernel development course lecture, because interviews frequently probe whether you know the current design:

Scheduling Policies vs Linux Scheduler Classes

Beginners often confuse two related concepts, so let’s separate them clearly:

• A scheduling policy is a user-visible label attached to a thread. You can query and change it with system calls or utilities. Examples: SCHED_OTHER, SCHED_FIFO, SCHED_RR, SCHED_BATCH, SCHED_IDLE, SCHED_DEADLINE, and SCHED_EXT.
• A scheduler class is the internal kernel implementation that services one or more policies.

Every thread has exactly one policy at any moment (though it can be changed at runtime), and that policy determines exactly one scheduler class. Inside each thread’s task structure (struct task_struct), the policy member records the policy, and a const struct sched_class *sched_class pointer records which class currently owns the thread.

Note that SCHED_EXT tasks are only truly serviced by the extensible class while a BPF scheduler is actually loaded; otherwise the kernel gracefully falls back to fair-class behavior. This safety net is a deliberate design choice – a buggy BPF scheduler can be ejected by the kernel at any time without hanging the machine.

Hands-On: Inspecting Policies on a Live System

Theory becomes real when you poke at a running kernel. All the commands below are safe to run on your laptop and are the same tools you will use throughout this free embedded systems course track.

View the policy and real-time priority of every thread:

ps -eLo pid,tid,cls,rtprio,comm | head -20

The cls column shows TS for normal (time-sharing) tasks, FF for SCHED_FIFO, RR for round-robin, DLN for deadline tasks, and IDL for idle-policy tasks. On a typical desktop, almost everything is TS, with a handful of FF threads belonging to kernel subsystems.

Query one specific process using chrt:

chrt -p 1
# pid 1's current scheduling policy: SCHED_OTHER
# pid 1's current scheduling priority: 0

Promote a thread to soft real-time (be careful – a runaway FIFO task at high priority can starve your desktop):

sudo chrt -f -p 50 <PID>     # SCHED_FIFO, priority 50
sudo chrt -r -p 30 <PID>     # SCHED_RR, priority 30
sudo chrt -o -p 0  <PID>     # back to SCHED_OTHER

Programmatically, the modern interface is sched_setattr()/sched_getattr(), which supersedes the older sched_setscheduler() because it can also express deadline parameters:

#include <linux/sched.h>
#include <sys/syscall.h>
#include <unistd.h>

struct sched_attr attr = {
    .size        = sizeof(attr),
    .sched_policy = SCHED_FIFO,
    .sched_priority = 50,
};

/* glibc has no wrapper; invoke the raw syscall */
if (syscall(SYS_sched_setattr, 0 /* self */, &attr, 0) == -1)
    perror("sched_setattr");

Common Mistakes and Troubleshooting

• Assuming CFS still runs your desktop. Since kernel 6.6, the fair class implements EEVDF. Many CFS-era tunables (like sched_latency_ns) no longer exist.
• Confusing modular classes with kernel modules. Scheduler classes are compiled in; only sched_ext policies load at runtime, and those are BPF programs, not .ko files.
• Setting SCHED_FIFO priority 99 casually. You can starve critical kernel threads and freeze the system. Start low, and prefer SCHED_RR while experimenting.
• Forgetting privileges. Raising a thread into the RT or deadline class requires CAP_SYS_NICE or appropriate RLIMIT_RTPRIO limits; otherwise sched_setattr() fails with EPERM.
• Looking for tunables in the old place. On modern kernels, check /sys/kernel/debug/sched/ (requires debugfs mounted) instead of /proc/sys/kernel/ for most scheduler knobs.

Best Practices

• Keep normal applications in the fair class; reach for RT or deadline policies only when you have measured a genuine latency requirement.
• When you do use SCHED_FIFO/SCHED_RR, always design a bounded execution path – RT threads must voluntarily sleep or yield.
• Use SCHED_DEADLINE for periodic control loops in embedded Linux; it gives mathematically-backed guarantees that static priorities cannot.
• For experimentation and learning, sched_ext is a superb sandbox: you can watch your own scheduling decisions play out without rebuilding the kernel.

Key Takeaways

• The Linux scheduler is a thin core plus pluggable scheduler classes, a design introduced in kernel 2.6.23 and still evolving.
• Modern kernels have six classes in strict priority order: stop → deadline → real-time → fair → ext → idle.
• Each thread carries one policy and one class at a time, both changeable at runtime.
• EEVDF (kernel 6.6) replaced CFS inside the fair class; sched_ext (kernel 6.12) made scheduling policies runtime-loadable via BPF.

Frequently Asked Questions (FAQ)

Conclusion

Linux scheduler classes turn a potentially monstrous scheduling problem into a clean, layered design: a tiny core that asks a fixed priority ladder of classes “do you have work?”, and specialized classes that each solve one job well. Understanding this structure is essential groundwork for kernel developers, embedded engineers, and anyone preparing for Linux internals interviews. In Part 2B of this free Linux kernel development course, we go one level deeper: how pick_next_task() actually walks the classes, and how per-CPU runqueues are organized in modern kernels.