A Google Pixel okostelefonok a leggyorsabb Android telefonok közé tartoznak a piacon. Az Energy Aware Scheduling (EAS) részben az oka annak, hogy a telefon olyan sima.
A régmúltban, amikor a Linux csak egy ötlet volt Linus Torvalds fejében, a CPU-k egymagos entitások voltak, amelyek hatalmas mennyiségű energiát igényeltek kis teljesítményhez. Az első kereskedelmi forgalomban kapható processzor, az Intel 4004 740 kHz-es órajelen futott egyetlen magon. Akkor még nem volt szükség terhelésütemezőre. A terhelés ütemezését a kétmagos "behemótoknak" tartották fenn, mint például az IBM Power 4, amely néhány évtizeddel később jelent meg. Ezek vadállati 1,1 GHz-től 1,9 GHz-ig futottak, és programokra és a rendszerre volt szükség ahhoz, hogy ezeket a magokat helyesen használják fel. Hogyan jutottunk el ezektől a gépektől a több magot használó szoftveralgoritmusig? Talán már hallott már fórumainkon az Energy Aware ütemezésről (EAS). Részben ez az oka annak, hogy a Google Pixel okostelefonok olyan jól teljesítenek. Mi olyan jó az EAS-ben, és hogyan jutottunk el idáig? Mielőtt ezt megmagyarázhatnánk, beszélnünk kell a Linux betöltésütemezőiről.
A Linux terhelésütemezőinek fejlődése
Round-Robin ütemezés
A körkörös feldolgozás egy egyszerű fogalom, amelyet meg kell magyarázni és megérteni, és még egyszerűbb a hátrányainak megértése. A kör-robin időszeletelést használ az idő leosztásához az egyes folyamatokhoz. Tegyük fel, hogy négy folyamat fut a számítógépünkön.
- A folyamat
- B folyamat
- C folyamat
- D folyamat
Most pedig végezzük el a körmérkőzéses ütemező munkáját. Minden folyamathoz 100 ezredmásodpercet (időszeletelés) rendelünk, mielőtt továbblépnénk a következőre. Ez azt jelenti, hogy az A folyamat 100 ezredmásodpercig is eltarthat a feldolgozásig, majd átkerül a B folyamatra és így tovább. Ha egy alkalmazás feladatának elvégzése 250 ezredmásodpercet vesz igénybe, akkor ennek a folyamatnak háromszor kell végigmennie ahhoz, hogy befejezze a munkáját! Most skálázza ezt a különböző magok között úgy, hogy az A és B folyamat az 1. maghoz, a C és a D folyamat pedig a 2. maghoz legyen hozzárendelve. Ezt felváltotta az O(n) ütemezés (ami olyan volt, mint a körmérkőzés, de korszakokat használt, és lehetővé tette a dinamikus kiosztást idő), majd O(1) ütemezés (minimális többletköltség, korlátlan folyamattámogatás), végül a Teljesen tisztességes ütemező (CFS). A CFS-t 2007 októberében egyesítették a Linux kernel 2.6.23-as verziójával. Azóta átdolgozták, és még mindig az alapértelmezett ütemező a Linux rendszerekben.
Teljesen korrekt ütemező
A Completely Fair Scheduler a kezdetektől fogva létezik az Androidon, és nem nagy rendszereken használják. KIS készülékek. Intelligens algoritmust használ a feldolgozási sorrend, a lefoglalt idő stb. meghatározására. Ez egy példa a jól tanulmányozott ütemezési algoritmus, az úgynevezett "súlyozott fair queueing" működő megvalósítására. Ez alapvetően arra összpontosít, hogy elsőbbséget biztosítson a rendszerfolyamatoknak és más, a rendszeren futó magas prioritású folyamatoknak gép. Ha nagyon futna. KIS eszköz, minden mag egyenlőnek számítana. Ez rossz, mivel az alacsony fogyasztású magok intenzív alkalmazások futtatására kényszerülhetnek, vagy ami még rosszabb, az ellenkezője fordulhat elő. A zenehallgatáshoz szükséges dekódolás történhet például a nagy magon, így szükségtelenül növelve az energiafogyasztást. Ezért van szükségünk egy új ütemezőre a nagy számára. KIS, amely ténylegesen képes felismerni és energiahatékonyan felhasználni a magok közötti különbséget. Itt jön a képbe a Heterogeneous Multi-Processing (HMP), a szabványos betöltési ütemező, amely a legtöbb Android-telefonon most fut.
Heterogén többszörös feldolgozás
Ez a szabványos betöltésütemező minden nagy számára. KIS, az elmúlt években kiadott eszköz, a Google Pixel kivételével. A HMP kihasználja a nagy. KEVÉS architektúra, alacsony prioritású, kevésbé intenzív munkát delegál a kis magokra, amelyek kevesebb energiát fogyasztanak. A HMP "biztonságos", ahol hiba nélkül tudja, hogy mi kerüljön a nagy magokhoz, és mi a kis magokhoz. Egyszerűen működik, és sokkal kevesebb erőfeszítést igényel a fejlesztési oldalon történő beállítás, mint az EAS, amelybe egy pillanat alatt belevágunk. A HMP csak a CFS kiterjesztése, hogy tudatossá tegye a teljesítményét.
A HMP nem tesz tippeket, és nem jósol meg jövőbeli folyamatokat. Ez jó, de ezért a készülék nem tud olyan folyékonyan működni, mint az EAS-t futtatók, és ezért fogyaszt valamivel többet az akkumulátort. Ez végül elvezet minket az Energy Aware Scheduling-hez (EAS), amely szilárd meggyőződésem, hogy a ROM és a kernelfejlesztés jövője, ahogy egyre több OEM alkalmazza.
Energiatudatos ütemezés
Az Energy Aware Scheduling (EAS) a következő nagy dolog, amelyről fórumainkon a felhasználók beszélnek. Ha OnePlus 3-at (vagy Google Pixelt, természetesen) használ, biztosan hallott róla a fórumokon. A Qualcomm Snapdragon 845-tel bevezették a mainstreambe, így ha rendelkezik ilyen eszközökkel, akkor már rendelkezik EAS-kompatibilis okostelefonnal. EAS kernelek formájában, mint pl RenderZenith és ROM-ok, mint pl VertexOS és PureFusion a OnePlus 3 fórumait a legkorábban elfoglalták. Természetesen a Google Pixelhez is jár EAS. A megnövelt akkumulátor-élettartam és jobb teljesítmény ígéreteivel mi a csapda?
Az energiatudatos ütemezés nem olyan egyszerű, mivel nem univerzális minden eszközre, például a CFS-re vagy a HMP-re. Az EAS-nek egy energiamodell alapján meg kell ismernie a processzort, amelyen fut. Ezeket az energiamodelleket mérnökcsapatok készítik, akik folyamatosan tesztelik és dolgoznak az optimális teljesítmény érdekében. Mivel a Snapdragon 820 és 821 alapvetően ugyanaz, a OnePlus 3 egyéni kernelei a Google Pixel energiamodellt használják. A Snapdragon 845-tel rendelkező eszközök használhatják az EAS-t, a OnePlus 6 pedig bizonyos mértékben. Nem olyan hangolt, mint egy Google Pixel eszköz, de elvégzi a munkát. Íme egy példa arra, hogy annak ellenére, hogy a OnePlus 6 jobb processzorral rendelkezik EAS-szal, a Pixel 2 XL még mindig simán felülmúlja azt. Mindkét kép a miénkről készült sebességorientált felülvizsgálat a OnePlus 6-ból.
Ha problémái vannak a grafikonok megértésével, útmutatásként tekintse meg az alábbi képet. Bármi, ami meghaladja a zöld vonalat, kiesett képkockákat és a legrosszabb esetben észrevehető dadogást jelez.
Az EAS OnePlus 6 megvalósítása érdekes, mivel nem tűnik olyan teljes értékű megvalósításnak, mint amilyet egy Google Pixelben találna ugyanazzal a SoC-vel. Az ütemező hangolhatónak sincs sok értelme, így valószínűleg ez magyarázza, hogy miért nem olyan hatékony a teljesítménye, mint az elvárná. Az energiafogyasztás tekintetében rendkívül konzervatív, mivel a rendszer a munka nagy részében az alacsony fogyasztású magokat részesíti előnyben.
A hangolható paraméterek egyszerűen a CPU kormányzónak átadott paraméterek halmaza, amely megváltoztatja, hogy a kormányzó hogyan reagál bizonyos helyzetekre a frekvencia tekintetében. Az ütemező ezután eldönti, hová helyezi el a feladatokat a különböző processzorokon. A OnePlus 6 hangolható elemei úgy vannak beállítva, hogy előnyben részesítsék az alacsony fogyasztású magokon végzett munkát. Az sem segít, hogy a Google Pixel 2 hatalmas mennyiségű bemenettel rendelkezik, így mind a 8 mag folyamatosan online marad. A Google is használ egy megszakítás kiegyenlítő amely segít eltávolítani a keret leesését és javítja a teljesítményt.
Tehát hogyan működik az EAS? Miért olyan hatékony, csak bizonyos körülmények között?
Az Energy Aware Scheduling bevezeti az energiamodell használatának szükségességét, és ahogy fentebb említettük, sok tesztelést és munkát igényel, hogy tökéletes legyen. Az EAS megpróbálja egyesíteni a kernel három különböző központi részét, amelyek mindegyike egymástól függetlenül működik, és az energiamodell segít ezek egységesítésében.
- Linux ütemező (fent említett CFS)
- Linux cpuidle
- Linux cpufreq
Az ütemező alatt mind a 3 alkatrész egyesítése és együttes számítása energiamegtakarítási lehetőséget ad, mivel ezek együttes számítása lehetővé teszi, hogy a lehető leghatékonyabbak legyenek. A CPUIdle megpróbálja eldönteni, hogy a CPU mikor lépjen készenléti módba, míg a CPUFreq megpróbálja eldönteni, hogy mikor kell felfelé vagy lefelé állítani a CPU-t. Mindkét modul elsődleges célja az energiamegtakarítás. Nem csak ez, hanem négy c-csoportba sorolja a folyamatokat, amelyek a legjobb alkalmazás, a rendszer háttér, az előtér és a háttér. A feldolgozásra váró feladatok ezek valamelyikébe kerülnek, majd a kategória megkapja a CPU-teljesítményt, és a munka különböző CPU-magokra delegálódik. a top-app a legmagasabb prioritású befejezés, ezt követi az előtér, a háttér, majd a rendszer-háttér. A háttérnek technikailag ugyanolyan prioritása van, mint a rendszer-háttérnek, de a rendszer-háttér általában több kis maghoz is hozzáfér. Valójában az Energy Aware Scheduling a Linux kernel alapvető részeit foglalja magában, és mindezt egyetlen folyamatban egyesíti.
Amikor felébreszti az eszközt, az EAS a legsekélyebb üresjárati állapotban választja a magot, minimalizálva az eszköz felébresztéséhez szükséges energiát. Ez segít csökkenteni az eszköz használatához szükséges teljesítményt, mivel nem ébreszti fel a nagy klasztert, ha nem muszáj. A terheléskövetés szintén rendkívül fontos része az EAS-nak, és két lehetőség közül választhat. Az „Entity Load Tracking”-et (PELT) általában a terhelés követésére használják, majd az információkat a frekvenciák és a feladatok CPU-n keresztüli delegálásának meghatározására használják. A „Window-Assisted Load Tracking” (WALT) is használható, és ez az, amit a Google Pixel is használ. Fórumainkon sok EAS ROM, például a VertexOS, a WALT használatát választja. Sok ROM a kernel két verzióját fogja kiadni WALT-tal vagy PELT-tel, így a felhasználó dönti el. A WALT burstosabb, magas CPU-frekvenciájú csúcsokkal, míg a PELT igyekszik következetesebb maradni. A terheléskövető valójában nem befolyásolja a CPU frekvenciáját, csak közli a rendszerrel, hogy mennyi a CPU használat. A nagyobb CPU-használat magasabb frekvenciát igényel, ezért a PELT következetes tulajdonsága, hogy a CPU-frekvencia lassan emelkedik vagy csökken. A PELT hajlamos a magasabb CPU-terhelési jelentés felé tévedni, így magasabb teljesítményt biztosíthat magasabb akkumulátorköltség mellett. Jelenleg azonban senki sem tudja megmondani, hogy melyik terheléskövető rendszer a jobb, mivel mindkét terheléskövetési módszert folyamatosan javítják és finomítják.
Akárhogy is, nyilvánvaló, hogy az alkalmazott terheléskövetési módszertől függetlenül javul a hatékonyság. Ahelyett, hogy a feladatokat bármilyen processzoron feldolgoznák, a feladat elemzi, és megbecsüli a futtatásához szükséges energiamennyiséget. Ez az okos feladatelhelyezés azt jelenti, hogy a feladatok sokkal hatékonyabban hajthatók végre, miközben a rendszer egészét is felgyorsítja. Az EAS lényege, hogy a lehető legsimább felhasználói felületet kapja minimális energiafelhasználással. Ez az a hely, ahol más külső komponensek, például a schedtune jönnek szóba.
A Schedtune-t minden ccsoportban két hangolható definiálja, amelyek pontosabb ellenőrzést biztosítanak az elvégzendő feladatok felett. Nem csak a feladatok több CPU-ra való szétosztását szabályozza, hanem azt is, hogy az észlelt terhelést fel kell-e növelni az időérzékeny feladatok gyorsabb elvégzése érdekében. Így a felhasználó által igénybe vett előtérbeli alkalmazások és szolgáltatások nem lassulnak le, és nem okoznak szükségtelen teljesítményproblémákat.
Bár az energiatudatos ütemezés a következő nagy dolog, az is vitatható, hogy ez már megvan, és már egy ideje. Egyre több eszköz kerül a mainstreambe az Energy Aware ütemezéssel, a mobil feldolgozás hatékonyságának új korszaka itt van.
A Round-Robin, a CFS, a HMP és az EAS előnyei és hátrányai
Bár a grafikai készségeim alulmúlnak, összeállítottam egy képet, amely összefoglalja, hogy ezeknek az ütemezőknek milyen előnyei és hátrányai vannak.
Szeretnék külön köszönetet mondani az XDA Elismert Közreműködőnek Mostafa Wael akiknek az EAS különféle vonatkozásaira vonatkozó magyarázatai nagyban segítették ennek a cikknek a létrejöttét. Szeretnék köszönetet mondani az XDA Recognized Developernek is joshuus, XDA elismert fejlesztő RenderBroken és Mostafa Wael az EAS-en írt írásáért. Azok számára, akik érdeklődést mutattak az EAS-szal kapcsolatos alkatrészek iránt, a Linaro rengeteg dokumentációt tartalmaz az EAS-ről, amelyeket el is olvashat.