Jaderné noviny – 15. 12. 2010: Triky pro vyšší efektivitu virtualizace

3. 1. 2011 | Jirka Bourek | Jaderné noviny | 4124×

Aktuální verze jádra: 2.6.37-rc5. Citáty týdne: Linus Torvalds, Andrew Morton. Přímé předání CPU. Řízení odmapovaných stránek v cache.

Obsah

• Aktuální verze jádra: 2.6.37-rc5
• Citáty týdne: Linus Torvalds, Andrew Morton
• Přímé předání CPU
• Řízení odmapovaných stránek v cache

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

Současné vývojové jádro je stále 2.6.37-rc5; minulý týden nevyšly žádné předverze. Linus se vrátil z cest a začal znovu začleňovat patche, takže novou verzi lze očekávat v blízké budoucnosti.

Stabilní aktualizace: 9. prosince vyšly aktualizace 2.6.27.57, 2.6.32.27 a 2.6.36.2. Greg Kroah-Hartman poznamenává, že to je poslední jádro 2.6.27, které vydal, a že jej k dlouhodobé údržbě předává Willymu Tareauovi (ve shodě se změnami ve stabilních stromech, které oznámil 3. prosince.) 57 verzí za 791 dní, obsahovalo 1596 patchů (což není nejvíce pro stabilní řady, .32 to již překonalo.) [...] Když mluvíme o .32, silně doporučuji všem uživatelům .27 přechod ke stromu .32.

Aktualizace 2.6.35.10 byla svým novým správcem Andi Kleenem vydána - s více než 200 patchi - 15. prosince. Andi říká: Tato verze obsahuje bezpečnostní opravy a všem uživatelům je doporučeno aktualizovat.

Citáty týdne: Linus Torvalds, Andrew Morton

Právě teď cestuju bez přístupu ke svému laptopu, takže nemůžu nic přetahovat. Nebylo to záměrem, ale můj laptop byl zabrán kvůli důležitějším věcem (dítě ho potřebovalo do školy a můj další laptop má rozbitý harddisk), takže jenom čtu e-maily v mobilu.

-- Linus Torvalds potřebuje port gitu na Android

Když se něco abstrahuje, má to tendenci zůstat napořád. Když máš ošklivý dočasný hack pro speciální případ, je dobré, že tam sedí uprostřed kódu a civí na tebe. Je velmi explicitní a nezapomeneš na něj.

-- Andrew Morton

Přímé předání CPU

napsal Jonathan Corbet, 15 prosince 2010

Současná CPU mají zajímavou vlastnost: dokáží poznat, že virtualizovaný host čeká ve smyčce na zámek, a předat tuto informaci jádru hostitele. Účelem je zajistit, aby hostitel mohl najít něco lepšího, co by procesor mohl dělat. KVM na to v současnosti zareaguje tím, že se na chvíli uspí, což umožňuje běh procesů mimo virtualizovaný systém. Jak ale upozornil Rik van Riel, to nemusí být správně.

Jestliže jedno vlákno ve virtualizovaném systému čeká na zámek, pak jiné vlákno v tomto systému musí ten zámek držet. Místo pozastavení celého hosta je lepší spustit vlákno, které drží zámek, aby ho bylo možné uvolnit. Pozastavení hosta jenom zpozdí uvolnění zámku, takže virtuální stroj jako celek je penalizován; to, jak říká Rik, vede k situaci, kdy hostu s Windows a 64 VCPU trvá věčnost a ještě něco k tomu, než nabootuje. Můžeme být v pokušení prostě obvinit Windows, ale pravděpodobně bude lepší problém opravit.

Rik mění to, jak se obsluha zachycené události [trap handler] chová; místo toho, aby se CPU vzdala úplně, vezme časový podíl vlákna čekajícího v cyklu a předá ho procesu na jiném CPU. Doufá se, že příjemce tohoto daru (efektivně se jedná o zvýšení priority) bude ten, kdo drží zámek, ale v současnosti to není nijak garantováno. Tato funkce je implementována novou funkcí yield_to(), o které Rik říká, že by ji bylo možné změnit na systémové volání, pokud by se ukázalo, že to bude užitečné.

Patch prošel několika koly revizí a možná si najde cestu do 2.6.38.

Řízení odmapovaných stránek v cache

napsal Jonathan Corbet, 13 prosince 2010

Virtualizace na hostitelský systém přináší nějaké zajímavé požadavky, mnoho z nich se týká správy paměti. Když dva prvky na stejném systému věří, že mají paměť na povel, musí nastat zajímavé konflikty. Nedávný patch, jehož autorem je Balbir Singh, ukazuje snahu na tyto konflikty reagovat, ale také naznačuje mnohem ambicióznější snahu o to, jak problém vyřešit.

Cache stránek v Linuxu udržuje v hlavní paměti kopie stránek a doufá, že se vyhne I/O operacím, když se k těmto stránkám přistupuje. Ve většině situací si cache stránek může snadno vzít více než polovinu z celkové paměti systému. Skutečná velikost cache stránek se postupem času mění; když narůstá objem paměti využité jinak (paměť jádra, anonymní stránky), cache stránek se zmenší, aby udělala místo. Balancování mezi požadavky cache stránek a ostatními uživateli paměti může být náročné, ale Linux to většinou dělá skoro správně.

Balbirův patch má správci systému dát o něco větší kontrolu nad využíváním cache stránek; za tímto účelem poskytuje nový parametr předávaný při bootu (unmapped_page_control), který nastavuje horní hranici počtu odmapovaných stránek v cache. „Odmapované“ [unmapped] stránky jsou takové, které nejsou namapovány do adresového prostoru žádného procesu – neobjevují se v žádné tabulce stránek [page table]. Odmapované stránky mají menší šanci, že je někdo bude v nejbližší budoucnosti potřebovat; systém se jich také může snáze zbavit. Tento patch tedy správci systému umožňuje relativně snadno minimalizovat spotřebu paměti cachí stránek.

Zjevná otázka: proč? Když systém bude potřebovat paměť jinde, stránky z cache stránek se uklidí i tak, takže se nezdá, že by mělo smysl ji zmenšovat předčasně. Problém je, zdá se, virtualizace. Když proces na virtualizovaném systému načte stránku ze souboru, operační systém hosta uloží kopii ve své cache stránek. Skutečné čtení nicméně bude předáno (a vykonáno) hostitelem, který si také uloží kopii do cache stránek. Jedna stránka se tedy cachuje dvakrát – nebo také vícekrát, pokud ji používá více virtuálních strojů. Cachovat stránku může být dobré, ale cachovat několik kopií je dobré až moc.

To, co dělá Balbirův patch, by se dalo vysvětlit takto: vynutí vyklizení kopií stránek z cache stránek hosta, aby se minimalizovaly duplikátní kopie. Paměť, která se takto uvolní, může být zabrána balónovým ovladačem a vrácena hostiteli k produktivnějšímu použití někde jinde.

Taková technika by situaci mohla zjevně zlepšit. Menší duplikace je dobrá a když host bude některé z uvolněných stránek potřebovat, pravděpodobně se najdou v cache stránek hostitele. Nelze se nicméně nepozastavit nad tím, jestli tento přístup není až příliš nepřímý. Než vynuceně uvolňovat stránky z cachí hostitelů, nebylo by lepší, kdyby všechny systémy sdílely stejnou cache stránek? Jednu unifikovanou cache by bylo možné spravovat tak, aby se maximalizovala výkonnost celého systému; to by mělo vést k lepšímu výsledkům, než spravovat několik zdánlivě nezávislých cachí stránek.

Virtualizace založená na kontejnerech má přesně takový typ sjednocené cache, protože všechny kontejnery běží na stejném jádře. To může být jeden z důvodů, proč se kontejnery považují za výkonnější než plně virtualizované systémy. Dostat sdílenou cache do světa virtualizace by nicméně mohlo být poněkud náročné, což je pravděpodobně hlavní důvod, proč to nikdo ještě neudělal.

Pro začátek jsou tu jasné záležitosti spojené s bezpečností. Virtualizovaný systém by neměl mít možnost přistupovat ke zdrojům, které mu nebyly přiřazeny. Jakákoliv sdílená cache stránek by se musela navrhnout tak, aby hostitel měl kontrolu nad tím, které stránky který host vidí. Prakticky by to znamenalo používat virtualizované blokové oladače, které nyní virtualizovaným hostům zpřístupňují souborové systémy. Místo „načtení“ stránky do stránky pod kontrolou hosta by ovladač mohl nějak namapovat kopii hostitele do adresového prostoru hosta.

Aby to fungovalo správně, muselo by se přidat nové, linuxové API mezi hostem a hostitelem. Bylo by těžké udělat to tak, aby se udržovala iluze, že host běží na vlastním hardwaru. Takovéto schéma by zkomplikovalo správu paměti hosta – hardware je sice čím dál tím dynamičtější, ale jednotlivé stránky ještě pořád nepřicházejí a nemizí spontánně. Sdílená cache stránek by také překážela pokusům používat pro paměť hosta obrovské stránky.

Jinými slovy potíže spojené se sdílením cache stránek mezi hostem a hostitelem rozhodně nevypadají triviálně. Není překvapením, že stále žijeme ve světě, kde se vzácné stránky v paměti plní duplikovanými kopiemi dat. Dokud se tato situace nezmění, bude tu místo pro patche, díky kterým se hosté budou chovat přátelštěji k systému jako celku.

       

Komentáře

[Pavel Stárek]

Mě by se spíš hodily triky pro menší latence (respektive menší zaškubávání) desktopu, například při kopírování souborů z/na disk .

[magor367]

Muzete zkusit BFS, ja jsem celkem spokojen :)

http://en.wikipedia.org/wiki/Brain_Fuck_Scheduler
http://zen-kernel.org/

[geebranz]

CPU transfer

Rely

[b fgngYD]

Ciastocne riesenie je i kupa ssd, ktore sa pouzije ako cache pre zvysok systemu (http://bcache.evilpiepirate.org/) Ja sa to prave pokusam nasadit na desktope, kde mam raid5 na 5 diskoch na vsetky data, pricom system je na raid10 (4 disky, ktore su zdielane s raid5 diskami = dokopy 5 diskov v bedni). Tiez ma trapi hlavne zapis na disk. Pri stahovani nejakeho blbuntu dvdcka cez torrent mi miestami zasekne cely komp (fluxbox).

BFS planovac mam vsak v plane tiez urcite vyskusat. Mala by to byt lepsia cesta.

[Michal]

On RAID5 obecne neni k zapisu moc pratelsky (typicky se musi nejdriv cist ze vsech 5 disku, spocitat nova data a zapsat) takze me neprekvapuje ze system spatne reaguje pri masivnich zapisech ve tvoji konfiguraci. IMO RAID 5 nebo 6 ma smysl jen v SAN nebo NAS diskovych polich ktere umi ruzne triky na zrychleni zapisu. Primo do desktopu nebo do serveru (nebo jako DAS pole) je lepsi RAID10 jelikoz ten jen zapisuje a nemusi predem nic cist.

[b fgngYD]

Som si toho plne vedomy, avsak potrebujem maximalizovat vyuzitelne miesto a do home adresaru malokedy zapisujem vela. Horsie je na tom adresar filmy, ale raz za mesiac, kedy s nim daco robim to uz prezijem.

Podla nejakej studie som cital, ze pri raid5 je nutne precitat len paritu, teda citat z jedneho disku a da sa zapis uskutocnit i s tymto nacitanim jedneho bloku. Neviem, ci je to i v linuxovom mdraide implementovane, ale skor nie.

Btw, vie mi niekto poradit, ako odtestujem co najspolahlivejsie vykon filesystemu? Ide mi o to, ze ked vytvorim ext3/4 particiu, daju sa jej odovzdat stride a podobne parametre. Nikde som nenasiel, aky to ma dopad na vykon a chcel som spravit nejake porovnanie. Zatial som experimentoval len s iozone a vzhladom na 12GB ram mi to rychlosti citania dalo kus skreslene i pri vacsich testovacich suboroch. (Tiez zarovnanie lvm budem mat asi nespravne, len sa nemam cas tomu venovat :-/ )

[Osvetitel]

RAID 5 ale nema paritu jen na jednom disku...

[Gilhad]

Dovedu si predstavit reseni, kdy se nacte menena oblast + parita, z toho se vypocte "parita bez oblasti" a pak "parita s novou oblasti" a pak se ulozi oblast a nova parita. U pomaleho disku a rychleho procesoru by to mohlo byt vyhodne, ale jestli to nekdo napsal a jestli se to pouziva fakt nevim.

[ebik]

Efektivne ma jeden paritni disk. To ze je pro ruzne "stripy" parita na ruznych diskach je vec druha. A jinak jak jiz tu psal Gilhad prede mnou: teoreticky staci precist prave jen paritu a menenou oblast a pak do nich zapsat nove hodnoty.

Nicmene pri zapisu velkych souboru staci pockat na tolik dat aby se zapisoval cely "pruh" ("stripe") - pak neni potreba nic cist. Predpokladam, ze takovou optimalizaci by i linux mohl mit. V pripade velikosti bloku raidu 64k a raid5 na peti diskach to dela 256k.

[Honza]

Ad cache:

Neni treba resenim mit virtualni disky na pseudo fs ktery necachuje ?

Napr: na AIXu mam moznost mountovat fs s options rbrw,cio,dio, ktere krome jineho zpusobi primy zapis na disk. Vyuziti to ma napr. u db systemu kdy sama databaze cachuje dle nejakeho algoritmu pouzivane bloky. Puzitim techto options pri mounutu na danem fs zabranim double cachingu na danem fs. Analogicky bych tyto options mohl pouzit i pro virtualni disky a cachovani nechat na virtualnich hostech.