Jaderné noviny - 12. 3. 2015: Pokrok v perzistentní paměti

29. 6. 2015 | Redakce | Jaderné noviny | 2664×

Stav vydání jádra. Citáty týdne. Pokrok v perzistentní paměti.

Stav vydání jádra

Aktuální vývojové jádro je 4.0-rc3, vydané 8. března. "Zpátky na zavedeném harmonogramu vydávání v neděli odpoledne. Jelikož se tento týden neobjevilo nic obzvlášť divného, žádná chyba na poslední chvíli, o které bych věděl, a pozdržel věci její opravou."

Stabilní aktualizace: 3.19.1, 3.18.9, 3.14.35 a 3.10.71 byly vydány 7. března.

Citáty týdne

I bez vynálezu nějaké samostatné medaile garantující org, jsem zatoužil po vytvoření *nové* ceny - "Internetového průkopníka". Zobrazovala by sošku inženýra, přikovaného ke skále, marketroidy požírající jeho vnitřnosti, s tuctem šípů v zádech a rukama nataženýma před sebe - v nich by držel zcela novou technologii.

-Dave Täht

Jsem přesvědčen o tom, že Git má kouzelné skryté rozhraní k síti. Jeho schopnost samovolně se spustit a udělat Git gc, v okamžiku kdy stahujete update na aktualizaci důležitého dotazu, je přímo neskutečná.

-Alan Cox

Jsem přesvědčen o tom, většina vývojářů používá "nesprávnou" angličtinu, druhá nejpoužívanější je americká angličtina, po ní indická a britská angličtina.

-Arnd Bergmann

"Code of conflict" Kernelu

Vydání 4.0-rc3 obsahuje rozšířenou dokumentaci, do které byl včleněn "code of conflict", jakýsi kodex či manifest, který definuje parametry přijatelného diskurzu, bez zavádění mnoha pravidel. Orgánem, který rozhoduje v případě nepřijatelného chování, je Linux Foundation Technical Advisory Board. Dokument byl výslovně potvrzen velkým počtem významných vývojářů kernelu.

Sasha Levin si bere na starost údržbu verze 3.18

Podle rozvrhu by se podpora stabilní verze 3.18 měla pomalu chýlit ke konci. V tomto případě se Sasha Levin rozhodl, že si údržbu této verze kernelu vezme na starost, takže updaty budou pokračovat zhruba až do konce roku 2016.

Pokrok v perzistentní paměti

Letošní rok byl "rokem perzistentní paměti" již po několikáté za sebou, řekl s úsměvem při zahajovací řeči Matthew Wilcox 9. března 2015 při zahájení Bostonského summitu Storage, Filesystem, and Memory Management. Perzistentní paměť odkazuje k zařízením, ke kterým lze přistupovat podobně jako k RAM, která však umí ukládat zapsaná data do trvalé paměti. Dobrou zprávou je, že některé paměti DIMM s baterií jsou již dostupné, nevýhodou je malá kapacita jejich paměti (např. 8 GB). Na obzoru jsou mnohem větší zařízení, padla zmínka o kapacitě 400 GB, jejich dostupnost ovšem zatím není známa. Z toho co Matthew Wilcox řekl vyplývá, že budou dvě kategorie zařízení s různými možnostmi využití, takže by s nimi měl odlišným způsobem pracovat také kernel.

Je fajn, že ve vývoji jsou "vzrušující nové paměťové produkty", ovšem na jejich uvedení na trh si možná ještě budeme muset počkat. Wilcox si není jistý, zda budou dostupné letos. Zpoždění ve vývoji můžou mít na svědomí problémy s "novými druhy fyziky", které musí společnosti řešit.

Do začátku rozhovoru skočil Christoph Hellwig, který se zeptal zda Intel, Wilcoxův zaměstnavatel, plánuje v blízké budoucnosti vydat ovladače pro zařízení s perzistentní pamětí. Wilcox byl očividně se situací nespokojen, ale řekl, že ovladače nemohou být vydány, dokud nebude dostupná ACPI specifikace, která určuje, jak se zařízení v systému hlásí. Toto je součástí procesu ACPI 6, který bude dostupný, "až se k tomu ACPI dostane" Jakmile se to stane, vydá Intel své ovladače.

James Bottomley poznamenal, že v rámci UEFI (která dohlíží na ACPI) funguje proces k vydání části specifikací, pokud dojde k obecné shodě všech účastníků. Bottomley vyzval Intel, aby využila tohoto procesu.

Další z účastníků se zeptal, zda by bylo možné již nyní napsat ovladač, který by pracoval se všemi prototypy testovaných zařízení a zároveň nepoškodil jiné z prototypů, které zatím testovány nebyly. Wilcox odpověděl, že to není možné. "Je to frustrující," řekl.

Perzistentní paměť a struct page

Wilcox se dále věnoval tématu, o kterém myslel, že by publikum, věnující se správě paměti, mohlo více zajímat. Se stránkou o velikosti 4 KB a struct page pro každou stránku, by zařízení s kapacitou 400 GB, které zmínil, potřebovalo 6 GB jen pro sledování těchto stránek v kernelu. Pro zařízení by to byla spousta "promrhaného" místa. Ale pokud kernel sleduje paměť se strukturou stránek, může se s ní pracovat jako s normální pamětí. Jinak bude zapotřebí speciální vrstvy, například blokového zařízení API, k přístupu k danému zařízení.

Wilcox pracoval s předpokladem, že tyto typy zařízení nebudou využívat struct page. Na druhou stranu Boaz harrosh (který na summitu nebyl), zveřejňoval patche pro jiná, menší zařízení a tyto patche struct page používají. Což jak řekl Wilcox, dává smysl pro použitá v tomto případě, ale ne pro typ zařízení, na který se zaměřil.

Větší zařízení mají podobné vlastnosti opotřebení jako NAND flash, ale nikoli "5000 cyklů a je po něm". Tato zařízení mají životnost 10⁷ nebo 10⁸ cyklů. Co se přístupových časů týče, jsou některá rychlejší než DRAM.

Ted Ts´o navrhoval, že se zařízeními s různou kapacitou by se mělo také různě pracovat. S tím souhlasil Dave Chinner a dodal, že zařízení s baterií jsou vlastně RAM, zatímco větší zařízení spíše úložiště (paměť), takže by mohla být řešena jako bloková zařízení.

Wilcox řekl, že nahradí pro tato zařízení několika předběžnými patchi volání z get_user_pages() novým voláním get_user_sg(), který získá seznam scatter/gather místo stránek. Takto nejsou nutné struktury stránek, pro zpracování zařízení tohoto druhu. Uživatelé mohou zařízení používat jako blokové zažízení. Mohou do něj vložit souborový systém a pro přístup k datům použít mmap()

To vedlo k diskuzi o tom, jak zvládal truncate()na souboru, který byl namapován pomocí mmap(). Wilcox si myslí, že Unix, tedy Linux, se v tomto scénáři chová špatně. Jestliže program přistupuje k paměti, která již není součástí namapovaného souboru vzhledem ke zkrácení, obdrží SIGSEGV. Místo toho by mělo volání truncate() počkat do odmapování paměti.

Zpracovat truncate() tak, aby počkalo, je triviální záležitost, řekl Peter Zijlstra, ale mění to současné chování. Navrhl přidat k mmap() vlajku, která by vyžadovala tuto operaci. To by mělo snížit faktor překvapení, jelikož chování bude závislé na tom, co je mapováno. Ts´o řekl, že si nemyslí, že by kernel mohl bezpodmínečně zablokovat truncate operace na hodiny nebo dny, aniž by došlo k poškození některých aplikací.

Zpátky o otázce ovladačů se Ts´o zeptal, která rozhodnutí je třeba udělat a do kdy. Zařízení s podporou baterií jsou již dostupná, takže by měly vycházet i patche na jejich podporu, řekl jeden z účastníků. Hellwig řekl, že by dávalo smysl mít v kernelu jak ovladač Haroshův, tak od Intelu. Uživatelé by si potom mohli vybrat ten, který by měl smysl pro jejich zařízení. Celkově došlo ke shodě, ale na ovladači pro zařízení s baterií, se ještě stále musí pracovat, než bude připraven na začlenění. Bottomley to tedy shrnul s tím, že se skupina shodla na tom, že je zapotřebí obou ovladačů, jeden potřebuje doladit a druhý ještě neexistuje.

       

Komentáře

[Michal Kubeček]

"Jít off"??? :-)

[kozec]

Go off, samovoľne spustiť. Myslím, že vhodným prekladom by tu bolo "zmyslieť si".

A ešte ten flag preložený ako vlajka znel divne, som si na 99% istý, ze sa to v našich končinách nepoužíva.

Ale to sú maličkosti :)

[Kvakor]

Pamatuju, že v nějaké starší knížce o programování v assembleru (mám pocit, že pro i8080) autor zásadně nazýval příznaky jako vlajky a registr příznaků (flags) jako registr vlajek. Mimo toho, místo akumulátoru (myšleno registr) používal termín střadač.

Náš administrátor shledal tento komentář závadným.

Vulgarity.

Zobrazit komentář

[mankind_boost]

-50

[Bystroushaak]

Kdyby někdo tápal jako já, co je to vynález nějaké samostatné medaile garantující org:

I bez vynálezu nějaké samostatné medaile garantující org, jsem zatoužil po vytvoření *nové* ceny - "Internetového průkopníka".

Originál:

Even without finding some separate medal granting org, I have longed to create a *new* award - an "Internet Pioneers Award".

[Václav "Darm" Novák]

To muselo stát hodně míčů něco takového vyplodit.

[mankind_boost]

Někdo by tyhle perly měl sbírat.

[JZD]

Kralyk tyhle perly sbírá. Stačí mu jen napsat.

[кулак из ГУЛАГ]

Seno pro ovce. Nový bača by měl pochopit, že bez dobrého žrádla nebude mít brzo co holit. Ovce zatím zůstavají, dobrého k snědku tu sic nic není, ale k tlemení věcí dostatek.

TL;DR: Tyto pastviny jsou kafilérii stále blíž a blíž.

[GeoRW]

nemrozumiem kmeni tvojho reča

[Karry]

Já děkuji za překlad.

Ano, je tam pár překlepů, pár výrazů bych přeložil jinak, jiné nepřekládal vůbec. Nevím ale co všichni blbnete? Číst se to dá bez problému a narozdíl od čtení originálu nemusím tolik přemýšlet.

[kyknos]

tak ja treba musim premyslet vic, nez pri cteni originalu, ale aspon si procvicim mozek :)

[Václav "Darm" Novák]

Až na to, že některé překlady kompletně mění význam (žádosti o aplikaci hned vedle). Já u toho teda musím přemýšlet víc než u originálu LKML, pokud tedy nechci zjistit z článku nesmysly.

Překládání není jednoduchá věc a je snadné být slepý vůči vlastním chybám. Proto je blbost vydávat články bez korektury.

[cronin]

Nerieš to, ono je to už vlastne len taký miestny folklór.

[Petr Ježek]

LWN trpí neaktuálními zprávami a tím i tyto Jaderné noviny. Zatímco se na vývoji kernelu toho dost děje, aktuální informace tyto portály nepřejímají a nevyhledávají. Ono je třeba se připravit na konec přežvýkávání (překladů) a začít s přímým reportováním přímo od pramene vývoje. Bohužel osobně nemám čas to lovit přímo u zdroje a následně překládat, mám vytížení jinou prací. Snad tedy autor?

[Lol Phirae]

Snad tedy autor?

Ježíšmarjá, jen to ne...