Multikernel’s first public Linux tree, v7.0-mk2, runs separate kernels on assigned physical resources. It is an experimental alternative worth understanding for partitionable workloads, with a different operational model from a virtual machine or a container.
Dedicated resources for each kernel
Cong Wang’s 25 August announcement describes a host allocating CPUs, memory and PCI devices, then starting additional kernels through an extended kexec_file_load() path. The release supports x86_64 and is based on Linux 7.0; it is a separate tree, not a claim that all these capabilities have entered upstream Linux.
The project setup guide shows the surrounding components: the modified kernel, Kerf management and Lazy CMA for memory pools. DAXFS is an additional requirement for the documented Docker-image or shared-directory path. A Docker image supplies a filesystem here; its presence does not make the resulting instance an ordinary shared-kernel container.
What the published timings can establish
The author reports lmbench on a dual-socket Xeon Gold 5418Y with SMT disabled. A two-core, 1 GB spawn instance is compared with a pinned two-vCPU, 1 GB KVM guest. The reported two-process context switch takes 1.37 microseconds versus 3.42, a ratio near 2.50. These are project measurements, not our independent tests or a promise of 2.5 times faster applications.
As a deliberately simplified calculation, if such switching accounted for 10% of a program’s total time, accelerating only that portion by 2.5 would give a total time of 0.90 + 0.10 / 2.5 = 0.94, or approximately 1.06 times the original speed. That example assumes everything else stays constant and makes no claim about an actual workload. It shows why a microbenchmark ratio cannot be applied to an entire service.
Partitionability comes before speed
Map which processes can live independently. If one application needs a single shared address space across all its worker threads, drawing two kernel boxes does not divide that address space for free. If the split requires a network hop, measure the new communication and serialization cost alongside any reduced kernel contention.
Separate kernels also should not be presented as proof of an audited hostile-tenant security boundary. Hardware assignment, DMA, shared memory, firmware and the host control path remain questions for the actual implementation and deployment. The project’s crash-isolation reports do not settle every exploit scenario.
Use dedicated lab hardware to evaluate this tree. Record resource placement, NUMA topology, memory, power policy, security modules and the KVM configuration being compared. Test reclamation and recovery as well as steady-state throughput. We have not installed or benchmarked it for this article.
Sources
Checked the first public release and setup guide; vendor microbenchmarks separated from application performance, isolation claims qualified, unsupported architectures excluded.