Vlákno názorů k článku Proč není Hurd ani po dvaceti letech hotový? od Mard - Jednoúlohový systém je z principu rychlejší než víceúlohový....
-
Mard (neregistrovaný)
Jednoúlohový systém je z principu rychlejší než víceúlohový. Stejně tak mikrojádro se nadřazenými démony je z principu pomalejší než komplexní monokernel - jednoduše proto, že mikrojádro musí řešit mnoho dalších věcí a složitějším způsobem než monokernel. Ale i přes toto tvrzení jsem si jist, že cesta dalšího vývoje půjde směrem k mikrokernelu. Důvody mám dva. Jednak bezpečnost běhu jednotlivých procesů a za druhé stálý nárůst všeho možného HW (takže se domnívám že stále rostoucí jádro je nadále neudržitelné).
S tvrzením že víceprocesorové systémy (či cpu s více jádry) snáze pracují s mikrojádrem bych si příliš jistý nebyl. Obecně běh jádra je časově zanedbatelný proti běhu aplikace (resp. by to tak mělo být) proto je celkem jedno jak dobře jde navláknovat běh jádra, ale podstatné je, jak se mi podaří řešit paralelní běh aplikací. Zde velké rozdíly mezi mikrojádrem a monokernelem nevidím. -
Sten (neregistrovaný)
Běh jádra vůbec není časově zanedbatelný. Třeba veškeré čtení dat z disku jde přes jádro, stejně tak veškerá interakce s uživatelem (obrazovka, klávesnice, myš). To všechno lze paralelizovat, čímž se výkon systému na vícejaderných strojích dost razantně zvýší, proto se v Linuxu tak pracně odstraňoval BKL a proto se tam teď řeší bezzámkové cache. Něco, co by v mikrojaderné architektuře nikdy nevzniklo, protože tam se tyhle problémy řeší pomocí MMU (hardware).
-
Sten (neregistrovaný)
Běžně asi jednu pětinu času, který využije příslušný proces, u virtualizace klidně i přes polovinu. Oboje je fakt hodně. Navíc se to týká všech procesů, takže nepatrné zrychlení jádra výrazně zrychlí celý systém.
Tak třeba pokud odstraníte globální zámek (BKL), který v mikrojádrech nemůže být by design, tak se rychlost zvýší až tolikrát, kolik máte jader.
Tak, že příslušné stránky se označí jako COW, případně pouze pro čtení, takže je můžete číst bez zamykání a nikdo vám je během čtení nezmění. Bez MMU to lze dělat podobně, ale je nutné provádět full memory barriery.
-
Lael Ophir (neregistrovaný)
BKL je problém synchronizace. U mikrokernelu se zamykání řeší už ve stádiu návrhu. U NT taky. U Linuxu se to řešilo tak, že Linus najprve přišel s BKL, protože nerozumí designu a protože se to tak velmi snadno píše. A pak se všichni dlouhá léta snažili BKL odstranit. Moc se to ale nepovedlo :/
-
Yenya (neregistrovaný)
> BKL je pouze důsledek návrhu (resp. absence návrhu).
Podle mě tento sarkasmus není na místě. Uvědomte si, že Linux vznikal v době, kdy víceprocesorové stroje byly doménou mainframů a superpočítačů, a v oblasti PC pouze exotů jako byl Intergraph (pamatujete někdo?).
Pokud byste měl na výběr udělat systém rychle, ale bez podpory více procesorů, a získal za to použitelnost na většině běžných zařízení, a tím větší rozšíření, a tím víc vývojářů, a tím po několika cyklech dostatek pracovní síly na reimplementaci, a naproti tomu udělat systém "pořádně" a pomalu s nedostatkem vývojářů, co byste si vybral? Přitom tehdy ani nebylo jasné jestli vývoj půjde k opravdu symetrickým multiprocesorům, nebo třeba k nějakým asymetrickým koprocesorům (jako je dnes Cell nebo různé APU architektury).
BKL umožnil _postupné_ zavedení podpory víceprocesorových systémů, a z těch míst kde opravdu vadil zmizel _dávno_ předtím, než se tyhle systémy začaly být masově rozšířené. Přitom ale už dlouho je Linux škálovatelnější než jiné systémy, které s paralelismem počítaly od začátku (Solaris, Windows NT).
Podle mě BKL bylo ve své době správné rozhodnutí.
Bylo by zajímavé podívat se z hlediska škálovatelnosti na mikrokernelové systémy. Kolik serverů v HURDu nebo v QNX umí využít víc než jedno jádro? Mají dnešní mikrokernely udělané fronty zpráv tak, aby bez zamykání mohlo více serverů číst z front události (jako to umožňují dnešní multiqueue síťové karty)? A umožňuje dnešní mikrokernel aby jeden klientský proces zařazoval požadavky na konkrétní server do fronty tak, aby se všechny požadavky jednoho klienta zpracovával ten server pořád na tom stejném CPU jádře? V monolitickém systému je to triviální - ty "požadavky" jsou volání funkce, které běží v tomtéž kontextu, a tedy obvykle na tomtéž jádře. Podle mě fronta zpráv serveru na většině dnešních mikrokernelů bude taková pěkná obdoba BKL.
-
Lael Ophir (neregistrovaný)
Jak došlo na BKL? Linus psal terminálový emulátor, ke kterému bylo potřeba pár funkcí, a nakonec mu z toho vylezl minimalistický OS. Napsal ho podle manuálů komerčních unixů, nad designem moc nepřemýšlel. Vizte jeho slova:
http://groups.google.com/group/comp.os.minix/msg/b813d52cbc5a044bBohužel design OS se později těžko opravuje. Implementace threadingu použitelným způsobem (NPTL) byla uvedena až po 12 letech v kernelu 2.6, po obrovském úsilí. I tak je výsledek slabý ve srovnání s NT i Solarisem. Při slušném návrhu by nebyl problém threading implementovat ihned, nebylo by to moc práce navíc. Podobně bylo možné napsat kernel od začátku preemptivní, a ne pracně dodělávat po všech stránkách špatný hack jménem PREEMPT_VOLUNTARY, případně dokonce PREEMPT, na který si snad dodnes netroufla žádná major distribuce.
Ohledně škálovatelnosti Linuxu to vidíte velmi optimisticky.
BTW u koprocesorů je zajímavá možnost psát v .NETových jazycích, překládat je do CIL bytecode, a ten pak překládat dynamicky do strojáku. To může vést k tomu, že CIL bytekód webového nebo mailového serveru přeložíte podle konfigurace čistě pro CPU, nebo kus pro CPU a kus pro inteligentní síťovou kartu, nebo třeba pro kombinaci CPU+GPU. MS na to má pěkný research projekt nad Singularity. Jsem zvědavý na komerční využití. Třeba budou za pár let řadiče RAIDu běžet část kódu FS.
Napsat reentrantní server přece není technicky problém. Řešení fronty také není větší problém, nakonec totéž úspěšně řeší většina SMP kernelů (a fakt nevidím důvod, aby to vedlo na giant lock). A zařazování požadavků na konkrétní server a CPU je o optimalizaci scheduleru. Odesilatele požadavku přece znáte, takže víte, na kterém CPU běží. Pro cc:NUMA navíc můžete použít metriky: kolik stojí z daného CPU přístup k dané části paměti, danému host bridge atd - má to podporu i v ACPI pomocí tabulek SRAT a SLIT.
Mikrokernely mají samozřejmě vyšší overhead než jiné architektury. Ale zase se snáze udržují a jsou spolehlivější. Přitom existuje řada různých přístupů. Viz NT kernel s vybranými servery běžícími z důvodu výkonu v kernel mode (hlavní výhodou je modularita a škálovatelnost), případně Singularity se Software Isolated Processes, které zásadním způsobem zmenšují overhead mikrokernelu. -
Yenya (neregistrovaný)
> Linus psal terminálový emulátor
Nic o emulátoru v tom článku není. Linus psal operační systém.
> Bohužel design OS se později těžko opravuje.
Právěže ne. Vývojový model Linuxu je přímo postaven na tom, že lepší je mít aspoň nějaký kód teď a opravit ho až někoho fakt bude štvát, a ne čekat 20 let na ideální kód jako HURD nebo sice méně než 20 let, ale pak se zavazovat ke kompatibilitě nekonečně dlouho jako Solaris nebo NT.
> Implementace threadingu použitelným způsobem
> (NPTL) byla uvedena až po 12 letech v kernelu
> 2.6, po obrovském úsilí.Opět je vidět, že nevíte o čem mluvíte. Implementace threadingu v kernelu se jmenuje clone() a je v kernelu už od 2.2 nebo 2.0. A implementace byla naprosto triviální. NPTL je jedna z implementací rozhraní POSIX threads pro user-space. Na podpoře vláken v kernelu je docela nezávislá.
> Podobně bylo možné napsat kernel od začátku
> preemptivní, a ne pracně dodělávat po všech
> stránkách špatný hack jménem PREEMPT_VOLUNTARY,
> případně dokonce PREEMPT, na který si snad
> dodnes netroufla žádná major distribuce.Bylo to sice možné, ale dopadli bychom jako HURD - nikdy by takový systém nevznikl. Nepreemptivní jádro se totiž dá napsat výrazně snadněji.
Ohledně PREEMPT - nevím po kterých všech stránkách je špatný, podle mě je prudce elegantní. Využívá totiž zajímavého faktu, a to že kernel byl mezitím portovaný na SMP systémy, a tedy do sekcí u kterých vadí paralelní běh byly dopsány zámky nebo BKL. A PREEMPT pak není nic jiného než povolit přepnutí kontextu i na UP v situaci, kdy nedržíte žádný zámek (a tedy kódu nevadí ani skutečný paralelismus SMP, natož umělý vyvolaný přepnutím kontextu).
> MS na to má pěkný research projekt nad
> Singularity. Jsem zvědavý na komerční využití.Já taky :-) Podle mě žádné nebude.
> Třeba budou za pár let řadiče RAIDu běžet část
> kódu FS.Tady už jsme byli. Říká vám něco pojem I2O?
Neprosadilo se to. A dneska by to z důvodů lokality dat mělo ještě větší problém než tehdy.> Napsat reentrantní server přece není technicky
> problém. Řešení fronty také není větší problém,
> nakonec totéž úspěšně řeší většina SMP kernelů
> (a fakt nevidím důvod, aby to vedlo na giant
> lock).Technicky to není problém. Teoretici vám vždycky vysvětlí, že teoreticky může být mikrokernel stejně rychlý jako monolitický kernel. Praxe ovšem pokulhává. Který současný mikrokernel má servery využívající více CPU?
Fronta ovšem obvykle na globální zámek vede, pokud se nechcete vzdát garance pořadí požadavků v té frontě. Což by zase znamenalo úplně nový návrh API pro zasílání zpráv v tom mikrokernelu.
> zařazování požadavků na konkrétní server a CPU
> je o optimalizaci scheduleru.Znovu: teoreticky to jde, v praxi to nikdo nedělá. A přitom v monolitickém kernelu to máte zadarmo: když více vláken volá tu stejnou funkci, triviálně běží požadavek každého vlákna na tom svém CPU.
NT není mikrokernel. Aspoň ve srovnání s Linuxem ze stejné doby mi vždycky ten NT "mikrokernel" (plus hal.exe) vyšel větší než monolitický Linux. NT je monolitický kernel. Některé části NT jsou v kernelu a jiné systémy je mají mimo kernel (grafika) a některé zase naopak.
-
Yenya (neregistrovaný)
> http://groups.google.com/group/comp.os.minix/msg/b813d52cbc5a044b
> Třeba budou za pár let řadiče RAIDu běžet část kódu FS.
Tak jsem se do výše citovaného threadu začetl ještě víc, a je tam zmiňovaný SCSI řadič NCR, který taky mohl vykonávat kusy kódu dodané operačním systémem. To je rok 1991 prosím. Tak se mi zdá že Microsoft vynalézá dvacet(*) let staré kolo.
(*) minimálně; řekl bych že mainframy tohle mohly mít ještě dalších dvacet let zpátky.
-
koudy (neregistrovaný)
Vzdycky se leknu jestli ctu dobre, protoze to jak si temer vzdy ohnete pravdu tak aby z toho vysli win dobre me zarazi a pak si vsimnu autora, usmeju se a nereaguju.
Vy to v podstate delate take, ale az po tom co vam nekdo Vasi pravdu vyvrati.. Pak uz se k vlaknu diskuse nevracite. -
Lael Ophir (neregistrovaný)
Z mého pohledu ohýbají pravdu lidé jako vy, tak aby jim vyšlo něco jiného. Některé věci jsou holt otázkou intepretace.
To je zajímavé. Když svůj názor na věc v diskusi dál rozvádím, tak jsem ten špatný, který začíná flame war. Když nemám trpělivost a čas na všechno odpovídat, tak jsem ten špatný, kdo z diskuse utíká, když mu jeho pravdu vyvrátí. Co z toho plyne? Vždycky je někdo nespokojený :)
ČLÁNKY DO MAILU