Mit mklinux v7.0-mk2 ist der erste \u00f6ffentliche Release eines Multikernel-Systems erschienen, das auf einem einzelnen physischen Rechner mehrere Linux-Kernel vollst\u00e4ndig ohne Hypervisor betreibt. Der Ansatz verspricht nicht nur geringere Latenzen als virtuelle Maschinen, sondern umgeht auch eine seit Jahren wachsende Schw\u00e4che 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 \u2013 nach \u00fcber 20 Jahren, in denen diese Idee immer wieder als Vision formuliert wurde, existiert damit erstmals lauff\u00e4higer Code.<\/p>\n
Was ist mklinux?<\/strong> mklinux ist ein Multikernel-System, das auf einem physischen Rechner mehrere vollwertige Linux-Kernel gleichzeitig und ohne Hypervisor ausf\u00fchrt. Ein Host-Kernel verwaltet CPU-, Speicher- und PCI-Ger\u00e4tepools und startet \u00fcber kexec_file_load() unabh\u00e4ngige Linux-Kernel, sogenannte Spawn-Kernel. Jeder Spawn-Kernel arbeitet nativ auf den ihm zugewiesenen CPUs und dem zugewiesenen physischen Speicher \u2013 ohne Emulation, ohne Traps und ohne den Umweg \u00fcber eine Virtualisierungsschicht.<\/p>\n Wichtig ist die Abgrenzung zu Containern: Container teilen sich einen einzigen Kernel. Ein Kernel-Panic oder eine ausgenutzte Sicherheitsl\u00fccke im gemeinsamen Kernel gef\u00e4hrdet s\u00e4mtliche Container. Bei mklinux besitzt jede Instanz ihren eigenen Kernel. St\u00fcrzt einer ab, bleiben die \u00fcbrigen unber\u00fchrt, und die zuvor genutzten CPUs fallen an den Host zur\u00fcck.<\/p>\n Die Architektur ist bewusst schlank gehalten. Der Host-Kernel beh\u00e4lt die Kontrolle \u00fcber die Ger\u00e4te und Ressourcen, gibt aber ganze CPUs und Speicherbereiche an die Spawn-Kernel ab. Welche Ressourcen geteilt werden, legt der Administrator explizit fest \u2013 standardm\u00e4\u00dfig 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.<\/p>\n Die Kommunikation zwischen den Instanzen l\u00e4uft \u00fcber den Host-Kernel, der als Vermittler fungiert. F\u00fcr Anwendungen \u00e4ndert sich dadurch zun\u00e4chst nichts: Sie sehen einen gew\u00f6hnlichen Linux-Kernel, nur eben auf einer begrenzten Anzahl von Kernen und mit einem eigenen Speicherbereich. Die Instanzkonfiguration erfolgt \u00fcber einen Ger\u00e4tebaum, der nach \/sys\/fs\/multikernel\/ geschrieben wird; per Device-Tree-Overlay lassen sich CPUs, Speicher und Ger\u00e4te zur Laufzeit neu zuordnen, ohne den Rechner neu zu starten.<\/p>\n Virtuelle Maschinen haben in den vergangenen Jahren einen Gro\u00dfteil ihres Overheads durch Hardwareunterst\u00fctzung verloren. Extended Page Tables (EPT) erledigen die Speicherverwaltung im Hardwarepfad, die virtualisierte Interruptsteuerung APICv \u00fcbernimmt die Zustellung von Unterbrechungen. Bei reinen Speicherzugriffen ist der Unterschied zur Bare-Metal-Ausf\u00fchrung inzwischen vernachl\u00e4ssigbar: Wons Messungen zeigen bei 128 MB eine Speicherlatenz von 32,1 Nanosekunden gegen\u00fcber 31,2 Nanosekunden \u2013 praktisch gleichauf.<\/p>\n Die Rechnung kippt, sobald der Kernel tats\u00e4chlich Arbeit verrichtet. Jeder Eintritt in den Kernel l\u00f6st in einer KVM-Gastinstanz einen VM-Exit aus, eine Kontroll\u00fcbergabe 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 \u00d7 24 Kerne) zeigen das deutlich:<\/p>\n KVM-Betreiber kennen diese L\u00fccke 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\u00e4hert. Der Preis ist hoch: Die CPUs erscheinen selbst im Leerlauf als voll ausgelastet und verbrauchen 12 bis 19 Watt zus\u00e4tzlich<\/strong>. Alternativ l\u00e4sst sich der mwait-Befehl durchreichen, damit die CPUs in Energiesparzust\u00e4nde wechseln k\u00f6nnen \u2013 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\u00e4nde, ohne die niedrigen Latenzen einzub\u00fc\u00dfen. Und das ist die Standardeinstellung, kein Ergebnis aufwendiger Optimierung.<\/p>\n Hinzu kommt ein prinzipieller Vorteil bei der Isolation. Da jeder Spawn-Kernel einen eigenen Adressraum und eigene Kernelstrukturen besitzt, k\u00f6nnen keine Cacheline-Konflikte zwischen den Instanzen entstehen. Ein fehlerhafter Treiber, ein Kernel-Panic oder ein kompromittierter Subsystem-Pfad bleibt auf seine Instanz beschr\u00e4nkt.<\/p>\n Das zweite Problem, das mklinux adressiert, betrifft jeden einzelnen Linux-Kernel: die begrenzte Skalierbarkeit bei wachsender Kernzahl. Die ver\u00f6ffentlichten will-it-scale-Messungen auf einem 48-Kern-Xeon zeigen ein ern\u00fcchterndes Bild. Erzeugt und l\u00f6scht 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\u00e4llt die Gesamtleistung auf 188.000 Operationen pro Sekunde. 48 Kerne erbringen damit nur das Vierfache eines einzelnen Kerns<\/strong> \u2013 jeder weitere Kern macht das System langsamer statt schneller.<\/p>\n Die Ursache liegt nicht in einem Fehler, sondern in der Architektur des Linux-Kernels. Beim Anlegen und L\u00f6schen von Dateien muss das \u00fcbergeordnete 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\u00e4mtliche Operationen. Dazu kommen die Referenzz\u00e4hler von Folios im Seitencache und von gemeinsam genutzten Dentries \u2013 je mehr Kerne darauf zugreifen, desto intensiver wird der Kampf um die Cacheline.<\/p>\n 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.<\/p>\n Die L\u00f6sung 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\u00e4ndert sich das Bild dramatisch. Die will-it-scale-Messungen im Prozessmodus mit 24 Aufgaben zeigen:<\/p>\n Die unver\u00e4nderten Werte bei getppid und futex sind der wichtigste Beleg daf\u00fcr, dass die Kernelteilung keinen Overhead auf dem Systemaufrufpfad erzeugt. Die Beschleunigung entsteht allein dadurch, dass die Sperrenkonflikte verschwinden. Noch deutlicher wird der Effekt \u00fcber die Socket-Grenze: Spannt ein einzelner Kernel zwei Sockets auf, kostet jeder Zugriff auf eine entfernte Cacheline den Weg \u00fcber den Ultra Path Interconnect (UPI). Bei Dateil\u00f6schungen f\u00e4llt die Leistung auf 231.000 Operationen pro Sekunde. Bekommt jeder Socket seinen eigenen Kernel, springt der Wert auf 939.000 \u2013 eine Steigerung um das 4,07-Fache<\/strong>.<\/p>\n Der Ansatz hat allerdings klare Grenzen. Ein Gro\u00dfteil der Verbesserung beim \u00d6ffnen von Dateien geht auf die gemeinsame Label-Verwaltung des Sicherheitsmoduls AppArmor zur\u00fcck; wird AppArmor deaktiviert, f\u00e4llt der Gewinn bei open auf den Faktor 1,00 zur\u00fcck, w\u00e4hrend unlink mit 2,24 weiterhin deutlich profitiert. F\u00fcr mmap-Tests war eine Instanz mit 8 GB Speicher erforderlich. Und Workloads, die als Threads in einem einzigen Adressraum arbeiten, lassen sich grunds\u00e4tzlich nicht auf mehrere Kernel verteilen.<\/p>\n Die Vorstellung, einen Rechner mit mehreren Kernen zu betreiben, ist nicht neu. Larry McVoy, Entwickler des Versionsverwaltungssystems BitKeeper, schlug bereits 2002 ein \u201ecache-koh\u00e4rentes Cluster“ f\u00fcr Linux vor. 2009 ver\u00f6ffentlichten die ETH Z\u00fcrich und Microsoft<\/a> Research mit Barrelfish ein Forschungs-OS, das konsequent als Multikernel aufgebaut war. Und in der Automobilindustrie geh\u00f6ren Systeme mit zwei getrennten Kernen l\u00e4ngst zum Serienstandard.<\/p>\n Was fehlte, war ein lauff\u00e4higer 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 \u201emehr 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.<\/p>\n Rund ein Jahr nach dem ersten Patch ist v7.0-mk2 Mitte August 2026<\/a> als erster \u00f6ffentlicher Release erschienen. Die Version basiert auf Linux 7<\/a>.0; mit CONFIG_MULTIKERNEL=n l\u00e4sst sich der Kernel als gew\u00f6hnlicher Linux-7.0-Kernel bauen und betreiben. Auf x86_64 durchlief sie lange Stabilit\u00e4tstests einschlie\u00dflich KASLR und 5-Level-Paging. Entscheidend f\u00fcr den produktiven Einsatz: Ein Absturz eines Kernels erreichte in den Tests nie einen anderen Kernel \u2013 auch nicht den Spawn-Kernel, der die Partition verwaltet.<\/p>\n Ob mklinux in den Hauptkernel einflie\u00dft, ist offen. Selbst im g\u00fcnstigsten Fall w\u00fcrde eine Integration noch Zeit brauchen. Bis dahin liegt der Code auf GitHub, und jeder kann ihn selbst bauen und testen. Die Einstiegsh\u00fcrde ist niedrig: Eine Instanz wird \u00fcber den Ger\u00e4tebaum unter \/sys\/fs\/multikernel\/ deklariert, die Zuordnung von CPUs, Speicher und Ger\u00e4ten erfolgt ohne Neustart.<\/p>\n Linux hat in zwanzig Jahren enorme Fortschritte bei der Skalierung gemacht. RCU-Mechanismen und Per-VMA-Sperren haben den Wettbewerb im Kernel sp\u00fcrbar reduziert. mklinux verl\u00e4sst diesen Pfad jedoch bewusst: Es verfeinert nicht die Sperren, es schneidet den Kernel selbst in St\u00fccke. Hinter der Mauer, die sich durch immer feinere Sperren nicht \u00fcberwinden l\u00e4sst, k\u00f6nnte genau dieser Weg der einzige sein, der noch offensteht \u2013 die Benchmark-Zahlen sprechen eine deutliche Sprache.<\/p>\n","protected":false},"excerpt":{"rendered":" Mit mklinux v7.0-mk2 ist der erste \u00f6ffentliche Release eines Multikernel-Systems erschienen, das auf einem einzelnen physischen Rechner mehrere Linux-Kernel vollst\u00e4ndig ohne Hypervisor betreibt. Der Ansatz verspricht nicht nur geringere Latenzen als virtuelle Maschinen, sondern umgeht auch eine seit Jahren wachsende Schw\u00e4che des klassischen Monolithen: die Konkurrenz aller CPU-Kerne um gemeinsame Sperren im Kernel. Statt diese […]<\/p>\n","protected":false},"author":5,"featured_media":53836,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/de\/50130.png","fifu_image_alt":"mklinux erster \u00f6ffentlicher Release bringt mehrere Linux-Kernel ohne Hypervisor","footnotes":""},"categories":[6672],"tags":[],"class_list":["post-50130","post","type-post","status-publish","format-standard","has-post-thumbnail","category-technologie"],"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/de\/50130.png","fifu_image_alt":"mklinux erster \u00f6ffentlicher Release bringt mehrere Linux-Kernel ohne Hypervisor","_links":{"self":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts\/50130","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/comments?post=50130"}],"version-history":[{"count":2,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts\/50130\/revisions"}],"predecessor-version":[{"id":50132,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts\/50130\/revisions\/50132"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/media\/53836"}],"wp:attachment":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/media?parent=50130"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/categories?post=50130"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/tags?post=50130"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Wie mklinux funktioniert: Mehrere Kernel ohne Hypervisor<\/h2>\n
Warum mklinux schneller ist als eine virtuelle Maschine<\/h2>\n
\n
Die Skalierungswand: Warum ein einzelner Kernel an seine Grenzen st\u00f6\u00dft<\/h2>\n
Kernelteilung in der Praxis: Die Benchmark-Zahlen<\/h2>\n
\n
Zwanzig Jahre Idee, ein Jahr bis zum lauff\u00e4higen Code<\/h2>\n