IMPORTANT: This repository includes example schedulers used for illustration purposes, or as a jumping-off point for
prototyping. The definitive versions of all chedulers in this repository are in the upstream kernel under the tools/sched_ext
directory. Please do not submit PRs for new features for the schedulers here. If you find any issues or bugs, please
submit a patchset in the upstream sched_ext mailing list.
sched_ext is a Linux kernel feature
which enables implementing kernel thread schedulers in BPF and dynamically
loading them. This repository contains various scheduler implementations and
support utilities.
sched_ext enables safe and rapid iterations of scheduler implementations, thus
radically widening the scope of scheduling strategies that can be experimented
with and deployed; even in massive and complex production environments.
You can find more information, links to blog posts and recordings, in the wiki. The following are a few highlights of this repository.
- The
scx_layeredcase study concretely demonstrates the power and benefits ofsched_ext. - For a high-level but thorough overview of the
sched_ext(especially its motivation), please refer to the overview document. - For a description of the schedulers shipped with this tree, please refer to the schedulers document.
- The following video is the
scx_rustlandscheduler which makes most scheduling decisions in userspaceRustcode showing better FPS in terraria while kernel is being compiled. This doesn't mean thatscx_rustlandis a better scheduler but does demonstrate how safe and easy it is to implement a scheduler which is generally usable and can outperform the default scheduler in certain scenarios.
scx_rustland-terraria.mp4
sched_ext is supported by the upstream kernel starting from version 6.12. Both
Meta and Google are fully committed to sched_ext and Meta is in the process of
mass production deployment. See #kernel-feature-status for more details.
In all example shell commands, $SCX refers to the root of this repository.
All that's necessary for running sched_ext schedulers is a kernel with
sched_ext support and the scheduler binaries along with the libraries they
depend on. Switching to a sched_ext scheduler is as simple as running a
sched_ext binary:
root@test ~# cat /sys/kernel/sched_ext/state /sys/kernel/sched_ext/*/ops 2>/dev/null
disabled
root@test ~# scx_simple
local=1 global=0
local=74 global=15
local=78 global=32
local=82 global=42
local=86 global=54
^Zfish: Job 1, 'scx_simple' has stopped
root@test ~# cat /sys/kernel/sched_ext/state /sys/kernel/sched_ext/*/ops 2>/dev/null
enabled
simple
root@test ~# fg
Send job 1 (scx_simple) to foreground
local=635 global=179
local=696 global=192
^CEXIT: BPF scheduler unregisteredscx_simple
is a very simple global vtime scheduler which can behave acceptably on CPUs
with a simple topology (single socket and single L3 cache domain).
Above, we switch the whole system to use scx_simple by running the binary,
suspend it with ctrl-z to confirm that it's loaded, and then switch back
to the kernel default scheduler by terminating the process with ctrl-c.
For scx_simple, suspending the scheduler process doesn't affect scheduling
behavior because all that the userspace component does is print statistics.
This doesn't hold for all schedulers.
In addition to terminating the program, there are two more ways to disable a
sched_ext scheduler - sysrq-S and the watchdog timer. Ignoring kernel
bugs, the worst damage a sched_ext scheduler can do to a system is starving
some threads until the watchdog timer triggers.
As illustrated, once the kernel and binaries are in place, using sched_ext
schedulers is straightforward and safe. While developing and building
schedulers in this repository isn't complicated either, sched_ext makes use
of many new BPF features, some of which require build tools which are newer
than what many distros are currently shipping. This should become less of an
issue in the future. For the time being, the following custom repositories
are provided for select distros.
scx
|-- scheds : Sched_ext scheduler implementations
| |-- include : Shared BPF and user C include files
| |-- vmlinux : vmlinux.h header
| |-- c : Example schedulers - userspace code written C
Use make to build all the schedulers in this repo.
Dependencies:
clang: >=16 required, >=17 recommendedlibbpf: >=1.2.2 required, >=1.3 recommendedbpftool: Usually available inlinux-tools-commonor similar packageslibelf,libz,libzstd: For linking against libbpfpkg-config: For finding system libraries
The kernel has to be built with the following configuration:
CONFIG_BPF=yCONFIG_BPF_SYSCALL=yCONFIG_BPF_JIT=yCONFIG_DEBUG_INFO_BTF=yCONFIG_BPF_JIT_ALWAYS_ON=yCONFIG_BPF_JIT_DEFAULT_ON=yCONFIG_SCHED_CLASS_EXT=y
The scx/kernel.config file includes all required and other recommended options for using sched_ext.
You can append its contents to your kernel .config file to enable the necessary features.
$ cd $SCX
$ make all # Build all C schedulers
$ make install INSTALL_DIR=~/bin # Install to custom directoryBinary location is build/scheds/c/scx_simple
Both make and cargo support these environment variables for BPF compilation:
BPF_CLANG: The clang command to use. (Default:clang)BPFTOOL: The bpftool command to use. (Default:bpftool)CC: The C compiler to use. (Default:cc)
Examples:
# Use specific clang version for C schedulers
$ BPF_CLANG=clang-17 make all
# Use specific clang version for Rust schedulers
$ BPF_CLANG=clang-17 cargo build --release
# Use clang for C compilation and system bpftool
$ CC=clang BPFTOOL=/usr/bin/bpftool make allWith the implementation of scx_stats, schedulers no longer display statistics by default. To display the statistics from the currently running scheduler, a manual user action is required.
Below are examples of how to do this.
- To check the scheduler statistics, use the
$ scx_SCHEDNAME --monitor $INTERVALfor example 0.5 - this will print the output every half a second
$ scx_bpfland --monitor 0.5Some schedulers may implement different or multiple monitoring options. Refer to --help of each scheduler for details.
Most schedulers also accept --stats $INTERVAL to print the statistics directly from the scheduling instance.
Want to learn how to develop a scheduler or find some useful tools for working with schedulers? See the developer guide for more details.
We aim to build a friendly and approachable community around sched_ext. You
can reach us through the following channels:
GitHub: https://github.com/sched-ext/scxDiscord: https://discord.gg/b2J8DrWa7tMailing List: sched-ext@lists.linux.dev (for kernel development)
We also hold weekly office hours every Tuesday. Please see the #office-hours
channel on Discord for details.
There are articles and videos about sched_ext, which helps you to explore
sched_ext in various ways. Following are some examples:
Sched_extYT playlist- LWN: The extensible scheduler class (February, 2023)
- arighi's blog: Implement your own kernel CPU scheduler in Ubuntu with
sched_ext(July, 2023) - David Vernet's talk : Kernel Recipes 2023 -
sched_ext: pluggable scheduling in the Linux kernel (September, 2023) - Changwoo's blog:
sched_ext: a BPF-extensible scheduler class (Part 1) (December, 2023) - arighi's blog: Getting started with
sched_extdevelopment (April, 2024) - Changwoo's blog:
sched_ext: scheduler architecture and interfaces (Part 2) (June, 2024) - arighi's YT channel:
scx_bpflandLinux scheduler demo: topology awareness (August, 2024) - David Vernet's talk: Kernel Recipes 2024 - Scheduling with superpowers: Using
sched_extto get big perf gains (September, 2024) - arighi's talk: Kernel Recipes 2025 - Schedule Recipes (September, 2025)