Mit mklinux v7.0-mk2 ist der erste öffentliche Release eines Multikernel-Systems erschienen, das auf einem einzelnen physischen Rechner mehrere Linux-Kernel vollständig ohne Hypervisor betreibt. Der Ansatz verspricht nicht nur geringere Latenzen als virtuelle Maschinen, sondern umgeht auch eine seit Jahren wachsende Schwäche des klassischen Monolithen: die Konkurrenz aller CPU-Kerne um gemeinsame Sperren im Kernel. Statt diese Sperren weiter zu verfeinern, teilt mklinux den Kernel selbst auf – nach über 20 Jahren, in denen diese Idee immer wieder als Vision formuliert wurde, existiert damit erstmals lauffähiger Code.
Was ist mklinux? mklinux ist ein Multikernel-System, das auf einem physischen Rechner mehrere vollwertige Linux-Kernel gleichzeitig und ohne Hypervisor ausführt. Ein Host-Kernel verwaltet CPU-, Speicher- und PCI-Gerätepools und startet über kexec_file_load() unabhängige Linux-Kernel, sogenannte Spawn-Kernel. Jeder Spawn-Kernel arbeitet nativ auf den ihm zugewiesenen CPUs und dem zugewiesenen physischen Speicher – ohne Emulation, ohne Traps und ohne den Umweg über eine Virtualisierungsschicht.
Wichtig ist die Abgrenzung zu Containern: Container teilen sich einen einzigen Kernel. Ein Kernel-Panic oder eine ausgenutzte Sicherheitslücke im gemeinsamen Kernel gefährdet sämtliche Container. Bei mklinux besitzt jede Instanz ihren eigenen Kernel. Stürzt einer ab, bleiben die übrigen unberührt, und die zuvor genutzten CPUs fallen an den Host zurück.
Wie mklinux funktioniert: Mehrere Kernel ohne Hypervisor
Die Architektur ist bewusst schlank gehalten. Der Host-Kernel behält die Kontrolle über die Geräte und Ressourcen, gibt aber ganze CPUs und Speicherbereiche an die Spawn-Kernel ab. Welche Ressourcen geteilt werden, legt der Administrator explizit fest – standardmäßig teilen die Kernel nichts. Die Spawn-Kernel laufen als normale Linux-Kernel auf ihrer partitionierten Hardware, ohne dass ein Hypervisor in den Daten- oder Kontrollpfad eingreift.
Die Kommunikation zwischen den Instanzen läuft über den Host-Kernel, der als Vermittler fungiert. Für Anwendungen ändert sich dadurch zunächst nichts: Sie sehen einen gewöhnlichen Linux-Kernel, nur eben auf einer begrenzten Anzahl von Kernen und mit einem eigenen Speicherbereich. Die Instanzkonfiguration erfolgt über einen Gerätebaum, der nach /sys/fs/multikernel/ geschrieben wird; per Device-Tree-Overlay lassen sich CPUs, Speicher und Geräte zur Laufzeit neu zuordnen, ohne den Rechner neu zu starten.
Warum mklinux schneller ist als eine virtuelle Maschine
Virtuelle Maschinen haben in den vergangenen Jahren einen Großteil ihres Overheads durch Hardwareunterstützung verloren. Extended Page Tables (EPT) erledigen die Speicherverwaltung im Hardwarepfad, die virtualisierte Interruptsteuerung APICv übernimmt die Zustellung von Unterbrechungen. Bei reinen Speicherzugriffen ist der Unterschied zur Bare-Metal-Ausführung inzwischen vernachlässigbar: Wons Messungen zeigen bei 128 MB eine Speicherlatenz von 32,1 Nanosekunden gegenüber 31,2 Nanosekunden – praktisch gleichauf.
Die Rechnung kippt, sobald der Kernel tatsächlich Arbeit verrichtet. Jeder Eintritt in den Kernel löst in einer KVM-Gastinstanz einen VM-Exit aus, eine Kontrollübergabe an den Hypervisor, die Zeit kostet. Auch das Aufwecken einer im Leerlauf befindlichen virtuellen CPU erzeugt diesen Aufwand. Die lmbench-Messungen auf einem Dual-Socket-Xeon Gold 5418Y (Sapphire Rapids, 2 × 24 Kerne) zeigen das deutlich:
- Kontextwechsel: 1,37 µs statt 3,42 µs – ein 2,5-facher Vorsprung für mklinux.
- Pipe-Latenz: 3,24 µs statt 7,06 µs – 2,18-fach schneller.
- Null-Syscall: 0,070 µs statt 0,099 µs – rund 30 Nanosekunden Overhead pro Aufruf.
KVM-Betreiber kennen diese Lücke und haben Gegenmittel. Mit dem Kernelparameter idle=poll bleiben die virtuellen CPUs dauerhaft aktiv, wodurch sich die Pipe-Latenz bis auf 3 Prozent an mklinux annähert. Der Preis ist hoch: Die CPUs erscheinen selbst im Leerlauf als voll ausgelastet und verbrauchen 12 bis 19 Watt zusätzlich. Alternativ lässt sich der mwait-Befehl durchreichen, damit die CPUs in Energiesparzustände wechseln können – dann verliert der Host jedoch den Einblick in den Zustand der virtuellen CPUs, und der tiefe Schlafzustand C6 wird nicht erreicht. Die Spawn-Kernel von mklinux durchlaufen dagegen die echten C1- bis C6-Zustände, ohne die niedrigen Latenzen einzubüßen. Und das ist die Standardeinstellung, kein Ergebnis aufwendiger Optimierung.
Hinzu kommt ein prinzipieller Vorteil bei der Isolation. Da jeder Spawn-Kernel einen eigenen Adressraum und eigene Kernelstrukturen besitzt, können keine Cacheline-Konflikte zwischen den Instanzen entstehen. Ein fehlerhafter Treiber, ein Kernel-Panic oder ein kompromittierter Subsystem-Pfad bleibt auf seine Instanz beschränkt.
Die Skalierungswand: Warum ein einzelner Kernel an seine Grenzen stößt
Das zweite Problem, das mklinux adressiert, betrifft jeden einzelnen Linux-Kernel: die begrenzte Skalierbarkeit bei wachsender Kernzahl. Die veröffentlichten will-it-scale-Messungen auf einem 48-Kern-Xeon zeigen ein ernüchterndes Bild. Erzeugt und löscht ein einzelner Prozess Dateien in einem Verzeichnis, schafft er 467.000 Operationen pro Sekunde. Steigt die Zahl der Prozesse auf 48, wobei jeder Prozess in einem eigenen Verzeichnis arbeitet, fällt die Gesamtleistung auf 188.000 Operationen pro Sekunde. 48 Kerne erbringen damit nur das Vierfache eines einzelnen Kerns – jeder weitere Kern macht das System langsamer statt schneller.
Die Ursache liegt nicht in einem Fehler, sondern in der Architektur des Linux-Kernels. Beim Anlegen und Löschen von Dateien muss das übergeordnete Verzeichnis seine Lese-Schreib-Sperre i_rwsem exklusiv halten. Existiert nur ein Verzeichnis, reihen sich alle 48 Kerne vor derselben Sperre auf. Bei Umbenennungen serialisiert die dateisystemweite Sperre s_vfs_rename_mutex sämtliche Operationen. Dazu kommen die Referenzzähler von Folios im Seitencache und von gemeinsam genutzten Dentries – je mehr Kerne darauf zugreifen, desto intensiver wird der Kampf um die Cacheline.
Konfiguration hilft hier nicht weiter. Selbst die Trennung von TCP-Verbindungen in getrennte Netzwerk-Namespaces brachte keinerlei Verbesserung. Die Mauer liegt unterhalb der Namespace-Ebene, tief im Kernel selbst.
Kernelteilung in der Praxis: Die Benchmark-Zahlen
Die Lösung von mklinux ist radikal: Statt Sperren feiner zu granulieren, wird der Kernel geteilt. Auf einem 24-Kern-Socket, aufgeteilt in zwei Kernel mit je 12 Kernen, verändert sich das Bild dramatisch. Die will-it-scale-Messungen im Prozessmodus mit 24 Aufgaben zeigen:
- Datei löschen (unlink): 300.000 auf 780.000 Operationen pro Sekunde – 2,6-fach.
- Umbenennen (rename): 792.000 auf 1,69 Millionen – 2,14-fach.
- Datei öffnen (open): 9,6 auf 19,3 Millionen – 2,02-fach.
- getppid: 268,2 auf 267,1 Millionen – unverändert (Kontrolltest).
- futex: 135,5 auf 134,9 Millionen – unverändert (Kontrolltest).
Die unveränderten Werte bei getppid und futex sind der wichtigste Beleg dafür, dass die Kernelteilung keinen Overhead auf dem Systemaufrufpfad erzeugt. Die Beschleunigung entsteht allein dadurch, dass die Sperrenkonflikte verschwinden. Noch deutlicher wird der Effekt über die Socket-Grenze: Spannt ein einzelner Kernel zwei Sockets auf, kostet jeder Zugriff auf eine entfernte Cacheline den Weg über den Ultra Path Interconnect (UPI). Bei Dateilöschungen fällt die Leistung auf 231.000 Operationen pro Sekunde. Bekommt jeder Socket seinen eigenen Kernel, springt der Wert auf 939.000 – eine Steigerung um das 4,07-Fache.
Der Ansatz hat allerdings klare Grenzen. Ein Großteil der Verbesserung beim Öffnen von Dateien geht auf die gemeinsame Label-Verwaltung des Sicherheitsmoduls AppArmor zurück; wird AppArmor deaktiviert, fällt der Gewinn bei open auf den Faktor 1,00 zurück, während unlink mit 2,24 weiterhin deutlich profitiert. Für mmap-Tests war eine Instanz mit 8 GB Speicher erforderlich. Und Workloads, die als Threads in einem einzigen Adressraum arbeiten, lassen sich grundsätzlich nicht auf mehrere Kernel verteilen.
Zwanzig Jahre Idee, ein Jahr bis zum lauffähigen Code
Die Vorstellung, einen Rechner mit mehreren Kernen zu betreiben, ist nicht neu. Larry McVoy, Entwickler des Versionsverwaltungssystems BitKeeper, schlug bereits 2002 ein „cache-kohärentes Cluster“ für Linux vor. 2009 veröffentlichten die ETH Zürich und Microsoft Research mit Barrelfish ein Forschungs-OS, das konsequent als Multikernel aufgebaut war. Und in der Automobilindustrie gehören Systeme mit zwei getrennten Kernen längst zum Serienstandard.
Was fehlte, war ein lauffähiger Multikernel auf Basis von Linux. Won, seit 17 Jahren Linux-Entwickler und seit 2017 Maintainer des Traffic-Control-Subsystems, hat mit seinem Unternehmen Multikernel Technologies genau das aufgebaut. Mehr als 1.000 Kernel-Commits gehen auf sein Konto. Im September 2025 reichte er einen ersten Patch mit 1.400 Zeilen bei der Linux-Kernel-Mailingliste ein; LWN.net-Redakteur Jonathan Corbet nannte das Projekt damals „mehr als ein Hobbyprojekt“. Die Inspiration stammt aus dem an der Virginia Tech entstandenen Popcorn-Linux-Projekt, das Ziel ist jedoch ein generischer Ansatz, der ohne spezielle Firmware oder dedizierte Hardware auskommt.
Rund ein Jahr nach dem ersten Patch ist v7.0-mk2 Mitte August 2026 als erster öffentlicher Release erschienen. Die Version basiert auf Linux 7.0; mit CONFIG_MULTIKERNEL=n lässt sich der Kernel als gewöhnlicher Linux-7.0-Kernel bauen und betreiben. Auf x86_64 durchlief sie lange Stabilitätstests einschließlich KASLR und 5-Level-Paging. Entscheidend für den produktiven Einsatz: Ein Absturz eines Kernels erreichte in den Tests nie einen anderen Kernel – auch nicht den Spawn-Kernel, der die Partition verwaltet.
Ob mklinux in den Hauptkernel einfließt, ist offen. Selbst im günstigsten Fall würde eine Integration noch Zeit brauchen. Bis dahin liegt der Code auf GitHub, und jeder kann ihn selbst bauen und testen. Die Einstiegshürde ist niedrig: Eine Instanz wird über den Gerätebaum unter /sys/fs/multikernel/ deklariert, die Zuordnung von CPUs, Speicher und Geräten erfolgt ohne Neustart.
Linux hat in zwanzig Jahren enorme Fortschritte bei der Skalierung gemacht. RCU-Mechanismen und Per-VMA-Sperren haben den Wettbewerb im Kernel spürbar reduziert. mklinux verlässt diesen Pfad jedoch bewusst: Es verfeinert nicht die Sperren, es schneidet den Kernel selbst in Stücke. Hinter der Mauer, die sich durch immer feinere Sperren nicht überwinden lässt, könnte genau dieser Weg der einzige sein, der noch offensteht – die Benchmark-Zahlen sprechen eine deutliche Sprache.
