Jaderné noviny – 15. 11. 2012: Účast procesů na řešení nedostatku paměti

3. 12. 2012 | Luboš Doležel | Jaderné noviny | 5329×

Aktuální verze jádra: 3.7-rc5. Citáty týdne: Jon Masters, Russell King, Andrew Morton. Příchod RedPatch. Masters: atomické operace na ARM. Řada 3.5.x bude mít rozšířenou podporu. vmpressure_fd().

Obsah

• Aktuální verze jádra: 3.7-rc5
• Citáty týdne: Jon Masters, Russell King, Andrew Morton
• Příchod RedPatch
• Masters: atomické operace na ARM
• Řada 3.5.x bude mít rozšířenou podporu
• vmpressure_fd()

Aktuální verze jádra: 3.7-rc5

Aktuální vývojová verze jádra je 3.7-rc5 vydaná 11. listopadu. Jsem rád za to, že jde o docela malé -rc. -rc4 už bylo docela poklidné a -rc5 má commitů ještě méně. A ještě důležitější je to, že až na jeden revert a aktualizaci ovladače pinctl jsou to docela malé commity, obvykle jen jednořádkové.

Citáty týdne: Jon Masters, Russell King, Andrew Morton

Já třeba po POSIXu a po standardizaci obecně teskním. Myslím si, že je velmi smutné, že se v dnešní době posouvá mnoho věcí kupředu bez důkladné standardizace. Něco podobného, čemu se říkalo „Unixové války“, jsme měli v 80./90. letech a míříme k čemusi podobnému v Linuxu.

-- Jon Masters

Něco vám uniká; jde o jednu z největších schopností open source. Jde o dopad existence spousty očí (a mozků). Každý problém už asi někdo vyřešil, jde jen o to ho najít.

-- Russell King

Bohužel není nic jako EKERNELSCREWEDUP [kód pro „jádro to podělalo“], tak obvykle používáme EINVAL [neplatná vstupní hodnota].

-- Andrew Morton

Příchod RedPatch

Začátkem roku 2011 jsme se podívali na změny v tom, jak Red Hat šíří své úpravy v jádrech. Namísto oddělených patchů šíří tarball celého stromu – což je krok, jenž vyvolal spoustu kritiky. Tým Ksplice z Oracle nyní oznámil dostupnost gitového stromu, který rozděluje změny zpátky do jednotlivých patchů. Tým Ksplice radostně oznamuje veřejnou dostupnost jednoho ze svých gitových repozotářů, RedPatch. RedPatch obsahuje zdrojový kód všech změn, které Red Hat dělá ve svém jádře, co oprava, to commit, najdete jej na oss.oracle.com/git. Díky RedPatch se můžete dostat k rozděleným patchům pomocí gitu, procházet je online přes gitweb a volně je šířit pod podmínkami GPL.

Masters: atomické operace na ARM

Jon Masters sestavil přehled toho, jak fungují atomické operace na ARM, určený pro ty, kteří se nebojí hutných podrobností. Pro zajištění atomického přístupu na dané umístění v paměti implementují procesory ARM model enginu vyhrazeného přístupu. Dané místo v paměti je nejprve načteno pomocí speciální instrukce 'load exclusive', která současně nastaví vyhrazený přístup k dané adrese v enginu vyhrazeného přístupu pro aktuální CPU. Když je pak upravená hodnota zapisována zpět do paměti, tento engine pak při použití odpovídající instrukce 'store exclusive' ověří, že má platnou rezervaci na tuto adresu a dále potvrdí, že žádné vnější zdroje do commitu paměti nezasahují. V registru se pak vrátí úspěch nebo chyba.

Řada 3.5.x bude mít rozšířenou podporu

Herton Ronaldo Krzesinski oznámil, že Canonical bude udržovat stabilní řadu 3.5.x, která byla součástí Ubuntu 12.10. Toto jádro bude podporováno stejně dlouho jako Ubuntu 12.10, což dle aktuálních plánů znamená až do konce března 2014.

vmpressure_fd()

Jednou z pěkných vlastností virtuální paměti je to, že se aplikace nemusejí zabývat tím, kolik paměti je na systému k dispozici. Člověk nemusí přemýšlet moc dlouho na to, aby si vybavil aplikace, jejichž vývojáři si tuto věc vzali skutečně k srdci. Často bylo ale navrhováno, že by systém jako celek mohl fungovat lépe, kdyby aplikace, jež projeví zájem, mohly být informovány, jakmile bude paměti málo. Takové aplikace by mohly reagovat snížením svých požadavků na paměť, čímž by mohly oddálit swapování nebo situace, kdy paměť dojde úplně. Posledním návrhem v tomto směru je nové systémové volání nazvané vmpressure_fd(); je nepravděpodobné, že by bylo začleněno v současné podobě, ale stejně stojí za zamyšlení.

Nápadem ukrytým za patchem Antona Vorontsova je vytvořit mechanismus, pomocí kterého bude jádro moci informovat uživatelský prostor, jakmile se mu nebude dostávat paměti. Aplikace by nejprve vyplnila strukturu vmpressure_config:

#include <linux/vmpressure.h>

struct vmpressure_config {
    __u32 size;
    __u32 threshold;
};

Pole size by mělo obsahovat velikost struktuy; jde o jakési verzování pro případ, že by se do struktury v budoucnosti přidávala další pole. Pole threshold udává minimální úroveň upozorňování, o kterou má aplikace zájem; dostupné úrovně jsou:

VMPRESSURE_LOW

Systému došla paměť a pro uspokojení nových alokací musí brát zpět [reclaim] stránky. To není až takový problém, proto ačkoliv tu panuje nenulový tlak, tak je stále omezený.

VMPRESSURE_MEDIUM

Střední úroveň – pravděpodobně dochází ke swapování.

VMPRESSURE_OOM

Stav paměti je na zoufalé úrovni a systém může být postižen OOM killerem.

Aplikace nemusí při nízkém stavu nedostatku dělat nic, při střední úrovni může uvolnit některé cache a při největším nedostatku by mohla uvolnit vše, co jen může. V tomto případě by taková aplikace asi nastavila threshold na VMPRESSURE_MEDIUM.

Žádost o notifikace je jednoduchá:

int vmpressure_fd(struct vmpressure_config *config);

Návratovou hodnotou je popisovač, jenž může být použit ke čtení událostí v tomto formátu:

struct vmpressure_event {
    __u32 pressure;
};

Současné rozhraní podporuje jen blokující režim, takže read() na vráceném popisovači nic nevrátí, než bude vygenerována nějaká notifikace. Aplikace mohou používat poll(), ale asynchronní notifikace přes signál SIGIO nejsou možné.

Interně nemá subsystém VM žádný jednoduchou představu o pojmu „nedostatek paměti“, tudíž tento patch musí něco takového doplnit. V tomto smětu je počítán „index neefektivity reclaimeru“ podle počtu stránek, které reclaimer zkoumá a toho, kolik z nich nemohlo být navráceno. Nutnost zkoumat velký počet stránek pro nalezení vhodných kandidátů znamená, že je obtížné nějaké najít – systém se jinými slovy dostává pod tlak. Index je poměrem neúspěšných pokusů o získání stránky ku počtu zkoumaných stránek vyjádřeným v procentech.

Toto procento je počítáno po blocích, standardně po každých 256 prozkoumaných stránkách. Tuto hodnotu lze měnit pomocí nové hodnoty sysctl vmevent_window. Současně lze ovlivnit to, při jakých hladinách jsou rozesílány notifikace: vmevent_level_medium (výchozí hodnota 60) a vmevent_level_oom (výchozí hodnota 99); úroveň „low“ je napevno na hodnotě nula, takže bude vyvolána kdykoliv začne systém aktivně hledat stránky.

Je tu i jeden dodatečný mechanismus pro detekci stavů, kdy došla paměť, protože může být těžké toto rozpoznat jen podle výše zmiňovaného indexu. Kód pro reclaim zahrnuje jistou „prioritu“, která řídí, jak agresivně se má snažit získávat stránky; hodnota začíná na 12 a klesá s tím, jak dřívější snahy nikam nevedou. Jakmile se priorita dostane na čtyři (výchozí hodnota, lze ji nastavit přes vmevent_level_oom_priority), tak se má za to, že se systém řítí do stavu, kdy dojde paměť, a je zaslána příslušná notifikace.

Někteří zpochybňují potřebu vytvářet další systémové volání. Už tu máme volání eventfd() určené k vytváření popisovačů pro notifikace od jádra. Používání eventfd() vyžaduje trochu zběsilejší používání, kdy aplikace nejprve získá popisovač od eventfd(), pak otevře soubor v sysfs a zapíše do něj číslo popisovače, aby došlo k propojení na určitý zdroj událostí. Jde ale o zavedenou techniku, kterou by bylo dobré zachovat. Další člověk zase navrhuje používat subsystém událostí perf, ale Anton věří, že perf přináší komplikace do něčeho, co mělo být relativně jednoduché.

Další stížnost souvisí s integrací (respektive neexistencí integrace) s „memcg“, řadičem využití paměti na bázi řídících skupin. Memcg už obsahuje notifikační mechanismus (popsaný v Documentation/cgroups/memory.txt), který dokáže informovat proces, jakmile řídící skupině dochází paměť; dávalo by smysl používat stejný mechanismus i pro tento účel. Anton odpověděl, že mechanismus memcg neposkytuje ty samé informace, nezahrnuje všechnu paměť a vyžaduje používání řídících skupin – což není úplně populární funkce jádra. I kdyby ale vmpressure_fd() bylo začleněno jako oddělený mechanismus, stejně by muselo být rozšířeno tak, aby fungovalo i na úrovni řídících skupin. Na kódu je vidět, že na tuto integraci bylo pamatováno, ale ještě nebyla implementována.

Vzhledem ke všem obavám je nepravděpodobné, že by se patch v aktuální podobě dostal do jádra. O něco podobného je ale zájem na systémech velkých i malých (Antonův patch byl zaslán z adresy na linaro.org). Tak jako tak snad bude jádro brzo mít mechanismus, pomocí kterého bude informovat procesy o tlaku na paměťový subsystém. Dalším krokem pak bude dotlačit aplikace k tomu, aby tyto notifikace odebíraly a zařizovaly se podle nich.

       

Komentáře

[pavlix]

Momentálně taky tlačím na změny, které jdou proti standardům. Je to dáno tím, že standardy se z nějakého důvodu nestíhají opravovat či přizpůsobovat realitě.

[D.A.Tiger]

Otázkou je jestli není lepší nejprve tlačit na změny standardů. Protože ti co se snaží potom vyhovět standardům se pak kolikrát nestačí divit - nejvíce (alespoň v mém případě) je to vidět u aplikací které se snaží spolupracovat s jinými částmi systému (myšleno obecně) nebo navazují na jejich práci a očekávají že i ony pracují (nebo generují výstup) podle těchto standardů....

[pavlix]

Otázkou je jestli není lepší nejprve tlačit na změny standardů.

To je dobrá otázka. Ale zatím se mi daří tlačit leda tak na záchodě. Nebudu generovat tunu errat či draftů, které nikdy nikdo nezačlení a zatím nemám za sebou ani jeden úspěšný.

http://tools.ietf.org/html/draft-gont-6man-slaac-dns-config-issues-00

Zatím moc žádná odezva a to je tam se mnou podepsaný člověk, který už se IETF nějak účastnil.

Pokud se ke mě někdo připojí a pomůže mi opravy standardů prosadit, tak budiž. Do té doby ale radši budu produkovat funkční nestandardní implementace.

[Petr Tomášek]

Jen jestli ty standardy nejsou mimo reality od sameho vzniku...

[pavlix]

Některé chyby vznikají zároveň s první iterací standardu, některé s dalšími iteracemi, je to dost podobné jako u software s tím rozdílem, že oprava software tolik nebolí.

[D.A.Tiger]

Nevím, ale mě osobně nepřijde řešení wmpressure_fd( ) takové, to pravé ořechové.

Jestli se nemýlím, tak jádro (nebo jeho subprocesy) by mělo být schopné odesílat signály do user space. Pokud ano, pak by mělo bych si to představoval tak, že by existovala standardní funkce, která zaregistruje pid procesu a signál, který jádro odešle v případě, že bude nutno informovat aplikaci o nedostatku paměti a maximálně ještě funkce která bude vracet jednu z výše uvedených hodnot, kterou inkriminovaná aplikace může využít k určení jak na daný signál zareaguje.

[Luboš Doležel (Doli)]

Taky by se mi to líbilo víc než další syscall navíc. Nějaký SIGMEM a bylo by.

[kralyk z abclinuxu]

No nevim no, unix signals jsou dost prasečina (hlavně způsob, jakým jejich obsluha přerušuje tok programu) a jsou vázány vždy na konkrétní proces, takže bys například nemohl funkcionalitu šetření paměti implementovat do sdílené knihovny / toolkitu bez nějaké explicitní spolupráce s hlavním programem.

Celkově ale, ať už by to bylo implementováno jakkoli, jsem skeptický k praktickým výsledkům. Programátoři si buďto na paměť dávají pozor, a pak jsou jejich programy obvykle paměťově snesitelné, anebo na to kašlou, optimalizacemi se nezabývají, a tudíž ani s tímhle API se nebudou zabývat, se obávám...

[Radek Miček]

Celkově ale, ať už by to bylo implementováno jakkoli, jsem skeptický k praktickým výsledkům. Programátoři si buďto na paměť dávají pozor, a pak jsou jejich programy obvykle paměťově snesitelné, anebo na to kašlou, optimalizacemi se nezabývají, a tudíž ani s tímhle API se nebudou zabývat, se obávám...

IMO pro autory virtuálních strojů / garbage collectorů to může být užitečné.

[Luboš Doležel (Doli)]

Přesně. Můj pohled se upírá k JVM.

[Sten]

JVM ale stejně neumí spouštět garbage collector ze signal handleru, takže klidně může používat nějaký file descriptor.

[Kvakor]

Možná by úplně stačilo přidat něco do /proc, možná rovnou i do /proc/meminfo, kde by jádro jasně říkalo, jak moc potřebuje volnou paměť. Přece jenom GC nebo nějaká ta údržba paměťových struktur se nemusí pouštět zas tak často, aby to mělo nějaký zásadní vliv na výkonost.

[Nikola Ciprich]

dokazu si predstavit ze treba i pro (O)RDBMS to muze byt uzitecne.. takovy postgres si urcite radsi snizi velikost cache nez aby dostal ranu od OOM killera

[D.A.Tiger]

No nevim no, unix signals jsou dost prasečina (hlavně způsob, jakým jejich obsluha přerušuje tok programu) a jsou vázány vždy na konkrétní proces, takže bys například nemohl funkcionalitu šetření paměti implementovat do sdílené knihovny / toolkitu bez nějaké explicitní spolupráce s hlavním programem.

To je možné, ale zas na druhou stranu vidím několik - dle mého názoru zásadních - rozdílů:

Např. nějak nedokážu pochopit, proč získání pouze orientační a obecné informace vůbec vázat na nějakou informaci o velikosti struktury. Další nevýhoda, kterou v tomto případě vidím, že kontrolu musím provádět průběžně za běhu programu, nebo před každou alokací paměti.

Na co? Pokud chci sledovat informativní stav nějakého zdroje stačí mi tři udaje : dostatek, dochází, kritický stav. K předání takových informací se prostě skvěle hodí signály, nebo jediné systémové volání. Signály mají ještě tu výhodu, že si napíši a zaregistruji odpovídající obslužné handlery a a tím pádem mi odpadá pravidelná kontrola a problém se řeší až opravdu nastane. A pokud mě to nezajímá, žádné handlery neřeším a aplikace bude tím pádem veškeré snahy jádra ji předběžně informovat zatvrzele ignorovat.

[kralyk z abclinuxu]

Např. nějak nedokážu pochopit, proč získání pouze orientační a obecné informace vůbec vázat na nějakou informaci o velikosti struktury.

Tak to je poměrně zvykem, že se podobná informace v těhle strukturách předává. Celkem bych ty 4 bajty neviděl jako problém. Krom toho, to je otázka tohohle konkrétního návrhu, klidně může to API být řešeno jinak. Jak píšou v článku, v téhle podobě to stejně nejspíš neprojde...

Na co? Pokud chci sledovat informativní stav nějakého zdroje stačí mi tři udaje : dostatek, dochází, kritický stav.

Kvůli každýmu stavu zavádět další signál je imho blbost. Signály jsou určeny na správu procesů jako takových, ne detailů ohledně správy paměti procesu a už vůbec ne na IPC.

Signály mají ještě tu výhodu, že si napíši a zaregistruji odpovídající obslužné handlery a a tím pádem mi odpadá pravidelná kontrola a problém se řeší až opravdu nastane.

Neodpadá, protože způsob, jakým se signal handlery vykonávají, je hrozně debilní. Ten handler se nevykoná v nějakým jiným vlákně, místo toho se prostě přeruší hlavní vlákno programu, jen tak hala bala, bez jakýchkoli ohledů na to, co se v něm dějě - takže to klidně přeruší thread-unsafe funkce, syscally, afaik i I/O, atd. Nemáš ale vyhráno ani ve chvíli, kdy už se spustí handler, protože se klidně může stát, že mezitím dorazí stejný signál znova nebo jiný a tvůj milej handler je přerušen, protože se vykoná jiný handler nebo bez varování znova ten samý. Takže v handleru toho nemůžeš moc dělat, rozhodně v něm nemůžeš uvolňovat někde nějakou paměť, protože to není reentrantní. Takže by sis stejně v signal handleru mohl tak akorát zamknout mutex, nastavit nějaký globalní příznak, odemknout mutex, co nejrychleji vypadnout a ten příznak pak vzít v úvahu během jiné činnosti programu, takže by tě to vyšlo úplně nastejno, jako s nějakým poll(). Nehledě na řadu možných race condition, pokud tvůj program používá víc vláken, což nejspíš používá.

Navíc u signálů není garantováno, že budou doručeny ve stejném pořadí jako byly vyslány. Takže by se technicky vzato mohlo stát, že by jádro vyslalo signál VMPRESSURE_LOW a vzápětí VMPRESSURE_MEDIUM, ovšem program by je obdržel v opačném pořadí, takže by se choval, jako kdyby systém měl paměti habaděj, což by ale ve skutečnosti nebyla pravda.

Celkově vzato, signály vypadají hezky na papíře, když ale člověk veme v úvahu tyhle detaily, tak zjistí, že signály jsou fakt dobrý tak akorát na SIGTERM, SIGKILL a podobně...

[Michal Kubeček]

Nemáš ale vyhráno ani ve chvíli, kdy už se spustí handler, protože se klidně může stát, že mezitím dorazí stejný signál znova nebo jiný a tvůj milej handler je přerušen, protože se vykoná jiný handler nebo bez varování znova ten samý.

Jen pro pořádek: defaultně je signál, který se právě zpracovává, blokován. Můžete to samozřejmě potlačit, např. pomocí SA_NODEFER, ale pak už si za své problémy můžete sám.

[trekker.dk]

takže to klidně přeruší thread-unsafe funkce, syscally, afaik i I/O

Kvůli tomu se taky syscally obalují makrem TEMP_FAILURE_RETRY, které v případě návratové hodnoty -1 a errno == EINTR daný syscall zavolá znova.

[kralyk z abclinuxu]

Anebo SA_RESTART, což mi přijde čistší..

[Jakub Lucký]

IO by snad signály rušit neměli, aspoň některé signály (SIGKILL) jsou v D stavu pozastavené...

[Michal Kubeček]

To, co je ve výstupu ps vidět jako stav D, může interně znamenat dvě různé věci (možná i víc, ve scheduleru se moc nevyznám) podle toho, jestli má task nastavený flag TASK_WAKEKILL - buď je opravdu nepřerušitelný nebo je sice nepřerušitelný, ale lze ho zabít signálem KILL.

Jinak ale syscally, kde se čeká na I/O (read(), recv(), poll(), …) - a vlastně obecně syscally, kde se na něco čeká - by měly být přerušitelné. Userspace procesy by neměly ve stavu D viset zbytečně dlouho, pokud ano, je to většinou příznak, že něco není v pořádku.

[Grunt]

Hele a co tak signál, kdy všechny běžící programy zastaví svůj chod, sejdou se v kulaté mítingové místnosti a začnou řešit který z nich tu paměť potřebuje víc. První kdo by se měl o docházející paměti dozvědět je IMHO uživatel. Velmi se mi líbilo jak to fungovalo na W98. Když došla paměť, vyskočilo varovné okno a zároveň bylo zakázáno spouštět jakékoliv další programy či alokovat paměť. Celkově mi chování GNU systémů při nedostatku paměti vadí. Nejlepší je to když se jede z CD. To se systém pokouší neustále o nějaký druhu defragmentace paměti či co, CD-ROM pořád žbleptá, se systémem nejde ani hnout dokud jádro nezpanikaří.

[luky]

před každou alokací paměti

Doporucuju si precist sekci BUGS v manualove strance malloc. K alokovani libovolne velke casti pameti potrebujete 0 az _pamet_nutna_pro_vytvoreni_tabulky_stranek_ B.

[trekker.dk]

No nevim no, unix signals jsou dost prasečina

Asi tak, než signály je lepší mít otevřený deskriptor a toho se ptát, když na to je správný čas. Ostatně tak se dá pracovat i se signály samotnými - signalfd()

[kralyk z abclinuxu]

Ostatně tak se dá pracovat i se signály samotnými - signalfd()

Aha, díky, to jsem neznal...

[luky]

No nevim no, unix signals jsou dost prasečina

Asi tak, než signály je lepší mít otevřený deskriptor a toho se ptát, když na to je správný čas. Ostatně tak se dá pracovat i se signály samotnými - signalfd()

Jak kdy, treba signal poslany pri nevalidni instrukci se pres signalfd bude osetrovat velmi spatne. Obcas se proste hodi mit dalsi zasobnik.

[Sten]

Signál při nevalidní instrukci se bude velmi špatně ošetřovat i ze signal handleru

[Ales Hakl]

Pokud si spravne vybavuji, tak AIX ma zrovna k tomuhle ucelu specialni signal.

Ono jde taky o to, ze je vhodne tu informaci do userspace dostat tak, aby se behem toho nemusela alokovat dalsi stranka, cemuz signal uplne nevyhovuje. Osobne mi prijde vhodne spise nejake jemnejsi madvise(MADV_DONTNEED), ktere stranku zahodi az v situaci kdy zacne pamet dochazet (rekneme podobnym zpusobem jako clean stranku z buffer cache), pripadne spojene s nejakou pripadnou notifikaci, ze stranka uz byla vynulovana.

[Kvakor]

Bohužel není nic jako EKERNELSCREWEDUP [kód pro „jádro to podělalo“], tak obvykle používáme EINVAL [neplatná vstupní hodnota].

V GNU Hurd už podobně barvitý chybový kód je - EIEIO aneb Computer bought the farm (to první je odkaz refrén ve známé písničce, zatímco to druhé je v angličtině známý eufemismus), nícméně tam znamená spíše to, co v Linuxu panika jádra.