Jaderné noviny – 28. 10. 2009

27. 11. 2009 | Jirka Bourek | Jaderné noviny | 3389×

Aktuální verze jádra: 2.6.32-rc5. Citáty týdne: David Woodhouse, Robert Bradbury, Ingo Molnár. Momentka z Tokia. Tracefs. Ovladače vyhozené do staging. /proc a práva adresářů. JLS2009: Obecné odlehčování při příjmu. JLS2009: Aktualizace Btrfs. Transparentní velké stránky. KS2009: Staging, linux-next a vývojový proces.

Obsah

• Aktuální verze jádra: 2.6.32-rc5
• Citáty týdne: David Woodhouse, Robert Bradbury, Ingo Molnár
• Momentka z Tokia
• Tracefs
• Ovladače vyhozené do staging
• /proc a práva adresářů
• JLS2009: Obecné odlehčování při příjmu
• JLS2009: Aktualizace Btrfs
• Transparentní velké stránky
• KS2009: Staging, linux-next a vývojový proces

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

Současné vývojové jádro je stále 2.6.32-rc5; během minulého týdne nebyly vydány žádné předverze.

Současné stabilní jádro je 2.6.31.5, vydané (společně s 2.6.27.38) 22. října. Aktualizace 2.6.27 je relativně malá a zaměřená na SCSI a USB zařízení; aktualizace 2.6.31 naopak řeší mnohem větší rozsah problémů.

Citáty týdne: David Woodhouse, Robert Bradbury, Ingo Molnár

Bylo by možné znovu prohledat RMRR tabulky, když vyjmeme zařízení ze si_domain, pokud bychom opravdu museli. Ale budu chtít pramen vlasů od člověka zodpovědného za tenhle postup, abych si mohl vyrobit voodoo panenku.

-- David Woodhouse

Jestliže je softwarový systém tak složitý, že nelze jednoduše identifikovat jeho záludnosti a pasti a vyhnout se jim (vizte například zprávu o problému s ondemand plánovačem na Pentiu IV, kterou jsem nedávno zaslal), pak to efektivně není open source. Jsem kvalifikován ke čtení manuálů k hardwaru, jsem kvalifikován k přepisování C kódu (napsal jsem generátory kódu k několika překladačům C), ale LKML je jako větrný mlýn a já se cítím jako Don Quijote, který na něj útočí. Dalo by se dokonce dohadovat, že chybějící otevřený systém pro hlášení chyb (a online zprávy o „současném stavu“) efektivně z Linuxu dělá systém, který není open source. Neměl by Linux být mezi prvními v tom, že zpřístupní všechny informace? Nebo je odsouzen k nahrazení systémy, které takové vlastnosti nabídnou (například Androidem???)

-- Robert Bradbury

Skutečný gitový strom bude obsahovat opravy pro chyby, ze kterých je člověku na blití, bude obsahovat reverty, bude obsahovat příležitostný ošklivý changelog. Tak tomu je, protože to víc odpovídá skutečnému životu, je to mnohem důvěryhodnější strom, ze kterého přetahovat. Nic nezlepší způsob práce víc než veřejné zahanbení – změna základního bodu nicméně velkou část tohoto faktoru veřejného zahanbení odstraňuje

-- Ingo Molnár

Momentka z Tokia

Vydání Windows 7 náhodou vyšlo na stejný čas jako Japan Linux Symposium v Tokiu. Na Linuse Torvaldse zjevně nové Windows udělaly velký dojem – a Chris Schlaeger byl u toho a okamžik zvěčnil. Původní obrázek je k dispozici zde.

Vizte také: Fotografie Lena Browna z Jaderného summitu a JLS.

Tracefs

Sledování v jádře se rychle stává vlastností, se kterou vývojáři a uživatelé počítají. V současných jádrech se nicméně všechny virtuální soubory, které se používají k řízení a přístupu k datům, nacházejí v souborovém systému debugfs v adresáři tracing. To není považováno za dlouhodobé řešení; debugfs má obsahovat nestabilní, ladící informace, ale uživatelé sledování by raději stabilní ABI na místě, které se nepoužívá pro ladění.

Po několika diskuzích na konferencích se Greg Kroah-Hartman rozhodl dát hierarchii sledovacích souborů nějakou formu vytvořením nového virtuálního souborového systému tracefs. Tracefs vypadá hodně podobně jako …/debug/tracing v tom, že soubory byly prostě přesunuty z jednoho místa na druhé, má však mnohem jednodušší interní API, protože nepotřebuje všechny vlastnosti podporované v debugfs.

Nápad samostatného tracefs byl všeobecně podpořen, ale tento konkrétní patch nevypadá jako něco, co by bylo brzy začleněno. Je tu obava z toho, že cokoliv, co bude přesunuto z debugfs do nějakého stabilnějšího umístění, se stane součástí jaderného ABI. Většina ze současných sledovacích rozhraní vznikla podle okamžité potřeby; stále ještě chybí ten způsob myšlení, který je zapotřebí k definici rozhraní, které má zůstat stabilní po další roky.

Ingo Molnár si myslí, že virtuální soubory, které popisují dostupné události, by měly být vyexportovány již teď, ale o moc víc by toho být nemělo. To ponechává většinu ostatních rozhraní v nestabilním stavu. Greg tedy patch stáhl; očekávejme, že se s ním vrátí, až vývojáři sledování budou více připraveni definovat ABI. V takové situace můžeme očekávat začátek debaty ohledně skutečně důležité otázky: /tracing, nebo /sys/kernel/tracing?

Ovladače vyhozené do staging

Strom staging vznikl jako způsob, kterým se ovladačům na úrovni pod standardem umožní dostat se do jádra. Nedávno se nicméně mluvilo o tom, jak použít staging i jako způsob, kterým by se ovladače snáze odstraňovaly. Nápad je takový, že zjevně nepoužívané a neoblíbené ovladače by byly přesunuty do stromu staging, kde by tři vývojové cykly umíraly. Pokud by se během té doby nepřihlásil nikdo, kdo by je udržoval, byly by ze stromu odstraněny. Tato myšlenka byla diskutována na Jaderném summitu a neobjevily se větší námitky.

Od té doby se John Linville rozhodl systém otestovat sérií pradávných bezdrátových ovladačů. Mezi ně patří ovladač „strip“ (STRIP je rádiový protokol vyvinutý pro projekt MosquitoNet – k přenášení internetového provozu přes rádia Metricom.) společně s ovladači arlan, netwave a wavelan. Zdá se, že o tento kód se nikdo nestará a je nepravděpodobné, že by ho ještě někdo používal. Pokud je to tak, nemělo by odstranění mít žádné nevýhody.

To ale stížnosti nezastavilo, většinou si stěžovali lidé, kteří věří, že odstraňování ovladačů přes staging z jádra je zneužití procesu takovým způsobem, který by mohl poškodit nicnetušící uživatele. Je pravda, že uživatelé si této změny jenom těžko všimnou předtím, než ovladače skutečně zmizí – i když jejich distributoři je mohou zahodit ještě předtím, než to udělá hlavní řada. Potenciál pro nepříjemné překvapení tu tedy je; chybné odstranění lze snadno vrátit zpět, ale to je pro uživatele, jehož systém právě přestal fungovat, jenom malá útěcha.

Problém je ale v tom, že není jiný způsob, jak ze stromu odstranit starý kód. Bylo nebylo, změny API by způsobily, že se nespravovaný kód nepřeloží; po delším období nefunkčnosti by kód bylo možné bezpečně odstranit. Současná etiketa nicméně vyžaduje, aby vývojář po změně API opravil všechny jeho uživatele ve stromě, takže tento indikátor již neexistuje. To znamená, že se strom může zaplnit kódem, který se nepoužívá a který již dávno nefunguje, ale stále se přeloží bez chyb. Je potřeba nějak najít způsob, jak takový kód odstranit. Proces „vyhodit přes staging“ nemusí být perfektní, ale lepší nápad zatím nikdo nenavrhl.

/proc a práva adresářů

Při diskuzi o patchi pro příznak otevření O_NODE se objevila zajímavá, i když pravděpodobně nezneužívaná, bezpečnostní díra. Jamie Lokier si problému všiml a Pavel Machek ji posléze zaslal do bezpečnostní e-mailové konference Bugtraq.

Za normálních okolností by jeden očekával, že soubor v adresáři s oprávněními 700 bude nepřístupný pro všechny kromě vlastníka (a roota samozřejmě). Jamie a Pavel ukázali, že toto omezení lze obejít použitím záznamu v adresáři fd útočícího procesu v souborovém systému /proc.

Pokud je někdy útočníkovi adresář přístupný, když je soubor přítomen, může tento soubor otevřít pro čtení a mít ho otevřený, i když oběť změní práva na adresář. Jakýkoliv normální zápis do popisovače souboru selže, protože byl otevřen pouze pro čtení, ale zápis do /proc/$$/fd/N, kde N je číslo otevřeného popisovače souboru, uspěje podle práv nastavených souboru. Jestliže soubor umožňuje útočícímu procesu zápis, pak zápis do /proc uspěje bez ohledu na práva nadřazeného adresáře. To je vcelku proti intuici a i když jde o poněkud vykonstruovaný příklad, zdá se, že je to bezpečnostní chyba.

Vlákno v Bugtraq se rychle dostalo mimo téma s poznámkou, že podobného jevu lze dosáhnout vytvořením pevného odkazu na soubor předtím, než se změní oprávnění adresáře. I když to je pravda, Pavlův příklad takové situaci předešel tím, že se podíval na počet odkazů na daný soubor předtím, než se změnila práva adresáře. Případ s pevným odkazem by v tu chvíli byl rozpoznán.

Lze si představit situace, ve kterých programy nenastaví souborům, které používají, správná oprávnění, a správce se pokusí problém obejít tím, že omezí přístup k nadřazenému adresáři. S použitím této chyby by útočník k takovým souborům mohl přistupovat dále způsobem, který je obtížné zjistit. Jak Pavel poznamenal, odpojení /proc problém odstraní, ale ani tak si nemyslí, že by připojení /proc mělo měnit sémantiku řízení přístupu.

V současnosti se diskutuje o tom, jak – a v určitém rozsahu zda vůbec – problém řešit, ale konsenzus (a patch) se ještě neobjevily.

JLS2009: Obecné odlehčování při příjmu

Autor tohoto článku (Jonathan Corbet) si stále pamatuje instalaci svého prvního ethernetového adaptéru. Za cenu obrovského úsilí techniků se DECu podařilo toto zařízení vměstnat na spojený pár UNIBUS desek – celkem na víc než polovinu čtverečního metru – takže bylo možné systém VAX připojit k moderní síti. Podpora 10 Mb/s byla v těch dnech trochu problém. V pozdějších dnes se špičkové síťové adaptéry dostaly na rychlost 10 Gb/s – zrychlení o tři řády. Podporovat tuto rychlost je stále výzva, i když tentokrát z jiných důvodů. Na Japan Linux Symposium 2009 Herbert Xu přednesl, jak se Linux vyvinul, aby tuto výzvu mohl plnit.

Část problémů spočívá v tom, že 10G Ethernet je stále Ethernet. To má svou hodnotu; minimalizuje to potřebné změny v ostatních částech systému. Je to ale stará technologie, která si s sebou přináší těžké břímě, přičemž největším z nich je maximální jednotka pro přenos dat [maximum transfer unit, MTU] o velikosti 1500 B. S velikostí paketu omezenou na 1500 B bude spojení o rychlosti 10 G běžící plnou rychlostí přenášet přes 800 000 paketů za sekundu. Opět jde od dob 10 Mb o rozdíl tří řádů, ale zde neudrželo tempo CPU – množství času CPU, které je k dispozici ke zpracování jediného ethernetového paketu je tedy menší, než kdysi bylo. Není potřeba říkat, že to na subsystém síťování vyvíjí větší tlak; množství času potřebné ke zpracování každého paketu musí být zmáčknuto, kdykoliv je to možné.

(Někdo by mohl namítnout, že i když rychlosti jednotlivých CPU tempo neudržely, vzrostl počet jader, což rozdíl vyrovná. To je pravda, ale předmětem Herbertova projevu byla výkonnost na jediném CPU, a to z několika důvodů: Jakákoliv práce na výkonnosti musí být přínosná i pro jednoprocesorový systém a distribuce práce jediného adaptéru mezi několik CPU má své vlastní problémy.)

Vzhledem k důležitosti režie spojené s jednotlivými pakety by se jeden mohl zeptat, jestli by nedávalo smysl zvýšit MTU. To je možné; mechanismus „obřích rámců“ [jumbo frame] může zvládnout pakety do velikosti 9 kB. Podle Herberta je problém v tom, že „došlo k Internetu“. Většina spojení, která nás zajímají, jde přes Internet a všechna jsou tedy omezena nejnižší MTU po cestě. Tato MTU je občas dokonce menší než 1500 bytů. Existují na protokolech založené mechanismy, kterými lze zjistit, jaká je nejnižší MTU, ale ty na Internetu nefungují dobře; konkrétně je znemožní většina konfigurací firewallů. Takže i když obří rámce mohou na lokální síti pomoci, smutný fakt je, že na Internetu máme jenom 1500 bytů.

Když nemůžeme použít větší MTU, můžeme se pokusit o druhou nejlepší možnost: Předstírat, že používáme větší MTU. Již pár let Linux podporuje síťové adaptéry, které „přebírají zátěž segmentace TCP“ [TCP segmentation offload, TSO]. S adaptérem podporujícím TSO jádro může připravit mnohem větší pakety (řekněme 64 kB) pro odchozí data; adaptér potom zajistí segmentaci dat na menší pakety, když se data vysílají do drátů. To snižuje režii jádra spojenou s paketem čtyřicetkrát. TSO je v Linuxu podporováno dobře; pro systémy, které z větší části data vysílají, je dostatečné k tomu, aby 10GB síť fungovala plnou rychlostí.

Jádro ve skutečnosti obsahuje mechanismus „obecného přebírání zátěže segmentace“ [generic segmentation offload, GSO], který není omezený na TCP. Ukazuje se, že výkonnost se zlepšuje, i když je tato vlastnost emulována ovladačem. GSO ale funguje jenom pro vysílání dat, ne jejich příjem. Toto omezení je naprosto v pořádku pro uživatele, kteří hlavně vysílají; místa, která poskytují do sítě obsah, například vysílají mnohem více dat, než jich přijímají. Na jiných místech jsou ale jiné typy zátěže a pro ně je režie přijímání paketů stejně důležitá jako režie vysílání.

Řešení na přijímací straně se objevovalo pomaleji a nejenom proto, že první uživatele mnohem více zajímala výkonnost při vysílání. Optimalizace na straně příjemce je těžší, protože přijímání paketů je obecně těžší. Když se data vysílají, má jádro kompletní kontrolu a je schopné omezit vysílající procesy, pokud je to nutné. Příchozí pakety jsou ale zcela asynchronní události pod kontrolou někoho jiného a jádro se prostě musí vyrovnat s tím, co přichází.

I tak se řešení objevilo v podobě „odlehčení při rozsáhlém příjmu“ [large receive offload, LRO], které používá velmi podobný přístup: Příchozí pakety jsou při přijetí spojovány, takže jich operační systém vidí méně. Toto spojování může zajišťovat buď zařízení, nebo hardware; dokonce i emulace LRO v ovladači má výkonnostní přínos. LRO je v linuxových ovladačích pro 10G široce podporováno.

LRO je ale podle Herberta trochu špatně fungující řešení; problém je v tom, že „spojí všechno, co vidí“. Tato transformace je ztrátová; mezi hlavičkami příchozích paketů jsou důležité rozdíly a tyto rozdíly se ztrácí. A tím se věcí rozbíjí. Pokud systém funguje jako router, opravdu by neměl měnit hlavičky paketů, které jím prochází. LRO může úplně rozbít satelitní spojení, ve kterých poskytovatelé dělají s hlavičkami velmi podivné triky, aby celá ta věc fungovala. Bridgování se rozbíjí, což je vážný problém: Většina konfigurací pro virtualizaci používá virtuální bridge mezi hostem a klienty. Používání LRO by se v takových situacích dalo jednoduše vypnout, ale právě tyto situace většinou bývají ty, které opravdu chceme optimalizovat. Virtualizované síťování je pomalejší už tak; jakákoliv možná optimalizace v této oblasti je značně zapotřebí.

Řešením je obecné odlehčení při příjmu [generic receive offload, GRO]. U GRO je značně omezeno, za jakých okolností je možné pakety spojit; MAC hlavičky musí být stejné a jenom pár TCP a IP hlaviček se smí lišit. Sada hlaviček, které se smí lišit, je omezena významně: Kontrolní součty jsou různé nutně a pole IP ID se může zvětšovat. Identické musí být i časové značky [timestamp] TCP, což je menší omezení, než by se mohlo zdát; časová značka je pole s relativně nízkým rozlišením, takže není neobvyklé, když má spousta paketů stejnou značku. Výsledkem těchto omezení je, že spojené pakety lze opět bezeztrátově segmentovat; výhodou navíc je to, že kód GRO lze použít k resegmentaci.

Další hezká vlastnost GRO je to, že na rozdíl od LRO není omezeno na TCP/IPv4.

Kód GRO byl začleněn do 2.6.29 a je podporován mnoha 10G ovladači. Konverze ovladačů na GRO je poměrně jednoduchá. Největší problém je pravděpodobně to, že nové ovladače jsou psány tak, že používají API LRO. Aby se tomu zabránilo, mohlo by být API LRO nakonec odstraněno, jakmile budou vývojáři síťování přesvědčeni, že GRO je plně funkční a nezůstávají v něm žádné výkonnostní regrese.

V reakci na dotazy Herbert řekl, že nebyla velká snaha o to používat LRO v ovladačích pro 1G. Obecně se současná CPU dokáží vyrovnat s datovým proudem 1G bez velkých potíží. Výhodu by to nicméně mohlo mít pro embedded systémy, které typicky mívají pomalejší procesory. Jak se jádro rozhodne o tom, jak dlouho bude čekat na příchozí pakety před jejich spojením? Ukazuje se, že není potřeba žádný zvláštní čekací kód: API NAPI se již umí příležitostně dotazovat ovladačů na nové pakety a zpracovávat je v dávkách. GRO lze jednoduše provádět při tom.

Dalším krokem by mohlo být „obecné slučování založené na toku“ [generic flow-based merging]; také by mohlo být možné začít spojovat nesouvisející pakety, které míří ke stejnému cíli, aby se vytvořily větší směrovací jednotky. Slučování UDP je na seznamu věcí, které je potřeba udělat. Mohlo by být výhodné i slučovat TCP ACK pakety. Tyto pakety jsou malé, ale je jich hodně – typicky jeden pro každé dva datové pakety jdoucí opačným směrem. Tato technologie se může vydat překvapujícími směry, ale jedna věc je jistá: Vývojářům síťování rozhodně nechybí nápady, jak v Linuxu umožnit držet tempo s rychlejším a rychlejším hardwarem.

JLS2009: Aktualizace Btrfs

Konference mohou být dobrými příležitostmi k získání přehledu o současných projektech. I detailní čtení relevantních e-mailových konferencí nemusí vždy osvětlit to, co vývojáři chystají dále, zatímco veřejné prezentace je mohou inspirovat k tomu, aby řekli, nad čím přemýšlí. Dobrý příkladem takového projevu je přednáška Chrise Masona o Btrfs na Japan Linux Symposium.

Souborový systém Btrfs byl začleněn do jádra 2.6.29, z větší části to bylo proto, aby se podpořilo širší testování a vývoj. Rozhodně tenkrát nebyl míněn k produkčnímu použití. Lidé odvádějí na Btrfs spoustu práce, takže se dostává do stavu, kde je pro odvážné uživatele dostatečně stabilní. Současné Btrfs obsahuje v Kconfig velkými písmeny napsané varování, že formát na disku ještě není stabilní; Chris plánuje toto varování odstranit, možná pro vydání 2.6.33. Btrfs se jinými slovy vyvíjí rychle.

Jeden nedávný přírůstek je plné použití komprese zlib. Změna velikosti a defragmentace za běhu fungují hezky. Také se pracuje na tom, aby dobře fungovaly synchronní I/O operace.

Defragmentace je v Btrfs jednoduchá: Specifický soubor lze defragmentovat tak, že se načte a zapíše zpět. Vzhledem k tomu, že Btrfs je souborový systém s kopírováním při zápisu, nový zápis souboru bude tak spojitý, jak to souborový systém bude schopen zajistit. Tento přístup lze také použít k řízení rozvržení souborů na souborovém systému. Jako experiment vzal Chris hromadu dat ze sledování bootu systému Moblin a analyzoval je, aby zjistil, ke kterým souborům se přistupovalo a v jakém pořadí. Poté přepsal dotyčné soubory tak, aby se všechny uložily na stejnou část disku. Výsledkem byla poloviční doba I/O při bootu, což vedlo k rychlejší inicializaci systému a úsměvům všude okolo.

Výkonnost synchronních operací byla během minulého roku významnou záležitostí. Na souborových systémech jako ext3 volání fsync() zapíše spoustu dat, která nesouvisí se souborem, kvůli kterému se fsync volalo; to přidává velký výkonnostní postih a odrazuje to od bezpečného programování. Btrfs situaci zlepšil tím, že se pro každý souborový systém, který používá synchronní I/O operace, vytvoří oddělený B-strom. Když přijde volání fsync(), může Btrfs tento strom použít k tomu, aby se vynutily operace pouze pro specifický soubor. To mu umožňuje významné výkonnostní zlepšení oproti ext3 i ext4.

Dalším zlepšením by bylo zapsat sadu souborů a potom vynutit jejich zápis jedinou operací. Btrfs by to mohlo udělat, ale POSIX nemá způsob, jakým jádru říct, že má zapsat několik souborů naráz. Oprava pravděpodobně bude spočívat ve vytvoření nového systémového volání.

Btrfs poskytuje mnoho vlastností, které jsou také k dispozici pomocí subsystémů device mapperu a MD; někteří lidé se ptali, jestli tato duplikace vlastností dává smysl. Má to ale dobré důvody; Chris udal několik příkladů:

• Vytváření snímků [snapshot] ve vrstvě device mapperu/LVM zahrnuje mnohem více kopírování relevantních dat. Chris udělal experiment, ve kterém vytvořil 400MB soubor, vytvořil několik snímků a poté soubor přepsal. Btrfs je schopen prostě zapsat novou verzi, přičemž umožní všem snímkům používat starou kopii. LVM místo toho pro každý snapshot data zkopíruje; tento test, který na Btrfs běžel méně než dvě vteřiny, trval na LVM okolo deseti minut.

• Každý, kdo musel vyměnit disk v RAID, ví, že proces obnovy pole může být dlouhý a bolestivý; zatímco se kopírují všechna data, pole běží pomalu a nenabízí obvyklé ochrany. Výhoda provozování RAIDu v Btrfs spočívá v tom, že souborový systém ví, které bloky obsahují užitečná data, a které ne. Takže zatímco RAID založené na MD musí zkopírovat celý obsah disku, Btrfs stačí zkopírovat používané bloky.

Co na nás tedy čeká v budoucnu? Chris říká, že jádro 2.6.32 bude obsahovat verzi Btrfs, která bude pro první uživatele dostatečně stabilní na to, aby si s ní mohli hrát. Se štěstím bude souborový systém v 2.6.33 obsahovat podporu pro RAID4 a RAID5. V 2.6.34 se poté věci ještě více stabilizují. Chris byl nicméně typicky rezervovaný ohledně produkčního nasazení s tím, že vždy trvá několik let, než se vyvine kompletní důvěra v nový souborový systém. Takže zatímco ti s dostatkem zvědavosti, odvahy a dobrých záloh možná budou používat Btrfs během roku, k širokému přijetí pravděpodobně dojde později.

Transparentní velké stránky

Většina linuxových systémů dělí paměť na 4096B stránky; pro většinu kódu správy paměti je to nejmenší jednotka paměti, se kterou lze manipulovat. 4 kB je nárůst oproti tomu, co se používalo v prvních systémech správy paměti; dříve bylo běžných 512 bytů. To je ale stále málo v porovnání jak s velikosti fyzické paměti dostupné na současných systémech, tak s velikostí dat, se kterými na těchto systémech pracují aplikace. To znamená, že operační systém musí spravovat více stránek, než tomu bylo před několika lety.

Většina současných procesorů může pracovat se stránkami většími než 4 kB. Používat větší stránky má výhody: Velikost tabulky stránek klesá, stejně tak klesá počet výpadků stránky, který je potřeba k tomu, aby se aplikace nahrála do RAM. Velká výkonnostní výhoda také pochází z toho, že velké stránky vyžadují méně pozic [slot] v TLB. Na většině systémů jsou tyto pozice zdrojem, o který se značně soupeří; omezení případů, kde se adresa v TLB nenajde, může výkonnost významně vylepšit při mnoha zátěžích s velkým využíváním paměti.

Využívání velkých stránek má také nevýhody. V důsledku interní fragmentace se zvyšuje objem vyplýtvané paměti; extra data, která je nutné tahat dokolečka s pamětí, ke které se příliš nepřistupuje, také mohou být drahá. Větší stránky trvá déle přenést ze sekundárního úložiště, což zvyšuje latenci výpadku stránky (přičemž to omezuje počet výpadků). Čas potřebný k jednoduchému vynulování velkých stránek může znamenat vytvoření významných latencí jádra. Ze všech těchto důvodů operační systémy raději využívají menší stránky. Krom toho mít jedinou a malou velikost stránky jednoduše funguje a má to výhodu mnohaletých zkušeností.

Jsou nicméně výjimky. Jaderná virtuální paměť se mapuje do obrovských stránek [huge page]. Pro uživatelský prostor je tu „hugetlbfs“, který lze použít k vytvoření a používání velkých stránek pro anonymní data. Hugetlbfs byl přidán, aby se uspokojila okamžitá potřeba velkých databázových systémů, které používají rozsáhlá pole v paměti. Je úzce zaměřen na malý počet případů použití a má významná omezení: Obrovské stránky musí být rezervovány dopředu, v nouzi nelze transparentně použít malé stránky, jsou uzamčeny v paměti a musí být nastaveny pomocí speciálního API. To fungovalo dobře, dokud byla jediným uživatelem určitá proprietární databáze. Roste ale zájem o používání velkých stránek i jinde; konkrétně virtualizace, zdá se, vytváří novou sadu požadavků pro tuto vlastnost.

Andrea Arcangeli zaslal patch transparentních obrovských stránek, který se pokouší situaci zlepšit tím, že odstraňuje dělení mezi velkými stránkami a běžným subsystémem virtuální paměti v Linuxu. Jeho cíl je poměrně ambiciózní: Byl by rád, aby aplikace mohly požadovat velké stránky jednoduše systémovým voláním madvise(). Pokud budou k dispozici velké stránky, systém je aplikacím poskytne v reakci na výpadek stránky; pokud ne, použijí se menší stránky.

Kromě toho tento patch umožňuje velké stránky odswapovat. To není tak jednoduché, jak to vypadá; subsystém swapu v současnosti není schopen pracovat s pamětí jinak, než v jednotkách o velikosti PAGE_SIZE. Odswapovat velkou stránku tudíž vyžaduje nejprve ji rozebrat na náhradní díly. To funguje, ale ne všichni souhlasí s tím, že to má cenu. Christoph Lameter zaslal komentář, ve kterém říká, že zátěže citlivé na výkonnost se stejně swapování vyhýbají, což ale nemusí být vždy úplně pravda na hostiteli, který se plní virtualizovanými hosty.

Vlastnost, která přijde v budoucnu, je transparentní znovusestavení velkých stránek. Pokud taková stránka byla rozdělena (nebo ji vůbec nebylo možné alokovat), bude mít aplikace mnoho malých stránek rozesetých v paměti. Pokud by se uvolnila velká stránka, bylo by hezké, kdyby si toho kód správy paměti všiml a přesunul tyto malé stránky do jedné velké. To by se potenciálně mohlo dít i u aplikací, které velké stránky vůbec nepožadovaly; jádro by jim je prostě ve výchozím nastavení poskytlo, pokud by se mu zdálo, že to má smysl. Tím by byly velké stránky opravdu transparentní a možná by se tím zároveň podařilo snížit fragmentaci paměti.

Jde o ambiciózní patch vnitřního kódu linuxového jádra, takže je možná úsměvné, že největší stížnost se zabývá tím, že nezachází dost daleko. Moderní procesory x86 mohou podporovat mnoho velikostí stránek až do obrovských 1 GB. Andreův patch má nicméně v úmyslu používat stránky o velikosti 2 MB – o dost méně. Důvod je jednoduchý: 1GB stránky jsou příliš neskladnou jednotkou paměti na to, aby se s nimi dalo pracovat. Žádný linuxový systém, který nějakou dobu běží, nebude mít k dispozici tolik spojité paměti a latence spojená s operacemi jako nulování takových stránek by byla příliš velká. Andi Kleen si nicméně myslí, že tento přístup je krátkozraký; dnes obrovský kus paměti je zítra stručný e-mail. Andi by byl radši, kdyby systém nebyl navržen podle dnešních omezení; zatím nedošlo k žádné shodě.

V každém případě je tento patch v současnosti RFC; v blízké budoucnosti nebude mířit do hlavní řady. Je to však zjevně něco, co Linux potřebuje; plné využívání schopností procesoru vyžaduje chovat se k velkým stránkám jako k plnohodnotným objektům správy paměti. Jednou bychom všichni měli velké stránky používat – i když o tom možná nebudeme vědět.

KS2009: Staging, linux-next a vývojový proces

Poslední dvě diskuze na Jaderném summitu 2009 se zabývaly tím, jak funguje vývojový proces. První, kterou vedl Greg Kroah-Hartman, se zaměřila na role stromů stable, staging a linux-next.

Strom stable byl vyřízen krátce: Zdá se, že jsou všichni spokojeni s tím, jak tento strom (který existuje již čtyři roky) funguje. Jsou stabilní stromy udržovány dostatečně dlouho? Zdá se, že odpověď je „ano“, alespoň od lidí v místnosti. Greg poznamenal, že pokračuje ve správě 2.6.27, protože to zjednodušuje jeho práci; současný plán je, že správu převezme Willy Tarreau (současný správce 2.4), až Greg přestane. Trochu se mluvilo o zlepšení informací prezentovaných na kernel.org, aby uživatelé viděli, co je k dispozici a co se stále udržuje.

Další na řadě byl linux-next. Stephen Rothwell prohlásil, že v posledním začleňovacím okně 22 % ze změn, které šly do hlavní řady, předtím nebylo v linux-next. Greg toto číslo prohlásil za „děsivé“, ale Linus si myslí, že pokrytí ze 78 % je naopak poměrně dobré. To je obzvláště pravdivé, když uvážíme, že většina ze zbývajícího provozu jsou rychle vyvinuté opravy problémů, které se objevily po začlenění změn do hlavní řady.

Andrew Morton byl nicméně i tak poněkud nabručený na vývojáře, kteří nabuší patche, pak je honem rychle ženou do hlavní řady a přitom občas něco rozbijí. Jejich motivaci chápe – nechtějí na patchích sedět dalších několik měsíců, než se otevře příští začleňovací okno – ale i tak by byl radši, kdyby lidé byli opatrnější. Měl za to, že by mělo být možné toto chování detekovat automaticky a zastavit ho. Tento nápad se ale příliš nelíbil.

Byla položena otázka, jestli je obecně lepší posílat opravy regresí rovnou do hlavní řady, nebo jestli je nejprve nechat trochu otestovat v linux-next. Mnoho vývojářů bylo pro to druhé, ale v takovém případě si jiní stěžují, že nejsou k dispozici urgentně potřebné opravy. Linus navrhl, že by to vývojáři se zpožďováním začleňování oprav neměli přehánět; občas je lepší poslat je hned.

Co se staging týče: Krátce bylo diskutováno téma „přes strom staging ven“. Zdá se, že proti tomuto návrhu nejsou námitky; cokoliv, co pomůže dostat starý kód z jádra, je považováno za dobrou věc.

Trochu se mluvilo o bezdrátových ovladačích ve stromě staging. Jejich existence je považována ze odměnu společnostem, které komunitu příliš nepodporují, s tím, že to snižuje snahu vytvořit skutečné řešení problému. Jednoduchý fakt ale je, že tyto ovladače nyní fungují a umožňují lidem používat svůj hardware. John Linville upozornil na to, že Ralink začal platit vývojáře, který pracuje na problémech s ovladači, takže by se situace měla zlepšit.

Pravděpodobně nejsilnější diskuze byla rezervována pro téma ovladače Nouveau – ovladače pro grafické čipové sady NVIDIA vytvořené reverzním inženýrstvím. Fedora Nouveau dodává, ale ve stromě staging není, což je považováno za porušení pravidel. Nouveau není ve staging, protože ho tam jeho vývojáři nechtějí. Zdá se, že jsou zde dvě záležitosti:

• Ovladače pro grafiky obecně zahrnují velké množství kódu v uživatelském prostoru a široké rozhraní mezi uživatelským prostorem a jádrem. Team Nouveau by si rád udržel možnost měnit ABI mezi komponentami dle libosti; vložení ovladače do stromu staging je považováno za omezení této flexibility.

• Jednou z věcí, které ovladače Nouveau dělá při startu, je, že do hardwaru nahraje velký blob. Nikdo neví, co tento blob („voodoo“) dělá. Může to být firmware, může to být něco jiného. Konkrétně to může být něco, na co se vztahují samostatná autorská práva a není to volně šiřitelné. Blob bude z ovladače vyňat a považován za firmware, ale to samo o sobě není kompletní řešení problému. Jak bude tato záležitost řešena, zůstává nejasné.

Objevila se kritika Fedory za to, že dodávají ovladač, který není v hlavní řadě; je velká šance, že už to v nejbližší době dělat nebudou.

Vývojáři mluvili o vyhazování ovladačů, které se nezlepšují. Konkrétně se zdá, že ovladače pro Android se nikdy nedostanou do slušného stavu a budou ze staging vyhozeny v 2.6.33. Google je dál tlačit nebude, ale, což je zajímavé, Qualcomm – ne vždy známý svou účastí v komunitě – pracuje na začlenění ovladačů pro telefon G1. (Martin Bligh mimo diskuzi řekl, že vývojáři ChromeOS jsou v jiné skupině s jinými procedurami a budou více orientování na upstream než skupina okolo Androidu.)

Sečteno a podtrženo – strom staging je považován za úspěšný experiment. Přivedl do hlavní řady spoustu externího kódu, kde se přinejmenším část rychle zlepšila. Staging se také ukázal jako dobrý způsob, jak přibrat nové programátory k práci na jádře.

Dále se mluvilo o vývojovém procesu obecně, diskuze se vrátila k problému, který se již několikrát objevil: Vývojáři, kteří zašlou patch, jsou žádáni, aby ho přepracovali způsobem, který značně překračuje rozsah původní práce. Například vývojářům DRBD bylo řečeno, že by měli sjednotit implementace RAID v jádře, aby byla implementace jejich zařízení začleněna. Vývojáři se shodli, že s těmito požadavky bychom měli být rozumnější a že by většinou měly být považovány spíše za doporučení. Jednu věc, kterou je možné udělat, by bylo začlenit patch a poté vznést požadavek; tak by vývojáři viděli nějaký pokrok a dalo by se jasně najevo, že jejich patche nejsou drženy jako rukojmí.

Linus řekl, že na Jaderný summit obvykle jezdí přinejmenším s jednou záležitostí, která ho štve. Letos je ale relativně spokojený. Začleňovací okna fungují dobře, vývojový proces běží hladce a nejsou žádné specifické subsystémové stromy, které by považoval za „černé puntíky“. Dokonce i chování v e-mailových konferencích se zlepšuje.

Trochu se mluvilo o pravidlech začleňovacího okna a o výjimce, která umožňuje začleňování ovladačů po vydání -rc1. Linus prohlásil, že tato výjimka existuje, protože nemá rád černobílá pravidla a protože chce mít flexibilitu k převzetí kódu, pokud to zjevně dává smysl. Ale jinak opravdu chce, aby se veškerý nový kód objevil během začleňovacího okna. Ovladač může příležitostně přijít později, ale opravdu by to měla být výjimka a neměl by to být jeden z „hororových ovladačů“.

Linus má také rád podmíněné požadavky na přetažení – takové, které říkají „tento kód by mělo být bezpečné začlenit, ale není to nutné“. Potom kód může nebo nemusí přetáhnout podle nálady a podle toho, co se aktuálně děje; ta flexibilita je dobrá a on rád ví, že daný kód čeká, i když není přetažen hned. Také požádal o e-maily s aktualizací, když se strom změní mezi požadavkem na přetažení a skutečným přetažením. Pokud přetahovaný strom neodpovídá požadavku, stojí ho čas zjistit proč.

Začleňovací okno funguje dobře, ale jádra -rc3 a -rc4 bývají i tak příliš velká. Linus by byl raději, kdyby se věci zklidnily rychleji. Proto prosil, aby lidé po -rc1 netlačili věci, které nejsou nutné.

Nakonec se mluvilo o občasných dlouhých sériích patchů, které jsou posílány znovu a znovu aniž by se významněji zlepšovaly. Když je sada patchů obrovská, vždycky je v ní něco, co lze opravit, takže je těžké ji začlenit. Odpovědí je zde pokusit se sérii rozdělit na menší kousky a ty začleňovat jeden po druhém.

       

Komentáře

[hikikomori82]

v JLS2009: Obecné odlehčování při příjmu je na fotke zla adresa

[Jary]

4kB of memory page should be enough for everybody ;)

[Jary]

Sorry, tohle nemělo být tady tak, jak tady je.

[hikikomori82]

To ako vazne nikomu nevadi ze je tam zle ten odkaz?

[Jan Přech]

Trond Myklebust ma prima triko

[Jirka]

Mozna by bylo fajn, kdyby existoval nejaky automaticky reportovaci nastroj, ktery by reportoval vyvojarum (at uz primo vyvojarum jadra nebo zprostredkovane pres distributory), ktere casti jadra se na danem pocitaci vyuzivaji. Lidi, co maji v pocitaci bezne zelezo, by to ani nemuseli moc pouzivat, ale lidi, co maji nejaky obskurni hardware, by jiste uvitali, kdyby se vyvojari o jejich stavu dovedeli bez vynalozeni jakekoli namahy.

[Gilhad]

Pri navrhu by ale bylo potreba se zamyslet i nad tim, ze si mnozi uzivatele nepreji zasilani "nejakych informaci nekam" jen tak, bez sveho souhlasu a kontroly. Ten nastroj by mel jit snadno nastavit, snadno vypnout a mel by byt dobre zdokumentovany a ryze nepovinny.

[kralyk z abclinuxu]

Dík za zajimavé počtení, jako obvykle...

[Radim Kolář]

$subj

[m;)]

tak tak .. zda sa ze freebsd je v tomto o krok dva dalej .. system sam rozhoduje o pouziti velkych ci malych stranok, dokaze robit "konverzie", aplikacie nemusia byt specialne pisane a teda vsetko funguje out-of-box, co je zrejme spravna cesta.

"The FreeBSD virtual memory subsystem now supports fully transparent use of superpages for application memory; application memory pages are dynamically promoted to or demoted from superpages without any modification to application code. This change offers the benefit of large page sizes such as improved virtual memory efficiency and reduced TLB (translation lookaside buffer) misses without downsides like application changes and virtual memory inflexibility. This can be enabled by setting a loader tunable vm.pmap.pg_ps_enabled to 1 and is enabled by default on amd64."