Multikernel Linux has published its first public kernel tree, based on Linux 7.0.

The idea

Conventional Linux runs one kernel instance managing all the hardware. Every core, every memory region, every device is under one kernel’s control, and isolation between workloads is provided by that kernel through namespaces, cgroups, or by a hypervisor running underneath it.

Multikernel does something different: several independent kernel instances on one physical machine, each owning a partition of the hardware. Cores 0 to 15 and one memory region belong to kernel A. Cores 16 to 31 and a different region belong to kernel B. They are separate kernels, not virtual machines, communicating through defined channels.

Why anyone would want this

Isolation without a hypervisor. Virtualisation isolates well and costs you overhead and a layer of indirection for every I/O operation. Partitioning hardware between kernels gives strong isolation with each kernel talking directly to its own devices.

Scaling. The kernel’s shared data structures and locks become contention points at very high core counts. Several kernels each managing a modest number of cores sidesteps some of that rather than optimising it away.

Failure containment. A kernel panic takes down its partition rather than the machine. For systems where a single fault bringing down 128 cores of work is unacceptable, that is the point.

Mixed workloads. A real-time kernel on one partition and a general-purpose kernel on another, on the same physical machine without a hypervisor mediating.

Live kernel replacement. Start a new kernel on idle partitions, migrate work to it, retire the old one. Updating without rebooting the machine, achieved by never having had only one kernel.

The difficulties

This is research, and the hard parts are hard:

Device ownership. Most hardware assumes one operating system. Partitioning devices between kernels means either dedicating each device to one kernel, which wastes hardware, or building a sharing mechanism, which reintroduces a layer that looks increasingly like a hypervisor.

Memory. Physical memory has to be partitioned at boot, and partitions cannot easily borrow from each other. The flexibility a single kernel has in reallocating memory between workloads is largely gone.

Communication. Kernels need to coordinate, and designing that channel without recreating the shared-state problems the partitioning was meant to avoid is the central design question.

Boot and firmware. Most firmware expects to hand control to one operating system.

Context

The concept is not new. Barrelfish from ETH Zurich and Microsoft explored multikernel operating systems over a decade ago, and Popcorn Linux pursued a related direction. Those were research systems.

A public tree based on a current kernel is more interesting than a paper, because it means the ideas can be tried against real hardware and real workloads by people outside the project.

Whether any of it reaches mainline is another question entirely. Most kernel research does not, and the ideas that matter tend to arrive in mainline in a different and more modest form than they had in the research tree. Our kernel and operating system explainer covers what the kernel is actually responsible for, which is most of what this project is proposing to partition.