A microkernel operating system written entirely in Rust just took a significant step forward. Redox OS, the open-source project that has spent nearly a decade attempting to build a Unix-like operating system from the ground up using memory-safe code, has landed a new CPU scheduler. Not a port. Not a derivative. A from-scratch implementation designed specifically for the system’s unique architecture.
The new scheduler, developed by Redox OS contributor 4lDO2, replaces the previous round-robin approach with something far more sophisticated. According to Phoronix, the new design draws inspiration from several established scheduling algorithms in the Linux world — including the Completely Fair Scheduler (CFS), EEVDF (Earliest Eligible Virtual Deadline First), and even some concepts from the recently merged sched_ext framework — but adapts them for Redox’s microkernel design rather than copying them wholesale.
That distinction matters more than it might initially seem.
In a monolithic kernel like Linux, the scheduler lives inside the kernel itself, with direct access to all the data structures it needs. Redox’s microkernel architecture is fundamentally different. Drivers, file systems, and many other components run as separate user-space processes rather than inside the kernel. This means the scheduler has to be efficient in a context where inter-process communication overhead is a real and constant concern. A scheduler that works beautifully in Linux can’t simply be transplanted into Redox and expected to perform well.
The technical details, as outlined in the project’s development notes and reported by Phoronix, reveal a scheduler that uses a virtual runtime mechanism similar to what CFS pioneered in Linux. Each task accumulates virtual runtime, and the scheduler picks the task with the lowest virtual runtime to run next. This ensures fairness — CPU-hungry processes don’t starve lighter workloads. But the Redox implementation goes further by incorporating deadline-based scheduling concepts from EEVDF, which was merged into the Linux kernel in version 6.6 to replace CFS as the default scheduler. EEVDF improves latency for interactive and real-time-adjacent workloads by assigning virtual deadlines to tasks, ensuring that processes that have been waiting longest get priority even when competing with compute-heavy threads.
So why does a small, experimental operating system need a sophisticated scheduler at all?
Because Redox OS is trying to prove something. The project, founded by Jeremy Soller in 2015, has always been an argument that systems programming doesn’t have to mean C. Rust’s ownership model and borrow checker eliminate entire categories of memory safety bugs — use-after-free, buffer overflows, data races — at compile time rather than at runtime. Every major operating system kernel in production today carries the scars of decades of memory safety vulnerabilities in C code. Android, Linux, Windows, macOS — all of them. Redox’s bet is that starting fresh in Rust, with a microkernel architecture that minimizes the amount of code running in privileged mode, can produce an OS that is both safer and more maintainable over the long term.
The scheduler is a critical piece of that argument. A toy scheduler — simple round-robin, no priority support, no fairness guarantees — signals a toy OS. A scheduler that incorporates modern scheduling theory and adapts it intelligently to a microkernel context signals something more serious.
The new implementation also includes support for multiple scheduling classes, allowing different types of workloads to coexist more gracefully. Real-time tasks, interactive desktop applications, and background batch processing all have different needs. A single scheduling policy can’t optimally serve all of them. By supporting multiple classes, the Redox scheduler can apply different policies to different workload types — a design pattern that Linux has used for years through its scheduling classes (SCHED_FIFO, SCHED_RR, SCHED_NORMAL, and others).
There’s also the question of SMP — symmetric multiprocessing. Modern machines have multiple CPU cores, and any scheduler worth its salt needs to distribute work across them efficiently. The new Redox scheduler includes logic for multi-core load balancing, ensuring that tasks are migrated between cores when imbalances arise. This is notoriously difficult to get right. Linux’s CFS load balancer has been the subject of multiple research papers documenting cases where it leaves cores idle while other cores are overloaded. Getting this right in a microkernel, where the cost of a bad scheduling decision is amplified by IPC overhead, is even harder.
The timing of this development is interesting. The broader operating systems world is in the middle of a sustained conversation about memory safety and kernel architecture. The U.S. government’s Cybersecurity and Infrastructure Security Agency (CISA) and the White House Office of the National Cyber Director have both published guidance urging software developers to adopt memory-safe languages. The Linux kernel itself has been gradually incorporating Rust, with Rust-for-Linux support merged in Linux 6.1 and expanding steadily since. But Rust in Linux is additive — new drivers and modules written in Rust, grafted onto a C kernel. Redox represents the other end of the spectrum: Rust all the way down.
And the project has been making steady progress beyond just the scheduler. Recent months have seen improvements to Redox’s graphics stack, its network drivers, and its package management system. The OS can boot on real hardware — not just emulators — and supports a graphical desktop environment called Orbital. It’s not ready to replace anyone’s daily driver. Not close. But the gap between “interesting research project” and “usable niche operating system” has been narrowing.
The sched_ext influence in the new scheduler design is particularly notable. In the Linux world, sched_ext — a framework that allows scheduling policies to be written as BPF programs and loaded dynamically — has generated enormous excitement. It was championed by Meta engineers and merged into Linux 6.12. The core idea is that scheduling policy should be separable from scheduling mechanism, allowing developers and system administrators to experiment with custom schedulers without modifying or recompiling the kernel. While Redox’s implementation doesn’t replicate sched_ext’s BPF-based extensibility, the philosophical influence is clear: scheduling should be modular, adaptable, and open to experimentation.
For industry observers tracking the evolution of alternative operating systems, Redox occupies a unique position. It’s not backed by a major corporation. It doesn’t have Google’s resources (Fuchsia) or the historical weight of an established Unix (FreeBSD, OpenBSD). What it has is a coherent technical vision — microkernel, Rust, memory safety by default — and a small but persistent community of contributors who keep shipping code. The new scheduler is one of the more technically ambitious pieces of infrastructure the project has produced to date.
Whether Redox OS ever achieves mainstream adoption is almost beside the point. The project serves as a proving ground for ideas that may eventually filter into systems that do have mainstream reach. If a Rust-native scheduler can match or approach the sophistication of Linux’s EEVDF while running in a microkernel, that’s a data point that matters to anyone thinking about the future of operating system design. And right now, data points like that are in short supply.
The code is open source and available on the project’s GitLab repository. For those inclined to read scheduling code written in Rust rather than C, it’s worth a look.
WebProNews is an iEntry Publication