Jaderné noviny – 3. 5. 2018: Přístup k úložným zařízením jako k paměti

13.5. | David Kolibáč | Jaderné noviny | 1671×

Stav vydání jádra. Citáty týdne: Sasha Levin a Linus Torvalds. Summit o úložištích, souborových systémech a správě paměti 2018. Přístup k úložným zařízením jako k paměti.

Stav vydání jádra

Kernel release status. Jonathan Corbet. 2. května 2018

Současné vývojové jádro je 4.17-rc3, vydané 29. dubna. Linus řekl: „A teď už myslím, že jsme opravili všechny z těch nejhorších dopadů začleňovacího okna. Konkrétně ten problém s velkými stránkami a PTI, který zasáhl lidi s určitými konfiguracemi, by už měl být v pořádku vyřešený.“

Stabilní aktualizace: 4.16.5 a 4.14.37 vyšly 26. dubna. Poté 30. dubna vyšly aktualizace 4.16.6, 4.14.38, 4.9.97, 4.4.130 a 3.18.107 a 2. května následovaly aktualizace 4.16.7, 4.14.39, 4.9.98, 4.4.131 a 3.18.108.

Citáty týdne

Quotes of the week. Jonathan Corbet. 2. května 2018

-rc vydání jsou mizérie. velká mizérie. Úroveň kvality commitů, které přišly v cyklech -rc, byla hluboko pod úrovní commitů v začleňovacím okně:

• U všech commitů bylo stejné riziko, že se sebou přinesou nějakou chybu, ať už přišly v začleňovacím okně, nebo v cyklu -rc. To znamená, že commity v -rc většinou nakonec nahradí zjevné chyby chybami méně zjevnými.
• Ačkoliv průměrný commit v začleňovacím okně změní – v průměru – třikrát tolik řádků co commit v -rc, riziko zanesení chyby v patchi zůstává stejné, takže hodnota metriky chyby na řádek kódu je mnohem vyšší u patchů v -rc.
• Commit během začleňovacího okna v průměru stráví v -next o 50 % dnů víc než commit v -rc.
• Commitů v -rc, které nikdy nespatřily světlo e-mailové konference nebo tam na ně nikdo nereagoval, bylo **mnohem** více než takových commitů v začleňovacím okně.
• Z nějakého důvodu je šance commitu v -rc, že se dostane do -stable, přes 20 %, ale u commitu v začleňovacím okně je to kolem 3 %. Nedokážu úplně říct, čím to je, ale naznačuje to, že commity z -rc nakonec -stable docela ubližují.

—Sasha Levin

Prosím, neupravujte patche ručně. Je to dovednost, kterou by neměl mít nikdo.

—Linus Torvalds

Summit o úložištích, souborových systémech a správě paměti 2018

The 2018 Linux Storage, Filesystem, and Memory-Management Summit. Jonathan Corbet. 24. května 2018

Na Summitu o úložištích, souborových systémech a správě paměti (Linux Storage, Filesystem, and Memory-Management Summit) se každoročně sejde ústřední skupina 80 až 90 jaderných vývojářů, kteří pak několik dní diskutují na velmi odborné úrovni. Letošní ročník byl uspořádán 23. až 25. dubna v Park City v Utahu. Linux Weekly News přinesly reportáže z většiny sezení.

Přístup k úložným zařízením jako k paměti

Exposing storage devices as memory. Jonathan Corbet. 27. května 2018

Úložná zařízení procházejí obdobím rozsáhlých změn. Jak se zrychlují a začínají podporovat adresování po bajtech (pro přístup CPU), úložiště čím dál tím více připomínají obyčejnou paměť. Ale obyčejnou pamětí nejsou, takže stále není jasné, jaký model přístupu k nim by se měl používat. Na Summitu o úložištích, souborových systémech a správě paměti 2018 vedl Adam Manzanares v rámci sekce věnované správě paměti sezení, na kterém se jeho návrh nového přístupového mechanismu setkal se skepsí.

Aktuálně se věci mají tak, řekl Manzanares, že úložiště jde zpřístupnit jako paměť dvěma způsoby: připojit ho jako odkládací (swap) zařízení, nebo aplikacím umožnit, aby zařízení přímo namapovaly do svého adresního prostoru. Ale jakkoliv jsou tato zařízení podobná paměti, stále nedisponují stejnými přístupovými časy jako dynamická RAM a stále nevydrží, pokroku navzdory, srovnatelný počet zápisů. Tudíž si Manzanares není jist, zda je práce s úložišti jako s obyčejnou pamětí ten správný přístup.

Měl jiný nápad: rozšířit myšlenku virtuální paměti, aby poskytovala přístup k úložným zařízením, která jsou paměti podobná. Každému zařízení by se alokovala nějaká běžná RAM, a ta by se používala jako mezipaměť pro data uložená na zařízení samotném. Toto zařízení by v jádře bylo reprezentováno jako prosté znakové zařízení (/dev/umap), což by aplikacím umožnilo namapovat si část prostoru na úložném zařízení do svého adresního prostoru. Význam /dev/umap v prvé řadě spočívá v zachytávání chyb stránek – na ně může reagovat přesunem dat mezi mezipamětí v RAM a úložným zařízením.

Přítomní vývojáři se domnívali, že takové uspořádání nápadně připomíná použití úložného zařízení jako odkládacího prostoru. Na to Manzanares odpověděl, že nechtěl použít stávající mechanismus odkládání, protože ten závisí na blokové vrstvě, která je podle něj spojená s vysokou režií, a tak by se jí rád vyhnul. Ani použití pouze stránkovací cache není zrovna atraktivní, pokračoval, je to totiž příliš paměťově náročné a neposkytuje aplikacím dostatečné možnosti. Věci se mají tak, řekl, že /dev/umap výkonově překonává alternativy v podobě jak mapování paměti, tak odkládacího prostoru.

Dan Williams navrhl, že namísto vytváření zcela nového mechanismu pro přístup k této paměti by bylo vhodnější začít se současnými API souborových systémů a stránkovací cache a pokud to bude nutné, osekat je. Dave Hansen řekl, že jádro má už teď problém zvládat stávající druhy paměti a přidáním dalšího se to téměř jistě nezlepší. Diskuze se pak ještě chvíli točila kolem těchto témat, ale jak se čas sezení krátil, bylo jasné, že /dev/umap se ve své současné podobě jen těžko může dostat do upstreamu.

       

Komentáře

[jdsulin2]

Obecna podpora pro NUMA uz v jadru je, neda se stejny princip aplikovat na vyssi uroven ?

[pc2005]

NUMA nespecifikuje věci jako že ti paměťová buňka za 1000 zápisů umře.

[Petr______]

a proc by jadro melo resit ze nejaka bunka za 2 zapisy umre? Neni to vec radice? Jak se dovi jadro, ze hardver x podporuje 1000 zapisu a hardver y jenom 10? Tohle by si mel resit hardver a ne jadro...

[pc2005]

Jádro se to dozví například tak, že mu driver nastaví vlastnost discard, takže userspace může použít fstrim. Použitím discardu se řadič dozví, že tahle směsice bajtů není používaná a může jí smazat a místo použít pro realokaci bloků, které mají horší životnost nebo potřebují refresh.

[pc2005]

Jinak abych to doplnil, tak IMO NUMA v kernelu dělá to, že zajišťuje, aby nebyl proces na jiném procesoru než má data (protože přístup k řadiči cizího procesoru trvá moc dlouho). Zajišťuje tedy hlavně plánování a migraci úloh. Při použití flash RAM máš ten přístup pomalej odkudkoliv. V článku jde hlavně o to, že neví, jak by s tou flash RAM měli pracovat po logické stránce (je to opravdu RAM? nebo spíš bloky filesystému, ...) , ne jak na ní plánovat úlohy.