Jaderné noviny - 28. 4. 2016: Summit o úložištích, souborových systémech a správě paměti podrobněji

9. 5. 2016 | Redakce | Jaderné noviny | 2654×

Stav vydání jádra. Citát týdne. Summit o úložištích, souborových systémech a správě paměti podrobněji.

Stav vývoje jádra

Současný vývojový kernel je 4.6-rc5, vydaný 24. dubna. Linus k tomu řekl: „Vše pokračuje v poklidu: rc5 je větší než rc4, ale rc4 byla maličká. A zatímco jsme zpět na počtu commitů, který je pro tohle vydání normální, typy chyb, které lidi nacházejí jsou stále nízké úrovně: nic hrozivého. Pokud bude vše pokračovat takto, mohlo by jít o jedno z těch vydání, která se nedostanou na rc7.“

Stabilní aktualizace: 4.5.2, 4.4.8 a 3.14.67 byly vydány 21. dubna.

Citát týdne

Drobné žádosti o zařazení mi vůbec nevadí a nevnímám „jen jeden malinký commit“ jako špatnou věc. Právě naopak. Tyto žádosti jsou jednoduché a mám dobrý pocit, že v subsystému je „vše v klidu, ale ne proto, že odpovědný správce lidem neodpovídá.“

- Linus Torvalds

Podrobněji o summitu věnovaném úložištím, souborovým systémům a správě paměti

Tento týden (a pravděpodobně i ty následující) se zde budeme podrobněji věnovat summitu o úložištích, souborových systémech a správě paměti. Pro kompletní přehled všech diskuzí a částí navštivte příslušnou stránku přímo na LWN. (Překlad jsme přinesli v minulých Jaderných novinách, do originálu mezitím přibývají další odkazy.)

Víceúrovňové radixové stromy

Radixové stromy mají v jádře celou řadu využití, z nichž vyčnívá ukládání spojitostí mezi stránkami v paměti a bloky souborů, kam se data skutečně ukládají. Tento specifický strom byl navržen s předpokladem, že všechny stránky mají stejnou velikost. Při použití velkých stránek musí být každý stránka zastoupena mnoha záznamy (většinou 512) v radixovém stromu, což není zrovna efektivní. Podporou více úrovní pro radixové stromy se zabývá Matthew Wilcox. Svou práci popsal na summitu.

Základní myšlenkou celé práce je umožnit radixovému stromu držet jeden jediný záznam pro reprezentaci celé velké stránky. Je to užitečné jak pro perzistentní paměť, která se nejefektivněji spravuje právě pomocí velkých stránek, tak pro mechanismus transparentních velkých stránek. Objevily se návrhy, že by to mohlo být přínosem pro souborové systémy při správě velkých bloků souborů, tím si však Matthew není jistý. I tak chtěl dát vývojářům vědět, že takto funkcionalita je nyní dostupná.

Výsledkem je drobná změna API radixového stromu. Nízkoúrovňové funkce __radix_tree_create() a __radix_tree_insert() nyní obsahují argumenty order, které indikují velikost vloženého záznamu. Ovšem kód, který víceúrovňové radixové stromy využívá, si vyžádá výrazné úpravy, aby byl připraven na víceúrovňové vstupy, které se budou vracet z vyhledávacích operací.

Vnitřně je novinka implementována označením ukazatele s „nepřímým“ bitem k označení uzlů ve stromu. Pokud je tento bit prázdný, odkazuje ukazatel k uživatelským datům. Na spodní úrovni stromu řada „sourozeneckých“ záznamů obsahuje ukazatele na kanonický záznam stránky. Zvláštní je, že strom neukládá úroveň (pořadí) stránky, uživatelé musí tyto informace získat jiným způsobem.

James Bottomley se zeptal, zda by se strom nedal použít k detekci možností pro použití větších stránek. Matthew odpověděl, že pravděpodobně nejde o to nejlepší místo, kde to řešit. Chris Mason řekl, že se jednou pokusil přimět Btrfs k použití pahýlů v radixovém stromu jako druh zámku při provádění přímého I/O – tato technika by se dala snáze implementovat za použití diskutované funkcionality. Snad by pak přímé I/O nebylo „až takovou noční můrou.“ Jan Kára poznamenal, že se pracuje na podobných věcech, které podporují mechanismus přímého přístupu DAX. Také dodal, že stránková cache používá záznamy radixových stromů k označení stránek k zahození, což by mohlo narušit jiné případy využití. Správným řešením by snad mohlo být použití dlouho diskutovaného mechanismu uzamykání výseků stránek. To už se však sekce rozvolnila a tento nápad se již dále neprobral.

Kontejnery a virtuální stroje

Kontejnery a virtuální stroje jsou dva odlišné mechanismy pro sdílení fyzického hostitele mezi několika hosty. Kontejnery bývají v porovnání s virtualizací úspornější na zdroje, ale virtuální stroje dokážou nabídnout silnější izolaci. Rik van Riel začal sekci Správy paměti na letošním summitu konstatováním o zvýšeném zájmu o využití virtuálních strojů jako kontejnerů. Jedním z problémů takového využití je ten, že ne každý virtuální stroj provádí kešování a je-li ponechán svému osudu, zaplní svou paměť daty z cache. To má za následek, že systémy používají mnohem více paměti, než kolik opravdu potřebují, a tak se snižuje počet virtuálních strojů, které je možné hostiteli přiřadit.

Současný přístup k tomuto problému představují balónové ovladače (ballon drivers), které se „nafouknou“ alokováním paměti z hosta a vrátí ji hostitelskému systému. To činí extrakci paměti z hostů efektivní, ale neodpovídá se tím na zásadní otázku: kdy by se tak mělo dít? Navzdory létům zkušeností s virtualizací stále nevíme, jak tento druh vyvažování paměti správně provádět.

James Bottomley navrhl možnost využití paravirtualizace, která by přesunula některá rozhodnutí o správě paměti z hosta na hostitele. Například projekt Clear Containers využívá mechanismu DAX – implementovaného tak, aby umožnil přímý přístup k datům uloženým v perzistentní paměti – ke sdílení stránkovacích souborů s hostitelem. Toto funguje dobře, i když sdílení anonymních stránek by bylo složitější. Možná by host mohl s hostitelem sdílet svůj seznam LRU, potom by hostitel viděl, co se host snaží udělat, a mohl by o vyvážení paměti lépe rozhodnout.

Sdílení všech dat uložených v cache mezi všemi hosty a hostitelem by za pomoci paravirtualizované cache stránek mělo být proveditelné, řekl James: „jak těžké to může být?“

I když přesuneme kešování stránek z hosta, stále by zde měla být možnost vyvíjet na něj tlak ohledně paměti (memory pressure). Ostatní cache, jako ty pro inode či dentry, by se stále mohly rozpínat, aby zaplnily zbývající dostupnou paměť. Takže potřeba najít způsob, jak kvantifikovat tlak paměti a komunikovat jej mezi hostitelem a hosty, nemizí. Ke konci sekce se přítomní shodli na tom, že ve hře jsou zajímavé nápady. Jak brzy se je podaří proměnit v kód, ovšem zůstává otázkou.

Heterogenní správa paměti

Procesor, který bereme jako ten „hlavní“, není jediným procesorem na většině systémů, ve skutečnosti nebývá ani tím nejrychlejším. Připojená zařízení, v první řadě GPU, mají své vlastní procesory, které mohou urychlit řadu výpočetních úloh. Často mívají plný přístup k systémové paměti, ale zřejmá omezení brání úplnému sdílení této paměti mezi CPU a dalšími procesory. Subsystém heterogenní správy paměti si klade za cíl takové sdílení umožnit. Sekci o heterogenní správě paměti na summitu vedl Jérôme Glisse.

Klíčovou vlastností heterogenní správy paměti (HSP) je podle Jérôma možnost zrcadlit adresní prostor procesu v rámci připojeného procesoru. Mělo by se tak dít bez nutnosti použít speciálního alokátoru v uživatelském prostoru. Po hardwarové stránce existuje několik technologií, které toto zrcadlení usnadňují. Jednou je rozhraní PowerPC CAPI, další mechanismus PASID pro sběrnici PCI Express. Na straně softwaru je možné buď zrcadlit tabulku stránek CPU v připojeném procesoru, nebo migrovat stránky tam a zpět mezi CPU a pamětí zařízení. Smyslem je, bez ohledu na způsob, prezentovat stejné API uživatelskému prostoru.

Záleží nám na tom, řekl Jérôme, protože hardware, který to umí, již existuje. Zmínil hlavně produkty společností Mellanox a Nvidia. Existují ovladače pro hardware, který je momentálně drahý, ale ještě letos zlevní. Pokud neposkytneme řešení v kernelu, poběží vše mnohem pomaleji a bude zapotřebí pinnování spousty paměti. Do kódu ovladačů zařízení bude nutné přidat mnohem více oznamovatelů MMU (memory-management unit notifiers), což málokdo považuje za žádoucí. Podpora OpenCL bude možná pouze na integrovaných GPU. Je-li to možné, je lepší tuto funkci v jádře podporovat, řekl Jérôme.

Řešením stávající neveselé situace je sada patchů, která poskytuje jednoduché API ovladačů pro úkony týkající se správy paměti. Dokáže zrcadlit stránkovací tabulky CPU na připojené zařízení a udržovat je synchronizované, zatímco dochází ke změnám na straně CPU. Stránky mohou být přesouvány mezi CPU a zařízením – stránka přesunutá z CPU je reprezentována zvláštním typem záznamu, jinými slovy vypadá, jakoby byla odsunuta. HSP se rovněž stará o DMA mapování připojeného zařízení.

Andrew Morton poznamenal, že tento patch set představuje „tuny kódu“, což zpravidla komplikuje jeho zařazení. Přišla tedy řeč na rozsekání na menší, snáze stravitelné kousky. Některý kód se zjevně také hodí k virtualizaci KVM. Andrew Jérômemu navrhl, aby zdokumentoval, kdo diskutovaný kód vlastně bude používat. „Pak už je to jen otázka toho zvednout zadky a zkontrolovat ten kód.“ Komplikace se mohou skrývat v použití oznamovatelů MMU, protože Linus už dříve dal najevo, že oznamovatele nevidí rád.

Všeho všudy však žádné námitky k jádru pudla nepadly. HSP se už nějaký ten rok vyvíjí a možná už se konečně také blíží k zařazení do hlavní větve jádra.

       

Komentáře