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í
×

dnes 00:44 | Pozvánky

V sobotu 21. října 2017 se na půdě Elektrotechnické fakulty ČVUT v Praze uskuteční RT-Summit – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt.

… více »
Pavel Píša | Komentářů: 0
včera 23:44 | Bezpečnostní upozornění

V Linuxu byla nalezena bezpečnostní chyba CVE-2017-15265 zneužitelná k lokální eskalaci práv. Jedná se o chybu v části ALSA (Advanced Linux Sound Architecture).

Ladislav Hagara | Komentářů: 0
včera 22:44 | Komunita

Greg Kroah-Hartman informuje na svém blogu, že do zdrojových kódu linuxového jádra bylo přidáno (commit) prohlášení Linux Kernel Enforcement Statement. Zdrojové kódy Linuxu jsou k dispozici pod licencí GPL-2.0. Prohlášení přidává ustanovení z GPL-3.0. Cílem je chránit Linux před patentovými trolly, viz například problém s bývalým vedoucím týmu Netfilter Patrickem McHardym. Více v často kladených otázkách (FAQ).

Ladislav Hagara | Komentářů: 1
včera 22:04 | Pozvánky

Rádi bychom vás pozvali na přednášku o frameworku Avocado. Jedná se o testovací framework další generace, inspirovaný Autotestem a moderními vývojovými nástroji, jako je třeba git. Přednáška se bude konat 23. října od 17 hodin na FEL ČVUT (Karlovo náměstí, budova E, auditorium K9 – KN:E 301). Více informací na Facebooku.

… více »
mjedlick | Komentářů: 0
včera 21:44 | Bezpečnostní upozornění

Nový útok na WPA2 se nazývá KRACK a postihuje prakticky všechna Wi-Fi zařízení / operační systémy. Využívá manipulace s úvodním handshake. Chyba by měla být softwarově opravitelná, je nutné nainstalovat záplaty operačních systémů a aktualizovat firmware zařízení (až budou). Mezitím je doporučeno používat HTTPS a VPN jako další stupeň ochrany.

Václav HFechs Švirga | Komentářů: 1
15.10. 00:11 | Zajímavý projekt

Server Hackaday představuje projekt RainMan 2.0, aneb jak naučit Raspberry Pi 3 s kamerovým modulem pomocí Pythonu a knihovny pro rozpoznávání obrazu OpenCV hrát karetní hru Blackjack. Ukázka rozpoznávání karet na YouTube. Zdrojové kódy jsou k dispozici na GitHubu.

Ladislav Hagara | Komentářů: 0
14.10. 15:11 | IT novinky

Online obchod s počítačovými hrami a elektronickými knihami Humble Bundle byl koupen společností IGN. Dle oficiálních prohlášení by měl Humble Bundle dále fungovat stejně jako dosud.

Ladislav Hagara | Komentářů: 7
14.10. 06:00 | Zajímavý článek

Brendan Gregg již v roce 2008 upozornil (YouTube), že na pevné disky se nemá křičet, že jim to nedělá dobře. Plotny disku se mohou rozkmitat a tím se mohou prodloužit časy odezvy pevného disku. V září letošního roku proběhla v Buenos Aires konference věnovaná počítačové bezpečnosti ekoparty. Alfredo Ortega zde demonstroval (YouTube, pdf), že díky tomu lze pevný disk použít také jako nekvalitní mikrofon. Stačí přesně měřit časy odezvy

… více »
Ladislav Hagara | Komentářů: 7
13.10. 14:33 | Komunita

Společnost SUSE natočila a na YouTube zveřejnila dva nové videoklipy: 25 Years - SUSE Music Video (7 Years parody) a Linus Said - Music Parody (Momma Said).

Ladislav Hagara | Komentářů: 6
13.10. 12:55 | Zajímavý projekt

Autoři stránky Open Source Game Clones se snaží na jednom místě shromažďovat informace o open source klonech proprietárních počítačových her. Přidat další hry nebo návrhy na zlepšení lze na GitHubu. Na stránce Open Source Text Games jsou shromažďovány informace o open source textových hrách. Opět lze k vylepšení nebo doplnění stránky použít GitHub.

Ladislav Hagara | Komentářů: 1
Těžíte nějakou kryptoměnu?
 (6%)
 (2%)
 (15%)
 (76%)
Celkem 717 hlasů
 Komentářů: 24, poslední 27.9. 08:30
    Rozcestník

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

    6.8. | Redakce | Jaderné noviny | 3553×

    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. 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.