Portál AbcLinuxu, 28. března 2024 11:24

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

26. 6. 2016 | Redakce
Články - Jaderné noviny - 16. 6. 2016: Čas na atomicitu z C11?  

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.

Odkazy a zdroje

LWN.net

Další články z této rubriky

Jaderné noviny – přehled za únor 2024
Jaderné noviny – přehled za leden 2024
Jaderné noviny – přehled za prosinec 2023
Jaderné noviny – přehled za listopad 2023
Jaderné noviny – přehled za říjen 2023

ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.