Jaderné noviny – 18. 4. 2013: Úspora energie vypínáním pamětí

6. 5. 2013 | Luboš Doležel, David Watzke | Jaderné noviny | 3724×

Aktuální verze jádra: 3.9-rc7. Citáty týdne: Rusty Russell, Dave Chinner. vm_iomap_memory(). Správa výkonu paměti v roce 2013.

Obsah

• Aktuální verze jádra: 3.9-rc7
• Citáty týdne: Rusty Russell, Dave Chinner
• vm_iomap_memory()
• Správa výkonu paměti v roce 2013

Aktuální verze jádra: 3.9-rc7

Aktuální vývojová verze jádra je 3.9-rc7 vydaná 14. dubna. Linus k ní řekl: Jde hlavně o nahodilé jednořádkové opravy s pár většími opravami v ovladačích. Nejzajímavější věcí (asi jen pro mě a nikoho jiného) je oprava drobné chyby ve zneplatnění TLB, která se dotýká jen 32bitového PAE kvůli zvláštnostem v tom, jak to funguje.

Stabilní aktualizace: verze 3.8.7, 3.4.40 a 3.0.73 vyšly 12. dubna; verze 3.8.8, 3.4.41 a 3.0.74 pak následovaly 16. dubna.

Citáty týdne: Rusty Russell, Dave Chinner

Gregu, jsem šokován! Už to snad děláš dostatečně dlouho na to, abys věděl, že takhle na LKML nemluvíme.

Abych napravil reputaci tohoto mailing listu jako nepřátelského tlakového hrnce poháněného doutnajícími zbytky usmažených nováčků, dovol, abych tvou odpověď napravil:

„NAK. A navíc smrdíš.“

Krize je odvrácena,

-- Rusty Russell

Cokoliv, co s děsivou pravidelností přichází o data, není vhodné pro použití na produkčních systémech.

-- Dave Chinner (na LF Collaboration Summitu)

vm_iomap_memory()

Fáze -rc7 jaderného vývojového cyklu je obvykle považována za dobu nevhodnou pro přidávání nových API pro ovladače; většina vývojářů, co se o takovou věc pokusí, může očekávat ne úplně 100% povzbuzující odpověď. Ale pokud jste Linus, tak vám i takové věci mohou projít. Takže tedy Linus, poté, co se podíval na příliš zmatený kód ovladače, přidal novou pomocnou funkci právě pro ovladače, které potřebují mapování fyzického paměťového rozsahu do paměťového prostoru nějakého procesu.

int vm_iomap_memory(struct vm_area_struct *vma, phys_addr_t start, 
        unsigned long len);

Tato funkce obaluje io_remap_pfn_range(), které se stará o řadu detailů specifických pro subsystém virtuální paměti, aby je nemusel řešit kód ovladače. Ve verzi 3.9 na tuto funkci ještě žádné ovladače nepřešly, ale dá se očekávat, že na to dojde v cyklu 3.10.

Správa výkonu paměti v roce 2013

Když vývojáři mluví o správě výkonu, skoro vždy se zabývají chováním CPU, jelikož to je prostor, kde toho zpravidla bývá nejvíc ke zlepšení. Jenže počítače se sestávají z více komponent, než jsou samotné procesory, a tyto komponenty potřebují výkon také. Zhruba jednou za rok se pozornost zdánlivě ubere na výkonostní požadavky operační paměti systému; jelikož RAM může až za třetinu spotřeby systému, tak to dává smysl. Proto se tímto LWN zabývalo jednou v roce 2011 a znova pak v roce 2012. Nyní je v oběhu nová sada patchů správy výkonu paměti, takže se tím bude zabývat opět.

Nejnovější sada patchů přichází od Srivatsy S. Bhata a liší se od předchozích přístupů v několika věcech. Zaměřuje se na řadiče paměti, které mají automatické režimy správy výkonu se zachováním obsahu. Tyto řadiče dělí paměť na několik oblastí, přičemž každou z nich lze nezávisle vypnout, když řadič detekuje, že k ní nebylo nějakou dobu přistupováno. Takže strategie je zřejmá: snažit se udržet co nejvíce paměťových oblastí prázdných, aby zůstaly vypnuté.

Prvním krokem je držet si přehled o těchto paměťových oblastech v subsystému správy paměti. Předchozí patche používaly systém zón (který rozděluje paměť s rozdílnými charakteristikami – např. na 32bitových systémech je paměť rozdělena na tu v nízké a vysoké adresní oblasti [high & low memory]) ke sledování oblastí. Tento přístup má problém ten, že způsobuje chaos v počtu zón, což vede k větší režii správy paměti a zesložiťuje to vyvážené využití paměti napříč všemi zónami. Srivatsův patch místo toho sleduje oblasti paměti jako odlišné entity oddělené od zón, takže se tomuto problému vyhýbá.

Když se jádro dozví, kde tyto oblasti jsou, tak se potom snaží soustředit paměťové alokace na pomerně malé množství oblastí, je-li to možné. Z toho důvodu sada patchů upravuje seznam volných stránek tak, aby byl seřazen dle oblastí, tedy aby alokace na začátku seznamu pocházely z oblastí s volnými stránkami, co jsou v adresním prostoru co nejníže. Za pozornost stojí, že řazení v rámci oblasti není nutné; postačí, když jsou všechny stránky z dané oblasti seskupeny dohromady. Sada ukazatelů do seznamu, vždy jeden na každou oblast, pomáhá tomu, aby čerstvě uvolněné stránky byly rychle vloženy do seznamu na správné místo.

Alokace paměti se zohledněním oblastí může pomoci tomu, aby aktivní stránky byly seskupovány u sebe, ale v realitě budou stejně po nějaké době rozprostřené po celé fyzické paměti. Pokud nebudou provedena další opatření, většina oblastí skončí s aktivními stránkami i za situace, kdy je v systému jen málo využité paměti; to bude mít za následek, že vypnutí těchto oblastí bude těžké nebo nemožné. Proto Srivatsova sada patchů zahrnuje mechanismy pro migraci stránek pryč z vybraných oblastí.

Uvolňování paměťového prostoru není novým problémem; například mechanismus alokátoru souvislé paměti (CMA) občas musí aktivně konat, aby se mu podařilo velké souvislé bloky paměti vytvořit. Takže tento konkrétní problém už byl v jádře vyřešen. Než aby se tedy přidávalo nové schéma pro kompakci paměti, Srivatsův patch upravuje implementaci CMA, aby byla vhodná i pro použití ve správě výkonu paměti. Výsledkem je jednoduchá funkce compact_range(), která může být zavolána libovolným subsystémem, aby došlo k přesunu paměti a uvolnění paměťového rozsahu.

Je tu pak ale stále otázka, kdy by se mělo jádro snažit uvolnit oblast paměti. Pokud k tomu nebude docházet dostatečně často, spotřeba paměti bude vyšší, než by musela být. Časté přesuny stránek zase budou spotřebovávat čas CPU, takže by výsledkem byly nulové úspory energie. Příliš agresivní kompakce by pak mohla vést dokonce i k vyšší spotřebě. Proto je nutné mít nějaký řídící mechanismus.

V této sadě patchů byl alokátor stránek rozšířen tak, aby zaznamenal, kdy se začíná alokovat paměť z nové oblasti paměti. Tato nová oblast, z důvodu, že byla od alokací doposud chráněna, by neměla mít alokováno mnoho stránek; to z ní dělá přirozený cíl pro kompakci. Ale nemá žádný smysl se o kompakci snažit v době, kdy dochází k alokaci, protože je jasné, že v nižších oblastech paměti žádné volné stránky nejsou. Proto se alokátor stránek o kompakci v tento moment nepokouší; místo toho si nastaví příznak, který znamená, že by v blízké budoucnosti měl pokus o kompakci proběhnout.

"Blízkou budoucností" se myslí doba, kdy jsou stránky uvolňovány. Jakmile jsou alokátoru některé stránky navráceny, může být možné použít tyto stránky k vyprázdnění nějaké málo užívané oblasti paměti. Právě tehdy je kompakce spuštěna; spustí se funkce v pracovní frontě (workqueue), která se pokusí vyprázdnit oblasti, které byly předtím alokátorem označeny. Tento kód se ale o tuto operaci pokusí jen tehdy, pokud by se muselo migrovat relativně malé množství stránek (v aktuálním patchi je to 32). Jinak jsou náklady považovány za příliš vysoké a oblast se nechá, jak je.

Tato sada patchů je stále ještě hodně čerstvá, proto není k dispozici mnoho dat o tom, jak si vede. Hovoří se ale o 6% úspoře energie na 2GB desce Samsung Exynos s potenciálem na další zlepšení, pokud by i další části subsystému správy paměti měly větší povědomí o úsporném chování. Je tu ale otázka, na kterou patche neodpovídají: na typickém linuxovém systému je jen opravdu málo stránek skutečně „volných“: místo toho je zabírá cache. Aby bylo oblasti možné uvolnit, tak se asi bude muset použít agresivnější přístup k získávání stránek od cache. Jistě se najde i řada dalších nedořešených míst; snad budou vyřešena v aktualizaci v roce 2014, nebo dokonce dříve.

       

Komentáře

[vodic62]

Začínám mít pocit, že to s tím šetřením energie začíná zacházet až moc daleko. Už před dvěma lety se mi začalo dít, že mi kernel uspával klávesnici po pár vteřinách nečinnosti (zhasly diody), takže když jsem začal znovu psát, obvykle to nezachytilo první písmenko. Pak po nějaké aktualizaci to na čas zmizelo a teď v OpenSUSE 12.3 se to vrátilo v plné síle. A to mám úplně jiný HW, takže asi nebudu jediný. Už asi budu muset zase začít děla bugreporty, ale kde na to mám pořád brát čas?

[Petr Ježek]

Takhle to vypadá, když se věc vezme za špatný konec. Pochopitelně nelze rezignovat na snahy o efektivní a současně úsporné využití pamětí (plurál!), ale v linuxu jde o poněkud komplikovanější úkol vzhledem k jeho specifické práci s pamětí.

[dsfsadfasdf]

to mi pripomina co jsem nekde slysel, ze snad nejake notebooky obsahovaly v sobe plnohodnotnou desku a k tomu zaroven maly arm pocitac. kdyz chtel clovek jenom surfovat a delat nenarocne veci tak nabootoval notebook jenom s armovym minipocitacem. bylo to nebo jsem slysel jenom kachnu.

[Max]

Asus Express Gate?
Zdar Max

[2X4B-523P]

to nebude ono, to je jen systém na flash, měl jsem ho kdysi na P4P800 Deluxe, což byla má poslední deska od jiného výrobce než Intel, bohužel se budu muset od Intelu zas přeorientovat a asi zpět k ASUSu, měl jsem s ním dobré zkušenosti...

[Sten]

Současné DDR RAM žerou nějaké 4 W na modul, což u různých micro nano piko počítačů může být problém to vůbec uchladit. Ale nevím, jestli tohle Linux neřeší trochu pozdě, DDR4 bude mít výrazně nižší napětí a tedy i spotřebu

[mimi.vx]

až na to že to není primárně určeno pro desktop ale po mobilní zařízení ... kde to má celkem smysl i když používáš LP DDR.

[Dreit]

Mě se náhodně restartuje, klidně i během psaní. Všechno je OK a najednou probliknou všechny diody a klávesnice je asi na vteřinu bez odezvy. Dělají mi to všechny tři klávenice, od nejstarší IBM přes USB-PS2 redukci až po týden starou ostrůvkovou od Geniusu.

[Grunt]

A nemáš náhodou v čudu USB řadič? Čas od času když z něj lezou nesmysly má jádro tendenci ho restartovat — dělá mi to pár USB portů navěšených na jeden controller.

[vodic62]

Tohle mě také napadlo, tak jsem to hned přepojil na port přímo na desce a žádná změna. Testováno na několika portech na dvou různých motherboardech. Je ale zajímavé, že to dělá jen někdy. Třeba teď zrovna ne :) A dmesgu žádné logy.

[Max]

Toto se mi děje, když mi na bytě sepne lednička :). Asi bych tu UPS neměl odkládat a konečně si jí pořídit.
Zdar Max

[Luboš Doležel (Doli)]

Já jsem teď zase díky UPS zjistil, že mi laserová tiskárna nárazově odebírá 800W (takže UPS začne hlásit overload).

[vodic62]

To je běžná hodnota. Jinak by neměla šanci zahřát válec během pár vteřin na 200 stupňů.

[Jendа]

Mně se tohle stane, když se resetne USB řadič (většinou kvůli přetížení napájení nebo detekci ESD). Většinou to zjistím tak, že Xka zapomenou rozložení a rychlost opakování. Jo a taky jsem teď zjistil, že když mám vedle myši položený mobil a začne vysílat, tak myš samovolně kliká pravým tlačítkem

[Kaacz]

AARRGGHH .. mobil .. to by mohlo souviset s obcasnymi divno-stavy :p

[pc2005]

To jsou věci . Jediné mé problémy s klávesnicí jsou v tom, že při přepínání mezi virtuálními terminály a xkama se občas ztratí kontext mezi numlock led a reálným stavem numlocku (možná to je i ostatní locky). Ale tuším, že tenhle bug je stará chyba.

Ad patička, docela by mě zajímalo zda jsou opravdu ty reference pravé (a co na to ty společnosti).

[Semo]

To mi robi, ked vypnem alebo zapnem velke 5.1 repraky od Geniusu. V standby zeru 10W, takze som dorobil vypinac na privodnu snuru a zmena stavu tohto vypinaca sposobi restart klavesnice. Ale uzivatelske dosledky to nema vobec ziadne, tak na to kaslem.

[trubicoid2]

a co toto? mas u klavesnice -1? nektery zarizeni, jako treba usb mysi a usb klavesnice blbnou, kdyz to neni vypnuty, t.j. -1

cat /sys/bus/usb/devices/*/power/autosuspend

[vodic62]

Diky za tip. Koukal jsem tam a autosuspend mam zapnuty, ale z nejakeho duvodu mi to klavesnice delat prestala. Mozna update, ktery jsem delal pred par dny. Jakmile se to vrati, tak aspon budu vedet kam sahnout.

[lertimir]

klávesnice se mi tedy v 12.3 nevypíná/neuspává