Kapasitas adalah jumlah total sumber daya (CPU, GPU, dll.) yang dimiliki perangkat selama jangka waktu tertentu. Halaman ini menjelaskan cara mengidentifikasi dan mengatasi masalah jank terkait kapasitas.
Gubernur lambat bereaksi
Untuk menghindari jank, pengatur frekuensi CPU harus mampu merespons beban kerja yang melonjak dengan cepat. Sebagian besar aplikasi UI mengikuti pola dasar yang sama:
- Pengguna sedang membaca layar.
- Pengguna menyentuh layar: mengetuk tombol, menggulir, dll.
- Layar bergulir, mengubah aktivitas, atau menganimasikan dengan cara tertentu sebagai respons terhadap masukan.
- Sistem berhenti saat konten baru ditampilkan.
- Pengguna kembali membaca layar.
Perangkat Pixel dan Nexus menerapkan peningkatan sentuhan untuk mengubah perilaku pengatur frekuensi CPU (dan penjadwal) saat disentuh. Untuk menghindari peningkatan yang lambat ke frekuensi jam yang tinggi (yang dapat menyebabkan perangkat menjatuhkan frame saat disentuh), peningkatan sentuhan biasanya menetapkan batas bawah frekuensi pada CPU untuk memastikan banyak kapasitas CPU tersedia saat disentuh. Lantai 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 mendapat bobot tambahan melalui schedtune untuk memastikan aplikasi mendapatkan kapasitas CPU yang cukup untuk berjalan dengan cepat. Nexus 5X dan 6P memiliki kesenjangan kinerja yang jauh lebih besar antara cluster CPU kecil dan besar (masing-masing A53 dan A57) dibandingkan Pixel dengan CPU Kryo. Kami menemukan bahwa cluster CPU yang kecil tidak selalu memadai untuk rendering UI yang mulus, terutama mengingat sumber jitter lain pada perangkat.
Oleh karena itu, pada Nexus 5X dan 6P, peningkatan sentuhan mengubah perilaku penjadwal agar aplikasi latar depan lebih mungkin berpindah ke inti besar (ini secara konseptual mirip dengan batas frekuensi CPU). Tanpa perubahan penjadwal untuk membuat aplikasi latar depan lebih mungkin dipindahkan ke cluster CPU yang besar, aplikasi latar depan mungkin tidak memiliki kapasitas CPU yang cukup untuk dirender hingga penjadwal memutuskan untuk menyeimbangkan beban thread ke inti CPU yang besar. Dengan mengubah perilaku penjadwal selama peningkatan sentuhan, thread UI akan lebih mungkin untuk segera berjalan pada inti yang besar dan menghindari jank tanpa memaksanya untuk selalu berjalan pada inti yang besar, yang dapat berdampak buruk pada konsumsi daya.
Pelambatan termal
Pelambatan termal terjadi ketika perangkat harus mengurangi output termal keseluruhannya, biasanya dilakukan dengan mengurangi jam CPU, GPU, dan DRAM. Tidak mengherankan, hal ini sering kali mengakibatkan jank karena sistem mungkin tidak lagi mampu menyediakan kapasitas yang cukup untuk merender dalam jangka waktu tertentu. Satu-satunya cara untuk menghindari pelambatan termal adalah dengan menggunakan lebih sedikit daya. Tidak banyak cara untuk melakukan hal ini, namun berdasarkan pengalaman kami dengan SOC sebelumnya, kami memiliki beberapa rekomendasi untuk vendor sistem.
Pertama, ketika membangun SOC baru dengan arsitektur CPU heterogen, pastikan kurva kinerja/W cluster CPU tumpang tindih. Kurva kinerja/W keseluruhan untuk seluruh prosesor harus berupa garis yang berkesinambungan. Diskontinuitas dalam kurva kinerja/W memaksa penjadwal dan pengatur frekuensi menebak apa yang dibutuhkan beban kerja; untuk mencegah jank, penjadwal dan pengatur frekuensi melakukan kesalahan dengan memberikan kapasitas beban kerja lebih besar dari yang dibutuhkan. Hal ini mengakibatkan konsumsi daya terlalu besar, sehingga berkontribusi terhadap pelambatan termal.
Bayangkan sebuah SOC hipotetis dengan dua cluster CPU:
- Cluster 1, cluster kecil, dapat menghabiskan antara 100-300mW dan mendapat skor 100-300 dalam benchmark throughput tergantung pada jam.
- Cluster 2, cluster besar, dapat menghabiskan antara 1000 dan 1600mW dan mendapat skor antara 800 dan 1200 dalam tolok ukur throughput yang sama tergantung pada jamnya.
Dalam benchmark ini, skor yang lebih tinggi akan lebih cepat. Meskipun tidak lebih diinginkan daripada lebih lambat, lebih cepat == konsumsi daya lebih besar.
Jika penjadwal yakin bahwa beban kerja UI akan memerlukan skor yang setara dengan 310 pada tolok ukur throughput tersebut, opsi terbaiknya untuk menghindari jank adalah dengan menjalankan cluster besar pada frekuensi terendah, sehingga membuang-buang daya secara signifikan. (Hal ini bergantung pada perilaku cpuidle dan balapan ke idle; SOC dengan kurva kinerja/W berkelanjutan lebih mudah untuk dioptimalkan.)
Kedua, gunakan CPUset. Pastikan Anda telah mengaktifkan cpusets di kernel dan BoardConfig.mk Anda. Anda juga harus menyiapkan penetapan cpuset sebenarnya di init.rc khusus perangkat Anda. Beberapa vendor membiarkan ini dinonaktifkan di BSP mereka dengan harapan mereka dapat menggunakan petunjuk lain untuk mempengaruhi perilaku penjadwal; kami merasa ini tidak masuk akal. cpusets berguna untuk memastikan penyeimbangan beban antar CPU dilakukan dengan cara yang mencerminkan apa yang sebenarnya dilakukan pengguna pada perangkat.
ActivityManager menugaskan aplikasi ke kumpulan cpu berbeda berdasarkan kepentingan relatif aplikasi tersebut (atas, latar depan, latar belakang), dengan aplikasi yang lebih penting mendapatkan lebih banyak akses ke inti CPU. Hal ini membantu memastikan kualitas layanan untuk aplikasi latar depan dan teratas.
cpusets berguna pada konfigurasi CPU yang homogen, namun Anda tidak boleh mengirimkan perangkat dengan konfigurasi CPU heterogen tanpa cpusets diaktifkan. Nexus 6P adalah model yang bagus tentang cara menggunakan cpuset pada konfigurasi CPU heterogen; gunakan itu sebagai dasar untuk konfigurasi perangkat Anda sendiri.
cpuset juga menawarkan keunggulan daya dengan memastikan thread latar belakang yang tidak terlalu penting bagi kinerja tidak pernah mendapatkan beban yang seimbang ke inti CPU yang besar, sehingga dapat menghabiskan lebih banyak daya secara signifikan tanpa manfaat apa pun yang dirasakan pengguna. Hal ini juga dapat membantu menghindari pelambatan termal. Meskipun pembatasan termal adalah masalah kapasitas, peningkatan jitter memiliki dampak yang sangat besar pada kinerja UI saat pembatasan termal. Karena sistem akan berjalan mendekati kemampuannya untuk merender 60FPS, dibutuhkan lebih sedikit jitter untuk menyebabkan frame terjatuh.