Portál AbcLinuxu, 26. dubna 2024 13:28
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.
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.
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í.
Prosím, neupravujte patche ručně. Je to dovednost, kterou by neměl mít nikdo.
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í.
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.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.