Jaderné noviny - 26. 3. 2008

22. 5. 2008 | Jirka Bourek | Jaderné noviny | 3837×

Aktuální verze jádra: 2.6.25-rc7. Citáty týdne: Val Henson, Jörn Engel, Ingo Molnár. Značky v jádře a pouze binární moduly. Prediktivní ELF bitmapy. Atomický kontext a design API jádra.

Obsah

• Aktuální verze jádra: 2.6.25-rc7
• Citáty týdne: Val Henson, Jörn Engel, Ingo Molnár
• Značky v jádře a pouze binární moduly
• Prediktivní ELF bitmapy
• Atomický kontext a design API jádra

Aktuální verze jádra: 2.6.25-rc7

Aktuální vývojové jádro je 2.6.25-rc7, vydané 25. března. Linus řekl: Zkrácený log obsahuje víc detailů, ale v podstatě se scvrkl na nějaké reverty, opravy docbooks, pár různých oprav anotací, větší množství triviálních patchů a zdravou spršku malých oprav. Dobře ho otestujte, protože jsme snad na dobré cestě k vydání skutečného 2.6.25! Zmíněný log lze nalézt v oznámení, detaily najdete v kompletním changelogu.

Aktuální stabilní jádro je 2.6.24.4, vydané 24. března. Toto vydání obsahuje mnoho oprav významných problémů v jádře 2.6.24.

Citáty týdne: Val Henson, Jörn Engel, Ingo Molnár

Řekla bych, že jsem měla radši, když na mě lidi prostě prázdně koukali poté, co jsem jim řekla, co dělám.

-- Val Helson

Když odmítnete užitečné patche s tím, že "toto není náš preferovaný styl", tak lidi naštvete. To je potom významný důvod, proč se rozhodnou strávit svůj čas jinde. V některých případech může být to, že lidi jádro opustí, zisk, častěji je to ztráta.

-- Jörn Engel

Moje zkušenost s checkpatch.pl je naprosto opačná od toho, čeho se bojíš: rozšířil základnu přispěvatelů. Značnému množství nováčků dodalo odvahy to, že jim objektivní nástroj ohlásil "chybu" v souboru, který byl napsán jinak "mnohem znalejšími" hackery jádra. checkpatch.pl je v podstatě revizní nástroj typu "ano, skutečně máš pravdu, tenhle kus kódu v Linuxovém jádře je vskutku hnus," takže nováčky podpoří. Zmenšuje překážky pro přístup k programování jádra a přesně v těch oblastech kódu, na kterých chceme, aby nováčci pracovali: na téměř neudržovaných zdrojácích.

-- Ingo Molnár

Značky v jádře a pouze binární moduly

Značky v jádře jsou mechanismus, který vývojářům umožňuje do jádra vkládat statické sledovací body [tracepoints]. Jakmile jsou umístěny, operátoři je mohou používat ke sledování známých události v běžících systémech, aniž by potřebovali něco vědět o jaderném kódu. Solaris poskytuje dlouhý seznam statických sledovacích bodů pro použití s Dtrace, ale Linux nemá žádné. Tato situace by se měla časem změnit - statické značky byly do hlavní řady začleněny teprve v 2.6.24. Nicméně jak se vývojáři začínají na značky dívat vážněji, vynořují se některé problémy.

Jeden z nich se objevil jako důsledek tohoto patche, který zaslal Mathieu Desnoyers a který umožňuje binárním modulům obsahovat značky. Fakt, že současná jádra značky v pouze binárních modulech nerozeznávají, je v podstatě náhoda: značky jsou zakázané v modulech, které mají nastavený některý příznak tainted, aby se zabránilo pádům jádra - oops je přece jenom o dost ošklivější značka, než na jakou by lidé chtěli narazit. Matthieu test omezil tak, že značky v proprietárních modulech povoluje s tím, že uvidíme, jak lidi zareagují. Je zbytečné říkat, že zareagovali.

Člověk by se mohl divit, proč by vývojáři jádra, kteří všeobecně nejsou příliš známí svými sympatiemi k proprietárním jaderným modulům, chtěli povolit těmto modulům obsahovat statické sledovací body. Hlavním argumentem je zde fakt, že tyto značky umožňují proprietárním modulům exportovat o něco víc interních informací jádru a jeho uživatelům. Je to viděno jako (velmi) malé otevření se na straně autora modulu. Mathieu řekl:

Myslím si, že pro koncového uživatele je jenom užitečné, když necháme proprietární moduly, aby se trochu otevřely. A k tomu by pravděpodobně došlo, protože autoři modulů by značky doma mohli používat bez omezení a před vydáním by je museli výslovně zakázat.

Myšlenka je taková, že umístěním těchto sledovacích bodů mohou autoři modulů pomoci ostatním dozvědět se, co se uvnitř modulu děje, a pomoci lidem vysledovat problémy. Výsledkem by mělo být stabilnější jádro, což je - bez ohledu na to, jestli byly nahrány proprietární moduly - obecně považováno za dobrou věc.

Na druhou stranu netrpíme nedostatkem vývojářů, kteří se staví proti jakémukoliv nabízení pomocné ruky autorům binárních modulů. Říká se, že dávat těmto modulům přístup k útrobám jádra, vede jenom k problémům. Ingo Molnár to řekl takhle:

Proč se o tom vůbec dohadujeme? Binární moduly by měly být izolovány tak, jak jenom je to možné - jsou to zcela nedůvěryhodné entity a historie znovu a znovu ukázala, že k čím menší části infrastruktury mají přístup, tím lépe.

Ingo má také obavy, že když se binárním modulům umožní používat značky, bude v budoucnu mnohem obtížnější změnit jejich API. Vzhledem k tomu, že API značek je poměrně mladé, je velká pravděpodobnost, že k nějakým změnám dojde. A přestože vývojáři jádra tvrdí, že o pouze binární moduly se nestarají, je fakt, že existují dobré důvody pro to, aby se vyhnuli dělání věcí, kvůli kterým by přestaly fungovat. Komunita testerů se vždycky zmenší, když testeři nemohou nahrát moduly, které potřebují k rozběhnutí svých systémů takovým způsobem, na jaký byli zvyklí. Takže je možné, že povolit proprietárním modulům používat značky by znamenalo obtížnější opravy API v budoucích vydáních jádra.

Reptání bylo dostatečně hlasité na to, že Matthieuho patch pravděpodobně nebude začleněn do 2.6.25. Nápad jako takový se pravděpodobně objeví znovu, nicméně asi ne tak brzy: značky byly začleněny v 2.6.24, ale zdá se, že 2.6.25 bude vydáno, aniž by se v něm nějaká značka objevila. Není tak úplně jisté, že autoři binárních modulů budou tlačit na přidání sledovacích bodů, když to nedělá nikdo z ostatních vývojářů. Do doby, než někdo statické značky začne používat, debaty o tom, kde se smí použít, budou spíše akademické povahy.

Prediktivní ELF bitmapy

Když jádro spustí program, musí načíst jeho kód z disku, což normálně dělá tak, že požaduje jeho stránkování, což vyžaduje cesta vykonání [execution path]. Kdyby jádro mohlo nějakým způsobem vědět, které stránky budou potřeba, mohlo by je stránkovat efektivněji. Andi Kleen zaslal experimentální sadu patchů, které dělají přesně tohle.

Programy neví o svém rozložení na disku nic a cesta vykonávání skrz kód není nijak optimalizována, aby se omezilo vyhledávání [seek], nicméně s některými informacemi o tom, které stránky budou potřeba, může jádro optimalizovat přístup k disku. Pokud by se nějak podařilo získat seznam stránek, které při vykonávání programu selhaly, tato informace by se dala uložit pro příští běh. Potom by se dala změnit v bitovou mapu, která by označovala, které stránky se mají přednačíst.

Jakmile takovou bitovou mapu máme, objeví se problém, kam ji uložit. Andiho metoda spočívá v tom, že ELF formát na disku se "hackne" a bitmapa se uloží na konec spustitelného souboru. To má několik nevýhod: nutnost seeku, aby se informace načetly, modifikace spustitelného souboru pokaždé, když se trénuje, a v celém systému takto může existovat pro jeden soubor jenom jeden vzor. Na druhou stranu to má i velmi příjemnou vlastnost, že bitová mapa a spustitelný soubor jsou synchronizovány; když se program změní například kvůli upgradu, bitová mapa je vymazána. Alternativní místa pro ukládání bitových map - například někde v uživatelově domovském adresáři - tuto vlastnost nezachovávají.

Andrew Morton se ptal, jestli je vůbec nutné dělat to v jádře:

Nedalo by se do všechno udělat v uživatelském prostoru? V LD_PRELOAD se zachytíš [hook] v exit(), použiješ /proc/self/maps a ten nový kód mapování stránek, kde zjistíš, které stránky v kterých souborech selhaly, zapíšeš informace do elf souboru (nebo do zvláštního stínového souboru pro každý spustitelný program) a pak je použiješ, když je program spuštěn, buď pomocí LD_PRELOAD nebo nějakým wrapperem.

Ulrich Drepper nechtěl, aby byl ELF formát takto zneužíván. Andi také ne, ale použil to jako prozatímní jednoduché řešení. Ulrich si myslí, že linker by bylo potřeba naučit generovat nový typ hlavičky, která by bitmapu ukládala. Ta by byla skoro na začátku ELF souboru, čímž by se eliminovalo vyhledávání. Problém tohoto přístupu je, že staré binárky by nemohly tuto techniku využit; bylo by potřeba nové slinkování.

Pak nastává otázka, jak se bitmapa inicializuje. Ulrich navrhl použít systemtap:

K naplnění bitových map můžeme mít zvláštní nástroj, který bude explicitně požádán, aby data aktualizoval. Ke sběru dat o selhání stránek se může použít systemtap. Je dostatečně jednoduché napsat skript, který bude pro každou binárku monitorovat malé výpadky stránek a zapisovat tato data do souboru. Nástroj pro úpravu binárek potom může použít tyto informace a vygenerovat bitmapu.

Andiho patch prochází tabulky stránek pro proces, když se ukončuje, a nastavuje bit v mapě, pokud daná stránka selhala. Ulrich to vidí jako neoptimální:

Během mnoha použití programu budou potřeba všechny druhy stránek, takže se jich označí mnohem více, než je potřeba pro obvyklý běh. Přednačítání by mělo pokrývat jenom v programu běžně využívané cesty kódu. Pokud natáhneš všechno, bude to výhodné, jenom pokud budeš mít dostatečnou cache stránek navíc. V takovém případě je ale jednodušší přednačíst celý soubor. Ne, vylepšená metoda tohoto typu musí být selektivnější.

Problém je v nalezení rovnováhy mezi jednoduchým přednačtením celého souboru - což může být velké plýtvání - a přednačítáním podmnožiny stránek, které se používají nejčastěji. Pro rozhodnutí je potřeba nějakou heuristiku. Jak Ulrich zdůraznil, zaznamenávání celé doby běhu programu vyústí v to, že budou označeny všechny stránky v programu (pokud nemáte v binárce spoustu mrtvého kódu a ten je všechen nahromaděný na jednom místě).

Místo, kde Ulrich vidí potřebu pro podporu ze strany jádra, je poskytnutí bitmapového rozhraní madvise(), aby se všechny díry ve stránkách, které se přednačtou, nevyplnily mechanismem dopředného čtení [readahead]. Současné rozhraní by vyžadovalo volání madvise() pro každou spojitou oblast, což by mohlo vést ke značnému počtu těchto volání. On i Andrew straní tomu, aby se většina práce odehrávala v uživatelském prostoru.

Celkově je potřeba udělat spoustu práce předtím, než se "prediktivní bitové mapy" dostanou do Linuxu - pokud se tam vůbec dostanou. Pro začátek je potřeba udělat nějaké benchmarky, které by ukázaly, že se výkonnost zlepší dostatečně na to, aby stálo za to takovou změnu udělat. David Miller se o tomto přístupu vyjádřil pesimisticky:

Takový patch jsem napsal už dávno.

Upřímně - podle mých zkušeností tenkrát a toho, co vím teď, si myslím, že je ztráta času se o to snažit.

I tak jde o zajímavý nápad, takový, který pravděpodobně vyraší znovu, jestliže tato konkrétní inkarnace nikam nedojde. Na druhou stranu, jelikož největší zisk efektivity pochází z omezení vyhledávání na disku, z dlouhodobého hlediska to tak zajímavé není. Jak řekl Andrew, solid-state disky připraví spoustu kódu o práci.

Atomický kontext a design API jádra

API by se mělo zdržet slibování něčeho, co nemůže splnit. Nedávná epizoda jaderného makra in_atomic() demonstruje, jak se věci mohou pokazit, když funkce nedělá to, co se zdá, že dělá. Je to také dobrý důvod podívat se na nedostatečně zdokumentovaný (ale důležitý) aspekt designu kódu jádra.

Jaderný kód obecně běží v jednom ze dvou základních kontextů. Kontext procesu vládne, když jádro běží kvůli (obvykle) procesu v uživatelském prostoru; kód, který implementuje systémová volání, je jeden příklad. Když jádro běží v kontextu procesu, je mu povoleno uspat se, pokud je to potřeba. Nicméně pokud jádro běží v atomickém kontextu, věci jako spaní nejsou povoleny. Kód, který obsluhuje hardwarová a softwarová přerušení, je jeden zjevný příklad atomického kontextu.

Je zde však něco navíc - jakmile nějaká jaderná funkce získá spinlock, přesouvá se do atomického kontextu. Vzhledem k tomu, jak jsou spinlocky implementovány, by bylo uspání v době držení spinlocku fatální chyba; pokud by se jiná jaderná funkce pokusila získat stejný zámek, systém by téměř jistě skončil v deadlocku.

"Deadlock navždy" se v seznamu přání uživatelů moc často nevyskytuje, takže se vývojáři jádra snaží této situaci vyhnout, což zahrnuje (1) žádný přístup do uživatelského prostoru a, což je důležitější, (2) žádné spaní. Problémy mohou vzniknout tam, kde konkrétní jaderná funkce neví, ve kterém kontextu může být vyvolána. Klasický příklad je kmalloc() a spol., které přijímají výslovný argument (GFP_KERNEL nebo GFP_ATOMIC) specifikující, jestli se může nebo nemůže spát.

Přání napsat kód, který by fungoval optimálně v obou kontextech, je přesto běžné. Někteří vývojáři ve snaze napsat takový kód mohou snadno zakopnout o následující definice z <linux/hardirq.h>:

/*
 * Are we doing bottom half or hardware interrupt processing?
 * Are we in a softirq context? Interrupt context?
 */
#define in_irq()       (hardirq_count())
#define in_softirq()   (softirq_count())
#define in_interrupt() (irq_count())

#define in_atomic()    ((preempt_count() & ~PREEMPT_ACTIVE) != 0)

Zdálo by se, že in_atomic() by se přesně hodilo každému vývojáři, který se snaží zjistit, jestli se daný kousek kódu potřebuje v daný čas chovat atomickým způsobem. Rychlý grep zdrojových kódu jádra ukazuje, že in_atomic() byl přesně k tomuto účelu na několika místech jádra použit. Problém je jenom jeden: tato použití jsou téměř určitě naprosto špatná.

Makro in_atomic() funguje tak, že zjistí, jestli je zakázaná preempce, což se zdá jako správná věc. Obsluhy událostí stejně jako hardwarová přerušení zakáží preempci, ale to udělá i získání spinlocku. Takže se zdá, že tento test zachytí všechny případy, kdy by uspání bylo špatný nápad. Značné množství lidí, kteří se na toto makro podívali, zcela jistě dospělo k tomuto závěru.

Jenže pokud preempce vůbec nebyla v jádře zapnuta, jádro nezvyšuje "počet preempcí" [preemption count], když je získán spinlock. Takže v takové situaci (která je běžná - mnoho distributorů stále preempci ve svých jádrech nezapnulo) nemá in_atomic() žádnou možnost zjistit, jestli volající kód drží nějaký spinlock, nebo ne. Proto vrátí nulu (indikuje kontext procesu), i když jsou drženy spinlocky. To může vést jaderný kód k tomu, aby si myslel, že běží v kontextu procesu (a choval se podle toho), i když to tak není.

Vzhledem k tomuto problému by se dalo pozastavit nad tím, proč tato funkce vůbec existuje, proč ji lidé používají a proč se vývojáři vůbec snaží řešit to, jestli mohou spát nebo ne. Andrew Morton zodpověděl první otázku poněkud zamlžujícím způsobem:

in_atomic() slouží pouze k použití v jádře jádra [core kernel]. Protože za zvláštních okolností (např: kmap_atomic()) spouštíme inc_preempt_count() i na ne-preemptivních jádrech, abychom sdělili pro architekturu specifické obsluze selhání, že byla vyvolána funkcí copy_*_user() uvnitř kmap_atomic() a musí selhat.

Jinýmy slovy in_atomic() funguje ve specifické nízkoúrovňové situaci, ale nikdy nebyla určena k použití v širším kontextu. Její umístění v hardirq.h těsně vedle maker, která mohou být použita kdekoliv jinde, bylo tedy téměř určitě chybou. A jak podotkl Alan Stern, fakt, že Linux Device Drivers doporučuje použití in_atomic(), situaci vůbec nevylepšil. Jonathan Corbet, autor tohoto článku, doporučuje, aby autoři této knihy okamžitě dostali padáka.

Jakmile budou tyto chyby odstraněny, stále zbude otázka, jak má jaderný kód poznat, jestli běží v atomickém kontextu, nebo ne. Skutečná odpověď je, že prostě nemůže. Opět citujeme Andrewa Mortona:

V jádře používáme konzistentní vzor, že volající sleduje, jestli běží v plánovatelném kontextu, a pokud je to nutné, informuje o tom volaného. Volaní si to sami nezjistí.

Tento vzor je v jádře konzistentní - příklad s GFP_ příznaky to v tomto ohledu jasně ukazuje. Nicméně je také zjevné, že tento způsob nebyl zdokumentován tak, aby vývojáři jádra věděli, že se věci mají dělat takto. Zvažme například tento nedávný příspěvek od Rustyho Russella, který těmto záležitostem rozumí více než jiní:

Tento příznak indikuje, co má alokátor dělat, když žádná paměť není k dispozici: má počkat (spát) dokud není paměť uvolněna nebo odswappována (GFP_KERNEL), nebo má okamžitě vrátit NULL (GFP_ATOMIC). A tento příznak je zcela redundantní: kmalloc() dokáže sám o sobě zjistit, jestli může spát, nebo ne.

Ve skutečnosti kmalloc() nemůže sám zjistit, jestli je spaní dovoleno nebo ne. Musí mu to být řečeno volajícím. Změna tohoto pravidla je nepravděpodobná, takže očekávejme sérii patchů odstraňujících in_atomic() počínaje jádrem 2.6.26. Jakmile tato práce bude hotova, makro in_atomic() může být přesunuto na bezpečnější místo, kde nebude způsobovat další zmatek.

       

Komentáře

[Jakub Lucký]

Řekl bych, že jsem měla radši, když na mě lidi prostě prázdně koukali poté, co jsem jim řekla, co dělám.

Trochu rozdílné rody

Jinak díky za každý další díl ;)

[Luboš Doležel (Doli)]

Opraveno, díky.

[Marex]

s/nápade\./nápadem\./

[ashen]

Hlavne je zajimave proc to rekla;o) preklad - Predala jsem ji svou vizitku a ona rekla 'Linux ...neni to ta vec, kterou zacal ten typek Hans co zabil svou zenu v Oaklandu?'

Řekla bych, že jsem měla radši, když na mě lidi prostě prázdně koukali poté, co jsem jim řekla, co dělám.

[Robert Krátký]

Trochu rozdílné rody

Oops, to první sloveso mi proklouzlo.

[Jakub Lucký]

Kernel Oops? ;)

[Filip Jirsák]

Ještě jeden překlep: kdy by uspání bylo špatný nápade.

[Jary]

Taky děkuju. Skvělý seriál.

[MiK]

diky za kazdy novy dil... ale tento je starsi nez vcerejsi :) je to tak v poradku?

[Robert Krátký]

V pořádku to není, ale chyba také ne. Vydáváme dva druhy JN. Jedny mají jako zdroj články z kerneltrap.org, druhé články z LWN.net. Ty z LWN.net mají bohužel zatím trochu větší zpoždění než ty z kerneltrap.org.

[Jary]

jinak řečeno "je to feature". Hmm, tohle zní jako mem.

[Robert Krátký]

Je to feature, které se snažíme rychle zbavit.

[KS]

Tohle je super seriál, díky za každý nový díl.

[newman]

> ...fakt, že Linux Device Drivers doporučuje použití in_atomic(), 
> situaci vůbec nevylepšil. Jonathan Corbet, autor tohoto 
> článku, doporučuje, aby autoři této knihy okamžitě dostali padáka.

Linux Device Drivers Authors: Jonathan Corbet, Alessandro Rubini, Greg Kroah-Hartman

:)