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 23:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 145. brněnský sraz, který proběhne v pátek 20. října od 18:00 hodin v restauraci Time Out na adrese Novoměstská 2 v Řečkovicích. Jedná se o poslední sraz před konferencí OpenAlt 2017, jež proběhne o víkendu 4. a 5. listopadu 2017 na FIT VUT v Brně. Běží registrace účastníků.

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

Byla vydána verze 5.2.0 multiplatformního virtualizačního nástroje Oracle VM VirtualBox. Jedná se o první stabilní verzi z nové větve 5.2. Z novinek lze zmínit například možnost exportování VM do Oracle Cloudu, bezobslužnou instalaci hostovaného systému nebo vylepšené GUI. Podrobnosti v seznamu změn. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 1
včera 14:00 | Zajímavý projekt

Byl spuštěn Humble Down Under Bundle. Za vlastní cenu lze koupit multiplatformní hry The Warlock of Firetop Mountain, Screencheat, Hand of Fate a Satellite Reign. Při nadprůměrné platbě (aktuálně 3,63 $) také Hacknet, Hacknet Labyrinths, Crawl a Hurtworld. Při platbě 12 $ a více lze získat navíc Armello.

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

Google Chrome 62 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 62.0.3202.62 tohoto webového prohlížeče přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře (YouTube). Opraveno bylo 35 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 2
včera 11:00 | Zajímavý článek

Článek (en) na Mozilla.cz je věnován vykreslování stránek ve Firefoxu. V průběhu roku 2018 by se ve Firefoxu měl objevit WebRender, jenž by měl vykreslování stránek urychlit díky využití GPU.

Ladislav Hagara | Komentářů: 4
včera 08:22 | Bezpečnostní upozornění

NÚKIB (Národní úřad pro kybernetickou a informační bezpečnost) informuje o zranitelnosti ROCA v procesu generování RSA klíčů, který se odehrává v softwarové knihovně implementované například v kryptografických čipových kartách, bezpečnostních tokenech a dalších hardwarových čipech vyrobených společností Infineon Technologies AG. Zranitelnost umožňuje praktický faktorizační útok, při kterém útočník dokáže vypočítat

… více »
Ladislav Hagara | Komentářů: 3
včera 01:23 | Zajímavý software

Příspěvek na blogu otevřené certifikační autority Let's Encrypt informuje o začlenění podpory protokolu ACME (Automatic Certificate Management Environment) přímo do webového serveru Apache. Klienty ACME lze nahradit novým modulem Apache mod_md. Na vývoj tohoto modulu bylo uvolněno 70 tisíc dolarů z programu Mozilla Open Source Support (MOSS). K rozchození HTTPS na Apache stačí nově přidat do konfiguračního souboru řádek s ManagedDomain. Minutový videonávod na YouTube [reddit].

Ladislav Hagara | Komentářů: 2
17.10. 14:15 | Komunita

Daniel Stenberg, autor nástroje curl, na svém blogu oznámil, že obdržel letošní Polhemovu cenu, kterou uděluje Švédská inženýrská asociace za „technologickou inovaci nebo důvtipné řešení technického problému“.

marbu | Komentářů: 10
17.10. 13:40 | Pozvánky

Cílem Social Good Hackathonu, který se uskuteční 21. a 22. října v Brně, je vymyslet a zrealizovat projekty, které pomůžou zlepšit svět kolem nás. Je to unikátní příležitost, jak představit nejrůznější sociální projekty a zrealizovat je, propojit aktivní lidi, zástupce a zástupkyně nevládních organizací a lidi z prostředí IT a designu. Hackathon pořádá brněnská neziskovka Nesehnutí.

… více »
Barbora | Komentářů: 1
17.10. 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ářů: 8
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (13%)
 (2%)
 (0%)
 (2%)
 (73%)
 (11%)
Celkem 62 hlasů
 Komentářů: 4, poslední včera 21:50
    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.