Jaderné noviny – 4. 11. 2009

3. 12. 2009 | Jirka Bourek | Jaderné noviny | 2881×

Aktuální verze jádra: 2.6.32-rc6. Citáty týdne: Nick Piggin, Linus Torvalds, Ryan Gordon, Theo de Raadt. Další zneužití nulového ukazatele. Zastarání IDE? Japan Linux Symposium: Zvyšování škálovatelnosti VFS. Změna licence sledovacích bodů a značek. Vstříc chytřejšímu OOM zabijákovi.

Obsah

• Aktuální verze jádra: 2.6.32-rc6
• Citáty týdne: Nick Piggin, Linus Torvalds, Ryan Gordon, Theo de Raadt
• Další zneužití nulového ukazatele
• Zastarání IDE?
• Japan Linux Symposium: Zvyšování škálovatelnosti VFS
• Změna licence sledovacích bodů a značek
• Vstříc chytřejšímu OOM zabijákovi

Aktuální verze jádra: 2.6.32-rc6

Současné vývojové jádro je 2.6.32-rc6 vydané 3. listopadu. Linus říká:

Od 2.6.31 bylo mnoho dalších ošklivých regresí, které byly také opraveny (většinou v ovladačích, u několika z nich v souvislosti s uspáním/probouzením, u jiných bylo tímto způsobem nejsnazší vyvolat chybu), takže doufám, že díky zpoždění je -rc lepší. A samozřejmě doufám, že jsme nezavlekli nové velké regrese.

Zkrácený changelog je v oznámení, všechny detaily vizte v kompletním changelogu.

Během minulého týdne nevyšly žádné aktualizace stabilních jader.

Citáty týdne: Nick Piggin, Linus Torvalds, Ryan Gordon, Theo de Raadt

Naší největší konkurencí jsou bohužel naše starší jádra a my jsme (byli jsme?) opravdu dobří v psaní opravdu rychlých jader. A většina našich uživatelů, která používá konkurenci, je spokojená se všemi jejími vlastnostmi, takže „upgrade“, který způsobí zpomalení, moc neprojde. Vlastnost, kterou by mohlo použít 0,01 % lidí, ale která všem ostatním způsobí zpomalení o 0,1 %… to není nejlepší nápad. Výkonnost je také vlastnost a pokaždé, když něco takového uděláme, jí kousek měníme za něco, co většina lidí nepotřebuje.

-- Nick Piggin

Faktem je, že správcovství neznamená vlastnictví. To znamená, že bys měl být za kód zodpovědný, za což ti budiž poděkováno, ale pokud dojde k problémům, "NEVLASTNÍŠ" ho. Ani omylem.

Pokud tomu nerozumíš, neměl bys být správcem.

-- Linus Torvalds

Zdá se, že správcům linuxového jádra se nelíbí patche FatELF. Někteří nápad pochopili a nesouhlasí, někteří podle všeho neslyšeli, co říkám a někteří se objevili prostě proto, aby byli nezdvořilí.

Opravdu jsem neočekával, že spadnu do takového kafemlýnku. Představoval jsem si, že lidé budou diskutovat výhody a slabiny tohoto nápadu a dopracujeme se k řešení, které Linux zlepší pro všechny. Zpočátku se to tak zdálo, ale nakonec jsem dostal přes hlavu správou balíčků, prokletím vývoje třetích stran, což má být všelékem na všechno.

-- Ryan Gordon

Pokud ode mě někdo chce výběrový citát o nedávných dírách v Linuxu, pak musím říci: Linus je příliš zaneprázdněn myšlením na masturbující opice, že nemá čas zabývat se bezpečností Linuxu.

-- Theo de Raadt

Další zneužití nulového ukazatele

V polovině října Earl Chew nahlásil pád způsobený nullovým ukazatelem v kódu jaderných rour. Počáteční reakce na toto hlášení byly poněkud pomalé, částečně protože provozoval jádro založené na 2.6.21. Earl tomu věnoval potřebný čas a prokousal se kódem; ukázalo se, že jde o starou slabinu, která je v současných jádrech stále přítomna.

V kódu rour je souběh [race condition]. Před jádrem 2.6.32-rc6 kód, který otevírá rouru (zde pouze pro zápis), vypadá takto:

static int
pipe_write_open(struct inode *inode, struct file *filp)
{
    mutex_lock(&inode->i_mutex);
    inode->i_pipe->writers++;
    mutex_unlock(&inode->i_mutex);

    return 0;
}

Problém je, že pokud konečné uzavření proklouzne ve špatný okamžik, může být inode-> nastavený na null. Je to tedy zase další zranitelnost způsobená nullovým ukazatelem; zbytek je jenom záležitost napsání exploitu. Zde je trochu problém to, že exploit má poměrně krátké okno, ve kterém může uspět, ale počítače jsou velmi dobré v tom dělat něco tak dlouho, než se to povede.

Oprava kód upravuje tak, že je mnohem opatrnější a testuje současný stav roury s tím, že odmítne další otevření, pokud již došlo ke konečnému uzavření. Distributoři dodávají aktualizace.

Tato konkrétní chyba přitahuje pozornost, protože je ve vnitřním kódu jádra a lze ji (relativně) přímočaře spustit. Rozhodně ale není unikátní. Rychlý pohled na patche začleněné od 2.6.31 ukazuje na ne méně než 34, které explicitně opravují chyby dereferencování nullového ukazatele, a těžko říci, kolik jich bylo opraveno bez přímé zmínky v nadpisu patche. Chyby s nullovým ukazatelem jsou běžné a pravděpodobně ještě nějaký čas budou.

Na této chybě je překvapivé, že jsou vůči ní některé distribuce stále zranitelné. Možnost zabránit zneužití nullových ukazatelů máme již nějakou dobu, ale některé distribuce – obecně ty pro „podnikové“ nasazení – tuto ochranu ve výchozím nastavení vypínají. Na místech, kde se takové distribuce používají, by se měli ujistit, že mají hodnotu vm.mmap_min_addr nastavenou na rozumné číslo; buď to, nebo nechť očekávají, že budou zranitelní vůči dalším zneužitím nullového ukazatele.

Zastarání IDE?

IDE ovladače jsou již nějakou dobu poměrně stojatá voda; většina distribucí přešla na novější sadu PATA ovladačů založených na libata. IDE nicméně v jádře zůstává bez jakékoliv zmínky o tom, že to již není preferovaný způsob. To může být problém, protože vývojáři mimo jiné stále zasílají nové ovladače založené na IDE, jenom aby se jim dostalo odpovědi, že tyto ovladače již nejsou přijímány.

Aby se tyto problémy odvrátily, zaslal Robert Hancock patch, který IDE označuje za zastaralé. David Miller přijal patch pro 2.6.33, ale tam se dostat nemusí. David má za to, že pár věcí je potřeba opravit:

• Byl by rád, kdyby libata vytvářelo jména zařízení ve stylu IDE (/dev/hdX), aby systémy, které ve fstab používají tato jména, nepřestaly fungovat. Dalo by se dohadovat, že taková změna má několik let zpoždění – většina systémů má již problémy s touto změnou za sebou. V tomto okamžiku je již běžné připojování podle popisku [label] nebo UUID, takže ztrátou starých jmen zařízení by mělo být postiženo jenom pár uživatelů. A jak upozornil Alan Cox, vždycky lze napsat pravidla pro udev, která v případě potřeby takové jméno vytvoří. Možná tedy nebude tlak na splnění tohoto požadavku.

• Je několik IDE zařízení, která ještě v libata nejsou podporována; ovladač „pmac“ (pro integrovaná IDE zařízení PowerMac) je nejcitovanějším příkladem. Dokud nebude pro tato zařízení v libata podpora, IDE vrstvu zjevně nebude možné označit za zastaralou ani ji odstranit.

Alan také naznačil, že IDE nakonec zemře bez cizí pomoci a že není potřeba žádný další tlak na uživatele, aby ho přestali používat. Varování nicméně možná začleněno bude i přesto pro ty, kteří tuto zprávu neobdrželi jinak. Pokud díky tomu alespoň jeden vývojář nebude ztrácet čas vytvářením nového IDE ovladače, pravděpodobně to má cenu.

Japan Linux Symposium: Zvyšování škálovatelnosti VFS

Bylo by lákavé nezabývat se prací na škálovatelnosti, protože je zajímavá hlavně pro společnosti, které provozují obrovské serverové systémy; většina „běžných“ uživatelů Linuxu nenaráží na problémy, které se snaží vývojáři zaměření na škálovatelnost opravit. Pravda je ale samozřejmě ta, že tito uživatelé na podobné problémy nenarazili zatím. Dřívější práce vývojářů zaměřených na škálovatelnost je důvod, proč současné desktopy a laptopy fungují tak dobře, jak fungují; ze současné práce těchto vývojářů budou napřesrok těžit uživatelé systémů na úrovni pro běžného zákazníka. Přednáška Nicka Piggina na Japan Linux Symposium o škálovatelnosti virtuálního souborového systému by tedy měla být zajímavá pro každého, kdo očekává, že bude Linux používat i v budoucnosti.

Jedno z klíčových omezení práce na škálovatelnosti je, že to nesmí zhoršit výkonnost na současných systémech. Nick proto dává pozor, aby jeho práce na VFS zlepšila škálovatelnost bez dopadu na výkonnost při běhu v jediném vlákně. Kromě toho je jeho cílem vylepšit škálovatelnost na jediném souborovém systému – nutit správce systémů dělit souborové systémy, aby získali lepší výkonnost, by bylo podvádění. Aby svého cíle dosáhl, identifikoval pět specifických úzkých hrdel, které je potřeba řešit.

Prvním z nich je files_lock; jak Nick říká, je nejjednodušší ho opravit. Tento globální zámek chrání seznam otevřených souborů pro daný superblok; je vyžadován cestami pro otvírání a zavírání. Jak roste počet vláken, omezuje tento zámek škálovatelnost zátěží orientovaných na souborové systémy. Zámek sám o sobě je jenom část problému; skutečný háček je v tom, že jediný list_head nebude na multiprocesorových systémech škálovatelný nikdy. V tomto případě se ukazuje, že jádro téměř nikdy nepotřebuje číst celý seznam otevřených souborů; to se děje jenom při odpojování. Změna jediného seznamu na seznam specifický pro CPU je tedy proveditelná; zamykání se úplně vyhýbá a správu seznamu lze škálovat. Jediná záludná část je, když se soubory odstraňují; to vyžaduje meziprocesorový přístup do seznamu.

Další na řadě je vfsmount_lock, který se používá, když se vyhledávají připojení ze struktur záznamů adresáře [directory entry, „dentry“]. Tento zámek je zabírán, když se při vyhledávání cesty překračují přípojné body; také se používá při připojování a odpojování. Vyhledávání cest je v jádře zjevně cesta kritická na výkonnost, takže zbavit se globálního zámku může být jenom dobře. Nick zvažoval pro vyhledávání cest čtení-kopírování-aktualizace [RCU], ale zjistil, že to je stále příliš pomalé. Částí problému je nutnost blokovat všechny čtenáře při odpojování, což RCU samo o sobě neumí.

Řešením je použít zámky pro jednotlivá CPU. Nick zavedl variantu zámků pro jednotlivá CPU, kterou nazval brlocks či „big reader locks“ [brzámky, velké čtenářské zámky]. Tyto zámky sdílejí jméno a cíl s brzámky z 2.4.x, které byly odstraněny ve vývojovém cyklu 2.5, jejich implementace je ale odlišná. Brzámek je v podstatě zámek specifický pro CPU při přístupu pro čtení, ale přístup pro zápis zablokuje všechny uživatele na všech CPU. Vzhledem k tomu, že je vyhledávání cesty operace, která pouze čte, budou brzámky rychlé tam, kde to jádro potřebuje; odpojování bude stále pomalé, ale to je relativně neobvyklá operace.

mnt_count je počet odkazů pro jednotlivé souborové systémy, je zvětšen při každém otevření a snížen při každém zavření. Stejně jako globální seznam popsaný výše omezuje tento globální čítač škálovatelnost otevírání a zavírání. Opět je zde zjevným řešení přechod na hodnoty specifické pro CPU s malým problémem, že operace put() musí kontrolovat, jestli je (globální) součet nula. Jak se stává, tento případ se objevuje, jen když souborový systém není připojen, takže tuto kontrolu většinou není potřeba provádět.

Nejtěžší je opravit dcache_lock. Ten potřebuje většina VFS operací s jedinou výjimkou vyhledávání jména, které již nějakou dobu používá RCU. Některé operace – hlavně prohledávání a znovuzískávání nejdéle nepoužitých záznamů v cache dentry – mohou tento zámek držet dlouho. Zámek přitom pokrývá celou sadu různých – a někdy neznámých – věcí. Exportování dcache_lock souborovým systémům nepomohlo; jednotlivé souborové systémy ho používají ke svým vlastním a někdy ne zjevným účelům. Vývojář, který se snaží dostat dcache_lock pod kontrolu, tedy musí začít tím, že zjistí, co všechno tento zámek chrání.

Nick udělal, co mohl, aby jednotlivé případy oddělil; patří mezi ně hash dentry cache, seznam nejdéle nepoužitých dentry, seznam aliasů inodů dentry, různé statistiky atd. Některé z těchto věcí jsou přesunuty pod ochranu spinlocku specifického pro dentry (d_lock); jiné věci, jako dentry hash a LRU [least recently used, nejdéle nepoužité], dostanou nové zámky. Stále je mnoho problémů počínaje záležitostmi okolo řazení zámků. Ty se Nick pokouší obejít použitím neblokujících operací „trylock“, ale takový kód bývá těžké nechat začlenit. Různé případy zamykání nejsou na sobě skutečně nezávislé; to mezi jinými věcmi vynucuje další požadavky na řazení zámků. A pohyb ve stromu adresářů vzhůru (obvykle aby se z dentry určila cesta) je bez globálního zámku mnohem těžší.

V souhrnu pročištění dcache_lock vypadá jako dlouhý a chaotický projekt. Jedná se ale o zámek, který se v některých situacích projevuje jako nejhorší úzké hrdlo, takže tuto práci bude nutné udělat.

Nakonec je tu záležitost inode_lock, který je potřeba pro většinu operací (vyhledávání, vytváření, rušení, zpětný zápis atd.). Stejně jako u dcache_lock Nick rozdělil zamykání na několik nezávislých tříd – inode sám o sobě, hash inodu, seznam LRU a tak dál. Některé z těchto tříd jsou přesouvány pod zámek specifický pro inode, pro některé případy byly přidány specifické zámky. Seznamy inodů pro jednotlivé superbloky se změnily na proměnnou pro CPU, stejně jako čítače používané pro generování statistik. Nick také změnil operace alokace čísel inodů tak, aby byla specifická pro procesor tak, že každému procesoru přidělil rozsah. To znamená, že čísla inodů již nejsou přidělována sekvenčně; není jasné, jestli to bude problém, nebo ne.

Co z této práce vzejde? Nick tvrdí, že „skvělá“ škálovatelnost otevírání/zavírání a „dobrá“ škálovatelnost vytváření/mazání. Ukázal výsledky mikrobenchmarku, který opakovaně dělal close(open(path)); se současnou hlavní řadou byl schopen provádět 450 operací za sekundu na každém ze 64 CPU. Po přidání patchů pro škálovatelnost se to zvýšilo na 300 000 operací za sekundu – významné zlepšení. Spuštění unlink(creat(path)) ukazuje lepší škálovatelnost dokonce i na dvou CPU – z nějakého důvodu to ale zhoršuje výkon jednovláknové zátěže na architektuře ia-64.

Práce na škálovatelnosti VFS zjevně stojí za to, aby se jí někdo zabýval; jednoho dne budeme rádi, že tyto problémy byly vyžehleny. Stále zbývají nějaké ošklivosti, které je potřeba uklidit, takže tato sada patchů (nebo alespoň její sukovitější části) ještě nějaký čas na cestě do hlavní řady stráví.

Změna licence sledovacích bodů a značek

Sdílení kódu tam, kde je to možné, je běžně považováno za dobrou věc, ale existují určitá omezení v tom, co lze sdílet. Jedním z omezujících faktorů je často kompatibilita licencí; konkrétně GPL kód často nelze kombinovat s kódem pod jinými licencemi a pak distribuovat. Jádro je licencováno pod GPL, ale vzhledem k tomu, že je neobvyklé, že by někdo chtěl jeho kód kombinovat s aplikacemi v uživatelském prostoru, nebyly dosud nekompatibility licencí velký problém.

V jádře ale existuje sledovací infrastruktura, kterou by bylo možné sdílet s aplikacemi pro sledování v uživatelském prostoru – pravděpodobně ku prospěchu obou – pokud by tyto části jádra byly k dispozici pod volnějšími licencemi. Mathieu Desnoyers, který většinu této infrastruktury vyvinul, se snaží přelicencovat nějaké poměrně malé části jádra duálním licencováním, aby tento kód bylo možné sdílet.

Mathieu by v podstatě rád, aby bylo možné použít jadernou sledovací infrastrukturu ve sledovači uživatelského prostoru [user-space tracer, UST] z Linuxových sledovacích nástrojů nové generace [Linux Trace Toolkit Next Generation, LTTng]. Svou potřebu popisuje takto:

Záměrem je umožnit vývoj kódu sledování jak na straně jádra jako součásti Ftrace, tak na straně LTTng v UST, aby ho bylo možné sdílet tam, kde to je vhodné. S tím bychom mohli uvažovat o řešeních sledujících uživatelský prostor běžících pouze v uživatelském prostoru bez nutnosti přepsat sledovací infrastrukturu jádra od základu.

Všechny soubory jsou v současnosti licencovány pod GPLv2, ale Mathieu by byl rád, kdyby C soubory byly k dispozici pod duální licencí GPLv2/LGPLv2.1 a hlavičkové soubory pod duální licencí GPLv2/BSD. Aby to mohl udělat – alespoň podle nejpřesnější interpretace autorských práv – musí získat svolení ke změně licence od všech přispěvatelů k tomuto kódu. Jeho zpráva na linux-kernel vyjmenovávala pár zbývajících přispěvatelů, od kterých nic neslyšel.

Soubory, o které se jedná, jsou kernel/marker.c a kernel/tracepoint.c společně s odpovídajícími hlavičkami v include/linux. V 2.6.32 byly jaderné značky odstraněny a všichni uživatelé konvertováni tak, aby používali události sledování [trace events], ale marker.[ch] UST stále používá. Nápad je takový, že by se soubory C změnily na knihovnu v uživatelském prostoru, kterou by bylo možné dynamicky linkovat s aplikacemi, které ji potřebují, zatímco hlavičkové soubory (dokonce s ještě volnější licencí) by bylo možné použít k přidávání statických sledovacích bodů do aplikací jak proprietárních, tak svobodných.

Z větší části se změna licence setkala se souhlasem vývojářů, kteří se ozvali, přičemž někteří říkali, že si nemyslí, že jsou jejich příspěvky dostatečné významné, aby byl jejich souhlas zapotřebí, ale že souhlasí i tak. Steven Rostedt se na změnu licence souborů C dotázal právního oddělení Red Hatu a získal povolení k tomu, aby všechny příspěvky Red Hatu byly duálně licencovány pod GPLv2/LGPLv2.1. Duální licencování hlavičkových souborů je podle Mathieua u Red Hatu stále v jednání.

Stále je pár vývojářů, kteří neodpověděli, ale jejich příspěvky jsou poměrně malé a v případě potřeby by bylo možné je poměrně snadno přepsat. Větším kamenem úrazu může být opozice Inga Molnára, který podle všeho považuje proces změny licence za právně pochybný: Legálnost této změny licence je pochybná, protože tento kód nikdy nebyl vyvíjen mimo jádro, ale jako součást jádra. Kromě toho má i technické námitky:

Také ale nesouhlasím na technické úrovni: Duplikace kódu je špatná. Proč by kód měl být takto duplikován v uživatelském prostoru? Byl bych rád, aby sledovací kód Linuxu byl v archivu jádra. Proč se to nedělá správně jako součást projektu jádra – aby se zajistilo, že to zůstane synchronní?

Z těchto dvou důvodů nemohu se změnou licence souhlasit, sorry.

Jestli je Ingův souhlas skutečně zapotřebí, je otevřená otázka, vzhledem k tomu, že jeho zaměstnavatel (Red Hat) již souhlasil se změnou licence jeho práce. Jestliže ale existují vážné obavy, které vedou na „nack“ patche měnícího licenci z jeho strany, věci se trochu zakalují. Je možné, že jde jenom o nedorozumění mezi Ingem a Mathieuem, protože Mathieuovy záměry nejsou zjevné. Jak upozornil Pierre-Marc Fournier, nezměnění licence povede k duplikaci kódu také:

GPL kód tedy bude nutné přepsat. A to povede na úplně stejné nevýhody, kterým se snažíš vyhnout tím, že jsi proti duálnímu licencování. Cílem duálního licencování je umožnit, aby kód zůstal mezi jádrem a uživatelským prostorem synchronní, ne naopak!

Matthieu v podstatě chce, aby aplikace v uživatelském prostoru mohly využívat sledovací body založené na stejném kódu, který se nyní používá v jádře. Tyto aplikace mohou být pod různými variantami svobodných nebo proprietárních licencí, ale sledovací body jsou jenom techniky statického osazení dané aplikace a ty je možné sdílet. Jak to říká Steven:

Myslím si ale, že tady jde o to, aby šlo použít stejný typ MAKER, která používáme v jádře, i v uživatelském prostoru. Aby program v uživatelském prostoru mohl přidat svůj vlastní "TRACE_EVENT" a hlavičky vytvořily sledovací bod stejně, jako to v současnosti děláme v jádře.

Ingo k tomuto tématu již mlčel, stejně tak utichlo vlákno, ale nápad jako takový zní rozumně. I když odhaluje jaderné rozhraní do uživatelskému prostoru, nepoutá jádro do budoucna k žádnému ABI/API. Pokud se jádro bude muset změnit, knihovny v uživatelském prostoru se změní s ním nebo vznikne fork. Vzhledem k tomu, že relevantní hráči pracují na obou stranách problému – v jaderném i uživatelském prostoru – nezdá se pravděpodobné, že by se tak stalo; rozhodně se ale nezdá, že k tomuto oddělení musí dojít hned.

Vstříc chytřejšímu OOM zabijákovi

Kód správy paměti v Linuxu dělá, co může, aby zajistil, že bude vždy k dispozici paměť, když ji nějaká součást systému potřebuje. Bez ohledu na tuto snahu je ale stále možné, aby se systém dostal do stavu, kdy nebude k dispozici žádná paměť. V takovém bodě se věci zastaví a jediným možným řešením (kromě rebootu systému) je zabíjet procesy, dokud se neuvolní dostatečné množství paměti. Nešťastná úloha je zabita zabijákem při nedostatku paměti [out-of-memory (OOM) killer). Každý, komu se stalo, že se OOM zabiják probudil, ví, že k zabití ne vždy vybere tu nejvhodnější úlohu, takže není překvapením, že snaha zajistit, aby byl OOM zabiják chytřejší, je opakovaně se objevující téma vývoje linuxové správy paměti.

Před pohledem na nejnovější pokus vylepšit OOM zabijáka stojí za to zmínit, že je možné nakonfigurovat linuxový systém tak, aby se zajistilo, že se OOM zabiják nikdy neprojeví. Situace nedostatku paměti jsou způsobeny tím, že je jádro ochotné přislíbit více paměti, než je k dispozici. Obecné pravidlo je, že procesy využívají pouze část adresového prostoru, který alokují, takže omezení alokací tak, aby součet nepřekročil celkovou velikost RAM a swapu v systému, vede k tomu, že se systémová paměť nevyužívá naplno. Toto omezení je však možné nastavit systémům, které se nikdy nesmí dostat do stavu nedostatku paměti; jednoduše stačí nastavit sysctl vm.overcommit_memory na 2. Jednotlivé procesy v tomto režimu pravděpodobně mnohem častěji uvidí selhání alokace paměti, ale systém jako celek nikdy nepřislíbí více zdrojů, než má.

Většina systémů ale přidělování paměti „na dluh“ umožňuje, protože alternativa je příliš omezující. Přislíbení většího množství zdrojů, než je k dispozici, funguje téměř vždy, ale stále je tu riziko, že přijde den, kdy vývojáři Firefoxu přidají o jeden únik paměti víc, než bude snesitelné. Až k této situaci dojde, bylo by hezké, aby OOM zabiják mířil na Firefox a ne třeba na X server nebo PostgreSQL. Během let se objevilo mnoho pokusů přidat do OOM zabijáka vychytávky; také existuje způsob, jak může správce systému namířit OOM zabijáka na nebo mimo specifické procesy. Manuální konfigurace je ale vhodná jenom pro určité relativně statické zátěže; pro zbytek je OOM zabiják často méně vybíravý, než by bylo vhodné.

Nejnovější pokus opravit OOM zabijáka je dílem, za kterým stojí Hiroyuki Kamezawa. Tento patch zavádí fundamentální změny výběru obětí OOM zabijáka. Výsledkem je, že OOM zabiják je v určitých ohledech chytřejší, ale také používá trochu odlišný způsob výběru svých obětí.

Jedním z faktorů, které OOM zabiják zvažuje, je samozřejmě množství paměti, kterou každý proces používá. Použité měřítko (mm->total_vm) je ale poněkud primitivní: Penalizuje procesy, které hodně využívají sdílenou paměť a říká jenom málo o tom, kolik fyzické paměti proces používá. Hiroyukiho patch se snaží ve většině situací odklonit od total_vm a místo toho se dívat na velikost rezidentní paměti (resident set size, RSS) a možná se dívat i na velikost využitého prostoru ve swapu.

Zjišťování využívání swapu je kontroverzní. Program, který využívá hodně swapu, zjevně vytváří tlak na paměť, ale jestliže je tento program z větší části odswapován, jeho zabití okamžitě mnoho RAM neuvolní. Do tohoto čerstvě uvolněného swapu by nakonec byly přesunuty jiné procesy, ale mohlo by dávat větší smysl odklidit tyto procesy hned ze začátku. I přesto Hiroyukiho patch zatím zjišťuje velikost swapu, pokud ho specifická omezení nenutí použít jiná kritéria.

Jedno omezení, které může výpočet změnit, je, když je nedostatek paměti specifický pro dolní paměť – oblast paměti, kterou lze přímo adresovat jádrem. Když je zapotřebí alokace z dolní paměti, nic jiného možné není, takže nemá cenu zabíjet procesy, které si nekřečkují stránky v dolní paměti. S patchem subsystém VM samostatně sleduje, kolik dolní paměti proces používá. Jestliže je situace nedostatku paměti způsobena pokusem alokovat dolní paměť, OOM zabiják měří „špatnost“ [badness] se zaměřením na procesy, které jí drží velké množství.

Současný OOM zabiják se pokouší mířit na procesy „fork bomby“ tak, že polovinu „špatnosti“ potomka přičítá jeho rodiči. Procesy s hodně potomky se tedy zlověstného pohledu OOM zabijáka dočkají dříve. Problém je zde v tom, že některé procesy mají hodně dětí legitimně – dobrým příkladem je správce sezení desktopového prostředí uživatele. Zabití gnome-session pravděpodobně uvolní významné množství paměti, ale vděk uživatele může být překvapivě omezený.

Patch významně mění detektor fork bomb. Nový kód počítá pouze ty potomky, které běží kratší dobu, než je specifikováno (v zaslaném patchi pět minut). Jestliže má jeden proces novorozené potomky, které tvoří přinejmenším jednu osminu procesů v systému, je tento proces považován za fork bombu; oprávněně je odměněn jednou z prvních pozic na krátkém seznamu OOM zabijáka.

A nakonec – současný OOM zabiják se snaží zabít nově vytvořené procesy, zatímco dlouhodobě běžícím procesům dovoluje běžet dále. Hiroyuki má pocit, že tento způsob dovoluje uniknout procesům, ve kterých pomalu uniká paměť. Webový prohlížeč možná běží dlouho a je to tudíž proces o vyšší hodnotě, ale po tuto dlouhou dobu odhazoval paměť na podlahu a je také příčinou problému. Nové změny v kódu tedy tento výpočet mění tak, že se zjišťuje, jak dlouho je to od doby, co proces zvětšil velikost virtuální paměti. Proces, který běží dlouho, ale jeho využívání paměti se během této doby nezvětšuje, bude vypadat lépe než ten, který roste.

K tomu, že je OOM zabijáka potřeba přepracovat, se objevuje jenom málo nesouhlasných názorů, ale ne každému se líbí tento přístup. Vypadá to jako velmi velká změna, která některé lidi znervózňuje. Také významně mění ohnisko pozornosti OOM zabijáka: Současné heuristiky byly navrženy tak, aby pro uživatele byly co nejméně překvapivé, zatímco nové jsou silněji zaměřeny na rychlé uvolnění paměti. Nicméně vzhledem k tomu, že existující heuristiky mohou za spoustu překvapení i tak, možná dává přístup více zaměřený na konečný cíl větší smysl.

(Žádný článek o OOM zabijákovi by přirozeně nebyl kompletní bez odkazu na tento komentář Andriese Brouwera).

       

Komentáře

[Michal2]

Hmm, jasne, Windouze overcommit nepovoli (budto je misto na swap a pak ho zvetsi nebo neni a pak alokace neprojde) takze tam ten problem nenastava.