Az új Windowsokban sokat tettek azért, hogy kevesebb energiát fogyasszanak a gépek. Munkaállomás esetén az akkuidő miatt fontos ez, kiszolgálóknál a villanyszámla és egyáltalán az energiapazarlás miatt fontos szempont a spórolás. Hogyan tudunk takarékoskodni? Automatikusan kapcsoljuk le azokat az eszközöket, amelyekre az adott pillanatban nincs szükség. Az előszobalámpát elintézzük kézzel, de a hardvereszközökhöz jobb, ha az operációs rendszer is segít, elvégre ő tudja, pontosan mit használunk és mit nem. Azt már régóta ismerjük, hogy a Windows lekapcsolja a képernyőt vagy a merevlemezt, ha nem ülünk a gép előtt. Vagy lejjebb vette a processzor órajel-sebességét, ha akkuról dolgoztunk. Nyilvánvalóan az egész témakör arról szól, hogy feladunk némi számítási teljesítményt, cserébe áramot spórolunk meg.
Persze lehet azért finomabban is szabályozni a megtakarításokat, akkor is, ha aktívan működik a gép. Erről lesz szó a következő részekben.
Processzortámogatás
A modern processzorokat át lehet kapcsolni alacsonyabb energiafogyasztású üzemmódokba. Az egyik megoldás az órajel frekvencia csökkentése, és a tápfeszültség csökkentése, ezek az ún. P állapotok. A frekvencia csökkentésével a belső kapacitások töltéséből-kisütéből származó dinamikus veszteség csökkenthető, a tápfesz csökkentésével pedig a szivárgóáramok okozta statikus teljesítményveszteség (a dinamikus veszteség egyenesen arányos a frekvenciával, a statikus pedig négyzetesen a feszültséggel). Mobil gépeken, laptopokon ez jó megoldás akkus üzem esetén, megy tovább a gép, csak kicsit lassabban. Passziánszhoz elég. Indexet olvasni még sok is.
Kiszolgálókon is használható lenne a frekvenciaszabályozás, azonban mivel ezekben általában elég sok processzor van, gyakran más megoldást használnak. Itt nem arról van szó, hogy csökkentik az órajel frekvenciát, hanem egyre mélyebb alvó állapotokba kapcsolják a processzorokat. Ezeket C állapotoknak hívják. Minél mélyebbre altatjuk a procit annál kevesebbet fogyaszt, de annál több idő is kell, mire észhez tér.
Nem annyira mély alvásból a megszakítások felébresztik a processzorokat, de a legmélyebb állapotokból már csak a maradék, még aktív processzorok tudják felébreszteni az alvókat.
Nagy vonalakban a következő C állapotokat ismerik a mai Intel processzorok:
· C0: teljes gázon működik
· C1, halt: nem hajt végre utasításokat, de szinte azonnal folytatja a futást, ha kell. Ennek egy továbbfejlesztett változata a C1E, ekkor lecsökkentik a processzor frekvenciáját és lejjebb húzzák a tápfeszültségét is.
· C2, stop-clock: ebben az állapotban már nem csak a processzoron belül kapcsolnak ki dolgokat, hanem bizonyos buszok szintjén is, de a processzor cache-t frissítik
· C3, sleep: itt már a processzor gyorsítótárát se tartják szinkronban, teljesen kikapuzzák az órajelet is
· C3, deep sleep: a legújabb processzorokban mélyebb alvó állapotokat is el lehet érni, itt a processzor energiafogyasztása már nagyon kevés lesz, de cserébe már több 10 ms kell az altatáshoz és az ébresztéshez is.
A gép indulásakor az eventlogban láthatók bejegyzések, amelyek a processzorok energiatakarékossági képességeit írják le, pl az alábbi egy szerveren látható:
Processor 6 exposes the following:
1 idle state(s) //csak C1-et tud
0 performance state(s) //Nincsenek benne P állapotok implementálva
8 throttle state(s) //8 T állapot (STPCLK, hasonló a P állapotokhoz)
Ez pedig a laptopomról, amiben mobil processzor van:
3 idle state(s) //C3-ig képes lemenni
4 performance state(s) //4 P állapot
8 throttle state(s) //8 T állapot
Core Parking
Láthatjuk, hogy szépen tudnak aludni a mai procik, most már csak az kell, hogy a Windows hagyja is őket minél tovább aludni. Erről szól a Windows 2008R2-ben bevezetett egy új technológia, a Core Parking.
Az eddigi Windowsok a maximális kiszolgáló-teljesítményre voltak hangolva, azaz igyekeztek kihasználni az összes processzort és egyenletesen elosztani rajtuk a terhelést, hogy a válaszidők és a kiszolgáló áteresztőképessége maximális legyen. De ettől nem csak a kiszolgáló-teljesítmény lesz nagy, hanem a villamos is, azaz sokat eszik a gép. Ha nem túl nagy a terhelés, és elég sok proci van egy kiszolgálóban, akkor a kisebb terhelést ki lehet szolgálni kevesebb processzorral is, cserébe azok valamivel terheltebbek lesznek, illetve a válaszidő valamennyire nagyobb lesz. Kicsit vagy közepesen terhelt kiszolgálóknál így nagyon sok teljesítményt meg lehet spórolni. Gondoljuk arra, hogy veszünk egy bika vasat, ami nap közben jól ki van terhelve, de éjszaka meg malmozik, pihen. Miután az utolsó terhelést okozó kolléga is elment és lekapcsolta a lámpákat, a Core Parking szépen lekapcsolja a felesleges processzorokat. A legelsőt mindig üzemben hagyja, hisz valakinek le kell kezelni az óra hardvermegszakítást, de a többiek szépen alukálnak. Egy sokprocesszoros gépen ez óriási megtakarítást eredményez. Az 1. ábrán a Resource Monitor bal alsó sarkában látható, hogy éppen alszik, parkolt a második processzor.
1. ábra: parkol a második processzor
Sokprocesszoros gépeken még közepes terhelésnél is tud parkolni jó pár processzor. Ez ne úgy képzeljük el, hogy órákig alszanak a processzorok, hanem alszanak pár másodpercet, aztán felébrednek, végeznek némi munkát majd megint alszanak egyet. Van, amikor csak pár tíz ms-ig alszanak, van, hogy percekig.
Timer összevonás (Timer coalescing)
Alvást gátló problémás pont, hogy az alkalmazások indíthatnak saját timereket, amelyek a megadott időközönként meghívnak a programban egy függvényt. Általában akkor élünk ezzel, ha valamit periodikusan meg kell ismételni, pl. várakozni valamilyen eseményre, amelyre nem tudunk kernel szinkronizációs objektummal várni.
A program azt mondja: kérek visszahívást mondjuk minden másodpercben. Ekkor a Windows elindít egy hardver timert, ami megszakításban jelez az OS-nek, hogy lejárt az idő, majd a Windows átdobja a hívást a kérő folyamatnak. Könnyű elképzelni, hogy sok program sok timere teljesen szabálytalan időközökben üt be, mert más a peródusidejük és más pillanatban indították el őket. Ez azért probléma, mert így a processzorok nem sokat tudnak aludni, hisz állandóan jön egy timer megszakítás.
Windows 7/2008R2-től a programok megadhatják, hogy mennyi csúszást viselnek el a timer időzítésében. Gondoljunk bele, sok esetben csak hasra ütésre választunk, mondjuk 1 mp-es periódusidőt, valójában teljesen mindegy, hogy ez 800ms vagy 1.5 mp lesz. Ha a programok jóindulatúak, és megadnak egy számukra elfogadható tűrést, akkor a Windows úgy rendezi össze a timer igényeket, hogylehetőleg sok program timer beütése egybe essen, ezáltal több ideig tudnak a processzorok aludni.
2. ábra: timer összevonás, a szétszórt timer eseményeket egybetereli a Windows, hogy ritkábbak legyenek a hardvermegszakítások, többet alhassanak a processzorok
Intelligens Tick elosztás
Egy processzor -általában az első- sose alszik, mert a kb. 15 ms-onként érkező óra megszakítást valakinek le kell kezelni. Ezt hívják ticknek. A tick alapvetően fontos egy preemptív operációs rendszer működéséhez, mert ebben (precízebben ez által kiváltva) van lehetősége az OS-nek lefuttatni az ütemező (scheduler) kódját, amely a szálak közötti ütemezést biztosítja. Ha nem lenne hardver megszakítás, hogyan tudná elrángatni a vezérlést az OS az éppen futó kódtól?
A tick az szépen beüt másodpercenként kb. 60-szor, ezt lekezeli egy processzor, a többiek alhatnak. Legalábbis Windows 2008R2-től kezdve, mert a korábbi OS-ek minden processzorra átvezették a tickeket, a 2008R2 a parkoltakra nem. Ez az intelligens tick elosztás.
A timer összevonás és az intelligens tick elosztás együtt eredményezi a 3. ábrán látható képet, amikor az összenyalábolt timer eseményeket kapcsán elküldenek egy-egy tickről is értesítést az addig alvó processzoroknak, így a terheletlen processzorokat ritkán zavarja meg bárminemű munka.
Azért azt érdemes még tudni, hogy az egyéb hardvermegszakítások, mint a hálózati kártyák vagy a merevlemez jelzései miatt továbbra is felébreszti a szükséges processzort az operációs rendszer, hisz ezek kiszolgálásával nem lehet késlekedni.
3. ábra: intelligens tick elosztás és timer összevonás után egyes processzoroknak igazán úri dolga lesz, alig kell nekik dolgozni
A kétféle megszakítások okozta ébrenlétek minimalizálása még ki van egészítve azzal is, hogy a Windows figyelembe veszi a tokok elosztását is. Ez azért fontos, mert egyes prociknál még nagyobb teljesítménycsökkentést lehet elérni, ha egy tokban az összes magot kikapcsolják, ezért erre is törekszik a kernel energiakezelője.
Zárásul, érdekességképpen még egy gondolat a témához. A 4. ábrán (az Inteltől töltöttem le) megfigyelhető, hogy a ritkább tickek lekezelése már elve kevesebb energiát igényel. Sűrűre állított óra megszakítások esetén (kék vonal) csak a megszakítások fogadása is már jelentős teljesítményigényt jelent.
4. ábra: egy adott processzor energiafogyasztása, ha a gép nincs terhelve, csak az óra megszakítások kezelése történik különböző frekvenciával