Jaderné noviny – 18. 8. 2016: Případ pozdržené kontroly CPU

28. 8. 2016 | Redakce

Články - Jaderné noviny – 18. 8. 2016: Případ pozdržené kontroly CPU  

Stav vydání jádra. Citáty týdne: Linus Torvalds, Konstantin Ryabitsev, Lara Abbott. Případ pozdržené kontroly CPU.

Stav vývoje jádra

Současný vývojový kernel je 4.8-rc2 vydaný 14. srpna. Linus k tomu řekl: „Vypadá to, že se neděje nic divného, takže prosím testujte a hlaste jakékoli chyby, na které narazíte. Očividně jsme na počátku řady rc vydání, ale nemyslím si, že v začleňovacím okně bylo něco znepokojivého, takže se nestyďte.“

Co se týče známých regresích ve vydání 4.8, viz tento report.

Stabilní aktualizace: 4.7.1, 4.6.7, 4.4.18 a 3.14.76 byly vydány 16. srpna. Řada 4.6.x verzí 4.6.7 končí.

Citáty týdne

Přiznejme si to, s uživatelskými programy, které dělají divné a nepříliš efektivní věci, se do budoucna musí počítat. Šílených uživatelských programů se nikdy nezbavíme, takže bychom mohli opravit problémy s výkonem i v situacích, kdy se nedá říct nic jiného než, že „to je hovadina.“

-Linus Torvalds

[I] když vám někdo na bugzilla.kernel.org řekne, abyste něco provedli se svým jádrem, ještě to neznamená, že ten člověk ví, co dělá.

-Konstantin Ryabitsev

Ráda bych rozptýlila tuto představu jednou pro vždy. Pro práci na jádře nepotřebujete mít extra talent, pokud jako talent nepočítáte vytrvalost a trpělivost. Práce v nízkoúrovňovém Céčku má své zvláštnosti stejně jako jiné jazyky. Šablony v C++ mě děsí a typový systém (resp. jeho absence) v JavaScriptu mě mate. Dovednosti potřebné k práci na jádře se můžete naučit.

-Laura Abbott

Případ pozdržené kontroly CPU

Dlouhotrvající technické neshody nejsou v jaderné komunitě ničím novým. Obvykle se je nakonec podaří vyřešit a zúčastnění vývojáři se mohou přesunout k novým problémům. Jenže občas může protahovaný status quo vést k rozkolu mezi jádrem a komunitou uživatelů. Probíhající spor ohledně ovladače CPU v nové hierarchii kontrolních skupin začíná vypadat jako jeden z těchto nepříjemných případů.

Kontrolní skupiny (cgroups) jádro podporuje již téměř deset let. Poskytují mechanismus, který umožňuje hierarchické seskupování procesů a následně jejich regulaci. Netrvalo dlouho a uživatelé si společně s vývojáři po zavedení kontrolních skupin začali uvědomovat, že jejich návrh má jisté zásadní vady. Diskuze o jejich nápravě nabyla na vážnosti začátkem roku 2012. Vedla k popisu druhé verze API kontrolních skupin a začátku procesu, který měl vést k přechodu na toto API. Aktuálně je přechod na druhou verzi API téměř hotov – zbývá jediná nápadná výjimka, a to kontrola CPU.

Kontrola CPU, jak ze jména samotného zřejmé, řídí přístup k CPU. Umožňuje různým skupinám procesů alokovat konkrétní kvanta procesorového času a zároveň jim brání v tom, aby si navzájem překážely. Nízkoúrovňový kód kontroly CPU může bez problému nové API podporovat, ale vývojáři plánovače prozatím zabránili začlenění API samotného. Nyní tak kontrola CPU zůstává nejvýznamnějším modulem bez podpory druhé verze rozhraní. Ve snaze postrčit věci kupředu (a říct, co se stane, když k posunu nedojde) zveřejnil správce cgroup Tehun Heo podrobné shrnutí situace tak, jak ji vidí on. Pro ty, kdo o toto téma mají zájem, se jedná o zajímavý dokument k přečtení.

Námitky proti kontrole CPU

Stručně řečeno, vývojáři plánovače proti novému API protestují ze dvou důvodů, které mají původ v zažitém nesouladu mezi jejich představou o principech kontroly CPU a API samotným. Oba důvody se vztahují k základním rozhodnutím v návrhu druhé verze API kontrolních skupin.

V původní implementaci kontrolních skupin je možné vložit každé jednotlivé vlákno (proces jich může obsahovat spoustu) do samostatné kontrolní skupiny. Druhá verze API místo toho vyžaduje, aby byla všechna vlákna jednoho procesu ve stejné skupině. V některých jiných případech oddělení vláken nedává velký smysl; týká se to např. kontroly využití paměti, jelikož vlákna jednoho procesu z principu paměť sdílejí, tudíž by jejich oddělení pozbývalo významu. Pro přiřazení různých politik využití CPU různým vláknům ovšem existují rozumné důvody, leč jednotná hierarchie, která je základním aspektem návrhu druhé verze API, vyžaduje, aby všechny kontrolní moduly viděly stejné uspořádání kontrolních skupin. Takže z pohledu kontroly CPU musí být všechna vlákna ve stejné kontrolní skupině.

Podle všeho je tento požadavek z pohledu vývojářů plánovače principiálně špatný. Nic přímo v plánovači nerozezná abstrakci „procesu“ – na této úrovni je vše vláknem. Aplikace „hrubší“ politiky na úrovni kontrolních skupin z jejich pohledu ubírá důležitou míru flexibility a nepřináší podle nich žádné výhody.

Jsou uživatelé, kteří chtějí mít možnost aplikovat různé politiky na různá vlákna. Správa poolu vláken (thread pool) je jedním z často jmenovaných případů užití. Avšak Heo stojí za rozhodnutím podle návrhu; také si myslí, že by se stejné rozhraní nemělo používat pro úroveň správce a v rámci dílčích procesů. Navrhl mechanismus, který nazval skupiny zdrojů (resource groups) pro použití uvnitř procesů. Zatím se nesetkal s velkým ohlasem.

Další věc, která se vývojářům plánovače na druhé verzi API nelíbí, je ta, že kontrolní skupina může obsahovat buď další kontrolní skupiny, nebo procesy – nikoli obojí. Procesy se v hierarchii kontrolních skupin mohou objevit pouze na samém konci jako listy. Opět platí, že toto rozhodnutí bylo přijato s cílem usnadnit podporu kontroly věcí jiných než CPU. Pokud se podskupiny a procesy ocitnou ve stejné skupině, pak tyto dva typy objektů musí soupeřit o stejný zdroj. V případě CPU se dá toto soupeření jednoduše spravovat. Když je „naplánována“ kontrolní skupina, plánovač se rekurzivně vrátí do skupiny a vybere z ní jeden z objektů ke spuštění. Jiné kontrolní mechanismy ovšem s procesy a podskupinami podobným způsobem pracovat nedovedou.

Hlavní námitka se týká toho, že toto omezení ničí některá elegantní řešení návrhu plánovače CPU. Rozhodnutí při plánování jsou aplikována na „plánované entity“, což mohou být jak procesy, tak skupiny – plánovač se nemusí starat, co je co. Nová verze API některé kontrolní politiky znesnadňuje, ba až znemožňuje. To však podle Hea nemusí příliš vadit:

Nicméně není jasné, jaké by bylo praktické využití rozložení s přímou konkurencí mezi úkoly a kontrolními skupinami, když uvážíme, že počet a chování úkolů si ovládají aplikace samotné, zatímco kontrolní skupiny se primárně zabývají přerozdělováním zdrojů na úrovni systému. Změny v počtu aktivních vláken by přímo ovlivnily distribuci zdrojů. Během diskuzí se nepodařilo přijít na příklady z praxe, ve kterých by takové rozložení našlo využití.

V souhrnu lze konstatovat, říká Heo, že pro rozhodnutí ohledně druhé verze API existují solidní důvody. Většina věci funguje tak, jak jsou, a přidání nové funkce, jako jsou skupiny zdrojů, může vyplnit zbývající mezeru. Pokud někdo stále nemůže pracovat s druhou verzí API, první verze bude udržována, dokud bude mít uživatele. Přechod je téměř kompletní: nechybí nízkoúrovňová podpora, jen zbývá začlenit kód na úrovni API, aby kontrola CPU mohla pracovat v jednotné hierarchii nové verze. Tento kód však byl zablokován a zdá se, že není cesty vpřed.

Co teď

Heo zjevně doufá, že se znovuotevřením diskuze podaří dojít k jejímu závěru a připravit cestu pro začlenění zbývajících patchů. Prozatím to ale na brzký konec nevypadá. Pokud se k řešení nedospěje tímto způsobem, chystá se Heo zpřístupnit svou funkcionalitu uživatelům jinak.

Jednou z možností je udržovat potřebné patche tak, že kdokoli, kdo bude chtít kontrolu CPU s druhou verzí API, si je bude moci snadno přidat do svého jádra. Přestože to zatím nikdo neřekl explicitně, je zjevné, že Heo doufá, že distributoři tyto patche zahrnou, aby byly uživatelům k dispozici. Tento přístup byl použit k vyřešení podobných záseků i v minulosti. Je-li patch široce aplikován distributory a využíván, nastává okamžik, kdy nemá smysl bránit mu ve vstupu do upstreamu. Tyto úvahy přivedly do upstreamu mimo jiné také Android.

Další věcí, kterou je třeba zajistit, je, aby nejrozšířenější nasazení kontrolních skupin – systemd – mohlo novou verzi API používat. Proto zveřejnil žádost o začlenění přidání této funkcionality do systemd se slovy: „Tento commit implementuje podporu systemd kontroly CPU v jednotné hierarchii, takže uživatelé, kteří se rozhodnou nasadit podporu pro druhou verzi kontroly CPU kontrolními skupinami, ji mohou jednoduše využívat.“ Tento kód byl začleněn do upstreamu systemd 14. srpna.

Tento krok vyvolal mírné neshody v komunitě systemd, jelikož tam je zvykem, že funkcionalita je dříve v „upstreamu“, než se [do systemd] začlení kód, který ji začne využívat. Ačkoliv, nutno podotknout, že většina protestů v tomto případě přichází od jediného hlučného vývojáře. Lennart Poettering tento krok bránil s tím, že vývojáři systemd chtějí, aby se funkce dostala do rukou uživatelů, a že doufá v začlenění jaderných patchů do Fedory. Greg Kroah-Hartman poznamenal, že se nejedná o první případ, kdy byla přidána podpora nezačleněné funkcionality, a že se tak často děje z dobrých důvodů:

Někdy je třeba přidat kód k projektům, aby bylo možné kód jádra pořádně otestovat. A aby lidé mohli snáze upgradovat svá jádra v budoucnu a aby vše správně fungovalo na jejich stávajících, starších, systémových nástrojích. Tohle se děje pořád, nechápu, proč jste tím najednou tak překvapeni.

Takhle nějak to vypadalo v době psaní tohoto článku. Předvídání může být nebezpečné, hlavně když jde o budoucnost, ale v tomto případě to vypadá, že se jaderné patche skutečně do různých distribučních jader dostanou. Díky nim bude druhá verze API používanější a protože většina distributorů již používá systemd, je jeden z významných uživatelů připraven API využít. Tlak ze strany uživatelské komunity je sice takovým tupým nástrojem, který by však v tomto případě mohl zaseknutým patchům pomoci.

Diskuse k tomuto článku

[Fox]

Control neni kontrola...

[Fluttershy, yay!]

Pokud je mi známo, kontrolní skupiny jsou zavedený překlad a zde o kontrolu ve stejném slova smyslu jde.

[trekker.dk]

Pokud zavedený překlad v tomto kontextu znamená to, co zde bylo zavedeno dříve, tak zavedený překlad za posledních přinejmenším 6 let jsou řídící skupiny. UTFG, pokud mi nevěříte.

[Josef Kufner]

Řídicí, nikoliv řídící. Jsou to skupiny určené k řízení, nikoliv skupiný, které právě něco řídí. Tedy pokud je o nich jednáno v obecné rovině.

[Fluttershy, yay!]

UTFG proběhlo a kontrolní skupiny se vyskytly tady, na Rootu i jinde (zadání diplomek, školení) o poznání dříve.

Co se týče jazykozpytné diskuze, viz komentáře na Rootu.

[trekker.dk]

Ano, vyskytly se tady, ale v jaderných novinách byl ustálený překlad řídicí skupiny. Mimo jiné i proto - a v tom blogu na rootu se to píše podobně - že kontrolní (kontrolovat) má jako prvotní význam "ověřit (jak něco dopadlo)"

[Fluttershy, yay!]

jako prvotní význam "ověřit (jak něco dopadlo)"

Těžký život inženýra.

Navíc všechny slovníky, které mám při ruce, v prvé řadě hovoří o dozoru či dohledu.

[trekker.dk]

Njn, ne všichni mají žaludek na to věčně studovat nesmysly, vyhýbat se práci a nechat si to platit od jiných.

[Fluttershy, yay!]

To eskalovalo rychle.

[citanus]

Kdyz uz se to musi prekladat, tak se taky primlouvam za ridici skupiny

[prcek]

+1

[win.net]

Jen bych upozornil na chybku: "Netrvalo dlouho a uživatelé si společně s vývojáři vývojáři po zavedení kontrolních skupin" Jednou by ti vývojáři mohli stačit

O

[Fluttershy, yay!]

Díky, opraveno.

[Xerces]

Na můj vkus je v článku o jádru příliš často použito slovo systemd a Android, ale každopádně díky za překlad.