Jaderné noviny – 8. 7. 2009

4. 8. 2009 | Jirka Bourek | Jaderné noviny | 3705×

Aktuální verze jádra: 2.6.31-rc2. Citáty týdne (speciál o VFAT): Rusty Russell, Andrew Tridgell, Alan Cox. V krátkosti: VFAT; Checkpatch policie. Trochu povyku pro nulu. Bezzámkový kruhový buffer. Přechodná paměť.

Obsah

• Aktuální verze jádra: 2.6.31-rc2
• Citáty týdne (speciál o VFAT): Rusty Russell, Andrew Tridgell, Alan Cox
• V krátkosti
  • VFAT
  • Checkpatch policie
• Trochu povyku pro nulu
• Bezzámkový kruhový buffer
• Přechodná paměť

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

Současné vývojové jádro 2.6 je 2.6.31-rc2 vydané 4. července. Obsahuje mnoho oprav chyb, zkrácený changelog je v oznámení, všechny detaily vizte v kompletním changelogu.

Současné stabilní jádro je 2.6.30.1 vydané 2. července. Obsahuje dlouhý seznam oprav (změněno 147 souborů) vážných problémů v mnoha oblastech. Ve stejné době vyšly aktualizace 2.6.29.6 a 2.6.27.26; 2.6.29.6 je poslední stabilní aktualizace v sérii 2.6.29.

Citáty týdne (speciál o VFAT): Rusty Russell, Andrew Tridgell, Alan Cox

Obcházení problémů přidáváme kvůli špatnému hardwaru, i když to oprávněně nemáme rádi. Podobně v tomto případě menší změna vyřeší skutečné problémy, které mají naši uživatelé (ano, vím, že máme jenom jedno hlášení o chybě).

Je to špatně. Nadávejme na to. A přesto to obejití přidejme.

-- Rusty Russell

Když se prodejce operačního systému ani neobtěžuje zobrazit pro svůj OS jasnou stránku „sorry, žádné aktualizace už nebudou“, řekl bych, že lze bezpečně předpokládat, že je daný operační systém mrtvý a pohřbený.

-- Andrew Tridgell

Jak může dodávání něčeho, co je označeno jako „vfat“, ale nefunguje to, znamenat „bránit se“? Je to „snažit se, aby si naši uživatelé začali myslet, že náš kód stojí za prd“.

-- Alan Cox

V krátkosti

VFAT

Diskuze o obcházení patentů na VFAT pokračuje, zaměřuje se hlavně na dva body. První je, jestli je vhodné vkládat do jádra obcházení problémů. Hlavní opozice pochází od Alana Coxe, který tvrdí, že vymyslet, jak obejít různé pro stát specifické zákonné nášlapné miny, je na jednotlivých firmách; obcházení těchto problémů by si nemělo nacházet cestu do upstreamu. Krom toho Alan tvrdí, že prodejci, kteří mají obavy z patentových žalob, nebudou spokojení s konfigurační volbou v jádře; ti ten kód vyhodí úplně.

Mezitím Andrew Tridgell pokračuje v tlaku na obcházení – je to strategie, která pro Sambu fungovala dobře. Tridge říká:

Jedinou zbraní, kterou máme v boji proti patentům, je nyní kolektivní schopnost najít chytrá řešení problémů. Přístup „každý prodejce sám za sebe“, který se ti podle všeho tak líbí, takový kolektivní přístup v podstatě vylučuje.

Jak se to vyvrbí, se uvidí. Zároveň také probíhala rozsáhlá technická diskuze zaměřená na problémy s interoperabilitou způsobené patchem. Některé problémy, jak vysvětlil Tridge, jsou důsledkem různých existujících připojovacích voleb VFAT; v některých případech i bez patche, o kterém se diskutuje, vytvoří Linux záznamy s dlouhými jmény v případech, které by se do formátu 8.3 vešly. Tento druh problému s interoperabilitou existuje již nějakou dobu.

Připojovací volby nicméně nevysvětlují všechny problémy. Zdá se, že některé přehrávače sice rozumí dlouhým jménům, ale stále potřebují, aby existovalo platné jméno ve formátu 8.3. Také jsou problémy s Windows 98, které by mohly (ale nemusely) být vyřešeny změnou toho, jak nyní patch vyplňuje informace ve formátu 8.3. Tridge si myslí, že Windows 98 jsou dost staré na to, aby nemělo cenu se jimi zabývat, ale ne všichni s tím souhlasí.

Checkpatch policie

Alan Cox nedávno navrhl přidání nového rozhraní pro události ovladače virtuálního terminálu. Ingo Molnár reagoval seznamem chyb vypsaných skriptem checkpatch.pl s požadavkem, aby byly opraveny. Alanova odpověď:

Vzhledem k tomu, že kód v současnosti nefunguje a je to pouze první návrh, jsou ty chyby sotva důležité. Vím, jak lépe využít čas, než hrát si na checkpatch policajta.

Následovala dlouhá diskuze o hodnotě checkpatch.pl, jestli by kód měl být z hlediska checkpatch čistý i před prvním zasláním, jestli by problémy ve stylu psaní kódu měly být řešeny kousek po kousku společně s tím, jak se dělá i další práce atd. Ingo by byl rád, kdyby problémy ve stylu kódu byly vyřešeny brzy; mezi jinými věcmi konzistentní styl kódu zjednodušuje revize. Alan považuje toto pročišťování za vyrušení, mělo by to být uděláno poté, co jsou vyřešeny důležitější záležitosti (kterých je v kódu TTY dost).

Konsenzus v této diskuzi nehledejte; očekávejte spíš, že půjde o jedno z témat, která se na linux-kernel objevují opakovaně.

Trochu povyku pro nulu

Počítače používají spoustu nul. V počátcích své kariéry programátora autor tohoto článku Jonathan Corbet pracoval na stroji, který poskytoval zvláštní hardwarový registr obsahující nulu; programátoři na tomto systému věděli, že mohou použít tolik nul, kolik chtějí, bez obav, že jim dojdou. Mezitím, v tomto století, si linuxové jádro odkládá stranou stránku plnou nul. Na architektuře x86 se jmenuje empty_zero_page a je dokonce exportována modulům. Co je zajímavé, tato stránka se nepoužívá tak často, jako to bylo před jádrem 2.6.24, ale to se teď možná změní.

Ve starých dobrých dnech jádro použilo nulovou stránku v situacích, kdy vědělo, že je potřeba stránka plná nul. Takže například když proces narazil na výpadek při čtení u stránky, kterou nikdy nepoužíval, jádro jednoduše na tuto adresu namapovalo nulovou stránku. Použilo se mapování s kopírováním při zápisu samozřejmě; pokud proces následně stránku modifikoval, skončil s vlastní kopií. Odkládání vytváření nových stránek vyplněných nulami však pomáhalo šetřit nulami, aby jádru nedošly. Shodou okolností to také šetřilo paměť, omezovalo tlak na cache a odstraňovalo potřebu nulovat novou stránku.

Efektem změny ve správě paměti provedené roku 2007 bylo to, že se k nulové stránce přidalo čítání odkazů. A to se ukázalo jako problematické na víceprocesorových strojích. Vzhledem k tomu, že všechny procesory sdílely stejnou nulovou stránku (protože nebylo pravděpodobné, že by se pro jednotlivé procesory lišila), manipulovaly také stejným počtem odkazů. To vedlo k vážným problémům s poskakující řádkou v cache, které měly měřitelný dopad. Nick Piggin proto vyhodnotil několik možných oprav včetně speciálního hacku, který by nečítal odkazy u nulové stránky, a přidání nulových stránek pro každé CPU. Patch, který byl začleněn, však jednoduše odstranil většinu případů použití nulové stránky. Změna byla ospravedlněna takto:

Vkládání ZERO_PAGE při anonymním výpadku čtení se zdá jako falešná optimalizace: Pokud je výkonnost pro aplikaci kritická, nebude mít mnoho výpadků při čtení nové paměti nebo od ní lze alespoň očekávat, že do této paměti brzy poté zapíše. Jestliže je kritické využívání cache nebo paměti, nemělo by se ani pracovat s významným počtem ZERO_PAGE stránek (měla by se použít kompaktnější reprezentace nul).

Okolo patche v dané podobě panovala nervozita; Linus si stěžoval na změny, kvůli kterým problém vznikl, a měl obavy:

Jádro vždycky mělo (v podstatě od prvního dne) tuhle ZERO_PAGE věc. To znamená, že by mě nepřekvapilo, kdyby na ní nějaká aplikace jednoduše závisela. Napsal jsem testovací programy, které na ní závisí – možná lidé napsali další kód, který byl jednoduše napsán pro a testován s jádrem, které zjednodušeně vždycky mělo extra levné nulové stránky pouze pro čtení.

I přes své pochybnosti Linus začlenil patch do 2.6.24, aby zjistil, jaké problémy se mohou objevit. Po dalších 18 měsíců se zdálo, že je takových problémů poměrně málo; většina lidí na nulovou stránku úplně zapomněla. Začátkem června nicméně Julian Phillips ohlásil problém, na který narazil:

Mám program, který vytváří rozumně velkou privátní anonymní mapu. Program poté zapíše do několika míst v mapě, ale čte všechno.

Když tento program spustím na systému s 2.6.20.7, proces podle všeho používá tolik paměti, kolik potřebuje k uložení dat, která zapsal (dobře – v jednotkách PAGE_SIZE). Když program spustím na systému s 2.6.24.5, pak při čtení stoupá množství využívané paměti, dokud není celá mapa alokována (a vzhledem k tomu, že je celková velikost větší než fyzicky dostupná RAM, způsobuje to swapování). Zjednodušeně mi přijde, že pozoruji chování kopírování při čtení místo kopírování při zápisu.

Co Julian pozoroval, byl samozřejmě efekt odstranění nulové stránky. Na starších jádrech byly všechny nezapsané stránky v datové struktuře mapovány na nulovou stránku, takže se nevyužívala žádná fyzická paměť navíc. Od 2.6.24 každá z těchto stránek dostane svou fyzickou stránku – která neobsahuje nic než nuly – což významně zvyšuje spotřebu paměti.

Hiroyuki Kamezawa hlásí, že viděl zátěže závisející na nulové stránce na dalších místech. Mnoho z těchto míst, říká, používá podnikové distribuce Linuxu, které ještě nedodávají dostatečně nová jádra, aby v nich chyběla podpora pro nulovou stránku. Má obavy, že tito uživatelé narazí na stejný druh nepříjemného překvapení, na které narazil Julian, až aktualizují na novější jádro. Z toho důvodu zaslal patch, který obnovuje podporu nulové stránky v jádře.

Hiroyukiho podpora pro nulovou stránku není úplně stejná jako ta dřívější. Vyhýbá se čítání odkazů na nulovou stránku, což je změna, která by měla odstranit ty nejhorší výkonnostní problémy. Přidává ale nějaké zajímavé zvláštní případy, kde kód virtuální paměti musí opatrně testovat nulovost stránky; většina těchto případů je řešena funkcí get_user_pages_nonzero(), která odstraní všechny nulové stránky z daného rozsahu. Linusovi se tyto zvláštní případy nelíbí, myslí si o nich, že jsou zbytečné. Místo toho navrhl alternativní implementaci používající k označení nulové stránky relativně nový příznak PTE_SPECIAL. V době psaní tohoto článku nebyla ještě zaslána aktualizovaná verze patche, která by používala tento přístup.

Nick Piggin, který napsal patch odstraňující podporu pro nulovou stránku, by byl raději, kdyby se nevracela. Co se postižených uživatelů týče, ptá se:

Neměli bychom je raději odstavit? Používání nulových stránek pro obrovské řídké matice stejně pravděpodobně není ideální, protože stejně musí docházet k výpadkům a obsazuje se prostor TLB. Mohli by dosáhnout lepší výkonnosti použitím lepšího algoritmu.

Linus by nicméně chtěl, aby tato vlastnost byla obnovena, pokud toho půjde dosáhnout čistě. Návrat podpory pro nulovou stránku se tedy zdá být poměrně pravděpodobný za předpokladu, že bude možné patch zpracovat do dostatečně dobrého stavu. Jestli to uklidní uživatele podnikových jader, to se uvidí; nová generace podnikového Linuxu se zdá být připravena použít jádra okolo 2.6.27. Pokud distributoři nebackportují patch nulových stránek, uživatelé podnikových verzí budou stejně odkázáni na současné, nulami plýtvající chování.

Bezzámkový kruhový buffer

Jedním z výsledků loňského Kernel summitu a Linux Plumbers Conference byl plán vytvořit nízkoúrovňovou implementaci kruhového bufferu, kterou by bylo možné sdílet mezi různými sledovacími řešeními pro Linux v jádře a uživatelském prostoru. Jedna implementace kruhového bufferu byla vydána jako součást 2.6.28, ale ta příliš intenzivně zamykala, což mělo dopad na její výkonnost. Nedávno Steven Rostedt navrhl bezzámkový algoritmus kruhového bufferu, který by odstranil zamykání při zápisu, což je u sledování rychlá cesta.

Když se v jádře sbírají informace ze sledování, je potřeba je někam uložit velmi rychle, aby byl dopad na časování pozorovaných událostí – a výkonnost systému celkově – poměrně minimální. Čtení dat se na druhou stranu provádí z uživatelského prostoru, takže to obecně není citlivé na výkonnost. Současná implementace kruhového bufferu vytváří kruhový obousměrný spojový seznam stránek společně s ukazateli na začátek [head] a na konec [tail], zapisuje se na konec a čte od začátku.

Když se kruhový buffer zaplní nebo téměř zaplní, je možné, že další zápisy přepíší data v první stránce, což by mohlo poškodit načítaná data. Z tohoto důvodu je zde oddělená stránka pro čtení [reader page], která je ze seznamu zcela odstraněna, čtoucí proces ji může použít bez obavy o poškození zápisem. Mít oddělenou stránku ale znamená, že se musí trochu tancovat, když čtenář se stránkou skončí a potřebuje novou. Stránka pro čtení musí být vložena zpět do seznamu někam za konec, přičemž současnou první stránku je potřeba ze seznamu odstranit, udělat z ní novou stránku pro čtení a z následující stránky udělat první. To vyžaduje zamykání.

V diagramu níže, která je převzat ze Stevenova dokumentu ring-buffer-design.txt, je vidět, jak by kruhový buffer vypadal. Pozorný čtenář si všimne ukazatele H, což je ukazatel s příznakem HEADER popsaný níže.

           stránka pro čtení
               |
               v
             +---+
             |   |------+
             +---+      |
                        |
                        v
    +---+    +---+    +---+    +---+
<---|   |--->|   |-H->|   |--->|   |--->
--->|   |<---|   |<---|   |<---|   |<---
    +---+    +---+    +---+    +---+

Zápisy lze přerušit jinými zápisy, pokud přerušující zapisovatel dokončí svůj zápis předtím, než může pokračovat přerušený zápis. To je v souladu s tím, jak se přerušení skládají, a je nutné to kvůli integritě struktury kruhového bufferu vynucovat. Když je zahájen zápis, je za koncovým ukazatelem rezervováno místo, kam se má událost uložit. Koncový ukazatel se tím přesouvá, takže je potřeba jiný ukazatel nazvaný ukazatel provedení [commit pointer], který sleduje nejnovější kompletní zápis.

V téměř prázdném kruhovém bufferu je možné, aby byla stránka pro čtení zároveň stránkou pro provedení [commit page] a poslední stránkou. I když je stránka pro čtení odstraněna z kruhového bufferu, její ukazatel next stále ukazuje na další záznam v kruhovém bufferu. Jakmile je provedeno dost zápisů, ukazatel provedení a ukazatel na konec jednoduše následují ukazatel next, jako by to udělaly normálně.

Aby se odstranilo zamykání u zápisů, které v současnosti potřebuje použít zámky při synchronizaci aktualizací ukazatelů na začátek, konec a ukazatele provedení, používá Steven atomickou operaci cmpxchg() dostupnou na některých architekturách. Ta funguje takto:

R = cmpxchg(A, C, B)
    – přiřadí A = B, pokud A == C
    – vrátí A v době volání, bezpodmínečně

Úspěch výměny lze ověřit testem, jestli R je rovno C, pokud ano, výměna byla provedena.

Algoritmus vyžaduje, aby byly ukazatele ve strukturách spojového seznamu zarovnány na 4 byty, aby bylo možné rezervovat spodní 2 bity pro příznaky. Ty jsou:

• HEADER – ukazatel na aktuální první stránku

• UPDATE – ukazatel na stránku, do které se v současnosti zapisuje, a buď to je, nebo brzy bude první stránka

Tyto příznaky společně s operací cmpxchg() jsou to, co umožňuje bezzámkové zapisování do bufferu.

Když je stránka pro čtení vyčerpána, současná první stránka musí být odpojena z kruhového bufferu jako nová stránka pro čtenáře. Použitím příznaku HEADER mohou ti, kteří zapisují, zabránit v zasahování těm, kdo čtou, aniž by se musel získávat zámek. Když se během procesu výměny čtenář pokusí změnit ukazatel next, použije cmpxchg(), aby zajistil, že je přítomen příznak HEADER. Tomu může zapisující zabránit nastavením příznaku na UPDATE nebo vynulováním příznaků. Když cmpxchg() čtoucího selže, znamená to, že zapisovatelé změnili stav bufferu a čtenář si musí najít novou první stránku a proces začít odznova.

Když zapisovatelé mění ukazatel na poslední stránku, zatímco plní buffer, kontrolují, jestli má ukazatel next nové stránky nastavený příznak HEADER. Pokud je přítomen, je změněn na UPDATE. To znamená, že je stránka nestabilní, protože ji právě používají zapisovatelé, a způsobí to, že cmpxchg() čtoucích selže, pokud se pokusí odpojit čelní stránku. To naznačuje, že buffer je téměř plný, že pro ukládání událostí zbývá pouze jedna stránka (tj. nová poslední stránka).

Kruhový buffer může pracovat ve dvou režimech; v přepisovacím (známém jako „černá skříňka“), kde nové události přepisují starší, když se buffer naplní, nebo v režimu producent/konzument [producer/consumer], kde pokus o zápis do plného bufferu selže. V režimu producent/konzument se první stránka mění pouze na přání čtoucího, ale v režimu přepisování, když se dosáhne konce poslední stránky, musí být první stránka o stránku posunuta, což je důvod, proč je potřeba použít příznak UPDATE.

Základní funkce algoritmu je relativně přímočará – i když poněkud náročná na pochopení – ale je zde mnoho složitějších případů, které je potřeba uvážit. Jedním z nich je možnost, že vnořený zápis způsobí, že se buffer zaplní, takže poslední stránka dosáhne stránky pro provedení. Není jiná možnost než zápisy v tomto bodě zahodit, ale může se stát, že je stránka pro provedení stránkou pro čtení (jak je ukázáno níže). Jednoduché posunutí první stránky dopředu za záznam, na který ukazuje stránka pro čtení, by stránce pro provedení zabránilo přesunout se ze stránky pro čtení zpět do kruhového bufferu. Zapisovatelé tedy musí tento stav testovat a zahazovat zápisy, když ho detekují.

    stránka pro čtení   stránka pro provedení
              |              |
              v              |
             +---+           |
             |   |<----------+
             |   |
             |   |------+
             +---+      |
                        |
                        v
    +---+    +---+    +---+    +---+
<---|   |--->|   |-H->|   |--->|   |--->
--->|   |<---|   |<---|   |<---|   |<---
    +---+    +---+    +---+    +---+
               ^
               |
             poslední stránka

Jsou možné i další složité situace; čtenáři, kteří mají zájem o více informací, nechť se podívají do Stevenova dokumentu o návrhu. Ten je poměrně podrobný a nacpaný ASCII artem zobrazujícím operace v kruhovém bufferu. Algoritmus jako takový je předmětem žádosti o patent, kterou Steven podal za Red Hat. Pokud bude schválen, bude k dispozici svobodnému softwaru podle patentové politiky Red Hatu.

Mathieu Desnoyers, vývojář Linuxových sledovacích nástrojů nové generace (Linux Trace Toolkit Next Generation, LTTng) sledoval zaslání kruhového bufferu pozorně, protože LTTng by mělo být prvním sledovacím řešením, od kterého se očekává používání společného kruhového bufferu. Řekl, že je navržený algoritmus složitý skoro jako mechanismy RCU, ale na rozdíl od RCU (či algoritmu bezzámkového bufferu LTTng) nebyl proveden žádný formální důkaz algoritmu. Souhlasí s tím, že jsou bezzámkové buffery pro sledování žádoucí a dosažitelné, ale má obavy z toho, že nedostatek formálního ověřování Stevenova algoritmu může vést k dlouhému období hledání chyb. Tato složitost má nicméně i světlou stránku, protože jak Mathieu poznamenal ve své revizi návrhu: Skvělá zpráva je pro mě to, že nikdo nemůže říct, že je algoritmus bezzámkového bufferování v LTTng v porovnání s tímhle složitý ;)

Další dvě obavy, které zmínil, jsou výkonnost a rychlé sledování z uživatelského prostoru. Stevenův algoritmus závisí na tom, že bude schopen zakázat preempci, což u sledování v uživatelském prostoru není možné. Mathieu řekl, že LTTng má kompaktnější události, které, jak věří, umožní verzi v LTTng zpracovat více událostí za sekundu, než zvládne Stevenova verze; žádné srovnání výkonnosti zatím nicméně provedeno nebylo. Mathieu doufá, že bude schopen navrhnout alternativní implementaci bezzámkového kruhového bufferu založenou na kódu v LTTng někdy brzy, ale je zde jistá malá záležitost v podobě dizertační práce pro Ph.D., která se bude muset dokončit dřív.

Steven se začleněním bezzámkového kruhového bufferu míří do 2.6.32, uvidí se, jestli proti začlenění budou námitky. To také může odradit alternativy. Dříve či později se nicméně nějaký druh bezzámkového bufferování událostí pro sledování s největší pravděpodobností do jádra dostane.

Přechodná paměť

Pro jakýkoliv operační systém je jednou z největších výzev co nejlepší využívání dostupné paměti. Vhoďte do směsi virtualizaci a objeví se nové výzvy (jako je například vyvažování spotřeby paměti mezi hosty) a příležitosti (sdílení stránek mezi hosty). Vývojáři reagovali technologiemi jako připojování paměti za běhu a KSM, ale nezdá se, že by někdo považoval problém za zcela vyřešený. Přechodná paměť [transcendent memory] je nová technika správy paměti, která, jak se doufá, zlepší využívání vzácné paměti systému bez ohledu na to, jestli se používá virtualizace.

Ve svém úvodu na linux-kernel se Dan Magenheimer ptá:

Co kdyby byla třída paměti, která má neznámou a dynamicky se měnící velikost, je adresovatelná pouze nepřímo jádrem, lze ji nakonfigurovat jak jako trvalou, tak jako „pomíjející“ (což znamená, že tu nějakou dobu bude, ale může bez varování zmizet) a přesto je dostatečně rychlá, aby k ní bylo možné přistupovat synchronně?

Dan (společně se skupinou dalších jaderných vývojářů) zkoumá koncept, který nazývá „přechodná paměť“ [transcendental memory]. V krátkosti lze tuto „nadpřirozenou“ paměť považovat za druh RAM disku s nějakými zajímavými vlastnostmi: Nikdo neví, jak je velký, zápisy nemusí uspět a data na něj zapsaná mohou zmizet předtím, než je někdo znovu přečte. Na první pohled to může vypadat jako relativně nepoužitelné zařízení, ale doufá se, že přechodná paměť bude schopna v některých situacích vylepšit výkonnost.

Specifikace API [PDF] je k dispozici; v patchi samotném je také s tím spojené C API. Tento článek se bude zaměřovat na to druhé, které tolik netrpí NADBYTEČNÝM POUŽÍVÁNÍM VELKÝCH PÍSMEN a je obecně snáze pochopitelné.

Přechodná paměť pracuje s konceptem fondů stránek; jakmile je vytvořen fond, lze do stránek v něm ukládat data. Volání pro vytváření a likvidaci fondů vypadají takto:

u32 pool_id = tmem_new_pool(struct tmem_pool_uuid uuid, u32 flags)
tmem_destroy_pool(u32 pool_id);

Fondy jsou identifikovány hodnotou uuid, i když tato identifikace je relevantní pouze pro fondy, které se mohou sdílet mezi několika uživateli. V poli flags je uloženo poměrně slušné množství informací včetně:

• Bit „pomíjivosti“, který určuje, jestli mohou data úspěšně zapsaná do fondu v budoucnu náhodně zmizet.

• Bit „sdílený“, který indikuje, jestli se fond bude sdílet s dalšími uživateli.

• Velikost stránek, které se ve fondu používají, vyjádřeno v jaderné hodnotě „řád“.

• Specifikace čísla verze, které zajišťuje, aby obě strany rozhovoru věděly, jak si mají s tou druhou porozumět.

I když se od uživatelů očekává, že specifikují velikost stránky, není možné specifikovat velikost fondu jako celku. Určení správné velikosti fondu (která se téměř určitě bude časem měnit) je ponecháno na hypervizoru nebo kterékoliv jiné softwarové komponentě, která bude mít fond na starosti.

Jak je naznačeno rozhraním výše, přechodná paměť je velmi orientovaná na stránky. Kromě toho se na ni nelze odkazovat přímo; uživatelé do ní a z ní musí kopírovat data explicitně. Funkce pro přesouvání dat mezi běžnou a přechodnou pamětí jsou:

int tmem_put_page(u32 pool_id, u64 object_id, u32 page_id, unsigned long pfn);
int tmem_get_page(u32 pool_id, u64 object_id, u32 page_id, unsigned long pfn);

V obou těchto volání pool_id specifikuje existující fond. Hodnoty object_id a page_id společně tvoří unikátní identifikátor stránky ve fondu. Pokud se fond například používá ke cachování stránek souborů, object_id by identifikovalo soubor, kdežto page_id by byl posun v tomto souboru. pfn (číslo rámce stránky, page frame number) identifikuje stránku, která je zdrojem pro data (pro tmem_put_page()) nebo cílem (tmem_get_page()).

Všimněte si, že obě tato volání mohou selhat. Vzhledem k tomu, že velikost fondu není známa, volající nikdy dopředu neví, jestli tmem_put_page() uspěje. Každý uživatel přechodné paměti tedy musí mít v záloze plán pro případ selhání. U fondů označených jako „pomíjivé“ může tmem_get_page() selhat i v případě, kdy tmem_put_page() na stejném ID uspělo; jinými slovy je implementaci dovoleno zahazovat stránky z pomíjivých fondů, když dospěje k rozhodnutí, že tuto paměť by bylo možné lépe využít jinde. Stojí také za to poznamenat, že u soukromých [private] pomíjivých stránek tmem_get_page() odstraní stránku z fondu.

Jako příklad, jak by bylo možné tuto vlastnost využít, vezměme cache stránek v Linuxu, která spravuje kopie stránek souborů na disku. Když paměť dochází, cache stránek začne zapomínat stránky, které jsou čisté, ale ke kterým se v nedávné minulosti nepřistupovalo. S přechodnou pamětí by cache stránek mohla stránky před zahozením zkusit uložit v pomíjivém fondu přechodné paměti. Někdy v budoucnu, když je jedna z takových stránek znovu zapotřebí, ji může cache stránek nejprve zkusit načíst z fondu. Pokud tmem_get_page() uspěje, nemusí se provádět jedna I/O operace disku a všichni získají; v opačném případě je stránka načtena z disku jako obvykle.

Přetrvávající (nepomíjivé) fondy lze použít jako určitý druh swapovacího zařízení. Pokud swapovací kód uspěje se zápisem stránky do fondu, může se vyhnout zápisu do skutečného swapovacího zařízení. Výsledkem je, že se ušetří čas I/O jak při swapování, tak načítání ze swapu. Pokud fond nemá místo pro stránku, která má být odswapována, je stránka zapsána na skutečné swapovací zařízení obvyklým způsobem.

Implementace přechodné paměti se přitom může pokusit optimalizovat svou správu fondů paměti. Hostitelům, kteří jsou aktivnější (nebo kterým byla dána vyšší priorita), může být dovoleno alokovat více stránek z fondů. Duplicitní stránky lze spojit; lze použít techniky podobné těm v KSM, ale v mnoha situacích by ID objektu mohlo zjednodušit detekci duplikátů. A tak dál.

API specifikuje mnoho dalších operací. Je několik volání, které odstraní stránky z fondu; jedno z nich může odstranit všechny stránky s daným ID objektu. Jsou podporovány čtení a zápisy o velikosti menší, než celá stránka; také je zde volání tmem_xchg(), které atomicky vymění data ve stránce přechodné paměti. Kompletní seznam vizte ve specifikaci API.

V následující diskuzi se objevilo několik obav; výsledkem je, že se API zmíněné výše pravděpodobně trochu změní. Největší obavou se nicméně zdá být bezpečnost. Možnost, že by se škodlivý kód připojil do sdíleného fondu a četl stránky, vývojáře znepokojila; to, že nejprve bude muset uhodnout 128bitové UUID se neukázalo jako dostatečné. A i když půjde pouze o legitimní uživatele, sdílený fond má potenciál obsahovat data, která by ve skutečnosti mezi hosty sdílena být neměla. Výsledkem je, že uživatel nadpřirozené paměti bude muset být napsán tak, aby měl na paměti záležitost ohledně vysokého zabezpečení v nízkoúrovňovém kódu.

Dan zdánlivě bezpečnostní problémy nepovažuje za tak znepokojivé jako ostatní. I tak nakonec oznámil, že patch nadpřirozené paměti nebude obsahovat podporu pro sdílené fondy a verze 2 opravdu tuto vlastnost postrádá. Tato vlastnost se pravděpodobně nevrátí, dokud nebudou promyšleny bezpečnostní záležitosti a vyřešeny obavy.

Kromě toho bude přechodná paměť potřebovat nějaké přesvědčivé důkazy, že může zlepšit výkonnost, aby se mohla do hlavní řady dostat. Potenciál pro zlepšení tu zjevně je; v podstatě jde o způsob, jakým systém může vzít v potaz vysokoúrovňové informace, když spravuje své zdroje virtuální paměti. Pokud bude přechodná paměť schopna naplnit svůj potenciál bezpečně, může pro ní v hlavní řadě být místo.

       

Komentáře

[Zdeněk Štěpánek]

Nejak jsem to s tim swapovanim do te pomijive pameti nepochopil...

Takze nejaky proces se zblazni a zacne pozirat pamet. Jadro vezme nepotrebne stranky a misto toho aby je nahazelo do swapu je nahazi do pomijive pameti kde se za chvilku vytratej protoze pamet zere onen zblazneny proces. V pripade ze se jedna o stranky ktere lze z disku znovu nacist (=ze souboru namisto ze swapu) tak se jedna o usporu. Ale vetsinou to prece jsou data programu a ty jaksi jen tak zahodit nelze, musej jit do swapu.

Nicmene by to mohlo byt zajimave treba jako cache pro netovy prohlizec.

Zdenek

[Jiří Svoboda]

Já to pochopil (možná špatně) tak, že by to měla být obdoba ReadyBoost pro Windows...

[Zdeněk Štěpánek]

Takhle jsem to z toho nepochopil. Tohle Readyboost neni vpodstate nic jineho nez prefetch, kterej je v linuxu davno a treba OpenSuse to v nektere sve verzi pouzilo tim stylem ze nacetlo spoustu programu a knihoven z disku do /dev/null, cimz se ty programy usidlily v cache a pri "prvnim" spusteni uz to slo rychle protoze byly v cache.

Spis je zajimavejsi jak to maj wokna ted, ze si vedou jakousi databazi pouzivanych souboru a ty si behem necinnosti nacitaj do ramky. To je to jak lidi nadavaj proc vista furt hrabe na diska nic vlastne nedela.

Zdenek

[petr_p]

Pomíjivá paměť má hlavně smysl u virtualizace, kdy o odebrání paměti rozhoduje hypervizor. Např. každý virtuál dostane garantované minimum a zbytek nevyužité paměti hypervizoru se půjčí virtuálu, který je zrovna hladový. Prostě se vzácná fyzická paměť přelévá mezi virtuály bez rizika swapování.

Otázka ale je, na co bude virtuálu paměť, jejíž data se mohou kdykoliv ztratit. Právě ten krkolomný případ se swapováním byl jaderný příklad.

V uživatelském prostoru je dobrým příkladem ten váš. Já taky úpím, když mi webový prohlížeč zaplní paměť zbytečnostmi, které si stejně může znovu dotáhnout ze sítě, když zrovna teď potřebuji paměť pro jiný proces a zároveň chci pracovat s prohlížečem (tedy nechci, aby mi ho operační systém odswapoval).

Neexistuje náhodou v Linuxu/POSIXu způsob, jak může jádro říct procesu, že dochází paměť, ať nějakou uvolní?

[trekker.dk]

Otázka ale je, na co bude virtuálu paměť, jejíž data se mohou kdykoliv ztratit. Právě ten krkolomný případ se swapováním byl jaderný příklad.

Tipuju, že by mělo být možné zařídit to tak, aby host věděl, že část jeho paměti je pomíjivá. (Stejně jako je možné zařídit, aby věděl, že jeho síťovka ve skutečnosti neexistuje) Potom by se pomíjivá paměť dala používat třeba jako swap či jako cache (samozřejmě jenom pro čisté stránky)

[petr_p]

Samozřejmě. Tak absurdní nedostatek mě ani nenapadl. Jen si prostě nedokážu představit jiné využití než cache, která je zálohována něčím jiným, a to pro použití jádrem. Kromě swapu snad ještě fscache (třeba pro NFS).

[trekker.dk]

Jen si prostě nedokážu představit jiné využití než cache, která je zálohována něčím jiným

I to už se ale docela hodí. Jednou jsem při testování nahodil na 3GB fyzické paměti 8 virtuálů - každý po 512MB RAM. Samozřejmě po chvíli došlo k tomu, že všechny ty stroje použily svou RAM jako cache, takže ve snaze šetřit I/O ho na hostiteli generovaly mnohem víc, protože ta "cache v paměti" se swapovala na disk.

Že by se hodilo mít nějakou možnost říct hostovi "tuhle paměť pokud možno nepoužívej jako cache, protože ve skutečnosti to není paměť", mě napadlo už tenkrát. S pomíjivou pamětí můžeš pro hosty udělat nějaký overcommit paměti a teoreticky by to v nejhorším případě mělo vyjít tak, že se výkon nezmění. Bez ní buď musíš overcommit vynechat, nebo riskovat, že výkon půjde dolů, pokud budou všichni hosti naráz aktivní.

[M. Lox]

Neexistuje náhodou v Linuxu/POSIXu způsob, jak může jádro říct procesu, že dochází paměť, ať nějakou uvolní?

Třeba na AIXu je SIGDANGER, na Linuxu nevím.

[trekker.dk]

Pokud se něco nezměnilo, tak Linux to neumí

[cronin]

Ano, to opisanie transcendentnej pamate ako swap-u je IMHO zavadzajuce. Ma zmysel ako cache, kde sa skutocne predpoklada, ze to, co sa do cache vlozi, tam neskor nemus byt, a existuje alternativny sposob, ako to ziskat.

Co sa tyka toho swapovania, ja som to pochopil tak, "odswapovat" do tej cudnej pamate mozno, ale zaroven to musi byt odswapovane aj perzistentne, a to bud do swap suboru, alebo sa za swap povazuje povodna binarka, odkial sa natiahol kod. V ziadnom pripade odswapovanie do tej pamate neusetri zapis; potencialne vsak moze usetrit citanie.

Mna skor zaujima, co za hw bude vlastne implementovat tuto transcendentnu pamat. "Normalna" pamat to zjavne nebude; ak by bola k dispozicii, patrne by bola pouzivana ako ... normalna pamat. Mam si to predstavit ako nejaky super rychly USB kluc pripojeny cez USB 6.0 , ktory bude moct operacny system pouzit ako pamat, ale v principe ho pouzivatel moze kedykolvek vyrvat von?

[CIJOML]

Producent-konzument je nazev toho algoritmu uceny na ceskych vysokych skolach. Zadny vyrobce.

[cronin]

Tak isto na lavom brehu Moravy.