Multikernel-Linux: Mehrere Linux-Kernels auf einer Maschine — erstes mklinux-Release veröffentlicht

Mehrere Kernels, eine Maschine, kein Hypervisor

Ende August 2026 hat das Multikernel-Projekt sein erstes öffentliches Release vorgestellt: mklinux v7.0-mk2, angekündigt von Cong Wang auf der Linux-Kernel-Mailingliste (25. August). Die Idee in einem Satz: Mehrere unabhängige Linux-Kernel laufen parallel auf derselben Hardware — auf Bare Metal, ohne Hypervisor und ohne Container-Dienst.

Das ist kein Container-Ansatz und keine Virtualisierung. Es ist ein Linux-Kernel-Fork, der eine Maschine in mehrere eigenständige Kernel-Instanzen aufteilt.

Wie es funktioniert

Ein Host-Kernel verwaltet einen Pool aus CPUs, Speicher und PCI-Geräten und unterteilt diesen Pool in Instanzen.
In jede Instanz bootet er über kexec_file_load() einen eigenen Spawn-Kernel — der läuft dann nativ auf seinen eigenen CPUs, mit eigenem physischem Speicher und eigenen Geräten.
Nichts wird emuliert, nichts wird abgefangen. Geteilt wird nur, was man bewusst teilt.
Instanzen werden über einen Device Tree deklariert, der nach /sys/fs/multikernel/ geschrieben wird. Device-Tree-Overlays verschieben CPUs, Speicher und Geräte zur Laufzeit zwischen Pool und laufenden Instanzen — ohne Reboot.
Instanzen lassen sich herunterfahren, ihre Ressourcen zurückholen und mit einem anderen Kernel neu starten.

Die Basis ist der reguläre Linux-Kernel 7.0: Mit CONFIG_MULTIKERNEL=n baut und verhält sich der Baum exakt wie ein Vanilla-v7.0. Der erste Release unterstützt ausschließlich x86_64; die architekturspezifischen Schnittstellen sind aber bereits abgetrennt, damit weitere Ports folgen können.

Die Benchmarks: Wo der Gewinn herkommt

Gegen KVM: keine „Virtualisierungssteuer"

lmbench auf einem 2-Core-Spawn-Kernel gegen einen ordentlich getunten KVM-Gast (EPT, unrestricted guest, APICv, gepinnte vCPUs) auf einem Dual-Socket Xeon Gold 5418Y:

Kontextwechsel (2 Prozesse): 1,37 µs vs. 3,42 µs → 2,5x
Pipe-Latenz: 3,24 µs vs. 7,06 µs → 2,2x
Null-Syscall: 1,42x, write(): 1,39x
fork + exit: nur 1,07x
Speicherbandbreite und -latenz: auf gleichem Niveau

Die Erklärung ist interessant: Mit Huge Pages ist die verschachtelte Adressübersetzung (EPT) heute quasi kostenlos — hier liegt KVM gleichauf. Was ein Gast nicht vermeiden kann, ist der VM Exit bei jedem Kernel-Eintritt und jedem Aufwecken einer idle vCPU. Genau daraus resultieren die 2,5x beim Kontextwechsel. KVM kann einen Großteil der Lücke mit idle=poll oder mwait-Passthrough schließen — kostet dann aber 12 bis 19 Watt zusätzliche Leistung pro vCPU, der dem Host als 100-prozentig ausgelastet erscheint. Ein Spawn-Kernel bekommt die niedrige Latenz und darf seine Kerne trotzdem in C1–C6 parken.

Skalierung: An den Mauern, die ein einzelner Kernel nicht durchbrechen kann

will-it-scale mit 24 Tasks auf einem Socket — ein Kernel mit 24 Kernen gegen zwei Spawn-Kernel mit je 12:

unlink1: 300K/s → 780K/s (2,6x)
rename1: 2,14x, stat2: 2,10x, open1: 2,02x
Kontrolltests (getppid, futex, poll): exakt 1,00x — null Overhead auf dem Syscall-Pfad

Die Kontrolle ist das starke Argument: Multikernel kostet nichts, aber several Kernel skalieren dort weiter, wo ein einzelner Kernel an globalen Locks hängt — dem Directory-i_rwsem, dem s_vfs_rename_mutex, geteilten Dentry-Refcounts, Folio-Refcounts im Page Cache. Ein einzelner Kernel liefert bei unlink1 ab 2 Tasks rückwärts; bei 48 Tasks noch 40 % dessen, was ein Task allein schafft. Richtet man die Kernel zusätzlich nach den Sockets aus (ein Kernel pro Socket statt einer über beide), wächst unlink1 auf 4,07x.

Bemerkenswert: Das Aufteilen über Netzwerk-Namespaces auf einem einzelnen Kernel bringt exakt nichts — die Mauer liegt unterhalb der Namespace-Grenze. Genau das ist das Problem, das Multikernel adressiert.

Ehrliche Einschränkungen

Die Entwickler legen die Caveats selbst offen — das allein hebt den Beitrag von typischen Vendor-Marketing ab:

Der open1-Gewinn stammt großteils von AppArmor-Label-Sharing und fällt mit abgeschaltetem LSM auf 1,00x (unlink1 hält 2,24x).
mmap1 brauchte 8-GB-Instanzen, damit vm_committed_as-Batching nicht stört.
Workloads, die einen Adressraum über alle Kerne teilen (Threads-Modus), können nicht geteilt werden und gewinnen nichts.

Isolierung ohne Virtualisierungs-Overhead

Der zweite Selling-Punkt neben Geschwindigkeit:

Gegenüber Containern: Instanzen teilen sich keinen Kernel. Ein Lock-Hänger, eine Kernel-Panic oder ein Exploit in einem Kernel erreicht die anderen nicht.
Gegenüber VMs: Kein VM-Exit-Pfad, keine zweite Stufe an Page Tables, kein Gerätemodell.

Als Zielgruppen nennt die Firma KI/ML-Training und -Inferenz, latenzempfindliche Dienste sowie Workloads mit strikten Sicherheits- und Isolierungsvorgaben. API- und ABI-Kompatibilität zu bestehenden Linux-Anwendungen soll voll erhalten bleiben.

Vom RFC zum Release — knapp ein Jahr

Das Projekt ist kein Blitz aus heiterem Himmel: Im September 2025 stellte Cong Wang die Architektur als RFC-Patchserie auf der LKML vor (7 Patches), begleitet von einer kritisch-analytischen Betrachtung auf LWN und teils scharfer Community-Diskussion — viel Marketing, damals wenig prüfbarer Code. Knapp ein Jahr später steht der Code öffentlich auf GitHub, mit messbaren, reproduzierbaren Angaben und offengelegten Schwächen.

Wer dahintersteckt: Cong Wang, Linux-Kernel-Entwickler mit 16 Jahren Erfahrung, Maintainer des Traffic-Control-Subsystems seit 2017, über 1.000 Commits im Kernel, zuvor Team-Lead bei ByteDance. Die dahinter stehende Firma ist Multikernel Technologies (multikernel.io), mit Wang als einzigem „Leadership"-Eintrag. Der Tree soll künftige Upstream-Releases weiterverfolgen; eigenständig tragfähige Teile sollen separat zum Upstream-Review eingereicht werden.

Kurios am Rande: Der Name MkLinux ist historisch doppelt vergeben — in den 90ern hieß so bereits das Apple/OSF-Projekt, das Linux über den Mach-Microkernel auf Power Macs brachte.

Einordnung

Die Zahlen stammen vom Anbieter, gemessen auf dem eigenen Release und einer konkreten Maschine — unabhängige Verification steht noch aus. Es ist ein erstes Test-Release: eine Architektur, eine kleine Firma, x86_64 only. Für Produktivumgebungen ist das nichts.

Trotzdem ist der Ansatz ernst zu nehmen, denn er zielt auf ein echtes, gut dokumentiertes Problem: globale Kernel-Locks, die weder Threads noch Namespaces skalierbar machen. Die Kontrolltests auf 1,00x und die selbst offengelegten Schwächen sprechen für eine ehrliche Arbeitsweise. Interessant wird jetzt: Bestätigen unabhängige Benchmarks (Stichwort Phoronix) die Werte? Schaffen es Teile upstream in den Hauptlinien-Kernel? Und folgt der zweite Architektur-Port? Für Bare-Metal-KI-Boxen mit Multi-Tenant-Anforderungen ist das jedenfalls ein Designpunkt im Lösungsraum, den man kennen sollte.

source@tmkis:~▊