Jaderné noviny – 9. 5. 2013: Jádro už téměř bez tiku

27. 5. 2013 | Luboš Doležel | Jaderné noviny | 4956×

Aktuální verze jádra. Citáty týdne: Russell King, Jeff Garzik, Daniel Phillips. Ve verzi 3.10 s jádrem (skoro) bez tiku.

Obsah

• Aktuální verze jádra
• Citáty týdne: Russell King, Jeff Garzik, Daniel Phillips
• Ve verzi 3.10 s jádrem (skoro) bez tiku

Aktuální verze jádra

Začleňovací okno 3.10 zůstává otevřené; přehled toho, co bylo začleněno, najdete v originále článku.

Stabilní aktualizace: verze 3.9.1, 3.8.12, 3.4.44 a 3.0.77 vyšly 7. května.

Citáty týdne: Russell King, Jeff Garzik, Daniel Phillips

Můj závěr je takový, že sestavovací systémy a systémy pro testování bootu v prostředí open source zkrátka nefungují, protože se nikdo nezabývá výsledky. Proč taky – správci mají dost práce jen s tím přečíst každý měsíc 6500+ e-mailů na mailing listech. Proč se zatěžovat pohledem na webovou stránku, když to může znamenat ještě víc práce.

-- Russell King

Když jsem se poprvé nachomýtl k Linuxu, neměl žádné PCI API (nyní zvané hotplug nebo API zařízení) a zasílání patchů byla docela bolestivá procedura připomínající házení špaget proti zdi: odesílání a přeposílání, zatímco Linus i správci museli ručně řešit konflikty při slučování. <brrrr>

Dostat do Linuxu nějakou podporu hardwaru byl opravdu boj. Obrovské množství dokumentace k hardwaru bylo neveřejné nebo zkrátka nedostupné.

Práce na správě paměti, systémech souborů nebo plánovači byla taková sexy PhD práce, která přitahovala lidi. Na druhou stranu jsem cítil, že ovladače hardwaru byly ignorovány jako nepřitažlivá otrocká práce. Což možná i byla. Ale každý další ovladač hardwaru pomohl Linux rozšířit mezi ještě více lidí. Alan Cox a Don Becker tehdy odvedli obrovské množství práce. Teď když je Linux tam, kde je, většina výrobců hardwaru má aktivní zájem o open source ovladače (až na NVIDIA samozřejmě). Jádro se dostalo opravdu daleko.

Pro mě teď nastal čas přesunout se do nových oblastí open source, mimo jádro.

-- Jeff Garzik

Snad se ani nedá přehnat, jak spokojeni s výsledky jsme. Hlavně po prvních výsledcích testů dbench, které byly ostudné: více než pětkrát pomalejší oproti ext4. Ukázalo se, že problémem byla neefektivní alokace inodů. Hirofumi předělal zoufale pomalé prohledávání itable btree na prostou „alokaci dalšího čísla inode“ a hle! Ze chcípáka se stala hvězda. Je tu ale jedno velké varování: kód, se kterým máme takové výsledky, aktuálně závisí na tomto speciálním hacku zrychlujícím alokaci inodů. Jsme si ale jisti, že náš produkční kód pro alokaci inodů bude mít oproti tomuto dočasnému hacku velkou režii.

-- Daniel Phillips tvrdí, že překoná tmpfs

Linuxové jádro je nadále zosobněním kvality. Od původní zprávy Coverity Scan z roku 2008 zkoumané verze Linuxu trvale dosahovaly hustoty chyb nižší než 1,0 a verze z let 2011 a 2012 dosahovaly hustoty pod 0,7. V roce 2011 Coverity proskenovalo více než 6,8 milionu řádek linuxového kódu a odhalilo hustotu chyb 0,62. V roce 2012 Coverity prošlo více než 7,4 milionu řádek linuxového kódu a zjištěná chybovost byla 0,66. Při poslední kontrole Coverity prošlo 7,6 milionu řádek Linuxu 3.8 a chybovost byla 0,59.

-- Coverity

Ve verzi 3.10 s jádrem (skoro) bez tiku

Na obvyklém linuxovém systému bude každé běžící CPU 100 až 1000krát za sekundu probuzeno pravidelným přerušením hodin. Toto přerušení je znamením procesoru, že se má promyslet, jaké procesy by měly běžet, že se mají dohnat zpětná volání RCU a obecně se má dělat jakýkoliv potřebný úklid. Tento pravidelný „tik“ by se dal porovnat s nechvalně známým velkým jaderným zámkem [big kernel lock; BKL]: je pohodlné ho mít, ale má to i dopad na výkon, kvůli kterému se ho vývojáři chtějí zbavit. Hlavním rozdílem je to, že odstranění tiku trvalo poněkud déle než odstranění BKL. Jádro 3.10 bude ale velkým krokem vpřed díky přidání režimu „úplného NOHZ“ – ale je tu ještě mnoho omezení.

Linux měl částečné řešení problému s tikem už roky, a to v podobě konfigurační volby CONFIG_NO_HZ. Pokud je tato volba nastavena, pak bude tik vypnut, ale jen v případě, že je CPU nečinné. Tento režim situaci značně zlepšuje; umožňuje procesorům, aby zůstávaly v hlubokém spánku, čímž je omezována spotřeba. Systémy s virtualizovanými hosty z tohoto také profitují, protože jinak by každý host obsluhoval přerušení, i když by neměl dělat nic. Abychom to shrnuli: vypnutí tiku časovače je natolik užitečné, že to většina distribucí tak má ve výchozím nastavení.

Protože je ponechávání CPU ve spánku obecně považováno za dobrou věc, člověk by mohl váhat, proč je toto nastavení vůbec volitelné. Odpovědí je to, že se tím zvyšuje režie spojená s probuzením CPU, což lehce prodlužuje dobu nutnou k tomu, aby spící CPU začalo zase pracovat. Tato režie může v prostředích, kde je latence důležitá, být až příliš velká. Všem ostatním lze ale vypnutí tiku CPU doporučit; u systémů poháněných z baterií to platí dvojnásob.

Další krok – vypnout tik u CPU, na kterých něco běží – je mnohem pracnější a nemá takový přínos, takže nepřekvapí, že trvalo, než na to došlo. Frederic Weisbecker se na to konečně vrhnul až v roce 2010; po mnoha změnách a výpomoci od ostatních (Paul McKenney se například postaral o rozsáhlé změny v RCU) se tato práce dostala do jádra 3.10.

V jádře 3.10 byla volba CONFIG_NO_HZ nahrazena výběrem ze tří možností:

• CONFIG_HZ_PERIODIC je stará možnost, kdy tik běží vždy.
• CONFIG_NO_HZ_IDLE (výchozí nastavení) znamená, že se tik bude vypínat při nečinnosti, což odpovídá předchozímu významu CONFIG_NO_HZ.
• CONFIG_NO_HZ_FULL povolí režim „úplně“ bez tiku.

Sestavovací systém byl upraven tak, aby make oldconfig ve verzi 3.10 vedlo k původnímu nastavení CONFIG_NO_HZ bez zásahu uživatele. Režim úplně bez tiku je standardně vypnutý; než jej povolíte, měli byste si být vědomi několika věcí.

Mezi požadavky je to, že CPU, která mohou běžet bez tiku, musejí být zvolena parametrem nohz_full= na příkazové řádce jádra. Bootovací CPU v tomto režimu běžet nemůže – alespoň jedno CPU musí stále přijímat přerušení a dělat běžnou práci. Volba CONFIG_NO_HZ_FULL_ALL zajistí, že všechna CPU (mimo bootovací CPU) standardně poběží v režimu bez tiku; je ale stále možné to volbou nohz_full změnit. Volbu CPU bez tiku nelze za běhu měnit; bylo by to příliš náročné implementovat a zatím není důvod to umožňovat.

I tak bude běžící CPU bez tiku jen za předpokladu, že je na tomto procesoru jen jediný spustitelný [runnable] proces. Jakmile se objeví druhý, pak bude tik zapotřebí pro funkčnost plánovače. A i s jediným procesem bude stále nutný alespoň jeden tik za sekundu, aby byl plánovač spokojený. I tak je ale pokles z třeba 1000 Hz na 1 Hz velkým zlepšením. Odchylka času kvůli přerušením časovače bude skoro pryč a podle Inga Molnara se ušetří až 1 % času CPU.

Existují typy zátěže, které z tohoto budou značně profitovat. High-performance computing (HPC) a realtime jsou evidentními zájemci; v obou případech je vyhrazení procesoru pro jedinou úlohu běžnou záležitostí. Ale v době, kdy i telefony mají čtyřjádrové procesory, nebude jediná spustitelná úloha na CPU neobvyklou situací.

Pro správné fungování je ale aktuálně nutné ještě hodně dalších věcí. Přinejmenším je potřeba, aby administrátor aktivně využíval „CPU affinity“ pro udržení relevantních procesů (včetně jaderných vláken) mimo dotčené procesory. Je také nutné donastavit RCU; vše najdete v dokumentaci.

Běh jádra bez tiku tak, jak je v Linuxu 3.10, je jasným krokem vpřed, ale je nutné mít na paměti, že jde o rozpracované dílo. Zbývá ještě dost práce, včetně podpory 32bitových procesorů (už je na to patch), odstranění posledního zbylého tiku za sekundu, potlačení nechtěných dopadů na statistiky plánovače a vyvažování a samozřejmě opravování chyb. Jde o rozsáhlou změnu v tom, jak jádro funguje; jakmile se funkci dostane většího testování, tak se jistě objeví všelijaké podivné důsledky.

Největší položkou na TODO listu je ale nepochybně odstranění požadavku na jediný spustitelný proces. Pro případ, že si toho vývojáři nevšimli, dal Linus jasně najevo, co si myslí:

Dokud bude volba NOHZ jen pro zátež typu HPC, pak budu mít popravdě pocit, že to za to nestojí. _Jedinou_ věcí, kvůli které to má smysl, jsou „budoucí plány“, kde by to už mělo pomoci při skutečných zátěžích.

Proto je pravděpodobné, že toto omezení bude v budoucích vývojových cyklech odstraněno, spolu s dalšími nepříjemnostmi. Do té doby tu máme Linux 3.10, který bude obsahovat významný milník ve vývoji linuxového jádra: částečné odstranění původu latence a režie, který se v jádře nacházel už od prvního vydání. Ani BKL nevydržel zdaleka tak dlouho.

       

Komentáře

[David Jaša]

nachomítnul (ale fuj); což odpovídá předchozímu významu CONFIG_NO_HZ_IDLE (nepřebývá tam něco?)

[Luboš Doležel (Doli)]

Ach jo, opraveno.

[dsfsadfasdf]

pokud odstrani i ten posledni tik jednou za sekundu a na procesoru pojede jen jeden proces, tak tenhle proces si pojede v kuse bez preruseni, pokud teda nedojde k nejake i/o operaci, atd.?

[Atom321]

No jasně, o tom to celé je

[dsfsadfasdf]

nebo by jadro nemelo vubec preruseni a kazdy uzivatelsky kod mohl semtam zavolat kernel samo schedule ale nekde jsem to uz videl.

[xxxx]

+ 1

[Grunt]

BIOS v 2.0. Kam se na to hrabe nějaké UEFI?

[Aleš Kapica]

Bez tiku a bohužel zatím také stále bez overlayfs či aufs.. 8-/

[mankind_boost]

+1

[Bill Gates]

Jak to bude s bombama bezicima na linuxu? Ty uz taky nebudou tikat? O.o

[aesrwerqwr]

holt pro bomby budou muset prekompilovat kernel to by bylo zajimave mit desticku "arduino bomb" s embedded linuxem predpripravena pro teroristy na vyrobu bomb. distro by bylo atomic linux.

[Bill Gates]

Holt vyvoj jde kupredu... Ani bomby uz dnes nejsou co byvaly. Netikaji ale maji minimalne 7mi segmentovy display :D

[Dreit]

Ono taky bombu s NE555 a děličkou už by dneska nikdo nedokázal zneškodnit

[Bill Gates]

Dokazal by to zcela jiste Chuck Noris tak, ze by ji sezral a pak si nechutne a prudce rihnul :D

[pc2005]

Tak vzhledem k tomu, že frekvence 555 se nastavuje poťákem (nebo ideálně tesla trimrem), tak bych se bál, že mi první exemplář udělá takové překvapující demo .

[Kvakor]

Hmmm, a za pár let bude pyrotechnik zneškodňovat bombu tak, že se k ní připojí přes SSH a bude zkoušet root exploity ...

PS: Pořád to není nic proti filosofické debatě s inteligentní bombou z černohumorného sci-fi filmu Temná Hvězda

[Hans1024]

Nad volbou NO_HZ jsem zrovna nedavno premyslel: jak to sakra muze fungovat?

A pak jsem zjistil, ze to vlastne bez tiku neni, takze nazev "no hz" je tak trochu zavadejici...

[dumblob]

Presne tak - proste vzdycky alespon jedno hardwarove jadro nebo CPU musi tikat.