Cum ajută EAS să facă din Google Pixel cel mai rapid telefon Android

În trecut, când Linux era doar o idee în mintea lui Linus Torvalds, procesoarele erau entități cu un singur nucleu care necesitau o cantitate imensă de energie pentru puțină putere. Primul procesor disponibil comercial, Intel 4004, a funcționat la o frecvență de ceas de 740 kHz pe un singur nucleu. Pe atunci, nu era nevoie de un programator de încărcare. Programarea încărcării a fost rezervată pentru „mașinii” dual-core, cum ar fi IBM Power 4, care a apărut la câteva decenii după. Acestea au funcționat la o frecvență de 1,1 GHz până la 1,9 GHz și au necesitat programe și sistem pentru a utiliza corect aceste nuclee. Cum am ajuns de la aceste mașini la algoritmi software care folosesc mai multe nuclee? Poate ați mai auzit de Energy Aware Scheduling (EAS) pe forumurile noastre. Este o parte din motivul pentru care smartphone-urile Google Pixel funcționează atât de bine. Ce este atât de grozav la EAS și cum am ajuns chiar și în acest punct? Înainte de a putea explica asta, trebuie să vorbim despre programatorii de încărcare Linux.

---

Evoluția programatorilor de încărcare Linux

Programare Round-Robin

Procesarea „round robin” este un concept simplu de explicat și înțeles și unul și mai simplu de înțeles dezavantajele acestuia. Round-robin folosește time slicing pentru a aloca timp fiecărui proces. Să presupunem că avem patru procese care rulează pe computerul nostru.

• Procesul A
• Procesul B
• Procesul C
• Procesul D

Acum, să facem treaba planificatorului round-robin. Vom aloca 100 de milisecunde (time-slicing) fiecărui proces înainte de a trece la următorul. Aceasta înseamnă că Procesul A poate dura 100 de milisecunde pentru a-și procesa, apoi trece la Procesul B și așa mai departe. Dacă munca unei aplicații durează 250 de milisecunde, va trebui să treacă prin acest proces de 3 ori doar pentru a-și termina munca! Acum scalați acest lucru pe diferite nuclee, astfel încât Procesul A și Procesul B să fie alocate nucleului 1, iar Procesul C și Procesul D să fie alocate nucleului 2. Aceasta a fost înlocuită cu programarea O(n) (care era ca round-robin, dar folosind epoci și permițând alocarea dinamică a timp), apoi programarea O(1) (supraveghere minimă, suport nelimitat pentru proces), apoi în cele din urmă Planificatorul complet corect (CFS). CFS a fost fuzionat cu versiunea de kernel Linux 2.6.23 în octombrie 2007. A fost revizuit de atunci și este încă programul implicit în sistemele Linux.

Scheduler complet corect

Completly Fair Scheduler a existat în Android încă de la început și este folosit pe non-big. MICI dispozitive. Utilizează un algoritm inteligent pentru a determina ordinea de procesare, timpul alocat etc. Este un exemplu de implementare funcțională a algoritmului de programare bine studiat numit „cozi de așteptare corecte ponderate”. Acest lucru se concentrează practic pe acordarea de prioritate proceselor de sistem și altor procese cu prioritate ridicată care rulează pe mașinărie. Dacă ar fi să ruleze pe un mare. MIC dispozitiv, toate nucleele ar fi percepute ca fiind egale. Acest lucru este rău, deoarece nucleele de putere redusă pot fi forțate să ruleze aplicații intensive sau chiar mai rău, se poate întâmpla contrariul. Decodarea pentru ascultarea muzicii se poate face pe nucleul mare, de exemplu, crescând inutil consumul de energie. Acesta este motivul pentru care avem nevoie de un nou planificator pentru mari. LITTLE, unul care poate recunoaște și utiliza de fapt diferența dintre nuclee într-un mod eficient din punct de vedere energetic. Aici intervine Heterogeneous Multi-Processing (HMP), programatorul standard de încărcare pe care majoritatea telefoanelor Android rulează acum.

Multi-procesare eterogenă

Acesta este programatorul de încărcare standard pentru orice mare. LITTLE dispozitiv lansat în ultimii ani, altul decât Google Pixel. HMP folosește marele. MUCĂ arhitectură, delegând o prioritate scăzută, o muncă mai puțin intensivă nucleelor ​​mici care consumă mai puțină energie. HMP este „sigur” în care știe ce ar trebui să meargă la miezurile mari și ce ar trebui să meargă la miezurile mici, fără a face greșeli. Pur și simplu funcționează și necesită mult mai puțin efort pentru a se configura pe partea de dezvoltare decât ceva de genul EAS, despre care vom intra într-un moment. HMP este doar o extensie a CFS pentru a-l face conștient de putere.

HMP nu acceptă presupuneri și nici nu prezice procese viitoare. Acest lucru este bun, dar este motivul pentru care dispozitivul nu poate fi la fel de fluid ca cei care rulează EAS și, de asemenea, consumă puțin mai multă baterie. Acest lucru, în cele din urmă, ne aduce la Energy Aware Scheduling (EAS), care cred cu fermitate este viitorul în dezvoltarea ROM și a kernel-ului, pe măsură ce mai mulți OEM îl adoptă.

Programare conștientă de energie

Energy Aware Scheduling (EAS) este următorul lucru important despre care vorbesc utilizatorii de pe forumurile noastre. Dacă folosești un OnePlus 3 (sau un Google Pixel, evident) cu siguranță ai auzit despre el pe forumuri. S-a lansat în mainstream cu Qualcomm Snapdragon 845, așa că dacă aveți unul dintre aceste dispozitive, aveți deja un smartphone compatibil EAS. EAS sub formă de nuclee precum RenderZenith și ROM-uri precum VertexOS și PureFusion au luat cu asalt forumurile OnePlus 3 la început. Desigur, Google Pixel vine și cu EAS. Cu promisiunile de viață îmbunătățită a bateriei și performanță mai bună, care este problema?

Programarea Energy Aware nu este atât de simplă, deoarece nu este universală pentru fiecare dispozitiv precum CFS sau HMP. EAS necesită o înțelegere a procesorului pe care rulează, pe baza unui model energetic. Aceste modele energetice sunt realizate de echipe de ingineri care testează și lucrează constant pentru a oferi o performanță optimă. Deoarece Snapdragon 820 și 821 sunt practic aceleași, nucleele personalizate de pe OnePlus 3 utilizează modelul energetic Google Pixel. Dispozitivele cu Snapdragon 845 pot utiliza EAS, iar OnePlus 6 o face într-o oarecare măsură. Nu este la fel de reglat precum ar fi un dispozitiv Google Pixel, dar își face treaba. Iată un exemplu despre cum, în ciuda faptului că OnePlus 6 are un procesor mai bun cu EAS, Pixel 2 XL încă îl bate în netezime. Ambele imagini au fost preluate de la noi revizuire orientată spre viteză a OnePlus 6.

Dacă întâmpinați dificultăți în înțelegerea graficelor, puteți arunca o privire la imaginea de mai jos pentru îndrumare. Orice depășește linia verde indică cadre căzute și, în cele mai rele cazuri, bâlbâială vizibilă.

Implementarea OnePlus 6 a EAS este interesantă, deoarece nu pare a fi o implementare completă, așa cum ați găsi pe un Google Pixel cu același SoC. Nici reglajele programatorului nu au prea mult sens, așa că probabil că asta explică de ce nu este atât de eficient pe cât te-ai aștepta. Este extrem de conservator în ceea ce privește consumul de energie, sistemul acordând prioritate nucleelor ​​de putere redusă pentru majoritatea lucrărilor.

Reglajele sunt pur și simplu un set de parametri care sunt transmise guvernatorului CPU, care schimbă modul în care regulatorul reacționează la anumite situații în ceea ce privește frecvența. Planificatorul decide apoi unde plasează sarcinile pe diferite procesoare. Reglabilele OnePlus 6 sunt setate să prioritizeze munca pe nuclee cu putere redusă. De asemenea, nu ajută că Google Pixel 2 are o cantitate uriașă de creștere a intrării, păstrând toate cele 8 nuclee online tot timpul. Google folosește și un echilibrator de întreruperi care ajută la eliminarea căderilor de cadru și la îmbunătățirea performanței.

Deci, cum funcționează EAS? De ce este atât de eficient doar în anumite condiții?

Energy Aware Scheduling introduce necesitatea de a utiliza un model energetic și, așa cum am menționat mai sus, necesită multă testare și muncă pentru a-l face perfect. EAS încearcă să unifice trei părți de bază diferite ale nucleului, care acționează toate independent, iar modelul energetic ajută la unificarea acestora.

• Programator Linux (CFS, menționat mai sus)
• CPU Linux
• Linux cpufreq

Unificarea tuturor celor 3 părți sub planificator și calcularea lor împreună oferă un potențial de economisire a energiei, deoarece calcularea lor împreună le permite să fie cât mai eficiente posibil. CPUIdle încearcă să decidă când procesorul ar trebui să intre în modul inactiv, în timp ce CPUFreq încearcă să decidă când să crească sau să coboare CPU. Ambele module au scopul principal de a economisi energie. Nu numai că, apoi clasifică procesele în patru grupuri c, fiind top-app, system-background, prim-plan și fundal. Sarcinile care urmează să fie procesate sunt plasate într-una dintre aceste categorii, apoi categoriei primesc putere CPU și munca este delegată pe diferite nuclee CPU. top-app este cea mai mare prioritate de finalizare, urmată de prim-plan, fundal și apoi de fundal de sistem. Din punct de vedere tehnic, fundalul are aceeași prioritate ca fundalul sistemului, dar fundalul sistemului are de obicei acces la mai multe nuclee mici. De fapt, Energy Aware Scheduling preia părțile de bază ale nucleului Linux și le unifică pe toate într-un singur proces.

La trezirea dispozitivului, EAS va alege miezul în starea inactivă cea mai mică, reducând la minimum energia necesară pentru a trezi dispozitivul. Acest lucru ajută la reducerea puterii necesare în utilizarea dispozitivului, deoarece nu va trezi clusterul mare dacă nu este necesar. Urmărirea încărcăturii este, de asemenea, o parte extrem de crucială a EAS și există două opțiuni. „Urmărirea sarcinii per entitate” (PELT) este de obicei folosită pentru urmărirea încărcăturii, iar informațiile sunt apoi folosite pentru a decide frecvențele și modul de delegare a sarcinilor pe CPU. „Window-Assisted Load Tracking” (WALT) poate fi, de asemenea, utilizat și este ceea ce este folosit pe Google Pixel. Multe ROM-uri EAS de pe forumurile noastre, cum ar fi VertexOS, optează pentru utilizarea WALT. Multe ROM-uri vor lansa două versiuni ale nucleului cu WALT sau PELT, așa că este la latitudinea utilizatorului să decidă. WALT este mai puternic, cu vârfuri ridicate ale frecvenței CPU, în timp ce PELT încearcă să rămână mai consistent. Tracker-ul de încărcare nu afectează de fapt frecvența procesorului, ci doar spune sistemului la ce se utilizează procesorul. O utilizare mai mare a procesorului necesită o frecvență mai mare și, prin urmare, o trăsătură consecventă a PELT este că face ca frecvența procesorului să crească sau să scadă încet. PELT tinde să se îndrepte către raportarea încărcării mai mari a procesorului, deci poate oferi performanțe mai mari la un cost mai mare al bateriei. Nimeni nu poate spune cu adevărat în acest moment care sistem de urmărire a încărcăturii este mai bun, totuși, deoarece ambele metode de urmărire a încărcăturii sunt corectate și perfecționate în mod continuu.

Oricum ar fi, este evident că, indiferent de metoda de urmărire a încărcăturii folosită, există o creștere a eficienței. Mai degrabă decât doar procesarea sarcinilor pe orice procesor, sarcina este analizată și cantitatea de energie necesară pentru a o rula este estimată. Această plasare inteligentă a sarcinilor înseamnă că sarcinile sunt finalizate într-o manieră mult mai eficientă, în timp ce sistemul este mai rapid în ansamblu. EAS se referă la obținerea celei mai fluide interfețe de utilizare posibilă cu un consum minim de energie. Aici intră în joc alte componente externe, cum ar fi schedtune.

Schedtune este definit în fiecare cgroup de două reglabile care asigură un control mai fin asupra sarcinilor care trebuie îndeplinite. Nu controlează doar răspândirea sarcinilor pe mai multe procesoare, ci și dacă sarcina percepută ar trebui să fie umflată pentru a se asigura că sarcinile sensibile la timp sunt finalizate mai rapid. În acest fel, aplicațiile și serviciile din prim-plan de care folosește utilizatorul nu vor încetini și nu vor cauza probleme inutile de performanță.

În timp ce programarea conștientă de energie este următorul lucru important, se poate, de asemenea, argumenta că este deja aici și a fost de ceva vreme. Cu din ce în ce mai multe dispozitive care ajung la curentul principal cu Energy Aware Scheduling, o nouă eră a eficienței procesării mobile este aici.

Avantajele și dezavantajele Round-Robin, CFS, HMP și EAS

În timp ce abilitățile mele de grafică sunt sub egale, am adunat o imagine care ar trebui să rezume care sunt avantajele și dezavantajele fiecăruia dintre aceste programatoare.

---

Aș dori să mulțumesc în mod special colaboratorului XDA recunoscut Mostafa Wael ale căror explicații asupra diferitelor aspecte ale EAS au ajutat foarte mult la realizarea acestui articol. De asemenea, aș dori să mulțumesc XDA Recognized Developer joshuous, Dezvoltator recunoscut XDA RenderBroken și Mostafa Wael pentru scrisul său pe EAS. Pentru aceia dintre voi care au găsit interes pentru părțile legate de EAS, Linaro are o mulțime de documentație despre EAS pe care o puteți citi.