Jaderné noviny – 13. 5. 2009

12. 6. 2009 | Jirka Bourek | Jaderné noviny | 3075×

Aktuální verze jádra: 2.6.30-rc5. Citáty týdne: Alan Cox, Hugh Dickings, Andrew Morton. Ve stručnosti: reflink(), devtmpfs, Hertzy, /proc/kpageflags. Seccomp a sandbox. TuxOnIce: Zpátky do tepla? Který z I/O řadičů je nejférovější? dm-ioband; io-throttle; io-controller.

Obsah

• Aktuální verze jádra: 2.6.30-rc5
• Citáty týdne: Alan Cox, Hugh Dickings, Andrew Morton
• Ve stručnosti
• Seccomp a sandbox
• TuxOnIce: Zpátky do tepla?
• Který z I/O řadičů je nejférovější?
  • dm-ioband
  • io-throttle
  • io-controller
  • Vybrat jeden

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

Současné vývojové jádro je 2.6.30-rc5 vydané Linusem 8. května. Aktualizace ovladačů (hlavně SCSI, ale změny jsou také ve vstupní vrstvě, síťování, DRI a MD). Aktualizace architektur (většinou podpora ARM „davinci“, ale také něco v x86 a dokonce i v alpha). A různé další náhodné záležitosti (poměrně velká aktualizace cifs, nějaké menší aktualizace ocfs2 a xfs a slušné množství malých jednořádků všude kolem). Všechny detaily vizte v kompletním changelogu.

Současné stabilní jádro 2.6 je 2.6.29.3 vydané 8. května s dlouhým seznamem oprav. 2.6.27.23 bylo vydáno ve stejný čas; jak bylo slíbeno, s aktualizacemi jádra 2.6.28 se končí.

Citáty týdne: Alan Cox, Hugh Dickings, Andrew Morton

Jestliže jsi nedostal žádnou zpětnou vazbu, prostě to v příštím začleňovacím okně zašli. Buď to nikomu nevadilo, nebo si nevšimli – v obou případech dosáhneš zasláním kýženého výsledku.

-- Alan Cox

Přemýšlím o aplikaci, která by připravila stránky plné oplzlých řečí a potom čekala a dívala se na svoje /proc/self/smaps, jestli někdo další píše takové příběhy!

-- Hugh Dickings uvažuje o bezpečnostních rizicích

No, omlouvám se, že jsem do sériové vrstvy natvrdo zakódoval, že tam nebude k mání žádné pivo, aby se ušetřila mikrosekunda, budeš se muset obejít bez něj… mně to funguje, takže tvůj způsob používání není zajímavý.

-- Alan Cox

Ten, kdo vynalezl kopírovat & vložit, se má rozhodně za co zodpovídat.

-- Andrew Morton

Ve stručnosti

Poznámka autora: není žádným tajemstvím, že se v jaderných e-mailových konferencích děje mnohem více, než lze popsat v Jaderných novinách. Důsledkem je, že zde často nejsou zmíněny zajímavé diskuze a vývoj. Tento článek je počátkem experimentální snahy tuto situaci vylepšit. Myšlenkou je stručně zmínit důležitá témata, která se ještě nevyvinula do kompletního článku v Jaderných novinách. Některé položky sledují vývoj dříve zmíněných diskuzí; jiné mohou být předzvěstí článků, které teprve přijdou.

Tento článek „ve stručnosti“ se pravděpodobně neobjeví každý týden. Ale jestli to bude fungovat, měla by se z toho stát polopravidelná záležitost. Komentáře jsou vítány.

reflink(): navržené systémové volání reflink() bylo popsáno minule. Od té doby přišly další verze, reflink() v2 zaslaný 7. května si udržel sémantiku referenční odkaz [reflink] jako snímek [snapshot]. Když byl tázán na toto rozhodnutí, Joel Becker odpověděl, že reflink() je snímkující volání, ne kuchyňský dřez. Zdálo se, že těm, kteří chtěli referenční dokaz jako kopii, nebylo vyhověno.

reflink() v4 zaslaný 11. toto trochu změnil. V této verzi proces, který buď (1) vlastní cílový soubor, nebo (2) má dostatečné kvalifikace, vytvoří odkaz, který kopíruje původní bezpečnostní informace – v podstatě referenční odkaz jako snímek. Proces, který soubor nevlastní a privilegia nemá, ale má možnost cílový soubor číst, získá referenční odkaz s bezpečnostními informacemi „nového souboru“ – referenční odkaz jako kopie. Cílem je udělat správnou věc ve všech situacích, ale někteří vývojáři nyní mají obavy z toho, že toto systémové volání bude mít odlišnou sémantiku pro procesy, které běží pod rootem. Tato konverzace bude ještě pokračovat.

devtmpfs byl také popsán minule. Tento patch byl také zaslán znovu; a výsledná konverzace bude také nějakou dobu pokračovat. Návrat devfs vždycky musel být kontroverzní; první verze konec konců inspirovala flamewary roky předtím, než byla začleněna. Vývojáři devtmpfs mají pocit, že tuto vlastnost potřebují k tomu, aby poskytli distribucím možnost bootovat rychle a spolehlivě v mnoha situacích; další si myslí, že tento problém má lepší řešení. V tuto chvíli není žádný konsenzus o začlenění tohoto kódu, ale stojí za to poznamenat, že diskuze se pomalu přesunula od obecné opozice k opravováním problémů v kódu.

Probouzecí zámky jsou zpět, ale nyní se tento nástroj přejmenoval na blokování uspání. Jádro návrhu je stejné: umožní kódu v jádře nebo v uživatelském prostoru zabránit po krátký čas systému uspat se. API pro uživatelský prostor se změnilo; nyní má podobu zařízení /dev/suspend_blocker, které poskytuje několik ioctl() volání. Uzavření zařízení blokování uvolní, což eliminuje potenciální problém API probouzecích zámků, kdy by pád procesu mohl znamenat zablokování uspávání natrvalo.

O novém kódu bylo relativně málo diskuzí; buď je s ním nyní každý spokojen, nebo si ještě nikdo nevšiml, že byl zaslán.

HZ: Většina jádra je nyní beztiková a vybavená časovači s vysokým rozlišením. Takže, říká Alok Kataria, není důvod provozovat x86 systémy s tikem hodin v intervalu 1 ms. Běh s HZ=1000 měřitelně zpomaluje provádění s CPU spojené smyčky [CPU-bound loop]. Tak proč ho nesnížit?

S nižší hodnotou HZ jsou však problémy, u mnoha z nich je přitom zdrojem stejný problém, kvůli kterému je HZ=1000 méně výkonné: Jádro stále není opravdu beztikové. Ano, periodické přerušení hodin je vypnuté, když procesor nic nedělá. Jenže když je CPU vytíženo, hodiny tikají jako obvykle. Změnit systém tak, aby byl kompletně beztikový, je mnohem obtížnější úkol, než jenom udělat beztikový stav nevytížení; mezi jinými věcmi je potřeba odstranit proměnnou jiffies a všechno, co na ní závisí. Do té doby bude mít snížení HZ také režii.

Wu Fengguang se již nějakou dobu snaží rozšířit /proc/kpageflags, jeho patch přidává spoustu informací o využívání paměti systému. Jeden by si myslel, že přidávání užitečných informací bude nekontroverzní, ale Ingo Molnár tomuto začlenění nadále oponuje. Ingovi se nelíbí ani toto rozhraní, ani fakt, že žije v /proc; řešení, které by preferoval, vypadá spíše jako rozšíření ftrace. Větší přemýšlení nad vytvořením jednotných sledovacích rozhraní vypadá jako dobrý nápad, ale současné rozhraní /proc/kpageflags prokázalo svou užitečnost. Je to také zavedené jaderné ABI, takže jen tak nezmizí. Jestli ale bude rozšířeno, to se uvidí.

Seccomp a sandbox

Roku 2005 Andrea Arcangeli, který byl v té době nejznámější díky své práci na správě paměti, zabrousil na pole bezpečnosti s vlastností „bezpečného počítání“ (nebo „seccomp“). Seccomp mělo podporovat jeho vedlejší projekt, který by vlastníkům linuxových systémů umožnil pronajmout CPU lidem, kteří zpracovávají data. Umožnit cizincům spustit libovolný kód je něco, co lidi znervózňuje; většinou vyžadují poměrně silné záruky, že tento kód nebude mít všeobecný přístup k jejich systémům.

Seccomp tento problém řeší vložením procesů, které spouští cizí kód, do přísného sandboxu (pískoviště). Proces, který běží v režimu seccomp, je značně omezen v tom, co je mu povoleno; má k dispozici pouze čtyři systémová volání – read(), write(), exit() a sigreturn(). Pokus použít jiné systémové volání okamžitě vede k ukončení procesu. Zamýšleno je, že řídící proces získá kód, který má být spuštěn, a nahraje ho do paměti. Poté nastaví popisovače souborů a zavolá:

prctl(PR_SET_SECCOMP, 1);

čímž se zapne režim seccomp. Jakmile je takto omezen, skočí do kódu hosta s tím, že není možné napáchat žádné škody. Kód hosta běží na CPU a komunikuje přes předané popisovače souborů, ale jiný přístup k systému nemá.

Andreova práce na CPUShare se nikdy neuchytila, ale seccomp v jádře zůstalo. Loni v únoru, když byla v kódu seccomp nalezena bezpečnostní chyba, se Linus zabýval tím, jestli se vůbec používá. Zdá se pravděpodobné, že v dané době žádní uživatelé opravdu nebyli, nyní je zde ale jeden významný perspektivní uživatel: Google.

Google nechce seccomp použít k vytvoření distribuované výpočetní sítě; lze předpokládat, že k tomu již budou mít své vlastní řešení. Ve skutečnosti se Google snaží nalézt bezpečný způsob, jak spouštět pluginy ve svém prohlížeči Chrome. Chrome sandbox je popsán takto:

Sandbox využívá zabezpečení poskytované operačním systém k tomu, aby umožnil spuštění kódu, který v počítači nesmí způsobit trvalé změny nebo přistupovat k informacím, které jsou důvěrné. Architektura a přesné záruky poskytované sandboxem závisí na operačním systému. V současnosti je jediná dokončená implementace pro Windows.

Zdá se, že vývojáři v Googlu si myslí, že seccomp by mohla být dobrá platforma, na které by bylo možné postavit „dokončenou implementaci“ pro Linux. Vývojář Googlu Markus Gutchke řekl:

V jednoduchosti seccomp je jeho krása. Je velmi jednoduché ověřit, že dělá správnou věc z bezpečnostního úhlu pohledu, protože jakýkoliv pokus volat nebezpečné systémové volání způsobí, že jádro program ukončí. To je mnohem lepší, než většina řešení založených na ptrace, jejichž správnost je mnohem obtížnější testovat.

Nevýhoda je, že kód v sandboxu musí delegovat vykonávání většiny svých systémových volání monitorovacímu procesu. To je pomalé a poněkud neohrabané. Nicméně díky kouzlu clone() lze (téměř) všechna systémová volání serializovat, poslat monitorovacímu procesu, bezpečně prozkoumat jejich parametry a poté spustit ve jménu procesu v sandboxu. Detaily jsou nudné, nicméně věříme, že jsou řešitelné se současnými jadernými API.

Je zde nicméně malý problém, že kód v sandboxu nemůže užitečně (a bezpečně) volat více než čtyři povolená systémová volání. Toto omezení lze obejít („nudné detaily“), ale utrpí výkonnost. Vývojářům Chrome by se líbila flexibilnější cesta, jak specifikovat, která systémová volání lze zavolat přímo z kódu uvnitř sandboxu.

Jeden návrh, který padl, bylo přidat do seccomp nový „režim“. API bylo navrženo s myšlenkou, že různé aplikace mohou mít jiné požadavky na zabezpečení; zahrnuje hodnotu „režim“, která specifikuje omezení. Implementován byl pouze původní režim, ale ostatní lze rozhodně přidat. Pokud by byl vytvořen nový režim, který by volajícímu procesu umožnil specifikovat, která systémová volání jsou povolena, byl by tento nástroj mnohem užitečnější pro případy, jako je sandbox v Chrome.

Adam Langley (také z Googlu) zaslal patch, který dělá přesně to. Nová implementace „režimu 2“ přijímá bitovou masku popisující, která systémová volání jsou dostupná. Jestliže je jedním z nich prctl(), pak kód v sandboxu může ještě více omezit svá systémová volání (ale nemůže obnovit přístup k těm, která byla zakázána). Ve shrnutí to vypadá jako rozumné řešení, které by mohlo zjednodušit život vývojářům sandboxu.

Tento kód nicméně nikdy nemusí být začleněn, protože od té doby se diskuze posunula k jiným možnostem. Ingo Molnár, který v mnoha situacích argumentoval pro použití frameworku ftrace, si myslí, že ftrace se přesně hodí i pro problém s Chrome sandboxem. Možná má pravdu, ale jenom pro verzi ftrace, která ještě není všeobecně dostupná.

Používání ftrace pro sandbox by se mohlo zdát poněkud zvláštní; od sledovacího frameworku se očekává, že bude hlásit, co se děje, a přitom situaci ovlivňovat co nejméně. Ftrace má ale několik nástrojů, které v takové situaci mohou být užitečné. Sledovač systémových volání je v jádře již teď, takže je snadné oháčkovat všechna systémová volání, která proces může volat. Navíc současný vývojový strom (pravděpodobně určený do 2.6.31) zahrnuje mechanismus filtru událostí, který umožňuje filtrovat události na základě logického výrazu. Používáním ftrace filtrů by sandbox mohl jít dál než k pouhému omezení systémových volání; také by mohl omezit argumenty těchto volání. Příklad, který dodal Ingo, vypadá takto:

{ "sys_read",              "fd == 0" },
{ "sys_write",             "fd == 1" },
{ "sys_sigreturn",         "1" },
{ "sys_gettimeofday",      "tz == NULL" },

Tyto výrazy implementují něco podobného, jako je seccomp režimu 1. read() je ale navíc omezeno pouze na standardní vstup a write() pouze na standardní výstup. Proces v sandboxu také může volat gettimeofday(), ale nemá přístup k informaci o časové zóně.

Výrazy mohou být libovolně komplexní. Také mají být velmi rychlé; Ingo tvrdí, že jsou rychlejší než vyhodnocení háčků bezpečnostních modulů. A pokud není přímé filtrování systémových volání dostatečné, na ostatní místa lze umístit libovolné sledovací body. Ve shrnutí se to zdá jako poměrně obecný mechanismus pro omezení toho, co může proces udělat.

Problém však stále nelze považovat za vyřešený. Kód sledování událostí je velmi nový a zatím většinou nevyužívaný. Stále není v hlavní řadě, což znamená, že může i rok trvat, než se objeví v jádrech dodávaných distribucemi. Kód, který by tomuto mechanismu umožnil řídit vykonávání, ještě nebyl napsán. Chrome tedy ještě nějaký čas nebude mít sandbox založený na něčem jiném, než je seccomp režimu 1 (i když vývojáři Chrome také zvažují použití SELinuxu).

Krom toho existují vážné pochyby, jestli je odchytávání systémových volání správný způsob, jak umístit proces do sandboxu. S ověřováním parametrů, pokud jsou uloženy v uživatelském prostoru, jsou velmi známé obtíže; nepřátelský proces se je může pokusit změnit mezi vykonáním bezpečnostních testů a skutečným použitím dat. Mezi systémovými voláními jsou také zajímavé interakce a je několik způsobů, jak dělat stejnou věc, což všechno může vést k protékajícímu sandboxu. To vše vedlo Jamese Morrise ke stížnosti:

Mám obavu z toho, že vidíme, jak se za běhu vytváří další bezpečnostní schéma bez dobře zformulovaného modelu ohrožení a bez toho, aby se vzaly do úvahy lekce, kterých se nám dostalo ze zdánlivě nekonečné přehlídky podobných schémat, která selhala.

Ingo nicméně obavy nemá; poznamenává, že je možné umístit libovolný filtrující sledovací bod na jakékoliv místo, ne jenom při vstupu do systémového volání. Problémy spojené s odchytáváním systémových volání tedy u schématu založeném na ftrace nemusí být potřeba řešit. Krom toho se zde jedná o specifický druh bezpečnostního problému:

Tvůj argument se týká celosystémového bezpečnostního řešení – při maximalizaci kompatibility a schopností a minimalizaci nepohodlí způsobeného uživateli. To je extrémně obtížný problém s mnoha nástrahami a agenty s teplou vodou, kteří překážejí na cestě. Zde je ale cíl jiný: Cílem je omezit běh velmi brutálním, ale stále výkonným způsobem.

Vypadá to na diskuzi, která bude nějaký čas trvat. Určitě bude opozice proti použítí kódu pro filtrování událostí jako dalšího jaderného jazyka pro bezpečnostní politiku. Může se ukázat, že jednoduché rozšíření seccomp je obecněji stravitelnější. Nebo se může objevit něco úplně odlišného. Je jasné, že sandbox představuje obtížný problém; mnoho chytrých lidí se ho pokusilo implementovat mnoha různými způsoby s různými úrovněmi úspěchu. Nedá se spoléhat na to, že by tentokrát bylo řešení snazší.

TuxOnIce: Zpátky do tepla?

Pokud jde o flamewary, nedávné vlákno na linux-kernel ohledně TuxOnIce bylo poměrně klidné. Pravděpodobně kvůli únavě účastníků z minulých rozvášněných diskuzí se většina z nich nechtěla hádat a zavázala se, že bude spolupracovat na zprovoznění hibernace (tj. uspání na disk) v Linuxu. Zdá se nicméně, že této spolupráci stojí v cestě překážky. Dlouhá historie TuxOnIce mimo strom kombinovaná s neschopností nebo neochotou hlavního vývojáře Nigela Cunninghama spolupracovat s komunitou znamená, že TuxOnIce bude mít do jádra hrbolatou cestu – pokud se tam vůbec dostane.

TuxOnIce, dříve známé jako suspend2 a swsusp2, je dlouho existující řešení hibernace, které není začleněno v hlavním stromu jádra. Má nadšenou komunitu uživatelů a také některé vlastnosti, které swsusp, který představuje hibernační kód v hlavní řadě, nenabízí. Některé z výhod, které má TuxOnIce mít, jsou podpora pro několik swapovacích zařízení nebo běžných souborů, do kterých lze zapsat obraz, lepší výkon díky komprimovaným obrazům a další techniky, které umožňují uložit téměř veškerý obsah paměti včetně cachí atd. Hlasití uživatelé nicméně říkají, že největší výhoda TuxOnIce je, že funguje mnoha lidem – z nichž někteří nejsou schopni zprovoznit mechanismus obsažený v hlavní řadě.

Většina z nedávné práce na hibernaci v hlavní řadě, kterou obecně udělali Rafael Wysocki a Pavel Machek, se zaměřovala na uswsusp, který přesouvá většinu práce s uspáváním do uživatelského prostoru. Jádro již tedy obsahuje dva mechanismy pro hibernaci, což třetímu nedává příliš mnoho šancí na začlenění.

Jsou zjevné neshody o tom, kolik a které části mají být v jádře a které v uživatelském prostoru. Pavel si, zdá se, myslí, že většinu úkolů je možné vyřešit v uživatelském prostoru, zatímco Nigel straní výhodám – výkonnosti a možnosti využít vnitřní jaderná rozhraní – kompletně jaderného přístupu. Rafael je někde uprostřed, zmiňuje některé výhody, které vidí v jaderném řešení:

Jednou výhodou je, že k tomu, aby hibernace fungovala, nepotřebujeme nic v initrd. Další je, že ze zjevného důvodu můžeme získat mnohem lepší výkonnost (méně kopírování dat, rychlejší I/O). Další je jednodušší konfigurace a odpadá nutnost udržovat oddělenou sadu nástrojů pro uživatelský prostor. Možná bych mohl nalézt i další.

Větší rozkol je nicméně v tom, jak dále postupovat. Nigel by rád viděl TuxOnIce začleněný kompletně jako paralelní alternativu k swsusp, s možností nakonec swsusp nahradit a odstranit. Pavel a Rafael na druhou stranu nemají zájem swsusp nahradit; byli by raději, kdyby se postupně navrhovala a začleňovala inkrementální zlepšení – z nichž mnoho přijde z kódu TuxOnIce. Zatímco Nigel by rád začlenil celý subsystém, lidé od swsusp musí subsystém – který většina distribucí používá pro hibernaci – udržovat.

Nigel nedávno zaslal RFC k začlenění TuxOnIce s výhledem na začlenění do 2.6.31 nebo .32 (v závislosti na tom, co bude potřeba udělat předtím, než to bude moci být začleněno, a ochotě těch, na kterých záleží. To se setkalo s poněkud rozpálenou Pavlovou odpovědí, ale Rafael rychle zakročil ve snaze uhasit plameny:

Abych pravdu řekl, považuji za výhodnější pracovat společně a ne flamovat. Prosím, nechte toho, tentokrát se toho nehodlám účastnit.

Poté, co Nigel souhlasil, se diskuze obrátila k tomu, jak spolupracovat, kde se, zdá se, dostala do slepé uličky. Rafael a Nigel přinejmenším vidí některé zjevné výhody kódu TuxOnIce, ale navzdory Nigelovu přání začlenění naráz není pravděpodobné. Nigel svůj plán popisuje takto:

Rád bych viděl všechny tři [swsusp, uswsusp a TuxOnIce] v jednom nebo dvou vydáních vanilla jádra, aby se vyřešily nepředvídané záležitosti. Jakmile bychom si byli jisti, že v TuxOnIce nejsou žádné regrese, odstranil bych swsusp. To je můj ideální plán útoku.

Není překvapivé, že Rafael a Pavel vidí věci jinak. Pavel není proti převzetí některých částí TuxOnIce do hlavní řady: Pokud mluvíme o vylepšení hlavní řady, aby umožnila funkčnost tuxonice… pak ano, to zní rozumě. Rafael navrhl alternativní plán, který se mnohem více drží tradičních vývojových strategií vývoje jádra:

Jde tedy o návrh nahradit současnou implementaci hibernace pomocí TuxOnIce.

S tím bohužel nesouhlasím.

Myslím si, že můžeme dostat jednu implementaci z těchto tří, pravděpodobně se zachováním rozhraní pro uživatelský prostor, aby binárky pro s2disk zůstaly spokojené, tím, že budeme kód TuxOnIce začleňovat postupně. Žádný přístup „všechno naráz“, prosím.

A „začleněním“ myslím přesně to. Žádné přidávání nového kódu a vyhazování starého.

Jak Nigel dále tlačil na pomoc pro začlenění TuxOnIce vedle swsusp, Rafael upozornil na to, že je potřeba velké množství revizí k tomu, aby bylo možné akceptovat obrovskou (10 000+ řádků kódu) sadu patchů: To by zabralo spoustu práce a také bychom museli žádat mnoho dalších zaneprázdněných lidí, aby pro nás udělali spoustu práce. Nigel si, zdá se, chybně myslí, že jaderní hackeři budou ochotni začlenit subsystém, který duplikuje jiný, bez zjevného důvodu. Představení toho, co považuje za nutný přechod od swsusp k TuxOnIce, pravděpodobně nebude tak přesvědčivé.

Pro Nigela je zjevně frustrující mít fungující řešení, ale nebýt schopen ho dostat do jádra. To je ale přímý důsledek práce mimo strom a poté snahy nabídnout řešení, když jádro zamířilo jiným směrem. To je běžná chyba, kterou udělalo mnoho lidí, když jednalo s jadernou komunitou. Ray Lee poskytuje hezkou odpověď na Nigelovu frustraci, ve které ukazuje na implementaci device mapperu od IBM, která byla postižena podobnou reakcí. Ray poznamenává, že Rafael nabídl extrémně cennou výpomoc:

Navrhuje dělat spojku mezi tvým kódem a způsoby, které jsou akceptovány a následovány zde v LKML. Vybírání věcí z celku, hledání dílů, které jsou nekontroverzní a snadno vyargumentovatelné, jejich začlenění do upstreamu s něčím, co je používá, a pak přechod k dalším částem.

Tím se externí patch TuxOnIce bude zmenšovat a zmenšovat, až nakonec zmizí s tím, že veškeré funkce budou v nějaké podobě v jádře.

Je tvůj kód lepší než uswsusp? Téměř určitě. O tom to ale není. Je to o zlepšení tvého kódu oproti tomu, čím je dnes, tím, že projde existujícím procesem revizí a začleňování.

V jednom místě Nigel poukázal na paměťové alokátory SL*B jako na příklad paralelních implementací, které jsou všechny k dispozici v hlavní řadě. Různí lidé odpověděli, že paměťové alokátory jsou poměrně uzavřené, na rozdíl od TuxOnIce. Navíc, jak poznamenává Pekka Enberg: Ano, tak prosím nedělej stejnou chybu, kterou jsme udělali my. Jakmile máš v jádře paralelní implementace, je extrémně obtížné se jich zbavit.

Trochu se diskutovalo o technických aspektech patche TuxOnIce, většina se týkala způsobu, jakým uvolňuje paměť, aby se vytvořilo dost místa pro vytvoření obrazu, přičemž do obrazu se vkládá i obsah této paměti. Způsobem, který závisí na existujícím chování jádra, které není nutně garantováno pro budoucnost, dokáže TuxOnIce zachovat téměř celý obsah paměti, zatímco swsusp zahazuje cache a podobné, aby vzniklo dost volné paměti, kam se obraz uloží. To může mít dopad na výkon, když se po probuzení tyto cache znovu plní. Celkově se nicméně diskuze zabývala cestou kupředu; zatím na této frontě došlo jenom k malému pokroku.

Není to poprvé, co se TuxOnIce dostal do tohoto bodu. V jeho dřívější podobě se ho Nigel pokusil několikrát začlenit do hlavní řady jako swsusp2. V březnu 2004 Andrew Morton žádal, aby byl rozdělen na menší, lépe stravitelné díly. Totéž se stalo koncem roku 2004, když Nigel navrhl přidat swsusp2 jako velkou kouli kódu. Ani tehdy to neskončilo, tu a tam byl vznesen stejný požadavek; v tuto chvíli se asi dá říci, že Nigel prostě navrhovaným způsobem postupovat nechce.

Existuje skutečné nebezpečí, že vlastnosti TuxOnIce, které mají jeho uživatelé rádi, mohou být ztraceny – nebo zůstat mimo strom – pokud se něco nezmění. Buď Nigel uzná, že jediná schůdná cesta, jak dostat TuxOnIce do jádra, je zavedeným způsobem vývoje, nebo někdo jiný vezme kód a udělá to sám. Když nikdo (kromě Nigela) netlačí kód k začlenění, jiná cesta, jak ho tam dostat, neexistuje.

Který z I/O řadičů je nejférovější?

I/O řadič je komponenta systému, jejímž úkolem je řídit přístup k blokovým úložným zařízením; měl by zajistit, že různé skupiny procesů dostanou různou úroveň přístupu v závislosti na politice, kterou definuje správce systému. Jinými slovy brání tomu, aby proces intenzivně používající I/O zabral disk pro sebe. Tato vlastnost může být užitečná v podstatě na každém systému, kde se soupeří o disk; nutností je nicméně na systémech, na kterých běží velké množství virtualizovaných (nebo kontejnerovaných) hostů. V tuto chvíli Linux v hlavní řadě I/O řadič postrádá, mimo hlavní řadu nicméně není žádný nedostatek možností. Tento článek se dívá na některé z projektů I/O řadičů, které se snaží protlačit se do hlavní řady.

Pro účely této diskuze může pomoci odkázat na skromné dílo autora článku Jonathana Corbeta, které vidíte po pravé straně. Zobrazuje zjednodušený pohled na to, jak v linuxovém systému probíhá blokové I/O. Nahoře vidíme několik zdrojů I/O aktivity. Některé požadavky přicházejí z vrstvy virtuální paměti, která čistí špinavé stránky a snaží se udělat místo pro nové alokace. Další přicházejí z kódu souborových systémů a ještě další pocházejí přímo z uživatelského prostoru. Je vhodné poznamenat, že pouze tyto požadavky jsou obsluhovány v kontextu procesu, který je vyvolal; to způsobuje komplikace, ke kterým se vrátíme. Bez ohledu na zdroj se požadavky nakonec octnou v blokové vrstvě, která je vyznačena jako velký modrý obdélník.

V blokové vrstvě mohou být I/O požadavky nejprve obslouženy jedním nebo více virtuálními blokovými ovladači. Mezi ty patří kód device mapperu, vrstva MD RAID atd. Nakonec (možná modifikované) požadavky směřuji k fyzickému zařízení, ale předtím se dostanou k I/O plánovači, který se snaží optimalizovat I/O aktivitu podle své vlastní politiky. I/O plánovač se snaží co nejvíce omezit pohyb hlavičkou na rotujících úložištích, ale také může implementovat I/O priority nebo další s politikou spojené záležitosti. Když se mu zdá, že přišel správný čas, přepošle I/O plánovač požadavky fyzickému blokovému ovladači, který nakonec zajistí, že jsou vykonány hardwarem.

To vše je relevantní, protože je možné připojit I/O řadič do kterékoliv úrovně v tomto diagramu – a různí vývojáři řadičů udělali přesně to. Jak uvidíme, každá z vrstev má své výhody a nevýhody.

dm-ioband

Patch dm-ioband, jehož autorem je Ryo Tsuruta (a další), pracuje ve vrstvě virtuálního blokového ovladače. Implementuje nový cíl device mapperu (nazvaný „ioband“), který dává prioritu procházejícím požadavkům. Politika je jednoduchý proporcionální váhovací systém; požadavky jsou děleny na skupiny, z nichž každá obdrží pásmo v závislosti na váze, kterou jí přidělí správce systému. Skupiny mohou být definovány podle ID uživatele, ID skupiny, ID procesu nebo skupinou procesů. Ke správě slouží nástroj dmsetup.

dm-ioband funguje tak, že každé skupině přiřadí hromádku „žetonů“. Pokud je I/O provoz nízký, řadič se drží z cesty. Jakmile se však provoz dostatešně zvýší, každé skupině se naúčtuje každý procházející požadavek. Jakmile skupině žetony dojdou, její I/O se vloží do seznamu, kde bude, nemilované, strádat, zatímco požadavky ostatních skupin budou dále vyřizovány. Jakmile všechny skupiny, které aktivně generují I/O, vyčerpají své žetony, každý dostane novou sadu a proces začne nanovo.

Základní kód dm-ioband má pár zajímavých omezení. Jedno je, že nepoužívá mechanismus kontrolních skupin [control group], což by se normálně od řadiče zdroje očekávalo. Také má opravdu problém s I/O operacemi, které asynchronně generuje jádro. V mnoha případech – možná ve většině – jsou I/O požadavky vytvářeny jadernými subsystémy (například správou paměti), které se snaží uvolnit zdroje a které nejsou vykonávány v kontextu žádného specifického kontextu. Tyto požadavky nemají snadno dostupnou návratovou značku, která by říkala, komu patří, takže dm-ioband neví, komu je účtovat. Běží tedy pod radarem a významně snižují hodnotu celého tohoto cvičení s I/O řadičem.

Dobrá zpráva je, že oba problémy mají řešení v podobě patche blkio-cgroup, který také vytvořil Ryo. Patch vytváří rozhraní mezi dm-ioband a mechanismem kontrolních skupin, takže řízení šířky pásma je možné aplikovat na libovolnou kontrolní skupinu. Na rozdíl od ostatních řešení dm-ioband stále nepoužívá kontrolní skupiny pro nastavení politiky šířky pásma; kontrolní skupiny se opravdu používají jenom k definici skupin procesu, se kterými pracovat.

Další vlastnost, kterou přidává blkio-cgroup, je mechanismus, kterým lze identifikovat vlastníka jakéhokoliv I/O požadavku. Za tímto účelem přidává položky do pole struktur page_cgroup v jádře. Toto pole je udržováno subsystémem řadiče využití paměti; struct page_cgroup lze považovat za hromadu věcí navíc přidaných do struct page. Na rozdíl od struct page ale struct page_cgroup není používána na horkých kódových cestách v jaderné správě paměti a je obecně z dohledu, takže si lidé většinou nevšímají toho, když roste. Pro každou stránku v paměti je ale v systému jedna struct page_cgroup, takže jde o velké pole.

Toto pole již má prostředky k identifikaci vlastníka každé dané stránky v systému. Nebo přinejmenším identifikuje nějakého vlastníka; nijak se nesnaží sledovat několik vlastníků sdílených stránek. Patch blkio-cgroup do tohoto pole přidává nějaké položky, které zjednodušují zjištění toho, která kontrolní skupina je spojená s danou stránkou. Vzhledem k tomu a vzhledem k tomu, že blokové I/O požadavky obsahují adresy relevantních stránek v paměti, není těžké dohledat kontrolní skupinu a s každým požadavkem ji spojit. Moduly jako dm-ioband potom tuto informaci mohou využít k řízení šířky pásma využívané všemi požadavky, ne jenom těmi, které přicházejí přímo z uživatelského prostoru.

Výhody dm-ioband zahrnují integraci s device-mapperem (pro ty, kteří device mapper používají) a relativně malou a dobře uzavřenou kódovou základnu – tedy alespoň dokud se do směsi nepřidá blkio-cgroup. Na druhou stranu je nutné s dm-ioband používat device mapper a plánovací rozhodnutí provedená zde pravděpodobně nepomohou I/O plánovači na nižší úrovni implementovat politiku správně. A nakonec dm-ioband neposkytuje žádnou garanci kvality služby [quality-of-service]; jednoduše zajišťuje, že každá skupina dostane přibližně požadované procento dostupné propustnosti I/O.

io-throttle

Patche io-throttle, jejichž autorem je Andrea Righi, používají odlišný přístup. Tento řadič od počátku používá mechanismus kontrolních skupin, takže se všechny parametry politiky nastavují přes virtuální souborový systém kontrolních skupin. Hlavním parametrem každé kontrolní skupiny ja maximální šířka pásma, kterou může skupina spotřebovat; io-throttle tedy místo dělení dostupné šířky pásma tak, jak to dělá dm-ioband, vynucuje absolutní hodnoty. (Shodou okolností mohou oba řadiče také omezovat počet I/O operací místo šířky pásma.) Je zde také hodnota „výška hladiny“; určuje úroveň využití, pod níž se žádné omezování neprovádí. Každá kontrolní skupina má svou vlastní výšku hladiny, takže je možné určit, že jsou některé skupiny omezovány dříve než jiné.

Každá kontrolní skupina je spojena se specifickým blokovým zařízením. Pokud chce správce nastavit identické politiky pro tři různá zařízení, je potřeba vytvořit tři kontrolní skupiny. Tento přístup nicméně umožňuje nastavit různým zařízením různé politiky.

Dalším zajímavým rozhodnutím při návrhu io-throttle je jeho umístění do struktury I/O: pracuje na vrcholu, kde I/O požadavky vznikají. Tento přístup znamená nutnost vložit volání cgroup_io_throttle() všude, kde mohou být generovány požadavky na I/O. Objevují se tedy v různých částech subsystému správy paměti, v kódu dopředného čtení [readahead] a zpětného zápisu [writeback], ve vrstvě synchronního I/O a samozřejmě v kódu předávajícím I/O hlavní blokové vrstvy. Kvůli tomu je patch io-throttle o trochu invazivnější než některé jiné.

Omezování na této úrovni má však výhodu: Umožňuje io-throttle zpomalit I/O tím, že jednoduše proces způsobující I/O na chvíli uspí; to je obecně preferované nad zaplněním paměti naplánovanými strukturami BIO. Spaní není vždy možné – například ve velkých částech subsystému virtuální paměti se to považuje za ubohost – io-throttle tedy občas musí I/O požadavky řadit do fronty.

Kód io-throttle neposkytuje pravou kvalitu služby, ale dostává se k ní o něco blíž. Pokud správce systému blokovému zařízení nenaloží víc, než může zvládnout, pak by každá skupina měla dostat šířku pásma, která jí byla přidělena. Tento řadič řeší problém asynchronně generovaných I/O požadavků stejně, jako to dělá dm-ioband: používá kód blkio-cgroup.

Výhody přístupu io-throttle zahrnují relativně jednoduchý kód a možnost omezovat I/O tím, že se uspí proces. Na druhou stranu práce na úrovni generování I/O požadavků znamená, že je potřeba zaháčkovat mnoho jaderných subsystémů – a tyto háčky udržovat. Omezování I/O na této úrovni také může kolidovat s politikami I/O priority implementovanými na úrovni I/O plánovače.

io-controller

Jak dm-ioband, tak io-throttle trpí významným problémem: Mohou narušit politiky (jako je například I/O priorita) implementované I/O plánovačem. Vzhledem k tomu, že modul pro řízení šířky pásma je z praktického pohledu I/O plánovačem sám o sobě, jeden by si myslel, že by dávalo smysl řídit šířku pásma na úrovni I/O plánovače. To přesně dělají patche io-controller Viveka Goyala.

Io-controller poskytuje koncepčně jednoduchý, na kontrolních skupinách založený mechanismus. Každá kontrolní skupina obdrží váhu, která určuje její přístup k šířce I/O pásma. Kontrolní skupiny v io-controller nejsou spojeny se specifickým zařízením, takže stejná váha se aplikuje na každé zařízení v systému. Jakmile je proces vložen do kontrolní skupiny, jeho šířka pásma je alokována z váhy této skupiny bez potřeby dalších zásahů – alespoň pro bloková zařízení, která používají jeden ze standardních I/O plánovačů.

Kód io-controller byl navržen tak, aby fungoval se všemi I/O řadiči v hlavní řadě: CFQ, Deadline, Anticipatory a no-op. Aby fungoval, vyžaduje významné změny těchto plánovačů; všechny potřebují mít hierarchický, férově plánující mechanismus, který implementuje politiku alokace šířky pásma. Plánovač CFQ již má jednu úroveň férového plánování, ale kód io-controller potřebuje druhou – jedna úroveň implementuje současný algoritmus férového plánování CFQ – včetně I/O priorit – kdežto druhá aplikuje omezení šířky pásma pro skupiny. To znamená, že omezení šířky pásma lze aplikovat způsobem, který nenaruší ostatní rozhodnutí o plánování I/O, která učiní CFQ. Ostatní I/O plánovače postrádají násobné fronty (i na jedné úrovni), takže je patch io-controller musí přidat.

Vivekův patch začíná tím, že z CFQ odstraňuje současný vícefrontový kód, přidává do něj více úrovní a dělá z něj součást obecného kódu výtahu [elevator]. Tím se všem I/O plánovačům umožňuje ho využívat s (relativně) malými změnami v kódu. Kód CFQ se významně zmenšuje a ostatní plánovače příliš nerostou. I Vivek řeší problém s asynchronními požadavky kódem blkio-cgroup.

Tento přístup má zjevnou výhodu v tom, že omezování šířky pásma provádí způsobem, který je konzistentní s ostatními politikami implementovanými I/O plánovačem. Je dobře uzavřený v tom, že nepotřebuje umístit háčky do jiných částí jádra a nepotřebuje používat device mapper. Na druhou stranu je to rozhodně největší patch řadiče šířky pásma, neumí implementovat různé politiky pro různá zařízení a ještě nefunguje se všemi I/O plánovači spolehlivě.

Vybrat jeden

Množení řadičů šířky pásma je považováno za problém minimálně od minulého roku. Není žádný zájem na tom začlenit více řadičů, takže v nějakém okamžiku bude potřeba jeden vybrat. Doufalo se, že různí vývojáři, kterých se to týká, se dají dohromady a shodnou se na jedné implementaci, ale to se ještě nestalo, takže Andrew Morton nedávno prohlásil:

Mám pocit, že vás, chlapi, je potřeba zavřít v jedné místnosti a vrátit se za 15 minut.

Ale vážně, jak tohle budeme řešit? Mohli bychom zamknout v jedné místnosti mě a vrátit se za 15 dní, ale není důvod myslet si, že se objevím s nejlepší odpovědí.

V dubnu na Storage and Filesystem Workshop se účastníci úložné koleje [storage track], zdá se, hodně přikláněli k řešení na úrovni I/O plánovače – a tím k io-controller. Cyničtější z nás by mohli být v pokušení poukázat na to, že Vivek tam byl, zatímco vývojáři konkurenčních nabídek ne. Takoví lidé by se nicméně také měli zeptat, proč by měl být problém plánování I/O řešen na nějaké jiné úrovni.

V každém případě vývojáři dm-ioband a io-throttle ve své práci nepřestali od doby, co se workshop konal, a širší jaderná komunita se v této oblasti ještě nerozhodla. Celkový obraz tedy je jenom o něco méně zamlžený než předtím. Snad jediná oblast, ve které panuje shoda, je využití blkio-cgroup ke sledování asynchronně generovaných požadavků. Co se toho ostatního týče, řešení v podobě zamčené místnosti nakonec možná ještě bude nutné.

       

Komentáře

[Ludvík Vlček]

joj,

to je dneska porce...

díky za takovovou míru podrobností.

[Robert Krátký]

Také Jirkovi děkuji za trpělivost. Dnešní díl je opravdu hodně dlouhý.

[Lukáš Czerner]

Jednoduše vynikající ! Díky

[martin()]

Proces v sandboxu také může volat gettimeoufday(), ale ...

Ďakujem za ďalší skvelý článok .

[deda.jabko]

účastníci úložné koleje

me dostali do kolen... ;-] v tomto priklade bych to asi neprekladal...

[Robert Krátký]

Já vím, ale "storage track"? Co s tím? Jak to vysvětlit?

[trekker.dk]

...no právě.

[deda.jabko]

jsem se vzdycky setkal s tim, ze i v cestine se pouzival termin ,,track''... ale asi bych to zkusil prelozit opisem, i.e.,

,,V dubnu na Storage and Filesystem Workshop se účastníci sekce věnované ukládání dat [storage track]...''

[PEPP]

Jak jsem to cetl znacne unaveny brzkym vstavanim, tak jsem na tohle slovicko ziral dost dlouho nez jsem ho "vyresil"

[Robert Krátký]

Dík.