Jaderné noviny - 5. 3. 2015: Správa paměti - selhání není možností

28. 6. 2015 | Redakce | Jaderné noviny | 2120×

Stav vydání jádra. Citáty týdne. Správa paměti - selhání není možností.

Stav vydání jádra

Aktuální vývojové jádro je 4.0-rc2, vydané 3. března. Linus o tom řekl:

Verze rc2 nevyšla v neděli odpoledne, jak bylo naplánováno, protože jsem strávil většinu víkendu laděním problému na starém Macu Mini, který tu mám, a já nemám rád předčasná problémová -rc vydání na strojích, ke kterým mám přímý přístup. I kdyby to postihovalo jen staré stroje, u kterých je nepravděpodobné, že by je vývojáři používali nebo alespoň měli.

Dnes jsem dostal opravný patch Daniela Vettera, takže místo nedělního vydání je úterní. Stáhněte si ho. Sice se zpožděním, ale funguje lépe.

Stabilní aktualizace: 3.18.8, 3.14.34 a 3.10.70 byly vydány 26. února. Updaty 3.19.1, 3.18.9, 3.14.35 a 3.10.71 jsou ve schvalovacím procesu. Vydány by mohly být po 6. březnu.

Citáty týdne

Stiskněte Y pokud chcete, aby váš systém padal a zamrzal více často.
Stiskněte N pokud chcete zdravý systém.

-Paul McKenney nabízí novou RCU funkci

Právníci zřejmě nevěří v #include legalese.h

-Alan Cox

Toto kejklířské kódování nás dovede na cestu černé magie. Já už mám černou kočku, takže jsem připraven.

-Steven Rostedt

Jo, vygooglil jsem si "nejrychlejšího šneka na světě", jen abych se ujistil, že můžu vyzvat kteréhokoli šneka a vyhrát.

-Linus Torvalds

Tým kernelu je plný skvělých, přátelských lidí. Je jich tu mnohem víc, než těch vousatých gronardů, kteří se chtějí pobít.

- SD Times

Správa paměti - selhání není možností

V lednu dospěla diskuze kolem systémových stalls v situacích s nedostatkem paměti k odhalení, že dynamická alokace paměti v kernelu nikdy neselhává. Od té doby pokračují diskuze o tom, jak nejlépe pracovat v situacích s nedostatkem paměti a zaměřují se hlavně na situace, kdy si kernel nemůže dovolit selhat alokaci paměti. Tato diskuze ukázala několik významných rozdílů v názorech, jak by alokace paměti měla v kernelu fungovat.

Některé úvodní koncepty

Subsystém správy paměti kernelu má za úkol zajistit dostatek paměti v situaci, kdy ji vyžaduje kernel nebo uživatelské procesy. Jednoduchý úkol je-li k dispozici dostatek paměti, ale těžší, jakmile se paměť zaplní - to nevyhnutelně stává. Pokud taková situace nastane a je požadavek na více paměti, má kernel několik možností: (1) uvolnit paměť používanou jinde nebo (2) odmítnout požadavek na alokaci.

Proces uvolnění (nebo "získání") paměti může zahrnovat zapsání aktuálního obsahu paměti do trvalého úložiště. To zahrnuje volání do souborového systému nebo kódu blocku I/O. Jenomže pokud jsou tyto subsystémy zdrojem žádosti o aplikaci, může zpětné volání způsobit uváznutí (deadlock) nebo jiné nemilé situace. Z tohoto důvodu (mezi jinými) s sebou žádosti o alokaci paměti nesou sadu vlajek, popisující akce, které lze provádět při provádění žádosti. Dvě z vlajek, o kterých je řeč v tomto článku, jsou GFP_NOFS (zpětná volání do souborového systému nejsou povolena) a GFP_NOIO (žádný typ I/O nemůže začít). První jmenovaná inhibuje pokusy o zapsaní "špinavých stránek zpátky do souborů na disku, druhá může zablokovat činnosti, jako stránkování na disk (writing pages to swap).

Je jasné, že čím omezenější je subsystém správy paměti, tím vyšší je pravděpodobnost, že nebude schopen vyhovět požadavku na přidělení paměti. Vývojářům kernelu bylo již dávno řečeno, že (téměř) jakýkoli požadavek může selhat, takže ve výsledku je kernel plný cest pro řešení chyb, které mají tuto možnost řešit. Nedávno ovšem vyšlo najevo, že kód pro řízení paměti ve skutečnosti nedovolí menším požadavkům selhat, místo toho se zacyklí ve snaze uvolnit paměť. Toto chování občas vede k zamrznutí systému, a to i přes to, že daný kód je připraven zpracovat chyby alokace paměti. Toto chování "příliš malé na selhání" (too hard to fail) je kontroverzní, ale bylo by těžké nyní něco měnit.

V kernelu jsem ovšem místa, která nejsou na selhání alokace připravena, většinou proto, že se alokace odehrává hluboko uvnitř složité řady operací, které by bylo těžké rozvinout. Vlajka _GFP_NOFAIL existuje výhradně pro to, aby stanovila, že selhání není volbou, přesto se její používání silně nedoporučuje.

Následující diskuze se tedy soustředí na dvě spřízněné otázky: (1) měl by kernel brát všechny malé alokace, jako by všechny měly _GFP_NOFAIL_ a (2) měly by vůbec být selhání-odolné alokace podporovány, a pokud ano, jak učinit tuto podporu robustnější?

Již ne "příliš malé na selhání"

Diskuze se znovu rozběhla, když Tetsuo Handa poznamenal, že se chování alokace paměti změnilo v kernelu 3.19; zejména malé alokace s vlajkami GFP_NOIO nebo GFP_NOFS by selhaly pod silným tlakem paměti. V předchozích kernelech by se tyto alokace, v případě nedostatku paměti, zacyklily donekonečna. Mezi jinými by touto změnou mohly selhávat operace souborového systému na systémech se zatíženou pamětí, kde by se to v minulosti nestalo.

Změna chování je výsledkem patche Johannese Weinera, který měl za úkol zabránit zablokování alokace paměti, která rozpoutala prosincovou debatu. Záměrem bylo vyhnout se zacyklení při pokusu o alokaci, pokud se nedošlo při uvolňování paměti k pokroku, ale náhodou se povedlo zabránit úplnému zacyklení i v případě GFP_NOIO a GFP_NOFS. Takže alokace nyní mohou selhat, to je v porovnání s předchozími verzemi kernelu velká změna.

Johannes měl původně v plánu toto nové chování ponechat a řekl, že "to dává smysl". Vývojáři souborového systému ostře nesouhlasili. Vypadá to, že v kódu souborového systému je příliš mnoho míst, která jsou na spolehlivém přidělení závislá, a spoustu z nich není označeno vlajkou _GFP_NOFAIL. Ted Ts´o pohrozil přidáním spousty _GFP_NOFAIL vlajek k voláním o alokaci v souborovém systému ext4, pokud nebudou změny vráceny do původního stavu. Takže vývojářům řízení paměti nezbylo, než si vybrat nejméně neoblíbenou možnost.

Nakonec vyhráli vývojáři souborového systému, Johannes změny začlenil do verze 4.0-rc2, obnovením chování při zacyklení pro dané typy alokací. Tato změna se pravděpodobně dostane také do stabilní verze 3.19. Původní patch je dobrým argumentem pro přístup odmítání "očišťujících" patchů v pozdní fázi vývojového cyklu. Došlo k jeho včlenění do prepatche 3.19-rc7, což znamená, že téměř nebyl čas všimnout si problémů před vydáním konečné verze 3.19.

Debata se netočila jen kolem nečekaného efektu jednoho pozdního patche pro správu paměti. Větší problém se zamrzáním systému v situacích s nedostatkem paměti a snahou zajistit, že důležité úkoly budou v takových situacích pokračovat, zůstal i nadále nevyřešen.

       

Komentáře

[Jendа]

V blozích se někdo nabízel že by pomáhal s překladem a korekturou. Nechcete to zkusit? A kdyby to fungovalo jako před několika lety, kdy redaktoři dostali článek den před vydáním, občas bych tam taky něco opravil.

Právníci zřejmě nevěří v #include legalese.h

jak nejlépe zacházet pracovat v situacích s nedostatkem paměti

kódu blocku I/O

Toto chování "příliš malé na selhání" (too hard to fail)

V kernelu jsem ovšem místa

[Václav "Darm" Novák]

„Stiskněte Y pokud chcete, aby váš systém padal a zamrzal více často.“ je taky krásný překlad typu „slovo od slova“

[Filip Jirsák]

A dále:

• to nevyhnutelně stává
• pokud jsou tyto subsystémy zdrojem žádosti o aplikaci → má být alokaci
• nesou sadu vlajek – v originále určitě flag, takže příznaků

Pak jsem český překlad Jaderných novin definitivně vzdal.

[Petr Tomášek]

selhání není možností

Když překládat neumíte, měl byste si najít jiný koníček...

[kyknos]

to je rada stejne blba jako ten preklad - treba se to nauci :)

ovsem asi by to nemel zverejnovat bez korektury

[Petr Tomášek]

treba se to nauci :)

Obávám se, že pro tuto Vaši domněnku nic nesvědčí.

[Jindřich Makovička]

Hlavně by se překladatel měl snažit ten překládaný text pochopit. A znalost jazyka, do kterého se překládá, taky neuškodí :)

[kyknos]

zadny uceny z nebe nespadl :)

[KeNaCo]

Možno by sa mali korektúry a opravy v komentároch jaderných novin dávať vo forme patchov ;)

[Lol Phirae]

Ostudné. Autor neumí nejen anglicky, ale ani česky.

[STN]

"Vlajky"? Mel jsem za to, ze "flags" se tradicne preklada jako "priznaky"...

[Lol Phirae]

Nerejmcej, viz vynález nějaké samostatné medaile garantující org

Kde nic není, tam ani smrt nebere...