{"slug": "run-several-linux-kernels-at-the-same-time-on-bare-metal-without-a-hypervisor", "title": "Run several Linux kernels at the same time on bare metal, without a hypervisor", "summary": "Cong Wang announced mklinux v7.0-mk2, the first public release of the multikernel Linux tree, which allows one machine to run several independent Linux kernels simultaneously on bare metal without a hypervisor. Benchmarks on a dual-socket Xeon Gold 5418Y show spawn kernels outperform KVM guests by up to 2.5x in context switch latency and 2.2x in pipe latency, and two kernels scale past single-kernel limits with up to 2.6x improvement in will-it-scale tests. The tree is based on v7.0 and behaves exactly like v7.0 when CONFIG_MULTIKERNEL=n.", "body_md": "# [ANNOUNCE] mklinux v7.0-mk2\n\n**Thread information**[\n\n[Search the all archive](/ml/all/)]\n\n```\n[No responses]\n```\n\nFrom: |\nCong Wang | |\nTo: |\nlinux-kernel-AT-vger.kernel.org | |\nSubject: |\n[ANNOUNCE] mklinux v7.0-mk2 | |\nDate: |\nTue, 25 Aug 2026 13:17:08 -0700 | |\nMessage-ID: |\n | |\nCc: |\nmultikernel-AT-lists.linux.dev |\n\n```\nHi all,\n\nI am happy to announce mklinux v7.0-mk2, the first public release of\nthe multikernel Linux tree.\n\n git: https://github.com/multikernel/linux\n tag: v7.0-mk2\n\nWhat is mklinux?\n================\n\nmklinux lets one machine run several independent Linux kernels at the\nsame time on bare metal, without a hypervisor. A host kernel owns a pool\nof CPUs, memory and PCI devices, carves that pool into instances, and\nboots a spawn kernel into each instance through kexec_file_load(). Every\nspawn kernel runs natively on its own CPUs, its own physical memory and\nits own devices. Nothing is emulated and nothing is trapped; the only\nthing shared is what you choose to share.\n\nInstances are declared with a device tree written to\n/sys/fs/multikernel/, and device tree overlays move memory, CPUs and\ndevices between the pool and running instances without a reboot. An\ninstance can be shut down, its resources reclaimed, and respawned with\na different kernel.\n\nCompared with virtual machines, there is no VM exit path, no second\nlevel of page tables and no device model. Compared with containers,\ninstances do not share a kernel, so a lock, a panic or an exploit in one\nkernel cannot reach another.\n\nThe tree is based on v7.0. With CONFIG_MULTIKERNEL=n it builds and\nbehaves exactly like v7.0.\n\nPerformance\n===========\n\nTwo things matter here: a spawn kernel should pay nothing over bare\nmetal, and splitting a machine into several kernels should let workloads\nscale past the walls a single kernel hits. Both were measured on a\ndual-socket Xeon Gold 5418Y (Sapphire Rapids, 2x24 cores, SMT off).\n\nNo virtualization tax\n---------------------\n\nlmbench on a 2-core, 1 GB spawn kernel against a 2-vCPU, 1 GB KVM guest\nwith EPT, unrestricted guest and APICv, vCPUs pinned to idle cores:\n\n Benchmark Multikernel KVM guest Ratio\n Null syscall 0.070 us 0.099 us 1.42x\n read() 0.099 us 0.124 us 1.26x\n write() 0.082 us 0.114 us 1.39x\n Signal handler install 0.123 us 0.159 us 1.29x\n Signal handler catch 0.770 us 0.881 us 1.14x\n Context switch (2 procs) 1.37 us 3.42 us 2.50x\n Pipe latency 3.24 us 7.06 us 2.18x\n AF_UNIX stream latency 4.81 us 7.48 us 1.55x\n fork + exit 115 us 123 us 1.07x\n\nMemory latency and bandwidth are at parity (lat_mem_rd 32.1 ns vs\n31.2 ns at 128 MB; ~20.9 GB/s sequential read on both), which is\nexpected: EPT with huge pages has made nested translation essentially\nfree. What a guest cannot avoid is the exit on every kernel entry and\non every wakeup of an idle vCPU, which is where the 2.5x context switch\nand 2.2x pipe latency gap comes from. KVM can close most of that gap\nwith idle=poll or mwait passthrough, at the cost of a vCPU that looks\n100% busy to the host and 12 to 19 W of extra power. A spawn kernel\ngets the low latency and still puts its cores into C1 to C6 when idle.\n\n https://multikernel.io/2026/08/16/multikernel-vs-kvm-lmbe...\n\nScaling past the single-kernel wall\n-----------------------------------\n\nwill-it-scale, processes mode, 24 tasks on one socket: one kernel\ndriving 24 cores versus two spawn kernels driving 12 cores each.\n\n Test 1 kernel 2 kernels Ratio\n unlink1 300K/s 780K/s 2.60x\n rename1 792K/s 1.69M/s 2.14x\n stat2 9.42M/s 19.8M/s 2.10x\n open3 3.42M/s 7.41M/s 2.17x\n open1 9.6M/s 19.3M/s 2.02x\n pread4 ~5.2M/s ~10.1M/s 1.94x\n mmap1 9.9M/s 12.2M/s 1.23x\n tcp_conn1 1.81M/s 2.10M/s 1.16x\n getppid1 268.2M/s 267.1M/s 1.00x (control)\n futex4 135.5M/s 134.9M/s 1.00x (control)\n poll2 26.7M/s 26.5M/s 0.99x (control)\n\nThe controls show there is no multikernel overhead on the syscall path\nat all. The wins come from locks that a single kernel cannot shard:\nthe directory i_rwsem, s_vfs_rename_mutex, a shared dentry refcount, a\nfolio refcount in the page cache. On one kernel, unlink1 peaks at 2\ntasks and then goes backwards; at 48 tasks it delivers 40% of what one\ntask manages alone. Splitting the same tasks across network namespaces\non one kernel gives exactly nothing (tcp_conn2 matches tcp_conn1 at\nevery task count), because the wall sits below the namespace boundary.\n\nAligning kernels with sockets makes the effect larger: with 12 cores\nper socket, one kernel spanning both sockets versus one kernel per\nsocket gives unlink1 231K/s vs 939K/s (4.07x) and open1 9.06M/s vs\n20.1M/s (2.22x).\n\nFor fairness, the caveats are in the post as well: open1's win is\nmostly AppArmor label sharing and drops to 1.00x with the LSM off\n(unlink1 keeps 2.24x); mmap1 needed 8 GB instances to keep\nvm_committed_as batching out of the way; and workloads that share one\naddress space across all cores (threads mode) cannot be split and gain\nnothing.\n\n https://multikernel.io/2026/08/17/multikernel-will-it-scale/\n\nStability on x86_64\n===================\n\nx86_64 is the supported architecture for this release and the reason\nit is the first one announced. Instances have been spawned, shut down,\nreconfigured and respawned in long soak loops on the machines above,\nwith KASLR and 5-level paging, including spawn kernels that panic; a\ncrash in one kernel does not reach the others, and every CPU an\ninstance was given is confirmed parked back on the host before it is\nreused. The benchmark numbers above were collected on this exact\nrelease with unmodified workloads inside the spawn kernels.\n\nThe architecture interface is split out so other ports can follow, but\nno other architecture is supported yet.\n\nGetting started\n===============\n\nCheck https://multikernel.io/getting-started.html\n\nFeedback, bug reports and testing on other hardware are very welcome.\nThe tree will keep tracking upstream releases, and pieces that stand on\ntheir own will be posted for upstream review separately.\n\nThanks,\nCong Wang\n```\n\n", "url": "https://wpnews.pro/news/run-several-linux-kernels-at-the-same-time-on-bare-metal-without-a-hypervisor", "canonical_source": "https://lwn.net/ml/all/ao34RJ7aZ2BLd67S@pop-os.localdomain/", "published_at": "2026-08-26 05:48:24+00:00", "updated_at": "2026-08-26 06:14:43.818959+00:00", "lang": "en", "topics": ["artificial-intelligence", "machine-learning", "large-language-models", "robotics", "autonomous-vehicles"], "entities": ["Cong Wang", "mklinux", "multikernel Linux tree", "Xeon Gold 5418Y", "KVM"], "alternates": {"html": "https://wpnews.pro/news/run-several-linux-kernels-at-the-same-time-on-bare-metal-without-a-hypervisor", "markdown": "https://wpnews.pro/news/run-several-linux-kernels-at-the-same-time-on-bare-metal-without-a-hypervisor.md", "text": "https://wpnews.pro/news/run-several-linux-kernels-at-the-same-time-on-bare-metal-without-a-hypervisor.txt", "jsonld": "https://wpnews.pro/news/run-several-linux-kernels-at-the-same-time-on-bare-metal-without-a-hypervisor.jsonld"}}