Jak EAS pomaga uczynić Google Pixel najszybszym telefonem z Androidem

Co to oznacza dla twojego następnego smartfona

Dawno temu, kiedy Linux był pomysłem Linusa Torvaldsa, procesory były jednostkami jednordzeniowymi, które wymagały ogromnej ilości energii przy niewielkiej mocy. Pierwszy dostępny na rynku procesor, Intel 4004, działał z taktowaniem 740 kHz na jednym rdzeniu. Wówczas nie było potrzeby tworzenia harmonogramu ładowania. Planowanie obciążenia było zarezerwowane dla dwurdzeniowych „gigantów”, takich jak IBM Power 4, które pojawiły się kilkadziesiąt lat później. Działały one z bestią od 1, 1 GHz do 1, 9 GHz i wymagały programów i systemu do prawidłowego wykorzystania tych rdzeni. Jak dotarliśmy z tych maszyn do algorytmów programowych wykorzystujących wiele rdzeni? Być może słyszałeś już wcześniej o planowaniu wykorzystania energii (EAS) na naszych forach. Jest to jeden z powodów, dla których smartfony Google Pixel działają tak dobrze. Co jest takiego wspaniałego w EAS i jak do tego doszliśmy? Zanim to wyjaśnimy, musimy porozmawiać o harmonogramach ładowania systemu Linux.


Ewolucja harmonogramów ładowania systemu Linux

Round-Robin Scheduling

Round Robin Processing. Źródło: Wikipedia

Okrągłe przetwarzanie robin to prosta koncepcja do wyjaśnienia i zrozumienia, a jeszcze prostsza do uchwycenia jej wad. Round-robin wykorzystuje podział czasu, aby przydzielić czas do każdego procesu. Załóżmy, że na naszym komputerze działają cztery procesy.

  • Proces A
  • Proces B
  • Proces C
  • Proces D

A teraz zróbmy zadanie przy użyciu programu do rundy. Przydzielimy 100 milisekund (przedział czasu) do każdego procesu przed przejściem do następnego. Oznacza to, że proces A może zająć 100 milisekund na przetworzenie, a następnie przechodzi do procesu B i tak dalej. Jeśli zadanie aplikacji zajmuje 250 milisekund, będzie musiał przejść ten proces 3 razy, aby zakończyć pracę! Teraz przeskaluj to w różnych rdzeniach, aby Proces A i Proces B zostały przydzielone do rdzenia 1, a Proces C i Proces D zostały przypisane do rdzenia 2. Zostało to zastąpione przez harmonogram O (n) (który był podobny do rundy, ale za pomocą epok i umożliwiając dynamiczny przydział czasu), następnie planowanie O (1) (zminimalizowane koszty ogólne, nieograniczone wsparcie procesu), a następnie w końcu całkowicie sprawiedliwy harmonogram (CFS). CFS został połączony z jądrem Linuksa w wersji 2.6.23 w październiku 2007 roku. Został przebudowany od tego czasu i nadal jest domyślnym harmonogramem w systemach Linux.

Całkowicie uczciwy harmonogram

Całkowicie uczciwy program planujący istnieje w Androidzie od samego początku i jest używany na urządzeniach innych niż duże.LITTLE. Wykorzystuje inteligentny algorytm do określania kolejności przetwarzania, przydzielonego czasu itp. Jest to przykład działającej implementacji dobrze zbadanego algorytmu planowania zwanego „ważonym uczciwym kolejkowaniem”. Zasadniczo koncentruje się on na zapewnieniu priorytetu procesom systemowym i innym procesom o wysokim priorytecie. działa na maszynie. Gdyby działał na urządzeniu big.LITTLE, wszystkie rdzenie byłyby postrzegane jako równe. Jest to złe, ponieważ rdzenie o niskiej mocy mogą być zmuszone do uruchamiania intensywnych aplikacji, a nawet gorzej, może wystąpić odwrotnie. Dekodowanie do słuchania muzyki może odbywać się na dużym rdzeniu, na przykład niepotrzebnie zwiększając zużycie energii. Właśnie dlatego potrzebujemy nowego harmonogramu dla big.LITTLE, takiego, który może faktycznie rozpoznać i wykorzystać różnicę w rdzeniach w efektywny energetycznie sposób. Właśnie tam pojawia się heterogeniczne przetwarzanie wieloprocesorowe (HMP), standardowy harmonogram ładowania, który działa obecnie na większości telefonów z Androidem.

Niejednorodna wieloprocesowa obróbka

Jest to standardowy harmonogram ładowania dla dowolnego urządzenia big.LITTLE wydanego w ostatnich latach, innego niż Google Pixel. HMP korzysta z architektury big.LITTLE, delegując niski priorytet, mniej intensywną pracę na małe rdzenie zużywające mniej energii. HMP jest „bezpieczny”, ponieważ wie, co powinno iść do dużych rdzeni, a co do małych rdzeni, bez popełniania błędów. To po prostu działa i wymaga dużo mniej wysiłku, aby skonfigurować po stronie programistycznej niż coś takiego jak EAS, o czym za chwilę się zajmiemy. HMP jest tylko rozszerzeniem CFS, aby uczynić go świadomym mocy.

HMP nie zgaduje ani nie przewiduje przyszłych procesów. Jest to dobre, ale dlatego urządzenie nie może być tak płynne jak te z EAS i dlatego zużywa nieco więcej baterii. To wreszcie prowadzi nas do EAS (Energy Aware Scheduling), które, jak wierzę, są przyszłością w rozwoju ROM i jądra w miarę, jak przyjmą je inni producenci OEM.

Planowanie z uwzględnieniem energii

Energy Aware Scheduling (EAS) to kolejna wielka rzecz, o której mówią użytkownicy na naszych forach. Jeśli używasz OnePlus 3 (lub Google Pixel, oczywiście) na pewno słyszałeś o tym na forach. Został wprowadzony do głównego nurtu dzięki Qualcomm Snapdragon 845, więc jeśli masz jedno z tych urządzeń, masz już smartfon z obsługą EAS. EAS w postaci jąder, takich jak RenderZenith i ROM-y, takie jak VertexOS i PureFusion, błyskawicznie zdobywały fora OnePlus 3. Oczywiście Google Pixel jest również wyposażony w EAS. Co przyniesie obietnica poprawy żywotności baterii i lepszej wydajności?

Planowanie z uwzględnieniem zużycia energii nie jest tak proste, ponieważ nie jest uniwersalne dla każdego urządzenia, takiego jak CFS lub HMP. EAS wymaga zrozumienia procesora, na którym działa, w oparciu o model energetyczny. Te modele energii są tworzone przez zespoły inżynierów stale testujących i pracujących w celu zapewnienia optymalnej wydajności. Ponieważ Snapdragon 820 i 821 są w zasadzie takie same, niestandardowe jądra w OnePlus 3 wykorzystują model energetyczny Google Pixel. Urządzenia z Snapdragon 845 mogą korzystać z EAS, a OnePlus 6 do pewnego stopnia. Nie jest tak dostrojony, jak urządzenie Google Pixel, ale wykonuje zadanie. Oto przykład tego, jak pomimo tego, że OnePlus 6 ma lepszy procesor z EAS, Pixel 2 XL wciąż bije go płynnie. Oba te zdjęcia pochodzą z naszej zorientowanej na szybkość recenzji OnePlus 6.

Jeśli masz problemy ze zrozumieniem wykresów, możesz zapoznać się z poniższym obrazkiem w celu uzyskania wskazówek. Wszystko, co wykracza poza zieloną linię, oznacza upuszczone ramki, aw najgorszych przypadkach zauważalne jąkanie.

Implementacja EAS w OnePlus 6 jest interesująca, ponieważ nie wydaje się być pełnoprawną implementacją, jaką można znaleźć w Google Pixel z tym samym SoC. Strojenie harmonogramu również nie ma większego sensu, więc prawdopodobnie wyjaśnia to, dlaczego nie jest tak wydajne, jak można się spodziewać. Jest wyjątkowo konserwatywny pod względem zużycia energii, a system priorytetowo traktuje rdzenie małej mocy przez większość pracy.

Przestrajalne to po prostu zestaw parametrów, które są przekazywane do regulatora procesora, co zmienia sposób, w jaki regulator reaguje na określone sytuacje pod względem częstotliwości. Następnie harmonogram decyduje, gdzie umieszcza zadania na różnych procesorach. Tunery OnePlus 6 są ustawione tak, aby nadać priorytet pracy na rdzeniach o niskiej mocy. Nie pomaga również to, że Google Pixel 2 ma ogromne zwiększenie mocy wejściowej, utrzymując wszystkie 8 rdzeni online przez cały czas. Google używa również modułu równoważenia przerwania, który pomaga usunąć spadki klatek i poprawić wydajność.

Jak działa EAS? Dlaczego jest tak wydajny tylko w określonych warunkach?

Planowanie z uwzględnieniem energii wprowadza potrzebę korzystania z modelu energii i, jak wspomniano powyżej, wymaga wielu testów i pracy, aby był idealny. EAS próbuje ujednolicić trzy różne podstawowe części jądra, z których wszystkie działają niezależnie, a model energetyczny pomaga je ujednolicić.

  • Harmonogram systemu Linux (wspomniany wyżej CFS)
  • Linux cpuidle
  • Linux cpufreq

Ujednolicenie wszystkich 3 części w harmonogramie i ich obliczenie razem daje potencjał do oszczędności energii, ponieważ obliczenie ich razem pozwala im być maksymalnie wydajnymi. CPUIdle próbuje zdecydować, kiedy CPU powinien przejść w tryb bezczynności, podczas gdy CPUFreq próbuje zdecydować, kiedy zwiększyć lub zmniejszyć procesor. Oba te moduły mają na celu przede wszystkim oszczędzanie energii. Ponadto kategoryzuje procesy na cztery grupy, które są najlepszymi aplikacjami, tłem systemowym, pierwszym planem i tłem. Zadania, które mają zostać przetworzone, są umieszczane w jednej z tych kategorii, a następnie kategoria ta otrzymuje moc procesora, a praca jest delegowana na różne rdzenie procesora. najwyższa aplikacja to najwyższy priorytet ukończenia, a następnie pierwszy plan, tło, a następnie tło systemu. Tło z technicznego punktu widzenia ma taki sam priorytet jak tło systemu, ale tło systemu zwykle ma również dostęp do większej liczby rdzeni. W efekcie Energy Aware Scheduling łączy kluczowe części jądra Linuksa i łączy je w jeden proces.

Po przebudzeniu urządzenia EAS wybierze rdzeń w płytkim stanie bezczynności, minimalizując energię potrzebną do obudzenia urządzenia. Pomaga to zmniejszyć wymaganą moc podczas korzystania z urządzenia, ponieważ nie obudzi dużego klastra, jeśli nie będzie to konieczne. Śledzenie obciążenia jest również niezwykle istotną częścią EAS i istnieją dwie opcje. „Śledzenie obciążenia na jednostkę” (PELT) jest zwykle używane do śledzenia obciążenia, informacje są następnie wykorzystywane do decydowania o częstotliwościach i jak delegować zadania na procesor. Można również użyć „śledzenia wspomaganego przez okno” (WALT) i jest ono używane w Google Pixel. Wiele ROM EAS na naszych forach, takich jak VertexOS, decyduje się na użycie WALT. Wiele ROM-ów wyda dwie wersje jądra z WALT lub PELT, więc decyzja należy do użytkownika. WALT jest bardziej wybuchowy, z wysokimi pikami częstotliwości procesora, podczas gdy PELT stara się być bardziej spójny. Moduł śledzenia obciążenia w rzeczywistości nie wpływa na częstotliwość procesora, po prostu informuje system o tym, jakie jest użycie procesora. Wyższe użycie procesora wymaga wyższej częstotliwości, więc konsekwentną cechą PELT jest to, że powoduje on, że częstotliwość procesora stopniowo rośnie lub maleje. PELT często błąka się w kierunku raportowania większego obciążenia procesora, więc może zapewnić wyższą wydajność przy wyższym koszcie baterii. Nikt jednak nie jest w stanie powiedzieć, który system śledzenia obciążenia jest lepszy, ponieważ obie metody śledzenia obciążenia są ciągle poprawiane i udoskonalane.

Tak czy inaczej, oczywiste jest, że niezależnie od zastosowanej metody śledzenia obciążenia występuje wzrost wydajności. Zadanie jest analizowane, a nie tylko przetwarzane na dowolnym procesorze, i szacowana ilość energii potrzebnej do jego uruchomienia. To sprytne umieszczanie zadań oznacza, że ​​zadania są wykonywane w znacznie bardziej wydajny sposób, a jednocześnie system jest szybszy jako całość. EAS polega na uzyskiwaniu jak najbardziej płynnego interfejsu użytkownika przy minimalnym zużyciu energii. W tym miejscu mają zastosowanie inne komponenty zewnętrzne, takie jak harmonogram.

Harmonogram jest zdefiniowany w każdej grupie przez dwa przestrajalne, które zapewniają lepszą kontrolę nad zadaniami do wykonania. Nie tylko kontroluje rozkład zadań na wiele procesorów, ale także to, czy postrzegane obciążenie powinno być zawyżone, aby zapewnić szybsze wykonywanie zadań wrażliwych na czas. W ten sposób aplikacje i usługi na pierwszym planie, z których korzysta użytkownik, nie zwolnią i nie spowodują niepotrzebnych problemów z wydajnością.

Chociaż planowanie energetyczne jest kolejną ważną rzeczą, można również argumentować, że już tu jest i było przez jakiś czas. Coraz więcej urządzeń trafia do głównego nurtu dzięki planowaniu energetycznemu, nadchodzi nowa era wydajności przetwarzania mobilnego.

Plusy i minusy Round-Robin, CFS, HMP i EAS

Chociaż moje umiejętności graficzne są słabsze, zrzuciłem obraz, który powinien podsumować zalety i wady każdego z tych harmonogramów.


Chciałbym szczególnie podziękować Uznanemu Współtwórcy Mostafa Waelowi, którego wyjaśnienie różnych aspektów EAS bardzo pomogło w stworzeniu tego artykułu. Chciałbym również podziękować uznanemu deweloperowi joshuous, uznanemu deweloperowi RenderBrokenowi i Mostafa Waelowi za jego napisanie na EAS. Dla tych z Was, którzy zainteresowali się częściami związanymi z EAS, Linaro ma wiele dokumentacji na temat EAS, które można przeczytać.