Jaderné noviny - 28. 5. 2008

11. 7. 2008 | Jirka Bourek | Jaderné noviny | 4123×

Aktuální verze jádra: 2.6.26-rc4. Citáty týdne: Alan Cox, James Bottomley, Andrew Morton. Reakce na poškození žurnálu ext4. Používání zavaděče firmwaru pro statická data. GEM vs. TTM.

Obsah

• Aktuální verze jádra: 2.6.26-rc4
• Citáty týdne: Alan Cox, James Bottomley, Andrew Morton
• Reakce na poškození žurnálu ext4
• Používání zavaděče firmwaru pro statická data
• GEM vs. TTM

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

Současné vývojové jádro 2.6 je 2.6.26-rc4 vydané 26. května. K obvyklým opravám se přidává několik aktualizací ovladačů v různých oblastech: DRI, síťování, MMC, USB, watchdog a IDE. Také je v něm oprava 32bitového jádra u x68 pro uživatele, kteří mají ve svých strojích "příliš mnoho paměti." Takže pokud jste měli povolené PAE a dostatečně nové CPU, které má NX, ale ne dost nové na to, aby bylo 64bitové (nebo jste byli prostě perverzní a chtěli provozovat 32bitové jádro na čipu, který umí pracovat 64bitově, a přitom měli tolik paměti, že jste rozhodně měli použít 64bitové jádro), objevovaly se vám různé náhodné pády programů se SIGSEGV. To se dělo v rozsahu od nestartujících X po nefungující OpenOffice, pokud X nastartovala. Jako vždy lze všechny ty nechutné detaily nalézt v dlouhém changelogu.

Citáty týdne: Alan Cox, James Bottomley, Andrew Morton

Test zatížením zde obvykle není k ničemu - věci jako souběhy ioctl najdete tak, že máte zlé myšlenky.

-- Alan Cox

Podle mého názoru je největší problém v tom, že když na začátečníky lijeme vitriol jako tady, poškozujeme svou reputaci komunity, která vítá nově příchozí, a omezujeme tak zásobu ochotných dobrovolníků. Na druhou stranu z pohledu správce - když na mě lidé křičí kvůli nezahrnutému patchi a trvajícím seznamu regresí a asi deseti chybovým hlášením, které je potřeba vysledovat, poslední věc, kterou chci vidět v okolí miliónu mil od své schránky, je patch, který opravuje bílé znaky. Čím víc takových patchů dostáváme, tím je problém horší a tím kratší a zápalnější jsou odpovědi. Takhle to nemůže pokračovat.

-- James Bottomley

Projekt č.1 pro všechny začátečníky v jádře by určitě měl být "zajistit, že jádro vždy běží perfektně na všech strojích, ke kterým se dostanou." Obvyklým způsobem, jak toho dosáhnout, je spolupracovat s ostatními na tom, aby byly věci opravovány (to může vyžadovat vytrvalost!), což je v pořádku - je to část vývoje jádra.

-- Andrew Morton

Reakce na poškození žurnálu ext4

Článek o bariérách z minulého týdne popsal jeden způsob, jak se mohou věci pokazit u žurnálovacích souborových systémů. Bylo v něm psáno, že vlastnost kontrolního součtu žurnálu přidaná do souborového systému ext4 by zmírnila některé z těchto problémů tím, že by se zabránilo použití žurnálu, pokud nebyl před pádem zcela zapsán. Nicméně, jak ukazuje diskuze z tohoto týdne, situace není tak úplně jednoduchá.

Ted Ts'o dělal nějaké testy u ext4, když si všiml problému s tím, jak je řešen kontrolní součet žurnálu. Žurnál obvykle obsahuje několik transakcí, které ještě nebyly v souborovém systému zcela dokončeny. Každá z těchto transakcí zahrnuje záznam vykonání [commit record], který mimo jiné obsahuje kontrolní součet transakce. Jestliže kontrolní součet souhlasí se skutečnými daty transakce v žurnálu, systém ví, že byly zapsány kompletně a bez chyb; mělo by tudíž být bezpečné je provést v souborovém systému.

Problém, kterého si všiml Ted, je tento: jestliže u transakce uprostřed série nesouhlasí kontrolní součet, přehrání [playback] žurnálu se zastaví - ale až po zápisu poškozené transakce do souborového systému. To je v podstatě scénář "to nejhorší ze všech světů": jádro zapíše data, o kterých se ví, že jsou poškozená, do souborového systému a pak tiše zahodí (pravděpodobně dobré) transakce za tou poškozenou. Vývojáři ext4 rychle došli ke konsenzu, že toto chování je chybné a mělo by se opravit.

Co by ale mělo být uděláno místo toho, není tak jasné, jak by si jeden mohl myslet. Ted navrhoval toto:

Myslím si, že správná věc, je znovu přehrát celý žurnál, včetně těch commitů s nesouhlasícími kontrolními součty (kromě případu, kde je povolené journal_async_commit a poslední commit má špatný kontrolní součet, ve kterém bychom vynechali poslední transakci). Přehráním [Replaying] celého žurnálu zabráníme ztrátě odřeknutých bloků [revoke blocks], což je nutné, abychom nepřepsali žádné datové bloky; přehráním následujících bloků metadat se pravděpodobně dostaneme do mnohem lepší pozice, ze které bude e2fsck schopný souborový systém obnovit.

K pochopení problému, který se Ted pokouší řešit, může pomoci několik informací z pozadí. Ve výchozím režimu data=ordered ext3 a ext4 nezapíší všechna data do žurnálu předtím, než jdou do samotného souborového systému. Místo toho se do žurnálu zapisují jenom metadata souborového systému; datové bloky se zapisují přímo. "Ordered" znamená, že všechny datové bloky jsou zapsány předtím, že než kód souborového systému začne zapisovat metadata; tímto způsobem metadata vždy popisují kompletní a správný souborový systém.

Nyní si představme žurnál, který obsahuje sadu transakcí podobnou téhle (v daném pořadí):

1. Je vytvořen soubor společně s metadaty, která k němu patří.
2. Tento soubor je pak vymazán a jeho bloky metadat jsou uvolněny.
3. Jiný soubor je prodloužen a nově uvolněné bloky metadat se znovu použijí jako datové bloky.

Dále si představme, že systém zhavaruje s těmito transakcemi v žurnálu, ale transakce 2 je poškozená. Jednoduché přeskočení špatné transakce a opakování transakce 3 povede k největšímu zmatení souborového systému, co se týče stavu znovupoužitých bloků. Nicméně zastavení se u poškozené transakce také znamená problém: datové bloky vytvořené v transakci 3 možná již byly zapsány, ale kvůli transakci 1 si souborový systém myslí, že jsou to bloky metadat. To také vede na poškozený souborový systém. Opakováním celého žurnálu, doufá Ted, by se taková situace mohla zachytit a souborový systém by byl v celkové lepším stavu.

Pravděpodobně není překvapení, že tento způsob vyvolal nějaký nesouhlas. Andreas Dilger argumentoval:

Jediným důvodem tohoto patche bylo vyhnout se případu, kdy je v žurnálu zapsán náhodný bordel, aby se nerozsypal po celém souborovém systému. Vzhledem k tomu, že žurnál má největší hustotu pro souborový systém důležitých metadat, je v podstatě nemožné mít někde vážnější poškození než v žurnálu.

Dalším návrhem bylo změnit formát žurnálu na disku ("ještě jednou") a změnit kontrolní součet transakce na kontrolní součet bloků. Potom by bylo možné zjistit, jak významné poškození je a i poškozené transakce by většinou šlo opakovat. V době psaní tohoto článku se zdá, že byl zvolen tento postup.

Dá se říci, že skutečný závěr této diskuze nejlépe vyjádřil Arjan van de Ven ve zcela jiném kontextu: mít žurnál patří do roku 1999. Souborový systém Btrfs, u kterého je slušná šance, že za pár let nahradí ext3 a ext4, žurnál nemá; místo toho používá mechanismus rychlých snapshotů, kterým udržuje transakce konzistentní. Btrfs by se tímto mohl vyhnout některým problémům, které žurnálování přináší - i když možná za cenu zavedení zajímavých nových problémů.

Používání zavaděče firmwaru pro statická data

Některé ovladače zařízení potřebují při inicializaci do hardwaru nahrát firmware. Existuje rozhraní jaderného zavaděče firmwaru [firmware loader], které tuto funkci podporuje, ale potřebuje k tomu pomoc z uživatelského prostoru, a ta nemusí být ve všech prostředích k dispozici. David Woodhouse navrhl patch, který by tuto potřebu eliminoval, takže by zavaděč firmwaru mohlo použít víc ovladačů místo toho, aby si vytvářely svá vlastní řešení.

Embedded zařízení budou jedním z hlavních uživatelů této schopnosti. Mnoho z nich nemá v čase bootu k dispozici souborový systém (v initrd nebo initramfs) pro uživatelský prostor, ale stejně potřebují přistoupit k obrazům firmwaru, aby je nahrála do periférií. Nová implementace request_firmware() by takovým zařízením umožnila připojit firmware do jádra a přitom by se stále používala jaderná infrastruktura pro firmware.

David sepsal skvělé shrnutí toho, o co se snaží, když zaslal patch:

Některé ovladače mají své vlastní hacky, které obcházejí jaderný zavaděč a připojují firmware do jádra; ty nebudou potřeba.

Jiné ovladače nepoužívají zavaděč firmwaru vůbec, protože vždy chtějí, aby byl firmware k dispozici. Tohle jim umožní začít zavaděč používat.

Třetí druh ovladačů již používá zavaděč firmwaru, ale nemůže se obejít bez pomoci z uživatelského prostoru, což občas vyžaduje initrd. Toto jim umožní fungovat i ve statickém jádru.

Ovladač, který má statická data firmwaru, je deklaruje:

DECLARE_BUILTIN_FIRMWARE("firmware_name", blob);

firmware_name se používá jako klíč pro nalezení specifického firmwaru, když je volána request_firmware(). blob je ukazatel na skutečný kód. Deklarace přidává firmware na konec pole udržujícího prvky struct builtin_fw, které vypadají takto:

struct builtin_fw {
        char *name;
        void *data;
        unsigned long size;
};

Když je voláno request_firmware(), nový kód lineárně prochází pole a hledá odpovídající klíč předtím, než volá uživatelský prostor. To umožňuje, aby měly staticky vytvořené bloby firmwaru přednost před těmi, které jsou v souborovém systému. Ten firmware, který je nalezen, je vrácen.

Zdálo se, že panuje všeobecný souhlas, že Davidův přístup správný. Jeho původní implementace zkopírovala blob firmwaru před vrácením tam, kde bylo voláno request_firmware(), což vyžadovalo vmalloc() - plýtvání na embedded zařízeních vzácnou pamětí. David měl obavy, že některé ovladače by mohly firmware modifikovat před nahráním do zařízení. Po nějakém hledání našel i příklady tohoto chování, ale místo penalizace všech zařízení změnil vrácená data firmwaru tak, že struct firmware je konstantní, což vedlo k následující struktuře:

struct firmware {
        size_t size;
        const u8 *data;
};

To znamená změnu API pro každého, kdo používá rozhraní request_firmware(). Ovladače ve stromě David příslušným způsobem modifikoval, ale autoři ovladačů mimo strom se musí této změně přizpůsobit sami. Každý ovladač, který potřebuje data modifikovat, si pro sebe musí vytvořit kopii.

Další vlastností, která by se mohla hodit na zařízeních s omezenou pamětí, je komprese firmwaru v obrazu jádra. David na to myslí, ale nepovažuje to za vlastnost, která by musela být v prvním vydání. Nekopírování dat pro většinu ovladačů je větší vítězství, i když komprese, obzvláště pro velké obrazy firmwaru, by mohla pomoci. V takových případech by však v paměti byla zároveň komprimovaná i nekomprimovaná data v době, kdy by je ovladač nahrával.

Bylo diskutováno zahrnutí této práce do 2.6.26, i když je začleňovací okno uzavřené. David si myslí, že by to mohlo být možné:

Fajn, je na to asi pozdě, ale je to strašně jednoduché a nemělo by to mít možnost cokoliv rozbít, takže bych řekl, že pokud nezačleníme patch korg1212 a zbytek podobných patchů, na kterých ještě pracujeme, není to tak šílený požadavek.

Jde o vcelku jednoduchý patch, který přidává velmi užitečnou funkci - obzvlášť pro komunitu okolo embedded zařízení. David se nedávno stal jedním z jaderných embedded vývojářů, takže v budoucnosti od něj možná uvidíme více podobných věcí. Je nepravděpodobné, že Linus Torvalds tuto vlastnost začlení tak pozdě v cyklu 2.6.26, ale začlenění do 2.6.27 se zdá být vcelku nasnadě.

GEM vs. TTM

Donutit třírozměrnou grafiku s vysokým výkonem k fungování pod Linuxem je značná výzva, i když jsou k dispozici základní informace o programování hardwaru. Jednou částí tohoto problému je správa paměti: grafický procesor (GPU) je v podstatě počítač s jiným pohledem na paměť. Správa paměti GPU - a jeho pohledu na systémovou paměť - se musí provádět opatrně, pokud má výsledný systém vůbec fungovat, natož aby měl akceptovatelný výkon.

Před nedávnem se zdálo, že problém byl vyřešen subsystémem map překládacích tabulek [translation table maps, TTM]. TTM nicméně zůstává mimo hlavní řadu jádra stejně jako všechny ovladače, které ho používají. Nedávný dotaz na to, co by bylo potřeba, aby byl TTM začleněn, vedl k zajímavé diskuzi, kde se ukázalo, že ve skutečnosti TTM vůbec nemusí být budoucností správy grafické paměti.

Objevilo se mnoho stížností na TTM. Jeho API je mnohem větší, než je pro jakýkoliv ovladač v Linuxu potřeba; jinými slovy má určité množství kódu určeného pro potřeby binárních ovladačů. Oplocující mechanismus (který řeší souběhy mezi hostitelským CPU a GPU) je považován za komplexní, obtížně se s ním pracuje a ne vždy poskytuje největší výkon. Značné používání paměťově mapovaných zásobníků může vytvořit problémy s výkonem samo o sobě. TTM API je lekce v poskytnutí čehokoliv ve všech situacích; ve výsledku je podle některých vývojářů ovladačů těžké ho použít na jakémkoliv existujícím hardwaru, těžké s ním začít a stejně je nedostatečné flexibilní. A, což je důležité, je výrazný nedostatek fungujících svobodných ovladačů, které TTM používají. Proto se Dave Airlie obává:

Doufal jsem, že jeden z ovladačů nouveau nebo radeon TTM použijí nebo alespoň udělají nějaké funkční demo, které by ho používalo. K tomu nedošlo a z toho mám obavy... Skutečná otázka je, jestli se TTM hodí autorům ovladačů v prostředí linuxových desktopů a embedded zařízení. Řekl bych, že doteď ze strany desktopů nevidím dostatek kladné zpětné vazby.

Všechny tyto obavy by se mohly zdát zbytečné, protože TTM je k dispozici a nic jiného není. Až na to, že se ukázalo, že něco jiného je: jmenuje se to Správce grafického zpracování [Graphics Execution Manager, GEM]. V době psaní tohoto článku je Intelem sponzorovaný projekt GEM měsíc starý. Vývojáři GEM ještě neměli v úmyslu svou práci oznámit, ale diskuze o TTM tuto záležitost posunulo do popředí.

Úvod do GEM od Keitha Packarda zahrnuje dokument popisující API tak, jak momentálně existuje. Je v něm mnoho významných rozdílů v tom, jak GEM provádí některé věci. Pro začátek GEM alokuje objekty grafických zásobníků při použití normální, anonymní paměti z uživatelského prostoru. To znamená, že tyto zásobníky mohou být odswapovány, když bude málo paměti. Tento přístup má zjevné výhody a nejen ve flexibilitě paměti: také zjednodušuje implementaci suspendu a resume tím, že automaticky poskytuje záložní paměť pro všechny objekty zásobníků.

API GEM se snaží odstranit mapování bufferů do uživatelského prostoru. Toto mapování je drahé a přináší s sebou všechny možné druhy zajímavých záležitostí, jako je koherence cache mezi CPU a GPU. Místo toho je k objektům zásobníků přistupováno jednoduchými voláními read() a write(). Nebo by to tak přinejmenším bylo, kdyby vývojáři GEM mohli připojit popisovač souboru ke každému objektu zásobníku. Jádro nicméně neumožňuje jednoduchou správu tak velkého množství popisovačů (zatím), takže skutečné API používá oddělené manipulátory [handle] pro objekty zásobníků a sadu volání ioctl().

To znamená, že je možné mapovat objekty zásobníků do uživatelského prostoru. Pak ale ovladač v uživatelském prostoru musí převzít jasnou zodpovědnost za správu koherence cache. Za tím účelem je zde sada ioctl() volání pro správu "domény" zásobníku; doména zjednodušeně popisuje, která komponenta v systému vlastní zásobník a je oprávněna s ním pracovat. Změna domén (jsou dvě, jedna pro přístup ke čtení, druhá pro zápis) zásobníku provede potřebné vyprázdnění cache [cache flush]. V jistém smyslu tento mechanismus připomíná API proudového DMA [streaming DMA], kde je možné měnit vlastnictví DMA zásobníku mezi CPU a periférií. To není příliš překvapivé, neboť je zde řešen velmi podobný problém.

Toto API také odstraňuje potřebu pro explicitní ohraničující operace. Místo toho operace CPU, která vyžaduje přístup do zásobníku, jednoduše počká, pokud je to potřeba, než GPU dokončí všechny probíhající operace, které se daného zásobníku týkají.

A nakonec: GEM API se nesnaží vyřešit celý problém; mnoho důležitých operací (jako je vykonání sady příkazů pro GPU) jsou ponechány k implementaci v ovladači specifickém pro hardware. GEM je tedy vcelku specifický pro potřeby ovladačů Intelu; nesnaží se o stejnou obecnost, jaká byla cílem TTM. Jak popsal Eric Anholt:

Problém v TTM spočívá v tom, že je určeno k vytvoření jednoho obecného API pro všechen hardware, přičemž to není to, co by naše ovladače chtěly... My se snažíme přistoupit k tomu jiným směrem: implementovat jeden ovladač dobře. Když někdo jiný implementuje jiný ovladač a zjistí se, že je zde kód, který by měl být společný, vložit ho do podpůrné knihovny a sdílet ho.

Výhodou tohoto přístupu je, že umožňuje relativně jednoduše vytvořit něco, co dobře funguje s ovladači od Intelu. A to by mohl být dobrý začátek; jedna fungující sada ovladačů je lepší než žádná. Na druhou stranu to znamená, že může být potřeba významné množství práce, aby se GEM dostal do bodu, kdy bude moci podporovat ovladače pro jiný hardware. Zdají se být dva úhly pohledu na to, jak se to dá udělat: (1) přidat do GEM schopnosti, když je další ovladače budou potřebovat, nebo (2) nechat každý ovladač používat vlastního správce paměti.

První přístup je v mnoha ohledech příjemnější. Plyne z něj ale požadavek na to, aby se postupem času mohlo GEM API významně měnit. A to může zase zpozdit začlenění celé věci; GEM API je exportováno do uživatelského prostoru, takže musí zůstat kompatibilní, i když se bude měnit. Proto se může objevit odpor k rychlému začlenění API, které vypadá, že se postupem času může ještě vyvíjet.

Druhý přístup nejlépe popsal Dave Airlie:

Nemůžu uvěřit, že bychom nevěděli dost na to, abychom byli schopni to udělat nějak obecně, ale možná tahle záležitost TTM vs. GEM dokazuje, že to možné není. Můžeme se tedy držet toho, že každý ovladač bude mít svého správce paměti, ale mám podezření, že to bude noční můra pro údržbu. Takže jestli se lidé rozhodnou, že toto je cesta kupředu, rád to uvidím, nicméně osoba zasílající správce paměti číslo n+1 musí být hodně ochotná stát za tím rozhraním do konce světa a vysvětlit, proč nemůže použít jednoho ze správců paměti 1..n.

Jednou ze zbývajících záležitostí je výkon. Keith Whitwell zaslal nějaké výsledky benchmarků, které ukazují, že ovladač i915 se chová významně hůře s TTM i s GEM než bez nich. Keith Packard nicméně získal jiné výsledky; jeho testy ukazují, že ovladač založený na GEM je významně rychlejší. Zjevně je potřeba sada konzistentních benchmarků; výkonnost grafických ovladačů je důležitá, ale nelze ji optimalizovat, pokud nemáme způsob, jak ji spolehlivě měřit.

Použití anonymní paměti také vyvolává nějaké obavy o výkonnost: FPS střílečka neposkytne stejný zážitek, když bude nutné její krvavé textury neustále stránkovat. Anonymní paměť také může být v horní paměti a tím pádem nedostupná přes 32bitový ukazatel. Některý GPU hardware neumí adresovat horní paměť, což v jádře pravděpodobně vynutí použití přeskakujících zásobníků [bounce buffers]. GEM bude muset dokázat, že může poskytnout vysokou výkonnost; jeho vývojáři jsou vysoce motivováni k tomu, aby jejich hardware vypadal dobře, takže je rozumná šance, že se na této frontě věci pohnou.

Závěrem toho všeho je, že problém správy GPU paměti nemůže být považován za vyřešený. GEM se nakonec může stát řešením, ale je to velmi nové API, které vyžaduje značné množství práce.

(Díky Timovi Jyrinki za doporučení tohoto tématu.)

       

Komentáře

[trekker.dk]

k tomu pomoc z uživatelského prostoru, a ta nemusí být ve všech prostředích k dispozici.

Čárka před a je IMO navíc.

[Marek Bečka]

oprava 32bitového jádra u x68

Malá chyba v architektúre.

[TT]

Zdravím,

zarazili mne patche na bílé znaky - whitespace asi v originále - a pak bych to překládal jako prázdná místa ... :)

TT

[Robert Krátký]

Jasně. Opr.

[DjAARA]

Označení bílé znaky se běžně používá.

[Tomas]

jj, je to rozhodne standardnejsi preklad nez prazdna mista (IMHO nesmysl, protoze nejsou prazdna, jsou tam prece ty mezery a tabulatory )

Az z tohohle komentare jsem pochopil na co vlastne ty patche byly.

[trekker.dk]

Přesně tak.

[Robert Krátký]

Hergot...

[Filip Jirsák]

…i když možná za cenu zavedení zajímavých nových problémů…

Asi bych spíš napsal „i když možná za cenu zavlečení zajímavých nových problémů“.