Tým vývojářů ve společnosti Multikernel Technologies rozvíjí neobvyklou variantu nasazení Linuxu s názvem split-kernel architecture. Na jednom fyzickém stroji nespouští více procesů nad společným jádrem jako kontejnery nebo více virtuálních počítačů jako hypervizory. Místo toho rozdělí hardware mezi několik samostatných instancí Linuxu. Každá má vlastní jádro, plánovač, paměť a vyhrazené procesorové prostředky.

Označení multikernel není nové. V akademickém světě se používá nejméně od projektu Barrelfish z roku 2009, který zmíníme níže. Multikernel Linux od Multikernel Technologies ale není pokračováním Barrelfish ani novou linuxovou distribucí. Jde o fork linuxového jádra s vlastními rozšířeními a nástroji.

Multikernel Technologies zveřejnil implementaci v září 2025 a uvedl, že první patche odeslal také do linuxové mailing listové konference. To není totéž jako začlenění do hlavní větve Linuxu. Pro použití je nutné sestavit upravený kernel z repozitáře projektu multikernel/linux, který je forkem oficiálního linuxového jádra.

Rozdělení na aplikační kernel a device kernel

Běžný Linux je monolitické jádro. Aplikační procesy, ovladače zařízení, obsluha přerušení, síťový stack a blokové I/O běží uvnitř jedné instance kernelu. Izolace kontejnerů proto končí na hranici namespaces, cgroups a bezpečnostních mechanismů téhož jádra. Chyba v jeho kódu, ovladači nebo privilegovaném subsystému může mít dopad na všechny kontejnery hostitele.

Multikernel Linux dělí systém na několik kernelových instancí. Aplikační kernel obsluhuje konkrétní pracovní zátěž a dostane vlastní sadu CPU a paměti. Vedle něj běží device kernel, jemuž zůstávají ovladače, fyzická zařízení a obsluha přerušení. Přenos dat mezi nimi využívá sdílenou paměť a fronty deskriptorů.

Důležitý efekt je strukturální. Pokud jsou přerušení směrována do device kernelu na jiných jádrech, aplikační kernel je přímo neobsluhuje. U služeb citlivých na kolísání latence tak může být oddělena aplikační část od síťových, blokových a ovladačových událostí.

Projekt k zavádění dalších kernelů používá existující jádrovou infrastrukturu kexec. Hostitelské jádro připraví paměť, předá novému jádru popis přidělených zdrojů a spustí je na vyhrazených CPU. Nejde tedy o emulovaný počítač ani o guest OS běžící nad KVM. Nový kernel běží přímo na přiděleném hardwaru, se svým vlastním plánovačem, síťovým stackem a pohledem na zařízení.

Tvrzení „bez hypervizoru“ nelze chápat dogamaticky, když přijde na praktický provoz. Na fyzickém serveru architektura nepřidává vlastní vrstvu typu KVM, Xen nebo ESXi. Pokud však multikernel běží uvnitř pronajatého cloudového virtuálního stroje, bude-li mít samozřejmě podporu pro multikelner, hypervizor poskytovatele zůstává pod ním.

Kernel, Kerf, Lazy CMA a DAXFS

Jak bylo řečeno, základ tvoří multijádrový fork linuxového jádra sestavený s volbou CONFIG_MULTIKERNEL. Po zavedení se chová jako běžné hostitelské jádro, ale umí spouštět další instance. Vedle něj projekt zveřejňuje několik pomocných komponent.

Nástroj Kerf vytváří instance, kontroluje kolize ve zdrojích, přiděluje CPU a paměť, načítá kernel a řídí jeho životní cyklus. Zatímco u virtuálních strojů podobnou roli obvykle plní hypervizor a orchestrace nad ním, zde Kerf pracuje přímo s rozdělením fyzických zdrojů. Jeho repozitář zmiňuje i práci s device tree a dynamickými překryvy konfigurace.

Další součástí je Lazy CMA modul pro přidělení souvislé fyzické paměti až za běhu. Klasická Contiguous Memory Allocator obvykle vyžaduje rezervaci při startu systému; Lazy CMA se pokouší uvolnit a získat potřebný blok dynamicky. Zvyšuje to pružnost, ale neodstraňuje fyzikální limit fragmentované paměti: na dlouho běžícím a zatíženém serveru může souvislá alokace selhat.

DAXFS je volitelný souborový systém pro sdílená data mezi instancemi. Pracuje s DAX-capable pamětí, například persistentní pamětí, CXL memory nebo DMA buffery, a umožňuje sdílený jmenný prostor i zero-copy přístup. Není to univerzální náhrada ext4, XFS nebo síťového souborového systému: nepodporuje běžné blokové disky a počítá s byte-addressable pamětí i cache-koherentním prostředím.

Kde multikernel najde uplatnění

Nejsilnější argument má technologie tam, kde je důležitější předvídatelnost a oddělení poruchových domén než maximální hustota malých služeb. Typickým příkladem jsou napříkald síťové a databázové služby citlivé na tail latency nebo zařízení s vlastní I/O cestou.

Ve storage appliance může být samostatný kernel určen pro front-end komunikaci, jiný pro datovou vrstvu a další pro ovladače NVMe či SAS. Chyba ovladače pak teoreticky nemusí znamenat pád celého řídicího uzlu. Podobně lze oddělit inference, pomocné služby a přístup ke GPU. Firma cílí i na sandboxování AI agentů, kdy má každý agent dostat vlastní kernel místo sdílení jádra kontejnerového hostitele.

To ovšem neznamená, že multikernel automaticky nahrazuje kontejnery. Naopak, jedna kernelová instance může obsloužit skupinu kontejnerů a stát se tvrdší hranicí mezi většími třídami zátěže. Pro desítky tisíc krátkodobých procesů by samostatné jádro pro každý z nich nedávalo smysl kvůli paměťové režii, správě obrazů i statickému přidělení procesorových prostředků.

Architektura také není plnohodnotnou náhradou bezpečnostního modelu hypervizoru. Samotné FAQ projektu připouští, že kompromitované jádro může ovlivnit další kernely na stejném uzlu. Podepisování kernelů při kexec, kernel lockdown, IOMMU a paměťové šifrování riziko snižují, ale hranice důvěry závisí na konkrétním hardwaru a konfiguraci.

Inspirace v Barrelfish a Popcorn Linuxu

Původní multikernel myšlenka vznikla jako reakce na růst počtu jader a heterogenní hardware. Například dnes již neaktivní projekt Barrelfish z ETH Zürich chápal vícejádrový počítač jako síť samostatných výpočetních uzlů. Jádra si data předávala přímo pomocí zpráv, nikoli jen přes společný globální stav. Každé pracovalo s vlastní kopií potřebných systémových dat a návrh operačního systému neměl být pevně svázán s konkrétním počtem, typem ani propojením procesorových jader.

Barrelfish byl výzkumný operační systém psaný od základu, ne rozšířený Linux. Jeho význam spočívá především v architektonické debatě. Multikernel Technologies naopak vyžívá existující linuxové jádro, jeho ovladače, API a kód kexec. Výsledkem je pragmatičtější, ale méně radikální přístup.

Příbuzným a stále aktivním projektem je Popcorn Linux, který se věnuje multikernelům přes odlišné instrukční architektury. Multikernel Linux jej uvádí jako jednu z inspirací.

Alternativy řeší jiný kompromis

Kontejnery zůstávají nejlevnější cestou k hustému provozu Linuxových aplikací. Sdílejí jedno jádro, rychle startují a dobře zapadají do Kubernetes, ale neposkytují samostatný kernelový trust boundary.

KVM, Xen, VMware a microVM systémy typu Firecracker dávají každé instanci vlastní guest kernel a silnější izolační hranici. Cenou je hypervizor, virtualizované nebo paravirtualizované zařízení, správa obrazů a v některých případech znatelnější latence I/O. Moderní virtualizace se SR-IOV a hardwarovou podporou je přitom často velmi rychlá; nelze její režii paušálně označit za 5 až 20 procent.

Jailhouse cílí na statické rozdělení strojů pro real-time a embedded prostředí. Unikernely zase spojují aplikaci a minimum operačního systému do jednoho obrazu, obvykle ale vyžadují úpravu aplikací nebo specializované runtime. Multikernel Linux se snaží ponechat kompatibilitu běžných linuxových aplikací a přitom posunout izolaci nad úroveň kontejneru.

Open source kód a komerční provoz

Licenční situace je transparentnější než označení produktů na webu naznačuje. Fork Linuxu dědí licenci GPL-2.0-only; výjimka pro systémová volání se týká uživatelského rozhraní Linuxu, ne obecného uzavřeného odvozování kernelu.

Lazy CMA a DAXFS jsou vedeny pod GPL-2.0. Kerf má licenci Apache-2.0, stejně jako nástroj kmorph. Zdrojové kódy těchto komponent jsou veřejně dostupné a lze je studovat, upravovat a používat podle podmínek příslušných licencí.

Open source základ ale automaticky neznamená bezplatný komerční produkt ve smyslu provozní odpovědnosti. Multikernel Technologies prodává validované a podepsané buildy, hardwarovou kvalifikaci, bezpečnostní backporty, servisní smlouvy, integrační práci a podporu. Z veřejných repozitářů také nelze odvodit, že jsou otevřené všechny části interní buildovací infrastruktury či produktového provozu.

Multikernel Linux je prozatím vhodné číst jako technologický směr pro specializovanou infrastrukturu, nikoli jako nový standard linuxových serverů. Přináší zajímavé propojení kernelové izolace, přímého přístupu k hardwaru a existujícího Linuxového ekosystému. Jeho skutečnou hodnotu ale určí až začlenění do širšího vývojového procesu Linuxu, nezávislá měření a zkušenosti z provozu mimo vlastní demonstrace výrobce. Vzhledem k současnému hardwarovému směru, který neustále zvyšuje počet dostupných jader v rámci jednoho CPU je budoucnost pro multikernel linux slibná.