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:33 | Zajímavý software

    plwm je nový, poměrně minimalistický správce oken pro X11. Podporuje dynamické dláždění okny, plochy, pravidla pro okna atd. Zvláštností je, že je napsaný v logickém programovacím jazyce Prolog. Používá implementaci SWI-Prolog.

    Fluttershy, yay! | Komentářů: 2
    dnes 00:22 | Komunita

    Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.

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

    Sean Heelan se na svém blogu rozepsal o tom, jak pomocí OpenAI o3 nalezl vzdálenou zranitelnost nultého dne CVE-2025-37899 v Linuxu v implementaci SMB.

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

    Jiří Eischmann v příspěvku na svém blogu představuje typy, jak lépe chránit své soukromí na mobilním telefonu: "Asi dnes neexistuje způsob, jak se sledování vyhnout úplně. Minimálně ne způsob, který by byl kompatibilní s tím, jak lidé technologie běžně používají. Soukromí ovšem není binární věc, ale škála. Absolutního soukromí je dnes na Internetu dost dobře nedosažitelné, ale jen posun na škále blíže k němu se počítá. Čím méně dat se o vás posbírá, tím nepřesnější budou vaše profily a tím méně budou zneužitelné proti vám."

    Ladislav Hagara | Komentářů: 12
    včera 00:22 | Nová verze

    Byla vydána nová stabilní verze 25.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Warbler. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.

    Ladislav Hagara | Komentářů: 0
    23.5. 18:11 | Nová verze

    Multiplatformní open source spouštěč her Heroic Games Launcher byl vydán v nové stabilní verzi 2.17.0 Franky (Mastodon, 𝕏). Přehled novinek na GitHubu. Instalovat lze také z Flathubu.

    Ladislav Hagara | Komentářů: 0
    23.5. 18:00 | Nová verze

    Organizace Apache Software Foundation (ASF) vydala verzi 26 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.

    Ladislav Hagara | Komentářů: 0
    23.5. 14:55 | IT novinky

    Klávesnice IBM Enhanced Keyboard, známá také jako Model M, byla poprvé představena v roce 1985, tzn. před 40 lety, s počítači IBM 7531/7532 Industrial Computer a 3161/3163 ASCII Display Station. Výročí připomíná článek na zevrubném sběratelském webu Admiral Shark's Keyboards. Rozložení kláves IBM Enhanced Keyboard se stalo průmyslovým standardem.

    Fluttershy, yay! | Komentářů: 6
    23.5. 12:00 | Nová verze

    Vyšlo Pharo 13 s vylepšenou podporou HiDPI či objektovým Transcriptem. Pharo je programovací jazyk a vývojové prostředí s řadou pokročilých vlastností.

    Pavel Křivánek | Komentářů: 3
    23.5. 04:00 | IT novinky

    Java má dnes 30. narozeniny. Veřejnosti byla představena 23. května 1995.

    Ladislav Hagara | Komentářů: 7
    Jaký je váš oblíbený skriptovací jazyk?
     (56%)
     (29%)
     (7%)
     (4%)
     (0%)
     (0%)
     (5%)
    Celkem 105 hlasů
     Komentářů: 8, poslední dnes 15:58
    Rozcestník

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

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

    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.