Smartphony Google Pixel patří mezi nejrychlejší telefony s Androidem na trhu. Energy Aware Scheduling (EAS) je částečně důvodem, proč je telefon tak hladký.
Daleko v minulosti, kdy byl Linux pouhou myšlenkou Linuse Torvaldse, byly CPU jednotky s jedním jádrem, které vyžadovaly obrovské množství energie při malém výkonu. Vůbec první komerčně dostupný procesor Intel 4004 běžel na taktovací frekvenci 740 kHz na jednom jádru. Tehdy nebylo potřeba plánovače zatížení. Plánování zátěže bylo vyhrazeno pro dvoujádrové „monstry“, jako je IBM Power 4, který vyšel několik desetiletí poté. Ty běžely na brutálních 1,1 GHz až 1,9 GHz a vyžadovaly programy a systém, aby tato jádra správně využívala. Jak jsme se dostali od těchto strojů k softwarovým algoritmům, které využívají více jader? Možná jste již na našem fóru slyšeli o Energy Aware Scheduling (EAS). Je to jeden z důvodů, proč smartphony Google Pixel fungují tak dobře. Co je na EAS tak skvělého a jak jsme se k tomuto bodu vůbec dostali? Než to budeme moci vysvětlit, musíme si promluvit o plánovačích zatížení Linuxu.
Vývoj plánovačů zatížení Linuxu
Round-Robin plánování
Round robin processing je jednoduchý koncept k vysvětlení a pochopení a ještě jednodušší k pochopení jeho nevýhod. Round-robin používá dělení času k přidělení času každému procesu. Předpokládejme, že na našem počítači běží čtyři procesy.
- Proces A
- Proces B
- Proces C
- Proces D
Nyní udělejme práci plánovače kruhových obměn. Než přejdeme k dalšímu, každému procesu přidělíme 100 milisekund (časové dělení). To znamená, že procesu A může zpracování trvat 100 milisekund, poté se přesune do procesu B a tak dále. Pokud úloha aplikace trvá 250 milisekund, bude muset projít tímto procesem 3krát, aby dokončila svou práci! Nyní to rozšiřte mezi různá jádra, takže Proces A a Proces B budou přiděleny jádru 1 a Proces C a Proces D budou přiděleny jádru 2. To bylo nahrazeno plánováním O(n) (které bylo jako kolo-robin, ale s použitím epoch a umožňujícím dynamickou alokaci čas), pak O(1) plánování (minimální režie, neomezená podpora procesů), nakonec úplně férový plánovač (CFS). CFS byl začleněn do linuxového jádra verze 2.6.23 v říjnu 2007. Od té doby byl přepracován a stále je výchozím plánovačem v systémech Linux.
Zcela spravedlivý plánovač
The Completely Fair Scheduler existuje v Androidu od jeho počátku a používá se na jiných než velkých. LITTLE zařízení. Používá inteligentní algoritmus k určení pořadí zpracování, přiděleného času atd. Je to příklad fungující implementace dobře prostudovaného plánovacího algoritmu zvaného „vážené spravedlivé řazení do front“. To se v podstatě zaměřuje na poskytování priority systémovým procesům a dalším procesům s vysokou prioritou běžícími na systému stroj. Kdyby to mělo běžet na velkém. LITTLE zařízení, všechna jádra by byla vnímána jako rovnocenná. To je špatné, protože jádra s nízkou spotřebou mohou být nucena spouštět intenzivní aplikace, nebo v horším případě může nastat opak. Dekódování pro poslech hudby může být provedeno na velkém jádře, což zbytečně zvyšuje spotřebu energie. To je důvod, proč potřebujeme nový plánovač pro velké. LITTLE, který dokáže skutečně rozpoznat a využít rozdíl v jádrech energeticky účinným způsobem. Zde přichází na scénu Heterogeneous Multi-Processing (HMP), standardní plánovač zatížení, na kterém nyní běží většina telefonů Android.
Heterogenní vícenásobné zpracování
Toto je standardní plánovač zatížení pro všechny velké. LITTLE zařízení vydané v posledních letech, jiné než Google Pixel. HMP využívá velké. Architektura LITTLE, delegující nízkou prioritu, méně intenzivní práci na malá jádra, která spotřebovávají méně energie. HMP je „bezpečné“, v němž ví, co by mělo jít do velkých jader a co by mělo jít do malých jader, aniž by dělalo chyby. Prostě to funguje a vyžaduje mnohem méně úsilí na nastavení po vývojářské stránce než něco jako EAS, do kterého se pustíme za chvíli. HMP je pouze rozšířením CFS, aby si uvědomilo výkon.
HMP nehádá ani nepředpovídá budoucí procesy. To je dobré, ale to je důvod, proč zařízení nemůže být tak tekuté jako ty, které používají EAS, a také proto spotřebovává o něco více baterie. To nás konečně přivádí k Energy Aware Scheduling (EAS), o kterém pevně věřím, že je budoucností ve vývoji ROM a jádra, protože jej přijme více výrobců OEM.
Plánování s ohledem na energii
Energy Aware Scheduling (EAS) je další velká věc, o které uživatelé na našich fórech mluví. Pokud používáte OnePlus 3 (nebo samozřejmě Google Pixel), určitě jste o něm ve fórech slyšeli. Vstoupil do hlavního proudu s Qualcomm Snapdragon 845, takže pokud máte jedno z těchto zařízení, již máte smartphone s podporou EAS. EAS v podobě jader jako např RenderZenith a ROM jako např VertexOS a PureFusion berou fóra OnePlus 3 útokem v nejlepších letech. Google Pixel samozřejmě přichází také s EAS. V čem je ten háček se sliby o lepší výdrži baterie a lepším výkonu?
Energy Aware Scheduling není tak jednoduché, protože není univerzální pro každé zařízení, jako je CFS nebo HMP. EAS vyžaduje pochopení procesoru, na kterém běží, na základě energetického modelu. Tyto energetické modely jsou vytvářeny týmy inženýrů, které neustále testují a pracují na optimálním výkonu. Protože Snapdragon 820 a 821 jsou v podstatě stejné, vlastní jádra na OnePlus 3 využívají energetický model Google Pixel. Zařízení se Snapdragonem 845 mohou využívat EAS a OnePlus 6 do určité míry ano. Není tak vyladěný jako zařízení Google Pixel, ale svou práci zvládne. Zde je příklad toho, jak navzdory tomu, že OnePlus 6 má lepší procesor s EAS, Pixel 2 XL jej stále překonává v plynulosti. Oba tyto obrázky byly převzaty z našeho recenze zaměřená na rychlost z OnePlus 6.
Pokud máte potíže s pochopením grafů, můžete se podívat na níže uvedený obrázek. Cokoli překračuje zelenou čáru, znamená vypadlé snímky a v nejhorších případech znatelné zadrhávání.
Implementace EAS OnePlus 6 je zajímavá, protože se nezdá být plnohodnotnou implementací, jakou byste našli na Google Pixel se stejným SoC. Laditelnost plánovače také nedává moc smysl, takže to pravděpodobně vysvětluje, proč není výkonově tak efektivní, jak byste očekávali. Je extrémně konzervativní ve spotřebě energie, přičemž systém upřednostňuje jádra s nízkou spotřebou energie pro většinu práce.
Laditelné parametry jsou jednoduše sada parametrů, které jsou předávány do regulátoru CPU, což mění, jak regulátor reaguje na určité situace z hlediska frekvence. Plánovač pak rozhodne, kam umístí úkoly na různé procesory. Laditelnost OnePlus 6 je nastavena tak, aby upřednostňovala práci na jádrech s nízkou spotřebou. Nepomáhá ani to, že Google Pixel 2 má obrovské množství vstupního posílení a udržuje všech 8 jader neustále online. Google také používá vyvažovač přerušení což pomáhá odstranit pády rámu a zlepšit výkon.
Jak tedy EAS funguje? Proč je tak účinný pouze za určitých podmínek?
Energy Aware Scheduling zavádí nutnost používat energetický model a jak již bylo zmíněno výše, vyžaduje hodně testování a práce, aby byl dokonalý. EAS se pokouší sjednotit tři různé základní části jádra, které všechny fungují nezávisle, a energetický model je pomáhá sjednotit.
- Plánovač Linux (CFS, zmíněný výše)
- Linux cpuidle
- Linux cpufreq
Sjednocení všech 3 částí pod plánovačem a jejich společný výpočet dává potenciál pro úsporu energie, protože jejich společný výpočet jim umožňuje být co nejúčinnější. CPUIdle se snaží rozhodnout, kdy má CPU přejít do klidového režimu, zatímco CPUFreq se snaží rozhodnout, kdy má CPU zvýšit nebo snížit. Oba tyto moduly mají primární cíl šetřit energii. A nejen to, pak kategorizuje procesy do čtyř skupin cgroups, které jsou top-app, system-background, foreground a background. Úlohy, které mají být zpracovány, jsou zařazeny do jedné z těchto kategorií a poté je kategorii přidělen výkon CPU a práce je delegována na různá jádra CPU. top-app má nejvyšší prioritu dokončení, následuje popředí, pozadí a poté pozadí systému. Pozadí má technicky stejnou prioritu jako systémové pozadí, ale systémové pozadí má obvykle také přístup k většímu počtu malých jader. Energy Aware Scheduling ve skutečnosti přebírá základní části linuxového jádra a sjednocuje je do jednoho procesu.
Při probuzení zařízení EAS vybere jádro v nejmělčím klidovém stavu, čímž minimalizuje energii potřebnou k probuzení zařízení. To pomáhá snížit potřebnou energii při používání zařízení, protože neprobudí velký cluster, pokud to nepotřebuje. Sledování zátěže je také extrémně důležitou součástí EAS a existují dvě možnosti. "Per-Entity Load Tracking" (PELT) se obvykle používá pro sledování zatížení, informace se pak používají k rozhodování o frekvencích a způsobu delegování úkolů napříč CPU. Lze také použít „Window-Assisted Load Tracking“ (WALT), které se používá na Google Pixel. Mnoho EAS ROM na našich fórech, jako je VertexOS, se rozhodlo používat WALT. Mnoho ROM uvolní dvě verze jádra s WALT nebo PELT, takže je na uživateli, jak se rozhodne. WALT je svižnější, s vysokými špičkami ve frekvenci CPU, zatímco PELT se snaží zůstat konzistentnější. Sledovač zátěže ve skutečnosti neovlivňuje frekvenci CPU, pouze říká systému, jaké je využití CPU. Vyšší využití CPU vyžaduje vyšší frekvenci, a proto konzistentní vlastností PELT je, že způsobuje pomalé zvyšování nebo snižování frekvence CPU. PELT má tendenci se odklonit od hlášení vyšší zátěže CPU, takže může poskytovat vyšší výkon při vyšších nákladech na baterii. Nikdo nemůže v tuto chvíli skutečně říci, který systém sledování zátěže je lepší, protože obě metody sledování zátěže se neustále opravují a zdokonalují.
Ať tak či onak, je zřejmé, že bez ohledu na použitou metodu sledování zátěže dochází ke zvýšení efektivity. Namísto zpracování úloh na libovolném procesoru je úloha analyzována a odhaduje se množství energie potřebné k jejímu spuštění. Toto chytré umístění úkolů znamená, že úkoly budou dokončeny mnohem efektivněji a zároveň zrychlí systém jako celek. EAS je o získání nejplynulejšího možného uživatelského rozhraní s minimální spotřebou energie. Zde vstupují do hry další externí komponenty, jako je schedtune.
Schedtune je definován v každé cgroup dvěma laditelnými prvky, které zajišťují jemnější kontrolu nad úkoly, které mají být dokončeny. Nekontroluje pouze rozložení úloh na více CPU, ale také to, zda by se měla vnímaná zátěž nafouknout, aby se zajistilo rychlejší dokončení časově citlivých úloh. Tímto způsobem se aplikace a služby v popředí, které uživatel využívá, nezpomalí a nezpůsobí zbytečné problémy s výkonem.
Zatímco Energy Aware Scheduling je další velká věc, lze také tvrdit, že tu již je a nějakou dobu je. S tím, jak se stále více zařízení dostává do hlavního proudu s plánováním Energy Aware, přichází nový věk efektivity mobilního zpracování.
Výhody a nevýhody Round-Robin, CFS, HMP a EAS
I když jsou mé grafické dovednosti podprůměrné, dal jsem dohromady obrázek, který by měl shrnout, jaké jsou výhody a nevýhody každého z těchto plánovačů.
Rád bych vyjádřil zvláštní poděkování uznávanému přispěvateli XDA Mostafa Wael jehož vysvětlení různých aspektů EAS velmi pomohla k vytvoření tohoto článku. Také bych rád poděkoval XDA Recognized Developer joshuous, XDA uznávaný vývojář RenderBroken a Mostafa Wael za jeho příspěvek na EAS. Pro ty z vás, kteří našli zájem o díly související s EAS, má Linaro spoustu dokumentace o EAS, kterou si můžete přečíst.