Optimalizace spotřeby – analytické nástroje

13. 4. 2011 | Vratislav Podzimek | Hardware | 5900×

Chceme-li snížit spotřebu el. energie našeho systému, máme několik možností. Můžeme použít nástroje pro dynamické přizpůsobování výkonnosti systému a tím i energetických nároků. Jedním za takových nástrojů je například Tuned, který jsme si představili v předchozím článku. Druhou možností je pak analýza našeho systému a jednotlivých procesů z pohledu faktorů významných pro spotřebu el. energie.

Můžeme tak zjistit, které procesy způsobují nejvíce probuzení procesoru, přenášejí nejvíce dat přes síťová rozhraní či pracují nejvíce s disky. I pro tento účel přináší moderní GNU/Linuxové systémy různé nástroje a právě na jejich možnosti se zaměříme v tomto článku.

Obsah

• PowerTOP
• Scomes
• Diskdevstat a Netdevstat
• Battery Life Tool Kit (BLTK)

PowerTOP

Nástroj PowerTOP vyvinutý firmou Intel (v roce 2007 uvolněn pod licencí GPLv2) slouží k analýze systému z hlediska počtu probuzení procesoru jednotlivými procesy (příp. službami jádra). S jeho pomocí tak můžeme odhalit největší "žrouty" v běžícím systému. Od verze 2.6.21 je jádro Linux tzv. tickless, což znamená, že se časová přerušení nastavují v závislosti na aktuálně běžících procesech a ne například 1000krát za sekundu, jako tomu bylo dříve. Pokud tedy v systému běžícím na moderním linuxovém kernelu není žádný proces, jenž by potřeboval v nejbližších 2s procesor, CPU může zůstat po celou dobu 2s ve stavu idle. (Pro více informací vizte kerneltrap.org.)

Co ale u moderních procesorů znamená idle stav? Specifikace ACPI rozlišuje tzv. C-stavy a P-stavy. C-stavy (obvykle C0-C3 nebo C4) určují, je-li procesor v pracovním režimu (C0), nebo v režimu idle (C1, C2, ...), přičemž jednotlivé idle stavy se liší ve spotřebě elektrické energie a latenci při přechodu do pracovního režimu. Některé procesory mají implementovaný i stav C6 (deep sleep), ve kterém je dosaženo značné úspory energie. Někdy bývá tento stav BIOSem namapován na stav C3. P-stavy zase určují frekvenci a napětí procesoru. U obou stupnic platí pravidlo "vyšší stav odpovídá nižší spotřebě a větší latenci při přechodu do nejvýkonnějšího režimu". Tedy, máme-li správně nakonfigurovaný a vyladěný systém, měli bychom na nepoužívaném PC dosáhnout alespoň 90 % v nejvyšším C-stavu i P-stavu.

Po spuštění PowerTOP sbírá informace ze systému a po chvíli (ve výchozím nastavení 5 s) přehledně zobrazí výsledky, které jsou průběžně obnovovány. Navíc se v dolní části výpisu postupně objevují návrhy na snížení spotřeby pomocí známých úprav - např. aktivace USB autosuspend, přepnutí politik řízení latence CPU na ondemand, deaktivace nepoužívaného Bluetooth apod. K příslušnému návrhu se také zobrazí písmeno, jímž je možno okamžitě změnu uplatnit, ovšem pouze do následujícího rebootu. Pokud bychom chtěli tyto úpravy zapnout trvale stačí PowerTOPem zobrazený odpovídající příkaz přidat jako nový řádek do souboru /etc/rc.local. Běží-li systém z baterie, zahrnuje výpis i odhad aktuální spotřeby (informace získané z ACPI).

Instalaci (v distribuci Fedora) provedeme příkazem

yum install powertop

Použití je pak velmi snadné, postačí nám jako root zadat příkaz

powertop

Užitečným přepínačem může být -d (dump – zjistí jednou informace o probuzeních procesoru a vypíše na výstup tipy na snížení spotřeby el. energie), který nám umožní z výstupu vykopírovat příkazy odpovídající zobrazeným tipům do /etc/rc.local. Společně s touto volbou je ještě možné použít přepínač -t DOUBLE (Kde DOUBLE značí hodnotu typu double, tedy číslo s pohyblivou desetinnou čárkou, v sekundách.), jehož pomocí můžeme určit čas, po který bude PowerTOP sbírat informace ze systému před zobrazením výsledků. V současné době je k dispozici i betaverze PowerTOP 2.0, která přináší mnoho novinek. Pro další informace vizte oficiální stránky projektu.

Scomes

Dalším velmi užitečným nástrojem je scomes. Jedná se o SystemTap (vizte web) skript, který nám umožní o běhu programu získat informace mající vliv na spotřebu el. energie. V současné době jsou to konkrétně tyto statistiky:

• Počet volání jádra (syscalls)
• Počet taktů v jádře a v uživatelském prostoru (kticks a uticks)
• Čtené a zapsané byty (reads, writes)
• Množství dat přijatých a odeslaných přes síťová rozhraní (ifrecv a ifxmit)
• Pollingová volání jádra (polling syscalls)
• Celkové skóre počítané dle vzorce
  SCORE = kticks + 2*uticks + 10*(reads+writes) + ifxmit + ifrecv

Můžeme tak například při vývoji programu porovnávat různé alternativy z hlediska energetických nároků.

Skutečnost, že je scomes implementován jako SystemTap skript, znamená, že pro jeho správnou funkčnost je třeba mít v systému nainstalován program SystemTap, a tedy i debuginfa jádra. Abychom mohli scomes používat např. na systému Fedora, je nutné provést následující příkazy:

debuginfo-install kernel # Případně kernel-PAE,
                         # je-li používáno jádro s podporou PAE)

yum install tuned-utils # scomes je součástí balíku tuned-utils

I když samotný scomes zabírá na disku pár desítek KB, debuginfa jádra nás připraví asi o 1,5 GB. Pro  funkčnost tohoto nástroje jsou však nezbytná. Po úspěšné instalaci je použití scomes velmi jednoduché.

scomes -c "program arg1 arg2..." čas

nám bude periodicky (perioda dána hodnotou parametru čas) zobrazovat sumy jednotlivých statistik z dosavadního běhu programu.

Diskdevstat a Netdevstat

Diskdevstat a Netdevstat jsou dva SystemTap skripty, které nám umožní získat informace o procesech právě běžících na systému z hlediska jejich diskových aktivit resp. síťových přenosů. Podobně jako scomes i tyto dva skripty jsou součástí balíku tuned-utils.

Použití si ukážeme na příkladu diskdevstat, pro netdevstat se liší pouze názvem volaného skriptu:

diskdevstat perioda délkaBěhu ukázatHistogram

Skript poté bude po dobu danou parametrem délkaBěhu periodicky zobrazovat informace o diskových aktivitách jednotlivých procesů běžících v systému. V případě hodnoty 1 na místě parametru ukázatHistogram bude na konci běhu skriptu zobrazen histogram.

Tímto způsobem tedy můžeme identifikovat procesy nejvíce pracující s diskem a následně např. pomocí programu strace zjistit, jaká konkrétní systémová volání v těchto procesech způsobují užití disku.

Battery Life Tool Kit (BLTK)

V poslední části se společně podívejme na nástroj Battery Life Tool Kit (BLTK). Ten původně vznikl za účelem analýzy výdrže a výkonnosti baterie notebooku, ale je použitelný i pro jiné účely a to i na desktopu (vizte přepínač -a dále).

BLTK simuluje různé typy zátěže odpovídající různým typickým činnostem běžného uživatele a po každém běhu uloží výsledky, ze kterých můžeme následně vytvořit snadno čitelnou zprávu obsahující mnoho údajů. Od výrobce a typu notebooku a baterie, přes statistiky setrvání v jednotlivých ACPI stavech, až po odhad aktuální spotřeby el. energie. Můžeme tak například testovat míru vyladění našeho systému pomocí dalších nástrojů. V současné době jsou k dispozici tyto typy simulovaných zátěží:

• Idle - probíhá pouze sběr dat; přepínač -I
• Developer - simulace práce vývojáře; přepínač -D
• Reader - simulace prohlížení dokumentu (implicitně v prohlížeči Firefox); přepínač -R
• Player - simulace přehrávání multimediálního obsahu z CD/DVD mechaniky (implicitně pomocí mplayeru); přepínač -P
• Office - simulace editace dokumentů pomocí sady OpenOffice.org; přepínač -O
• 3D game - simulace hraní 3D hry (implicitně demo Unreal Tournament); přepínač -G

Instalaci v distribuci Fedora provedeme pomocí

yum install bltk

Poté nám již nic nebrání v používání, ovšem pouze na notebooku. Chceme-li BLTK používat na desktopovém PC, musíme bltk spouštět s přepínačem -a, což způsobí ignorování stavu připojení napájení. Dalšími užitečnými přepínači jsou:

• -T početSekund – čas, po který dávka poběží
• -F názevSouboru – soubor užitý pro dávku (např. pro player)
• -W aplikace – aplikace, kterou dávka využije (např. jiný prohlížeč pro Reader)

Výsledky analýzy se po průběhu simulace zátěže uloží do adresáře specifikovaného v konfiguračním souboru /etc/bltk.conf, defaultně  bltk.typ_simulace.cislo (u první simulace není uvedeno číslo). Tyto výsledky nejsou však příliš přehledné a dobře čitelné. Právě za tímto účelem vznikl nástroj bltk_report, který voláním ve tvaru

bltk_report cestaKadresariSvysledky

vytvoří velmi přehlednou zprávu, již jako soubor s názvem Report uloží k výsledkům. Volbou -o si můžeme výsledek přesměrovat na standardní výstup. Pro zobrazení grafu odpovídajícímu výsledkům poslouží příkaz bltk_plot, kterému opět jako parametr předáme cestu k adresáři s výsledky.

Dobrým rozcestníkem pro získání dalších informací jsou stránky Fedora Power Management Special Interest Group.

       

Komentáře

[jan.xxx]

No, tak mi to ten powertop hezky rozvrtal a restart jaksi nepomohl Kdykoliv teď v KDE chci změnit velikost konzole, tak si systém totálně shodím. Ale proč?

[v.podzimek]

No, tak mi to ten powertop hezky rozvrtal a restart jaksi nepomohl Kdykoliv teď v KDE chci změnit velikost konzole, tak si systém totálně shodím. Ale proč?

Tak s tím jsem se ještě nesetkal. Jak rozvrtal? A jen pouhé spuštění PowerTop? Chtělo by to další informace a poté nejlépe nahlásit bug.

[LaLa]

To s powertopem nesouvisi. Je to znama chyba v KDE 4.6. Tusim, ze nejak souvisi s proprietarnim ovladacem nVidia.

[jiri.one]

mam KDE 4.6 i proprietarni ovladac nVidia a nikdy se mic takoveho nestalo. Vlastne KDE 4.6 mi nespadlo jeste ani jednou.

[LaLa]

no, to je teda argument :-/
https://bugs.archlinux.org/task/23381

[stativ]

Je to znama chyba v KDE 4.6

Zajímavé, že ve značné části komentářů u bugu, který odkazuješ níže se mluví i o jiných prostředích než je kde. Podle všeho je to chyba ovladačů.

[LaLa]

Je to tak. Chyba bude nejspis v X serveru a kompositor v kwinu (?) ji jenom spousti. Kazdopadne se to v predchozich verzich KDE nestavalo.

[qweerty]

Když jsme u šetření energie, může mi někdo povědět jestli je už něak ošetřeno parkování disku na notebooku v Kubunutu/Debianu jako součást systému, řízení napájení. Já k tomu používám hdparm spouštěný v jednotlivých stupních nastavení systému.