Blog: New: sched_ext support, optional and off by default
Key points
MocaccinoOS will enable sched_ext in both its Stable and LTS kernels starting with the next kernel update. Users can then load alternative CPU schedulers written as BPF programs without rebuilding the kernel. Nothing changes unless a user starts a scheduler, so systems keep the default behaviour out of the box.
What changed
- sched_ext, available in Linux since 6.12, lets a CPU scheduler be loaded from user space as a BPF program on a running system, with no reboot or kernel rebuild.
- The default scheduler remains EEVDF (Earliest Eligible Virtual Deadline First), which took over from CFS in kernel 6.6.
- If the kernel detects a scheduling problem, it switches back to the default scheduler on its own.
- Enabling sched_ext required supporting kernel options: BTF type information, function tracing hooks and some BPF settings.
Cost for all users
- The kernel grows by a few megabytes of extra type information.
- The project expects the tracing hooks to have negligible overhead when tracing is not in use.
How to try it
- Update to the new kernel, reboot, install the scheduler collection, then start a scheduler from a terminal:
sudo luet install apps/scx
sudo scx_lavd- From a second terminal, check that it is active with the two commands below. The state file should read
enabled:
cat /sys/kernel/sched_ext/state
cat /sys/kernel/sched_ext/root/ops- Ctrl+C stops the scheduler and returns the kernel to the default. A scheduler started this way does not persist across a reboot.
- The package comes from the sched-ext/scx project on GitHub.
What has been tested
scx_lavd, aimed at gaming and interactive use, andscx_bpfland, aimed at low response times, both load on MocaccinoOS kernels, and the kernel reports them as active.- That is all the project has verified. It has run no benchmarks of its own and has not tried the other schedulers in the scx collection.
Performance expectations
- The
scx_lavddevelopers report higher frame rates in games than the default scheduler, with fewer stutters and slightly lower power use, measured on their own workloads. - A third-party benchmark from June 2026 on throughput workloads such as compiling and stress tests found EEVDF essentially tied for fastest.
scx_lavdtook about 8% longer in total. - In GPU-bound games, the CPU scheduler has little effect.
- Results depend on the workload: possibly smoother frame times under load, possibly no visible difference, possibly a slowdown. The project says a lack of improvement is an expected outcome, not a bug.
Further reading
- The post links to the kernel documentation on the Extensible Scheduler Class, LWN coverage of sched_ext and the schedulers built on it, and the sched-ext/scx repository.
Summary by DistroNews, based on the original post.
Opt-in CPU Schedulers: What We’re Adding, and What to Expect The CPU scheduler is the part of the kernel that decides which program runs on which core, and when. Linux has a built-in answer to that question: a scheduler called EEVDF (Earliest Eligible Virtual Deadline First), which replaced the older CFS in kernel 6.6. For most people it’s a good one. But different workloads want different trade-offs, and until recently, trying a different scheduler meant patching and rebuilding your kernel. With the next kernel update, that changes. Both our Stable and LTS kernels will ship with sched_ext enabled. What is sched_ext? sched_ext is a Linux kernel feature (available since 6.12) that lets a CPU scheduler be written as a small BPF program and loaded from user space while the system is running. No reboot, no kernel rebuild. It has a safety net built in: if the kernel detects a scheduling problem, it reverts to the default scheduler and carries on. 1 And nothing changes until you load a scheduler yourself. Out of the box, MocaccinoOS behaves exactly as before. What we changed The kernel configuration for sched_ext needs a few supporting options (BTF type information, function tracing hooks and a few BPF settings). That has a small cost for everyone: the kernel carries a few megabytes of extra type information, and the tracing hooks should be negligible when tracing isn’t in use. We think that’s a fair price for being able to offer this, but we’d rather say it than hide it. How to try it Update to the new kernel and reboot, then install the schedulers: $ sudo luet install apps/scx Start one from a terminal, for example: $ sudo scx_lavd You can check that it’s active from another terminal: $ cat /sys/kernel/sched_ext/state enabled $ cat /sys/kernel/sched_ext/root/ops Press Ctrl+C to stop it and the kernel goes back to the default scheduler. A scheduler started this way also stops at reboot.
This is the opening of the story. The full text is on the original page.
Read the original at mocaccino.org