Ponsel pintar Google Pixel adalah salah satu ponsel Android tercepat di pasaran. Penjadwalan Sadar Energi (EAS) adalah salah satu alasan mengapa ponsel ini begitu lancar.
Jauh di masa lalu ketika Linux hanyalah sebuah ide di benak Linus Torvalds, CPU adalah entitas inti tunggal yang membutuhkan energi dalam jumlah besar dengan daya yang kecil. Prosesor pertama yang tersedia secara komersial, Intel 4004, berjalan pada kecepatan clock 740kHz pada satu inti. Saat itu, penjadwal beban tidak diperlukan. Penjadwalan beban dicadangkan untuk "raksasa" dual-core seperti IBM Power 4 yang keluar beberapa dekade setelahnya. Ini berjalan pada kecepatan 1,1GHz hingga 1,9GHz dan memerlukan program dan sistem untuk menggunakan inti ini dengan benar. Bagaimana kita beralih dari mesin ini ke algoritma perangkat lunak yang menggunakan banyak inti? Anda mungkin pernah mendengar tentang Penjadwalan Sadar Energi (EAS) di forum kami sebelumnya. Itu salah satu alasan mengapa ponsel pintar Google Pixel berkinerja sangat baik. Apa hebatnya EAS dan bagaimana kita bisa mencapai titik ini? Sebelum kami menjelaskannya, kita perlu membicarakan tentang penjadwal beban Linux.
Evolusi Penjadwal Beban Linux
Penjadwalan Round-Robin
Pemrosesan round robin adalah konsep yang sederhana untuk dijelaskan dan dipahami, dan bahkan lebih sederhana lagi untuk memahami kelemahannya. Round-robin menggunakan pemotongan waktu untuk mengalokasikan waktu pada setiap proses. Anggaplah kita memiliki empat proses yang berjalan di komputer kita.
- Proses A
- Proses B
- ProsesC
- Proses D
Sekarang, mari kita lakukan tugas penjadwal round-robin. Kami akan mengalokasikan 100 milidetik (pengirisan waktu) untuk setiap proses sebelum melanjutkan ke proses berikutnya. Artinya Proses A membutuhkan waktu 100 milidetik untuk melakukan pemrosesannya, kemudian berpindah ke Proses B dan seterusnya. Jika suatu pekerjaan membutuhkan waktu 250 milidetik untuk diselesaikan, aplikasi tersebut harus melalui proses ini sebanyak 3 kali hanya untuk menyelesaikan pekerjaannya! Sekarang skalakan ini ke seluruh inti yang berbeda, sehingga Proses A dan Proses B dialokasikan ke inti 1, dan Proses C serta Proses D dialokasikan ke inti 2. Ini digantikan oleh penjadwalan O(n) (yang seperti round-robin, tetapi menggunakan zaman dan memungkinkan alokasi dinamis waktu), kemudian penjadwalan O(1) (overhead yang diminimalkan, dukungan proses yang tidak terbatas), dan terakhir Penjadwal yang Sepenuhnya Adil (CFS). CFS digabungkan ke dalam kernel Linux versi 2.6.23 pada bulan Oktober 2007. Ini telah dirombak sejak itu dan masih menjadi penjadwal default di sistem Linux.
Penjadwal yang Sepenuhnya Adil
Penjadwal yang Sepenuhnya Adil telah ada di Android sejak awal dan digunakan pada perangkat non-besar. Perangkat KECIL. Ia menggunakan algoritma cerdas untuk menentukan urutan pemrosesan, alokasi waktu, dll. Ini adalah contoh implementasi kerja dari algoritma penjadwalan yang telah dipelajari dengan baik yang disebut "antrian adil berbobot". Ini pada dasarnya berfokus pada pemberian prioritas pada proses sistem dan proses berprioritas tinggi lainnya yang berjalan di mesin. Jika itu ingin dijalankan secara besar-besaran. Perangkat KECIL, semua inti akan dianggap setara. Ini buruk, karena inti berdaya rendah mungkin terpaksa menjalankan aplikasi intensif, atau lebih buruk lagi, hal sebaliknya mungkin terjadi. Penguraian kode untuk mendengarkan musik dapat dilakukan pada inti yang besar, misalnya, meningkatkan konsumsi daya secara sia-sia. Inilah sebabnya mengapa kita membutuhkan penjadwal baru secara besar-besaran. LITTLE, yang benar-benar dapat mengenali dan memanfaatkan perbedaan inti dengan cara yang hemat daya. Di sinilah Heterogeneous Multi-Processing (HMP) berperan, penjadwal beban standar yang dijalankan sebagian besar ponsel Android saat ini.
Multi-Pemrosesan Heterogen
Ini adalah penjadwal beban standar untuk semua ukuran besar. Perangkat KECIL dirilis dalam beberapa tahun terakhir, selain Google Pixel. HMP memanfaatkan yang besar. Arsitektur LITTLE, mendelegasikan pekerjaan berprioritas rendah dan kurang intensif ke inti kecil yang mengonsumsi lebih sedikit daya. HMP bersifat "aman" karena ia mengetahui apa yang harus masuk ke inti besar dan apa yang harus masuk ke inti kecil, tanpa membuat kesalahan. Ini hanya berfungsi dan membutuhkan lebih sedikit upaya untuk menyiapkan sisi pengembangan dibandingkan sesuatu seperti EAS, yang akan kita bahas sebentar lagi. HMP hanyalah perpanjangan dari CFS untuk menjadikannya sadar daya.
HMP tidak menebak-nebak, juga tidak memprediksi proses di masa depan. Ini bagus, tetapi itulah sebabnya perangkat tidak bisa selancar perangkat yang menjalankan EAS dan juga mengapa perangkat ini mengonsumsi baterai sedikit lebih banyak. Hal ini, pada akhirnya, membawa kita pada Penjadwalan Sadar Energi (EAS), yang saya yakini merupakan masa depan dalam pengembangan ROM dan kernel karena semakin banyak OEM yang mengadopsinya.
Penjadwalan Sadar Energi
Penjadwalan Sadar Energi (EAS) adalah hal besar berikutnya yang dibicarakan oleh pengguna di forum kami. Jika Anda menggunakan OnePlus 3 (atau Google Pixel, tentunya) Anda pasti pernah mendengarnya di forum. Ini diluncurkan ke pasar mainstream dengan Qualcomm Snapdragon 845, jadi jika Anda memiliki salah satu perangkat ini, Anda sudah memiliki ponsel cerdas yang mendukung EAS. EAS dalam bentuk kernel seperti RenderZenith dan ROM seperti VertexOS Dan Fusi Murni mengambil alih forum OnePlus 3 pada masa puncaknya. Tentu saja Google Pixel juga hadir dengan EAS. Dengan janji peningkatan masa pakai baterai dan kinerja yang lebih baik, apa untungnya?
Penjadwalan Sadar Energi tidak sesederhana karena tidak bersifat universal untuk setiap perangkat seperti CFS atau HMP. EAS memerlukan pemahaman tentang prosesor yang dijalankannya, berdasarkan model energi. Model energi ini dibuat oleh tim insinyur yang terus menguji dan bekerja untuk memberikan kinerja optimal. Karena Snapdragon 820 dan 821 pada dasarnya sama, kernel khusus pada OnePlus 3 menggunakan model energi Google Pixel. Perangkat dengan Snapdragon 845 dapat menggunakan EAS, dan OnePlus 6 dapat memanfaatkannya sampai tingkat tertentu. Memang tidak sesempurna perangkat Google Pixel, namun berfungsi dengan baik. Berikut ini contoh bagaimana, meskipun OnePlus 6 memiliki prosesor yang lebih baik dengan EAS, Pixel 2 XL tetap mengunggulinya dalam hal kehalusan. Kedua gambar ini diambil dari kami ulasan berorientasi kecepatan dari OnePlus 6.
Jika Anda kesulitan memahami grafiknya, Anda dapat melihat gambar di bawah ini untuk panduannya. Apa pun yang melebihi garis hijau menunjukkan frame yang terjatuh dan, dalam kasus terburuk, terlihat tersendat-sendat.
Implementasi EAS di OnePlus 6 menarik, karena tampaknya ini bukan implementasi penuh seperti yang Anda temukan di Google Pixel dengan SoC yang sama. Tunable penjadwal juga tidak masuk akal, jadi itu mungkin menjelaskan mengapa kinerjanya tidak seefisien yang Anda harapkan. Konsumsi dayanya sangat konservatif, dengan sistem yang memprioritaskan inti berdaya rendah untuk sebagian besar pekerjaan.
Tunable hanyalah sekumpulan parameter yang diteruskan ke gubernur CPU, yang mengubah cara gubernur bereaksi terhadap situasi tertentu dalam hal frekuensi. Penjadwal kemudian memutuskan di mana ia menempatkan tugas pada prosesor yang berbeda. Tunable OnePlus 6 diatur untuk memprioritaskan pekerjaan pada core berdaya rendah. Juga tidak membantu bahwa Google Pixel 2 memiliki peningkatan input dalam jumlah besar, menjaga 8 core tetap online sepanjang waktu. Google juga menggunakan penyeimbang interupsi yang membantu menghilangkan penurunan bingkai dan meningkatkan kinerja.
Jadi bagaimana cara kerja EAS? Mengapa hanya efisien pada kondisi tertentu?
Penjadwalan Sadar Energi memperkenalkan perlunya penggunaan model energi, dan seperti disebutkan di atas memerlukan banyak pengujian dan upaya untuk menyempurnakannya. EAS berupaya untuk menyatukan tiga bagian inti berbeda dari kernel yang semuanya bertindak secara independen, dan model energi membantu menyatukannya.
- Penjadwal Linux (CFS, disebutkan di atas)
- CPU Linux
- frekuensi cpu Linux
Menyatukan ketiga bagian di bawah penjadwal dan menghitungnya bersama-sama memberikan potensi penghematan energi, karena menghitungnya bersama-sama memungkinkannya menjadi seefisien mungkin. CPUIdle mencoba memutuskan kapan CPU harus masuk ke mode siaga, sementara CPUFreq mencoba memutuskan kapan harus meningkatkan atau menurunkan CPU. Kedua modul ini mempunyai tujuan utama yaitu penghematan energi. Tidak hanya itu, ia kemudian mengkategorikan proses ke dalam empat kelompok, yaitu aplikasi teratas, latar belakang sistem, latar depan, dan latar belakang. Tugas yang harus diproses ditempatkan ke dalam salah satu kategori ini, dan kemudian kategori tersebut diberikan daya CPU dan pekerjaan didelegasikan ke inti CPU yang berbeda. aplikasi teratas adalah prioritas penyelesaian tertinggi, diikuti oleh latar depan, latar belakang, dan kemudian latar belakang sistem. Latar belakang secara teknis memiliki prioritas yang sama dengan latar belakang sistem, tetapi latar belakang sistem biasanya juga memiliki akses ke inti yang lebih kecil. Akibatnya, Penjadwalan Sadar Energi mengambil bagian inti dari kernel Linux dan menyatukan semuanya menjadi satu proses.
Saat membangunkan perangkat, EAS akan memilih inti dalam kondisi idle paling dangkal, sehingga meminimalkan energi yang diperlukan untuk membangunkan perangkat. Hal ini membantu mengurangi daya yang diperlukan dalam penggunaan perangkat, karena perangkat tidak akan membangunkan cluster besar jika tidak diperlukan. Pelacakan beban juga merupakan bagian yang sangat penting dari EAS, dan ada dua opsi. "Pelacakan Beban Per-Entitas" (PELT) biasanya digunakan untuk pelacakan beban, informasi tersebut kemudian digunakan untuk menentukan frekuensi dan cara mendelegasikan tugas di seluruh CPU. "Pelacakan Beban Berbantuan Jendela" (WALT) juga dapat digunakan dan digunakan di Google Pixel. Banyak ROM EAS di forum kami, seperti VertexOS, memilih untuk menggunakan WALT. Banyak ROM yang merilis dua versi kernel dengan WALT atau PELT, jadi terserah pada pengguna untuk memutuskan. WALT lebih bursty, dengan puncak frekuensi CPU yang tinggi sementara PELT mencoba untuk tetap lebih konsisten. Pelacak beban sebenarnya tidak memengaruhi frekuensi CPU, ia hanya memberi tahu sistem berapa penggunaan CPU. Penggunaan CPU yang lebih tinggi memerlukan frekuensi yang lebih tinggi sehingga sifat PELT yang konsisten adalah menyebabkan frekuensi CPU naik atau turun secara perlahan. PELT cenderung menyimpang ke arah pelaporan beban CPU yang lebih tinggi, sehingga PELT mungkin memberikan kinerja lebih tinggi dengan biaya baterai lebih tinggi. Namun, tidak ada yang benar-benar dapat mengatakan pada saat ini sistem pelacakan beban mana yang lebih baik, karena kedua metode pelacakan beban tersebut terus ditambal dan disempurnakan.
Apa pun yang terjadi, jelas bahwa, apa pun metode pelacakan beban yang digunakan, terdapat peningkatan efisiensi. Daripada hanya memproses tugas pada prosesor apa pun, tugas tersebut dianalisis dan jumlah energi yang diperlukan untuk menjalankannya diperkirakan. Penempatan tugas yang cerdas ini berarti tugas diselesaikan dengan cara yang jauh lebih efisien sekaligus membuat sistem lebih cepat secara keseluruhan. EAS adalah tentang mendapatkan UI sehalus mungkin dengan penggunaan daya minimal. Di sinilah komponen eksternal lainnya seperti schedtune ikut berperan.
Jadwal ditentukan di setiap cgroup oleh dua merdu yang memastikan kontrol yang lebih baik atas tugas yang harus diselesaikan. Ini tidak hanya mengontrol penyebaran tugas pada beberapa CPU, tetapi juga apakah beban yang dirasakan harus ditingkatkan untuk memastikan tugas-tugas yang sensitif terhadap waktu diselesaikan lebih cepat. Dengan cara ini, aplikasi dan layanan latar depan yang digunakan pengguna tidak akan melambat dan menyebabkan masalah kinerja yang tidak perlu.
Meskipun Penjadwalan Sadar Energi adalah hal besar berikutnya, dapat dikatakan bahwa hal ini sudah ada dan sudah berlangsung cukup lama. Dengan semakin banyaknya perangkat yang menggunakan Penjadwalan Sadar Energi, era baru efisiensi pemrosesan seluler telah tiba.
Kelebihan dan Kekurangan Round-Robin, CFS, HMP dan EAS
Meskipun kemampuan grafis saya di bawah standar, saya telah menyusun sebuah gambar yang merangkum pro dan kontra dari masing-masing penjadwal ini.
Saya ingin menyampaikan terima kasih khusus kepada Kontributor yang Diakui XDA Mustafa Wael yang penjelasannya tentang berbagai aspek EAS sangat membantu terwujudnya artikel ini. Saya juga ingin mengucapkan terima kasih kepada Pengembang yang Diakui XDA joshuous, Pengembang yang Diakui XDA Render Rusak Dan Mostafa Wael atas tulisannya di EAS. Bagi Anda yang tertarik dengan bagian-bagian terkait EAS, Linaro memiliki banyak dokumentasi tentang EAS yang dapat Anda baca.