Jaderné noviny – 28. 4. 2011: Jednodušší API pro děravé soubory

9. 5. 2011 | Jirka Bourek | Jaderné noviny | 3305×

Aktuální verze jádra: 2.6.39-rc5. Citáty týdne: Casey Schaufler, Andrew Morton, Al Viro. Škálovatelnost dcache a bezpečnostní moduly. Návrat SEEK_HOLE. ARM, DMA a správa paměti.

Obsah

• Aktuální verze jádra: 2.6.39-rc5
• Citáty týdne: Casey Schaufler, Andrew Morton, Al Viro
• Škálovatelnost dcache a bezpečnostní moduly
• Návrat SEEK_HOLE
• ARM, DMA a správa paměti

Aktuální verze jádra: 2.6.39-rc5

Současné vývojové jádro je 2.6.39-rc5 vydané 26. dubna. Linus říká:

Máme o něco méně commitů než v -rc4, což je dobře. Zároveň s tím ale musím vynadat některým lidem za začlenění nějakých pochybných oprav regresí. Bohužel 'lidé', kterým musím vynadat, jsem já, protože -rc5 obsahuje něco, co je technicky regrese, ale je to věc týkající se výkonnosti a je trochu děsivá. Jedná se o patche od Andiho (s nějakými úpravami od Erica), které umožňují procházení cest s RCU, i když je povolený SELinux.

Všechny detaily vizte v kompletním changelogu.

Stabilní aktualizace: 21. dubna vyšla aktualizace 2.6.38.4; 2.6.32.39 a 2.6.33.12 následovaly o den později; všechny obsahují další dlouhý seznam důležitých oprav.

Aktualizace 2.6.27.59 a 2.6.35.13 se revidují v době psaní tohoto článku; lze je očekávat 28. dubna nebo později.

Citáty týdne: Casey Schaufler, Andrew Morton, Al Viro

S tím se nedá nic dělat. Ještě nikdo nenapsal zdvořilou aplikaci, co se používání disku týče. Aplikace jsou jako rackové, hledají volné bloky na disku a křičí „Můj! Můj!“

-- Casey Schaufler

To funguje. Ale Greg by nás při tom mohl přistihnout, takže jsou potřeba nějaké další začlenitelné patche, které tento export potřebují a které Grega uspokojí. (Jinými slovy jsi nucen dělat nějaké pročišťovací práce.)

-- Andrew Morton

Od 25. března jsem byl offline z velmi ošklivého důvodu – prasklý aneurismus v pravé arterii choroidea. Jinými slovy krvácení do mozku. Když to řeknu velmi jemně, měsíc na JIPce nebyl zábavný. A mizerná místní síť taky ne... Podle lidí z nemocnice nedošlo k žádnému neurologickému poškození, což je lepší (pro mě), než se očekávalo.

Není pravděpodobné, že by současný stav vydržel, pokud se pokusím prokopat nějakými 15k zprávami ve schránce; vysoký tlak je zjevně hlavní příčinou opakovaných krvácení.

-- Vítaný návrat Ala Viro

Škálovatelnost dcache a bezpečnostní moduly

napsal Jonathan Corbet, 27. dubna 2011

Sada patchů pro škálovatelnost dentry cache byla začleněna do jádra 2.6.38; funguje tak, že se pokusí vyhledat cestu bez držení jakýchkoliv zámků. To, že struktury dentry budou existovat po celou dobu vyhledávání cesty, zajišťuje mechanismus čtení-kopírování-aktualizace [read-copy-update, RCU]. Tato sada patchů odstranila významný problém škálovatelnosti jádra a významně zlepšila dobu vyhledávání. Až na to, že, jak se ukázalo, vždycky to takhle nefunguje. Do 2.6.39-rc5 byla začleněna sada patchů – ve vývojovém cyklu o dost později, než by jeden očekával – která tento problém pomáhá řešit.

Fakt, že rychlá cesta vyhledávání cesty běží pod RCU, znamená, že žádná operace nesmí blokovat. Jakmile se ukáže, že vyhledávání nelze provést bez blokování (například pokud se záznam o adresáři musí načíst z disku), vyhledávání rychlou cestou se zruší a celý proces začne znovu v pomalém režimu. V kódu v jádře 2.6.38 pouhá přítomnost bezpečnostních modulů stačila k tomu, aby se jádro vždy muselo vrátit k pomalé cestě, a to i když žádný modul není aktivní. Tak to bylo, protože si nikdo nenašel čas ověřit, jestli jsou kontroly inode_permission() v bezpečnostních modulech bezpečné s RCU, nebo ne. Když jsou tedy zapnuty bezpečnostní moduly, výsledkem je nejenom to, že výhody týkající se škálovatelnosti v 2.6.38 nejsou k dispozici; ve skutečnosti kód běží pomaleji než v 2.6.37.

Podnikové distribuce mají tendenci povolit bezpečnostní moduly, takže problémy s výkonností jsou realitou. V reakci na to se Andi Kleen podíval do kódu a zjistil, že zlepšení situace není tak těžké; jeho patche byly počátkem toho, co nakonec bylo začleněno do 2.6.39. Andi začal tím, že bezpečnostním modulům umožnil rozhodnout se, jestli dokážou bezpečně provést kontrolu práv v režimu RCU nebo ne; výchozí je návrat k pomalému režimu. Vzhledem k tomu, že výchozí kontrola inode_permission() nedělá nic, šlo snadno zajistit, aby ji bylo možné bezpečně použít v RCU režimu; jenom tato změna stačí k tomu, aby systémy, na kterých jsou povoleny bezpečnostní moduly, ale kde není žádný modul aktivní, mohly používat rychlou cestu.

Když se díval dál, zjistil Andi, že jak SELinux, tak SMACK již při kontrole oprávnění používají RCU. Vzhledem k tomu, že tento kód již je bezpečně použitelný s RCU, jeho rozšíření tak, aby bylo z hlediska RCU bezpečné i ověřování oprávnění, bylo relativně přímočaré. Jediný zbývající háček se objevuje v situaci, kdy je povolen audit [auditing]; ten není bezpečný, takže na takových systémech se věci zpomalí. V ostatních případech by nicméně výhody plynoucí z práce na škálovatelnosti dcache měly být rozšířeny i na systémy, kde jsou přítomny bezpečnostní moduly – tedy za předpokladu, že patche v takto pozdní fázi vývojového cyklu nezpůsobí regrese, kvůli kterým by je bylo potřeba odstranit.

Návrat SEEK_HOLE

napsal Jonathan Corbet, 26. dubna 2011

Roku 2007 se čtenáři Jaderných novin dozvěděli o volbách SEEK_HOLE a SEEK_DATA pro systémové volání lseek(). Tyto volby umožňují aplikaci zmapovat „díry“ v řídkém souboru; původně byly implementovány v Solarisu pro souborový systém ZFS. V té době bylo toto rozšíření pro Linux odmítnuto; vývojáři souborových systémů měli za to, že mají lepší způsob, jak problém vyřešit. Nakonec se ale může ukázat, že lepší způsob měli lidé od Solarisu.

Souborové systémy v POSIXových operačních systémech nemusí alokovat bloky pro soubory, pokud by tyto bloky obsahovaly pouze nuly. Rozsah v souboru, pro který nejsou alokovány žádné bloky, se nazývá „díra“. Aplikace, která se z díry pokusí číst, dostane jenom nuly; ve většině případů přitom ani neví, že ve skutečnosti nebylo nic alokováno. Soubory s dírami jsou relativně vzácné, ale některé aplikace „řídké“ soubory vytváří, když je tím efektivnější jejich ukládání.

Ve většině případů se aplikace nemusí dírami zabývat, ale jsou tu výjimky. Zálohovací nástroje mohou ušetřit místo na úložišti, pokud si všimnou děr v souborech a zachovají je. Jednoduché nástroje, jako je cp, mohou také, pokud o dírách ví, zajistit, aby se díry nekopírovaly a nevyplňovaly nulami, když se pořizuje kopie souboru. Dává tedy smysl, aby operační systém poskytoval aplikacím způsob, jak zjistit, kde jsou v souborech díry – pokud tam nějaké jsou.

Rozhraní, které vzniklo v Sunu, používalo systémové volání lseek(), které se normálně používá pro změnu pozice v souboru, odkud se čte a kam se zapisuje. Pokud se lseek() předá SEEK_HOLE, pozice v souboru se přesune na začátek první díry, která začíná za specifikovanou pozicí. SEEK_DATA naopak přesune na začátek první oblasti, která začíná za danou pozicí a která není dírou. „Díra“ je v tomto případě definována jako rozsah nul, který nicméně nemusí odpovídat blokům, které byly ze souboru opravdu vynechány; v praxi nicméně téměř vždy bude. Souborové systémy nemusí vědět o dírách a ani je nemusí hlásit; SEEK_HOLE je optimalizace, ne prostředek pro vygenerování 100% přesné mapy každého místa, kde soubor obsahuje nuly.

Když Josef Bačík roku 2007 zaslal patch pro SEEK_HOLE, obdržel komentáře jako je tento:

Stojím si za tím, že SEEK_HOLE/SEEK_DATA je ubohé rozhraní. Zneužívá operaci seek k dotazování, vyžaduje celkový počet systémových volání odpovídající počtu děr a dat a není dost obecné pro další podobná použití (např. celkový počet spojitých rozsahů, komprimovaných rozsahů, rozsahů aktuálně sdílených s ostatními inody, rozsahů zabudovaných v inodech (konce souborů) atd.)

Patch tedy nebyl začleněn. Místo něj jsme získali novou ioctl() operaci nazvanou FIEMAP. Není pochyb o tom, že FIEMAP je mocnější operace; umožňuje precizní mapování rozsahů v souboru včetně informací o tom, které rozsahy byly alokovány, ale ještě nebyly zapsány, a které rozsahy byly již zapsány, ale ještě nemají přiřazeno přesné číslo bloku. Jedním systémovým voláním lze získat informace pro všechny rozsahy. S takovýmto rozhraním se mělo za to, že SEEK_HOLE není potřeba.

Nedávno nicméně Josef zaslal nový patch SEEK_HOLE s komentářem:

Ukazuje se, že používání fiemap ve věcech, jako je cp, způsobuje více problémů, než řeší, takže se pokusme dát uživatelskému prostoru rozhraní, které nestojí za prd.

Rychlým hledáním na netu lze najít dlouhý seznam hlášení chyb týkajících se FIEMAP. Některá z nich jsou jednoduše chyby v implementacích specifických souborových systémů, příkladem budiž problém spojený se zpožděnou alokací, který byl objeven v únoru. Jiné souvisí s poměrně komplikovanou sémantikou některých možností FIEMAP a například s tím, jestli musí být soubor již uložen na disku předtím, než je možné tuto operaci použít. A jiné se zjevně týkají složitosti samotného systémového volání. Výsledkem je dlouhý seznam hlášení o poškozených souborech – to rozhodně není něco, co vývojáři souborových systémů ve svých schránkách chtějí.

Zdá se, že FIEMAP je mocný nástroj s ostrými hranami, který dostávají do rukou aplikace, které chtěly nůž na máslo. Když dojde na jednoduché hledání toho, které části souborů není potřeba kopírovat, jednoduché rozhraní jako SEEK_HOLE vypadá vhodněji. Dá se předpokládat, že tentokrát se tedy toto rozhraní do jádra dostane.

Zdá se nicméně, že bude nejdříve potřeba pár úprav. API zaslané Josefem nedělá přesně to, co dělá Solaris; přidávat API, které není kompatibilní s existující implementací, nedává smysl. Také je zde otázka, co se má stát, pokud souborový systém neimplementuje volby SEEK_HOLE a SEEK_DATA; současný patch v této situaci vrátí EINVAL. Byla navržena alternativa, která by přidávala implementaci na úrovni VFS, ve které by se předpokládalo, že v souboru žádné díry nejsou. API by tak bylo zdánlivě podporováno na všech souborových systémech a odstranilo by to jednu chybu, kterou by aplikace musely ošetřovat.

Až se tyto detaily vyřeší – a napíší se odpovídající manuálové stránky – mohly by patche SEEK_HOLE tentokrát být začleněny. FIEMAP bude pro aplikace, které potřebují více detailů o rozložení souborů na disku, existovat i nadále; příkladem takové aplikace jsou nástroje, které se snaží optimalizovat dopředné čtení při bootu. Pro všechno ostatní by tu nicméně měla – konečně – být jednodušší možnost.

ARM, DMA a správa paměti

napsal Jonathan Corbet, 27. dubna 2011

Snaha přidat do architektury ARM správné abstrakce a odstranit duplikace kódu pokračuje. Jednou z oblasti, kde se jasně vyskytují problémy, je správa DMA paměti. Architektura ARM přináší do této oblasti unikátní problémy, ne všechny jsou ale specifické pro ARM. Také vidíme zajímavý náhled na budoucnost, kde bude složitější hardware vyžadovat nové mechanismy v jádře, aby fungovalo správně.

Jedním z pokroků, které vidíme u ARM, je poněkud opožděné přidání jednotek pro správu I/O paměti [I/O memory management unit, IOMMU]. IOMMU sedí mezi zařízením a hlavní pamětí a překládá adresy mezi nimi. Nejzjevnější účel IOMMU je, že fyzicky rozdrobená paměť se pro zařízení může zdát jako spojitá, což zjednodušuje velké DMA přenosy. IOMMU může také omezit DMA přístup jenom do specifikovaného rozsahu paměti, čímž do systému přibývá jedna ochranná vrstva – i když pomineme obavy o bezpečnost, zařízení, které čmárá na náhodné místo v paměti, může způsobit nekončící řadu těžko laditelných problémů.

S tím, jak se tato vymoženost dostala na ARM systémy, vytvořili vývojáři přesně v duchu práce s ARM speciální rozhraní pro správu IOMMU. Problém je v tom, že jádro již takové rozhraní má – je to API DMA. Ovladače, které toto API používají, by měly fungovat téměř na jakékoliv architektuře; všechny s tím spojené problémy včetně koherence cache, programování IOMMU a přeskakující zásobníky [bounce buffer] jsou krásně skryty. Zdá se tedy jasné, že ovladače pro ARM by toto API měly používat také; správce ARM Russel King to nedávno řekl bez jakýchkoliv pochybností.

Na architektuře ARM nicméně používání DMA API má několik zajímavých háčků. Většina problémů pochází z toho, že architektura jako taková není schopna vypořádat se s vícenásobnými mapováními stránek, pokud tato mapování nesdílí stejné atributy. To je problém, který se objevil již dříve; více informací vizte v tomto článku. V kontextu DMA je poměrně snadné vytvořit mapování s konfliktními atributy a záležitosti spojené s výkonností pravděpodobně způsobí, že těchto konfliktů bude ještě více.

Dlouho existující DMA buffery se typicky alokují dma_alloc_coherent(); z jména lze odvodit, že tato mapování jsou koherentní z hlediska cache. Dlouho známý problém (nejenom u ARM) je v tom, že některé ovladače potřebují velké a fyzicky spojité DMA oblasti, které může být těžké sehnat, když systém již delší dobu běží. Zkoušelo se mnoho řešení tohoto problému; většina z nich, jako je CMA alokátor, vyžaduje si během bootu dát nějakou paměť stranou. Používání této paměti na ARM může být nebezpečné, protože může být mapována jako paměť zařízení, což vede na problém s konfliktními atributy.

V nedávné době se objevil další problém: v některých případech chtějí vývojáři tuto DMA paměť nastavit jako necachovanou. Vzhledem k tomu, že hlavní paměť je již do adresového prostoru jádra mapována jako cachovaná, není možné ji namapovat jako necachovanou v jiném kontextu a neporušit přitom pravidla. Vzhledem k tomuto konfliktu bychom se mohli ptát (a někteří vývojáři to udělali), k čemu jsou necachovaná DMA mapování dobrá. Důvod vysvětlila Rebecca Schultz Zavin – souvisí s grafikou. Je běžné, že aplikace naplní paměť obrázky a texturami a následně je předá GPU, aniž by na ně dál sahala. V takové situaci není důvod mít tuto paměť v cache CPU; ve skutečnosti to dokonce může zhoršit výkonnost. Vypnutí cachování (ale se zachováním kombinovaného zápisu [write combining]) výkonnost značně vylepšuje.

Vyšší rychlost ale nikdo neocení, když se CPU bude chovat podivně poté, co narazí na vícenásobná mapování s různými atributy. Rebeca vyjmenovala několik možných řešení tohoto problému; některá byla zkoušena již dříve a žádné není považováno za ideální. Jedním je odložit si paměť při bootu – což se občas dělá kvůli velkým bufferům – a nikdy ji nemapovat do adresového prostoru jádra. Další přístup je použít pro tyto buffery horní paměť – ta se do adresového prostoru jádra normálně nemapuje. Systémy založené na ARM typicky horní paměť nepotřebují, ale až se budou dodávat zařízení s 1GB (či více) paměti, horní paměť se začne používat. Poslední alternativa je poladit atributy jaderného mapování dané paměti. To by bylo trochu záludné; tato paměť se mapuje s velkými stránkami, které by se musely dělit na kousky.

Tyto problémy – a další – shrnul v „to do“ seznamu Arnd Bergmann. Narovnat toto rozhraní bude zjevně znamenat spoustu práce a to i přes problémy, které z toho plynou. Na horizontu se nicméně objevil další mrak, protože čím dál více je potřeba tyto buffery mezi zařízeními sdílet. Jeden příklad lze nalézt v tomto patchi, který se pokouší vytvářet grafické overlaye jako regulérní objekty v prostředí jaderného nastavování režimu grafiky [kernel mode setting]. Overlaye nabízí způsob, jak zobrazit (většinou) rychle se měnící grafiku nad tím, co dělá správce oken; tradičně se používají pro přehrávání videa. Často chceme vzít obraz přímo z kamery a zobrazit jej na obrazovce, pokud možno bez účasti uživatelského prostoru. Tyto nové overlaye, pokud se správně propojí s konceptem overlayí ve Video4Linux, by to měly umožnit.

Hardware je čím dál tím sofistikovanější a důsledkem toho je, že jsou čím dál složitější i jeho ovladače. Periferní zařízení jsou v dnešní době často sama o sobě relativně schopné počítače; lze je naprogramovat a pak je delší dobu nechat pracovat samostatně. Je jenom přirozené, když chceme, aby tyto periférie byly schopny samostatně spolupracovat. Paměť je prostředkem, pomocí kterého mohou komunikovat, takže potřebujeme mechanismus pro alokaci a správu paměti, který bude v takovém prostředí fungovat. Objevily se návrhy, že by správce paměti GEM – v současnosti používaný pro GPU – šlo zobecnit tak, aby mohl v takovém režimu pracovat.

Zatím nikdo skutečně nepopsal, jak by tohle všechno mohlo fungovat, a tím pádem ani nikdo nezaslal patche. Vyřešit všechny záležitosti s tím spojené zjevně zabere nějaký čas. Vypadá to jako zábavná výzva pro ty, kdo by chtěli pomoci nastavit směr, kterým se jádro bude ubírat v budoucnosti.

       

Komentáře

[kip]

Nemá být v obsahu a nadpisech místo "Ala Viro" "Al Viro"? A místo "Vítaný návrat Ala Viro" by možná bylo lepší "Vítaný návrat Ala Vira". Na druhou stranu, návrat Vira nezní moc dobře.

[trekker.dk]

V nadpisech a obsahu mělo. Co se příjmení týče, mám za to, že v tomhle případě se neskloňuje.

[Jirka]

Viro jako Ďuričko. Není důvod neskloňovat.

Viro, bez Vira, k Virovi, Vira, Viro!, o Virovi, s Virem.

[trekker.dk]

Viro jako Ďuričko.

Tak o tomhle vzorovém slově slyším poprvé...

[Ladicek]

Zcela mimo téma: pro kompletní popis skloňování v češtině se používá téměř stovka vzorů. Těch čtrnáct (nebo patnáct), co se lidi učí na základní škole, jsou jenom takový základ. Přiznám se, že o tomhle vzoru jsem taky nikdy neslyšel, ale něco málo možná napoví tahle stránka.

[Xgamer]

Tento krát celkom vtipné citáty, a ten posledný je až jemne čierny humor :D:)

[i6]

ale až se budou dodávat zařízení s 1GB (či více) paměti, horní paměť se začne používat.

nojono.. trochu jsme to s Pandaboardem, který do této kategorie spadá, schytali

Existuje nějaká možnost, jak informaci o jeho existenci propagovat?

[Atom321]

Dá se to koupit v ČR? (Tak, abych to nemusel tlačit přes celnici.)

[i6]

To je dobrá myšlenka propagace, ale svoji pandu ti neprodám.

Obávám se, že ne Já jsem svoji dostal bez poštovného (>200$) i bez daně(<200€), ale za nicmoc kurzu dolaru (18) Takže pokud si chytíš čas s kurzem <=15, tak ji budeš mít lacinějc.

A digikey by ji měl mít i skladem snad.. takže si budeš moct vybrat za jaký kurz to bude.

[Atom321]

No, propagovat se to dá docela obyčejným článkem/zprávičkou na odborných serverech (jako třeba abclinuxu.cz, hw.cz). Ale když se to nedá koupit, tak k čemu propagace?

[i6]

Původní důvod bylo to, že mezi lidmi jsou i vývojáři a lidi co píšou takovéhle články. A s tím "nedá koupit" nesouhlasím, pro mě byla laťka hodně nízko..... Ale uznávám, že ne každý zná někoho, kdo vlastní účet u DigiKey.