Jaderné noviny – 3. 10. 2013: Úspory díky vypínání pamětí

22. 10. 2013 | Luboš Doležel | Jaderné noviny | 4780×

Aktuální verze jádra: 3.12-rc3. Citáty týdne: Ingo Molnar, Borislav Petkov. Prohození dvou souborů. Kolik správy výkonu paměti je užitečné?

Obsah

• Aktuální verze jádra: 3.12-rc3
• Citáty týdne: Ingo Molnar, Borislav Petkov
• Prohození dvou souborů
• Kolik správy výkonu paměti je užitečné?

Aktuální verze jádra: 3.12-rc3

Aktuální vývojová verze jádra je 3.12-rc3 vydaná 29. září. Linus ji shrnul takto: Celkem vzato tam není nic až tak strašidelného. Vzhůru do testování.

Stabilní vydání: verze 3.11.2, 3.10.13, 3.4.63 a 3.0.97 vyšly 26. září; následovalo je vydání verzí 3.11.3, 3.10.14, 3.4.64 a 3.0.98 1. října.

Citáty týdne: Ingo Molnar, Borislav Petkov

Je to snad poprvé, kdy se kód napsaný na obyčejném mobilním telefonu dostal do linuxového jádra, takže je to asi nový milník Linuxu, takový zvrácený.

-- Ingo Molnar

Pod danou funkci v arch/x86/lib/misc.c bychom mohli přidat komentář:

/*
 * Odesláno z mobilu. Prosím omluvte mou stručnost a chybějící formátování.
 */

-- Borislav Petkov

Prohození dvou souborů

Systémové volání renameat() změní název souboru předaného jako argument, přičemž může během toho dojít k nahrazení existujícího souboru. Tato operace je atomická; z pohledu uživatelského prostoru bude vidět stav před nebo po volání renameat(), ale nikdy nic mezi tím. Funguje to dobře, když jde jen o jeden soubor, ale co když je nutné provést několik přejmenování jako jedinou atomickou operaci? To je velký problém, ale díky patchi od Miklose Szerediho možná budeme pro některé situace mít řešení.

Miklos se snaží vyřešit problém prohození dvou souborů – oba nadále existují, ale jejich názvy jsou prohozené. Aby bylo možné toho dosáhnout, vytvořil patch, který přidává nové systémové volání renameat2():

int renameat2(int olddir, const char *oldname, 
	int newdir, const char *newname, unsigned int flags);

Toto systémové volání se od renameat() liší tak, že má nový argument flags; pokud je flags nulové, pak se renameat2() chová přesně stejně jako renameat(). Pokud ale flags obsahuje RENAME_EXCHANGE, pak nebude stávající soubor v newname odstraněn; místo toho bude přejmenován na oldname. Proto je s tímto příznakem možné použít renameat2() k prohození dvou souborů. Hlavní využití renameat2() nachází v systémech souborů typu union, kde je často žádoucí atomicky nahradit soubory nebo adresáře bez „výpadků“, které by naznačovaly, že došlo k jejich odstranění. Dalo by se to jistě využít i jinak; Miklos uvedl atomické nahrazení adresáře symbolickým odkazem.

V době psaní tohoto textu se k patchi ještě nikdo nevyjádřil.

Kolik správy výkonu paměti je užitečné?

Na většině současných systémů se už většina jednoduchých způsobů, jak snížit spotřebu, používá. Ale jistě stojí za to podívat se na každou komponentu, která spotřebovává energii, zda by bylo možné spotřebu snížit. V případě hlavní paměti se říká, že potenciální úspory jsou veliké, ale jsou vykoupeny zesložitěním (už tak složitého) subsystému pro správu paměti. Po posledním v dlouhé řadě patchů pro správu výkonu pamětí mají vývojáři pochyby, k čemu je taková složitost dobrá.

O sadě patchů pro správu výkonu pamětí od Srivatse S. Bhata se na LWN psalo v dubnu 2013. Většina hlavních principů je stejná, ale některé drobnosti se značně změnily.

Patche jsou stále postavené na myšlence rozdělení hlavní paměti na oblasti, které odpovídají hranicím správy paměti v přislušném hardwaru. Na úrovni hardwaru je oblastí rozsah paměti, který lze jako celek vypnout. Základním cílem správy výkonu paměti je udržet co nejvíce těchto oblastí prázdných, aby bylo možné je držet při nízké spotřebě.

Oblasti se trochu podobají zónám vedeným subsystémem pro správu paměti. Jenže hranice zón jsou stanovené jádrem a mají málo co do činění s architekturou hardwaru (ačkoliv zóny nikdy nebudou napříč více uzly NUMA). Oproti tomu regiony jsou ryze hardwarová záležitost. Protože mají oblasti a zóny tak málo společného, patch definuje oblasti jako nezávislou strukturu, téměř úplně odlišnou od zón.

První krok je jednoduchý: při alokaci stránek se alokuje od oblasti s volnými stránkami s nejnižším číslem. To má za důsledek soustředění alokací na konci rozsahu paměti a oblasti s vysokým číslem jsou tedy volné. Aby byla alokace v tomto režimu snazší, seznam volných stránek alokátoru je upraven tak, aby řadil stránky podle oblasti; to umožní rychlé nalezení stránek z příslušných oblastí bez nutnosti seznam prohledávat. Logika alokace se také trochu změnila. Aktuálně se jádro snaží předcházet rozdělování velkých souvislých oblastí při řešení žádosti, pokud je dostupný vhodný (a menší) blok paměti. Patche obětují tuto heuristiku tak, že velké oblasti v zónách s nízkým číslem budou rozděleny spíše, než aby byla paměť alokována v zónách s vysokým číslem.

Další krok představuje poněkud větší zásah: do subsystému pro správu paměti je přidán „alokátor oblastí“; spravuje paměť po velkých blocích odpovídajících hardwarovým oblastem. V aktuálních jádrech alokátor stránek pracuje přímo s dostupnou pamětí v systému; v novém návrhu alokátor stránek nejprve alokuje paměť v oblastech paměti získaných od alokátoru oblastí. Jinými slovy byl alokátor oblastí umístěn mezi alokátor stránek a fyzickou paměť. Pokud alokátor stránek potřebuje více paměti, pak si požádá o novou oblast od alokátoru oblastí. Pokud si zase alokátor stránek uvědomí, že má celou volnou oblast, pak tuto oblast může vrátit alokátoru oblastí.

Probíhá snaha o to, aby všechny alokace z dané oblasti měly stejný „typ migrace“. Typ migrace stránky popisuje, jak snadné by bylo obsah stránky přesunout jinam. Anonymní stránky pro uživatelský prostor je relativně snadné přesunout; k tomu je nutné jen okopírovat data a změnit všechny položky v tabulkách stránek, které na stránku odkazují. Stránky používané ve slab alokátorech jádra jsou oproti tomu nehybné; k přesunutí takové stránky by bylo potřeba dohledat a změnit všechny ukazatele v jádře, které ukazují na objekty alokované na této stránce – to není snadno řešitelný problém. Účel je jasný: k tomu, aby oblast musela zůstat zapnutá, stačí jediná nepřesunutelná stránka. Pokud je možné udržet všechny nepřesunutelné stránky odděleně od těch, co se dají snadno přestěhovat, pak bude jednodušší uvolňovat oblasti paměti.

Poslední část patche využívá přesunutelných stránek k aktivnímu uvolňování paměti za předpokladu, že jsou k tomu vhodné podmínky. Pokud například oblast obsahující přesunutelné stránky je převážně prázdná a jinde jsou k dispozici volné stránky, pak se jádro pokusí přestěhovat data z této oblasti a jakmile bude oblast prázdná, tak ji vrátí alokátoru oblastí. V ostatních případech (například čisté stránky cache) je možné stránky jednoduše uvolnit. Předpokládá se, že takto bude možné čistit fragmentaci, ke které nevyhnutelně bude docházet, takže se co nejvíce oblastí bude udržovat volných.

Většina tohoto patche o 40 částech je docela nekontroverzní, ale jsou tu jisté obavy z aktivní ochrany proti fragmentaci. Pokud nebudou používány opatrně, pak by mohly vést ke zvýšení spotřeby namísto snížení: přesun stránek spotřebovává energii, stejně tak nahrazování stránek v cache, které byly uvolněny předčasně. Proto je nutné mít důkazy, že aktivní ochrana přináší úspory; zatím takové důkazy neexistují, protože v poslední době nebyly zveřejněny žádné výsledky benchmarků.

Navíc jsou tu obavy, že aktivní ochrana může představovat rozkol mezi návrhem patche a tím, jak správa výkonu doopravdy probíhá na současném hardwaru. Hlavní myšlenkou je udržovat co nejvíce oblastí paměti volných; to umožní těmto oblastem, aby byly vypnuty – při současné ztrátě obsažených dat – bez problémů. V tomto modelu může jediná aktivní stránka způsobit to, že nedojde k vypnutí oblasti, takže oblasti je nutné zcela vyčistit, aby došlo k úsporám.

Jak ale Arjan van den Ven vysvětlil, tak přinejmenším na současném hardwaru od Intelu probíhá správa výkonu paměti odlišně. K dispozici je řada režimů snížené spotřeby, přičemž většina z nich je pro operační systém zcela transparentní a nedochází ke ztrátě obsažených dat. Přechody mezi jednotlivými stavy jsou docela rychlé, a to tak, že latence nepředstavuje problém. Aby tento typ správy výkonu začal fungovat, stačí jen to, aby daná oblast byla po většinu času nečinná. Arjan to popsal takto:

Abychom dosáhli úspor, tak se domnívám (na základě jednoduchých experimentů, které jsem letos dělal na Intelech), že je více než postačující mít „statistickou“ úroveň „vazby“ [binding], aby bylo možné dosáhnout 95 %+ maximálních teoretických úspor...

Jinými slovy, pokud je možné udržet velké množství oblastí téměř bez stránek, pak nevadí, když se několik zbylých stránek stále používá. To by znamenalo, že části Srivatsovo patche, které řídí způsob alokace, plně postačují k tomu, aby se podařilo dosáhnout většiny úspor – alespoň na hardwaru od Intelu. Aktivní číštění oblastí může nakonec být jen marnou snahou dosáhnout několika dalších procent úspor. Ne všechen hardware pochopitelně vyrábí Intel; výsledky na jiných procesorech a architekturách mohou být odlišné. I na systémech od Intelu může v některých situacích dávat smysl podporovat úplné vypnutí pamětí. Ale skutečnost, že většiny výhod je zjevně možné dosáhnout bez aktivního přesouvání stránek, bude asi důvodem, aby tato funkčnost byla přinejmenším standardně vypnutá.

Všimněte si ale použití slova „zjevně“. V debatě zatím schází přehled celkových měření s a bez těchto patchů. Skutečná měření, která mají obvykle větší váhu než teoretické diskuze, by měla být klíčem pro rozhodnutí, kolik částí patche začlenit a zda by aktivní defragmentace měla být standardně povolena, nebo ne. Tak či tak se zdá, že většina patche je docela nekontroverzní, takže bychom v blízké budoucnosti měli konečně vidět v oblasti správy výkonu pamětí nějaký posun.

       

Komentáře

[Aleš Kapica]

Jinými slovy, pokud je možné udržet velké množství oblastí téměř bez stránek, pak nevadí, když se několik zbylých stránek stále používá. To by znamenalo, že části Srivatsovo patche, které řídí způsob alokace, plně postačují k tomu, aby se podařilo dosáhnout většiny úspor – alespoň na hardwaru od Intelu.
...
Ne všechen hardware pochopitelně vyrábí Intel

Že by právě tohle bylo příčinou záhadných vytuhnutí mých strojů? Před výpadkem shodné symptomy - obsazení paměti minimální a procesor AMD. Stroj pokaždé "jen" přestal komunikovat, i přesto že nadále běžel.

[Luboš Doležel (Doli)]

Nechápu, asi jsi ten text špatně pochopil. Navíc je ten patch jen návrh, není to nikde začleněné.

[Aleš Kapica]

Možná. Každopádně to chování bylo pokaždé zcela nestandardní. Stroj sice nekomunikoval, ale přesto nějakým způsobem síťově žil. Což bylo horší, než kdyby normálně chcípnul. Bohužel jsou to starší stroje, které nemají ipmi. Teď už jsou přepojeny na PDU. Když se to stalo poprvé v průběhu týdne, tak jsem si ho vypnul sám, ale v sobotu už bylo třeba sehnat někoho, kdo ho odbouchne, aby bylo vůbec možné nahodit záložní stroj.

[chrono]

Tú úsporu riadi procesor a/alebo čipová sada bez zásahu OS.

[Dreit]

Takže po bootu systému se mi bude napájet jeden RAM modul a pokud bude docházet místo, tak okamžitě naskočí další podle potřeby?

[Heron]

Naopak. Když za běhu serveru přijde z Bruselu příkaz od EU, že je vysoká spotřeba energie, tak se vypne náhodný paměťový modul. V dalším kole to budou jádra procesorů a od roku 2018 se zakážou ATX počítače jako celek. Potom se budou prodávat pod označením tepelný kvádr.

[trekker.dk]

NENAPOVÍDAT!

[Jakub Lucký]

A databáze se ve snaze o integritu přestanou dělat tak, aby se vešli do ramky, ale do cache procesoru... (In your face, Oracle!)

[omg]

to spis odpovida in your face intel... protoze co jadro to cache a k tomu vse ve velkych poctech to arm a do tohodle vlacku uz amd prece ohlasilo, ze naskoci.

[Bilbo]

EU se uz snazi regulovat treba i prikon grafickych karet: http://diit.cz/clanek/evropska-unie-zakazali-jsme-zarovky-zakazeme-i-graficke-karty

Nevim jak moc daleko s tim dojdou a treba to mezitim spetou ze stolu jako totalni hovadinu, ale nedivil bych se kdyby dalsi komponenty (CPU, ...) byly dalsi na rade :)