An Overview of the Extensible Scheduler Class (sched_ext) in the Linux Kernel

The article introduces the Linux kernel's extensible scheduler class, sched_ext , which allows developers to modify scheduling policies using eBPF programs. It references a 2023 article on kernel innovations and positions sched_ext alongside the newly added EEVDF scheduler in Linux 6.6.

2.1 Basic Framework – The core of sched_ext consists of a BPF scheduler and a core scheduler. The core scheduler adds a new ext_sched_class with standard queue operations (enqueue, dequeue, preempt, select) plus numerous callbacks and eBPF interfaces for user‑space customization. Enabling the class requires setting CONFIG_SCHED_CLASS_EXT (and optionally CONFIG_EXT_GROUP_SCHED for group scheduling).

The core scheduler adds a new ext_sched_class that mirrors existing classes but introduces additional callbacks and a set of eBPF interfaces for user‑space interaction.

2.2 Extension Interfaces – The header include/linux/sched/ext.h declares the struct sched_ext_ops with callbacks such as init , select_cpu , enqueue , dispatch , etc. These allow developers to plug in custom logic without recompiling the whole kernel.

Key source files:

include/linux/sched/ext.h – ops interface declarations and core data structures.

kernel/sched/ext.h – ordinary function interfaces and flags.

kernel/sched/ext.c – implementation of the core ops.

Tools for examples:

tools/sched_ext/scx_central.c – central scheduler loading and monitoring.

tools/sched_ext/scx_central.bpf.c – concrete BPF policy implementation.

2.3 Core Data Structures – Each task in sched_ext is represented by struct sched_ext_entity . Dispatch queues are managed by struct scx_dispatch_q . These structures enable both per‑CPU (local) and global dispatch queues.

2.4 Kernel Scheduling Logic

The class defines its priority (lower than rt_sched_class and fair_sched_class ) and integrates with the existing scheduler hierarchy. Tasks can be placed into either built‑in dispatch queues (local or global) or user‑created queues via BPF. The scheduling flow involves two main phases: dispatch (moving tasks from a global queue to a local queue) and consume (executing tasks from the local queue).

Key points include:

Synchronization overhead: dispatch queues require an additional lock beyond the per‑CPU runqueue lock.

Load balancing: global queues can improve balance across CPUs compared to per‑CPU runqueues.

Load tracking: per‑CPU runqueues provide immediate load information, which global queues lack.

2.5 BPF Scheduler Application Example

The tools/sched_ext/ directory contains a central scheduler example. Its design highlights:

One central CPU makes scheduling decisions for all other CPUs.

Tickless operation with unlimited time slices.

Kthread‑driven preemption and kick‑based task migration.

Ops implementation details:

ops.init – Switches all NORMAL tasks to EXT , creates a fallback dispatch queue, and starts a 1 ms timer to monitor task slices and trigger kicks.

ops.select_cpu – Returns the user‑specified central CPU.

ops.enqueue – Places Kthreads into a local DSQ with preempt flag; other tasks go to a BPF map or fallback DSQ, with kicks issued as needed.

ops.dispatch – Handles cases where both built‑in local and global queues are empty, pulling tasks from fallback or central queues and performing kicks.

The central scheduler demonstrates high flexibility but also shows drawbacks such as lack of weight‑based scheduling and heavy central‑CPU load.

Conclusion

sched_ext offers a powerful, extensible framework for custom kernel scheduling, leveraging eBPF to tailor policies for diverse workloads. While it provides great adaptability, its adoption faces community resistance and requires careful consideration of trade‑offs.

References:

Sched Ext source code: https://github.com/sched-ext/sched_ext/tree/sched_ext

Various LWN articles on eBPF, kernel ops structures, and the extensible scheduler class are listed in the original document.