abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 21:11 | Nová verze

Po půl roce vývoje od vydání verze 8.0.0 byla vydána verze 9.0.0 překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, Extra Clang Tools, LLD a Libc++. Vývojáři zdůrazňují podporu "asm goto", díky které lze pomocí Clangu přeložit například Linux pro x86_64 (CONFIG_JUMP_LABEL=y).

Ladislav Hagara | Komentářů: 2
včera 14:00 | Nová verze

Bylo vydáno Eclipse IDE 2019-09 aneb Eclipse 4.13. Představení novinek na YouTube. Vydána byla také nová verze 7 online IDE Eclipse Che.

Ladislav Hagara | Komentářů: 0
včera 11:11 | Nová verze

Byla vydána verze 24.0 svobodného softwaru OBS Studio (Open Broadcaster Software, Wikipedie) určeného pro streamování a nahrávání obrazovky počítače. Přehled novinek na GitHubu nebo pomocí krátkých videí na Twitteru.

Ladislav Hagara | Komentářů: 3
včera 11:00 | Komunita

Microsoft představil a pod licencí SIL Open Font License (OFL) na GitHubu zveřejnil font Cascadia Code. Font je určen především pro zobrazování textu v emulátorech terminálu a vývojových prostředích (Přehled fontů s pevnou šířkou).

Ladislav Hagara | Komentářů: 12
18.9. 21:11 | Zajímavý software

Souborový systém exFAT se běžně používá na paměťových médiích jako karty SDXC, ale z licenčních důvodů jej nebylo možné začlenit do Linuxu, ačkoliv v roce 2013 unikl ovladač od Samsungu, jak shrnuje článek na Linux Weekly News. Park Ju Hyung nedávno vzal novější verzi ovladače od Samsungu a založil na ní vlastní projekt exfat-linux, který je k dispozici uživatelům.

Fluttershy, yay! | Komentářů: 9
18.9. 05:55 | Pozvánky

Dnes a zítra pořádá Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) ve spolupráci se studentským portálem Security Outlines konferenci CyberCon Brno 2019. Sledovat ji lze také online.

Ladislav Hagara | Komentářů: 0
18.9. 04:44 | Nová verze

Byla vydána Java 13 / JDK 13. Nových vlastností (JEP - JDK Enhancement Proposal) je 5. Nová Java / JDK vychází každých 6 měsíců.

Ladislav Hagara | Komentářů: 2
18.9. 03:33 | Komunita

Mozilla.cz informuje (en), že Mozilla postupně zrychlí pravidelné vydávaní nových verzí Firefoxu na 4 týdny. Aktuálně jsou vydávány nové verze Firefoxu každých 6 až 8 týdnů.

Ladislav Hagara | Komentářů: 13
17.9. 18:44 | Nová verze

MojeFedora.cz informuje (en) o vydání betaverze Fedory 31, tj. dalšího mezníku na cestě k plánovanému vydání Fedora 31 na konci října. K dispozici je v edicích Workstation a Server. Můžete také vyzkoušet jeden ze spinů, labů nebo verzi pro ARM.

Ladislav Hagara | Komentářů: 0
17.9. 17:00 | Nová verze

Byl vydán CentOS Linux 7 (1908) vycházející z Red Hat Enterprise Linuxu 7.7. Podrobnosti v poznámkách k vydání.

Ladislav Hagara | Komentářů: 1
Kdy jste naposledy viděli počítač s připojeným běžícím CRT monitorem?
 (20%)
 (4%)
 (10%)
 (38%)
 (27%)
 (2%)
Celkem 178 hlasů
 Komentářů: 18, poslední včera 09:03
Rozcestník

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

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

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.

       

Hodnocení: 100 %

        špatnédobré        

Nástroje: Tisk bez diskuse

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

8.8.2017 09:43 Xerces
Rozbalit Rozbalit vše Re: Jaderné noviny – 29. 6. 2017: daxctl() – získání druhé poloviny výkonu perzistentní paměti
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á. :-)
ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.