Proč výrobci v poslední době tak moc o ty mikrokernely stojí?
Minix, Hurd i HelenOS jsou salónní teoretické projekty, u kterých není drajv na nasazení od praxe. Autoři si s tím hračičkují, miliskují se, ale prioritou není praktické nasazení a snaha to rychle prakticky co nejdříve nasadit.
Naproti tomu existuje řada skutečných mikrokernelových systémů. Leckde je to i nezbytné z důvodu spolehlivosti, kterou takový systém může nabídnout. PLus řadu dalších vlastností.
Ale Linus jednou řekl, že mikrokernel je blbost, tak prostě je. A všichni budou tvrdit jak je špatný, protože to řekl Linus. Jiný důvod není.
i linus zacal s linuxem jen pro zabavu.
ale byl prvni tak ma nejvetsi pozornost a slavu.
verim, ze jednou i ten slavny hurd bude pouzivan v produkcnim systemu.
co rekl linus o mikrojadru vychazi z dosavadni prakticke zkusenosti,
myslim, ze jeho slova budou platit jeste maximalne 10 let.
pak bude mikrojadro skoro vsude.
Problém mikrojádra je výkon. Přepínání mezi procesy a přiřazování stránek paměti je zátěž. Dokud jsou jen desítky user procesů a celý systém jede v reálu, výkon je v pohodě a systém je tak výkonný, jak ho všichni známe. Ale jakmile se masově nasadí user-space na všechno, tak najednou poběží tisíce, ne-li desetitisíce modůlů, každý s vlastním adresním prostorem. X86 podporuje hardwarově jen 128 procesů, nepletu-li se, při vyšším počtu musí OS vyměňovat položky v tabulce procesů s těmi uloženými jinde. S takovou superzátěží může systém masově užívající user-space zapomenout na výkonnou síť, editaci hudby a vlastně na celé komerční využití. Vždyť i ta fréza se zláme o sklíčidlo dřív, než mikrojádro ráčí přesypat 4000 služeb, jak si možná žádá plánovač, a popoběhnout s naší aplikací. (Tady trochu přeháním, systém můžeme ořezat o grafické rozhraní, vypnout si na chvíli přerušení a je to :-)
Jedině že by se věc vydala cestou posunu kompromisu od efektivních k vysokoúrovňovým jazykům a v budoucnu získaný výkon procesorů se investoval do spolehlivosti systému.
X86 podporuje hardwarově jen 128 procesů, nepletu-li se, při vyšším počtu musí OS vyměňovat položky v tabulce procesů s těmi uloženými jinde.
Předpokládám, že tady hovoříte o Task State Segmentu. Ten má ovšem velikost 8192 položek a většina operačních systémů (včetně Linuxu a Windows) jej stejně nepoužívá pro přepínání vláken — používají klasický softwarový context switch.
Samozřejmě na x86 nejde TSS úplně vypnout (stejně jako segmentace), takže jedna položka v TSS tabulce je skutečně vždy vyplněna, ale po celou dobu běhu Linuxu, Windows i HelenOSu zůstává konstantní. Většina jiných platforem (včetně x86-64) žádnou analogii TSS nemá.
BTW: Nemyslím si, že existuje důvod, aby počet modulů/úloh v mikrojádrovém systému, který provádí několik činností (dejme tomu workload typického desktopu), rostl k tisícům. Už v žádném případě není důvod, aby mikrojádrový systém, který řídí frézu, měl 4000 modulů. Chápu argumentaci přehánením, ale ani s přeháněním by se to nemělo přehánet :-D
Servery v mikrojádrovém systému nemají granularitu tříd, ani nereprezentují jednotlivé instance objektů. Dovedu si představit mnohaprocesorový stroj vyřizující stovky požadavků na sekundu, na kterém budou běžet tisíce serverových úloh. Takové konfigurace dnes ale běží i nad monolitickými systémy.
Závěrem: Určitě nelze zpochybňovat overhead mikrojádrové architektury, ale také by se neměla démonizovat. Není to daň jen tak za nic. Je to daň za explicitní zachycení architektury systému v jeho kódu, vzájemnou izolaci komponent, kompozici složitého systému z jednoduchých stavebních kamenů apod.