Multikernel Aims to Run Multiple Linux Kernels on One Physical Server Without a Hypervisor

Multikernel Technologies is proposing an alternative to traditional virtualization: running multiple independent Linux kernel instances on a single physical server, with dedicated hardware resources assigned to each instance and without relying on a conventional hypervisor. The project, associated with Cong Wang, aims to reduce the overhead that virtualization can introduce for certain workloads. Early results point to lower latency than KVM in selected configurations, although further testing is needed to establish the scope of those improvements and their implications for production environments.

Multikernel at a Glance: The Key Points in 20 Seconds

• Multikernel aims to run multiple Linux kernels on one physical machine, directly on the hardware.
• Each instance receives dedicated resources rather than sharing them through a traditional hypervisor.
• Early tests reported by the project show lower latency than KVM in certain configurations.
• Results depend on system tuning and do not demonstrate universal performance gains across all workloads.
• Isolation, resource management, and stability must be validated before production deployment.

The proposal addresses a common infrastructure design question: how to separate services without multiplying the number of physical servers. Virtual machines allow multiple operating systems to run in isolation on the same server, while containers share the host system’s kernel. Multikernel seeks a different approach, with multiple independent kernels running on the hardware without a conventional hypervisor layer.

This difference could be relevant in environments where every microsecond of latency matters or where different workloads need to remain separate. However, removing a virtualization layer does not automatically guarantee better overall performance. Results depend on resource allocation, the architecture of the solution, and the type of application being run.

Multiple Linux Kernels on a Single Machine

On a conventional virtualized server, the hypervisor manages virtual machines and distributes physical resources such as processors, memory, and input/output devices. On Linux, KVM (Kernel-based Virtual Machine) uses processor virtualization capabilities and integrates with the kernel to run virtual machines.

Multikernel proposes a different arrangement. Instead of placing multiple guest systems under a conventional hypervisor, it assigns dedicated resources to independent kernel instances that run directly on the hardware, a configuration known as bare metal.

The goal is to reduce some of the work involved in managing virtual machines and prevent certain workloads from competing for resources that could otherwise be reserved more strictly. For latency-sensitive applications, such as some networking services or real-time processing systems, this approach may be worth evaluating.

However, assigning dedicated resources to each instance does not mean all interaction between them disappears, nor does it automatically provide isolation equivalent to that of a virtual machine. Establishing the level of separation requires technical details about memory protection, device access, interrupt handling, hardware access, and the mechanisms that prevent one kernel from interfering with another.

Instance management also matters. A production environment needs tools to start and update kernels, allocate resources, monitor failures, and recover services when an instance stops working. How easily these tasks integrate with existing Linux tools will be a practical consideration for infrastructure teams.

The Comparison With KVM Needs Further Testing

Early benchmarks shared by the project indicate that Multikernel can achieve lower latency than KVM in some configurations. That result justifies further investigation, but it does not establish that Multikernel will be faster on every server or application.

Benchmark results depend on many factors, including processor model, memory topology, CPU core allocation, network configuration, storage access, and workload type. It is also important to know which KVM version serves as the baseline and how both environments were tuned.

A rigorous evaluation would compare equivalent configurations, publish the test conditions, and measure average latency alongside high-percentile latency, sustained throughput, and resource consumption. In low-latency services, for example, an improvement in average response time may matter less than a reduction in the spikes experienced by the slowest requests.

There is also insufficient evidence to extrapolate these results to GPUs. The cited tests do not demonstrate that Multikernel improves graphics accelerator performance or enables lower-overhead GPU sharing than alternative approaches. Those questions require dedicated testing that accounts for drivers, device allocation, and the characteristics of each workload.

Comparisons with virtual machines must also consider security and failure recovery, not just speed. An architecture may reduce latency while still requiring additional mechanisms to achieve the isolation and operational resilience expected in enterprise environments.

Where Multikernel Could Make Sense

Separating trusted workloads and running latency-sensitive services are two areas where the proposal merits technical evaluation. An operator could assess whether dedicating physical resources to one kernel instance for a particular service, while reserving another instance for different tasks, reduces interference.

However, the decision should not rely on a single benchmark figure. A laboratory evaluation should measure performance with real applications, examine what happens when an instance fails, and verify whether reserved resources are being used efficiently. It should also test updates, restarts, and maintenance procedures to determine whether the architecture simplifies or complicates day-to-day operations.

In environments where flexibility is the priority, virtual machines will continue to offer established advantages, including workload mobility, mature management tools, and broad compatibility with infrastructure platforms. Multikernel will need to demonstrate what it offers in return and what trade-offs it introduces.

The main question is whether lower overhead justifies adopting a different architecture. For services with strict latency requirements, the answer could be yes under specific conditions. In other scenarios, the performance gains may not justify changing tools and procedures that already work well.

For now, Multikernel should be treated as an option worth evaluating, not as a universal replacement for KVM or a guarantee of stronger security. More reproducible results and documentation of its isolation model will help determine where it offers practical advantages.

Frequently Asked Questions

What is Multikernel for Linux?

It is a proposal from Multikernel Technologies to run multiple independent Linux kernel instances on one physical server, with dedicated resources and without a conventional hypervisor.

How is it different from KVM?

KVM runs virtual machines using processor virtualization capabilities and its integration with Linux. Multikernel proposes a different arrangement in which multiple kernels run directly on the hardware.

Is Multikernel faster than KVM?

Early benchmarks shared by the project show lower latency in certain configurations. Confirming that advantage in other environments requires comparable tests across different workloads and hardware.

Can Multikernel replace virtual machines in production?

That cannot yet be established in general. Before adopting it, organizations should evaluate performance, isolation, device compatibility, failure recovery, and management tools.