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

[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.