Problematický je i vyšší počet procesů, kterými musí volání projít. Každý proces má vlastní mapování virtuálního adresního prostoru na fyzický, a s každým context switchem je potřeba to mapování změnit, což má poměrně velkou režii.
Volání klasického kernelu sice vyžaduje relativně drahý syscall, ale nevyžaduje (ve většině případů) context switch. Díky tomu kernel může hrábnout do paměti aplikace pro vstupní parametry, a předat do ní nakonec výstupní parametry. U mikrokernelů si se servery povídáte pomocí zpráv, což znamená data kopírovat.
Jinými slovy pokud je například operace nad FS zpracovávána v rámci procesů (serverů) VFS, FS, driveru, memory manageru atd., se všemi těmi context switchi, zprávami od/pro aplikaci i mezi servery, a celé to propadne na nevím kolik volání mikrokernelu (tj. syscallů), tak to z hlediska výkonu dopadne fakt mizerně. Nakonec to je důvod, proč třeba Windows NT běží servery převážně v kernelu v rámci jednoho adresního prostoru.
Nějaké informace jsou zde. Některé optimalizace jsou třeba to, že při posílání zprávy PM, VM nebo VFS serveru se použije direct process switch (provede se velmi omezený context switch a objede se scheduler) či že odpovědi od FS serverů se vrací rovnou do procesu (nejdou přes VFS server). Předávání paměti se pak řeší přes memory grants (sdílené stránky, které se odemykají a zamykají podle toho, kdo s nimi potřebuje pracovat), takže data není potřeba kopírovat.
To všechno jsou způsoby jak do jisté míry zmenšit velikost problému, ne jak ho odstranit. Je prostým faktem, že pokud OS rozsekáte na menší izolované části (process isolation), a ta izolace stojí nějaké zdroje, tak utrpí výkon.
Navíc celá věc neřeší chybovost SW, a místo toho se snaží napravovat následky těch chyb. Jako daleko zajímavější mi přijde model checking a formální verifikace, protože to umožňuje zaručit vlastnosti kódu. Jinými slovy to že modul nehrábne do paměti kam nemá, nebo že v něm nedojde k deadlocku, je lepší zajišťovat tak že formálně dokážeme, že to ten modul prostě nemůže udělat. Sice to také stojí nějaké zdroje, ale výsledkem je daleko vyšší spolehlivost.
Take by mě to zajímalo. S overheadem to zatím za pětatřicet let co máme mikrokernely nikdo nevymyslel.
Pokud mají ovladače běžet v userspace a posílat mikrokernelu zprávu, kdykoliv budou chtít načíst data z I/O tak to teda potěž koště...
Ale chápu, že ne každá implementace musí být navržená s ohledem na výkon. A Tannenbaum je akademik...
Čím je častější v poměru k užitné činnosti, tím více vadí. Z principu je však vždycky vyšší než u jinak identického návrhu založeného na monolitické architektuře. Tato přítěž je však akceptovatelná, je-li vyvážena nějakou výhodou, což u mikrojader je: jasně definované rozhraní a striktní modularita, vedoucí k snadnějšímu vývoji a ladění a k vyšší spolehlivosti systému.
Na druhou stranu ale nesouhlasím s (Tanenbaumovým) tvrzením, že monolitická architektura je dnes už anachronismem a vedle mikrojádra nemá opodstatnění; ve spoustě průmyslových a embedded aplikacích by mikrojádro představovalo naprosto zbytečnou režiji, neboť jejich menší rozsah anuluje výhody mikrojádrového konceptu z hlediska vývoje a spolehlivosti je dosahováno uzavřeností a důkladným ad hoc validačním testováním a certifikací každého konkrétního řešení.