Smartfony Google Pixel to jedne z najszybszych telefonów z Androidem na rynku. Energy Aware Scheduling (EAS) jest częściowo powodem tak płynnej pracy telefonu.
Dawno, dawno temu, kiedy Linux był tylko pomysłem Linusa Torvaldsa, procesory były jednordzeniowymi jednostkami, które wymagały ogromnej ilości energii przy niewielkiej mocy. Pierwszy dostępny na rynku procesor, Intel 4004, pracował z częstotliwością taktowania 740 kHz na jednym rdzeniu. W tamtych czasach nie było potrzeby stosowania harmonogramu obciążenia. Planowanie obciążenia było zarezerwowane dla dwurdzeniowych „behemotów”, takich jak IBM Power 4, który pojawił się kilkadziesiąt lat później. Działały one z zawrotną częstotliwością od 1,1 GHz do 1,9 GHz i wymagały programów i systemu do prawidłowego wykorzystania tych rdzeni. Jak przeszliśmy od tych maszyn do algorytmów oprogramowania wykorzystujących wiele rdzeni? Być może słyszałeś już na naszych forach o harmonogramowaniu uwzględniającym zużycie energii (EAS). Między innymi z tego powodu smartfony Google Pixel działają tak dobrze. Co jest takiego wspaniałego w EAS i jak w ogóle dotarliśmy do tego punktu? Zanim będziemy mogli to wyjaśnić, musimy porozmawiać o programach planujących obciążenie Linuksa.
Ewolucja harmonogramów ładowania systemu Linux
Harmonogram okrężny
Przetwarzanie okrężne to koncepcja prosta do wyjaśnienia i zrozumienia, a jeszcze prostsza do zrozumienia jej wad. Metoda okrężna wykorzystuje dzielenie czasu w celu przydzielenia czasu każdemu procesowi. Załóżmy, że na naszym komputerze działają cztery procesy.
- Proces A
- Proces B
- Proces C
- Proces D
Teraz wykonajmy pracę harmonogramu okrężnego. Przydzielimy 100 milisekund (cięcie czasu) każdemu procesowi przed przejściem do następnego. Oznacza to, że przetwarzanie procesu A może zająć 100 milisekund, następnie przechodzi do procesu B i tak dalej. Jeśli wykonanie zadania aplikacji zajmuje 250 milisekund, aby zakończyć pracę, będzie ona musiała przejść ten proces 3 razy! Teraz przeskaluj to na różne rdzenie, tak aby Proces A i Proces B były przydzielone do rdzenia 1, a Procesy C i Proces D do rdzenia 2. Zostało to zastąpione przez planowanie O(n) (które działało jak okrężne, ale wykorzystywało epoki i umożliwiało dynamiczną alokację czas), następnie harmonogramowanie O(1) (zminimalizowany narzut, nieograniczone wsparcie procesów), a na koniec całkowicie uczciwy harmonogram (CFS). CFS został włączony do jądra Linuksa w wersji 2.6.23 w październiku 2007. Od tego czasu został on odnowiony i nadal jest domyślnym harmonogramem w systemach Linux.
Całkowicie uczciwy harmonogram
Program „Completyly Fair Scheduler” istnieje w systemie Android od jego powstania i jest używany na urządzeniach innych niż duże. MAŁO urządzeń. Wykorzystuje inteligentny algorytm do określenia kolejności przetwarzania, przydzielonego czasu itp. Jest to przykład działającej implementacji dobrze zbadanego algorytmu planowania zwanego „ważoną uczciwą kolejką”. Zasadniczo koncentruje się to na zapewnieniu priorytetu procesom systemowym i innym procesom o wysokim priorytecie działającym w systemie maszyna. Gdyby to miało działać na dużym. LITTLE, wszystkie rdzenie byłyby postrzegane jako równe. Jest to niedobre, ponieważ rdzenie o małej mocy mogą być zmuszone do wykonywania intensywnych aplikacji lub, co gorsza, może wystąpić sytuacja odwrotna. Dekodowanie do słuchania muzyki może odbywać się na przykład na dużym rdzeniu, co niepotrzebnie zwiększa zużycie energii. Dlatego właśnie potrzebujemy nowego harmonogramu dla dużych. LITTLE, który faktycznie potrafi rozpoznać i wykorzystać różnicę w rdzeniach w sposób energooszczędny. Tutaj właśnie pojawia się Heterogeneous Multi-Processing (HMP), standardowy harmonogram ładowania, z którego korzysta obecnie większość telefonów z Androidem.
Heterogeniczne przetwarzanie wielokrotne
Jest to standardowy harmonogram ładowania dla każdego dużego pliku. Urządzenie LITTLE wypuszczone na rynek w ostatnich latach, inne niż Google Pixel. HMP wykorzystuje duże możliwości. Architektura LITTLE delegująca mniej intensywną pracę o niskim priorytecie do małych rdzeni, które zużywają mniej energii. HMP jest „bezpieczny”, ponieważ wie, co powinno trafić do dużych, a co do małych rdzeni, bez popełniania błędów. To po prostu działa, a jego konfiguracja po stronie programistycznej wymaga znacznie mniej wysiłku niż coś takiego jak EAS, o którym porozmawiamy za chwilę. HMP to tylko rozszerzenie CFS, które ma na celu zwiększenie świadomości mocy.
HMP nie zgaduje ani nie przewiduje przyszłych procesów. To dobrze, ale dlatego urządzenie nie może być tak płynne jak urządzenia z systemem EAS i dlatego zużywa nieco więcej baterii. To w końcu prowadzi nas do planowania uwzględniającego zużycie energii (EAS), które w moim przekonaniu jest przyszłością w rozwoju pamięci ROM i jądra, w miarę jak będzie go stosować coraz więcej producentów OEM.
Planowanie uwzględniające zużycie energii
Energy Aware Scheduling (EAS) to kolejna ważna rzecz, o której mówią użytkownicy na naszych forach. Jeśli używasz OnePlus 3 (lub oczywiście Google Pixel), na pewno słyszałeś o tym na forach. Wszedł do głównego nurtu wraz z 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 RenderujZenith i ROMy takie jak VertexOS I PureFusion w czasach swojej świetności szturmem zdobywały fora OnePlus 3. Oczywiście Google Pixel jest również wyposażony w EAS. Gdzie jest haczyk przy obietnicach dłuższej żywotności baterii i lepszej wydajności?
Planowanie uwzględniające energię nie jest tak proste, ponieważ nie jest uniwersalne dla każdego urządzenia, takiego jak CFS czy 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, które stale testują i pracują nad zapewnieniem optymalnej wydajności. Ponieważ Snapdragon 820 i 821 są w zasadzie takie same, niestandardowe jądra OnePlus 3 korzystają z modelu energetycznego Google Pixel. Urządzenia ze Snapdragonem 845 mogą korzystać z EAS, a OnePlus 6 w pewnym stopniu to robi. Nie jest tak dostrojony jak urządzenie Google Pixel, ale spełnia swoje zadanie. Oto przykład tego, jak pomimo tego, że OnePlus 6 ma lepszy procesor z EAS, Pixel 2 XL nadal pobija go pod względem płynności. Obydwa zdjęcia pochodzą z naszego serwisu przegląd zorientowany na prędkość z OnePlusa 6.
Jeśli masz problemy ze zrozumieniem wykresów, możesz spojrzeć na poniższy obrazek, aby uzyskać wskazówki. Wszystko, co przekracza zieloną linię, oznacza utratę klatek i, w najgorszych przypadkach, zauważalne zacinanie się.
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. Dostrajanie harmonogramu również nie ma większego sensu, co prawdopodobnie wyjaśnia, dlaczego nie jest on tak wydajny, jak można by się spodziewać. Jest niezwykle konserwatywny pod względem zużycia energii, a system przez większość pracy priorytetowo traktuje rdzenie o niskim poborze mocy.
Elementy dostrajalne to po prostu zestaw parametrów przekazywanych do regulatora procesora, który zmienia sposób, w jaki regulator reaguje na określone sytuacje pod względem częstotliwości. Następnie osoba planująca decyduje, gdzie rozmieści zadania na różnych procesorach. Funkcje strojenia OnePlus 6 są ustawione tak, aby priorytetowo traktować pracę na rdzeniach o małej mocy. Nie pomaga również to, że Google Pixel 2 ma ogromne wzmocnienie wejściowe, utrzymując wszystkie 8 rdzeni przez cały czas w trybie online. Google używa również pliku moduł równoważenia przerwań co pomaga usunąć spadki klatek i poprawić wydajność.
Jak więc działa EAS? Dlaczego jest tak skuteczny tylko w określonych warunkach?
Energy Aware Scheduling wprowadza potrzebę stosowania modelu energetycznego i jak wspomniano powyżej, wymaga wielu testów i pracy, aby uczynić go idealnym. EAS próbuje ujednolicić trzy różne podstawowe części jądra, które działają niezależnie, a model energetyczny pomaga je ujednolicić.
- Harmonogram dla systemu Linux (CFS, wspomniany powyżej)
- Procesor Linux
- Częstotliwość procesora w systemie Linux
Ujednolicenie wszystkich 3 części w ramach harmonogramu i ich wspólne obliczenie daje potencjał w zakresie oszczędności energii, ponieważ ich wspólne obliczenie pozwala na uzyskanie maksymalnej wydajności. CPUIdle próbuje zdecydować, kiedy procesor powinien przejść w tryb bezczynności, podczas gdy CPUFreq próbuje zdecydować, kiedy zwiększyć lub zmniejszyć obciążenie procesora. Głównym celem obu modułów jest oszczędzanie energii. Co więcej, następnie kategoryzuje procesy na cztery grupy: najważniejsza aplikacja, tło systemu, pierwszy plan i tło. Zadania do wykonania umieszczane są w jednej z tych kategorii, następnie tej kategorii przydzielana jest moc procesora, a praca jest delegowana pomiędzy różne rdzenie procesora. top-app to najwyższy priorytet ukończenia, po którym następują pierwszy plan, tło i tło systemowe. Tło ma technicznie ten sam priorytet co tło systemu, ale tło systemu zwykle ma również dostęp do większej liczby małych rdzeni. W efekcie Energy Aware Scheduling łączy podstawowe części jądra Linuksa w jeden proces.
Budząc urządzenie, EAS wybierze rdzeń w najpłytszym stanie bezczynności, minimalizując energię potrzebną do wybudzenia urządzenia. Pomaga to zmniejszyć zapotrzebowanie na energię w użytkowaniu urządzenia, gdyż nie wybudzi ono 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. Do śledzenia obciążenia zwykle używa się „śledzenia obciążenia na jednostkę” (PELT). Informacje te są następnie wykorzystywane do decydowania o częstotliwościach i sposobie delegowania zadań pomiędzy procesorem. Można również zastosować funkcję „Śledzenie obciążenia wspomaganego oknem” (WALT), która jest stosowana w Google Pixel. Wiele ROM-ów 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 dynamiczny, z wysokimi szczytami częstotliwości procesora, podczas gdy PELT stara się zachować większą spójność. Moduł śledzenia obciążenia w rzeczywistości nie wpływa na częstotliwość procesora, po prostu informuje system o zużyciu procesora. Większe użycie procesora wymaga wyższej częstotliwości, dlatego stałą cechą PELT jest to, że powoduje powolny wzrost lub spadek częstotliwości procesora. PELT ma tendencję do raportowania wyższego obciążenia procesora, więc może zapewnić wyższą wydajność przy wyższym koszcie baterii. Jednak w tej chwili nikt nie może tak naprawdę powiedzieć, który system śledzenia ładunku jest lepszy, ponieważ obie metody śledzenia ładunku są stale łatane i udoskonalane.
Tak czy inaczej oczywiste jest, że niezależnie od zastosowanej metody śledzenia obciążenia, następuje wzrost wydajności. Zamiast po prostu przetwarzać zadania na dowolnym procesorze, zadanie jest analizowane i szacowana jest ilość energii potrzebnej do jego wykonania. To sprytne rozmieszczenie zadań oznacza, że zadania są wykonywane w znacznie bardziej efektywny sposób, a jednocześnie sprawia, że system jako całość jest szybszy. Celem EAS jest uzyskanie jak najpłynniejszego interfejsu użytkownika przy minimalnym zużyciu energii. Tutaj w grę wchodzą inne komponenty zewnętrzne, takie jak schedtune.
Schedtune jest definiowany w każdej grupie c przez dwie możliwości dostrajania, które zapewniają lepszą kontrolę nad zadaniami do wykonania. Kontroluje nie tylko rozłożenie zadań na wiele procesorów, ale także to, czy postrzegane obciążenie powinno zostać zawyżone, aby zapewnić szybsze wykonanie zadań wrażliwych na czas. W ten sposób aplikacje i usługi pierwszoplanowe, z których korzysta użytkownik, nie spowalniają i nie powodują niepotrzebnych problemów z wydajnością.
Chociaż planowanie uwzględniające zużycie energii to kolejna wielka rzecz, można również argumentować, że już istnieje i to już od jakiegoś czasu. Coraz więcej urządzeń trafia do głównego nurtu dzięki Energy Aware Scheduling, nadchodzi nowa era wydajności przetwarzania mobilnego.
Plusy i minusy metody round-robin, CFS, HMP i EAS
Chociaż moje umiejętności graficzne są kiepskie, stworzyłem obraz, który powinien podsumować zalety i wady każdego z tych programów planujących.
Chciałbym szczególnie podziękować Uznanemu Współtwórcy XDA Mostafa Wael którego wyjaśnienia różnych aspektów EAS znacznie pomogły w powstaniu tego artykułu. Chciałbym także podziękować XDA Recognized Developer wesoły, Uznany programista XDA Renderowanie uszkodzone I Mostafie Waelowi za artykuł na temat EAS. Dla tych z Was, którzy zainteresowali się częściami związanymi z EAS, Linaro ma wiele dokumentacji na temat EAS, którą można przeczytać.