Google Pixel-smarttelefonene er blant de raskeste Android-telefonene på markedet. Energy Aware Scheduling (EAS) er delvis grunnen til at telefonen er så jevn.
Langt tilbake i fortiden, da Linux bare var en idé i Linus Torvalds sinn, var CPU-er enkeltkjerne-enheter som krevde en enorm mengde energi for lite strøm. Den første kommersielt tilgjengelige prosessoren noensinne, Intel 4004, kjørte med en klokkefrekvens på 740 kHz på en enkelt kjerne. Den gang var det ikke behov for en lastplanlegger. Lasteplanlegging var reservert for dual-core "behemoths" som IBM Power 4 som kom ut noen tiår etter. Disse kjørte på en dyrisk 1,1 GHz til 1,9 GHz og krevde programmer og systemet for å bruke disse kjernene riktig. Hvordan kom vi fra disse maskinene til programvarealgoritmer som bruker flere kjerner? Du har kanskje hørt om Energy Aware Scheduling (EAS) på forumene våre før. Det er en del av grunnen til at Google Pixel-smarttelefonene yter så bra. Hva er så bra med EAS, og hvordan kom vi til dette punktet? Før vi kan forklare det, må vi snakke om Linux-belastningsplanleggere.
Utviklingen av Linux-belastningsplanleggerne
Round-Robin-planlegging
Round robin-behandling er et enkelt konsept å forklare og forstå, og et enda enklere konsept for å forstå dets ulemper. Round-robin bruker time slicing for å tildele tid til hver prosess. La oss anta at vi har fire prosesser som kjører på datamaskinen vår.
- Prosess A
- Prosess B
- Prosess C
- Prosess D
La oss nå gjøre jobben med round-robin-planleggeren. Vi vil allokere 100 millisekunder (time-slicing) til hver prosess før vi går videre til neste. Dette betyr at prosess A kan ta 100 millisekunder å utføre sin prosessering, deretter går den til prosess B og så videre. Hvis en applikasjons jobb tar 250 millisekunder å gjøre, må den gå gjennom denne prosessen 3 ganger bare for å fullføre arbeidet! Skaler nå dette på tvers av forskjellige kjerner, slik at prosess A og prosess B er allokert til kjerne 1, og prosess C og prosess D er allokert til kjerne 2. Dette ble erstattet av O(n)-planlegging (som var som round-robin, men ved å bruke epoker og tillate dynamisk tildeling av tid), deretter O(1)-planlegging (minimert overhead, ubegrenset prosessstøtte), så til slutt Completely Fair Scheduler (CFS). CFS ble slått sammen til Linux-kjerneversjon 2.6.23 i oktober 2007. Den har blitt overhalt siden og er fortsatt standardplanleggeren i Linux-systemer.
Helt rettferdig planlegger
The Completely Fair Scheduler har eksistert i Android siden starten og brukes på ikke-store. SMÅ enheter. Den bruker en intelligent algoritme for å bestemme behandlingsrekkefølge, allokert tid osv. Det er et eksempel på en fungerende implementering av den godt studerte planleggingsalgoritmen kalt "vektet rettferdig kø". Dette fokuserer i utgangspunktet på å gi prioritet til systemprosesser og andre høyprioriterte prosesser som kjører på maskin. Hvis det skulle kjøre på en stor. LITEN enhet, alle kjerner ville bli oppfattet som like. Dette er dårlig, siden laveffektkjerner kan bli tvunget til å kjøre intensive applikasjoner, eller enda verre, det motsatte kan oppstå. Dekodingen for å lytte til musikk kan gjøres på den store kjernen, for eksempel øke strømforbruket unødvendig. Dette er grunnen til at vi trenger en ny planlegger for store. LITTLE, en som faktisk kan gjenkjenne og utnytte forskjellen i kjerner på en strømeffektiv måte. Det er her Heterogeneous Multi-Processing (HMP) kommer inn, standard lastplanleggeren de fleste Android-telefoner kjører nå.
Heterogen Multi-Processing
Dette er standard lasteplanlegger for alle store. LITE enhet utgitt de siste årene, bortsett fra Google Pixel. HMP benytter seg av det store. LITE arkitektur, delegerer lav prioritet, mindre intensivt arbeid til de små kjernene som bruker mindre strøm. HMP er "trygt" der den vet hva som skal gå til de store kjernene og hva som skal gå til de små kjernene, uten å gjøre feil. Det fungerer bare og krever mye mindre innsats å sette opp på utviklingssiden enn noe som EAS, som vi kommer inn på om et øyeblikk. HMP er bare en utvidelse av CFS for å gjøre den kraftbevisst.
HMP tar ikke gjetninger, og forutsier heller ikke fremtidige prosesser. Dette er bra, men det er grunnen til at enheten ikke kan være like flytende som de som kjører EAS, og det er også grunnen til at den bruker litt mer batteri. Dette bringer oss til slutt til Energy Aware Scheduling (EAS), som jeg er overbevist om er fremtiden innen ROM- og kjerneutvikling ettersom flere OEM-er tar det i bruk.
Energibevisst planlegging
Energy Aware Scheduling (EAS) er den neste store tingen brukerne på forumene våre snakker om. Hvis du bruker en OnePlus 3 (eller en Google Pixel, åpenbart) har du definitivt hørt om det i forumene. Den ble lansert i mainstream med Qualcomm Snapdragon 845, så hvis du har en av disse enhetene har du allerede en EAS-aktivert smarttelefon. EAS i form av kjerner som f.eks Render Zenith og ROM-er som f.eks VertexOS og PureFusion tok OnePlus 3-foraene med storm i sin beste alder. Google Pixel kommer selvfølgelig også med EAS. Med løftene om forbedret batterilevetid og bedre ytelse, hva er fangsten?
Energy Aware Scheduling er ikke så enkelt som det ikke er universelt for alle enheter som CFS eller HMP. EAS krever en forståelse av prosessoren den kjører på, basert på en energimodell. Disse energimodellene er laget av team av ingeniører som kontinuerlig tester og jobber for å gi optimal ytelse. Siden Snapdragon 820 og 821 i utgangspunktet er de samme, bruker tilpassede kjerner på OnePlus 3 Google Pixel-energimodellen. Enheter med Snapdragon 845 kan bruke EAS, og OnePlus 6 gjør det til en viss grad. Den er ikke så innstilt som en Google Pixel-enhet ville vært, men den får jobben gjort. Her er et eksempel på hvordan, til tross for at OnePlus 6 har en bedre prosessor med EAS, slår Pixel 2 XL den jevnt. Begge disse bildene er tatt fra vår hastighetsorientert gjennomgang av OnePlus 6.
Hvis du har problemer med å forstå grafene, kan du ta en titt på bildet nedenfor for veiledning. Alt som overskrider den grønne linjen indikerer tapte rammer og i verste fall merkbar stamming.
OnePlus 6-implementeringen av EAS er interessant, siden det ikke ser ut til å være en fullverdig implementering som du finner på en Google Pixel med samme SoC. Planleggerens tunables gir heller ikke mye mening, så det forklarer sannsynligvis hvorfor det ikke er så ytelseseffektivt som du forventer. Det er ekstremt konservativt når det gjelder strømforbruk, med systemet som prioriterer de lave strømkjernene for mesteparten av arbeidet.
Tunables er ganske enkelt et sett med parametere som sendes til CPU-regulatoren, som endrer hvordan guvernøren reagerer på visse situasjoner når det gjelder frekvens. Planleggeren bestemmer deretter hvor den plasserer oppgaver på forskjellige prosessorer. OnePlus 6s tunables er satt til å prioritere arbeid med lavkraftige kjerner. Det hjelper heller ikke at Google Pixel 2 har en enorm mengde input-boost, og holder alle 8 kjerner online hele tiden. Google bruker også en avbryte balanserer som bidrar til å fjerne rammefall og forbedre ytelsen.
Så hvordan fungerer EAS? Hvorfor er det så effektivt bare under visse forhold?
Energy Aware Scheduling introduserer behovet for å bruke en energimodell, og krever som nevnt over mye testing og arbeid for å gjøre den perfekt. EAS forsøker å forene tre forskjellige kjernedeler av kjernen som alle fungerer uavhengig, og energimodellen hjelper til med å forene dem.
- Linux-planlegger (CFS, nevnt ovenfor)
- Linux cpuidle
- Linux cpufreq
Å forene alle 3 delene under planleggeren og beregne dem sammen gir et potensial for energisparing, ettersom å beregne dem sammen gjør at de blir så effektive som mulig. CPUIdle prøver å bestemme når CPUen skal gå inn i inaktiv modus, mens CPUFreq prøver å bestemme når CPUen skal trappes opp eller ned. Begge disse modulene har som hovedmål å spare energi. Ikke bare det, den kategoriserer deretter prosesser i fire cgroups, som er toppapp, systembakgrunn, forgrunn og bakgrunn. Oppgaver som skal behandles plasseres i en av disse kategoriene, og deretter får kategorien CPU-kraft og arbeidet delegeres over ulike CPU-kjerner. topp-appen er den høyeste prioritet for fullføring, etterfulgt av forgrunn, bakgrunn og deretter systembakgrunn. Bakgrunn har teknisk sett samme prioritet som system-bakgrunn, men system-bakgrunn har vanligvis også tilgang til flere små kjerner. Faktisk tar Energy Aware Scheduling kjernedeler av Linux-kjernen og samler det hele i én prosess.
Når du vekker enheten, vil EAS velge kjernen i den grunneste tomgangstilstanden, og minimere energien som trengs for å vekke enheten. Dette bidrar til å redusere den nødvendige kraften ved bruk av enheten, siden den ikke vil vekke den store klyngen hvis den ikke trenger det. Lastsporing er også en ekstremt viktig del av EAS, og det er to alternativer. "Per-Entity Load Tracking" (PELT) brukes vanligvis for lastsporing, informasjonen brukes deretter til å bestemme frekvenser og hvordan man skal delegere oppgaver over CPU. "Window-Assisted Load Tracking" (WALT) kan også brukes og er det som brukes på Google Pixel. Mange EAS ROM-er på forumene våre, for eksempel VertexOS, velger å bruke WALT. Mange ROM-er vil gi ut to versjoner av kjernen med WALT eller PELT, så det er opp til brukeren å bestemme. WALT er mer sprengt, med høye topper i CPU-frekvens mens PELT prøver å forbli mer konsistent. Lastsporeren påvirker faktisk ikke CPU-frekvensen, den forteller bare systemet hva CPU-bruken er på. En høyere CPU-bruk krever en høyere frekvens, og derfor er et konsistent trekk ved PELT at det får CPU-frekvensen til å rampe opp eller ned sakte. PELT har en tendens til å avvike mot rapportering om høyere CPU-belastning, så det kan gi høyere ytelse til en høyere batterikostnad. Ingen kan egentlig si på dette tidspunktet hvilket lastsporingssystem som er bedre, ettersom begge lastsporingsmetodene blir kontinuerlig lappet og raffinert.
Uansett er det åpenbart at det er en økning i effektiviteten, uansett hvilken lastsporingsmetode som brukes. I stedet for bare å behandle oppgaver på en hvilken som helst prosessor, analyseres oppgaven og mengden energi som kreves for å kjøre den, estimeres. Denne smarte oppgaveplasseringen betyr at oppgavene blir utført på en mye mer effektiv måte, samtidig som det gjør systemet raskere som helhet. EAS handler om å få et jevnest mulig brukergrensesnitt med minimalt strømforbruk. Det er her andre eksterne komponenter som schedtune kommer inn i bildet.
Schedtune er definert i hver cgroup av to tunables som sikrer finere kontroll over oppgavene som skal fullføres. Den kontrollerer ikke bare spredningen av oppgaver over flere CPUer, men også om den oppfattede belastningen skal blåses opp for å sikre at tidssensitive oppgaver fullføres raskere. På denne måten vil ikke forgrunnsapplikasjoner og -tjenester som brukeren benytter seg av, redusere hastigheten og forårsake unødvendige ytelsesproblemer.
Mens Energy Aware Scheduling er den neste store tingen, kan det også hevdes at den allerede er her og har vært det en stund. Med flere og flere enheter som treffer mainstream med Energy Aware Scheduling, er en ny tid med mobil prosesseringseffektivitet her.
Fordeler og ulemper med Round-Robin, CFS, HMP og EAS
Selv om grafikkferdighetene mine er under pari, har jeg satt sammen et bilde som skal oppsummere fordelene og ulempene med hver av disse planleggerne.
Jeg vil rette en spesiell takk til XDA Recognized Contributor Mostafa Wael hvis forklaringer av ulike aspekter ved EAS i stor grad hjalp til med å gjøre denne artikkelen mulig. Jeg vil også takke XDA Recognized Developer joshuous, XDA anerkjent utvikler RenderBroken og Mostafa Wael for hans skriving om EAS. For de av dere som fant interesse for EAS-relaterte deler, har Linaro mye dokumentasjon på EAS som dere kan lese.