![[Swap file data structures]](https://static.lwn.net/images/2016/swap_cluster.svg)
Portál AbcLinuxu, 8. května 2025 23:28
Stav vydání jádra. Citáty týdne: Rusty Russel, Dave Chinner a Linus Torvalds. Škálovatelný odkládací prostor.
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.
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í.
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)
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."
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:
![[Swap file data structures]](https://static.lwn.net/images/2016/swap_cluster1.svg)
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ě.
10.11.2016 15:00
David Ježek | skóre: 83
| blog: Mostly_IMDB
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.