Google Pixel-smarttelefonerna är bland de snabbaste Android-telefonerna på marknaden. Energy Aware Scheduling (EAS) är delvis varför telefonen är så smidig.
Långt tillbaka i det förflutna när Linux bara var en idé i Linus Torvalds sinne, var processorer enkärniga enheter som krävde en enorm mängd energi för lite kraft. Den första kommersiellt tillgängliga processorn någonsin, Intel 4004, körde med en klockfrekvens på 740 kHz på en enda kärna. Då fanns det inget behov av en belastningsschemaläggare. Belastningsplanering var reserverad för de dual-core "behemoths" som IBM Power 4 som kom ut några decennier efter. Dessa körde på ohyggliga 1,1 GHz till 1,9 GHz och krävde program och systemet för att använda dessa kärnor korrekt. Hur kom vi från dessa maskiner till mjukvarualgoritmer som använder flera kärnor? Du kanske har hört talas om Energy Aware Scheduling (EAS) på våra forum tidigare. Det är en del av anledningen till att Google Pixel-smarttelefonerna presterar så bra. Vad är så bra med EAS och hur kom vi ens till denna punkt? Innan vi kan förklara det måste vi prata om Linux-belastningsschemaläggare.
Utvecklingen av Linux Load Schedulers
Round-Robin Schemaläggning
Round robin-bearbetning är ett enkelt koncept att förklara och förstå, och ett ännu enklare för att förstå dess nackdelar. Round-robin använder time slicing för att allokera tid till varje process. Låt oss anta att vi har fyra processer som körs på vår dator.
- Process A
- Process B
- Process C
- Process D
Nu, låt oss göra jobbet med round-robin-schemaläggaren. Vi kommer att allokera 100 millisekunder (time-slicing) till varje process innan vi går vidare till nästa. Detta innebär att process A kan ta 100 millisekunder att göra sin bearbetning, sedan flyttas den till process B och så vidare. Om en applikations jobb tar 250 millisekunder att göra, kommer den att behöva gå igenom den här processen 3 gånger bara för att avsluta sitt arbete! Skala nu detta över olika kärnor, så att Process A och Process B allokeras till kärna 1, och Process C och Process D tilldelas kärna 2. Detta ersattes av O(n)-schemaläggning (som var som round-robin, men med användning av epoker och tillät dynamisk allokering av tid), sedan O(1) schemaläggning (minimerad overhead, obegränsat processstöd), sedan slutligen Completely Fair Scheduler (CFS). CFS slogs samman till Linux-kärnan version 2.6.23 i oktober 2007. Den har genomgått en översyn sedan dess och är fortfarande standardschemaläggaren i Linux-system.
Helt rättvis schemaläggare
The Completely Fair Scheduler har funnits i Android sedan starten och används på icke-stora. Små enheter. Den använder en intelligent algoritm för att bestämma bearbetningsordning, allokerad tid etc. Det är ett exempel på en fungerande implementering av den väl studerade schemaläggningsalgoritmen som kallas "viktad rättvis köbildning". Detta fokuserar i grunden på att ge prioritet åt systemprocesser och andra högprioriterade processer som körs på maskin. Om det skulle köras på en stor. LITE enhet, alla kärnor skulle uppfattas som lika. Detta är dåligt, eftersom lågeffektskärnor kan tvingas köra intensiva applikationer, eller ännu värre, motsatsen kan inträffa. Avkodningen för att lyssna på musik kan göras på den stora kärnan, till exempel ökar strömförbrukningen i onödan. Det är därför vi behöver en ny schemaläggare för stora. LITTLE, en som faktiskt kan känna igen och utnyttja skillnaden i kärnor på ett energieffektivt sätt. Det är där Heterogeneous Multi-Processing (HMP) kommer in, den vanliga laddningsschemaläggaren som de flesta Android-telefoner körs nu.
Heterogen multibearbetning
Detta är standard lastschemaläggare för alla stora. LITE enhet som släppts under de senaste åren, förutom Google Pixel. HMP använder sig av det stora. LITE arkitektur, delegerar låg prioritet, mindre intensivt arbete till de små kärnorna som förbrukar mindre ström. HMP är "säkert" där den vet vad som ska gå till de stora kärnorna och vad som ska gå till de små kärnorna, utan att göra misstag. Det fungerar bara och kräver mycket mindre ansträngning att ställa in på utvecklingssidan än något som EAS, som vi kommer in på om ett ögonblick. HMP är bara en förlängning av CFS för att göra den kraftmedveten.
HMP tar inga gissningar och förutsäger inte heller framtida processer. Detta är bra men det är därför enheten inte kan vara lika flytande som de som kör EAS och det är också därför den drar lite mer batteri. Detta för oss slutligen till Energy Aware Scheduling (EAS), som jag är övertygad om är framtiden för ROM- och kärnutveckling när fler OEM-tillverkare använder det.
Energimedveten schemaläggning
Energy Aware Scheduling (EAS) är nästa stora sak som användare på våra forum pratar om. Om du använder en OnePlus 3 (eller en Google Pixel, uppenbarligen) har du definitivt hört talas om det i forumen. Den lanserades i mainstream med Qualcomm Snapdragon 845, så om du har en av dessa enheter har du redan en EAS-aktiverad smartphone. EAS i form av kärnor som t.ex RenderZenith och ROM som t.ex VertexOS och PureFusion tog OnePlus 3-forumen med storm i sin bästa tid. Naturligtvis kommer Google Pixel också med EAS. Med löften om förbättrad batteritid och bättre prestanda, vad är haken?
Energy Aware Scheduling är inte så enkelt eftersom det inte är universellt för alla enheter som CFS eller HMP. EAS kräver en förståelse för processorn den körs på, baserat på en energimodell. Dessa energimodeller är gjorda av team av ingenjörer som ständigt testar och arbetar för att ge optimal prestanda. Eftersom Snapdragon 820 och 821 i princip är samma, använder anpassade kärnor på OnePlus 3 Google Pixel-energimodellen. Enheter med Snapdragon 845 kan använda EAS, och OnePlus 6 gör det till viss del. Den är inte så finjusterad som en Google Pixel-enhet skulle vara, men den får jobbet gjort. Här är ett exempel på hur, trots att OnePlus 6 har en bättre processor med EAS, så slår Pixel 2 XL den fortfarande i jämnhet. Båda dessa bilder är tagna från vår hastighetsorienterad granskning av OnePlus 6.
Om du har problem med att förstå graferna kan du ta en titt på bilden nedan för vägledning. Allt som överstiger den gröna linjen tyder på tappade ramar och i värsta fall märkbar stamning.
OnePlus 6-implementeringen av EAS är intressant, eftersom det inte verkar vara en fullfjädrad implementering som du skulle hitta på en Google Pixel med samma SoC. Schemaläggarens justeringar är inte heller meningsfulla, så det förklarar förmodligen varför det inte är så prestandaeffektivt som du kan förvänta dig. Det är extremt konservativt när det gäller strömförbrukning, där systemet prioriterar lågeffektkärnorna för större delen av arbetet.
Tunables är helt enkelt en uppsättning parametrar som skickas till CPU-regulatorn, vilket ändrar hur regulatorn reagerar på vissa situationer när det gäller frekvens. Schemaläggaren bestämmer sedan var den placerar uppgifter på olika processorer. OnePlus 6:s tunables är inställda på att prioritera arbete med lågenergikärnor. Det hjälper inte heller att Google Pixel 2 har en enorm mängd input boost, och håller alla 8 kärnor online hela tiden. Google använder också en avbryta balanseraren som hjälper till att ta bort ramfall och förbättra prestandan.
Så hur fungerar EAS? Varför är det så effektivt bara under vissa förhållanden?
Energy Aware Scheduling introducerar behovet av att använda en energimodell, och som nämnt ovan kräver mycket testning och arbete för att göra den perfekt. EAS försöker förena tre olika kärndelar av kärnan som alla agerar oberoende, och energimodellen hjälper till att förena dem.
- Linux-schemaläggare (CFS, nämnt ovan)
- Linux cpuidle
- Linux cpufreq
Att förena alla tre delar under schemaläggaren och beräkna dem tillsammans ger en potential för energibesparing, eftersom att beräkna dem tillsammans gör att de blir så effektiva som möjligt. CPUIdle försöker bestämma när processorn ska gå in i viloläge, medan CPUFreq försöker bestämma när processorn ska rampas upp eller ner. Båda dessa moduler har det primära målet att spara energi. Inte bara det, den kategoriserar sedan processer i fyra cgroups, som är toppapp, systembakgrund, förgrund och bakgrund. Uppgifter som ska bearbetas placeras i en av dessa kategorier, och sedan ges kategorin CPU-kraft och arbetet delegeras över olika CPU-kärnor. top-app är högsta prioritet för slutförandet, följt av förgrund, bakgrund och sedan systembakgrund. Bakgrund har tekniskt sett samma prioritet som systembakgrund, men systembakgrund brukar också ha tillgång till fler små kärnor. I själva verket tar Energy Aware Scheduling kärndelarna av Linux-kärnan och förenar det hela i en process.
När enheten väcks kommer EAS att välja kärnan i det grundaste viloläget, vilket minimerar den energi som behövs för att väcka enheten. Detta hjälper till att minska den kraft som krävs för att använda enheten, eftersom den inte kommer att väcka det stora klustret om det inte behövs. Lastspårning är också en extremt avgörande del av EAS, och det finns två alternativ. "Per-Entity Load Tracking" (PELT) används vanligtvis för lastspårning, informationen används sedan för att bestämma frekvenser och hur uppgifter ska delegeras över CPU: n. "Window-Assisted Load Tracking" (WALT) kan också användas och är vad som används på Google Pixel. Många EAS ROMs på våra forum, som VertexOS, väljer att använda WALT. Många ROM kommer att släppa två versioner av kärnan med WALT eller PELT, så det är upp till användaren att bestämma. WALT är mer bursty, med höga toppar i CPU-frekvens medan PELT försöker förbli mer konsekvent. Lastspåraren påverkar faktiskt inte CPU-frekvensen, den talar bara om för systemet vad CPU-användningen är på. En högre CPU-användning kräver en högre frekvens och därför är ett konsekvent drag hos PELT att det får CPU-frekvensen att långsamt öka eller minska. PELT tenderar att avvika mot rapportering om högre CPU-belastning, så det kan ge högre prestanda till en högre batterikostnad. Ingen kan egentligen säga vid denna tidpunkt vilket lastspårningssystem som är bättre, eftersom båda lastspårningsmetoderna ständigt korrigeras och förfinas.
Hur som helst är det uppenbart att det, oavsett vilken lastspårningsmetod som används, ökar effektiviteten. Istället för att bara bearbeta uppgifter på vilken processor som helst, analyseras uppgiften och mängden energi som krävs för att köra den uppskattas. Den här smarta uppgiftsplaceringen gör att uppgifterna slutförs på ett mycket mer effektivt sätt samtidigt som det gör systemet snabbare som helhet. EAS handlar om att få ett så smidigt användargränssnitt som möjligt med minimal strömförbrukning. Det är här som andra externa komponenter som schedtune kommer in i bilden.
Schedtune definieras i varje cgroup av två tunables som säkerställer bättre kontroll över de uppgifter som ska slutföras. Det styr inte bara spridningen av uppgifter över flera processorer, utan också om den upplevda belastningen ska blåsas upp för att säkerställa att tidskänsliga uppgifter slutförs snabbare. På så sätt kommer förgrundsapplikationer och tjänster som användaren använder inte att sakta ner och orsaka onödiga prestandaproblem.
Medan Energy Aware Scheduling är nästa stora grej, kan det också hävdas att det redan är här och har varit ett tag. Med fler och fler enheter som når mainstream med Energy Aware Scheduling, är en ny tid av mobil bearbetningseffektivitet här.
För- och nackdelar med Round-Robin, CFS, HMP och EAS
Även om mina grafikkunskaper är undermåliga, har jag slängt ihop en bild som ska sammanfatta vilka fördelar och nackdelar var och en av dessa schemaläggare är.
Jag vill rikta ett speciellt tack till XDA Recognized Contributor Mostafa Wael vars förklaringar av olika aspekter av EAS i hög grad hjälpte till att göra den här artikeln möjlig. Jag vill också tacka XDA Recognized Developer joshuous, XDA erkänd utvecklare RenderBroken och Mostafa Wael för hans inlägg om EAS. För er som funnit intresse för EAS-relaterade delar har Linaro en hel del dokumentation om EAS som ni kan läsa.