Kapasitas adalah jumlah total beberapa resource (CPU, GPU, dll.) yang dimiliki perangkat selama jangka waktu tertentu. Halaman ini menjelaskan cara mengidentifikasi dan mengatasi masalah jank terkait kapasitas.
Governor lambat merespons
Untuk menghindari jank, pengontrol frekuensi CPU harus dapat merespons dengan cepat ke workload yang berfluktuasi. Sebagian besar aplikasi UI mengikuti pola dasar yang sama:
- Pengguna sedang membaca layar.
- Pengguna menyentuh layar: mengetuk tombol, men-scroll, dll.
- Layar men-scroll, mengubah aktivitas, atau menganimasikan dengan cara tertentu sebagai respons terhadap input.
- Sistem akan berhenti beroperasi saat konten baru ditampilkan.
- Pengguna kembali membaca layar.
Perangkat Pixel dan Nexus menerapkan peningkatan sentuhan untuk mengubah perilaku pengontrol (dan penjadwal) frekuensi CPU saat disentuh. Untuk menghindari peningkatan lambat ke frekuensi clock yang tinggi (yang dapat menyebabkan perangkat kehilangan frame saat disentuh), peningkatan sentuhan biasanya menetapkan nilai minimum frekuensi pada CPU untuk memastikan banyak kapasitas CPU tersedia saat disentuh. Lantai akan bertahan selama beberapa waktu setelah disentuh (biasanya sekitar dua detik).
Pixel juga menggunakan cgroup schedtune yang disediakan oleh Energy Aware Scheduling (EAS) sebagai sinyal peningkatan sentuhan tambahan: Aplikasi teratas mendapatkan bobot tambahan melalui schedtune untuk memastikan aplikasi tersebut mendapatkan kapasitas CPU yang cukup untuk berjalan dengan cepat. Nexus 5X dan 6P memiliki kesenjangan performa yang jauh lebih besar antara cluster CPU kecil dan besar (masing-masing A53 dan A57) daripada Pixel dengan CPU Kryo. Kami mendapati bahwa cluster CPU kecil tidak selalu memadai untuk rendering UI yang lancar, terutama mengingat sumber jitter lainnya di perangkat.
Oleh karena itu, di Nexus 5X dan 6P, peningkatan sentuhan mengubah perilaku penjadwal untuk meningkatkan kemungkinan aplikasi latar depan berpindah ke core besar (secara konseptual mirip dengan nilai minimum pada frekuensi CPU). Tanpa perubahan penjadwal untuk membuat aplikasi latar depan lebih cenderung berpindah ke cluster CPU besar, aplikasi latar depan mungkin tidak memiliki kapasitas CPU yang memadai untuk merender hingga penjadwal memutuskan untuk melakukan load balancing thread ke core CPU besar. Dengan mengubah perilaku penjadwal selama peningkatan sentuhan, thread UI lebih cenderung langsung berjalan di core besar dan menghindari jank tanpa memaksanya untuk selalu berjalan di core besar, yang dapat berdampak parah pada konsumsi daya.
Throttling termal
Throttling termal terjadi saat perangkat harus mengurangi output termal keseluruhannya, biasanya dilakukan dengan mengurangi clock CPU, GPU, dan DRAM. Tidak mengherankan, hal ini sering kali menyebabkan jank karena sistem mungkin tidak dapat lagi menyediakan kapasitas yang cukup untuk merender dalam jangka waktu tertentu. Satu-satunya cara untuk menghindari throttling termal adalah dengan menggunakan lebih sedikit daya. Tidak banyak cara untuk melakukannya, tetapi berdasarkan pengalaman kami dengan SOC sebelumnya, kami memiliki beberapa rekomendasi untuk vendor sistem.
Pertama, saat mem-build SOC baru dengan arsitektur CPU heterogen, pastikan kurva performa/W cluster CPU tumpang-tindih. Kurva performa/W keseluruhan untuk seluruh prosesor harus berupa garis yang berkelanjutan. Diskontinuitas dalam kurva perf/W memaksa penjadwal dan pengontrol frekuensi untuk menebak kebutuhan workload; untuk mencegah jank, penjadwal dan pengontrol frekuensi akan memberikan lebih banyak kapasitas kepada workload daripada yang diperlukan. Hal ini menyebabkan penggunaan daya yang terlalu banyak, yang berkontribusi pada throttling termal.
Bayangkan SOC hipotetis dengan dua cluster CPU:
- Cluster 1, cluster kecil, dapat menghabiskan antara 100-300 mW dan skornya 100-300 dalam benchmark throughput, bergantung pada clock.
- Cluster 2, cluster besar, dapat menghabiskan antara 1.000 dan 1.600 mW dan skornya antara 800 dan 1.200 dalam benchmark throughput yang sama, bergantung pada clock.
Dalam benchmark ini, skor yang lebih tinggi lebih cepat. Meskipun tidak lebih diinginkan daripada lebih lambat, lebih cepat == konsumsi daya yang lebih besar.
Jika penjadwal yakin bahwa beban kerja UI akan memerlukan skor setara dengan 310 pada benchmark throughput tersebut, opsi terbaiknya untuk menghindari jank adalah menjalankan cluster besar pada frekuensi terendah, sehingga membuang daya yang signifikan. (Hal ini bergantung pada perilaku cpuidle dan race to idle; SOC dengan kurva perf/W berkelanjutan lebih mudah dioptimalkan.)
Kedua, gunakan cpuset. Pastikan Anda telah mengaktifkan cpuset di kernel dan di
BoardConfig.mk. Anda juga harus menyiapkan penetapan cpuset
yang sebenarnya di init.rc khusus perangkat. Beberapa vendor membiarkan
hal ini dinonaktifkan di BSP mereka dengan harapan mereka dapat menggunakan petunjuk lain untuk memengaruhi
perilaku penjadwal; kami merasa hal ini tidak masuk akal. cpuset berguna untuk
memastikan load balancing antara CPU dilakukan dengan cara yang mencerminkan apa
yang sebenarnya dilakukan pengguna di perangkat.
ActivityManager menetapkan aplikasi ke cpuset yang berbeda berdasarkan kepentingan relatif aplikasi tersebut (atas, latar depan, latar belakang), dengan aplikasi yang lebih penting mendapatkan lebih banyak akses ke core CPU. Hal ini membantu memastikan kualitas layanan untuk aplikasi latar depan dan teratas.
cpuset berguna pada konfigurasi CPU homogen, tetapi Anda tidak boleh mengirimkan perangkat dengan konfigurasi CPU heterogen tanpa mengaktifkan cpuset. Nexus 6P adalah model yang baik untuk cara menggunakan cpuset pada konfigurasi CPU heterogen; gunakan sebagai dasar untuk konfigurasi perangkat Anda sendiri.
cpuset juga menawarkan keunggulan daya dengan memastikan thread latar belakang yang tidak penting bagi performa tidak pernah mendapatkan load balancing ke core CPU besar, tempat thread tersebut dapat menghabiskan daya secara signifikan tanpa manfaat yang dirasakan pengguna. Hal ini juga dapat membantu menghindari throttling termal. Meskipun throttling termal adalah masalah kapasitas, peningkatan jitter memiliki dampak yang besar pada performa UI saat throttling termal. Karena sistem akan berjalan lebih dekat dengan kemampuannya untuk merender 60 FPS, diperlukan lebih sedikit jitter untuk menyebabkan frame yang terputus.