Jaderné noviny – 15. 4. 2010

3. 5. 2010 | Jirka Bourek | Jaderné noviny | 2942×

Aktuální verze jádra: 2.6.34-rc4. Citáty týdne: Linus Torvalds, Andi Kleen. Vkládání nečinných cyklů. ELC: Stav embedded Linuxu. Rychlost bootu. Souborové systémy. Správa napájení a běh v reálném čase. Velikost jádra. Sledování a bezpečnost. Práce pro CELF. Volání do zbraně. Případ příliš anonymní anon_vma.

Obsah

• Aktuální verze jádra: 2.6.34-rc4
• Citáty týdne: Linus Torvalds, Andi Kleen
• Vkládání nečinných cyklů
• ELC: Stav embedded Linuxu
  • Rychlost bootu
  • Souborové systémy
  • Správa napájení a běh v reálném čase
  • Velikost jádra
  • Sledování a bezpečnost
  • Práce pro CELF
  • Volání do zbraně
• Případ příliš anonymní anon_vma

Aktuální verze jádra: 2.6.34-rc4

Současné vývojové jádro je 2.6.34-rc4 vydané 12. dubna – téměř o týden později, než se očekávalo. Zpoždění vzniklo v důsledku ošklivé regrese ve VM (vizte v článku níže). Od -rc3 bylo začleněno nějakých 500 oprav. Zkrácený changelog je v oznámení, všechny detaily najdete v kompletním changelogu.

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

Citáty týdne: Linus Torvalds, Andi Kleen

Hej, ale všechny moje teorie také dávaly smysl. Jenom nefungovaly.

Ale jak řekl Edison: Neselhal jsem, jenom jsem našel další tři způsoby, jak nenapravit tvou chybu.

-- Linus Torvalds

Abych byl upřímný, myslím si, že 4k zásobník musí zmizet. Většinou ho nazývám režim „ruská ruleta“

Byl to jenom starý způsob, jak obejít velmi starý zachybovaný VM, který nebyl schopen uvolnit 8k stránky, a VM je teď podstatně lepší. A obecný trend je zesložiťování kódu, takže 4k zásobníky jsou čím dál tím nebezpečnější. Už tenkrát to byl špatný nápad a stále je to špatný nápad, zhoršuje se čím dál tím víc s každým miliónem řádků kódu, které v jádře každý rok přibudou.

-- Andi Kleen

Vkládání nečinných cyklů

napsal Jonathan Corbet, 14. dubna 2010

Když Mike Waychison z Googlu hovořil na Jaderném summitu 2009, jeden z cílů, které si vytkl, bylo začlenění kódu vkládání nečinných cyklů [idle cycle] do hlavní řady. Vkládání nečinných cyklů znamená vynucené uvedení procesoru do klidového stavu, aby se zabránilo přehřátí; v podstatě se jedná o Googlí způsob, jak provozovat procesory na hranici jejich schopností, aniž by tato hranice byla překročena. Tento způsob správy napájení rozhodně není záležitost specifická jen pro Google, takže dává smysl tento kód začlenit do upstreamu. Salman Qazi nedávno zaslal sérii patchů kidled, která ukazuje současný stav této práce.

Základní nápad je jednoduchý: Přes nějaký nový řídící soubor v /proc/sys/kernel/kidled může správce systému pro jednotlivá CPU nastavit procento času, které má procesor strávit v klidu, a interval, ze kterého se tento podíl počítá. Jestliže se konec intervalu blíží a CPU nebylo přirozeně v klidu dostatečně dlouho, kidled na chvíli donutí procesor k nečinnosti.

Samozřejmě jsou tu nějaké komplikace. První je, že by bylo pěkné vyhnout se nečinným cyklům, když běží důležité procesy. Kidled tedy zavádí pojem „vkládání horlivých cyklů“ [eager cycle injection]. Pomocí mechanismu řídících skupin [control groups] lze procesy označit jako „interaktivní“. Když takto označené procesy neběží, kidled se pokusí vynutit nečinné cykly brzy. Když interaktivní procesy běží, nečinné cykly jsou vynuceny, jenom pokud je to striktně nutné. Tak se zajistí, že „interaktivní“ procesy nebudou zdržovány nečinnými cykly, pokud to nebude nezbytné.

Další záležitost se týká účtování nečinného času CPU. Vkládání nečinných cyklů někomu odebere čas CPU; kód kidled umožní správci stanovit, kdo by měly být oběti. Další parametr pomocí řídících skupin stanovuje každému procesu „prioritu pro omezení spotřeby“ [power capping priority]. Když jsou vloženy nečinné cykly, kidled se pohrabe v datových strukturách plánovače, aby se čas nečinnosti naúčtoval procesům o nižší prioritě. To znamená, že když musí být přiškrceno využívání CPU, některé procesy mohou trpět více než jiné.

V době psaní tohoto článku o těchto patchích neproběhla velká veřejná diskuze. Základní koncept není kontroverzní, ale bude zajímavé sledovat, jak budou přijaty části spojené s plánovačem.

ELC: Stav embedded Linuxu

napsal Jake Edge, 14. dubna 2010

Organizátor Embedded Linux Conference (ELC) Tim Bird nabídl ve své přednášce shrnutí situace ohledně Linuxu v embedded zařízeních. Hovořil o nových a navrhovaných vlastnostech jádra, které by mohly vývojáře zajímat, a také vývojáře „volal do zbraně“, aby se více zapojili do komunity. Tato přednáška je na ELC pravidelná, aby komunita měla k dispozici nejčerstvější informace a přehled o neuvěřitelné rychlosti vývoje jádra.

Od minulé konference byla vydána čtyři nová jádra a Tim vyjmenoval zajímavé vlastnosti v každém z nich od 2.6.30 po .33. Zmínil také, že LogFS se konečně dostal do jádra ve verzi 2.6.34, přičemž podle jeho obav k tomu nemuselo dojít nikdy. Rychlost vývoje jádra je podle něj úžasná a skvělý na tom je fakt, že i když spím, lidé na něm stále pracují.

Upozornil na některé patche, které je dobré sledovat, protože by mohly vyjít v nových jádrech, obzvláště na konfigurační volbu CROSS_COMPILE, která zjednoduší překlad na několik architektur. Také upozornil na patche asm-generic Arnda Bergmanna, jejichž cílem je zjednodušit přidávání nových architektur do jádra – bez rozšiřování chyb a zvláštností těch existujících.

Rychlost bootu

Tim se poté podíval na jiné „technologické oblasti“, aby upozornil na zajímavé vlastnosti nebo na práci, která v nich probíhá. Čas bootu je nyní horké téma; byl by jím i v minulosti, kdyby byla embedded komunita více zapojena do vývoje hlavní řady jádra. Snaha o pětivteřinový boot u Moblinu tuto práci pořádně nakopla. Tim dodal, že má videokameru Sony (jeho zaměstnavatel), která nabootuje Linux za 1,5 sekund; Na to jsem velmi pyšný, řekl.

Omezit dobu bootu pomáhá několik nových vlastností jádra včetně infrastruktury pro asynchronní volání funkcí, která některým částem inicializace zařízení umožňuje běžet paralelně. Také je zde skript scripts/bootgraph.pl, který pomáhá zobrazit, kde se při bootování tráví nejvíce času.

Jako způsob zrychlení bootu bylo zmíněno také devtmpfs, někteří pozorovali na desktopu zrychlení až o 0,6 sekundy. Tim řekl, že je potřeba nějaké testování na straně embedded systémů, aby se zjistilo, jak může devtmpfs pomoci tam. Také zmínil dva patche, které zrychlují rozlišování symbolů pro nahrávání modulů tak, že se zbavují současného lineárního prohledávání. Jeden používá binární vyhledávání a druhý hash tabulku. Tim vždy ovladače zabudovává do jádra staticky, ale slyšel, že se víc vývojářů drží nahrávatelných modulů.

Greg Kroah-Hartman se ozval s tím, že potřeboval jeden z těchto dvou patchů pro MeeGo, ale ti, kdo je zaslali, se ztratili. Panovala obecná shoda na tom, že by bylo dobré je kontaktovat a dostat něco do upstreamu.

Souborové systémy

Tim poskytl seznam několika různých souborových systémů pro použití v embedded zařízení. Squashfs byl mimo hlavní řadu léta, ale začleněn byl do 2.6.29 a od té doby byl vylepšen, což je klasický příklad demonstrující výhody kódu v hlavní řadě. Ubifs je také v hlavní řadě a lidé z Toshiby charakterizovali jeho výkonnost na CE Linux Forum (CELF) Japan Jamboree. V některých případech se opravdu dlouho připojuje, lidé z CELF by rádi najali někoho, kdo by to opravil.

LogFS je pro některá flash zařízení optimalizován mnohem lépe a připojuje se rychle, poznamenal Tim. Dodal, že AXFS, pokročilý souborový systém se spouštěním na místě [execute-in-place, XIP], se vytratil a nevypadá to, že by byl na cestě do hlavní řady. S AXFS si Tim v Sony hrál, aby ještě snížil dobu bootu.

Tim také upozornil na to, že patche obcházející patenty na VFAT se do hlavní řady nedostaly. Řekl, že pro některá embedded zařízení by byly užitečné: Většina vývojářů patenty obchází tím, že VFAT zakazují a používají jména ve formátu 8.3, což je poměrně nešťastné. Další věc, kterou sleduje, jsou sjednocená připojení založená na VFS, která by umožnila přestat vytvářet souborové systémy s podivnými odkazy jednoho na druhý, což je v současnosti běžné.

Správa napájení a běh v reálném čase

Kód správy napájení za běhu byl začleněn, což umožňuje uspávání a probouzení jednotlivých komponent systému, aby se omezila spotřeba. Dále se pracuje na asynchronním uspávání/probouzení; Tim řekl, že o tom moc neví, ale že to bude opravdu skvělé. Někdo z obecenstva mu vypomohl a řekl, že je to v některých ohledech podobné kódu asynchronní inicializace (pro rychlejší boot), ale opačným směrem.

Sada patchů RT_PREEMPT pokračuje ve svém pomalém pochodu do jádra, obsluhy přerušení ve vláknech byly začleněny v 2.6.30 a přípravná práce pro budoucí začlenění spících spinlocků byla začleněna do 2.6.33. Stále je několik záležitostí spojených s Velkým jaderným zámkem [big kernel lock, BKL], které je potřeba vyřešit, a CELF možná bude nějakou práci v této oblasti financovat.

Velikost jádra

Slide pro velikost jádra a spotřebu paměti obsahoval obrázek hybridního karavanu, což odráží to, jak si Tim představuje dnešní jádro. To prostě stále roste. Vývojářům pomáhá lépe využít omezenou paměť nástroj smem, jehož vývoj financoval CELF. Tim ho letos použil na několik projektů a sloužil velmi dobře.

Bylo přidáno několik metod komprese, které různými způsoby komprimují jádro. LZMA může být až o 30 % lepší než gzip a LZO není tak dobré v kompresi, ale je o mnoho rychlejší. Jak upozornil Dirk Hohndel, je potřeba zvažovat rychlost procesoru a propustnost I/O, takže vybrat správnou metodu komprese není triviální.

Zařízení ramzswap (také známé jako compcache) umožňuje používat komprimovaný swap v paměti. Je to fakt skvělé, ale jeho správci se podařilo udělat benchmarky jenom na desktopovém systému. Tim řekl, že by bylo dobré, kdyby se někomu podařily nějaké benchmarky na embedded zařízení.

Sledování a bezpečnost

Ftrace nyní obsahuje podporu pro dynamické sondy, která se objevila v 2.6.33, a nástroj perf tyto sondy může umisťovat a používat také. Také je k dispozici sledování přístupu k jaderným proměnným a jejich modifikace. Režim perf „diff“, který se také objevil v 2.6.33, může zobrazit rozdíly výkonnosti mezi dvěma běhy.

Začlenění TOMOYO do 2.6.30 bylo velice významné, protože se tím do jádra konečně dostala bezpečnost založená na cestách. NTT Data nyní přidává pravidla pro TOMOYO do Androidu. Co se bezpečnosti týče, je Tim příznivcem možnosti volby, protože ta dává lidem možnost demonstrovat, které řešení je ve specifické situaci nejlepší. Součástí toho je studie [PDF] financovaná CELF, která zkoumá použití bezpečnostního modulu Smack v televizoru a která zjišťuje, že režie byla větší, než se očekávalo.

Práce pro CELF

CELF financovalo během minulého roku různé projekty včetně smem, upozorňování na nedostatek paměti v řídících skupinách, SquashFS, analýzu Smack, stromy zařízení pro ARM a práci na -ffunction-sections, což vkládá každou funkci jádra do vlastní sekce a tak pomáhá při odstraňování mrtvého kódu. Do budoucna CELF plánuje návrh otevřeného projektu, podle kterého se během několika týdnů chystá zahájit financování nových projektů. Také sponzoruje Matta Mackalla jako jednoho ze dvou správců embedded zařízení v linuxovém jádře (tím druhým je David Woodhouse.)

Volání do zbraně

Tim zakončil svou přednášku seznamem věcí, které mohou vývojáři embedded zařízení udělat pro to, aby lépe pracovali s komunitou. Na vrcholu seznamu bylo pracujte na vrcholu stromu. Uvědomil si, že při přednáškách obvykle mluví k lidem, kteří nepoužívají zmiňovaná jádra, protože lidé od embedded vývoje si obvykle vyberou jedno jádro a toho se drží. Pracovat s nejnovějším jádrem je obtížné, ale stojí to za to. Propast mezi verzemi je ten největší problém embedded Linuxu. Navrhl, aby se vývojáři vrhli na prodejce desek, získali od nich podpůrné balíčky s nejnovějšími jádry a testovali na deskách, které již jsou hlavní řadou podporovány.

Další návrh byl nečekat, až ostatní otestují nové vlastnosti, ale testovat. Vyjmenoval několik věcí, které v hlavní řadě potřebují otestovat: LogFS, dobu připojování Ubifs, ramzswap, správu napájení za běhu a tak dál. Výsledky zašlete na wiki elinux.org nebo přijeďte na příští konferenci (27.-28. října v Cambridge ve Velké Británii), kde je můžete předat osobně.

Případ příliš anonymní anon_vma

napsal Jonathan Corbet, 13. dubna 2010

Během stabilizační fáze jaderného vývojového cyklu vychází -rc typicky jednou za týden. -rc4 je jasnou výjimkou, vyšlo téměř dva týdny po předchozím -rc3. Zdržení v tomto případě způsobila ošklivá regrese, která celé dny téměř na plný úvazek zaměstnávala mnoho jaderných vývojářů. Lov na tuto chybu je klasický příběh o tom, co se může stát, když se kód moc zesložití.

Zaslat e-mail do linux-kernel může být z několika důvodů poměrně nepříjemná vyhlídka; jeden z nich je to, že jeden nikdy neví, jestli z toho nevznikne obrovské vlákno – obsahující stovky zpráv, které se kopírují původnímu odesílateli. Hlášení o chybě v 2.6.34-rc3 od Bořislava Petkova dopadlo podobně. V tomto případě nebylo ovšem vzniklé vlákno nijak zápalné; reprezentuje nejintenzivnější škrábání se na hlavě, které bylo možné za nějakou dobu vidět.

Chyba, kterou Bořislav nahlásil, byla dereferencování nulového ukazatele, ke kterému došlo poměrně spolehlivě po hibernaci (a restartu) systému. Rychle bylo rozpoznáno, že jde o stejný problém jako v jiné nahlášené chybě, tu hlásil stejný den Steinar H. Gunderson, ale hibernaci nezahrnovala. Společným jmenovatelem zde bylo dereferencování nulového ukazatele vyprovokované tlakem na paměť. Patch, který problém způsobil, téměř okamžitě identifikoval Linus; stojí za to se podívat, co patch dělal.

Kdysi dávno roku 2004 LWN psaly o přidání kódu anon_vma; patch byl v té době kontroverzní, protože od chystaného jádra 2.6.7 se očekávalo, že bude postaru „stabilní verze bez nových vlastností“. Tento patch byla série skládající se ze 40 částí a od základů přepracovávala subsystém virtuální paměti, což nebylo považováno za stabilní materiál, přestože se ho Linus pokoušel charakterizovat jako „implementační detail“. I tak kód prokázal svou užitečnost a od té doby nebyl významně měněn – až doteď.

Problém, který řešil patch anon_vma, spočíval v nalezení všech (VMA) struktur vm_area_struct, které se odkazují na danou anonymní stránku v paměti (na haldě nebo na zásobníku). Anonymní stránky obvykle nejsou mezi procesy sdíleny, ale každé volání fork() způsobí, že je stránka sdílena mezi rodičem a potomkem; toto sdílení je narušeno jenom v případě, že jeden z procesů zapíše do nějaké stránky, což vyvolá kopírování při zápisu (copy-on-write, COW). Do mnoha stránek se nezapíše nikdy, takže jádro musí být schopné najít všechny VMA, které odkazují na danou anonymní stránku; jinak by nebylo schopné stránku odmapovat, takže by ji nebylo možné odswapovat.

Ukázalo se, že reverzní mapování původně použité v 2.6 je příliš nákladné a že vyžaduje přepis. Tento přepis zavedl strukturu anon_vma, která drží seznam všech VMA, které by mohly odkazovat na danou stránku. fork() tedy způsobí, že je každá VMA v procesu potomka, který obsahuje anonymní stránky, přidána na seznam udržovaný strukturou rodiče anon_vma. Ukazatel mapping ve struct page ukazuje na strukturu anon_vma, což jádru umožňuje procházet seznam a najít všechny relevantní VMA struktury.

Obrázek z článku z roku 2004 ukazuje, jak tato struktura vypadá:

Toto řešení škálovalo lépe než jeho předchůdce, ale svět ho nakonec dostihl také. Rik van Riel se tedy rozhodl věci zrychlit a napsal tento patch, který byl začleněn do 2.6.34. Rik problém popisuje takto:

Při zátěži s 1000 procesy potomka a VMA s 1000 anonymními stránkami na proces, které jsou kopírovány při zápisu, to vede na systém, který má milion anonymních stránek v jedné struktuře anon_vma, přičemž každá je mapována jenom jedním z 1000 procesů. Současný kód rmap je nicméně musí projít všechny, což znamená složitost prohledávání O(N) pro každou stránku.

Zorganizováním všech anonymních stránek, které vznikly u stejného rodiče, do stejné struktury anon_vma jádro v podstatě vytváří monstrózní datovou strukturu, kterou musí projít pokaždé, když potřebuje reverzně mapovat stránku. To vede k tomu, že jádro prohledává velký počet VMA, které vůbec nemohou na stránku odkazovat, přičemž drží zámky. Výsledkem je, jak říká Rik, „katastrofické selhání“ při běhu benchmarku AIM.

Rikovo řešení je vytvoření struktury anon_vma pro každý proces a spojení těchto struktur místo struktur VMA. Toto spojení je provedeno pomocí nové struktury nazvané anon_vma_chain:

struct anon_vma_chain {
    struct vm_area_struct *vma;
    struct anon_vma *anon_vma;
    struct list_head same_vma;
   struct list_head same_anon_vma;
};

Každý záznam anon_vma_chain (AVC) obsahuje dva seznamy: Všechny struktury anon_vma relevantní pro danou vma (same_vma) a všechny VMA, které spadají do oblasti pokryté danou strukturou anon_vma (same_anon_vma). Je to trochu komplikované, takže možná pomohou nějaké obrázky. Ze začátku máme proces s jednou anonymní VMA:

Zde je „AV“ struktura anon_vma a „AVC“ je struktura anon_vma_chain popsaná výše. AVC odkazuje jak na strukturu anon_vma, tak na strukturu VMA přímými ukazateli. Ukazatel (modrého) spojového seznamu je seznam same_anon_vma, (červený) ukazatel je seznam same_vma. Zatím je to jednoduché.

Představme si nyní, že se tento proces rozdělí, takže je VMA zkopírováno potomkovi; nejprve máme osamocené VMA:

Jádro musí propojit toto VMA ke struktuře anon_vma rodiče; to vyžaduje přidání nového anon_vma_chain:

Všimněte si, že nový AVC byl přidán na modrý seznam všech VMA odkazujících se na danou strukturu anon_vma. Nová VMA nicméně také potřebuje svoji vlastní anon_vma:

Nyní je zde další struktura anon_vma_chain, která se napojuje na novou anon_vma. Nový červený seznam se rozšířil tak, aby pokryl všechny AVC, které pokrývají relevantní struktury anon_vma. Jak autor článku slíbil, komplikuje se to; diagram pro případ s tisíci potomky, který motivoval tento patch, je ponechán jako cvičení pro čtenáře.

Když se zavolá fork(), všechny anonymní stránky v oblasti ukazují na strukturu rodiče anon_vma. Když do stránky zapíše potomek, dojde ke kopírování při zápisu a nová stránka je namapována do struktury potomka anon_vma. Nyní lze reverzní mapování provést okamžitě bez potřeby procházet ostatní procesy v hierarchii. Tím se ztrácí soupeření o zámky a provozovatelé benchmarků jsou šťastní.

Jediný problém je ta zahanbující záležitost ohledně oopsu. Linus, Rik, Bořislav a další se za ní hnali a zkoušeli nekončící zástup změn. Chvíli se zdálo, že by problém mohla být chyba, která způsobuje přílišné znovuvyužívání struktur anon_vma, když se VMA slučují, ale oprava této chyby neopravila oops. Změna hranic VMA pomocí mprotect() mohla občas způsobit použití špatné anon_vma, ale ani oprava tohoto problému nepomohla. Změna pořadí řetězů, když se kopírovaly, byla také problém, ale ne ten problém.

Linus se zjevně začal zabývat tím, jak to skončí: Opravili jsme tři různé chyby a pořád nic? Opakovaně zvažoval revert dané změny, ale nechtělo se mu do toho; řešení se zdálo být nadějně blízko. Nakonec vytvořil další hypotézu, která vypadala slibně. Anonymní stránka sdílená mezi rodičem a potomkem zpočátku ukazovala na anon_vma rodiče:

Jestliže ale oba procesy stránku odmapovaly (což se může stát například při hibernaci systému) a potomek se na ni potom odkázal první, mohla se odkazovat na anon_vma potomka.

Pokud později stránku namapoval rodič a potomek ji odmapoval (například tím, že se ukončil), rodiči zbyla anonymní stránka ukazující na potomka anon_vma – která již neexistovala:

Není třeba říkat, že taková situace jenom těžko v blízké budoucnosti povede k něčemu dobrému.

Oprava je jednoduchá; když se odkazuje existující stránka na strukturu anon_vma, jádro musí vybrat tu, která je nejvýše v hierarchii procesů; to zajišťuje, že anon_vma nezmizí předčasně. První testy naznačují, že problém byl opravdu opraven. Během toho byly opraveny tři jiné chyby a Linus poznal záludný kód, který, pokud se k tomu Linus dostane, získá vylepšenou dokumentaci. Jinými slovy se zdá, že na tento výsledek stálo za to si počkat.

       

Komentáře

[mimi.vx]

prvni .... pekny popis lovu chyby + navic vyreseni par dalsich bokem ..

[still]

nerozumiem tomu, ale bavi ma to citat, citim taku hrdost nad tym ako sa linux kernel vyvija, ze sa otvorene riesia chyby, presny opak microsoftu....dobry pocit.

[Johny]

Úplný súhlas!

[Mykonou]

Tim Bird nebo Tom?

[trekker.dk]

stfg

tim bird linux, není to tak těžké

[Mykonou]

Ooo, diky velky. Narazel jsem na to ze jednou je v clanku tim a pak uz jenom tom ...

[trekker.dk]

No to je chyba, to stačí říct rovnou