BPF Opens Door to Linux Extensible Scheduling (Maybe with Rust!)

Hacking around over the holidays, Canonical Linux kernel engineer Andrea Righi wrote a Linux scheduler in Rust (and some help from the Berkeley Packet Filter) that in early tests outperforms the kernel’s own stock scheduler.

“I’m pretty shocked to see that it doesn’t just work, but it can even outperform the default Linux scheduler (EEVDF) with certain workloads” such as gaming, he wrote on X.

Though a prototype, it accomplished its mission, namely to “show that it’s possible to implement working schedulers running in user-space, that even outperform the default Linux scheduler under certain particular conditions.”

An accompanying video shows a simple computer game moving at 25-30 frames-per-second (fps), while a kernel is being compiled on the machine. Switching over to Righi’s scheduler bumped up the action to around 60 frames per second, all while the kernel kept compiling:

Does Linux Need More Schedulers?

The Linux kernel scheduler does the important work of doling out to applications slices of CPU time, with the goal of ensuring each application gets its fair share of time, often through the use of the Completely Fair Scheduler (CFS) algorithm.

Though Linux’s one-size-fits-all scheduler may need to be updated for the more complex heterogenous environments of today’s distributed computing environs.

Righi’s scx_rustland is an implementation of sched_ext, an experimental Linux kernel feature for running kernel thread schedulers that can be created, and loaded in, with the Berkeley Packet Filter (implemented in the kernel as eBPF). It was written by a group of engineers from Meta and Google, with the help of others in the kernel community, with the hopes that it one day will be included upstream in the core Linux kernel.

“It was only a matter of time before somebody tried to bring BPF to the kernel’s CPU scheduler,” commented LWN.Net (formerly Linux Weekly News) chief Jonathan Corbett in February, soon after the technology was introduced.

A BPF-based scheduler makes sense for a number of reasons, Corbett explained: it is easier to experiment with new approaches to scheduling. Today’s systems are far more complex than in decades in past, and so require more domain-specific and niche scheduling solutions (i.e. schedulers for gaming and those for networking). It could also give developers a way to tweak the CPU for their own applications.

Not everyone in the Linux community is on board with the idea of dynamic scheduling, it should be noted, including the Linux head honcho himself Linus Torvalds. Linux scheduler maintainer Peter Zijlstra, commenting on the first release of sched_ext, remarked “I hate all of this,” adding that Torvalds had nixed previous attempts at alternate schedulers, given the complexity they introduce.

Both AMD and Google have also introduced proposals for alternative schedulers.

…But Could Rust Be Faster than C for Linux?

Over the past few years, there has been growing interest in using the memory-safe Rust programming language for mission-critical work, such as building operation system kernels, displacing C that can inadvertently introduce security bugs. Torvalds is open to the use of Rust in the kernel.

So it made sense that when Linux news site Phoronix covered Righi’s work in a post it would focus on the use of Rust, with a headline that screamed: “Rust-Written Linux Scheduler Showing Promising Results for Gaming Performance.”

But the post generated a fair amount of debate not on schedulers, but on whether or not using Rust over C offered any inherent advantages.

“What does [the scheduler] do differently that causes it to actually perform differently? Is it because it is incomplete or is it actually because it is genuinely better? Because I can’t believe that Rust by itself is better than C,” commented Theprimeagen in a highly-viewed commentary video on Twitch. “What can be done in Rust what can not be done in C?”

Schedulers are all about trade-offs, he noted. Obviously, this scheduler is tweaked for gaming, at the expense of some other functionality.

“All this news tells us is that a Rust implementation can compare to a C implementation in this field,” wrote pseudocomposer in the Hacker News discussion. “This news unlocks us having more options, both C and Rust schedulers, meaning a better experience for the Linux community across a variety of workloads.”

When contacted through LinkedIn, Righi responded that Rust provided great flexibility in allowing him to spin up this project.

“I can’t say that Rust contributed too much on the performance, but it allowed me to write this scheduler in a couple of weeks, implementing and reusing elegant high-level abstractions while being able to go deep into low-level details when I needed.”