For most of the last twenty years, anyone who wanted two Linux installs sharing a server reached for a hypervisor. Containers came later for process-level isolation, but the kernel itself stayed single-tenant inside each VM. Multikernel Linux is an experimental take that throws out the hypervisor entirely and asks what kernel-level isolation should look like when the child runs directly on the hardware.
After about a year of quiet work, the project pushed its first public kernel tree, based on Linux 7.0 and tagged v7.0-mk2. The pitch is simple: real isolation, measurable latency wins, paid for in measurable watts. The team is upfront about the trade, which is the only way to take a v1 release seriously.
How the layout works in practice
Conceptually, Multikernel is one host kernel running many child kernels, each on its own slice of bare metal. Boot a single host Linux kernel that owns everything. That host divides the physical resources into groups (compute cores, memory regions, PCI devices) and starts a fresh Linux kernel in each group. There is no virtual machine abstraction between the children and the hardware. Each child thinks it owns the slice it was handed, because nothing is emulating anything in software.
What makes the design interesting is that the slices are not fixed. Shutting one child down returns its resources to the host, which can hand them to a different child running a different kernel build. The mental model sits somewhere between container orchestration and full virtualization, but with a real kernel boundary instead of either a namespace boundary or a hypervisor boundary.
Children that want fine control over their own CPU power states can ask for it, but every knob the child turns in that direction trades against energy use and resource sharing with the host. The design rewards thinking about the whole machine as a single power budget.
Where the latency story actually comes from
Anyone familiar with modern hardware virtualization knows that memory bandwidth and latency numbers are basically a tie these days. That holds up in the Multikernel team’s measurements on a dual-socket Intel Xeon Gold 5418Y with two cores and 1 GB of RAM allocated, running Multikernel against a tuned KVM guest using the same kernel build. Where Multikernel pulls ahead is the kind of micro-operations that real workloads hit thousands of times per second:
- Process context switch: 1.37 microseconds in Multikernel versus 3.42 in the KVM guest
- Pipe latency: 3.24 versus 7.06 microseconds
- Unix domain socket latency: 4.81 versus 7.48 microseconds
lmbench (a benchmark suite that has measured OS-level latency since the 1990s) is the tool behind these numbers, and the deltas are roughly 2x in the operations where inter-process communication dominates. For chatty microservice meshes and databases doing many small IPC hops per second, that gap compounds across a request path. The numbers are reproducible on stock server hardware, not a synthetic claim.
The mechanism is straightforward once stated. In KVM, putting an idle virtual CPU back to sleep or waking it up requires a round trip through the hypervisor boundary. Multikernel skips that by scheduling directly onto physical cores. Children see faster wakeups and faster transitions. The downside is that idle physical cores look busy to the host’s power management, which never gets the chance to park them in deep C-states (CPU idle power-saving modes).
The wattage story needs its own planning
Across the same dual-core setup, the team measured roughly 19 extra watts before any tuning. That figure comes from the cores that never go idle, even when their assigned child is not actively running. Multiplied across hundreds of cores in a real fleet, the delta lands on the next quarterly power bill. Anyone whose data center contract is per-watt will see the math immediately.
Two mitigations are available. Letting the child kernel take more control over CPU power states can claw back some of the latency advantage and trim the wattage cost, but every setting in that direction reduces the host’s ability to share resources fairly. The honest version is that this is a budget decision, not a free lunch. The team is clear about that, and the trade belongs in a capacity planning meeting rather than a tweet thread.
The published lmbench numbers are also a ceiling rather than a guarantee. The benchmarks landed in the specific operations where Multikernel is designed to win. Memory-heavy workloads will see a much smaller delta. Compute-heavy workloads with low IPC will see a modest delta. Latency-sensitive workloads with lots of small message passing will see the largest delta. Real workloads vary, and the only honest test is running the project’s tree against the workload you actually care about.
What works today and what is still pending
v7.0-mk2 is a research release, and the project makes that clear. The architecture-specific code lives in its own tree structure, but x86_64 is the only fully tested and stable target. ARM and RISC-V support are planned, the code is structured for them, and nothing is shipping yet. Anyone running a fleet on ARM hardware should treat Multikernel as a project to watch rather than a tool to evaluate.
A few operational realities are worth flagging before anyone pulls the tree:
- The published benchmarks are a ceiling, not a guarantee, and your workload will land somewhere on a wide range
- Power management is the first knob to revisit when tuning for production
- The build is rough around the edges and should be treated as a research target, not a production drop
- The lmbench numbers were generated on a specific two-core setup and may not generalize to many-core machines
Anyone evaluating this seriously should grab v7.0-mk2, build it on spare hardware, and run their own benchmark suite against their current KVM setup. That is the only way to confirm whether the latency delta is worth the watt delta for the workload that actually matters.
Trade-offs
Multikernel deserves attention for two reasons and caution for a third. The latency story is real and reproducible, which puts it on the short list of any team that has hit a virtualization ceiling. The isolation story is real because children run on hardware rather than inside a hypervisor, which is closer to bare metal than any other approach available today. Both wins are clear.
The caution is the wattage delta, which is also real and reproducible. A project that costs around 19 watts per pair of cores is not a drop-in replacement for KVM. The economics only work for systems where the latency gain translates directly into revenue or capacity savings that outweigh the power bill. For everyone else, the better answer is to keep watching.
The v1 factor matters too. The public tree is the first thing the team has shipped, which means documentation is sparse, error messages will be unhelpful, and the upgrade path between versions has not been exercised. Production deployments of v1 research kernels have a track record of regret inside six months.
Finally, the architecture question is real. x86_64 only today means ARM and RISC-V are not in the conversation. ARM servers are a growing slice of the data center market, and Multikernel will not be a real option there until the port lands.
Bottom line
Multikernel Linux is a project worth a bookmark, not a deployment, for almost every team reading this. The latency numbers are real, the isolation model is interesting, and the architecture choice is worth understanding before the next hardware refresh.
For teams that already push the limits of KVM latency and have the power budget to absorb the cost, pull the v7.0-mk2 tree and try it on spare hardware. Run a workload representative of your real traffic, not just lmbench, and treat the published numbers as a ceiling. For everyone else, the right move is to follow the next public release, see whether ARM support lands, and revisit the decision when the project has matured past v1.