By ByteBot
On August 25, Multikernel Technologies released Linux 7.0-mk2 — the first public version of a patched kernel tree that lets one physical server run several independent Linux kernels side by side, each sitting directly on its own CPUs, RAM, and devices. No hypervisor. No emulation. Just kernels running on bare metal next to each other.
That is not a container trick and it is not KVM with extra steps. It is a third approach to workload isolation on Linux that developers have been waiting for, and the initial benchmark numbers suggest it delivers on the core promise.
The Problem With the Existing Options
Workload isolation on Linux has always been a compromise. Containers are fast but share a kernel — one kernel-level exploit lands every container on the box. KVM gives you full kernel isolation but comes with the hypervisor tax: VM exits, second-level page tables, and a device model sitting between your workload and the hardware.
mklinux cuts through that trade-off:
| Approach | Kernel Isolation | Overhead | Emulation |
|---|---|---|---|
| Containers | None (shared kernel) | Near zero | None |
| KVM | Full | High | Full device model |
| mklinux | Full | Very low | None |
A host kernel owns the entire hardware pool — CPUs, memory, PCI devices — and allocates slices of that pool to spawn kernels via kexec_file_load(). Each spawn kernel runs natively on its allocated hardware. As the project states: “Nothing is emulated and nothing is trapped; the only thing shared is what you choose to share.”
What the Benchmarks Actually Show
The team ran lmbench comparisons documented by Phoronix on a dual-socket Intel Xeon Gold 5418Y, giving both mklinux and KVM the same kernel build, two CPU cores, and 1 GB of RAM.
- Two-process context switch: 1.37 µs (mklinux) vs. 3.42 µs (KVM) — 2.5× faster
- Pipe latency: 3.24 µs (mklinux) vs. 7.06 µs (KVM) — roughly 2.2× faster
The reason is structural. KVM handles VM exits and maintains shadow page tables on every context switch. mklinux has none of that machinery — the spawn kernel talks to the hardware directly, the same way a standard kernel would on the same hardware.
Where This Actually Makes Sense
The use cases become clear once you internalize the model:
- Real-time plus standard workloads on the same box: Pin a real-time kernel to a dedicated core set, run standard Linux on the rest. Jitter in one kernel cannot spill into the other.
- Kernel A/B testing: Boot a new kernel version on a subset of cores, validate against production traffic, then migrate resources — without rebooting the machine.
- HPC workloads: Each compute instance gets physical CPUs and memory. No hypervisor tax on syscalls or inter-process communication.
- Security isolation without VM cost: A panic or exploit in one kernel cannot propagate to another — something containers fundamentally cannot offer.
- Zero-downtime kernel upgrades: Live resource migration moves CPUs and memory between running instances without taking anything offline.
How to Get Your Hands on It
The management tool is kerf, available on GitHub. It handles instance creation, resource allocation, and the full instance lifecycle:
git clone https://github.com/multikernel/kerf.git
cd kerf
pip install -e .Instances are declared through /sys/fs/multikernel/ using device tree syntax. Resources — CPUs, memory, devices — move between running instances via device tree overlays, without taking anything down. The official getting started guide walks through first instance setup in detail.
What It Is Not, Yet
This is a first public release. Keep that in mind before designing production architecture around it.
mklinux is currently x86_64 only. It is not in mainline Linux — it is an out-of-tree patch set against Linux 7.0. RFC patches hit the kernel mailing list in September 2025; there is no confirmed timeline for mainline inclusion. You will need to build the custom kernel yourself. No distro packages exist yet.
Worth noting: this project has nothing to do with Apple’s MkLinux from 1997, which ran Linux as a task on the Mach microkernel. Same name, entirely different approach.
Why It Matters
Linux workload isolation has lived with two options for decades: share the kernel (containers) or add a hypervisor (VMs). Multikernel is a genuine third option, and the architecture is clean enough that LWN covered the announcement directly. If the project lands in mainline, infrastructure engineers will have a new primary tool for workload isolation on Linux servers — one that does not force a choice between security and performance.
It is early. The x86_64-only limitation and out-of-tree status are real constraints. But the benchmark results are credible, the architecture is sound, and the developer behind it — Cong Wang, a 16-year Linux kernel contributor — has the credentials to push this forward.
