MorphSched uses AI to build workload-specific Linux schedulers

A scheduler tailored to the workload

A Linux scheduler allocates processor time among runnable tasks. Its decisions must balance competing demands: an interactive service needs prompt responses, while background computation needs enough processor time to keep making progress.

In the MorphSched preprint, researchers at Zhejiang University describe a system that uses large language models to generate schedulers for particular combinations of applications, background interference and machines. It is not intended to replace Linux’s default EEVDF scheduler with one universally better policy.

The system builds on Linux’s sched_ext framework, which allows custom scheduling policies to run through eBPF programs without replacing the core kernel scheduler. This makes experimentation more accessible, but writing a working policy still requires coordinated components: kernel-side scheduling code, user-space control software and interfaces connecting them.

From measurements to generated code

MorphSched first measures the target workload under EEVDF. Those measurements establish relative performance objectives rather than a fixed target that might be unrealistic on a particular machine.

For services such as Redis, the main objective is lower p99 latency: the response-time threshold below which 99% of measured requests fall. For the CPU-focused Sysbench benchmark, the objective is higher throughput. The evaluation also imposes a background-throughput requirement, intended to prevent a generated scheduler from improving the foreground application simply by starving other work.

The language model then translates the proposed scheduling strategy into a structured intermediate description. This specifies rules such as how tasks enter queues and receive priority. MorphSched establishes shared interfaces before separate generation threads produce Rust user-space code and BPF C scheduling code within a fixed project scaffold.

Its search separates two problems. Compilation, verification and runtime failures trigger implementation repairs. A policy that runs safely but misses its performance objective instead prompts changes to the scheduling strategy. A repair graph supports rollback from unsuccessful fixes, while a strategy memory pool retains potentially useful ideas from earlier attempts.

This is therefore an iterative generate-and-test process, not a demonstration that an unconstrained model can write reliable kernel software in one attempt.

What the benchmarks show

The researchers evaluated 120 configurations spanning four foreground workloads, five machine settings, and six execution conditions: running alone or alongside one of five background interferers. Experiments used Ubuntu 24.04 with Linux 6.17.0-29-generic, on one physical machine and four virtual-machine configurations.

Each reported measurement was averaged across three independent runs, with workloads restarted and schedulers reloaded between runs. The authors report that the generated schedulers compiled, passed eBPF verification, loaded and remained stable during benchmark execution, without manual edits to generated source code.

Across the configurations, they report an average foreground improvement of 26.5% and a maximum of 87.3% over EEVDF. These percentages combine different measures: p99 latency reductions for Redis, Nginx and memcached, and throughput increases for Sysbench. They should not be read as a uniform increase in overall computer speed.

There is also an important inconsistency in the manuscript. Although its prose says every configuration improved, the performance heatmap includes negative entries, indicating regressions. The results therefore do not support an unqualified claim of improvement in every case. A separate table also shows some regressions in average response latency.

Comparisons with five hand-written sched_ext schedulers covered six selected workload/interference cases. MorphSched achieved the highest Sysbench throughput in those comparisons, but some hand-written policies delivered better Redis p99 latency in particular cases.

Protecting foreground work has tradeoffs

One Redis case illustrates the intended balance. The generated policy gave Redis tasks a bounded wakeup bonus and penalized identified CPU interferers only while Redis was recently active. Other tasks retained a shared dispatch path.

Redis p99 latency fell from 14.087 milliseconds to 10.879 milliseconds, a 22.8% reduction. The background CPU workload retained 89.2% of its EEVDF throughput. That is evidence of a tradeoff, rather than a performance gain with no cost to competing work.

Experimental success is not a safety proof

The authors explicitly acknowledge that compilation, eBPF verification and runtime monitoring do not constitute a formal correctness proof. Longer stress tests and deployment-specific safeguards would be needed before production use.

The study primarily considers one foreground target with one background interferer, not a complex mix of services with interacting requirements. Generation also depends on the language model, supplied API knowledge and kernel version. Although measurements were repeated, the main performance figures omit error bars, limiting readers’ ability to judge variability.

The preprint offers evidence that constrained AI generation can help explore specialized scheduling policies. It does not establish universal performance improvements or production-ready reliability.