How ByteDance’s Parker Enables Multiple Linux Kernels on a Single Machine

A few days ago ByteDance submitted a multi‑kernel architecture proposal for the Linux kernel.

This approach differs from the recently published Multikernel Technologies; ByteDance has been developing a similar solution called Parker, which they later officially unveiled as a way to run multiple kernels in parallel on the same hardware.

Parker can run several Linux kernels on a single machine without relying on KVM or other virtualization technologies. It partitions CPU cores, memory, and devices, creating a Linux kernel that is aware of these partitions.

In the proposal ByteDance acknowledges some similarity to the recent Multikernel RFC, but the design and implementation mechanisms are completely different.

The RFC posted to the Linux kernel mailing list, authored by engineers Fam Zheng and Thom Hughes, introduced Parker (short for “PARtitioned KERnel”).

Parker further explains its multi‑kernel design:

“Each kernel instance can use the same image, but the initial kernel (the boot kernel) is responsible for controlling hardware allocation and partitioning. The remaining kernels are secondary (application) kernels, each managing its allocated CPU, memory, and I/O devices.” Parker’s primary use case is high‑core‑count machines where scalability can be problematic. After boot, kernel instances do not communicate and share no resources, which enhances scalability. Each kernel requires its own PCIe device for I/O, such as an NVMe drive or a network card. Another possible scenario is configuring different performance‑tuning options, CONFIG settings, and FDO/PGO strategies for each kernel instance based on workload requirements.

The concept aims to allow multiple Linux kernels to run simultaneously on a single physical machine without depending on traditional virtualization tools like KVM.

Parker operates by partitioning hardware resources. The boot kernel first divides CPU cores, memory regions, and I/O devices, then hands these partitions to what developers call application kernels.

Because each kernel runs independently and does not need to communicate with others, the approach theoretically offers better scalability on servers with very high core counts.

Engineers see a use case where kernels with different configurations or performance optimizations run side‑by‑side to handle diverse workloads. Parker achieves this by exposing a kernfs interface and using kexec to hot‑load secondary kernel images into reserved memory. Prior to this, the boot kernel must offline CPUs, reserve memory, and detach devices to ensure each partition can operate safely.

However, not everyone is convinced. Intel’s Dave Hansen criticized the proposal, warning that without a supervisory layer, conflicts between kernels could arise—for example, a kernel issuing a WBINVD instruction could affect all other kernels on the machine.

Many companies are actively experimenting with multi‑kernel solutions to better handle modern high‑core‑count systems. The future direction of this work and which proposals will eventually be adopted into the upstream Linux kernel remain topics of ongoing interest.