Pojemność to całkowita ilość niektórych zasobów (CPU, GPU itp.), które urządzenie posiada przez pewien czas. Na tej stronie opisano, jak identyfikować i rozwiązywać problemy związane z pojemnością.
Gubernator powoli reaguje
Aby uniknąć szarpnięć, regulator częstotliwości procesora musi być w stanie szybko reagować na duże obciążenia. Większość aplikacji interfejsu użytkownika ma ten sam podstawowy wzór:
- Użytkownik czyta ekran.
- Użytkownik dotyka ekranu: dotyka przycisku, przewija itp.
- Ekran przewija się, zmienia aktywność lub w jakiś sposób animuje w odpowiedzi na wprowadzane dane.
- System zawiesza się po wyświetleniu nowej zawartości.
- Użytkownik wraca do czytania ekranu.
Urządzenia Pixel i Nexus wykorzystują funkcję Touch Boost, aby modyfikować zachowanie regulatora częstotliwości procesora (i harmonogramu) pod wpływem dotyku. Aby uniknąć powolnego przyspieszania do wysokiej częstotliwości zegara (co mogłoby spowodować utratę klatek przez urządzenie przy dotknięciu), wzmocnienie dotykowe zwykle ustawia minimalną częstotliwość procesora, aby zapewnić dostępność dużej mocy procesora przy dotyku. Podłoga utrzymuje się przez pewien czas po dotknięciu (zwykle około dwóch sekund).
Pixel wykorzystuje także grupę schedtune udostępnianą przez Energy Aware Scheduling (EAS) jako dodatkowy sygnał wzmocnienia dotyku: najlepsze aplikacje zyskują dodatkowe obciążenie dzięki schedtune, aby zapewnić im wystarczającą moc procesora do szybkiego działania. Nexus 5X i 6P mają znacznie większą różnicę w wydajności pomiędzy małym i dużym klastrem procesorów (odpowiednio A53 i A57) niż Pixel z procesorem Kryo. Odkryliśmy, że mały klaster procesora nie zawsze był odpowiedni do płynnego renderowania interfejsu użytkownika, zwłaszcza biorąc pod uwagę inne źródła drgań na urządzeniu.
Odpowiednio w Nexusie 5X i 6P funkcja touch boost modyfikuje zachowanie programu planującego, zwiększając prawdopodobieństwo, że aplikacje działające na pierwszym planie przeniosą się do dużych rdzeni (jest to koncepcyjnie podobne do minimalnej częstotliwości procesora). Bez zmiany harmonogramu, która sprawi, że aplikacje działające na pierwszym planie będą bardziej skłonne do przenoszenia się do dużego klastra procesora, aplikacje na pierwszym planie mogą mieć niewystarczającą moc procesora do renderowania, dopóki program planujący nie zdecyduje się zrównoważyć obciążenia wątku z dużym rdzeniem procesora. Zmieniając zachowanie programu planującego podczas przyspieszania dotykowego, jest bardziej prawdopodobne, że wątek interfejsu użytkownika będzie natychmiast uruchamiany na dużym rdzeniu i unika Janck, nie zmuszając go do ciągłego działania na dużym rdzeniu, co mogłoby mieć poważny wpływ na zużycie energii.
Dławienie termiczne
Dławienie termiczne ma miejsce, gdy urządzenie musi zmniejszyć ogólną moc cieplną, co zwykle odbywa się poprzez zmniejszenie zegarów procesora, karty graficznej i pamięci DRAM. Nic dziwnego, że często powoduje to szarpnięcie, ponieważ system może nie być już w stanie zapewnić wystarczającej pojemności do renderowania w danym przedziale czasu. Jedynym sposobem uniknięcia dławienia termicznego jest zmniejszenie zużycia energii. Nie ma wielu sposobów, aby to zrobić, ale w oparciu o nasze doświadczenia z poprzednimi SOC, mamy kilka zaleceń dla dostawców systemów.
Po pierwsze, budując nowy SOC z heterogeniczną architekturą procesorów, upewnij się, że krzywe wydajności/W klastrów procesorów nakładają się. Ogólna krzywa wydajności/W dla całego procesora powinna być linią ciągłą. Nieciągłości na krzywej wydajności/W zmuszają planistę i regulatora częstotliwości do odgadnięcia, czego potrzebuje obciążenie; aby zapobiec szarpnięciu, planista i regulator częstotliwości popełniają błąd, przyznając obciążeniu większą pojemność, niż jest to wymagane. Powoduje to zużycie zbyt dużej ilości energii, co przyczynia się do dławienia termicznego.
Wyobraź sobie hipotetyczny SOC z dwoma klastrami procesorów:
- Klaster 1, mały klaster, może wydać od 100 do 300 mW i osiągać 100–300 punktów w teście przepustowości, w zależności od zegarów.
- Klaster 2, duży klaster, może wydawać od 1000 do 1600 mW i osiągać wyniki od 800 do 1200 w tym samym teście wydajności, w zależności od zegarów.
W tym teście wyższy wynik oznacza szybszy wynik. Chociaż nie jest to bardziej pożądane niż wolniejsze, szybsze == większe zużycie energii.
Jeśli osoba planująca uważa, że obciążenie interfejsu użytkownika wymagałoby wyniku równego 310 w tym teście porównawczym przepustowości, najlepszą opcją uniknięcia szarpania jest uruchomienie dużego klastra z najniższą częstotliwością, marnując znaczną ilość energii. (Zależy to od zachowania procesora i wyścigu do stanu bezczynności; łatwiej jest zoptymalizować SOC z ciągłymi krzywymi wydajności/W.)
Po drugie, użyj zestawów procesorów. Upewnij się, że włączyłeś zestawy procesorów w jądrze i w pliku BoardConfig.mk . Musisz także skonfigurować faktyczne przypisania zestawu procesorów w pliku init.rc specyficznym dla urządzenia. Niektórzy dostawcy pozostawiają tę opcję wyłączoną w swoich BSP w nadziei, że będą mogli skorzystać z innych wskazówek, aby wpłynąć na zachowanie programu planującego; uważamy, że to nie ma sensu. cpusets są przydatne do zapewnienia równoważenia obciążenia pomiędzy procesorami w sposób odzwierciedlający to, co użytkownik faktycznie robi na urządzeniu.
ActivityManager przypisuje aplikacje do różnych zestawów procesorów na podstawie względnego znaczenia tych aplikacji (na górze, na pierwszym planie, w tle), przy czym ważniejsze aplikacje uzyskują większy dostęp do rdzeni procesora. Pomaga to zapewnić jakość usług dla aplikacji pierwszoplanowych i najlepszych.
zestawy procesorów są przydatne w jednorodnych konfiguracjach procesorów, ale nie należy wysyłać urządzenia z heterogeniczną konfiguracją procesora bez włączonej obsługi zestawów procesorów. Nexus 6P to dobry model wykorzystania zestawów procesorów w heterogenicznych konfiguracjach procesorów; użyj tego jako podstawy do konfiguracji własnego urządzenia.
Zestawy procesorów oferują również przewagę w zakresie zasilania, zapewniając, że wątki w tle, które nie są krytyczne dla wydajności, nigdy nie zostaną zrównoważone obciążeniem z dużymi rdzeniami procesora, gdzie mogłyby wydać znacznie więcej energii bez żadnych korzyści postrzeganych przez użytkownika. Może to również pomóc w uniknięciu dławienia termicznego. Chociaż dławienie termiczne jest problemem związanym z wydajnością, ulepszenia jittera mają ogromny wpływ na wydajność interfejsu użytkownika w przypadku dławienia termicznego. Ponieważ system będzie zbliżał się do swojej zdolności do renderowania 60 klatek na sekundę, potrzeba mniej drgań, aby spowodować utratę klatek.