- A cpuidle különválasztja a szabályzatot és a mechanizmust azáltal, hogy vezérlőket és illesztőprogramokat használ a CPU alvó állapotainak kezelésére.
- Az állapotkiválasztás a célhely, a kimeneti késleltetés, az inaktivitási előzmények és a közelgő időzítők alapján történik.
- PM QoS és a tick ütemező feltétele, hogy a mély állapotok használhatók a késleltetési követelmények megsértése nélkül.
- Az ARM-ban és más modern SoC-kben a cpuidle PSCI-n keresztül integrálva van a firmware-rel, ami kulcsfontosságú a valós energiafogyasztás és az akkumulátor élettartama szempontjából.
Ha Linuxot használsz laptopon, asztali számítógépen vagy ARM alaplapon, és aggódsz amiatt, akkumulátor, hő, vagy miért nem megy alvó üzemmódba a CPU "ahogy kellene", megérteni az alrendszer működését cpuidle Ez kulcsfontosságú. Valami olyan egyszerű dolog mögött, mint a „a CPU tétlen”, egy meglehetősen kifinomult mechanizmus rejtőzik, amely eldönti, hogy milyen nyugalmi állapotot alkalmazzunk, mennyi ideig aludjunk, és mennyi idő alatt ébredjünk fel.
Továbbá, ha olyan projektekből érkezel, mint például Asahi Linux Macen M1/M2-velTeljesen normális, ha összezavarodunk: a következő autók sofőrjeiről beszélünk: cpuidle...éretlen vagy teljesen hiányzó nyugalmi állapotokból, és hogy pontosan ez akadályozza meg a rendszer mindennapi használatát. Ebben a cikkben nyugodtan lebontjuk... Mi is pontosan a cpuidle, hogyan működik belsőleg, milyen szerepet játszanak benne a vezérlők és illesztőprogramok, hogyan van konfigurálva, milyen kernelbeállítások befolyásolják, és hogyan integrálódik a modern ARM platformokba? például azok, amelyek PSCI-t vagy TF-A-t használnak.
Mi a cpuidle alrendszer és miért létezik?
Évtizedekkel ezelőtt a kernel „pihenő” része egy üres ciklus volt.Amikor nem volt mit végrehajtani, lefutott az üresjárati ciklus, ami lényegében egy végtelen ciklust hozott létre a következő megszakításra várva. Már azzal is, hogy nem hajtottak végre komplex kódot, némi energiát takarítottak meg: a gyorsítótárat, az FPU-t stb. nem használták annyira.
A hardverek fejlődésével a processzorok számos funkciót kínáltak. tétlen állapotok (C-állapotok)mindegyikhez eltérő megtakarítási szintek és büntetések társulnak: egy mélyállapotba való belépés sok energiát takaríthat meg, de Több időbe és energiába telik be- és kijutni Tőle. Ha túl mély állapotba kerülsz, és túl gyorsan felébredsz, akkor veszítettél.
Itt jön a játék cpuidle, a CPU üresjárati idejének kezelésére szolgáló kernel alrendszerA célja, hogy minden alkalommal, amikor egy CPU kifogy a feladatokból (csak az üresjárati feladat marad), eldöntse, melyik a legjobb alvó állapot, amelyet energiamegtakarításra használhat a válaszidő megszakítása nélkül.
Fogalmilag a cpuidle két darabot választ el egymástól: az egyik oldalon a mechanizmus (meghajtók), amely tudja, hogyan kommunikáljon a hardverrel és hogyan sorolja fel az üresjárati állapotokat; és másrészt a politika (kormányzók)amely eldönti, hogy melyik konkrét állapotot kell használni egy adott időpontban, a következők alapján: inaktivitási előzmények, közelgő időzítők és késleltetési korlátozások.
Mindez az alapjárati ciklusban történik.Amikor az ütemező látja, hogy egy CPU-nak nincs több futtatható feladata, végrehajtja a speciális „tétlen” feladatot, amelynek kódja először a kormányzót hívja meg az állapot kiválasztására, majd a meghajtót a belépésre.
Logikai CPU-k, tétlen feladat és mit jelent a tétlenség
Az alrendszer A cpuidle mindig logikai CPU-k szerint működikVagyis az ütemező által látott entitások lehetnek fizikai magok, hardverszálak (hiperszálak) vagy ezek kombinációi, az architektúrától és a megvalósítástól függően.
A kernel szempontjából egy logikai CPU akkor „tétlen”, ha Nincsenek hozzá kapcsolódó végrehajtható feladatok, kivéve az üresjárati feladatot.Az ütemező a folyamatokat és a szálakat „feladatokként” kezeli, és ezek különböző állapotokban lehetnek; amikor egy feladat futtathatóvá válik, hozzárendelődik egy CPU-hoz. Ha egy CPU-nak csak a futtatható feladat marad tétlenül, a kernel inaktívnak tekinti.
Az üresjárati feladat végrehajtja a hívást tétlen ciklusEz a ciklus minden iterációban meghív egy cpuidle vezérlőt, hogy eldöntse az alvó állapotot, majd meghívja a cpuidle illesztőprogramot, hogy kérje a hardvertől az állapotba lépést. Ha nincsenek elérhető alvó állapotok, nincs elég idő a következő eseményig, vagy a késleltetési korlátok túl szigorúak, a CPU vagy egy viszonylag haszontalan ciklust hajt végre, vagy a legalapvetőbb várakozási utasítást használja (például a `wait`-ot). hlt vagy hasonló).
Többmagos processzorokban vagy SMT-vel rendelkezőkben a A tétlen döntések befolyásolják az egységhierarchiákatEgy szál szintű alváskérés a magot mélyebb állapotba hozhatja, ha minden szál tétlen, és így egy magfürt alvó állapotba kerülhet, ha minden tagja engedélyezi. A cpuidle-nek ezt a következőképpen kell modelleznie... olyan állapotok, amelyek a hierarchikus szintek kombinációit képviselik, a lehető legmélyebb állapotot tükröző latenciákkal és rezidenciákkal.
Amikor egy típusú objektum által reprezentált állapotot kérünk struct cpuidle_stateA meghajtó engedélyezheti a hardvernek, hogy olyan mélyre menjen, amennyire a terv megengedi. Ezért A kilépési késleltetést és a célhelyszínt a valós legrosszabb eseti állapotkombinációhoz kell igazítani. a hierarchián belül (mag, klaszter, csomag stb.).
CPUIDLE irányítók: hogyan döntik el, melyik állapotot használják
sok A cpuidle irányítók házirend-modulok Ezek a folyamatok minden alkalommal lefutnak, amikor egy CPU belép az üresjárati ciklusba. Céljuk, hogy a rendelkezésre álló információk alapján kiválasszák azt az üresjárati állapotot, amely a legtöbb energiát takarítja meg a késleltetési korlátok megsértése nélkül.
Minden kormányzót egy struktúraként definiálnak struct cpuidle_governorvisszahívásokkal enable, disable, select y reflect, egy prioritási mező (rating) és egy nevet. Miután regisztrálta magát a következővel: cpuidle_register_governor(), a kernel automatikusan kiválaszthatja (a besorolás, az alapértelmezett konfiguráció vagy a paraméter alapján) cpuidle.governor=) vagy manuálisan a felhasználói térből a sysfs-en keresztül.
Amikor egy CPU-hoz egy vezérlőt aktiválnak a visszahívásán keresztül enable(), kap egy struct cpuidle_device ami azt a CPU-t és egy struct cpuidle_driver az elérhető államok listájával (struct cpuidle_state). Igen enable() Nem sikerül; a kernel egy alapértelmezett tétlenségi kódot használ. architektúra-specifikus a cpuidle helyett az adott CPU-hoz.
A kormányzó szíve a visszahívás select()amely fogadja a cpuidle eszközt, az illesztőprogramot és egy mutatót egy logikai értékre stop_tickEz a visszahívás a kiválasztott állapot indexét adja vissza az állapotok tömbjén belül, vagy egy negatív hibakódot. Ezenkívül eldöntheti, hogy leállítsa-e a bitütemezőt az adott CPU-n (törölje a logikai értéket vagy sem).
Amikor a CPU felébred, a vezérlő megkapja a hívást a következőhöz: reflect() információkkal arról, hogy melyik államot választották, és mennyi ideig tartott a leállás. Ez lehetővé teszi, hogy finomítsák előrejelzéseiket a korábbi adatok alapjánA PM QoS késleltetési korlátozásainak betartása is kötelező: cpuidle_governor_latency_req() megkapja a tényleges késleltetési korlátot, és soha nem szabad olyan állapotot választania, amelynek exit_latency meghaladja azt az értéket.
Fő irányítók: létra, haltpoll, menü és teo
Linuxban számos cpuidle irányító létezik, mindegyiknek megvan a saját stratégiája és célközönsége. A négy fő a ladder, a haltpoll, a menu és a teo., és hogy melyiket választjuk alapértelmezés szerint, nagyban függ attól, hogy a kernel tickless (képes-e leállítani a tick ütemezőt) vagy sem.
létra Aktív periodikus ketyegést alkalmazó rendszerekhez tervezték. Egyszerű megközelítést alkalmaz, amely szinte kizárólag a következőn alapul: tétlenségi időtartam előzményeiFel-alá jár az állapotok „létráján”, mélyebb állapotokba lépve, amikor kellően hosszú tétlenséget tapasztal, és visszahúzódva, amikor az ébredések túl korán következnek be.
haltpoll Ez egy speciális vezérlő virtuális gépekhez. Ahelyett, hogy mély hardveres tétlenségi állapotba kerülne, Nagyban támaszkodik a közvélemény-kutatásokra. (várakozóhurok) a látszólagos késleltetés csökkentése érdekében olyan környezetekben, ahol a fizikai nyugalmi állapotok nem járulnak hozzá jelentősen, vagy a hipervizor nem modellezi őket jól.
menü y teo Ezeket a kullancsmentes rendszerekben használt szabályozókat használják (CONFIG_NO_HZ_IDLE o CONFIG_NO_HZ_FULLMindkettő egyesíti a Tétlen időszakok előzményei a következő időzítő információivalés megpróbálnak energiát megtakarítani anélkül, hogy több időt töltenének a döntés kiszámolásával, mint amennyit megtakarítanak a meghozatalával.
A kormányzó menü szól explicit módon megjósolja, hogy mennyi ideig lesz tétlen a CPUA következő időzítőig eltelt idő egy részét felső határként veszi fel, és a közelmúltbeli inaktivitási előzményeken alapuló korrekciós tényezőt alkalmaz a „tipikus” időtartam becsléséhez. Ezzel a becsült értékkel tekintse meg az állapottáblázatot a legmélyebb állapot kiválasztásához, amelyhez a cél tartózkodási hely illeszkedik.
A kormányzó teo (Időzítő-eseményorientált) Másképp kezeli a problémát: a pontos leállási idő előrejelzése helyett, Az egyes állapotokhoz tartozó "tárolóhelyekre" vagy intervallumokba számszerűsíti a historikus adatokat.Minden egyes tartomány megfelel annak az időtartománynak, amelyben az adott állapot jellemzően optimális. A TEO a következő metrikákra vonatkozóan tart fenn adatokat: találat (ébredések, ahol a tényleges időtartam megegyezik a célzott lakhellyel) és lehallgatja (időn kívüli események miatti felébredések, amelyek megzavarják a jóslatot), és ezzel közvetlenül következtet Melyik konkrét államnak van a legnagyobb valószínűsége a helyes válaszra?.
A TEO csak akkor ellenőrzi a következő időzítőig hátralévő időt, ha az neki előnyös, hogy elkerülje egy olyan állapotba való belépést, amelynek a célzott tartózkodási idő hosszabb, mint a ténylegesen elérhető időablakTovábbá a kialakítása a döntési költségek csökkentésére törekszik: nagyon rövid üresjárati idővel járó forgatókönyvek esetén jobb gyorsan egy sekély állapotot választani, mint több energiát pazarolni a gondolkodásra, mint amennyit megtakarítunk.
cpuidle illesztőprogramok: híd a kernel és a hardver között
Miközben a kormányzók a politikával vannak elfoglalva, a A cpuidle illesztőprogramok valósítják meg a tényleges állapot bemeneti/kimeneti mechanizmusátMinden illesztőprogram a processzor (vagy CPU-k egy csoportja) által támogatott állapotok listáját jelöli egy struct cpuidle_driver amely tartalmazza a következő tömböt: struct cpuidle_state.
Minden struct cpuidle_state meghatározza többek között a cél lakóhelyet (target_residency mikroszekundumban), a maximális kimeneti késleltetés (exit_latency), olyan zászlók, mint CPUIDLE_FLAG_POLLING és ami nagyon fontos, egy visszahívás enter() amelyik a kényes részt végzi: végrehajtja a hardvernek az adott állapotba való belépéséhez szükséges utasításokat vagy hívásokat.
Az állapot tömbben lévő bejegyzéseket a következő sorrendben kell rendezni: cél_lakóhely növekvőÍgy a 0 index jellemzően a legsekélyebb (és legolcsóbban használható) állapotnak felel meg, a további indexek pedig egyre mélyebb állapotokhoz kapcsolódnak. A kormányzók ezt a sorrendet feltételezik a számításaikban.
A visszahívás enter() fogadja a használandó cpuidle eszközt, illesztőprogramot és állapotindexetFelfüggesztéses típusú esetekben felfüggesztés alapjáraton, helyette azt használják enter_s2idle()amelynek szigorúbb korlátozásoknak kell megfelelnie: végrehajtása során nem aktiválhatja újra a megszakításokat, és nem manipulálhatja az időzítő eszközöket, ami enter() Igen, platformtól függően megoldható.
Az állapotok leírása mellett a meghajtónak rögzítenie kell, hogy mely CPU-k vannak az irányítása alatt: minden CPU-nak megvan a saját struct cpuidle_device, amelyet általában a következővel regisztrálnak: cpuidle_register_device()Ha nincsenek „kapcsolt” állapotok (amelyek több CPU közötti koordinációt igényelnek), akkor a regiszter a következővel készül el: cpuidle_register_driver()Ha vannak ilyenek, azokat használják cpuidle_register()amely az eszközök regisztrációjáért is felelős.
A modern platformok megpróbálják csökkenteni a specifikus illesztőprogramok számát: például az ARM jellemzően egy általános illesztőprogramot használ, amely szabványos interfészekre, például a PSCI-re (Power State Coordination Interface) delegálhatóÉs a RISC-V-ben valami hasonló az SBI-n (Supervisor Binary Interface) keresztül. Ennek ellenére az ilyen meghajtóprogramok továbbra is léteznek x86-ban. intel_idle (a meghajtóba "beégetett" állapottáblával) és acpi_idle (amely az ACPI táblákból nyeri ki az állapotokat).
Inaktivitási állapotok: paraméterek, rendszerfszek és metrikák
Minden nyugalmi állapotot, amelyet a cpuidle kormányzóknak tesz ki, számos fő paraméter jellemez. A két legfontosabb a célzott lakóhely (target_residency) és kimeneti késleltetés (exit_latency), mindkettő mikroszekundumban.
La target_residency A gyakorlatban az állam energetikai mélységét jelöli.Ez a minimális időtartam, ameddig a hardvernek ebben az állapotban kell maradnia (beleértve a belépési költséget is) ahhoz, hogy megérje a működést a kevésbé intenzív állapotokhoz képest. Ha a rendszer a tartózkodási idő elérése előtt felébred, valószínűleg több energiát fordított az állapotba való belépésre, mint amennyit megtakarított.
La exit_latency Beállítja a legrosszabb esetre vonatkozó időt, amely eltelik a CPU általi kilépés kérése és a következő hasznos utasítás tényleges végrehajtása között.Ide tartozik az az eset is, amikor egy felébresztési esemény érkezik, miközben a hardver még belép az állapotba, mivel általában a belső átmenetnek be kell fejeződnie, mielőtt rendezett módon kiléphetne.
Ezenkívül vannak olyan jelzők is, amelyek az állam további tulajdonságait írják le: például, CPUIDLE_FLAG_POLLING azt jelzi, hogy ez az „állapot” valójában nem hardveres pihenőhanem egy lekérdező hurok, amelyet speciális mechanizmusként használnak a valós állapotok megérintésének elkerülésére, amikor az kényelmes (például bizonyos virtualizált vagy hibakeresési környezetekben).
A kernel nagyon részletes információkat tesz elérhetővé a CPU tétlenségi állapotairól a sysfs-en keresztül, a /sys/devices/system/cpu/cpu<N>/cpuidle/Vannak ott címtárak. state0, state1stb., a meghajtó tömb minden bemenetéhez egyet, és mindegyikben megtaláljuk olyan tulajdonságok, mint name, desc, latency, residency, usage, time, power, above, below y rejected.
Ezek a tulajdonságok lehetővé teszik számunkra, hogy lássuk hányszor kérték az egyes államokat?usage), a kernel szerint mennyi időt töltöttek vele összesen (time)és milyen mértékben volt jó vagy rossz a választás (above y below Számítják azokat az eseteket, amikor a tényleges üresjárati időtartam egyértelműen túl rövid vagy túl hosszú volt a céllakáshoz képest. rejected Számolja azokat az alkalmakat, amikor a kérést elutasították, jellemzően azért, mert egy megszakítás történt közvetlenül az átmenet idején.
Van egy különösen hasznos tulajdonsága, disableEz lehetővé teszi egy adott CPU-állapot aktiválását vagy deaktiválását a felhasználói térből (1 vagy 0 beírásával). Ha le van tiltva egy CPU-nál, a vezérlő nem veszi figyelembe a kiválasztáskor; ha teljesen el szeretne távolítani egy rendszerállapotot, akkor a következőket kell tennie: tiltsd le az összes CPU-n. Tulajdonság default_status jelzi, hogy az állapot alapértelmezés szerint engedélyezve van-e vagy sem.
A kullancsütemező és a kullancsmentes rendszerek
a híres ütemező pipa Ez egy periodikus időzítő (100, 250 vagy 1000 Hz, a készülék állapotától függően) CONFIG_HZ), amelyet a kernel többek között a CPU-idő feladatok közötti elosztására, a számlálók frissítésére és az időzítő lejáratának kiváltására használ.
A cpuidle szempontjából a periodikus ketyegés kellemetlen: amíg aktív egy tétlen CPU-n, A CPU hosszabb ideig tud aludni, mint a ketyegési periódusTovábbá minden egyes felébredés kullancsonként magában foglalja a nyugalmi állapotba való belépést és kilépést, energiapazarlással, ha túl mélyet választunk.
Definíció szerint egy olyan CPU-n, amely csak az alapjárati ciklust futtatja, Nem feltétlenül szükséges a kullancs megtartása CPU-megosztás esetén: nincsenek több futtatható feladatok. Ezért a Linux a következőképpen konfigurálható: kullancsmentes alapjáraton (CONFIG_NO_HZ_IDLE) vagy „teljes” módban, amikor csak egy elszigetelt feladat van a CPU-n (CONFIG_NO_HZ_FULL), deaktiválva a kullancsot ilyen feltételek mellett.
A kullancs leállításáról vagy leállításáról a kormányzó dönt a paraméter segítségével. stop_tick a visszahívásodból select()Ha rövid távon (egy időintervallumon belül) megszakításra számít (időzítővel vagy más módon), Nincs értelme kikapcsolni a kullancsot.Időt venne igénybe az újraprogramozása, és a leállási időszak esetleg túl felszínes lenne, ha kiderülne, hogy senki sem ébreszti fel a CPU-t.
Fordítva, ha a vezérlő úgy véli, hogy a CPU hosszabb ideig lesz tétlen, mint az adott időpontban, és a kiválasztott állapot mély, A legjobb, ha leállítod a ketyegést, hogy ne menjen tönkre a megtakarításod.Néhány kernel konfiguráció (paraméter nohz=off vagy letiltani CONFIG_NO_HZ_IDLE) arra kényszeríti a kullancsot, hogy soha ne álljon le, ebben az esetben a rendszer nem kullancsmentes, és az alapértelmezett irányító általában a ladder a menu vagy a teo helyett.
PM QoS: A nyugalmi késleltetések szabályozása
A kerete Energiagazdálkodási szolgáltatásminőség (PM QoS) Lehetővé teszi a meghajtóprogramok és a felhasználói térben zajló folyamatok számára, hogy korlátozásokat fejezzenek ki a rendszer energiaviselkedésére vonatkozóan, különösen a következőkre vonatkozóan: az alvó állapotok bemeneti/kimeneti késleltetései.
A cpuidle esetében két fő korlátozástípus létezik: globális CPU késleltetési korlát és a korlátozások CPU folytatási késleltetés (pm_qos_resume_latency_us)A kéréseket belsőleg prioritási listákban tárolja a rendszer, és az effektív érték ebben az esetben az összes kért érték minimuma.
A felhasználói térből a globális limit módosítható a megnyitással /dev/cpu_dma_latency és egy 32 bites egész szám beírása a leíróba a maximálisan tolerált késleltetéssel mikroszekundumban. Minden nyitott leíró egy független kérést képvisel.Amikor bezárul, a kérés eltűnik, és a rendszer a többivel újraszámítja a tényleges értéket.
A CPU-korlátozásokhoz van egy fájl power/pm_qos_resume_latency_us en /sys/devices/system/cpu/cpu<N>/Egy érték odaírása megváltoztatja az adott CPU-hoz társított kérést (amelyet a teljes felhasználói tér megoszt, ezért célszerű eldönteni, hogy ki férhet hozzá). A kernel illesztőprogramok a belső PM QoS API-kon keresztül is regisztrálhatják saját kéréseiket.
A cpuidle kormányzóinak minden állami választáson a következőket kell tenniük: tartsd be a tényleges globális késleltetés és az érintett CPU késleltetése közötti minimumotNem választhatnak olyan államokat, amelyek exit_latency túllépi ezt a határértéket. Ez rendkívül fontos olyan szoftverek esetében, amelyek lágy valós idejű követelmények, például hang- vagy videófájlok, ahol a mély állapotból való túl lassú folytatás alulfutásokat vagy hibákat okozhat.
Van egy másik QoS is, cpu_wakeup_latencyami befolyásolja az alapállapotok megválasztását az üzemmód során felfüggesztés alapjáraton (s2idle) a rendszerben. A kezelése a felhasználói térből hasonló a cpu_dma_latency és mikroszekundumban is kifejezik.
cpuidle vezérlés kernel paramétereken keresztül
A Linux lehetővé teszi a cpuidle és az idle illesztőprogramok viselkedésének módosítását a kernel parancssorából. A legszigorúbb paraméter a cpuidle.off=1Ez teljesen letiltja az alrendszert: az üresjárati ciklus továbbra is létezik, de a cpuidle vezérlők és illesztőprogramok már nem kerülnek meghívásra, ehelyett az architektúra „alapértelmezett” mechanizmusát használja, ami általában sokkal egyszerűbb és kevésbé hatékony.
Paraméter cpuidle.governor=<nombre> Lehetővé teszi, hogy a kormányzót arra kényszerítsd, hogy például a következőt használja: cpuidle.governor=menu o cpuidle.governor=teo, ahelyett, amelyik automatikusan kiválasztásra kerülne. Ez akkor hasznos, ha ugyanazon a hardveren szeretnél kísérletezni az energiafogyasztással és a késleltetéssel a kernel újrafordítása nélkül.
Az x86 architektúrákban vannak olyan speciális paraméterek is, amelyek az alapjárati módba lépés módjára vonatkoznak. Például: idle=halt y idle=poll Letiltják a drivereket. intel_idle y acpi_idlea rendszert az utasítás használatára kényszeríti hlt vagy egy tiszta lekérdező ciklus a többi adathoz. Ez leegyszerűsíti a viselkedést, de a hatékonyság rovására megy: idle=pollKülönösen megakadályozhatja a P-állapotok használatát, amelyek megkövetelik a CPU-k tétlenségét, rontva az energiafogyasztást és az egyszálú teljesítményt.
Paraméter idle=nomwait tiltja az MWAIT utasítás használatát alvó állapotokba való belépéshez, kényszerítve acpi_idle használni hlt és kikapcsolása intel_idle Az Intel processzorokban csak az ACPI kezeli az állapotokat. Továbbá az illesztőprogramok intel_idle y processor (ez utóbbiba beletartozik) acpi_idle) fogadjon el olyan lehetőségeket, mint intel_idle.max_cstate=<n> y processor.max_cstate=<n> hogy leszűkítse az illesztőprogramban elérhető állapotok listáját, és elvesse azokat, amelyek mélyebben vannak a megadott indexnél.
Abban az esetben, intel_idle.max_cstate=0Ez egyenértékű azzal, mintha kifejezetten letiltanánk az Intel illesztőprogramot, és hagynánk, hogy az ACPI illesztőprogram vegye át az irányítást, miközben processor.max_cstate=0 úgy értelmezik processor.max_cstate=1Ezek hasznos lehetőségek a következőkhöz: stabilitási problémák, rendellenes késleltetések vagy szokatlan energiafogyasztás diagnosztizálására, azon az áron, hogy korlátozza a rendszer energiatakarékos képességét alapjáraton.
Integráció ARM, PSCI és készenléti platformokkal
A modern ARM platformokon (például számos TI, NXP, Rockchip, Apple és Asahi SoC-ján stb.) A cpuidle jellemzően alacsony szintű firmware-rel van integrálva PSCI-n keresztül.és gyakori az IoT eszközökben intelligens IoT szolgáltatásmenedzsmentA cpuidle általános ARM illesztőprogramja az, amely SMC (Secure Monitor Call) hívások segítségével kommunikál a PSCI-vel, és az aktuális állapotátmenetet TF-A-ra (Arm Trusted Firmware) vagy más azzal egyenértékű firmware-re delegálja.
Egy tipikus példa erre egy olyan SoC, mint az AM62x, ahol a A készenléti állapot CPUIdle állapotként van megvalósítva a WFI (Wait For Interrupt) utasítás alapjánA felhasználó szemszögéből a rendszer folyamatosan, másodpercenként többször is belép és kilép a készenléti állapotból, interakció nélkül: ez az alapértelmezett „enyhe” készenléti állapot, amelynek be- és kilépési ideje mikroszekundum nagyságrendű.
A végrehajtási útvonal, amikor a rendszer tétlen üzemmódba lép ezeken a platformokon, körülbelül a következő: Az üresjárati ciklus érzékeli, hogy nincsenek feladatok, és a vezérlő kiválasztja a megfelelő állapotot (például egy úgynevezett állapotot). stby)Az általános ARM-illesztőprogram a rétegen keresztül hívja meg a PSCI-t. drivers/firmware/psci.c, és a TF-A oldalon a kezelő meghívódik cpu_standby() a struktúrában meghatározott plat_psci_opsOtt történik igazán. WFI.
Amikor egy megszakítás érkezik, a processzor automatikusan kilép a WFI-ből, a TF-A visszaadja a vezérlést a kernelnek, és a CPU onnan folytatja a végrehajtást, ahol abbahagyta. Mindez transzparens módon történik, feltéve, hogy a az eszközfa pontosan leírja az üresjárati állapotokat (csomópont idle-states, az egyes CPU-któl származó referenciák és olyan tulajdonságok, mint a entry-latency-us, exit-latency-us y min-residency-us).
Ezt a könnyű CPU-készenléti állapotot nem szabad összekeverni a következővel: rendszerszintű mély alvás módokahol teljes tápegységeket állítanak le, a perifériákat újrakonfigurálják, és a bemeneti/kimeneti idők milliszekundumos vagy másodperces tartományban vannak. A CPU üresjárati állapotai inkább a ... felé irányulnak. rövid távú pihenés mikromenedzseléseA mély alvás módok ezzel szemben a futásidejű PM, a felfüggesztési/folytatási illesztőprogramok további koordinációját, valamint gyakran a rendszerbetöltő vagy a firmware specifikus támogatását igénylik.
Miután a kernelben engedélyezve van a cpuidle, és van egy működő illesztőprogram (például az általános ARM + PSCI illesztőprogram, amelyet helyesen leírtak a DT-ben), A felhasználónak nem kell semmit "aktiválnia".A kormányzók automatikusan kezelik. A statisztikákat azonban megtekintheti a /sys, változtassa meg a jelenlegi kormányzót /sys/devices/system/cpu/cpuidle/current_governor vagy módosítsa a meghajtó által megjelenített állapotok tulajdonságait.
Viszonylag új platformokon vagy olyan portolási folyamatokban, mint az Asahi Linux, az akkumulátorral, a túlmelegedéssel vagy a funkcionális "alvó" állapot hiányával kapcsolatos problémák közül sok a következőkhöz kapcsolódik: hogy a cpuidle teljes hardverintegrációja még nem létezik (vagy nem érett)A problémák a következők: hiányoznak a fejlesztőeszközből a jól leírt állapotok, nincs olyan firmware, amely ésszerű állapotokat valósítana meg, vagy a meghajtóprogram még fejlesztés alatt áll. Amíg ez nem stabilizálódik, gyakori, hogy csak egy nagyon alapvető Wi-Fi állapotot használnak, vagy ami még rosszabb, hogy teljesen letiltják a CPU IDLE-t, és egy meglehetősen kezdetleges alvó állapotban maradnak.
Végső soron annak megértése, hogy a cpuidle hogyan modellezi a logikai CPU-kat, hogyan hoznak döntéseket a vezérlők Célhelyiségek, késleltetések és PM QoSHa megértjük, hogyan kapcsolódnak az illesztőprogramok az ACPI-hez, a PSCI-hez vagy a saját firmware-hez, és hogyan szabályozza az ütemező az üresjárati időszakokat, új megvilágításba kerülhet, hogy a laptop miért bírja tovább (vagy rövidebb ideig) akkumulátorral, miért fogyaszt általában kevesebb energiát egy „kullancsmentes” kernel, és miért bizonyos egzotikus hardverekhez vezető portokban a… Az alvás és az alapjárat szó szerint a tesztrendszer és a használható mindennapi vezetés közötti különbséget jelenti..
Szenvedélyes író a bájtok és általában a technológia világáról. Szeretem megosztani tudásomat írásban, és ezt fogom tenni ebben a blogban, megmutatom a legérdekesebb dolgokat a kütyükről, szoftverekről, hardverekről, technológiai trendekről stb. Célom, hogy egyszerű és szórakoztató módon segítsek eligazodni a digitális világban.