Jaderné noviny - 27. 10. 2016: Škálovatelný odkládací prostor

9. 11. 2016 | Redakce | Jaderné noviny | 2477×

Stav vydání jádra. Citáty týdne: Rusty Russel, Dave Chinner a Linus Torvalds. Škálovatelný odkládací prostor.

Stav vydání jádra

Současný vývojový kernel je 4.9-rc2, vydaný 23. října. Linus žádá, aby se lidé zaměřili na testování zvláště jedné funkce: „Moje nejoblíbenější novinka, kterou jsem vyzdvihl při oznámení rc1 (virtuálně mapované zásobníky), je nejspíš zapletená do některých pádů, kterými se zabýval Dave Jones, takže jestli chcete být užiteční a můžete přispět dalšími daty, povolte si prosím CONFIG_VMAP_STACK.“

Aktuální seznam regresí v 4.9 obsahuje 14 známých problémů.

Stabilní aktualizace: 4.8.3, 4.7.9 a 4.4.26, obsahující opravu „Dirty COW“, byly vydány 20. října. Verze 4.8.4, 4.7.10 a 4.4.27 následovaly o dva dny později. Verze 4.7.10 je poslední v řadě 4.7.x.

Verze 4.8.5 (140 změn) a 4.4.28 (112 změn) byly v době psaní tohoto článku v procesu revidování a vyšly 28. října.

Citáty týdne

Mým největším kariérním úspěchem, který trval posledních 19 let, byla možnost být správcem linuxového jádra. Nyní však máme nadbytek vynikajících hackerů, takže můžu své místo bez výčitek předat dál.

–Rusty Russel končí

Rychle se vzdalujeme ze světa, ve kterém je stránková cache nutná, aby aplikace měly slušný výkon. DAX stránkovou cache nemá; aplikace, které chtějí využít úložiště s vysokým IOPS (stovky tisíc až miliony), používají přímé IO, protože stránková cache akorát přidává zpoždění, problémy s využitím paměti a nedeterministické chování IO.

Jestli nám jde o to udělat ze stránkové cache „jediný správný zdroj optimalizací IO“, lžeme si do kapsy, protože nové IO technologie ji už nevyžadují.

–Dave Chinner

A ten patch samozřejmě není vůbec otestovaný. Nechtěl bych si kazit reputaci *testováním* patchů, které odešlu. Jaká by v tom byla legrace?

–Linus Torvalds, který daný patch následně otestoval (díky Borisi Petkovovi)

První zveřejnění patche bus1

Mechanismus pro předávání zpráv bus1 je nástupcem projektu „kdbus“. Na LWN se o něm psalo v srpnu. Patche jsou nyní zveřejněny k revizi. „Ačkoliv bus1 původně vzešel z projektu kdbus, je napsaný na zelené louce a dohromady toho oba koncepty nemají mnoho společného. Ve zkratce, bus1 poskytuje IPC systém na založený na schopnostech; v zásadě je podobný Android Binderu, Cap'n Proto nebo seL4."

Škálovatelný odkládací prostor

Odkládací (swap) subsystém je místo, kam odcházejí anonymní stránky (ty, které obsahují data programu bez zálohy v souborovém systému), když je nedostatek místa vytlačí z RAM. Široce zastoupený názor říká, že swapování je téměř vždy špatnou zprávou. V okamžiku, kdy se linuxový systém dostane do bodu, kdy swapuje anonymní stránky, je bitva o výkon většinou již prohraná. Takže není vůbec neobvyklé, že se setkáváme s linuxovými systémy, které jsou konfigurované zcela bez odkládacího prostoru. Zda je relativně slabý výkon swapování příčinou, nebo následkem tohoto přístupu, je otázkou k diskuzi. Stále jasnější je však fakt, že důvody pro použití swapování jsou stále silnější, takže rychlejší swapování by bylo přínosem.

Swapování s rostoucí kapacitou úložných zařízení (SSD obzvláště) nabývá na popularitě. Není to tak dávno, co bylo přesouvání stránky z/na úložiště velmi pomalou operací – trvalo řádově déle než přímý přístup k paměti. Příchod zařízení s perzistentní pamětí tento poměr změnil takovým způsobem, že se rychlost úložišť blíží rychlosti hlavní paměti. Zároveň poskytuje rozšiřování cloud computingu poskytovatelům silnější podnět k tomu, aby na svých systémech dávali výraznou přednost hlavní paměti. Pokud se podaří swapování zrychlit dostatečně, stane se penalizace při agresivním používání paměti bezvýznamnou, což povede k lepšímu využití systému jako celku.

Jak poznamenal Tim Chen v nedávno zveřejněné sadě patchů, jádro má v současné době značnou režii při výpadcích stránek, které vedou k získání stránky z odkládacího prostoru. Sada patchů tento problém řeší zlepšením škálovatelnosti odkládacího subsystému hned několika způsoby.

V současných jádrech je odkládací zařízení (vyhrazený oddíl nebo speciální soubor v souborovém systému) reprezentováno strukturou swap_info_struct. Mezi položkami této struktury se nachází swap_map, ukazatel na pole bajtů, kde každý bajt obsahuje referenční čítač stránky uložené na odkládacím zařízení. Ona struktura vypadá nějak takto:

Část kódu swapování je docela stará, podstatná část sahá do doby zavádění Gitu. Dříve se jádro snažilo koncentrovat využití odkládacího prostoru směrem k začátku zařízení (levý konec pole swap_map vyobrazeného výše). Při swapování na rotačním úložišti dává tento přístup smysl, protože udržování dat v odkládacím prostoru popořádku by mělo minimalizovat množství hledání, které je zapotřebí k přístupu na požadované místo. Na SSD to funguje o něco hůře, a to z několika důvodů: (1) na těchto zařízeních neexistuje zpoždění při hledání (seek delay) a (2) požadavky na opotřebení SSD lépe odpovídají rovnoměrnému rozložení přes celé úložiště.

V roce 2013 (resp. vydání 3.12) došlo ke změně kódu ve snaze o lepšit výkon na SSD. Když odkládací subsystém ví, že pracuje s SSD, rozdělí jej na clustery, viz ilustraci:

Ukazatel percpu_cluster ukazuje na jiný cluster pro každé CPU v systému. S tímto uspořádáním může každé CPU alokovat stránky z odkládacího zařízení v rámci vlastního clusteru. Výsledkem je rozprostření těchto alokací po celém zařízení. Teoreticky je tento přístup lépe škálovatelný. Tedy až na to, že v současných jádrech zatím nebylo dosaženo plného potenciálu škálování.

Problémem je, jak už to v takových případech bývá, zamykání. CPU často nemají výhradní přístup k libovolnému clusteru (dokonce ani k tomu indikovanému v percpu_cluster), takže dřív než dojde ke změně, musejí získat zámek (spinlock) lock ve struktuře swap_info_struct. Běžně na jednom systému nebývá tolik odkládacích zařízení – často pouze jedno – takže dochází-li ke swapování, je o zámek velmi velký zájem.

Soutěžení o zámky není právě cestou k lepší škálovatelnosti, v tomto případě dokonce ani soutěžení není vůbec nutné. Každý cluster je nezávislý a může se do něj alokovat bez zásahu do ostatních, takže skutečně není nutné čekat na jeden globální zámek. Stěžejním cílem sady patchů je tedy přidat nový zámek pro každý záznam v poli cluster_info. Aby se omezilo zabírání paměti navíc, jsou použity jednobitové zámky. Poté může kterékoli CPU alokovat stránky ze svého clusteru (nebo je uvolňovat do něj) bez soupeření s ostatními.

I tak může dojít k mimořádné režii při zabírání zámku a při přístupu k zámku na jiných clusterech CPU může dojít k soutěžení o řádek cache (jak k tomu často při uvolňování stránek dochází, protože je nic nenutí k tomu, aby byly vhodně k dispozici v rámci uvolňujícího se clusteru CPU). Za účelem minimalizace této režie přidává sada patchů nové rozhraní k alokaci a uvolňování odkládacích stránek v dávkách. Jakmile CPU alokuje dávku odkládacích stránek, může je použít bez potřeby užití lokálního zámku clusteru. Uvolněné odkládací stránky jsou kumulovány v samostatné cache a vraceny v dávkách. Je zajímavé, že uvolněné stránky nejsou opětovně použité uvolňovaným CPU v naději, že jejich celkové uvolnění pomůže minimalizovat fragmentaci odkládacího prostoru.

Ještě jeden bod, kde dochází k soutěžení, je třeba vyřešit. Vedle struktury swap_info_struct odkládací subsystém udržuje pro každé odkládací zařízení strukturu address_space. Tato struktura obsahuje mapování mezi stránkami v paměti a jejich odpovídající prostor v paměti na odkládacím zařízení. Změny v přidělování odkládacího prostoru vyžadují aktualizaci radixového stromu ve struktuře address_space, přičemž tento radixový strom je chráněn dalším zámkem. Vzhledem k tomu, že na systému je obvykle jen jedno odkládací zařízení, jedná se o další globální zámek, o nějž musí soutěžit všechna CPU.

Řešením je v tomto případě varianta přístupu ke clusterům. Struktura address_space je replikována do mnoha struktur, jednou pro každých 64 MB odkládacího prostoru. Pokud má odkládací prostor (například) 10 GB, bude jedna struktura address_space rozdělena na 160 částí, každou s vlastním zámkem. Jasně to snižuje rozsah soupeření o každý dílčí zámek. Patch také dbá o to, že počáteční alokace odkládacích clusterů umístí každé CPU do samostatného address_space, čímž zajistí, že nedojde k soutěžení hned na začátku (ale jakmile bude systém nějakou dobu v chodu, budou vzorce odkládacího prostoru v podstatě náhodné).

Podle Chena přidávají současná jádra přidávají asi 15µs režii ke každému výpadku stránky, která je řešena čtením z odkládacího SSD. To je podle něj srovnatelné s časem, který je potřeba k samotnému přečtení dat z tohoto zařízení. Po aplikaci patchů klesne režie na 4 µs, což je výrazné zlepšení. V době psaní tohoto článku nebyly k sadě patchů definitivní připomínky, ale vypadá to jako ten druh vylepšení, který odkládací subsystém potřebuje, aby mohl se současnými úložišti pracovat efektivně.

       

Komentáře

[troll master 4]

"Široce zastoupený názor říká, že swapování je téměř vždy špatnou zprávou." To ovšem neplatí pro Windows, tam se swapuje hned od bootu a je to úplně noumální.

[Sten]

To je ten systém, kde potřebujete 32 GiB RAM, aby aplikace mohly použít 8 bez toho, aby začaly swapovat?

[David Ježek]

No, to je otázka. Tuhle jsem pouštěl Skyrim na Windows 8.1 x64 a měl jsem pár minut dojem, že se lokace načítají trošičku pomaleji, než jsem zvyklý. Letmá kontrola ukázala, že 1 z 2 osazených DIMMů nefunguje, takže to celé jede na 2 GB RAM. No, SSD se asi dost zapotilo, ale já to málem nepoznal.

[pavele]

Ne, to je ten systém s 32 GB RAM, na kterém kopíruješ 50 GB dat a systém začne swapovat (i při nastavení swappiness na 3 a vfs_cache_pressure na 10000).

Pak musíš šaškovat s ionice nebo cgroup.

[Michal Kubeček]

Někteří lidé mají zajímavé představy o tom, co znamená "swapovat"…