Kapasitas adalah jumlah total dari beberapa sumber daya (CPU, GPU, dll.) yang dimiliki perangkat selama beberapa waktu. Halaman ini menjelaskan cara mengidentifikasi dan mengatasi masalah jank terkait kapasitas.
Gubernur lambat bereaksi
Untuk menghindari jank, pengatur frekuensi CPU harus dapat merespons beban kerja yang meledak dengan cepat. Sebagian besar aplikasi UI mengikuti pola dasar yang sama:
- Pengguna sedang membaca layar.
- Pengguna menyentuh layar: mengetuk tombol, menggulir, dll.
- Menggulir layar, mengubah aktivitas, atau menganimasikan dengan cara tertentu sebagai respons terhadap masukan.
- Sistem diam saat konten baru ditampilkan.
- Pengguna kembali membaca layar.
Perangkat Pixel dan Nexus menerapkan peningkatan sentuh untuk mengubah perilaku pengatur frekuensi (dan penjadwal) CPU saat disentuh. Untuk menghindari ramp lambat ke frekuensi clock tinggi (yang dapat menyebabkan perangkat menjatuhkan frame saat disentuh), peningkatan sentuh biasanya menetapkan dasar 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 schedtune cgroup yang disediakan oleh Energy Aware Scheduling (EAS) sebagai sinyal peningkatan sentuhan tambahan: Aplikasi teratas mendapatkan bobot tambahan melalui schedtune untuk memastikan mereka 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) daripada Pixel dengan CPU Kryo. Kami menemukan bahwa kluster CPU 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 sentuh memodifikasi perilaku penjadwal agar lebih memungkinkan aplikasi latar depan untuk pindah ke inti besar (ini secara konseptual mirip dengan frekuensi dasar pada CPU). Tanpa perubahan penjadwal untuk membuat aplikasi latar depan lebih mungkin untuk pindah ke kluster CPU besar, aplikasi latar depan mungkin memiliki kapasitas CPU yang tidak mencukupi untuk dirender hingga penjadwal memutuskan untuk memuat keseimbangan utas ke inti CPU yang besar. Dengan mengubah perilaku penjadwal selama peningkatan sentuh, kemungkinan besar utas UI akan segera berjalan pada inti besar dan menghindari jank tanpa memaksanya untuk selalu berjalan pada inti besar, yang dapat berdampak parah pada konsumsi daya.
Pelambatan termal
Throttling termal terjadi ketika perangkat harus mengurangi output termal secara keseluruhan, biasanya dilakukan dengan mengurangi jam CPU, GPU, dan DRAM. Tidak mengherankan, ini sering mengakibatkan jank karena sistem mungkin tidak lagi dapat menyediakan kapasitas yang cukup untuk merender dalam timelice tertentu. Satu-satunya cara untuk menghindari pelambatan termal adalah dengan menggunakan lebih sedikit daya. Tidak banyak cara untuk melakukan ini, tetapi berdasarkan pengalaman kami dengan SOC sebelumnya, kami memiliki beberapa rekomendasi untuk vendor sistem.
Pertama, saat membangun SOC baru dengan arsitektur CPU yang heterogen, pastikan kurva kinerja/W dari cluster CPU saling tumpang tindih. Kurva kinerja/W keseluruhan untuk seluruh prosesor harus berupa garis kontinu. Diskontinuitas dalam kurva perf/W memaksa penjadwal dan pengatur frekuensi untuk menebak apa yang dibutuhkan beban kerja; untuk mencegah jank, penjadwal dan pengatur frekuensi berbuat salah di sisi memberikan beban kerja kapasitas lebih dari yang dibutuhkan. Ini menghasilkan terlalu banyak daya, yang berkontribusi pada pelambatan termal.
Bayangkan SOC hipotetis dengan dua cluster CPU:
- Cluster 1, cluster kecil, dapat menghabiskan antara 100-300mW dan skor 100-300 dalam benchmark throughput tergantung pada jam.
- Cluster 2, cluster besar, dapat menghabiskan antara 1000 dan 1600mW dan skor antara 800 dan 1200 dalam benchmark throughput yang sama tergantung pada jam.
Dalam benchmark ini, skor yang lebih tinggi lebih cepat. Meskipun tidak lebih diinginkan daripada yang lebih lambat, lebih cepat == konsumsi daya yang 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 menjalankan cluster besar pada frekuensi terendah, membuang daya yang signifikan. (Ini tergantung pada perilaku cpuidle dan berlomba ke idle; SOC dengan kurva perf/W berkelanjutan lebih mudah untuk dioptimalkan.)
Kedua, gunakan cpuset. Pastikan Anda telah mengaktifkan cpuset di kernel Anda dan di BoardConfig.mk Anda. Anda juga harus mengatur penetapan cpuset yang sebenarnya di init.rc khusus perangkat Anda. Beberapa vendor membiarkan ini dinonaktifkan di BSP mereka dengan harapan mereka dapat menggunakan petunjuk lain untuk memengaruhi perilaku penjadwal; kami merasa ini tidak masuk akal. cpuset berguna untuk memastikan penyeimbangan beban antar CPU dilakukan dengan cara yang mencerminkan apa yang sebenarnya dilakukan pengguna di perangkat.
ActivityManager menetapkan aplikasi ke cpuset yang berbeda berdasarkan kepentingan relatif dari aplikasi tersebut (atas, latar depan, latar belakang), dengan aplikasi yang lebih penting mendapatkan lebih banyak akses ke inti CPU. Ini membantu memastikan kualitas layanan untuk aplikasi latar depan dan teratas.
cpuset berguna pada konfigurasi CPU yang homogen, tetapi Anda tidak boleh mengirimkan perangkat dengan konfigurasi CPU yang heterogen tanpa mengaktifkan cpuset. Nexus 6P adalah model yang baik untuk cara menggunakan cpuset pada konfigurasi CPU yang heterogen; gunakan itu sebagai dasar untuk konfigurasi perangkat Anda sendiri.
cpuset juga menawarkan keunggulan daya dengan memastikan utas latar belakang yang tidak kritis terhadap kinerja tidak pernah mendapatkan beban seimbang ke inti CPU besar, di mana mereka dapat menghabiskan lebih banyak daya secara signifikan tanpa manfaat yang dirasakan pengguna. Ini dapat membantu menghindari pelambatan termal juga. Sementara pelambatan termal adalah masalah kapasitas, peningkatan jitter berdampak besar pada kinerja UI saat pelambatan termal. Karena sistem akan berjalan mendekati kemampuannya untuk merender 60FPS, dibutuhkan lebih sedikit jitter untuk menyebabkan bingkai terjatuh.