Jaderné noviny - OLS: tři přednášky o správě napájení

24. 7. 2007 | Robert Krátký | Jaderné noviny | 6917×

Jak vyždímat co nejvíce z beztikového jádra. Mýty o ACPI. Jak uchopit Linux (spotřeba energie vs. odvod tepla).

Obsah

• Jak vyždímat co nejvíce z beztikového jádra
• Mýty o ACPI
• Jak uchopit Linux

Len Brown má určitě sebemrskačské sklony; je totiž správcem linuxového ACPI subsystému. To není lehká pozice: ACPI znamená práci s BIOSem, což je oblast systémového softwaru, která se většinou nevyznačuje pečlivou a kvalitně odvedenou prací. Podpora ACPI je úkol, který - mimo jiné - vyžaduje vložení specializovaného interpreteru do jádra, a to není zrovna populární myšlenka. Přes to všechno je třeba se zamyslet nad tím, jak moc velká dávka masochismu je potřeba k tomu, aby člověk přednesl tři samostatné přednášky na linuxovém symposiu 2007 v Ottawě. Přesně to však Len udělal; výsledkem byl podrobný pohled na mnohé aspekty otázky správy napájení.

Jak vyždímat co nejvíce z beztikového jádra

První řeč (o beztikovém jádře) měl původně přednést Suresh Siddha, který se však nakonec nemohl zúčastnit. Patche implementující dynamický tik nejsou nijak nové. Přednáška nebyla ani tak o tom, jak tyto patche fungují, jako spíše o věcech, které zbývá dodělat, abychom mohli beztikový design plně využít. Vypadá to, že doposud odvedená práce je jen začátek.

Jedním z problémů je to, že na systému, který používá Suresh a spol., se průměrná doba spánku procesoru nedostala nad 1 ms, i když byl zapnut kód s dynamickým tikem. Vzhledem k tomu, že hlavní motivací pro dynamický tik je nechat procesor delší dobu spát - a tím ušetřit energii - je to mizerný výsledek. Je však hodně věcí, které by situaci mohly vylepšit.

Prvním krokem je vyřešit jeden jaderný problém: existuje hodně aktivních jaderných časovačů, které mají tendenci se časem rozbíhat od sebe. Kvůli tomu se jádro budí daleko častěji, než kdyby byly časovače dostatečně koordinované, aby co nejčastěji vypršely ve stejnou chvíli. Mnohé jaderné časovače totiž nevyžadují velkou přesnost; pokud časovač spustí o pár milisekund později, než jak byl nastaven, není to problém. Kdyby tedy jádro mohlo některé časovače pozdržet, aby spustily ve stejný okamžik jako jiné, snížil by se počet probuzení. Patch, který implementuje odložitelné časovače, přesně tohle umí; funkce round_jiffies() (přidaná v 2.6.19) by jádru také mohla pomoci řadit události. Přidání tohoto kódu zvýšilo průměrnou dobu spánku na 20 ms, přičemž systém zpracovával 90 přerušení za vteřinu.

Další problém je s hardwarovými časovači. Na architektuře i386 se preferuje lokální APIC (LAPIC) časovač, který je zabudován do procesoru a lze jej naprogramovat velmi rychle. Jenže uspání procesoru uspí i LAPIC časovač, což Len přirovnal k vypnutí budíku než člověk usne. V obou případech může být nechtěným výsledkem zaspání. Programovatelný intervalový časovač [programmable interval timer (PIT)] sice zůstává vzhůru a je snadné jej použít, ale maximální doba, na kterou lze nastavit, je 27 ms. Pokud bychom chtěli, aby spal procesor déle, bude nutné najít jiné řešení. A tím je časovač událostí s vysokým rozlišením [high-precision event timer (HPET)], který má maximální interval alespoň tři vteřiny. Může být však obtížné získat k HPET přístup; dobrá podpora v BIOSu není moc častá a HPET je obvykle vypnutý. Pokud by však bylo možné vynutit zapnutí, mohla by se průměrná doba spánku zvýšit až na 56 ms, přičemž by zpracovával 32 přerušení za vteřinu.

Ještě lepší je vzít HPET z "legacy mode" [režim pro kompatibilitu se starším hardwarem/funkcemi], který teď Linux používá. Tento režim je snadno použitelný, ale vyžaduje přeposílání časovačových přerušení na víceprocesorových systémech. HPET však umí pracovat s kanály pro jednotlivé procesory, což tento problém odstraňuje. Výsledkem je nárůst průměrné doby spánku na 74 ms.

V tuto chvíli se věc přesouvá do uživatelského prostoru. Od vydání powertop toho bylo v této oblasti spoustu uděláno; uživatelské aplikace, které mohou způsobovat zbytečně časté probouzení, jsou hned rozpoznány a mohou být opraveny. Ale, jak poznamenal Len, uživatelský prostor je furt na houby.

Mýty o ACPI

Trochu to vypadá, že už Lena unavuje neustálé stěžování uživatelů na ACPI v Linuxu. Jeho odpovědí byla přednáška "Deset mýtů o ACPI" - i když se pak seznam rozrostl na dvanáct.

#1: Zapnuté ACPI nepřináší žádné výhody. Lenova odpověď měla dvě části, z nichž ta první je, že už pomalu nejsou žádné alternativy. Rozhraní APM je zastaralé a Vista ho už nepodporuje vůbec. Takže brzy už nebude APM podporovat ani žádný hardware; je to mrtvý standard. Standard MPS (používaný pro nacházení procesorů) je také starý a pomalu odumírá. Ať se vám to líbí nebo ne, ACPI je potřeba, abyste mohli svůj hardware používat.

Pozitivní však je to, že používání ACPI vám zpřístupní různé funkce hardwaru, například softwarem ovládaná tlačítka na vypínání a uspávání. Budete mít k dispozici údaje o stavu baterie a také možnosti, jak snížit spotřebu a prodloužit baterii výdrž. S ACPI je také možné za běhu připojovat komponenty (hotplug) a dokovat.

#2: Potíže s uspáváním na disk má na svědomí ACPI. Ve skutečnosti se jen malá část procesu uspávání na disk [suspend-to-disk] týká ACPI - všechno ostatní je v jiných částech jádra. Pokud máte problémy s uspáváním na disk, radí Len, stěžujte si Pavlu Machkovi, ne mně.

#3: Když nefungují speciální tlačítka, je to chyba ACPI. V tomto případě je problém v tom, že podpora "hotkeys" není součástí specifikace ACPI. Všechny ty extra čudlíky na noteboocích jsou funkce, které přidali výrobci. Ovladače získané pomocí zpětného inženýrství, které jsou teď v jádře, jsou heroický výkon, ale neměly by být potřeba. Výrobci by měli pro svůj hardware dodávat ovladače.

#4: Problémy při bootu se zapnutým ACPI jsou chyba ACPI. Len připouští, že tohle by občas mohla být pravda. Ale vypnutí ACPI vypíná i jiné funkce hardwaru - především IO-APIC. Takže problémy související s těmi ostatními částmi systému budou vypnutím ACPI skryty. Vypadá to, že původní problém byl s ACPI, ale ve skutečnosti je to více komplikované.

#5: Problémy s ACPI způsobuje nekvalitní BIOS platformy. Existují tři hlavní zdroje ACPI nekompatibilit. Jen jedna z nich je však BIOS, který porušuje specifikaci ACPI; nekompatibilní záležitosti, které nevadí Windows, často testováním proklouznou. Může s tím pomoci kit pro vývojáře firmwaru od Intelu. Dalším zdrojem problémů jsou odlišné interpretace specifikace, která je dlouhá a komplikovaná. Vývojáři linuxového ACPI pomáhají s vyjasňováním těchto záležitostí, když na nějaké narazí. A konečně poslední možnost - v linuxovém kódu prostě mohou být chyby.

#6: Linuxová komunita nemůže pomáhat vylepšovat specifikaci ACPI. Ve skutečnosti ACPI tým posílá vylepšení, většinou formou "objasnění specifikace". Mnohé z nich byly zařazeny a objevily se v aktualizacích specifikace.

#7: ACPI kód se hodně mění, ale ne k lepšímu. Intel sestavil sadu s více než 2000 testy; změny ACPI teď musí všemi testy projít, než jsou začleněny. Počet nových chyb se zmenšuje - i když možná pomaleji, než bychom si přáli.

#8: ACPI je pomalé a škodlivé pro regulátory procesorů [CPU governor] zaměřené na vysoký výkon. ACPI interpreter se nepoužívá v situacích, kde by záleželo na výkonu, takže nemůže věci zpomalovat. ACPI je využíváno pro konfiguraci.

#9: Regulátor speedstep-centrino je rychlejší než acpi-cpufreq. Acpi-cpufreq se dočkal mnoha vylepšení a umí teď přistupovat k MSR rychleji a snáze podporovatelným způsobem. Jeho výkon je tedy optimální a speedstep-centrino bude odstraněn.

#10: U procesoru je lepší mít více stavů nečinnosti. To by mohla být pravda u kteréhokoliv procesoru, ale nejde na základě toho procesory porovnávat. Záleží pouze na tom, kolik energie tyto stavy ušetří.

#11: Snižování frekvence procesoru [CPU throttling] ušetří energii. Tady je problém se záměnou termínů "příkon" a "energie". Procesor se sníženou frekvencí může šetřit mít menší příkon, ale je nutné ho mít puštěný déle, aby udělal svou práci. Takže přiškrcení procesoru (při zachování stejného napětí) může mít za následek více energie. Skoro vždy je lepší běžet s plnou frekvencí, jakou aktuální napětí povoluje, a dodělat práci rychleji; Len to popsal jako úprk k odpočinku.

Existují však druhotné účinky, které je možné vzít do úvahy. Především to, že baterie vydrží déle, pokud jsou vybity za delší dobu. Přiškrcený procesor může být také cladnější, což umožňuje vypnutí větráků. Přiškrcování může být nezbytné kvůli regulaci teploty. Ale z pohledu šetření energií jde skutečně jen o druhotné aspekty.

#12: Nemohu přispívat ke zlepšení ACPI v Linuxu. Stejně jako každý další projekt, i ACPI by uvítalo nové vývojáře. A kromě toho lze testovat jádra a reportovat chyby. Ve skutečnosti existuje mnoho příležitostí ke zlepšování ACPI kódu.

Jak uchopit Linux

Lenova poslední přednáška přešla od spotřeby energie k jejím účinkům - především vytváření tepla. Přebytečné teplo není vítáno v žádném zařízení, ale v handheldech [zařízení do ruky] dvojnásob. Zařízení, kvůli kterým se ruka potí, není moc příjemné používat; a ty, která jsou tak horká, že je nejde držet, mohou být zcela nepoužitelná. Správa teploty je tedy velmi důležitá. Jenže sama podstata těchto zařízení regulaci teploty velmi ztěžuje: v linuxovém mobilu není prostor pro větráky a odvádění tepla bývá všeobecně dost obtížné.

Specifikace ACPI 3.0 obsahuje komplikovaný teplotní model. Zařízení je rozděleno na zóny a všechny komponenty mají charakterizovaný svůj příspěvek každé zóně. Implementace této specifikace je složitá - do té míry, že vývojáři linuxového ACPI vůbec nepočítají s tím, že by to dělali. Místo toho se zaměří na něco jednoduššího.

To něco je teplotní model ACPI 2.0. Součástí jsou teplotní zóny, z nichž každá má teplotní senzory a několik spouštěcích stupňů [trip point]. Spouštěcí stupeň "kritické vypnutí" je nastaven těsně před tím, než se zařízení začne tavit; kdyby začalo být tak velké teplo, musí se zařízení co nejrychleji vypnout. Ještě předtím dojde na jiné spouštěcí stupně; měly by zařídit čím dál přísnější opatření pro omezení teploty. Může se jednat o zapnutí větráků (pokud jsou k dispozici), snížení frekvence nebo uspání zařízení na disk. ACPI 2.0 obsahuje řadič, který monitoruje teplotní senzory systému a posílá procesoru události, když se stane něco zajímavého.

Vyvíjený kód pro regulaci teploty zatím využívá stávající mechanismus pro kritické vypnutí, který je zabudován do ACPI. Existuje už také podpora pro některé pasívní spouštěcí stupně, které se starají o snižování frekvence procesoru. U teplotních zón, jež se netýkají procesoru, je však lepší nechat rozhodnutí o dalším postupu na uživatelském prostředí - takže to tak ACPI kód udělá. Bude připraveno netlink rozhraní, přes které bude možné posílat teplotní události a nastavovat sysfs adresáře pro čtení hodnot senzorů. Sysfs strom bude také obsahovat ovládací soubory, a ty bude moci využít uživatelský démon k přiškrcování různých zařízení na základě teplotních událostí.

Takže jádro bude nakonec jen spojka pro přenos událostí a ovládacích nastavení mezi komponenty zařízení a uživatelským prostorem. Objevily se otázky, jestli bude k dispozici standardizovaná sada sysfs čudlů pro ovládání každého zařízení; odpověď bude asi "ne". Každé zařízení je jiné, všechna mají své vlastní ovládací parametry; bylo by těžké vytvořit standardní sadu, která by je všechna popsala. Navíc jsou cílovou skupinou embedded zařízení, z nichž každé je unikátní. Očekává se, že každé zařízení bude mít svého vlastního specializovaného démona, který bude napsán přímo pro něj, takže není důvod věci zevšeobecňovat.

Ze všech těchto přednášek to vypadá, že v oblasti správy napájení se toho děje docela dost, ačkoliv to po dlouhou dobu byla část Linuxu, která nedosahovala potřebné kvality. Narůstající využívání Linuxu v embedded zařízeních tomu může jen pomoci; je dost výrobců, kteří mají velký zájem na vylepšené podpoře inteligentního využívání energie. Dostane-li se správě napájení času a dalšího úsilí, přestane to být možná zanedlouho problém, který by bylo potřeba řešit.

       

Komentáře

[Ses]

Díky za JN...

Pozn.: v #7 i když možná pomaleji, než bych si přáli

[Robert Krátký]

Dík.

[Ondrej 'SanTiago' Zajicek]

#11 v originale 'processor throttling' . Tim se AFAIK obvykle oznacuje spis nucene vkladani idle cyklu (obvykle pouzivane pri prekroceni teplotnich limitu), nez skutecne snizovani frekvence procesoru.

[Ondrej 'SanTiago' Zajicek]

Pro upresneni v originale 'processor throttling' namisto 'snizovani frekvence'.

[jirka22]

Hned mi to bylo divné. Frekvence se v tom obecném vzorečku pro spotřebu objevuje v druhé mocnině. Při nižší frekvenci výpočet trvá déle, ale skutečně se spotřebuje méně energie.

[Ondrej 'SanTiago' Zajicek]

> Frekvence se v tom obecném vzorečku pro spotřebu objevuje v druhé mocnině.

To spis napeti.

[Robert Krátký]

#11 v originale 'processor throttling' . Tim se AFAIK obvykle oznacuje spis nucene vkladani idle cyklu

Aha... upravím.

[Robert Krátký]

No, tak už si nejsem tak jistý... Na Wikipedii (http://en.wikipedia.org/wiki/CPU_throttling) se píše:

CPU throttling refers to a series of methods for reducing power consumption in computers by lowering the clock frequency.

[trekker.dk]

IMO to maj špatně. Throttling je vkládání idle cyklů, na mém starém Athlonu XP se to dalo ručně zapnout přes /proc a počítač výrazně zpomalil, přestože neuměl měnit frekvenci; samo se to spínalo při přehřátí. Teď mám Athlon64, který umí měnit frekvenci a v /proc/acpi/processor/CPU0/throttling je napsáno "not supported"

[disorder]

minimalne v linuxovej terminologii je scaling zmena frekvencie, throttling je vkladanie idle

[Filip Jirsák]

[časovače] které mají tendenci se časem rozbíhat od sebe – asi by bylo lepší rozbíhat samy od sebe.

[Semo]

Podla mna je to spravne. Chapem to nie ako casovace, ktore sa sami od seba spustia, ale ako casovace, ktorych najmensi spolocny nasobok period je vacsi nez maly.

[Robert Krátký]

Jsou tím myšleny časovače, jejichž doby vypršení se od sebe postupem času stále více oddalují.

[Filip Jirsák]

Ach so. Mně to bylo divné, jak se může časovač sám rozhodnout, že najednou poběží

[Joe]

rozumne systemy maji casovac jen jeden takze se nemuzou "rozbihat". ovsem pC, natoz ACPi, neni rozumne...

[disorder]

mein gott, odbornik

[Filip Jirsák]

Myšleny jsou asi časovače jako „příjemci“ nějakého pravidelného „tiku“. A těch i v seberozumnějším systému bude spousta – tu potřebuje časování hardware, nějaké časování potřebuje klávesnice pro opakování znaků, onde je potřeba časování pro nahrávání/přehrávání videa, a těch časovačů pro různé softwarové účely bude spousta. Problém je v tom, že časovač pro video tiká každých 250 milisekund, jiný bude mít tik třeba 230 milisekund (a nebo taky 250, ale někde se zpozdí, a poběží tak o pár milisekund za tím prvním). Tzn. místo aby se procesor probudil a udělal všechnu práci naráz, probudí se kvůli jednomu časovači, udělá práci pro něj, uspí se a za chvilenku se probudí znova kvůli jinému. To asi bylo myšleno tím „rozbíháním“ (jestli jsem to na druhý pokus pochopil správně). Jsem si vědom, že jsem pomíchal různé druhy časovačů, ale to snad lze pro tento příklad zanedbat.

[zde]

Ne, v PC je opravdu spousta nezávislých časovačů na všechno možné, které se samozřejmě rozjíždějí. Typický problém je (ve windows i linuxu) A/V synchronizace. Tam se to řeší tak, že se vybere tzv "master stream" (typicky audio), a audio driver posílá interrupty když prohazuje vstupní buffery. Ty se pak použijou pro doladění časovače, který časuje video. V podstatě je to takovej softwarovej fázovej závěs.

Nevím jak fungují jednoúčelové stolní přehrávače, ale asi s tím problém nemají, tam se obraz i zvuk časují ze stejných hodin, takže ujet nemůžou.

[Filip Jirsák]

To jsou ale předpokládám hardwarové časovače (na grabovací kartě, na zvukové kartě atd.), a ty asi nepůjde bez spolupráce procesoru přesvědčit o tom, aby počkaly ještě chvilku, ne? Ostatně během přehrávání nebo dokonce nahrávání videa se asi řeší jiné starosti, než že procesor málo spí

[fakenickname]

"Vypnout zařízení těsně před bodem tavení." -- Tak to je docela ostré. Ale zdá se mi to podezřelé, protože většina kovů (a asi i dalších materiálů) má tendenci si teplotní růst ponechat, takže pokud se zařízení vypne těsně před bodem tavení, neznamená to, že takové teploty nedosáhne. Možná to mysleli v originále jinak..

[Olsan]

To bylo ironické - myslí se tím dosažení nebezpečné teploty. Protože AFAIK se čip zničí o dost dřív, než vám vyteče ze socketu.

[Robert Krátký]

To bylo ironické - myslí se tím dosažení nebezpečné teploty.

Také to tak chápu.

[cedrik]

On se netaví cely čip, ale jenom jeho jednotlivá část (části), takže opravdu nevyteče, to dříve shoří. Nataví se, změní to svoje elektické a pak i mechanické vlastnosti a pak se může vyhodit, i když se to stane jen jedné souástce. V tom lepším případě máme krásný zážitek, jak se nám tvoří díra v čipu. Je to nádhera, stojí to za pohled. Dopuručuji vyzkoušet.

[Jiří (BoodOk) Kadeřávek]

To těsně znamená asi těsně před okamžikem kdy by již zastavení teplotního gradientu vyžadovalo aktivní chlazení. Ale moc bych se v tom nerýpal

[Jan Včelák]

Přiškrcený procesor může být také cladnější, což umožňuje vypnutí větráků.

[Robert Krátký]

Dík, opravím.

[Alex]

>Tady je problém se záměnou termínů "elektřina" a "energie"<. Puvodni termin 'power' je spatne prelozen jedna se o vykon/prikon/spotreba. Elektrina je dost nefyzikalni velicina. Je ovsem pravda, ze hodne lidi pojmy vykon a energie zamenuje. Hlavne zelena lobby, ktera se rada chlubi kolik energie vyrobi kdejakej vetrak nebo slunecni elektrarna.

[rejpal]

...hodne lidi pojmy vykon a energie zamenuje. Hlavne zelena lobby, ktera se rada chlubi kolik energie vyrobi kdejakej vetrak nebo slunecni elektrarna.

Svatá pravda, a nemusí se jednat jen o tuto lobby, ale stává se to "folklórem" v mediích vůbec. Neměli by takto postižení mediální experti žádat o navrácení školného??