Jaderné noviny - 1/2008

22. 1. 2008 | Jirka Bourek

Články - Jaderné noviny - 1/2008  

2.6.24-rc4, "trošku pozdě". 2.6.24-rc5, konečná verze do Vánoc nebude. Citát: Vyhýbání se OOM killerovi. Sbírání dat z jaderných oops. Oprášení jádra 0.01. Vydání stabilního jádra 2.4.36. Citát: Proti tomu se postavím. Ospalý Linux. Citát: Výhody TuxOnIce. 2.6.24-rc7, spousta malých změn. Citát: Menšina. Dekódování oops.

Obsah

• 2.6.24-rc4, "trošku pozdě"
• 2.6.24-rc5, konečná verze do Vánoc nebude
• Citát: Vyhýbání se OOM killerovi
• Sbírání dat z jaderných oops
• Oprášení jádra 0.01
• Vydání stabilního jádra 2.4.36
• Citát: Proti tomu se postavím
• Ospalý Linux
• Citát: Výhody TuxOnIce
• 2.6.24-rc7, spousta malých změn
• Citát: Menšina
• Dekódování oops

Následující obsah je © KernelTrap.

2.6.24-rc4, "trošku pozdě"

4. prosinec, originál

Mezi jednotlivými vydáními -rc bychom měli mít týdenní interval, ale během Díkůvzdání jsem byl týden pryč (stejně jako mnoho dalších vývojářů jádra), takže tohle je trochu opožděné. Zpoždění začíná být spíše pravidlem než výjimkou, ale slibuji, že se polepším... Linus Torvalds takto začal oznámení o vydání jádra 2.6.24-rc4. Není v něm moc vzrušujících změn, ale děje se v něm o hodně víc změn, než bych doufal ve stádiu, kdy máme -rc4. V diffstatech vynikají Blackfin, MIPS a Power, ale v ARM a x86 došlo také k nějakým aktualizacím.

Něco se dělo také u ACPI (přiškrcování [throttling] procesoru atd.), společně s tím proběhly různé aktualizace ovladačů: ATA, IDE, infiniband, SCSI, USB a síťové ovladače. U souborových systémů cifs, NFS, ocfs2 a proc. Uf. Je toho příliš.

Diff od -rc3 má skoro 36000 řádek a to je ten menší pro git, kde se přejmenování ukazují jako přejmenování (není to ten, který nahrávám jako patche na kernel.org, ten je dělán tak, aby ho mohli používat lidé s GNU patch a dalšími starodávnými programy, které používají diffy). Částečně za to může to dvoutýdenní okno, ale i tak je to trochu skličující. Opravdu doufám, že budeme zpomalovat a že -rc5 bude o hodně menší.

Zkrátka, žádná ze změn není opravdu vzrušující nebo opravdu děsivá. Také jsme opravili spoustu regresí, i když víc jich určitě zbývá.

2.6.24-rc5, konečná verze do Vánoc nebude

12. prosinec, originál

Je to týden, co jsem slíbil, že budu hodný chlapec a budu dodržovat pravidla o vydávání verzí, takže tady je další -rc, psal Linus Torvalds v oznámení jádra 2.6.24-rc5 Dodal k němu:

Věci se zpomalily, ale lhal bych, kdybych řekl, že máme všechny regrese ošetřené a pod kontrolou. Pracuje se na nich a seznam se zmenšuje, ale můj odhad je, že určitě nebudeme mít finální verzi 2.6.24 hotovou před Vánoci, pokud tedy Santa nezaměstná víc elfů, aby na těch regresích zapracovali. Takže všichni elfové tam venku - prosím, pokračujte v práci.

Linus dodal, že v tomto nejnovějším release candidate nebyly žádné velké změny, takže nemá cenu posílat diffstat. S ohledem na délku textu je na pohled výrazný revert PA-RISC a aktualizace defconfigu u powerpc. A SPI ovladač pro Blackfin. Zbytek je z velké části náhodný šum v různých subsystémech (ovladače/síť, souborový systém xfs a aktualizace architektur jsou některé z oblastí, kde se objevuje víc změn).

Citát: Vyhýbání se OOM killerovi

Kdykoliv začne OOM killer střílet, se systémem je něco špatně a je mnohem produktivnější to řešit, než si přát přesnějšího OOM killera.

Dan Kegel, zpráva ze 7. prosince na Linux Kernel mailing list.

Sbírání dat z jaderných oops

17. prosinec, originál

Arjan van de Ven oznámil novou webovou stránku: http://www.kerneloops.org sbírá z různých mailových konferencí a bugzill zprávy z jaderných oops a varování. Přiložil shrnutí deseti nejčastějších oops zpráv za posledních 7 dní a poznamenal: Toto je první takové shrnutí, které zasílám. Dejte mi, prosím, vědět, jestli je to užitečné, nebo ne.

Odezva byla kladná. Andrew Morton poznamenal: To mohla být sranda naprogramovat. Steven Richter vyjádřil obavy, že tento nástroj bude započítávat stejnou zprávu o chybě několikrát, pokud ji najde na několika místech. S tím Arjan souhlasil: To je pravda, nicméně je to... složitá věc. Je opravdu složité rozlišit duplicitní zprávu od dvou zpráv o stejné chybě. Objevila se také další obava, že budou odděleny oops vygenerované jádrem 2.6.X-rcY a 2.6.X.rcY-mmZ. Arjan poznamenal: Zjištění, ze které verze jádra ten oops pochází je... překvapivě složité. A upřímně, chyby proti -mm nás také dost zajímají, protože se přece jenom v budoucnu dostanou do hlavní řady.

Oprášení jádra 0.01

2. leden, originál

Abdel Benamrouche oznámil, že aktualizoval původní jádro verze 0.01 tak, aby šlo přeložit gcc řady 4.x a mohlo tedy běžet v emulátorech jako je QEMU a Bochs.

Po aplikování sady malých patchů, vysvětluje Abdel, může být jádro 0.01 přeloženo na systému, který běží na linuxovém jádře 2.6.

Dodal, že úspěšně portoval bash-3.2, část coreutils-6.9, dietlibc-0.31 (místo glibc), bin86-0.16.17, make-3.81, ncurses-2.0.7 a vim-7.1, aby mohly na tomto modifikovaném jádře fungovat.

Vydání stabilního jádra 2.4.36

3. leden, originál

Nový rok, nové jádro: Linux 2.4.36 je konečně hotové a bylo prověřováno dost dlouho na to, abychom ho mohli vydat. Od 2.4.35 byla opravena spousta chyb, chyb při překladu a bezpečnostních problémů, ale všechny tyto opravy byly začleněny do 2.4.35-stable, oznámil správce jádra 2.4 Willy Tarreau.

Měl bych říct, že jsem docela spokojen s modelem vydávání s dvěma větvemi, který velmi úspěšně odděluje rychlé opravy od změn, které potřebují podrobnější testování. Potom dodal:

Co se budoucích verzí týče, nezbývá už nic, co by bylo potřeba udělat. Budu pokračovat s 2.4.36.X, až přijdou opravy chyb. 2.4.37 založím jenom v případě, že dostanu něco, co nebudu považovat za vhodné pro zařazení do 2.4.36.X.

Předchozí stabilní jádro 2.4.35 bylo vydáno v červenci 2007. Změny na úrovni zdrojových kódů lze prohlédnout přes gitweb rozhraní linux-2.4.

Citát: Proti tomu se postavím

Proti čemu se budu hodně stavět, je přístup "nevíme, co je špatně, ale necháme to špatně, protože nás přece nikdo nemůže otravovat s tím, abychom to řešili."

Linus Torvalds, zpráva ze 2. ledna na Linux Kernel mailing list.

Ospalý Linux

4. leden, originál

Současné verze Linuxu umí přejít do režimu uspání do paměti [suspend-to-RAM] docela dobře, ale mohou to udělat jenom na přímý příkaz. Uspávání do paměti je ale důležité, spotřeba energie v porovnání s nezatíženým [idle] systémem je asi 10 %. Ruční uspávání není příliš vhodné, začal Pavel Machek popis svého nápadu, který nazval Ospalý Linux.

Ruční uspávání nepřichází v úvahu na víceuživatelských strojích a ani na jednouživatelských to není tak jednoduché: 1) Stáhni tenhle velký kus něčeho v Mozille a pak se uspi; 2) Zkompiluj tohle a pak se uspi; 3) Můžeš se uspat hned, ale v 8:30 mě probuď mp3 přehrávačem. Pavel poskytl jednoduchý a ne zcela funkční patch, potom popsal navrhované řešení:

Dnešní hardware je většinou schopen fungovat lépe: se správně nastaveným probouzením může stroj spát a přitom předstírat, že nespí, tak, že se probudí pokaždé, když se stane něco zajímavého. To je samozřejmě jednodušší na strojích, které nejsou připojeny do sítě, a na noteboocích.

Citát: Výhody TuxOnIce

Možná to také pomůže v mé snaze, pokud si na nějakou najdu čas, přesvědčit Andrewa, že TuxOnIce má skutečně významné výhody oproti (u)swsusp a na kexec založené hibernaci.

Nigel Cunningham, zpráva z 1. ledna na Linux Kernel mailing list.

2.6.24-rc7, spousta malých změn

7. leden, originál

Linus Torvalds oznámil vydání linuxového jádra 2.6.24-rc7: Od -rc6 uplynuly dva týdny, ale přiznejme si, že mezi Vánoci a Novým rokem (a narozeninami) nebylo mnoho pracovních dní, takže rozdílový patch z -rc6 je poloviční oproti tomu z rc5 na rc6. Budu shovívavý a budu tvrdit, že je to díky tomu, že se všechno stabilizuje, ne proto, že jsme všichni během svátků byli zpití do němoty.

Linus stručně shrnul změny: Zkrácený log (přiložen dole) je krátký a vcelku informativní. Je to prostě jenom spousta malých změn. Diffstat zobrazuje spoustu jedno- a dvouřádkových změn, větší pozornost budí jen pár ovladačů (a platforma Cell.) Více vyniká jenom podpora /proc/slabinfo ve SLUB.

Citát: Menšina

Musím říct, že chyby, které skutečně zmizí poté, co uživatel přestane používat nvidia/fglrx/ndiswrapper/atd., tvoří v celkovém počtu menšinu.

Andrew Morton, zpráva z 9. ledna na Linux Kernel mailing list.

Dekódování oops

9. leden, originál

Tento týden bylo hlášeno celkem 49 oops hlášení a varování, minulý týden to bylo 53, napsal Arjan van de Ven, když posílal seznam nejčastějších 10 kernel oops z tohoto týdne. Al Viro navrhl: Lidé, kteří si stěžují, že s prací v jádře teprv začínají a že pro ně proto není dost práce, by mohli dekódovat tato hlášení na "tohle místo v téhle funkci, funkce byla volána <odtud>, hodnota té a té proměnné byla <taková>" a posílat výsledky.

Následovalo mnoho požadavků na návod, jak takový oops dekódovat. Linus Torvalds odpověděl: Ve skutečnosti to není vždy tak triviální, zvlášť když nemáte hluboké znalosti o kódu generovaném pro danou architekturu (a i tak jsou některé oops složitější než jiné kvůli inliningu, volání funkce na konci jiné [tail-call], atd.) Pokud oops nastane u kernelu, který jste si přeložili sami, je to většinou jednoduché, zvlášť pokud jste při konfiguraci řekli "y" u "Generovat ladící informace" [Generate debugging info].

Linus pokračoval detailnějším postupem, jak hledat chybu v oops hlášení, které náhodně vybral v lkml. Obecně musíte disasemblovat šestnáctkovou sekvenci uvedenou v oops hlášení (řádka "Code") a pokusit se ji spojit se zdrojovým kódem tak, abyste zjistili, co se děje. Potom uvedl několik tipů, jak toho dosáhnout nejlépe, a pokračoval příkladem, ve kterém prošel jeden z nahlášených oops. Al Viro se přidal popisem svých vlastních metod, jak dosáhnout stejného výsledku, přičemž prošel jiné hlášení a chybu nalezl.

Diskuse k tomuto článku

[Filip Jirsák]

• první odstavec – „Zpoždění začíná to být spíše pravidlem“
• na konci 2.6.24-rc5, konečná verze do Vánoc nebude chybí konec spanu pro citaci

Nepoužívaly se dříve v JN správné české uvozovky „“?

Nehodilo by se pro citáty v JN používat sémantický tag <cite> a dám mu stejný styl, jako má třída kt_citace?

Jinak opět děkuji za další díl Jaderných novin.

[Robert Krátký]

Nepoužívaly se dříve v JN správné české uvozovky „“?

Spíše ne, ale je pravda, že bych to měl zavést u všech článků.

Nehodilo by se pro citáty v JN používat sémantický tag <cite> a dám mu stejný styl, jako má třída kt_citace?

Těch tagů, které by našly uplatnění, je více (q, samp, kbd, ...). Zkusím s nimi začít pracovat.

[kavol]

Kdykoliv začne OOM killer střílet, se systémem je něco špatně a je mnohem produktivnější to řešit, než si přát přesnějšího OOM killera.

nevím, jestli to není vytržené z kontextu, ale tak jak to stojí, tak bych řekl, že pisatel je s odpuštěním trouba - když je chyba v aplikaci (nebo třeba ani ne chyba, prostě jen zpracovává neobvykle velká data) a ta si naalokuje veškerou dostupnou paměť, takže systém jde do kytek, jak to podle něj mám řešit, to mám tu aplikaci přestat používat a odinstalovat, aby náhodou nedošlo na killer? nebo si mám napsat vlastního démona, který bude hlídat paměť a sestřelí, co jí žere kriticky mnoho, aby náhodou nedošlo na killer (neměla by to snad být jeho práce)?

[Filip Jirsák]

Kdykoliv začne OOM killer střílet, se systémem je něco špatně a je mnohem produktivnější to řešit, než si přát přesnějšího OOM killera.

nevím, jestli to není vytržené z kontextu, ale tak jak to stojí, tak bych řekl, že pisatel je s odpuštěním trouba - když je chyba v aplikaci (nebo třeba ani ne chyba, prostě jen zpracovává neobvykle velká data) a ta si naalokuje veškerou dostupnou paměť, takže systém jde do kytek, jak to podle něj mám řešit, to mám tu aplikaci přestat používat a odinstalovat, aby náhodou nedošlo na killer? nebo si mám napsat vlastního démona, který bude hlídat paměť a sestřelí, co jí žere kriticky mnoho, aby náhodou nedošlo na killer (neměla by to snad být jeho práce)?

Co takhle opravit tu aplikaci? Když jí OOM killer „zastřelí“, tak asi stejně nebude moc použitelná…

[Luboš Luňák]

A k cemu potom OOM killer je? Jestli "neni" problem, ze OOM killer by se spis mel jmenovat OOM mass murderer a nahodne postrili i uplne nevinne procesy, tak to uz stejne tak tam muzou dat random() a hotovo. Kazdy se obcas utne a je dost otrava, kdyz se kvuli tomu musi vsechno restartovat (napr. OOM killer se zeleznou pravidelnosti vybere jako prvni k zastreleni jeden z nejdulezitejsich procesu z KDE a vsechno jde do haje, museli jsme na to pridavat workaround).

[Filip Jirsák]

On snad někdo pravidelně používá programy, které sežerou veškerou dostupnou paměť? Může se to dít ppogramátorům nebo testerům – pak ale není problém v algoritmu OOM killeru, ale v tom, že nemá uživatel šanci říci mu, který přesně proces je ten, který OOM pravděpodobně způsobí. Pak by ale podle mne jediné řešení bylo umožnit uživateli nastavit procesu příznak, že v případě nedostatku paměti má být přednostně odstřelen tento proces.

[Michal Kubeček]

Nebo spíš obráceně: označit procesy, které smějí být odstřeleny jen v případě, že není jiného zbytí (třeba sshd).

[Filip Jirsák]

Ale to přece neodpovídá realitě. V praxi pokud někdo (opakovaně) pouští proces, který zabere veškerou paměť, ví přesně, který proces to je, a jeho představa je taková, že OOM killer zabije právě tenhle jeden proces.

Pokud někdo spustí nějaký proces „v dobré víře“ a ten proces užírá paměť postupně, je to stav prakticky nepopsatelný, tudíž nealgoritmizovatelný, a asi nemá smysl bádat nad tím, jestli by OOM killer neměl proces k ukončení vybírat nějak lépe. Protože jak posoudí uživatel, že OOM killer vybral pro zabití špatný proces? Jedině tak, že má dopředu představu, který proces měl vybrat místo něj. A jsme zpátky u toho, označit dopředu proces(y), u kterých předpokládám, že by mohly dělat neplechu.

[happy barney]

v praxi to funguje tak, že php zožerie pamäť, ale oom killer odstrelí databázu

[cronin]

To je nie chyba, to je predsa umela inteligencia: OOM Killer odvodil, ze PHP vyzralo pamat len kvoli tomu, ze z databazy natiahlo prilis vela udajov.

[Michal Kubeček]

Mně šlo spíš o to, aby když už dojde na nejhorší a OOM něco odstřelí, aby to nebyl zrovna ten jediný proces, který by mi umožnil s tím systémem na dálku něco udělat (i kdyby to měl být jen korektní restart).

[happy barney]

je to dôležité (sshd)? do inittabu s ním

[Filip Jirsák]

Bral jsem to, že když už mi na nějakém takhle důležitém systému běží nějaká leakující aplikace, je už to stejně skoro jedno, protože nějaký nekorektní restart je ten nejmenší z problémů, který mi to způsobí

Ale jinak je to pravda – pro běžný provoz by se hodilo, aby nad některými aplikacemi držel OOM ochranou ruku, pro testování je zase lepší, když mu některé hříšníky nabonzuju rovnou předem. A jak napsal někdo níž v diskuzi, obojí je možné. Teď už zbývá jenom doladit startovací skripty, aby při spuštění daemona nastavily procesu tu hodnotu podle nějakého rozšířeného atributu spouštěné binárky automaticky, a máme vystaráno

[happy barney]

oom_adj je tuším dedené, takže v rc skriptoch bude stačiť echo $oom_value > /proc/$$/oom_adj

[Luboš Luňák]

Ach jo, tady si to zase nekdo predstavuje jak Hurvinek valku :-/. To mam porad laborovat s nastavovanim nejakeho priznaku na proces, ktery by zrovna mozna nahodou mohl mit problem, jen protoze kernel neni schopny pochopit, ze ma killnout proces, ktery za posledni okamzik nejvic narostl? A ano, vim, ze dokonaly algoritmus pro OOM killer nejde, jenze soucasny k nemu ma asi tak daleko jako trabant k formuli - nakonec taky nejak dojede.

A hlavni problem soucasneho OOM killeru neni ten, ze by se obcas netrefil. On se napoprve netrefi skoro nikdy.

[Filip Jirsák]

jen protoze kernel neni schopny pochopit, ze ma killnout proces, ktery za posledni okamzik nejvic narostl

Nepovede tenhle postup k zabití poslední spuštěné aplikace, nebo k zabití X, pokud oním zlobivým procesem je nějaká GUI aplikace? Případně vybije všechno možné, ale trvale rostoucího bumbrlíčka nechá na pokoji?

[Stanislav Brabec]

Ono je těžké odhadnout, kdo je ten nebezpečný bumbrlíček.

Představte si proces, který náhodně, zhruba jednou za sekundu, naalokuje pár kilobajtů, a nikdy nic nevrátí. Přestože vypadá nenápadně, časem dokáže zlikvidovat systém.

Proti němu vypadá proces, který zrovna desetkrát alokoval paměť, aby zobrazil okno „Není dostatek paměti!“ jako hlavní podezřelý. Až postřílí podobně „podezřelé“ dostane to i ten bumbrlíček.

Je ovšem ještě šance, že ten po první chybě paměť žrát přestane, a jen bude sedět na tom, co už má. Pak už jde použít jedině heuristiku: „Odstřel toho, kdo má nejvíc.“ Je skoro jasné, že podle této heuristiky to jako první dostanou Evolution, Firefox a X.

[Filip Jirsák]

Právě proto tvrdím, že buď můžu jako uživatel předem označit aplikaci, která je „podezřelá“, nebo holt vybíjení procesů nebude moc daleko od náhodných výstřelů, protože spolehlivě určit viníka nelze. Ostatně která aplikace je viník je vždycky věc názoru člověka, který ty aplikace provozuje – obecně může mít nějaká aplikace dobrý důvod alokovat postupně čím dál víc paměti, stejně jako to může znamenat memory leak. A i aplikace, kde je to memory leak, může takhle leakovat „chtěně“ – např. když se programátor pokouší zjistit, kde je vlastně problém.

[petr_p]

/proc/PID/oom_adj:

This file can be used to adjust the score used to select which processes should be killed in an out-of-memory situation. Giving it a high score will increase the likelihood of this process being killed by the oom-killer. Valid values are in the range -16 to +15, plus the special value -17, which disables oom-killing altogether for this process.

[Ondrej 'SanTiago' Zajicek]

> to mám tu aplikaci přestat používat a odinstalovat, aby náhodou nedošlo na killer?

Co poustet takovou aplikaci s vhodne nastavenym ulimitem?

[kavol]

a to "vhodné nastavení" zjistím jak? - nemám křišťálovou kouli, abych v okamžik spuštění nějaké aplikace věděl, jestli druhý den sestřelí systém když bude zabírat 500 MB paměti nebo až když bude zabírat 1,5 GB ...

[trekker.dk]

když je chyba v aplikaci (nebo třeba ani ne chyba, prostě jen zpracovává neobvykle velká data) a ta si naalokuje veškerou dostupnou paměť, takže systém jde do kytek, jak to podle něj mám řešit, to mám tu aplikaci přestat používat a odinstalovat, aby náhodou nedošlo na killer?

Pokud aplikace zpracovává neobvykle velká data a dojde paměť, tak "je se systémem něco špatně", protože jsi tam nedal dost paměti. Je produktivnější to řešit (přidat paměť), protože jinak se situace pravděpodobně bude opakovat.

A ne, nemáš ji přestat používat, aby na killera náhodou nedošlo, ale máš potom zjistit, co se stalo a pokusit se tomu nějak předejít. OOM killer je jenom nouzový prostředek, který má napravovat chyby někoho jiného - mnohem efektivnější, než vylepšovat OOM killer, je podle mě věnovat čas na opravu těch chyb.

[kavol]

Pokud aplikace zpracovává neobvykle velká data a dojde paměť, tak "je se systémem něco špatně", protože jsi tam nedal dost paměti. Je produktivnější to řešit (přidat paměť), protože jinak se situace pravděpodobně bude opakovat.

jenomže dopředu to obvykle nevím - ano, až to zjistím, mohu paměť dokoupit, jenomže mezitím jaksi potřebuju něco, aby zasáhlo právě v ten okamžik, kdy problém nastane; můj počítač totiž jaksi nepodporuje hotswap pamětí, nehledě na to, že bych s ním třeba chtěl ještě něco udělat než do toho krámu pro tu paměť poběžím atd.

A ne, nemáš ji přestat používat, aby na killera náhodou nedošlo, ale máš potom zjistit, co se stalo a pokusit se tomu nějak předejít. OOM killer je jenom nouzový prostředek, který má napravovat chyby někoho jiného - mnohem efektivnější, než vylepšovat OOM killer, je podle mě věnovat čas na opravu těch chyb.

ta myšlenka nebyla tak úplně dokončená, měl jsem ještě říct, že takhle bych mohl odinstalovat celý systém

samozřejmě je lepší, aby k chybám nedocházelo, ale občas se holt stane, a říkat, že není vhodné snažit se, aby ten "nouzový prostředek" nebyl co nejefektivnější, je divné ... asi jako kdyby někdo říkal, že nepotřebujeme tolik přispívat na hasiče, aby měli co nejlepší vybavení, protože když někde začne hořet, mám pak zjistit, co se stalo, a pokusit se tomu předejít (nejspíš instalovat tabulku s nápisem "neodhazute nedopalky" a najmout hlídače na vynucení dodržování? )

[miso]

Nikdy nehas benzinem ohniste!

Ted je to uz jedno, ale pro priste

[geebranz]

More news

cryotherapypensacolafl.com