Jaderné noviny - 7. 11. 2007

11. 12. 2007 | Robert Krátký | Jaderné noviny | 3731×

Aktuální verze jádra: 2.6.24-rc2. Citáty týdne: Ingo Molnár, Rusty Russell, David Miller. Správa paměti grafických procesorů. ID procesů ve světě s více jmennými prostory.

Obsah

• Aktuální verze jádra: 2.6.24-rc2
• Citáty týdne: Ingo Molnár, Rusty Russell, David Miller
• Správa paměti grafických procesorů
• ID procesů ve světě s více jmennými prostory

Aktuální verze jádra: 2.6.24-rc2

Aktuální předverze je (k 7. 11. 2007) 2.6.24-rc2, vydaná, poněkud opožděně, 6. listopadu. Linus vysvětlil: To zdržení nezpůsobilo nic konkrétního. Prostě jsem na to minulý týden zapomněl. Patche začleněné od -rc1 jsou většinou opravy, ale přibylo i pár vylepšení DCCP, příznak pro potlačení varování o použití zastaralých rozhraní, asynchronní API pro upozorňování na události pro SCSI/SATA (říká systému, kdy byl vložen disk), japonský překlad dokumentu SubmittingPatches, API pro správu napájení ATA spojení [ATA link] a trochu další práce na spojení x86. Seznam patchů najdete v krátkém changelogu a podrobnosti v dlouhém.

Od vydání -rc2 se zatím do hlavního git repozitáře žádné další patche nedostaly.

Starší jádra: 2.6.22.11 a 2.6.22.12 byly vydány 2. a 5. listopadu. Tyto verze obsahují řádku patchů, z nichž jeden se týká bezpečnosti - pro oba dva lidi, kteří používají souborový systém Minixu. Greg Kroah-Hartman nedávno uvedl, že navzdory předchozím vyjádřením bude řada 2.6.22.x ještě nějakou dobu pokračovat.

2.6.16.56 a 2.6.16.57 vyšly 1. a 5. listopadu. Obsahují docela dost oprav, z nichž několik řeší bezpečnostní problémy.

Citáty týdne: Ingo Molnár, Rusty Russell, David Miller

Už teď máme v jádře příliš mnoho nekompletních konceptů a API. Možná mám přehnané obavy, ale bojím se, že dopadneme jako v případě kvalifikací nebo sendfile - příliš brzy začleněný kód, který nebyl léta dokončen, možná nebude dokončen nikdy. VMS a WNT tyhle věci podle mě vyřešily lépe - jejich API systémy zahrnují vše a jsou kompletní - a to i v okrajových případech.

-- Ingo Molnar

Starosti mi dělá to, že stringbuf byl dobrý, ale ne skvělý. A přitom na jádro vždycky pohlížím jako na baštu opravdu dobrého C kódu, který pečlivě vybrušují rozumní programátoři. V tomto případě však i ty neměřené optimalizační pokusy ukazují na nedostatek snahy zkušených jaderných hackerů.

-- Rusty Russell

Důvod, proč je kód v jádře tak dobrý, není to, že by se tam už dostal v perfektním stavu - je to proto, že ho pořád dokola ořezáváme, dokud se nedostane do toho perfektního stavu. Tenhle ořezávací systém nám umožňuje během týdne a půl nacpat do stromu 25 MB změn a ono to nakonec všechno funguje.

-- David Miller

Správa paměti grafických procesorů

Správa video hardwaru je už dlouhou dobu slabou stránkou Linuxu (a svobodných operačních systémů obecně). X Window System schytá hodně kritiky za problémy v této oblasti, ale pravda je taková, že potíže se projevují na více místech a jádro X Window Systému nikdy práci neusnadnilo. Grafické procesory (GPU) jsou stále výkonnější, a to až do té míry, že z jistého pohledu jde ve většině systémů o nejrychlejší procesory. Ale jaderná podpora programování GPU je pozadu. Na nápravě této situace se však intenzivně pracuje a pro začlenění do jádra byla právě představena jedna důležitá komponenta.

Bývaly časy, kde se video paměť sestávala z jediného framebufferu, ze kterého byly na displej posílány pixely; byla starost systémového procesoru dostat do toho framebufferu užitečná data. Se současnými GPU je situace komplikovanější: typický GPU může pracovat s několika různými druhy paměti:

• Video RAM (VRAM) je vysokorychlostní paměť instalovaná přímo na videokartě. Většinou ji lze vidět na systémové PCI sběrnici, ale není to pravidlo. Je dost pravděpodobné, že v této paměti bude framebuffer, ale také mnoho dalších druhů dat.


• Na mnoha levnějších systémech je "video RAM" ve skutečnosti vyhrazená část systémové paměti. Taková RAM je dána stranou, aby ji mohl využívat GPU, a pro nic jiného ji nelze využít. I adaptéry s vlastní pamětí mohou mít vyhrazenou oblast obecné RAM.


• Video adaptéry obsahují jednoduchou jednotku pro správu paměti (graphics address remapping table, GART = přemapovávací tabulka grafických adres), kterou je možné použít k mapování různých stránek systémové paměti do adresního prostoru GPU. Výsledkem je, že GPU má kdykoliv přístup k libovolné (roztroušené [scattered]) části stránek systémové RAM.

Každý z druhů video paměti má různé vlastnosti a omezení. S některými se rychleji pracuje (z pohledu CPU nebo GPU). Některé druhy VRAM nemusí být CPU schopen přímo adresovat. Paměť může, ale nemusí podporovat koherenci dat v keši [cache coherency] - rozlišení, které vyžaduje opatrné programování, aby se předešlo poškození dat a problémům s výkonem. A grafické aplikace mohou chtít pracovat s mnohem většími objemy video paměti, než lze pro GPU v určitou chvíli zviditelnit.

To všechno představuje problém se správou paměti, který, i když je podobný potřebám správy systémové RAM, má svá vlastní speciální omezení. Takže grafičtí vývojáři už léta říkají, že by Linux potřeboval řádnou správu paměti, která je přístupná GPU. Ale celá léta už fungujeme bez správce paměti, což má za následek, že je správa prováděna nepěknou kombinací kódu v X serveru, jádře a často proprietárních ovladačích. Naštěstí se zdá, že už tento stav nebude trvat dlouho, a to díky modulu s mapou překladových tabulek [translation-table maps (TTM)], který z většiny napsali Thomas Hellstrom, Eric Anholt a Dave Airlie. TTM poskytuje správce paměti pro potřeby GPU a grafických klientů.

Hlavní objekt, který - z pohledu uživatelského prostoru - TTM spravuje, je "buffer objekt". Bufferový objekt je kus paměti alokovaný aplikací a případně sdílený více aplikacemi. Obsahuje oblast paměti, se kterou může pracovat GPU. Je zaručeno, že bufferový objekt nezmizí, dokud na něj nějaká aplikace udržuje odkaz; umístění bufferu se však může měnit.

Jakmile aplikace vytvoří bufferový objekt, může jej namapovat do svého adresního prostoru. Podle toho, kde se buffer právě nachází, může mapování vyžadovat přemístění bufferu do takového druhu paměti, který může CPU adresovat (přesněji řečeno by takový přesun vynutil výpadek stránky při pokusu aplikace o přístup k namapovanému bufferu). Je samozřejmě také nutné se postarat o koherenci dat v keši.

Přijde chvíle, kdy bude potřeba, aby byl tento buffer k dispozici GPU pro nějakou operaci. TTM vrstva poskytuje speciální "validační" ioctl() pro přípravu bufferů ke zpracovávání; validace bufferu by opět mohla zahrnovat přesun nebo nastavení mapování pomocí GART. Adresa, na které bude GPU k bufferu přistupovat, nebude známa až do validace; po validaci nebude buffer odstraněn z adresního prostoru GPU, dokud se s ním bude pracovat.

To znamená, že jádro musí vědět o dokončení práce s daným bufferem; stejně tak to musí vědět aplikace. TTM vrstva k tomu účelu poskytuje "plotové" [fence] objekty. Plot je speciální operace, která je umístěna do FIFO grafického procesoru. Když je plot spuštěn, nastaví signál, který značí, že všechny instrukce zařazené do fronty před ním, byly spuštěny a že GPU už nebude přistupovat k žádným bufferům, které k nim byly přiřazeny. Způsob fungování signalizace závisí na GPU; může se jednat o přerušení nebo jen zapsání hodnoty na speciální místo paměti. Při spuštění signálu jsou všechny přiřazené buffery označeny, aby bylo zřejmé, že na ně už GPU neodkazuje, a odešle se oznámení procesům v uživatelském prostoru, které to zajímá.

Na vytíženém systému může běžet množství grafických aplikací, z nichž každá se snaží grafickému procesoru cpát buffery. Nebylo by překvapení, kdyby poptávka po bufferech, které může GPU adresovat, přesáhla množství paměti, ke které má GPU přístup. Takže TTM vrstva bude muset v reakci na příchozí požadavky buffery přesouvat. U bufferů mapovaných pomocí GART může stačit odmapovat stránky z bufferů, které zrovna nejsou pro GPU operace validovány. V ostatních případech může být nutné překopírovat obsah bufferů do jiného druhu paměti, případně i pomocí GPU hardwaru. V takových situacích je nejprve nutné buffery invalidovat v tabulkách stránek všech uživatelských procesů, které je mají namapovány, aby se pojistilo, že do bufferu nebude během přesunu zapisováno. Jinými slovy, TTM tak opravdu rozšiřuje systémový kód pro správu paměti.

Další otázka je nasnadě: co se stane, když chtějí grafické aplikace používat více paměti, než může celý systém poskytnout? Stránky běžné systémové RAM, které se používají jako video paměť, jsou pevně stanoveny (a nelze je použít pro nic jiného), takže jejich počet musí být omezen. Stávající řešení je omezit počet těchto stránek na zlomek dostupné spodní paměti - 1 GB na 4GB, 32bitovém systému. Bylo by fajn mít možnost rozšířit tuto paměť zápisem nepoužívaných stránek do swapu, ale linuxová implementace swapu neumí pracovat se stránkami, které patří jádru. Vypadá to, že do budoucna se plánuje umožnit X serveru vytvořit velký virtuální rozsah pomocí mmap(), který by pak šlo swapovat. To však zatím implementováno není.

Další informace o kódu TTM lze nalézt v tungstengraphics.com/mm.pdf. V tuto chvíli to funguje s opatchovanou verzí ovladače i915 od Intelu, další budou doplněny. TTM bylo navrženo k začlenění do jádra -mm a do hlavního v rámci 2.6.25. Do té doby půjde především o posouzení uživatelského API, které by bylo těžké po začlenění měnit. Bohužel to vypadá, že k tomuto API není moc dokumentace.

ID procesů ve světě s více jmennými prostory

Článek o kontejnerech z minulého týdne pojednával o jmenných prostorech ID procesů. Účelem těchto jmenných prostorů je určovat, které procesy uvidí proces uzavřený v kontejneru. Rozšířené používání PID pro identifikaci procesů způsobilo, že tento konkrétní patch prošel dlouhým vývojem, než byl do 2.6.24 začleněn. Vypadá to však, že se objevily potíže, které by mohly zabránit tomu, aby byla tato funkce v další verzi jádra k dispozici. Jak se stává často, i tentokrát jsou největší problémy s uživatelským API.

1. listopadu Ingo Molnár poukázal na to, že některé otázky, které v roce 2006 pokládal Ulrich Drepper, zůstaly bez odpovědi. Všechny se týkají toho, co se stane, když používaný PID unikne ze jmenného prostoru, do kterého patří. Existuje několik jaderných API týkajících se meziprocesové komunikace a synchronizace, kde by se to mohlo stát. Realtimové signály obsahují informace o ID procesů, stejně jako fronty zpráv SYSV. Přinejmenším bude k tomu, aby tato rozhraní správně fungovala ve všech jmenných prostorech PID, potřeba, aby jádro provádělo překlady PID, kdykoliv PID překročí hranici jmenného prostoru.

Největší potíž však asi bude s robustním mechanismem futexů, jenž používá PID ke sledování, který proces vlastní určitý futex v daný okamžik. Jedním z klíčových konceptů u futexů je rychlý způsob jejich získávání (pokud se o futex nesoupeří), který vůbec nevyžaduje zapojení jádra. Jenže při tom rychlém získávání je také nastaveno pole PID. Není tedy možné dát jádru možnost provést kouzlení s překladem PID, aniž by to mělo negativní dopad na výkon, který byl jednou z hlavních motivací pro futexy.

Ingo, Ulrich a další, kterým tento problém dělá starosti, by byli rádi, kdyby byly jmenné prostory PID v 2.6.24 úplně vypnuty. Není však jasné, jak by takové řešení vypadalo, nebo jestli je vůbec nutné.

Ulrich by pravděpodobně preferoval, aby byly částečně odstraněny rozmanité možnosti, které jádro poskytuje pro ovládání sdílení jmenných prostorů. S rozhraním, které je v 2.6.24-rc1, může proces, jenž zavolá clone(), vyžadovat, aby byl potomek umístěn do nového jmenného prostoru PID, ale aby ostatní jmenné prostory (například souborové systémy nebo síťování) byly sdíleny. To si, podle Ulricha, říká o potíže:

Celý ten přístup, který umožňuje zapínání a vypínání jmenných prostorů, je prostě špatný. Nechte, ať je to buď všechno nebo nic - aspoň u těch problematických jako NEWPID. Přístup ke stejnému souborovému systému, ale zároveň používání jiného jmenného prostoru PID, to prostě nebude fungovat.

Sjednocení několika voleb jmenných prostorů do jediného bitu "nový kontejner" by pomohlo s nedostatkem klonovacích bitů, ale problémy API by to možná vůbec nevyřešilo. Dokonce i procesy s odlišnými jmennými prostory souborových systémů by mohly najít ten samý futex prostřednictvím souboru, který by byl viditelný v obou prostorech. Předávání dokladů přes sokety unixových domén by to mohlo také pěkně zamotat. Zdá se, že jsou místa, kde se používají PID, na která si zatím nikdo nevzpomněl.

Další možný přístup, který v popisované debatě ani nezazněl, by bylo vytvoření globálně unikátních PID hodnot, které by fungovaly ve všech jmenných prostorech. Současná 32bitová hodnota PID by mohla být rozdělena na dvě pole, přičemž nejvýznamnější bity by značily, ve kterém jmenném prostoru je PID (obsažený v nejméně významných bitech) definován. Většinou by byla potřeba jen ta druhá část; ta by byla interpretována ve vztahu k aktuálnímu jmennému prostoru PID. Ale v případech, kdy by to dávalo smysl, by se použilo plné, unikátní PID. To by umožnilo funkcím, jako jsou futexy, fungovat ve všech jmenných prostorech PID.

I tak by s tím však byly problémy. Základní myšlenka jmenných prostorů PID je úplné schování procesů, které jsou vně aktuálního prostoru; vytvoření a používání globálních PID v této izolaci dělá díry. A je jisté, že by se v uživatelském API objevily komplikace, které by bylo těžké jen tak zaplácnout.

Pak je tu otázka, jestli jde vůbec o podstatný problém. Linus si to nemyslí a poukazuje na to, že sdílení PID mezi jmennými prostory je podobné jako používání PID v zamykacích souborech sdílených po síti. Zamykání založené na PID nefunguje na souborech připojených přes NFS a rozhraní založená na PID nebudou fungovat mezi jmennými prostory PID. Linus to shrnul takto:

Nechápu, jak tomu můžete říkat "chyba návrhu jmenných prostorů PID", když to s těmi jmennými prostory PID nemá zjevně nic společného - naopak to má všechno společné s *futexy*, které bláznivě předpokládají, že jsou PID unikátní, a které na tom postavily část uživatelského rozhraní.

Dalo by se argumentovat tím, že o konfliktu se jmennými prostory PID se vědělo už při začleňování futexů, a že se s tím dalo něco udělat už tenkrát. Ale to už teď nikomu nepomůže. A kromě toho tam jsou i jiné problémy než jen s futexy.

Jmenné prostory PID výrazně komplikují uživatelské API; redefinují základní hodnotu, která měla všeobecně chápaný význam od raných dnů unixu. Není tedy nijak divné, že se vynořily zajímavé otázky. Získávání solidních odpovědí na všetečné otázky ohledně API není tradičně silnou disciplínou vývoje Linuxu, ale třeba se to změní.

       

Komentáře

[mkoubik]

V odkazu na krátký changelog k 2.6.24-rc2 chybí http://lwn.net.

[Luboš Doležel (Doli)]

Díky, opraveno.