Jaderné noviny - 5. 5. 2016: Honba za rychlejšími futexy; zápis na pozadí a DAX na BTT

15. 5. 2016 | Redakce | Jaderné noviny | 3190×

Stav vydání jádra. Citáty týdne. Honba za rychlejšími futexy. Zápis na pozadí. DAX na BTT.

Stav vydání jádra

Současný vývojový kernel je 4.6-rc6, vydaný 1. května. Linus k tomu napsal: „Vše je v normálu, ale jsem si téměř jistý, že v této sérii uděláme i rc7.“ Od tohoto prepatche je kód znám jako „Charred Weasel“.

Stabilní aktualizace: 4.5.3, 4.4.9 a 3.14.68 byly vydány 4. května.

Citáty týdne

Nesnažím se nikoho urazit, ale množství procesů spojených se snahou dostat kód do OpenStacku je šílené. Pošlete plán. Pošlete specifikace. Získejte povolení. Poté pošlete kód. Předpokládám, že je to jednodušší než pracovat pro vládu. Ale potom není divu, že cykly vydávání mají šest měsíců.

- Kristen Accardi

Stojí za zmínku, že smyslem DAXu bylo, aby ve stávajících souborových systémech nebylo potřeba velkých změn k přidání podpory rychlých operací pmem (perzistentní paměti), mít tedy aspoň něco co nejdřív, zatímco nativní souborové systémy pro perzistentní paměti jsou ve vývoji, aby podporovaly perzistentní paměť se všemi jejími výstřednostmi, čistým a účinným způsobem.

Místo toho pozoruji trend tlačit podporu požadavků a bizarností DAXu a pmem do stávajících souborových systémů, bez nějakého ohledu na nativní řešení pmem. Slýchávám, že „potřebujeme velký zásah do stávajících souborových systémů a blokových zařízení, aby DAX správně fungoval,“ spíše než: „Jak to můžeme zefektivnit pro nativní řešení pmem, abychom se nemuseli omezovat sémantikou blokových zařízení?“

- Dave Chinner

Honba za rychlejšími futexy

Futexy, Linuxem poskytovaná primitiva pro rychlou podporu vzájemného vyloučení, se na stránkách LWN rozebíraly docela často. Za ta léta se jim dostalo různých vylepšení v podobě dědění priority a odolnosti vůči umírajícím procesům. Stále ovšem postrádají aspoň jednu věc. Nedávný revidovaný patchset Thomase Gleixnera si klade za cíl napravit nešťastnou skutečnost, že futexy nejsou dost rychlé.

Tvrzení, že futexy jsou rychlé (jak naznačuje „f“ v jejich názvu), je primárně založeno na jejich chování v okamžiku, kdy o konkrétní futex zrovna není zájem. Nárokování futexu, který není v držení jiného úkolu nebo jeho uvolňování je velmi rychlé, celá operace se uskuteční v uživatelském prostoru bez účasti jádra. Tvrzení, že futexy nejsou dostatečně rychlé, se zaměřují na opačný případ: čekání na zaneprázdněný zámek nebo odesílání požadavku na probuzení během uvolňování zámku, na který čekají jiné procesy. Tyto operace musí obsahovat volání do kernelu v podobě událostí uspání/probuzení, zahrnují také komunikaci mezi různými úlohami. Očekává se, že tento případ nebude tak rychlý jako ten dříve zmíněný, ale mohl by být rychlejší než nyní, a že způsobená zpoždění by mohla být lépe předvídatelná. Zdroj zpoždění má co do činění se sdíleným stavem, který řídí jádro.

Zbytek článku (anglicky)

Zápis na pozadí

Problémy se zápisem na pozadí v Linuxu jsou známy již delší dobu. Nedávno došlo na snahu aplikovat na blokové vrstvě to, co se naučili síťoví vývojáři, kterým se podařilo vyřešit problém „bufferbloat“. Jens Axboe se zhostil vedení části, věnované tomuto problému, na summitu o úložištích, souborových systémech a správě paměti.

Základní problém spočívá v tom, že zápis (flush) blokových dat z paměti na úložné zařízení (writeback) může zaplavit fronty takovým způsobem, že všechny ostatní požadavky na čtení a zápis budou mít vysokou latenci. Jens zveřejnil několik verzí patchsetu, které mají tento problém řešit, a věří, že se blíží konečné fázi – snížil se počet věcí, které lze ladit, a vše v podstatě funguje.

Fronty jsou na straně zařízení spravovány způsobem, který je „velmi volně založen na CoDel“ z kódu pro správu sítí. Fronty jsou monitorovány a v okamžiku, kdy fronty příliš narostou, jsou požadavky na zápis zastaveny. Jens zvažoval o zahazování zápisů (jako to CoDel dělá v případě síťových paketů), ale seznal, že by lidé z takového přístupu nebyli nadšeni.

Aktuálně je problém z velké části vyřešen. Latence čtení i zápisu se zlepšily, přesto stále zbývá prostor pro zlepšování. Algoritmus je nastaven tak, že pokud je zařízení dostatečně rychlé, „neplete se do cesty.“ Dokáže se rychle zaměřit na fronty správných velikostí a pokud o fronty nesoupeří žádné požadavky ke čtení, „nedělá vůbec nic.“ Jens dále zmínil, že dosud znovu nespustil „šílený Chinnerův test.“

Ted Ts'o se zeptal na interakci s řadičem I/O kontrolních skupin, který se snaží o proporční I/O. Axboe odpověděl, že si s tím nedělá nijak velké starosti. Řadiče pro každou kontrolní skupinu o sobě budou muset vědět, ale „nejspíš bude vše v pořádku.“

David Howells se zeptal na zápis na~ více zařízení. Axboe na to řekl, že na tom ještě bude nutné pracovat. Někdo další se zeptal na čtení na pozadí – to by podle Jense šlo přidat. Nic tomu nebrání, ale je třeba to udělat.

DAX na BTT

V závěru summitu vedla většina týmu, který pracuje na mechanismu přímého přístupu DAX, diskuzi o tom, jak by měl DAX komunikovat s BTT (block translation table). Jedná se o mechanismus, jenž by měl perzistentní paměti poskytnout schopnost atomického sektorového zápisu, který uživatelé od blokových zařízení očekávají. Dan Williams se ujal role moderátora, ale účastnili se také Matthew Wilcox, Vishal Verma a Ross Zwisler.

Williams poznamenal, že například Microsoft DAX pro perzistentní paměť přijal a dokonce jej nadále nazývá DAX. Wilcox k tomu dodal, že to znamená, že „Microsoft se změnil a svým zákazníkům naslouchá.“

BTT nabízí způsob, jak vložit sémantiku blokové vrstvy do perzistentní paměti, která zpracovává zápisy o granularitě cache (tj. 64 bajtů), takže (sektorové) 512bajtové zápisy se stávají atomickými. Tím se eliminuje „trhání sektorů“, při kterém výpadek napájení nebo jiná porucha způsobí částečný zápis do sektoru, což má za následek pomíchání starých a nových dat – to je situace, na kterou nejsou aplikace (potažmo souborové systémy) připraveny. Microsoft podporuje DAX na blokových zařízeních s BTT i bez něj, zatímco Linux zvládá pouze druhou variantu. Williams se zeptal, zda je dobrý nápad následovat Microsoft do neznáma či nikoli.

Problém spočívá v tom, že BTT je určeno k nápravě problému, kdy se s perzistentní pamětí zachází jako s blokovým zařízením, což ovšem není smyslem DAXu. Řešením může být používat BTT pouze na metadata souborového systému, řekl Zwisler. Na druhou stranu Ric Wheeler poznamenal, že souborové systémy již vkládají hodně úsilí do práce s kontrolními součty metadat, takže použití BTT by vše ještě zpomalilo s malým přínosem.

Jeff Moyer poukázal na to, že trhání sektorů se může přihodit na blokových zařízeních, kam patří například SSD, což uživatelé neočekávají. Joel Becker navrhl, že souborové systémy či aplikace, jež se mohou potýkat s trháním sektorů, by mohly používat příkaz SCSI pro atomický zápis. Tento příkaz zaručuje, že sektor je zapsán buď zcela, nebo vůbec. Neexistuje způsob, kterým by se aplikace daly nějak zázračně zachránit, pokud nevyužijí žádná opatření, pokračoval.

Podle Williamse jsou za podporou BTT tak trochu „postranní úmysly.“ V současné době řadiče nepoznají, že dojde k vytvoření či zrušení DAX namapování, což by se podporou BTT změnilo. Wilcox řekl, že má připravené patche, které některé tyto problémy řeší vytvořením radixového stromu jako zdroje příslušných informací.

       

Komentáře

[Jendа]

Od tohoto prepatche je kód znám jako „Charred Weasel“ („ohořelý vrak“).

Ne, jedná se o lasičku, která v CERNu překousala kabel podobný tomu z patičky.

nebylo potřeba velkých změn k přidání podpory podpoře rychlých operací pmem

[Fluttershy, yay!]

Brainfart. Opraveno.

[Kvakor]

Ne, jedná se o lasičku, která v CERNu překousala kabel podobný tomu z patičky.

Viz třeba článek na Oslu Rozmarné jaro na LHC: Dvoufotonové srážky a patálie s kunou (a to, o jakou lasicovitou šelmu se opravdu jednalo, nechám na zvídavých čtenářích ).