Google Pixel -älypuhelimet ovat markkinoiden nopeimpia Android-puhelimia. Energy Aware Scheduling (EAS) johtuu osittain siitä, miksi puhelin on niin sujuva.
Kaukana menneisyydessä, kun Linux oli vain idea Linus Torvaldsin mielessä, prosessorit olivat yhden ytimen kokonaisuuksia, jotka vaativat valtavan määrän energiaa pieneen tehoon. Ensimmäinen kaupallisesti saatavilla oleva prosessori, Intel 4004, toimi 740 kHz: n kellotaajuudella yhdellä ytimellä. Silloin ei ollut tarvetta latausaikataululle. Kuormituksen ajoitus oli varattu kaksiytimisille "behemoteille", kuten IBM Power 4:lle, joka ilmestyi joitakin vuosikymmeniä myöhemmin. Nämä toimivat hirveällä 1,1 GHz - 1,9 GHz taajuudella ja vaativat ohjelmia ja järjestelmää käyttääkseen näitä ytimiä oikein. Kuinka pääsimme näistä koneista ohjelmistoalgoritmeihin, jotka käyttävät useita ytimiä? Olet ehkä kuullut Energy Aware Schedulingista (EAS) foorumeillamme aiemmin. Se on osa syy siihen, miksi Google Pixel -älypuhelimet toimivat niin hyvin. Mikä EAS: ssa on niin hienoa ja miten pääsimme tähän pisteeseen? Ennen kuin voimme selittää sen, meidän on puhuttava Linuxin latausaikatauluista.
Linuxin kuormitusaikataulujen kehitys
Round-Robin-aikataulu
Round robin -käsittely on yksinkertainen käsite selittää ja ymmärtää, ja vielä yksinkertaisempi käsite ymmärtää sen haitat. Round-robin käyttää aika viipalointia varatakseen aikaa kullekin prosessille. Oletetaan, että tietokoneellamme on käynnissä neljä prosessia.
- Prosessi A
- Prosessi B
- Prosessi C
- Prosessi D
Tehdään nyt round robin -aikatauluttajan työ. Varaamme kullekin prosessille 100 millisekuntia (aikaleikkaus) ennen kuin siirrymme seuraavaan. Tämä tarkoittaa, että prosessin A käsittely voi kestää 100 millisekuntia, minkä jälkeen se siirtyy prosessiin B ja niin edelleen. Jos sovelluksen työ kestää 250 millisekuntia, sen on suoritettava tämä prosessi 3 kertaa vain saadakseen työnsä valmiiksi! Skaalaa tämä nyt eri ytimien kesken siten, että prosessi A ja prosessi B allokoidaan ytimelle 1 ja prosessi C ja prosessi D ytimelle 2. Tämä korvattiin O(n)-aikataululla (joka oli kuin round-robin, mutta jossa käytettiin aikakausia ja mahdollisti dynaamisen aika), sitten O(1) ajoitus (minimoitu yleiskustannukset, rajoittamaton prosessituki), sitten lopuksi Täysin reilu ajoitus (CFS). CFS yhdistettiin Linux-ytimen versioon 2.6.23 lokakuussa 2007. Sitä on kunnostettu siitä lähtien, ja se on edelleen oletusaikataulu Linux-järjestelmissä.
Täysin reilu aikataulu
Täysin oikeudenmukainen ajoitus on ollut olemassa Androidissa sen alusta lähtien, ja sitä käytetään ei-suurissa. PIENET laitteet. Se käyttää älykästä algoritmia määrittääkseen käsittelyjärjestyksen, varatun ajan jne. Se on esimerkki hyvin tutkitun aikataulutusalgoritmin toimivasta toteutuksesta, jota kutsutaan "painotetuksi reiluksi jonotukseksi". Tämä pohjimmiltaan keskittyy ensisijaisesti järjestelmäprosessien ja muiden korkean prioriteetin prosessien asettamiseen kone. Jos se ajaisi suurella. PIENI laite, kaikki ytimet pidettäisiin samanarvoisina. Tämä on huono asia, koska pienitehoiset ytimet voivat joutua suorittamaan intensiivisiä sovelluksia, tai vielä pahempaa, päinvastoin voi tapahtua. Dekoodaus musiikin kuuntelua varten voidaan tehdä esimerkiksi isossa ytimessä, mikä lisää virrankulutusta tarpeettomasti. Siksi tarvitsemme uuden aikataulun isolle. LITTLE, joka pystyy todella tunnistamaan ja hyödyntämään ytimien eron tehotehokkaalla tavalla. Tässä tulee esiin Heterogeneous Multi-Processing (HMP), tavallinen latausaikataulu, jota useimmat Android-puhelimet käyttävät nyt.
Heterogeeninen monikäsittely
Tämä on tavallinen latausaikataulu kaikille suurille. LITTLE laite on julkaistu viime vuosina, paitsi Google Pixel. HMP hyödyntää suurta. VÄHÄ arkkitehtuuri, joka delegoi alhaisen prioriteetin, vähemmän intensiivisen työn pienille ytimille, jotka kuluttavat vähemmän virtaa. HMP on "turvallinen", jossa se tietää, mitä pitäisi mennä suuriin ytimiin ja mitä pitäisi mennä pieniin ytimiin, tekemättä virheitä. Se vain toimii ja vaatii paljon vähemmän vaivaa käyttöönottoon kehityspuolella kuin EAS: n kaltainen, johon pääsemme hetken kuluttua. HMP on vain CFS: n laajennus tehotietoisuuden lisäämiseksi.
HMP ei ota arvauksia eikä ennusta tulevia prosesseja. Tämä on hyvä asia, mutta siksi laite ei voi olla yhtä nestemäinen kuin EAS: ää käyttävät ja siksi se kuluttaa myös hieman enemmän akkua. Tämä vie meidät lopulta Energy Aware Scheduling (EAS) -ohjelmaan, jonka uskon vakaasti olevan tulevaisuus ROM- ja ytimen kehityksessä, kun yhä useammat OEM-valmistajat ottavat sen käyttöön.
Energiatietoinen aikataulu
Energy Aware Scheduling (EAS) on seuraava iso asia, josta käyttäjät foorumeillamme puhuvat. Jos käytät OnePlus 3:a (tai Google Pixeliä, ilmeisesti), olet varmasti kuullut siitä foorumeilla. Se lanseerattiin valtavirtaan Qualcomm Snapdragon 845:n kanssa, joten jos sinulla on jokin näistä laitteista, sinulla on jo EAS-yhteensopiva älypuhelin. EAS ytimien muodossa, kuten RenderZenith ja ROM-levyt, kuten VertexOS ja PureFusion valtasivat OnePlus 3 -foorumit parhaimmillaan. Tietysti Google Pixelin mukana tulee myös EAS. Mikä on saalis lupausten parantuneesta akun kestosta ja paremmasta suorituskyvystä?
Energiatietoinen ajoitus ei ole niin yksinkertaista, koska se ei ole universaali kaikille laitteille, kuten CFS tai HMP. EAS edellyttää energiamallin pohjalta ymmärrystä prosessorista, jossa se toimii. Nämä energiamallit ovat insinööritiimien valmistamia, jotka testaavat jatkuvasti ja työskentelevät optimaalisen suorituskyvyn saavuttamiseksi. Koska Snapdragon 820 ja 821 ovat periaatteessa samat, OnePlus 3:n mukautetut ytimet käyttävät Google Pixel -energiamallia. Snapdragon 845:llä varustetut laitteet voivat hyödyntää EAS: ää, ja OnePlus 6 käyttää jossain määrin. Se ei ole niin viritetty kuin Google Pixel -laite, mutta se tekee työnsä. Tässä on esimerkki siitä, kuinka vaikka OnePlus 6:ssa on parempi prosessori EAS: lla, Pixel 2 XL päihittää sen silti tasaisesti. Molemmat kuvat on otettu meiltä nopeussuuntautunut tarkistus OnePlus 6:sta.
Jos sinulla on vaikeuksia ymmärtää kaavioita, voit katsoa ohjetta alla olevasta kuvasta. Kaikki vihreän viivan ylittäminen tarkoittaa pudonneita kehyksiä ja pahimmassa tapauksessa havaittavaa änkytystä.
EAS: n OnePlus 6 -toteutus on mielenkiintoinen, koska se ei näytä olevan täysin toimiva toteutus, kuten Google Pixelissä, jossa on sama SoC. Scheder-virittävillä ei myöskään ole paljon järkeä, joten se todennäköisesti selittää, miksi se ei ole niin suorituskykyinen kuin odotit. Se on erittäin konservatiivinen virrankulutuksen suhteen, ja järjestelmä priorisoi pienitehoiset ytimet suurimmassa osassa työtä.
Viritettävät ovat yksinkertaisesti joukko parametreja, jotka välitetään CPU: n ohjaimelle, mikä muuttaa sitä, miten ohjain reagoi tiettyihin tilanteisiin taajuuden suhteen. Ajastin päättää sitten, mihin se sijoittaa tehtäviä eri prosessoreihin. OnePlus 6:n virittimet on asetettu priorisoimaan pienitehoisten ytimien käyttöä. Se ei myöskään auta, että Google Pixel 2:ssa on valtava määrä syöttötehoa, mikä pitää kaikki 8 ydintä verkossa koko ajan. Google käyttää myös keskeytyksen tasapainotin joka auttaa poistamaan rungon putoamisen ja parantamaan suorituskykyä.
Joten miten EAS toimii? Miksi se on niin tehokas vain tietyissä olosuhteissa?
Energy Aware Scheduling tuo energiamallin käytön tarpeen, ja kuten edellä mainittiin, sen täydellinen tekeminen vaatii paljon testausta ja työtä. EAS yrittää yhdistää kolme erilaista ytimen ydinosaa, jotka kaikki toimivat itsenäisesti, ja energiamalli auttaa yhdistämään niitä.
- Linux-aikataulu (CFS, mainittu yllä)
- Linux cpuidle
- Linux cpufreq
Kaikkien kolmen osan yhdistäminen aikataulun alle ja laskeminen yhdessä antaa mahdollisuuden energiansäästöön, koska laskemalla ne yhdessä mahdollistavat niiden tehokkuuden. CPUIdle yrittää päättää, milloin suorittimen tulee siirtyä lepotilaan, kun taas CPUFreq yrittää päättää, milloin prosessoria nostetaan tai lasketaan. Molempien moduulien ensisijaisena tavoitteena on säästää energiaa. Sen lisäksi se luokittelee prosessit neljään c-ryhmään, jotka ovat huippusovellus, järjestelmätausta, etuala ja tausta. Käsiteltävät tehtävät sijoitetaan johonkin näistä luokista, ja sitten kategorialle annetaan prosessoriteho ja työ delegoidaan eri CPU-ytimille. top-app on suorituksen korkein prioriteetti, jota seuraa etuala, tausta ja sitten järjestelmätausta. Taustalla on teknisesti sama prioriteetti kuin järjestelmätaustalla, mutta järjestelmätaustalla on yleensä pääsy myös useampaan pienempään ytimeen. Itse asiassa Energy Aware Scheduling ottaa Linux-ytimen ydinosat ja yhdistää sen yhdeksi prosessiksi.
Kun laitetta herätetään, EAS valitsee ytimen matalimmassa tyhjäkäynnissä, mikä minimoi laitteen herättämiseen tarvittavan energian. Tämä auttaa vähentämään laitteen käytössä tarvittavaa tehoa, koska se ei herätä suurta klusteria, jos sen ei tarvitse. Kuorman seuranta on myös erittäin tärkeä osa EAS: ää, ja vaihtoehtoja on kaksi. "Per-Entity Load Tracking" (PELT) -toimintoa käytetään yleensä kuormituksen seurantaan, minkä jälkeen tietoja käytetään päätettäessä taajuuksista ja tehtävien delegoinnista prosessorissa. "Window-Assisted Load Tracking" (WALT) -toimintoa voidaan myös käyttää, ja sitä käytetään Google Pixelissä. Monet foorumeillamme olevat EAS-ROM-levyt, kuten VertexOS, valitsevat WALTin käytön. Monet ROM-levyt julkaisevat kaksi versiota ytimestä, joissa on WALT tai PELT, joten se on käyttäjän päätettävissä. WALT on purskeisempi ja prosessorin taajuuden huippuja on korkea, kun taas PELT yrittää pysyä johdonmukaisempana. Kuormanseuranta ei itse asiassa vaikuta suorittimen taajuuteen, se vain kertoo järjestelmälle prosessorin käytön. Suurempi suorittimen käyttö vaatii korkeamman taajuuden, joten PELTin johdonmukainen ominaisuus on, että se saa suorittimen taajuuden nousemaan tai laskemaan hitaasti. PELT pyrkii harhailemaan kohti korkeamman suorittimen kuormituksen raportointia, joten se voi tarjota paremman suorituskyvyn korkeammalla akun kustannuksilla. Kukaan ei kuitenkaan voi tässä vaiheessa sanoa, mikä kuormanseurantajärjestelmä on parempi, koska molempia kuormanseurantamenetelmiä korjataan ja jalostetaan jatkuvasti.
Joka tapauksessa on selvää, että käytetystä kuormanseurantamenetelmästä riippumatta tehokkuus lisääntyy. Sen sijaan, että käsiteltäisiin tehtäviä millä tahansa prosessorilla, tehtävä analysoidaan ja sen suorittamiseen tarvittava energiamäärä arvioidaan. Tämä älykäs tehtäväsijoittelu tarkoittaa, että tehtävät suoritetaan paljon tehokkaammin ja samalla nopeuttaa koko järjestelmää. EAS: n tavoitteena on saada mahdollisimman sujuva käyttöliittymä mahdollisimman pienellä virrankulutuksella. Tässä tulevat esiin muut ulkoiset komponentit, kuten schedtune.
Schedtune määritellään kussakin c-ryhmässä kahdella viritettävällä säätimellä, jotka varmistavat suoritettavien tehtävien tarkemman hallinnan. Se ei vain ohjaa tehtävien jakautumista useille prosessoreille, vaan myös sitä, pitäisikö havaittua kuormitusta lisätä, jotta aikaherkät tehtävät voidaan suorittaa nopeammin. Näin käyttäjän käyttämät etualan sovellukset ja palvelut eivät hidastu ja aiheuta tarpeettomia suorituskykyongelmia.
Vaikka Energy Aware Scheduling on seuraava iso asia, voidaan myös väittää, että se on jo täällä ja on ollut jo jonkin aikaa. Yhä useammat laitteet saavuttavat valtavirran Energy Aware Schedulingin avulla, joten mobiilikäsittelyn tehokkuuden uusi aikakausi on täällä.
Round-Robinin, CFS: n, HMP: n ja EAS: n hyvät ja huonot puolet
Vaikka graafiset taitoni ovat huonot, olen koonnut kuvan, jonka pitäisi tiivistää kunkin aikataulun edut ja haitat.
Haluan esittää erityisen kiitoksen XDA Recognized Contributorille Mostafa Wael joiden selitykset EAS: n eri näkökohdista auttoivat suuresti tekemään tämän artikkelin mahdolliseksi. Haluan myös kiittää XDA Recognized Developeria joshuus, XDA: n tunnustettu kehittäjä RenderBroken ja Mostafa Wael hänen kirjoituksestaan EAS: ssa. Niille teistä, jotka ovat kiinnostuneita EAS: iin liittyvistä osista, Linarolla on paljon EAS-asiakirjoja, joita voit lukea.