Jaderné noviny – 29. 6. 2017: daxctl() – získání druhé poloviny výkonu perzistentní paměti

6. 8. 2017 | Redakce | Jaderné noviny | 3958×

Stav vydání jádra. Citáty týdne: Linus Walleij a Casey Schaufler. daxctl() – získání druhé poloviny výkonu perzistentní paměti.

Stav vydání jádra

Současné vývojové jádro je 4.12-rc7, vydané 25. června. Linus k tomu řekl: „Je celkem malé, nedostalo se nám žádných velkých překvapení, takže pokud se v následujícím týdnu nestane nic nečekaného, bude to poslední kandidát na vydání. Ale jako obvykle si vyhrazuji právo to trochu natáhnout, pokud se mi něco nebude z nějakého důvodu zdát, a to i intuitivně, takže uvidíme.“

Stabilní aktualizace: 4.11.7 a 4.9.34 byly vydány 24. června. Následovaly je 4.4.74 a 3.18.58 dne 26. června.

Další aktualizace 4.11.8, 4.9.35, 4.4.75 a 3.18.59 byly v době psaní článku revidovány a vyšly později 29. června.

Citáty týdne

Mexický pat dodavatelů GPU je fraška odsouzená k tomu stát se terčem posměchu dějin lidstva. Spíš bych věřil ovladačům vyvinutým pomocí reverzního inženýrství, jako jsou Feedreno nebo skvělá práce lidí od etnavivu.

—Linus Walleij

Kombinace SELinuxu, Smacku, AppArmoru a/nebo TOMOYO není ani tak cíl, jako spíš testovací případ. MAC byla ta nejúžasnější technologie v roce 1990. Implementovali jsme ji. Nedovedu si představit, že by někdo dělal na nové implementaci MAC. Co si představit *dovedu*, je práce na bezpečnostních modulech implementujících jiné modely bezpečnosti. Některé z nich potřebují udržovat stav, což znamená, že v architektuře LSM používají bezpečnostní bloby. Některé z těchto modelů budou chtít použít secmarks k implementaci řízení na základě soketů. Pokud se nám to podaří poskytnout pro SELinux+Smack*, můžeme si být celkem jisti, že budeme moci podporovat cokoli, co dnešní děcka chtějí. Pokud to vyhodíme / zrušíme, Linux se nebude moct přizpůsobit bezpečnostním požadavkům budoucnosti.

—Casey Schaufler

daxctl() – získání druhé poloviny výkonu perzistentní paměti

Perzistentní paměť slibuje vysokorychlostní přístup k úložišti s adresací po bajtech a z toho plynou příslušné výhody pro nejrůznější typy aplikací. Ale ukázalo se, že skutečné dosažení těchto výhod představuje pro jadernou komunitu řadu výzev. Perzistentní paměť není běžnou pamětí ani běžným úložištěm, takže tradiční přístupy k paměti a úložištím se pro tento nový svět ne vždy hodí. Návrh nového systémového volání daxctl() spolu s následnou diskuzí ukazuje, jak těžké je dostat z perzistentní paměti co nejvíce.

Mechanismus DAX umožňuje aplikaci mapovat soubor z perzistentního paměťového úložiště přímo do jejího adresního prostoru, aniž by do hry vstoupila jaderná cache stránek. Poté lze k datům v souboru přistoupit pomocí ukazatele – není třeba I/O operací nebo kopírování dat přes RAM. Zatím dobré, ale má to háček. Tento režim vyhovuje pouze aplikacím, které čtou data z perzistentní paměti. Jakmile dojde na zápis, věci se komplikují. Zápis může zahrnovat alokaci bloků na příslušném úložném zařízení a krom toho také vytváří aktualizace metadat, jež spravuje souborový systém. Pokud není řádně naloženo s těmito aktualizacemi metadat, nelze data považovat za správně zapsaná.

Konečným výsledkem je, že aplikace provádějící zápisy do perzistentní paměti musí volat fsync(), aby se ujistila, že se zápisy neztratí. Dokonce i když vývojář pamatuje na to, kde všude se tato volání mají provést, fsync() může vést k libovolnému množství I/O operací, a tak přidat volající aplikaci nepředvídatelnou latenci. Vývojáři, pokud si dávají tu práci s použitím DAXu, tak činí, aby získali výkon navíc. V takovém případě mají tendenci reagovat na nápady jako „nepředvídatelná latence“ poněkud nevraživě. Takže se dožadovali lepšího řešení.

daxctl()

Proto napsal Dan Williams v úvodu ke své řady patchů, že „příslib přístupu k perzistentní paměti s adresací po bajtech byl rozhraním mezi souborovým systémem a daxem splněn pouze z poloviny.“ Naplnění druhé poloviny vyžaduje, aby byl souborový systém mimo smyčku, pokud jde o operace zápisu. Kdyby, řekněme, soubor mohl být nastaven tak, aby nedocházelo ke změně metadat v reakci na zápis, problém by prostě zmizel. Aplikace by byly schopné zapisovat do paměti mapované DAX a pokud by si zajistily, že jejich vlastní zápisy budou skutečně správně uloženy na perzistentním úložišti (což se v uživatelském prostoru dá udělat několika speciálními instrukcemi), obavy ze ztráty metadat by měly pominout.

Williamsův návrh na implementaci tohoto přístupu vyžaduje několik kroků. Prvním je, že aplikace musí zavolat fallocate(), aby se ujistila, že požadovaný soubor skutečně má bloky alokované v perzistentní paměti. Potom musí říct jádru, že soubor má být zpřístupněn skrze DAX a že stávající alokace bloků nelze za žádných okolností změnit. K tomu slouží následující nové systémové volání:

int daxctl(char *path, int flags, int align);

Zde path označuje požadovaný soubor, flags označuje požadovanou akci a align naznačuje velikost stránek, které by aplikace chtěla použít. Příznak DAXFILE_F_STATIC, pokud je přítomen, dá soubor do režimu „veškeré změny zcela zakázány“. Pokud tento příznak chybí, stane se soubor opět běžným souborem. Dokud je statický režim aktivní, všechny operace na souboru, které by si mohly vynutit změny metadat (např. změna velikosti pomocí truncate()), selžou a výsledkem bude chybový kód.

Implementace tohoto nového režimu by vyžadovala významné změny na úrovni souborového systému, ale ukazuje se, že tato funkcionalita již existuje. Používá ji odkládací subsystém, který při swapování do běžného souboru potřebuje vědět, kde se alokované bloky souboru nacházejí na disku. Tento mechanismus se skládá ze dvou částí, první je tato metoda address_space_operations:

/* Unfortunately this kludge is needed for FIBMAP. Don't use it */
sector_t (*bmap)(struct address_space *s, sector_t sector);

Volání bmap() vrátí číslo fyzického bloku, na kterém se daný sector nachází. Odkládací subsystém tuto informaci používá k výměně stránek přímo na příslušném zařízení bez použití souborového systému. Aby bylo možné se ujistit, že se seznam fyzických bloků odpovídajících odkládacímu souboru nemění, odkládací subsystém danému souboru přidělí příznak inode S_SWAPFILE. Testy rozsypané po celé vrstvě virtuálního souborového systému (a samotných souborových systémech) zablokují všechny operace, které by změnily rozložení souboru s tímto příznakem.

Tato funkcionalita je shodná s tím, co DAX potřebuje k bezpečnému přímému zápisu do perzistentní paměti. Takže systémové volání daxctl() jednoduše znovu použilo tento mechanismus a dalo soubor do režimu, ve kterém není možné měnit metadata, aniž by se používal ke swapování.

MAP_SYNC

Christoph Hellwig neváhal, aby vyjádřil nesouhlas s tímto nápadem. Byl by radši, kdyby se metoda bmap() nepoužívala nikde jinde v jádře. Podle jeho názoru je rozbitá hned na několik způsobů. Její užití při swapování je rovněž rozbité, říká, ačkoliv „jsme to zvládli přehlížet.“ Navrhl, že by se vývoj měl spíše zaměřit na stabilitu DAXu, než se budou přidávat nové funkce.

Alternativní přístup, který navrhl Andy Lutomirski, se objevil už dříve, a to (pod označením MAP_SYNC) během diskuze o příznaku „vím, co dělám“ začátkem roku 2016. Ústřední myšlenka je transparentně se ujistit, že souborový systém se postará o potřebná metadata dříve, než má aplikace možnost zapsat do stránky, které se tato změna týká. Toho by se dalo dosáhnout pomocí ochrany postižených stránek před zápisem a následným zápisem potřebných změn v rámci procesu obsluhy chyby zápisu do některé z těchto stránek. Teoreticky by tento přístup měl pokrýt mnoho případů užití blokovaných technikou daxctl(), včetně změn v délce souborů, sémantiky copy-on-write, souběžného přístupu a dalších. Jedná se o zdánlivě jednoduchý nápad, který však ukrývá velkou složitost. Jeho implementace by nebyla jednoduchá.

Kromě složitosti implementace má MAP_SYNC další problém: je v rozporu s původním cílem mít nízkou latenci. Zápis metadat do souborového systému může být zdlouhavý a složitý úkol, vyžadující značné množství procesorového času a I/O. Svěření této práce obsluze výpadků stránek znamená, že výpadky stránek mohou zabrat libovolně dlouhou dobu. Jak říká Dave Chinner:

Předpověď budoucnosti MAP_SYNC: častá hlášení chyb týkající se velkých, nepředvídatelných latencích výpadků stránek na souborech s DAX, protože jednou za čas vyžaduje výpadek stránky synchronizaci desítek tisíc nesouvisejících špinavých objektů kvůli omezením uspořádání žurnálu souborového systému.

Došlo k diskuzi o tom, jak by se dal omezit dopad aktualizací metadat na obsluhu výpadků stránek, ale nikdo nepřišel s nápadem, který by jej zcela eliminoval. Ti (například Hellwig), kdo podporují přístup s MAP_SYNC, uznávají, že je nákladný, ale považují jej za vhodnější než přidávat speciální jednoúčelové rozhraní, které přináší vlastní problémy se správou.

Na druhou stranu by tato práce mohla vést k vylepšením odkládacího subsystému, čímž by se stal robustnějším a zlepšila by se jeho kompatibilita se souborovými systémy (jako Btrfs), jejichž sémantika CoW se pořádává s přístupem „žádné změny na metadatech“ velmi bídně. Pro tuto funkcionalitu existuje další případ užití: vysokorychlostní DMA přímo do perzistentní paměti také vyžaduje, aby souborový systém nečinil žádné nečekané změny v mapování souboru. Společně s relativní přímočarostí Williamsova patche by to mohlo pomoci protlačit mechanismus daxctl(), přestože není všeobecně oblíbený.

Dá se říct, že skutečným poučením z této diskuze je, že perzistentní paměť není ideálním protějškem k sémantice poskytované unixovým API a současnými souborovými systémy. Časem se může ukázat, že je zapotřebí jiného typu rozhraní, alespoň pro aplikace, které chtějí z této technologie získat maximum výkonu. Nikdo ale doopravdy neví, jak by toto rozhraní mělo vypadat, takže současný přístup napasovat moderní mechanismy na to, co máme teď, může být nejlepší cestou kupředu.

       

Komentáře

[Xerces]

Nikdo ale doopravdy neví, jak by toto rozhraní mělo vypadat ... to je docela zajímavý a asi to svědčí o vyzrálosti těch vývojářů, protože co tak koukám kolem tak lidi většinou sami nejlíp vědí, jak by mělo něco vypadat a radši rozjedou svůj nový projekt, než aby si dali práci s opravou stávajícího. Podobnost se systemd (pokud to někoho napadlo) je čistě náhodná.