Jaderné noviny – 26. 1. 2017: Budoucnost cache stránek

13. 2. 2017 | Redakce | Jaderné noviny | 2673×

Stav vydání jádra. Vetter: správci neškálují. Budoucnost cache stránek.

Stav vydání jádra

Současný vývojový kernel 4.10-rc5 byl vydán 22. ledna. Linus jen poznamenal, že „vše se zdá v pořádku.“ Také změnil označení z krátkodobého „Roaring Lionus“ na „Anniversary Edition.“

Stabilní aktualizace: 4.9.5 a 4.4.44 byly vydány 20. ledna. Verze 4.9.6 a 4.4.45 byly v době psaní článku revidovány a vyšly 26. ledna.

Vetter: Správci neškálují

Daniel Vetter zveřejnil text svého příspěvku z linux.conf.au, který se týkal správy jádra. „Pro mě není revize kódu pouze o tom, ujistit se, že se jedná o kvalitní kód, ale také o rozšiřování znalostí a zlepšování porozumění. Nejprve rozumí kódu jen jeho autor (a ani to někdy neplatí). Po dobré revizi by mu měli rozumět alespoň dva lidé, a to opravdu dobře včetně okrajových případů. To je také důvod, proč si myslím, že skupinové správcovství je jediný způsob, jak provozovat jakýkoli projekt s víc než jedním pravidelným přispěvatelem.“

Budoucnost cache stránek

Příslib velké perzistentní paměti si vynutil řadu změn v jádře a vyvolal otázky o tom, zda vůbec bude jaderná cache stránek (page cache) v budoucnu zapotřebí. Matthew Wilcox ve své přednášce na linux.conf.au 2017 prohlásil, že cache stránek nejen potřebujeme, ale navíc by se její role měla zvětšit. Nejprve je ovšem třeba napravit chybu, kterou před pár lety udělal jistý pan Wilcox.

Wilcox začal tím, že jde o jeho první vystoupení jako zaměstnance Microsoftu, což si myslel, že nikdy neřekne. Potom se pustil do svého tématu se slovy, že při využívání počítače jde především o využívání cache. Jeho nový laptop umí provést 10 miliard operací za sekundu, ale pouze pokud nenastane cache miss. Paměť na jeho systému může poskytnout pouze 530 milionů řádek cache za sekundu, takže k vážnému ovlivnění výkonu stačí nemnoho takových selhání. Ještě horší je situace v případě, že data, která potřebujete, nejsou uložená v cache, ale je nutné je načíst z paměťového zařízení, byť se třeba jedná o rychlé SSD.

Vždy tomu tak bylo. PDP-11 bylo také výrazně zpomalováno cache miss. Jenže problém je čím dál horší. Rychlosti CPU vzrostly víc než rychlosti pamětí, které zase vzrostly víc než rychlosti úložišť. Cena nevyužívání cache vhodným způsobem stoupá.

Cache stránek

Unixové systémy už dávno měly rychlou vyrovnávací paměť (buffer cache), která se nacházela mezi souborovým systémem a diskem a sloužila ke kešování diskových bloků do paměti. Wilcox se při přípravě své prezentace podíval na šesté vydání Unixu (z roku 1975) a našel – vyrovnávací paměť. Linux ji obsahuje již od samého začátku. V roce 1995 přidal Linus Torvalds do vydání 1.3.50 významnou inovaci v podobě cache stránek. Od vyrovnávací paměti se liší tím, že se nachází mezi virtuálním souborovým systémem (VFS) a souborovým systémem samotným. Díky ní není třeba volat kód souborového systému v případě, že je požadovaná stránka již přítomna. Původně byly obě cache, vyrovnávací (buffer) a stránek (page), zcela oddělené, ale v roce 1999 je Ingo Molnár sjednotil. Vyrovnávací paměť stále existuje, ale záznamy v ní odkazují do cache stránek.

Cache stránek v sobě má zabudovanou spoustu funkcí. Některé jsou zřejmé, např. nalezení stránky podle zadaného indexu; pokud stránka neexistuje, je možné ji vytvořit a volitelně naplnit z disku. Špinavé stránky je možné odsunout zpět na disk. Stránky je možné zamykat, odemykat a odstranit z cache. Vlákna mohou čekat na změny ve stavu stránky a existují rozhraní pro vyhledávání stránek v daném stavu. Cache stránek také umí sledovat chyby spojené s trvalým úložištěm.

Zamykání cache stránek se provádí vnitřně. V jaderné komunitě přetrvávají neshody o tom, na jaké úrovni by se zamykání mělo provádět. V tomto případě se situace ustálila právě u vnitřního zamykání. Při úpravě cache stránek se k řízení přístupu používá spinlock, zatímco vyhledávání se obejde bez zámků – pomocí mechanismu RCU (read-copy-update).

Podle Wilcoxe je kešování uměním předvídat budoucnost. Když cache příliš naroste, vstoupí do hry různé heuristiky rozhodující, které stránky je třeba odstranit. U jednou použitých stránek je malá pravděpodobnost, že budou použity znovu, takže jsou uchovávány v seznamu neaktivních stránek a k jejich vytlačení dojde poměrně brzy. Druhé použití stránky ji přeřadí z „neaktivního“ seznamu do seznamu „aktivního“. Nevyužité stránky budou stárnutím vráceny zpět do „neaktivního“ seznamu. Výjimečné „stínové“ záznamy se používají ke sledování stránek, které vypadly z konce „neaktivního“ seznamu a došlo k jejich opětovnému použití. Tyto záznamy mají za následek prodlužování paměti jádra věnované stránkám, které byly naposledy použity v poměrně dávné minulosti.

Velké stránky představovaly pro cache stránek jistou dobu výzvu. Jaderné transparentní velké stránky původně pracovaly pouze s anonymní pamětí (která není založená na souborech). Pro používání velkých stránek v cache stránek však existují dobré důvody. Počáteční práce v této oblasti jednoduše přidává do cache stránek velký počet jednostránkových záznamů tak, aby odpovídaly jedné velké stránce. Wilcox došel k závěru, že tento přístup byl „hloupý.“ Proto vylepšil kód radixového stromu, který se používá ke sledování stránek v cache stránek, aby mohl spravovat záznamy velkých stránek přímo. Zatím nezařazené patche způsobí, že cache stránek použije pro velké stránky po jedné položce.

Je cache stránek stále potřeba?

Dave Chinner se nedávno vyjádřil, že cache stránek již není potřeba. Poznamenal, že subsystém DAX, původně vytvořený právě Wilcoxem za účelem poskytování přímého přístupu k datům souborů uloženým v perzistentní paměti, obchází cache stránek úplně. „Nic vás tak nepotěší, jako kolegové, kteří zpochybňují vaši motivaci,“ řekl Wilcox. Existují ale lidé, kteří s Chinnerem nesouhlasí, a to včetně Torvaldse, který se vynořil na samostatném fóru s tím, že cache stránek je důležitá, protože nutnost mít nízkoúrovňový kód souborového systému ve stěžejním postupu pro přístup k datům nevěstí nic dobrého.

S ohledem na tento výrok se Wilcox ponořil do toho, jak nyní pracuje I/O požadavek s použitím DAX. Když psal původní kód DAX, dospěl k závěru, že cache stránek není zapotřebí. Toto rozhodnutí bylo, jak řekl, mylné.

Když v současném jádře aplikace provede systémové volání, např. read() k přečtení dat ze souboru v perzistentní paměti, dojde k zapojení DAX. Vzhledem k tomu, že požadovaná data nejsou k dispozici v cache stránek, zavolá vrstva VFS funkci read_iter() použitého souborového systému. Ta zase volá kód DAX, který volá zpět souborovému systému, aby přeložil offset souboru na číslo bloku. Pak je bloková vrstva dotázána na umístění bloku v perzistentní paměti (s mapováním do adresního prostoru jádra, je-li to potřeba), aby obsah bloku mohl být zkopírován zpět do aplikace.

Není to až tak strašné, pokračoval Wilcox, ale mělo by to fungovat jinak. Úvodní kroky by byly stejné, stále by došlo k volání funkce read_iter(), která by volala do kódu DAX. Ale místo volání zpět souborovému systému by měl DAX volat cache stránek, aby získal fyzickou adresu spojenou s požadovaným offsetem v souboru. Potom by z této adresy došlo ke zkopírování dat zpět do uživatelského prostoru. Při tom všem se předpokládá, že dané informace jsou již přítomny v cache stránek, ale pokud tomu tak je, není třeba vůbec zapojovat nízkoúrovňový kód souborového systému. Souborový systém již svou práci vykonal a cache stránek uložila výsledek.

Torvalds ve výše zmíněném příspěvku napsal:

Z pohledu zamykacího mechanismu se také jedná o naprostou katastrofu: věřte mi, pokud si myslíte, že váš souborový systém zvládne jemné řešení zamykání, když jde o věci jako souběžné vyhledávání cest k souborům, žijete v říši snů.

Tohle je podle Wilcoxe fakt, zamykání v DAX bylo skutečně katastrofální. Původně myslel, že by bylo možné využívat relativně jednoduché zamykání, ale do každého objeveného okrajového případu se vloudila složitost. Zamykání DAX je nyní „opravdu hnusné“ a Wilcox lituje, že se chybně domníval, že by mohl cache stránek obejít. Nyní je třeba to napravit.

Budoucí práce

Svůj příspěvek uzavřel řadou zlepšení, která by kolem DAX a cache stránek rád viděl. Patří mezi ně zmíněná vylepšená podpora velkých stránek, která již čeká ve stromu -mm a měla by brzy být hotová. Používání struktur page místo čísel rámců stránek je stále projednáváno, protože nikdo moc netouží po tom, aby jádro uchovávalo velké množství struktur page pro velká pole perzistentní paměti.

Chtěl by se vrátit k myšlence souborových systémů s bloky, které by byly větší než systémová velikost stránky. Tohle lidé chtějí už mnoho let. Když už teď cache stránek zvládá více velikostí stránek, mělo by to být možné. „Je to prostě otázka toho to naprogramovat,“ řekl Wilcox. Hledá další zainteresované vývojáře, kteří by se na tom chtěli podílet.

Velké swapovací záznamy jsou další oblastí zájmu. V paměti máme velké anonymní stránky, ale když dojde na jejich swapování, jsou rozbity na běžné stránky. „To je pravděpodobně špatné řešení.“ Pracuje se na zlepšení výkonu swapování, ale je potřeba zaměřit se na to, aby velké stránky zůstaly pohromadě. To by mohlo pomoci myšlence s tím spojené, swapování do perzistentní paměti. Data ve swapovacím prostoru perzistentní paměti jsou stále přístupná, takže dává smysl je tam nechat, obzvláště když nejsou výrazně měněna.

Záznam přednášky je dostupný, a to včetně extra části věnované zamykání cache stránek.

       

Komentáře

[mikro]

Nie som expert na terminologiu, ale nebolo by vhodnejsie oznacovat "page cache" ako strankovu cache miesto cache stranok? Rovnako ako mame diskovu cache, tiez nehovorime "cache diskov".

[Fluttershy, yay!]

To přirovnání mi nesedí. Než abych to opisoval, Wiki říká:

While CPU caches are generally managed entirely by hardware, a variety of software manages other caches. The page cache in main memory, which is an example of disk cache, is managed by the operating system kernel.

While the disk buffer, which is an integrated part of the hard disk drive, is sometimes misleadingly referred to as "disk cache", its main functions are write sequencing and read prefetching. Repeated cache hits are relatively rare, due to the small size of the buffer in comparison to the drive's capacity. However, high-end disk controllers often have their own on-board cache of the hard disk drive's data blocks.

[Petr Tomášek]

häää?

[Michal Kubeček]

To je už klasický rant "Až půjdu přes Most Karla do Divadla národa na Stěnu čerta…" IMHO je to ale spíš věc vkusu a stylu, neřekl bych, že je jedno z toho vysloveně špatně.

[MMMMMMMMM]

Díky za zajímavý článek! :)