Jaderné noviny - 16. 6. 2016: Čas na atomicitu z C11?

26. 6. 2016 | Redakce | Jaderné noviny | 60050×

Stav vydání jádra. Leemhuis hledá regrese. Čas na atomicitu z C11?

Stav vydání jádra

Současný vývojový kernel nese označení 4.7-rc3, vydán byl 12. června. Linus k tomu řekl: „Přehled změn vypadá docela normálně a neškodně. Tentokrát mají souborové systémy větší podíl než obvykle, ale vesměs se jedná o nově přidané testy btrfs, které když ignorujete, zbývají celkem obvyklé věci: dominují ovladače (grafické a síťové představují většinu, a pak i i2c, rdma,…) spolu s aktualizacemi architektury a nějakým tím obecným kódem pro sítě. A konečně nahodile ode všeho trochu jako vždycky.“

Thorsten Leemhuis se prozatím chopil dlouho zanedbávaného úkolu hledání regresí v -rc jádrech. Zatím se mu v 4.7-rc3 povedlo najít 21 regresí.

Stabilní aktualizace: Žádné nebyly tento týden vydány.

Čas na atomicitu z C11?

Klasický program napsaný v C vypadá jako deterministický seznam kroků v jistém pořadí. Na co už ale programátor nevidí, to jsou změny pořadí operací, které může za účelem urychlení běhu programu provést překladač nebo CPU. Jestliže pracujeme pouze s jedním vláknem, je přeřazování operací, aniž by došlo k poškození programu, relativně jednoduchá záležitost. Neplatí to však v případě, kdy se stejnou pamětí pracuje najednou více vláken. V případě více vláken jsou vývojáři často nuceni explicitně vznést požadavky na uspořádání.

Za tímto účelem jádro definuje celou řadu paměťových bariér a atomických operací, jejichž cílem je zachování pořadí přístupu do paměti (memory access ordering) v místech, kde je to důležité, při zachování výkonu. Standard C11 jazyka C se snaží vyřešit stejný problém jinou sadou bariérových operací. Opět je na místě ona otázka: Měl by kernel dát přednost operacím definovaným standardem C před svými vlastními operacemi?

Tato otázka se naposledy objevila v roce 2014, viz shrnutí na LWN o tom, jak atomické operace C11 fungují a jak se může při nedostatečně kontrolované změně pořadí operací pokazit souběžný přístup k paměti. Podpora atomických operací ze standardu C11 se mezitím v překladačích zlepšila a David Howell přišel s plnou implementací atomických operací jádra (pro x86), postavenou právě na C11. Implementace samotná je vcelku přímočará, například funkce atomic_read() vypadá takto:

static __always_inline int __atomic_read(const atomic_t *v, int memorder)
{
    return __atomic_load_n(&v->counter, memorder);
}
#define atomic_read(v)		(__atomic_read((v), __ATOMIC_RELAXED))
#define atomic_read_acquire(v)	(__atomic_read((v), __ATOMIC_ACQUIRE))

Davidovy patche ukazují, že konverzi provést jde. Otázkou zůstává, zda by se měla udělat. Jak by se dalo očekávat, existují argumenty pro i proti.

Přechod k atomickým operacím z C11 by teoreticky měl umožnit vyhození spousty složitého, na architektuře závislého kódu pro bariéry z jádra – místo toho by se využilo stejného kódu, leč zabudovaného přímo do překladače, který budou souběžné programy uživatelského prostoru využívat. Atomicita z C11 poskytuje překladači lepší přehled o tom, co kód doopravdy dělá, otevírá více příležitostí k optimalizaci a použití instrukcí, které je těžké vyvolat v inline assembleru. Překladač také může vybrat instrukci, která odpovídá velikosti operandu, čímž dokáže eliminovat přerostlé větvení vyhodnocované při překladu ve stávajících hlavičkových souborech jádra.

Současné překladače zdaleka nevyužívají všechny možnosti optimalizace, ale potenciálně by ty budoucí mohly překonat ručně psaný, vyladěný kód v assembleru. Jak k tomu řekl Paul McKenney:

Souhlasím, že pro C11 může být těžké porazit precizně optimalizovaný kód v assembleru. Ale nemusí to trvat až zas tak dlouho, než překladače porazí jednodušší ručně psaný kód v assembleru. Nakonec, překladače můžou časem překonat i ten optimalizovaný kód v assembleru ve složitějších případech jako cykly cmpxchg.

Další výhodou je schopnost překladače přesunout konkrétní bariéry pryč od atomických operací samotných, pokud se tím dosáhne vyššího výkonu. Takové přesuny u inline assembleru nejsou možné.

Přechod ale samozřejmě přináší také nevýhody. Jednou z nich je, že atomicita z C11 je pořádně implementována pouze v nejnovějších překladačích. David říká, že generovanému kódu bude k optimalitě hodně scházet před vydáním gcc-7.1, a to je vydání, na které si počkáme ještě skoro rok. Přesně podle očekávání se objevuje spousta chyb, která s atomicitou z C11 souvisí. Jsou sice hlášeny a opravovány, ale pravděpodobně jich ještě přibude. Z dlouhodobého hlediska by používání atomicity z C11 jistě vedlo k zavedení robustnějšího překladače, ale cesta nejspíš bude trnitá.

Když se jádro sestavené pro běh na víceprocesorovém systému (to jsou téměř všechna) dostane na systém jednoprocesorový, odstraní nepotřebné synchronizační instrukce z vlastního kódu. Při použití atomicity z C11 nebude něco takového možné, nelze totiž zjistit, kde se tyto informace nacházejí, a sebemenší změny v překladači mohou vést k nevídaným zmatkům. Jednoprocesorové systémy jsou čím dál tím vzácnější a jednorázově sestavená jádra jsou pro ně vesměs k dispozici, ale stejně by bylo lepší takové systémy zbytečně nezpomalovat.

Konečně, asi největší potenciální problém spočívá v tom, že model paměti implementovaný pomocí atomicity z C11 do jisté míry neodpovídá modelu, který používá jádro. Model C11 je postaven na sémantice acquire/release – tedy na jednosměrných bariérách, o kterých byla řeč ve výše odkázaném článku z roku 2014 a v tomto článku. Velká část jádra místo toho používá load/store bariéry, které jsou jednak přísnější, jednak obousměrné. Zápis do paměti s release sémantikou bude dokončen pouze v případě, že jsou veškeré předchozí operace čtení nebo zápisu viditelné v celém systému, ale umožní přeřadit jiné operace, provedené logicky po zápisu, tak, aby byly vykonány před příslušným zápisem. Zápis se sémantikou store místo toho striktně řadí ostatní operace zápisu na obou stranách bariéry.

Jednou možností by bylo zeslabit paměťový model jádra tak, aby architektura, která využívá sémantiky acquire/release, mohla dosáhnout na příslušné výkonnostní benefity. Je však jasné, že taková změna by mohla přinést náchylnost k těžko odhalitelným chybám. Proto je k tomu nutné přistupovat opatrně. David poznamenává, že PowerPC již zřejmě se zeslabeným modelem pracuje, takže přímo v jádru už nutně nemusí číhat tolik problémů.

Jak podotkl Will Deacon, atomicita z C11 postrádá, krom jiného, dobrou implementaci operací consume load, které tvoří důležitou součást mj. RCU. Consume load může být vždy nahrazeno operací acquire, leč za cenu horšího výkonu. Will se obává, že model C11 není vhodný pro architekturu ARM a že výsledkem záměny může být nepraktická kombinace C11 a operací specifických pro jádro. Souhlasil však s tím, že generická implementace založená na C11 by byla užitečným nástrojem pro vývojáře, kteří portují jádro na novou architekturu.

Zatím o nápadu proběhla o poznání kratší diskuze než minule. Možná, že se vývojáři pomalu smiřují s myšlenkou, že ke změně nakonec stejně dojde, i když se to nyní zdá předčasné. Výhody by taková změna přinesla jak pro jádro, tak pro komunity kolem překladačů. Zatím se nepovedlo rozseknout, zda tyto výhody převažují nad nevýhodami.

       

Komentáře

[pc2005]

Tak jestli není pořádně nahraditelná atomicita v RCU, tak bych to snad ani nenahrazoval, to by se klidně mohlo celé rozsypat ([joke] ... a z linuxu vzniknout jednotaskovej OS [/joke]).

Možná by bylo jednodušší to změnit v GCC.

P.S. Ví někdo jaká je nejstarší verze GCC, kterou jde zkompilovat jádro? Já začal až na 3.xx, ale řekl bych, že za tu dobu se to klidně mohlo posunout.

[vgy]

GCC mi bezne nedokazalo skompilovat programy, co jeste pred nejakejma verzemi gcc skompilovat slo. Oproti tomu Microsoft kompilator to iste napric verzema dokazal skompilovat. GCC je pro mne smejd. Aby clovek neustale opravoval program kvuli tomu, ze je gcc vylepsene.

[Michal Kubeček]

Ve svém svatém rozhořčení jste zapomněl zmínit jeden důležitý "detail": jestli ten zdroják byl opravdu korektní podle normy jazyka nebo jestli překladač jen začal odmítat něco, co korektní nebylo, ale dříve to toleroval.

[Ccfjdj]

Na to staci vypnut -pedantic -Werror.

[petr_p]

Nestačí. S každou verzí přibývají optimalizace, kdy se program i přeloží, ale kvůli konstrukcím s nedefinovaným chováním se výsledná binárka chová jinak. Pak naopak zapnutá varování jsou důležitá. Každopádně stěžovateli bych doporučil program opravit, nebo neaktualizovat překladač (nebo alespoň přes -std zamknout verzi C).

[Homer Simpson]

(Homer Simpson šéfem směťáků):

A nemohl by to udělat někdo jinej?

(počítač na velikým projektu?) A poté firma skrachovala a město se přestěhovalo... do Redmontu

[fe]

Tak Visual Studio je hoooodně benevolentní a „skousne“ některá přetypování, které GCC ale hlavně Clang nezkousne a nahlásí jako error.

Je čistě filozofická otázka co je správně – já se přikláním na stranu GCC a Clang, které vynucují standardy jazyka.

Ale z mé praxe v multiplatformním vývoji, ti co kompilují na GCC/Clang stále dokola opravují kód vyprodukovaný těmi, co programují ve VS. A podle toho co za poslední roky vidím, MS by měl svůj kompilátor opravdu zlepšit a standardy dodržovat.

[Petr Ježek]

Potvrzuji tuto zkušenost. Problém programátorů z Redmondu byl a je, že standardy definoval management a vlastníci, nikoli kybersystém a jeho tvůrci. Bohužel jde o široce rozšířený nešvar, který je v poslední době pouze lépe vidět poté, co se v MS tváří přívětivě na multiplatformálnost.

[little.owl]

Pak se jedna o hodne prasacke programy stavejici sve chovani na nespecifikovanem nebo implementacne zavislem chovani. A pokud nekdo pise user space programy tak, ze je to "bezne", je lepsi ho poslat past ovce.

[Michal Kubeček]

Minulý týden jsem zrovna narazil na thread, kde tahle otázka padla. Podle dokumentace je potřeba aspoň 3.2, ale nikdo si netroufá dát ruku do ohně, že jádro touhle verzí opravdu přeložit jde. A nikomu se pochopitelně nechce instalovat gcc 3.2 a zkoušet to, natož pak dělat nějaké důkladné testy, jestli aktuální jádro přeložené gcc 3.2 funguje správně.

[koroptev]

Zdrojaky jadra nejsou korektni podle normy? Nebo gcc pred 3.2 nebylo schopne kompilovat korektni veci a pote ano?

[Michal Kubeček]

Nejsou. Pokud by vás to náhodou opravdu zajímalo, nebude pro vás problém zjistit si proč. Pokud jako obvykle jen trollujete, nestojí za to ztrácet čas vysvětlováním.

[ced]

Ano. zrojáky jádra nejsou místy korektní podle normy. Sice nejsem autor jádra a nemluvím o celém jádře, ale to co jsem četl, nebylo striktně podle normy. Bylo to podle dokumentace GCC. Včetně těch sekcí jako GCC only nebo experimental. Upřímně, ono ani podle normy napsat ne vždy jde, ale někdy jsem měl dojem, že když si autor dal práci se čtením experimentálních novinek v GCC, rozhodl si to procvičit na jádru, bez ohledu na to, že u nich bylo napsáno, že nikdo nezaručuje stejné chování i do budoucna.

[little.owl]

Kernel je jedna z veci, ktera nutne zavisi na nespecifikovanem a implementacne zavislem chovani, zavisejice jen na C standardu to napsat nelze.

[pc2005]

GCC 3.2 vyšlo 2002, tak to by mohlo trvat dalších 14 let než na ty funkce přejdou . Nejhorší bude stav, kdy pojede půlka architektur na starým mechanismu a půlka na novým.

[Petr Ježek]

Při použitelné a současně i používané existenci clangu jde o nesmyslný argument. Clang je dobrou příležitostí zmíněné diskrepance eliminovat.

[pc2005]

Clang už zkompiluje kernel? Každopádně bude řešit stejný problém jako gcc a to je implementace vestavěných atomických operací vs implementace v kernelu. Nezapomeň, že v kernelu musí být různé varianty pro různé architektury (některé ani neumí SMP) a pak jsou lidi, co třeba laděj zámky (článek tady v jaderných novinkách před nějakou dobou).