AbcLinuxu:/ Články / Jaderné noviny - 25. 2. 2009

Štítky: jádro, Linux, multimédia, programování, video, V4L

Jaderné noviny - 25. 2. 2009

26. 3. 2009 | Jirka Bourek | Jaderné noviny | 3301×

Aktuální verze jádra: 2.6.29-rc6. Citáty týdne: Ted Ts'o, Casey Schaufler, Andrew Morton. Zrychlování alokátoru stránek. Kontrolní bod/restart se snaží mířit do hlavní řady. O správě subsystémového stromu Video4Linux.

Obsah

Aktuální verze jádra: 2.6.29-rc6
Citáty týdne: Ted Ts'o, Casey Schaufler, Andrew Morton
Zrychlování alokátoru stránek
Kontrolní bod/restart se snaží mířit do hlavní řady
O správě subsystémového stromu Video4Linux

Aktuální verze jádra: 2.6.29-rc6

link

Současné vývojové jádro 2.6 je 2.6.29-rc6 vydané 22 února. Seznam změn je stále poměrně dlouhý, ale s trochou štěstí jsou problémy opravovány. Zkrácený changelog vizte v oznámení, všechny detaily obsahuje kompletní changelog.

V době psaní tohoto článku si do repozitáře hlavní řady našlo cestu několik po-rc6 patchů. Obsahují více oprav, ale také nové ovladače pro gigabitové ethernetové adaptéry Atheros L1C a IEEE1394 adaptéry FireDTV.

Současné stabilní jádro 2.6 je 2.6.28.7 vydané (bez oznámení) 20. února. Obsahuje obvyklý dlouhý seznam oprav, mnoho z nich je pro souborový systém ext4; changelog obsahuje detaily. 20. bylo vydáno i 2.6.27.19, také bez oznámení; seznam patchů, které obsahuje, vizte v changelogu.

Citáty týdne: Ted Ts'o, Casey Schaufler, Andrew Morton

link

Obzvláště u vývojářů, kteří do projektu začínají posílat patche, je ojedinělé, když je patch dostatečně kvalitní, aby ho bylo možné přímo aplikovat do repozitáře bez oprav nějakého druhu. Patch nemívá správný styl kódu vzhledem ke kódu, který ho obklopuje, může obsahovat zásadní chyby, protože odesílatel kódu plně neporozuměl. Ve většině případů, když mi někdo pošle patch, je užitečnější jako ukazatel na místo, kde je chyba, než jako cokoliv jiného. Často musím patch kompletně přepsat předtím, než se dostane do repozitáře hlavní řady e2fsprogs.

-- Ted Ts'o

Osobně pokládám názor, že by síťová komunikace měla být vyjmuta z řízení přístupu, za hanebný. Skláním se ale před vůlí lidu.

-- Casey Schaufler

Lepší přístup by byl navrhnout jednoduchá, robustní jaderná rozhraní, která dávají smysl a nejsou komplexní kvůli tomu, že se uživatelská rozhraní dávají do jaderného prostoru. A také spravovat odpovídající nástroje pro uživatelský prostor, které by ovládaly a zobrazovaly IO z těchto jaderných rozhraní

Ale to neděláme, protože uživatelský prostor je složitý, protože nemáme způsob, jak to dodat. Ale nikdo se o to ani nepokusil!

-- Andrew Morton

Zrychlování alokátoru stránek

link

Jaderná operace, která nezahrnuje alokaci a uvolňování paměti, je poměrně vzácná. Kromě veškeré správy paměti, která je typická pro složitější systém, musí být jaderný kód psán s ohledem na extrémně přísná omezení na zásobník. Výsledkem je, že proměnné, které by v kódu v uživatelském prostoru obvykle byly deklarovány jako automatické (zásobníkové), vyžadují v jádře dynamickou alokaci. Efektivita subsystému správy paměti má tudíž významný vliv na výkonnost systému jako celku. To je důvod, proč má jádro v současnosti tři alokátory na slab úrovni (původní slab alokátor, SLOB a SLUB), přičemž další (SLQB) čeká na otevření začleňovacího okna 2.6.30. Doposud nikdo nebyl schopen vytvořit jediný slab alokátor, který by poskytoval ve všech situacích nejlepší výkonnost, přičemž v sázce je dost na to, aby stálo za to se o to pokoušet.

I když je mnoho jaderných alokací paměti provedeno na úrovni slabů (použitím kmem_cache_alloc() nebo kmalloc()), pod slab alokátory je další vrstva správy paměti. Na konci se veškerá správa dynamické paměti setkává u alokátoru stránek, který paměť rozdává po celých stránkách. Alokátor stránek musí paměť spravovat tak, aby se příliš nefragmentovala; také musí řešit detaily, jako je afinita k uzlu CPU či NUMA, přístupnost pro DMA a jestli lze použít horní paměť [high memory]. Zjevně také musí být rychlý; pokud zpomaluje, není toho moc, co mohou vyšší úrovně udělat, aby se situace zlepšila. Vzhledem k tomu by měli všichni věnovat pozornost tomu, co napsal hacker správy paměti Mel Gorman:

Složitost alokátoru stránek po nějaký čas roste a nyní se dostala do bodu, kdy SLUB alokátor používá podivné triky, aby se alokátoru stránek vyhnul. To je zjevně špatně, protože to může povzbudit ostatní subsystémy, aby se mu vyhnuly také.

Jak by se dalo očekávat, Mel přišel se sadou patchů, které mají za cíl zrychlit alokátor stránek a odstranit pokušení ho obcházet. Výsledkem je, zdá se, významné pročištění kódu a skutečné zlepšení ve výkonnosti; patche také ukazují, jaký druh práce je potřeba k udržení nepostradatelného subsystému v perfektním stavu.

Melův patch o dvaceti částech (připojený u citace výše) na problém útočí několika způsoby. Mnoho z nich jsou malá ladění; například vnitřní funkce pro alokaci stránky (alloc_pages_node()) obsahuje následující test:

if (unlikely(order >= MAX_ORDER))
    return NULL;

Jak ale říká Mel, žádný slušný uživatel alokátoru stránek by v žádném případě neměl alokovat něco, co je větší než MAX_ORDER. Jeho sada patchů proto odstraňuje tento test z kódové cesty alokátoru a nahrazuje ho funkcí v pomalé cestě, která přitahuje mnohem více pozornosti (VM_BUG_ON). Rychlá cesta alokace je o něco málo rychlejší a špatné použití rozhraní bude stejně podchyceno (a objeví se stížnost).

Pak je zde malá funkce gfp_zone(), která přebírá příznaky předané požadavkem na alokaci a rozhoduje se, ze které oblasti paměti se pokoušet alokovat. Různé požadavky je potřeba uspokojovat z různých oblastí paměti v závislosti na faktorech jako, jestli bude paměť používána pro DMA, jestli je možné použít horní paměť nebo jestli je možné paměť přesunout za účelem defragmentace. Současný kód tento test provádí pomocí série čtyř if, ale spousta skoků může být v rychlém kódu drahá. Melův patch tedy testy nahrazuje vyhledáváním v tabulce.

Mnoho dalších změn je podobných - zdánlivé mikrooptimalizace, se kterými by se normálně nikdo neobtěžoval. V rychlém kódu hluboko uvnitř systému nicméně stojí za to se zabývat i optimalizacemi na této úrovni. Tato sada patchů také věci reorganizuje tak, aby rychlá cesta byla explicitnější a spojitá; i to může věci zrychlit, ale také to zajišťuje, že si vývojáři uvědomí, že pracují na kódu kritickém pro výkonnost.

Změna, která vyprovokovala největší diskuzi, je nicméně odstranění rozlišování horkých a studených stránek. Tato vlastnost začleněná do 2.5.45 se pokouší sledovat, které stránky jsou nejpravděpodobněji v cache procesoru. Pokud může alokátor paměti žadateli vrátit horké stránky, výkonnost práce s pamětí by se měla zlepšit. Jak ale Mel poznamenává, ukazuje se, že velmi málo stránek je uvolněno jako "studené" a kvůli tomu jsou obecně rozhodnutí, jestli konkrétní stránku označit jako horkou, nebo jako studenou, snadno zpochybnitelná. Tato vlastnost do alokátoru přidává nějakou složitost, ale zdá se, že výkonnost nevylepšuje, takže se Mel rozhodl ji odstranit. Provedl ale několik benchmarků a usoudil, že ve skutečnosti nemá tušení, jestli tato vlastnost pomáhá nebo ne. Druhá verze patche tedy odstranění horká/studená vynechává, ale toto téma bude v budoucnosti znovu nastoleno.

Mel tvrdí, že má dobré výsledky:

Nechal jsem tohle všechno proběhnout přes profiler a ukázalo se, že cena za alokaci a uvolňování stránky je příjemně snížena, aniž by se nějak drasticky měnilo to, jak alokátor skutečně funguje. Pokud vynechám cenu za nulování stránek, je cena alokace o 25% menší a cena uvolňování o 12% menší. Opět, když vynechám nulování stránky, většinu zbývající ceny způsobují čítače, ladící testy a zakazování přerušení. Samozřejmě, když je potřeba stránku vynulovat, největší cena za alokaci stránky spočívá v jejím nulování.

S touto sadou patchů ukazuje zlepšení mnoho standardních benchmarků v uživatelském prostoru. Revize jsou obecně dobré, takže je šance, že tyto změny by se mohly vyhnout dlouhým zpožděním typickým pro patche správy paměti a zamířit do hlavní řady v relativně blízké budoucnosti. Pak by neměla být žádná omluva pro to snažit se alokátoru stránek vyhnout.

Kontrolní bod/restart se snaží mířit do hlavní řady

link

Při vývoji jádra je vždycky napětí mezi potřebami nové vlastnosti a potřebami jádra jako celku. Projekty obecně z různých důvodů chtějí, aby jejich kód byl začleněn tak rychle, jak je to jenom možné, zatímco zbytek jaderné komunity chce mít pocit, že vlastnost je rozumná, žádaná a, což je možná nejdůležitější, udržovatelná. Současná snaha o začlenění vlastnosti, která by uměla stanovit kontrolní bod procesů a restartovat je, toto napětí zvýrazňuje.

Koncem ledna Oren Laadan zaslal nejnovější verzi svého kódu pro jaderné kontrolní body a restart s poznámkou: Myšleno do -mm. Tyto kontrolní body mají mnoho možných použití, ale jde o extrémně komplexní problém. Orenova současná verze je vcelku minimální, implementuje pouze malou podmnožinu předvídaných vlastností, ale on by se rád dostal k tomu druhu revizí a testování, které je spojené se začleňováním do hlavní řady.

Po dvou týdnech bez mnoha komentářů se další předkladatel, Dave Hansen, zeptal, co, pokud vůbec něco, brání sadě patchů začlenění do -mm. Andrew Morton odpověděl, že měl nějaké obavy, o kterých se před pár měsíci bez závěru klábosilo. Andrewův názor má poměrně velkou váhu - ne nejmenším důvodem pro to je fakt, že provozuje cílový strom. Dívá se do budoucnosti a snaží se zajistit, aby měly patche smysl:

Mám obavu, že tato implementace je tak trochu hračka a že nevíme, jak bude vypadat dostatečně hotová verze. Je tu riziko, že když začleníme hračku, tak buď:

a) budeme muset začlenit neúnosně-složitě-spravovatelný kód, abychom z toho udělali ne-hračku, nebo

b) se rozhodneme, že nezačleníme neúnosně-složitě-spravovatelný kód, takže nám zbude jenom hračka, nebo

c) jednoduše nebudeme schopni vyřešit, jak implementovat chybějící funkce.

Andrew požádal o odpovědi na některé otázky ohledně toho, které vlastnosti jsou v současné implementaci k dispozici, stejně jako o informaci, co je potřeba přidat. Také se zeptal, jestli Oren a Dave mají nějakou představu o tom, jak navrhnout potřebné, ale v současnosti neimplementované vlastnosti. Ve zkratce se snaží vyhnout všem případům, které nastínil. Jako odpověď na další otázky Ingo Molnára Dave nastínil některé nedostatky současné implementace:

Právě teď to není moc užitečné. Aplikace musí být buď specificky navržena, aby to fungovalo, nebo být poměrně malinká, co se jejích schopností týče. Všechny popisovače souborů, které jsou otevřené, lze obnovit pouze v případě, pokud by je do správného stavu bylo možné dostat pomocí jednoduchého open(); lseek();. Proces musí být jednovláknový. Sdílená paměť, hugetlbfs, VM_NONLINEAR nejsou podporovány.

Dave také zaslal podrobnější odpověď na Andrewovy otázky, která ukázala, že zbývá spousta práce. Současný kód například funguje jenom na architektuře x86 a jenom pro základní typy souborů, v podstatě jenom pro běžné soubory a roury. Přirovnal vývoj kontrolního bodu/restartu k vývoji škálovatelnosti jádra; jde o přetrvávající práci, která nikdy nebude hotová:

Máme v úmyslu umožnit kontrolní body pro nejvýznamnější jaderné funkce. Odtud se přesuneme tam, kde budeme (my a naši uživatelé) vidět důležité věci, ale rozhodně nikdy nebudeme hotoví.

Jednou z hlavních obav není to, že zbývá ještě spousta práce, ale že se v ní mohou skrývat problémy, které buď nebudou mít řešení, nebo je bude možné vyřešit jenom velmi rušivými změnami jádra. Matt Mackall se podíval na Davův seznam dalších vlastností, které je potřeba implementovat, a obavy shrnul takto:

Myslím si, že skutečná otázka je tato: kde se skrývají draci? O některých z těchto věcí víme, že jsou problematické. A některé jsou kritické pro kontrolní body typických aplikací. Pokud máte plány a teorie o tom, jak implementovat všechno uvedené výše, fajn. Tenhle seznam ale nedává žádný náhled na to, jestli se máme obávat toho, co číhá za dveřmi.

Je nicméně k dispozici svobodná implementace kontrolních bodů/restartu mimo strom v projektu OpenVZ. OpenVZ je virtualizační schéma, které používá svou vlastní implementaci kontejnerů - odlišnou od té, která je v novějších jádrech - jež podporuje kontrolní body a migraci těchto kontejnerů. Je to ale velký patch, na který se Andrew díval před několika lety a došel k závěru, že pro hlavní řadu není vítaný. Dave považuje OpenVZ za užitečný příklad, ale se všemi informacemi od lidí od OpenVZ a přinejmenším tří dalších projektů se vsadím, že můžeme přijít s něčím lepším.

Inkrementální přístup k implementaci kontrolních bodů je rozumný, ale Andrew má obavu, že začleněním současných patchů by se vývojáři zavázali k začlenění něčeho, co vypadá jako - a je rušivé jako - patche OpenVZ. Ingo je optimističtější: považuje to za důležitou vlastnost bez mnoha dlouhodobých draků. V inkrementálním přístupu nicméně vidí jednu potenciálně problémovou oblast:

Je zde jedna dočasná cena při běhu: rozhodování, jestli "můžeme vytvořit kontrolní bod, nebo ne", které musí udělat jádro, dokud tato vlastnost nebude hotová.

To je, jestli tato vlastnost bude fungovat, krátkodobá záležitost - protože v dlouhodobém měřítku bude možné vytvořit kontrolní bod vždy.

To je jeden z technických problémů, které je v současné sadě patchů potřeba vyřešit: jak proces programově zjistí, jestli je možné vytvořit jeho kontrolní bod? Jestliže proces provedl nějakou akci při běhu na jádře, které nepodporuje kontrolní bod stavu způsobeného touto akcí, je potřeba to zjistit. Ingo navrhl přetížení [overloading] bezpečnostních háčků LSM tak, že provedení dané akce podle potřeby nastaví jednosměrný příznak "nelze vytvořit kontrolní bod". Tento příznak by potom proces nebo nějaký jiný program, který má zájem, mohl přečíst. Přetížení LSM háčků není zcela nekontroverzní, ale háčky jsou v jádře umístěny na mnoha místech, kde jsou potřeba - přidat na stejná místa další volání kvůli kontrolním bodům pravděpodobně neprojde.

Také se objevila otázka, jestli by příznak "nelze vytvořit kontrolní bod" opravdu měl být jednosměrný, když by ho bylo možné vynulovat poté, co se proces vrátí do stavu, ve kterém by bylo možné kontrolní bod vytvořit. Ingo argumentoval, že jednosměrnost příznaku je lepší: funkce, díky které nelze vytvořit kontrolní bod, by měla způsobovat co nejvíc potíží, aby se zajistilo, že se to opraví. Uživatelé, kteří narazí na problémy při snaze vytvořit kontrolní bod svého programu, budou tlačit na to, aby vytváření kontrolního bodu ukládalo i potřebný stav. Jako počáteční bod Dave zaslal jednosměrný příznak založený na tom, jaký druh souboru proces otevřel.

Kontrolní body jsou užitečná vlastnost, kterou by bylo možné využít při migraci procesů na jiné stroje, při hibernaci systému, chránit dlouhoběžící procesy proti pádům jádra či jeho aktualizacím atd. Je to složitý problém, který možná nikdy nebude zcela vyřešen a dotýká se spousty jaderného kódu. Z těchto důvodů je jistě zcela ospravedlnitelná obezřetnost, ale jeden má pocit, že tato vlastnost se nakonec do hlavní řady jádra dostane. Jestli to bude Orenova verze, něco odvozeného od OpenVZ nebo nějaký úplně jiný mechanismus, to se teprve zjistí.

O správě subsystémového stromu Video4Linux

link

Bylo nebylo, vývojová komunita Video4Linux (V4L) byla považována za nesourodou skupinu, která se poflakuje na svém vlastním hřišti a které se nepodařilo implementovat podporu pro mnoho dostupného hardwaru. Časy se změnily; komunita V4L je energická a produktivní, rušivé flamewary z poštovních konferencí zmizely a Linux nyní podporuje velkou část hardwaru, který lze na trhu nalézt. Jak komunita postupuje kupředu, reorganizuje věci na mnoha frontách; kromě jiného pracuje na vytvoření prvního skutečného frameworku pro video zachytávající zařízení. Vývojáři V4L se také dívají na své praktiky správy kódu; během toho narážejí na mnoho záležitostí, kterým čelily i další subsystémy.

Diskuze začala tímto RFC od Hanse Verkuila. Hans upozorňuje na to, že velikost V4L subsystému (který je v drivers/media v jaderných zdrojových kódech) v nedávných letech výrazně vzrostla - v současnosti je 2,5krát větší, než byla v jádře 2.6.16. Tento růst je známkou úspěchu: V4L přidalo vlastnosti a podporu pro obrovské pole nového hardwaru. Jsou zde ale také náklady - jde o spoustu kódu, který je potřeba udržovat.

Jak se tak stává, vývojáři V4L mají tuto údržbu ještě obtížnější, protože do svého stromu zahrnují zpětnou kompatibilitu. Strom, který provozuje správce V4L Mauro Carvalho Chehab nepodporuje pouze současné jádro hlavní řady; lze ho přeložit na jakémkoliv jádře od 2.6.16 dále. To není jednoduchý trik vzhledem k tomu, že většina toho kódu v době 2.6.16 neexistovala. Během této doby došlo k významným změnám vnitřního jaderného API; podpora všech těchto jader vyžaduje komplikovanou strukturu #ifdefů, hlavičky pro kompatibilitu a další. Na udržování této struktury kompatibility je potřeba spousta práce. Tento druh kódu pro kompatibilitu navíc není v jádře hlavní řady vítán, takže musí být před zasíláním do upstreamu odstraňován.

Důvod pro toto chování je relativně jasný: vývojáři V4L chtějí umožnit testerům zkoušet nové ovladače, aniž by je nutili instalovat nejnovější jádra hlavní řady. Jde o stejný důvod, který uvedli vývojáři DRM na Jaderném summitu 2008: umožnit testerům přeložit moduly pro starší jádra jim zjednodušuje život. A to obratem poskytuje současnému kódu více testování. Cena za tuto kompatibilitu je ale vysoká, takže Hans navrhuje několik změn.

Jednou z nich je to, jak je spravován strom subsystému. V současnosti je strom udržován v Mercurial repozitáři, který reprezentuje pouze subsystém V4L (ne celý jaderný strom) a který obsahuje patche pro zpětnou kompatibilitu. Tato organizace interakci s vývojovým procesem jádra mnoha způsoby ztěžuje. Kromě snahy potřebné k udržení zpětné kompatibility oddělený strom ztěžuje integraci patchů napsaných proti hlavní řadě jádra a tento strom nemá způsob, jak obsáhnout patche, které ovlivňují jaderný kód mimo drivers/media. Život by byl jednodušší, kdyby vývojáři mohli jednoduše pracovat proti běžnému stromu hlavní řady.

Hans tedy navrhuje změnit organizaci stromu podle technik vyvinutých projektem ALSA. Správci ALSA (kteří také udržují zpětnou kompatibilitu patchů) používají jako svůj hlavní strom klon gitového repozitáře hlavní řady. Změny pro zpětnou kompatibilitu jsou poté dodatečně vloženy do odděleného stromu, který existuje jenom z tohoto důvodu. Prací proti stromu hlavní řady vývojáři ALSA snáze spolupracují se zbytkem vývojového procesu jádra. Nevýhoda je, že vytvoření zpětně kompatibilního stromu vyžaduje víc práce; tým vývojářů V4L by musel do tohoto cíle vložit úsilí a čas.

To samozřejmě vede k největší otázce: jaká je skutečná hodnota práce na zpětné kompatibilitě a jak daleko zpět by projekt měl jít? Zdá se, že je málo snahy zbavit se kompatibility se staršími jádry úplně; hodnota testerů a vývojářů se zdá být příliš velká. Není ale jasné, jestli je nutné podporovat všechna jádra až k 2.6.16. Jaké je tedy nejstarší jádro, ptá se tedy Hans, které by projekt měl podporovat?

Hans zde má jasný cíl: změny v i2c, které byly začleněny do 2.6.22, vytvářejí hranici, za kterou je dosažení zpětné kompatibility podstatně obtížnější. Pokud by byla jádra před 2.6.22 vyhozena, spousta problémů se zpětnou kompatibilitou by zmizela. Pohodlnost ale není jediná věc, kterou je potřeba mít na paměti, když se vyhazuje nějaká podpora; je také potřeba zvážit, jestli tato změna bude mít významný vliv na počty testerů, kteří mohou s kódem pracovat. Také by bylo dobré stanovit nějakou objektivní politiku zpětné kompatibility, takže by bylo možné se v budoucnu zbavovat podpory starších jader bez rozsáhlých diskuzí.

Navrhovaná politika zní takto: zpětná kompatibilita V4L by měla podporovat nejstarší jádra podporovaná "třemi významnými distribucemi" (Fedora, openSUSE a Ubuntu). V současnosti je náhodou tímto jádrem 2.6.22, které bude v Ubuntu 7.10 podporováno do dubna 2009. (Zajímavé je, že Hans, zdá se, přeskočil vydání 6.06 "Dapper Drake" - podporované do června 2009 - které používá bleeding-edge jádro 2.6.15.) Rychlá anketa, kterou Hans zorganizoval, naznačuje, že proti odstranění podpory pro jádra před 2.6.22 je jenom málo opozice.

Nějaká tu však je: John Pilkington upozorňuje:

Myslím si, že bys měl vzít na vědomí, že komunity mythtv a ATrpms obsahují významný počet lidí, kteří se rozhodli používat sérii CentOS_5 ve snaze získat systémy, které není potřeba přeinstalovávat každých pár měsíců. Doufám, že je nezklameš.

CentOS 5 (stejně jako distribuce RHEL5, ze které je odvozen) je dodáván s jádrem 2.6.18. Zdá se nicméně, že ve vývojové komunitě CentOS nemá příliš sympatií (stejně jako ostatní "podnikové" distribuce). Provozovat distribuci, která má být stabilní po několik let, a chtít přitom podporu nejnovějšího hardwaru se považuje za protichůdné cíle. Zdá se tedy nepravděpodobné, že by byl strom V4L spravován s ohledem na potřeby podnikových distribucí.

Prozatím se nedospělo k žádným skutečným rozhodnutím. Mauro, od kterého by se jako od správce subsystému očekávalo, že jeho hlas bude mít v takovém rozhodování velkou váhu, se v diskuzi ještě neukázal. Vzhledem k nedostatku silné opozice proti tomuto návrhu by nicméně bylo překvapivé, kdyby návrhy nebyly v nějaké podobě přijaty.