Google Pixel-smartphones er blandt de hurtigste Android-telefoner på markedet. Energy Aware Scheduling (EAS) er til dels grunden til, at telefonen er så glat.
Langt tilbage i fortiden, da Linux kun var en idé i Linus Torvalds sind, var CPU'er enkeltkerne-enheder, som krævede en enorm mængde energi for lidt strøm. Den første kommercielt tilgængelige processor nogensinde, Intel 4004, kørte med en clock-rate på 740 kHz på en enkelt kerne. Dengang var der ikke behov for en belastningsplanlægger. Belastningsplanlægning var forbeholdt dual-core "behemoths" såsom IBM Power 4, der udkom nogle årtier efter. Disse kørte med en uhyggelig 1,1 GHz til 1,9 GHz og krævede programmer og systemet for at bruge disse kerner korrekt. Hvordan kom vi fra disse maskiner til softwarealgoritmer, der gør brug af flere kerner? Du har måske hørt om Energy Aware Scheduling (EAS) på vores fora før. Det er en del af grunden til, at Google Pixel-smartphones klarer sig så godt. Hvad er så fantastisk ved EAS, og hvordan nåede vi overhovedet til dette punkt? Før vi kan forklare det, skal vi tale om Linux-belastningsplanlæggere.
Udviklingen af Linux Load Schedulers
Round-Robin planlægning
Round robin-behandling er et simpelt koncept at forklare og forstå, og et endnu enklere koncept til at forstå dets ulemper. Round-robin bruger time slicing til at allokere tid til hver proces. Lad os antage, at vi har fire processer kørende på vores computer.
- Proces A
- Proces B
- Proces C
- Proces D
Lad os nu gøre arbejdet med round-robin-planlæggeren. Vi vil allokere 100 millisekunder (time-slicing) til hver proces, før vi går videre til den næste. Det betyder, at proces A kan tage 100 millisekunder at udføre sin behandling, derefter flyttes den til proces B og så videre. Hvis en applikations job tager 250 millisekunder at udføre, skal den gennemgå denne proces 3 gange bare for at afslutte sit arbejde! Skaler nu dette på tværs af forskellige kerner, så proces A og proces B er allokeret til kerne 1, og proces C og proces D er allokeret til kerne 2. Dette blev erstattet af O(n)-planlægning (som var som round-robin, men ved at bruge epoker og tillade dynamisk allokering af tid), derefter O(1) planlægning (minimeret overhead, ubegrænset processupport), så til sidst den fuldstændig fair planlægning (CFS). CFS blev flettet ind i Linux-kerneversion 2.6.23 i oktober 2007. Det er blevet eftersyn siden og er stadig standardplanlæggeren i Linux-systemer.
Fuldstændig fair skemalægger
The Completely Fair Scheduler har eksisteret i Android siden starten og bruges på ikke-big. SMÅ enheder. Den bruger en intelligent algoritme til at bestemme behandlingsrækkefølge, allokeret tid osv. Det er et eksempel på en fungerende implementering af den velundersøgte planlægningsalgoritme kaldet "vægtet retfærdig kø". Dette fokuserer grundlæggende på at give prioritet til systemprocesser og andre højprioriterede processer, der kører på maskine. Hvis den skulle køre på en stor. LILLE enhed, alle kerner ville blive opfattet som lige. Dette er dårligt, da laveffektkerner kan blive tvunget til at køre intensive applikationer, eller endnu værre, det modsatte kan forekomme. Afkodningen for at lytte til musik kan udføres på den store kerne, for eksempel øger strømforbruget unødigt. Det er derfor, vi har brug for en ny skemalægger for store. LITTLE, en som faktisk kan genkende og udnytte forskellen i kerner på en strømeffektiv måde. Det er her, Heterogeneous Multi-Processing (HMP) kommer ind, den standardindlæsningsplanlægning, som de fleste Android-telefoner kører nu.
Heterogen Multi-Processing
Dette er standard belastningsplanlæggeren for enhver stor. LILLE enhed udgivet i de seneste år, bortset fra Google Pixel. HMP gør brug af det store. LITE arkitektur, uddelegering af lav prioritet, mindre intensivt arbejde til de små kerner, som forbruger mindre strøm. HMP er "sikker", hvor den ved, hvad der skal gå til de store kerner, og hvad der skal gå til de små kerner, uden at begå fejl. Det virker bare og kræver meget mindre indsats at sætte op på udviklingssiden end noget som EAS, som vi kommer ind på om et øjeblik. HMP er blot en udvidelse af CFS for at gøre den strømbevidst.
HMP tager ikke gæt, og forudsiger heller ikke fremtidige processer. Dette er godt, men det er grunden til, at enheden ikke kan være så flydende som dem, der kører EAS, og det er også grunden til, at den bruger lidt mere batteri. Dette bringer os endelig til Energy Aware Scheduling (EAS), som jeg er overbevist om er fremtiden inden for ROM- og kerneudvikling, efterhånden som flere OEM'er tager det i brug.
Energibevidst planlægning
Energy Aware Scheduling (EAS) er den næste store ting, som brugere på vores fora taler om. Hvis du bruger en OnePlus 3 (eller en Google Pixel, naturligvis) har du helt sikkert hørt om det i foraene. Den blev lanceret i mainstream med Qualcomm Snapdragon 845, så hvis du har en af disse enheder, har du allerede en EAS-aktiveret smartphone. EAS i form af kerner som f.eks RenderZenith og ROM'er som f.eks VertexOS og PureFusion tog OnePlus 3-foraene med storm i sin bedste alder. Google Pixel kommer naturligvis også med EAS. Med løfterne om forbedret batterilevetid og bedre ydeevne, hvad er fangsten?
Energy Aware Scheduling er ikke så simpel, da den ikke er universel for enhver enhed som CFS eller HMP. EAS kræver en forståelse af den processor, den kører på, baseret på en energimodel. Disse energimodeller er lavet af teams af ingeniører, der konstant tester og arbejder for at give en optimal ydeevne. Da Snapdragon 820 og 821 grundlæggende er de samme, bruger brugerdefinerede kerner på OnePlus 3 Google Pixel-energimodellen. Enheder med Snapdragon 845 kan bruge EAS, og det gør OnePlus 6 til en vis grad. Den er ikke så finjusteret, som en Google Pixel-enhed ville være, men den får jobbet gjort. Her er et eksempel på, hvordan, på trods af at OnePlus 6 har en bedre processor med EAS, slår Pixel 2 XL den stadig i glathed. Begge disse billeder er taget fra vores hastighedsorienteret gennemgang af OnePlus 6.
Hvis du har problemer med at forstå graferne, kan du tage et kig på billedet nedenfor for at få vejledning. Alt, der overstiger den grønne linje, indikerer tabte rammer og i værste tilfælde mærkbar hakken.
OnePlus 6-implementeringen af EAS er interessant, da det ikke ser ud til at være en fuldgyldig implementering, som du ville finde på en Google Pixel med samme SoC. Schedulæggerens tunables giver heller ikke meget mening, så det forklarer nok, hvorfor det ikke er så ydelseseffektivt, som du ville forvente. Det er ekstremt konservativt med hensyn til strømforbrug, hvor systemet prioriterer de lave strømkerner for størstedelen af arbejdet.
Tunables er simpelthen et sæt parametre, der sendes til CPU-regulatoren, hvilket ændrer, hvordan regulatoren reagerer på bestemte situationer med hensyn til frekvens. Planlæggeren bestemmer derefter, hvor den placerer opgaver på forskellige processorer. OnePlus 6's tunables er indstillet til at prioritere arbejde med lavenergikerner. Det hjælper heller ikke, at Google Pixel 2 har en enorm mængde input-boost, der holder alle 8 kerner online hele tiden. Google bruger også en afbryde balanceren som hjælper med at fjerne rammefald og forbedre ydeevnen.
Så hvordan fungerer EAS? Hvorfor er det kun så effektivt under visse forhold?
Energy Aware Scheduling introducerer behovet for at bruge en energimodel, og som nævnt ovenfor kræver det en masse test og arbejde for at gøre den perfekt. EAS forsøger at forene tre forskellige kernedele af kernen, som alle fungerer uafhængigt, og energimodellen hjælper med at forene dem.
- Linux-planlægger (CFS, nævnt ovenfor)
- Linux cpuidle
- Linux cpufreq
At samle alle 3 dele under skemalæggeren og beregne dem sammen giver et potentiale for energibesparelse, da det ved at beregne dem sammen gør dem så effektive som muligt. CPUIdle forsøger at bestemme, hvornår CPU'en skal gå i inaktiv tilstand, mens CPUFreq forsøger at bestemme, hvornår CPU'en skal rampes op eller ned. Begge disse moduler har det primære mål at spare energi. Ikke nok med det, så kategoriserer den processer i fire cgroups, som er top-app, system-baggrund, forgrund og baggrund. Opgaver, der skal behandles, placeres i en af disse kategorier, og derefter får kategorien CPU-kraft, og arbejdet delegeres over forskellige CPU-kerner. top-app er den højeste prioritet for færdiggørelse, efterfulgt af forgrund, baggrund og derefter system-baggrund. Baggrund har teknisk set samme prioritet som system-baggrund, men system-baggrund har som regel også adgang til flere små kerner. I realiteten tager Energy Aware Scheduling kernedele af Linux-kernen og samler det hele i én proces.
Når du vækker enheden, vil EAS vælge kernen i den laveste inaktive tilstand, hvilket minimerer den nødvendige energi til at vække enheden. Dette hjælper med at reducere den nødvendige strøm ved brug af enheden, da den ikke vil vække den store klynge, hvis det ikke er nødvendigt. Lastsporing er også en ekstremt afgørende del af EAS, og der er to muligheder. "Per-Entity Load Tracking" (PELT) bruges normalt til belastningssporing, informationen bruges derefter til at bestemme frekvenser og hvordan man uddelegerer opgaver på tværs af CPU'en. "Window-Assisted Load Tracking" (WALT) kan også bruges og er det, der bruges på Google Pixel. Mange EAS ROM'er på vores fora, såsom VertexOS, vælger at bruge WALT. Mange ROM'er vil frigive to versioner af kernen med WALT eller PELT, så det er op til brugeren at bestemme. WALT er mere sprængfyldt med høje peaks i CPU-frekvens, mens PELT forsøger at forblive mere konsistent. Belastningssporingen påvirker faktisk ikke CPU-frekvensen, den fortæller blot systemet, hvad CPU-forbruget er på. Et højere CPU-forbrug kræver en højere frekvens, og derfor er et konsekvent træk ved PELT, at det får CPU-frekvensen til at rampe langsomt op eller ned. PELT har en tendens til at afvige mod rapportering om højere CPU-belastning, så det kan give højere ydeevne til en højere batteriomkostning. Ingen kan dog rigtig sige på nuværende tidspunkt, hvilket lastsporingssystem der er bedre, da begge lastsporingsmetoder løbende bliver rettet og forfinet.
Uanset hvad, er det indlysende, at der er en stigning i effektiviteten, uanset hvilken lastsporingsmetode, der anvendes. I stedet for blot at behandle opgaver på en hvilken som helst processor, analyseres opgaven, og mængden af energi, der kræves for at køre den, estimeres. Denne smarte opgaveplacering betyder, at opgaverne bliver udført på en meget mere effektiv måde, samtidig med at systemet som helhed bliver hurtigere. EAS handler om at få den glatteste brugergrænseflade med minimalt strømforbrug. Det er her, andre eksterne komponenter såsom schedtune kommer i spil.
Schedtune er defineret i hver cgroup af to tunables, som sikrer finere kontrol over de opgaver, der skal udføres. Det styrer ikke kun spredningen af opgaver over flere CPU'er, men også hvis den opfattede belastning skal pustes op for at sikre, at tidsfølsomme opgaver udføres hurtigere. På denne måde vil forgrundsapplikationer og -tjenester, som brugeren benytter sig af, ikke bremse og forårsage unødvendige ydeevneproblemer.
Mens Energy Aware Scheduling er den næste store ting, kan det også hævdes, at den allerede er her og har været det i et stykke tid. Med flere og flere enheder, der rammer mainstream med Energy Aware Scheduling, er en ny tidsalder med mobil behandlingseffektivitet her.
Fordele og ulemper ved Round-Robin, CFS, HMP og EAS
Mens mine grafiske færdigheder er under pari, har jeg smidt et billede sammen, som skal opsummere, hvad fordelene og ulemperne ved hver af disse planlæggere er.
Jeg vil gerne rette en særlig tak til XDA Recognized Contributor Mostafa Wael hvis forklaringer af forskellige aspekter af EAS i høj grad hjalp med at gøre denne artikel mulig. Jeg vil også gerne takke XDA Recognized Developer joshuous, XDA anerkendt udvikler RenderBroken og Mostafa Wael for hans indlæg om EAS. Til de af jer, der fandt interesse for EAS-relaterede dele, har Linaro en masse dokumentation om EAS, som du kan læse.