Android menambahkan ukuran halaman 16 KB

• Halaman adalah unit minimum yang digunakan sistem operasi untuk mengelola memori
• Sebagian besar CPU mendukung ukuran halaman 4 KB, dan Android OS serta aplikasi telah dioptimalkan untuk ukuran halaman 4 KB
• CPU ARM mendukung ukuran halaman 16 KB, dan saat Android menggunakan ukuran ini, performa meningkat 5-10% sementara penggunaan memori naik sekitar 9%
• Untuk meningkatkan performa sistem operasi secara keseluruhan dan memungkinkan produsen perangkat memilih trade-off ini, Android 15 dapat berjalan dengan ukuran halaman 4 KB atau 16 KB
• Sistem Android pertama yang mendukung ukuran halaman 16 KB akan tersedia sebagai opsi pengembang di beberapa perangkat

Rincian teknis tentang ukuran halaman 16 KB

• Sebagian besar CPU memiliki perangkat keras khusus bernama memory management unit (MMU) yang menerjemahkan alamat yang digunakan program ke lokasi fisik di memori
• Penerjemahan ini dilakukan dalam satuan ukuran halaman
  • Setiap kali program membutuhkan lebih banyak memori, sistem operasi harus turun tangan untuk mengisi entri "page table" dan mengalokasikan potongan memori tersebut ke proses
• Jika ukuran halaman menjadi 4 kali lebih besar, pekerjaan pencatatan ini berkurang 4 kali.
  • Karena itu, sistem dapat menghabiskan lebih banyak waktu untuk membuat video tampak bagus, menjalankan game dengan baik, dan mengeksekusi aplikasi dengan mulus, serta lebih sedikit waktu untuk pekerjaan administratif sistem operasi tingkat rendah
• Ukuran halaman bukanlah Application Binary Interface (ABI)
• Artinya, jika aplikasi diperbaiki agar tidak bergantung pada ukuran halaman, biner aplikasi yang sama dapat berjalan di perangkat 4KB maupun 16KB
• Di Android 15, Android telah direfaktor dari awal agar tidak bergantung pada ukuran halaman sehingga dapat berjalan pada berbagai ukuran halaman

Perubahan utama pada OS

• Perangkat berbasis Android 15:
  • Makro PAGE_SIZE saat compile time diganti dengan getpagesize(2) saat runtime
  • Semua biner OS disejajarkan ke 16 KB (aplikasi/pustaka pihak ketiga mungkin tidak disejajarkan ke 16KB)
  • Semua biner OS dibangun sebagai segmen terpisah yang dapat dimuat agar semua area memori yang dipetakan ke proses dapat dibaca, dan beberapa aplikasi bergantung pada ini
  • Berbagai komponen OS ditulis ulang agar tidak mengasumsikan ukuran halaman tertentu dan dioptimalkan untuk ukuran halaman yang lebih besar

Sistem file

• Untuk kinerja yang baik, ukuran blok sistem file harus cocok dengan ukuran halaman. Sistem file EROFS dan F2FS serta lapisan penyimpanan UFS kompatibel dengan 16KB
• Pada sistem 4KB, ukuran berkas executable ELF bertambah karena padding tambahan untuk penyelarasan 16KB, tetapi biaya ini dihindari melalui berbagai optimasi
• Sistem file read-only sparse memastikan halaman 0 yang dibuat untuk padding tambahan demi penyelarasan 16KB tidak ditulis ke disk
• Sistem file yang dapat dibaca/ditulis menangani halaman 0 per kasus

Manajemen memori

• Linux page cache dimodifikasi agar tidak melakukan prefetch pada ruang padding ekstra ini, sehingga menghemat pemuatan memori yang tidak perlu
• Halaman ini adalah padding kosong dan program tidak akan pernah membacanya. Ini hanya ruang di antara bagian program yang dapat digunakan, untuk tujuan penyelarasan

Kernel Linux

• Kernel Linux sangat terikat pada ukuran halaman tertentu, sehingga ukuran halaman yang akan digunakan harus dipilih saat membangun kernel, sementara bagian sistem operasi lainnya tetap sama

Aplikasi Android

• Semua aplikasi yang memiliki native code atau dependensi harus dikompilasi ulang agar kompatibel dengan perangkat berukuran halaman 16KB
• Karena sebagian besar aplikasi Android dan native code dalam SDK dibangun dengan asumsi ukuran halaman 4KB, semuanya perlu disejajarkan ulang ke 16KB agar biner kompatibel dengan perangkat 4KB dan 16KB
• Pada sebagian besar aplikasi dan SDK, ini adalah proses dua tahap:
  1. Bangun ulang native code dengan penyelarasan 16KB
  2. Uji dan perbaiki di perangkat/emulator 16KB jika ada asumsi yang di-hardcode tentang ukuran halaman

Mengembangkan perangkat 16 KB

• Perangkat Android yang saat ini diproduksi belum mendukung ukuran halaman 16 KB
  • Untuk mengatasi hal ini, Google bekerja sama dengan mitra agar opsi pengembang dapat digunakan di perangkat yang ada
• Dukungan ukuran halaman 16 KB akan disediakan melalui opsi pengembang
• Target emulator 16 KB tersedia di Android Studio

Opsi pengembang 16 KB

• Di Android 15, Google mengimplementasikan opsi pengembang yang memungkinkan peralihan antara ukuran halaman 16 KB dan 4 KB
• Tersedia di Pixel 8 dan Pixel 8 Pro, dan akan didukung di perangkat tambahan
• Untuk menggunakan opsi pengembang, perangkat harus di-reset dan bootloader harus dibuka kuncinya

16 KB di desktop x86_64

• Ukuran halaman 16 KB dapat diemulasikan di emulator x86_64
• Emulator halaman 16 KB dapat diunduh dan dijalankan dari Android Studio SDK Manager

Masa depan

• Android 15 dan AOSP mendukung halaman 16 KB, dan dapat diimplementasikan melalui opsi pengembang
• Diharapkan pengembang aplikasi dan SDK memanfaatkan opsi ini untuk menyiapkan perangkat Android yang lebih cepat dan efisien

Opini GN⁺

• Peralihan ke ukuran halaman 16KB adalah perubahan penting untuk meningkatkan performa dan efisiensi perangkat Android
• Dengan menggunakan ukuran halaman yang lebih besar, overhead manajemen memori dapat berkurang dan performa sistem secara keseluruhan dapat meningkat
• Namun, perubahan ini juga dapat menimbulkan masalah kompatibilitas, terutama untuk aplikasi dan SDK yang bergantung pada native code, sehingga pengembang perlu memperbarui perangkat lunaknya dengan mempertimbangkan ukuran halaman 16KB
• Google menyediakan alat bagi pengembang untuk menguji dan mempersiapkan transisi ini melalui opsi pengembang 16KB dan dukungan emulator
• Halaman 16KB saat ini hanya berlaku untuk perangkat Android berbasis ARM, tetapi ke depan ada kemungkinan meluas ke platform perangkat keras lain
• Selain menyesuaikan aplikasi dan SDK ke ukuran halaman 16KB, pengembang juga perlu mempertimbangkan dampak ukuran halaman yang lebih besar terhadap penggunaan memori dan melakukan optimasi memori bila perlu
• Peralihan ke halaman 16KB adalah upaya penting yang membutuhkan kolaborasi di seluruh ekosistem Android, tetapi pada akhirnya akan memberikan performa dan efisiensi yang lebih baik bagi pengguna

[GN⁺]

Komentar Hacker News

• Baru-baru ini mulai dikerjakan build kernel ARM64 di kernel Debian dengan ukuran halaman 16KiB

  • Sedang ada diskusi tambahan untuk ukuran halaman 64KiB juga
  • DART IOMMU pada Apple M1 mensyaratkan ukuran halaman minimum 16KiB sehingga efisiensi diperkirakan meningkat

• Sistem Android pertama dengan dukungan 16KB akan tersedia di sebagian perangkat melalui opsi pengembang

  • Bisa diuji dan diperbaiki melalui opsi pengembang
  • Biner aplikasi yang tidak bergantung pada ukuran halaman dapat berjalan baik di perangkat 4KB maupun 16KB

• Penasaran kapan aplikasi tidak independen terhadap ukuran halaman

  • Ingin tahu dalam situasi seperti apa masalah ini terjadi

• Ada masalah jika langsung memakai default 16KB tanpa mendukung proses 4KB dan 16KB secara bersamaan

  • Biner lama bisa rusak dan ada kekhawatiran performa emulator menurun
  • Diperlukan kernel yang juga mendukung halaman 4KB
  • Akan masuk akal bila dalam desain CPU, entri tabel halaman 16KB bisa dipetakan dalam unit 4KB

• iOS sudah menggunakan halaman 16KB sejak transisi ke 64-bit

  • Mac ARM juga mewarisi desain ini

• RHEL pernah mencoba halaman 64KB pada AARCH64 di masa lalu, tetapi akhirnya dibatalkan karena banyak bug

  • Upaya Google mengesankan, tetapi masih diragukan apakah akan berhasil

• Penasaran seberapa besar Asahi membantu pekerjaan kernel dan ekosistem untuk mengaktifkan halaman 16KB

  • Fakta bahwa RISC-V terkunci ke halaman 4KB tampak seperti sebuah kesalahan

• iOS sudah lama memakai halaman 16K

  • OSX beralih ke halaman 16K pada 2020 bersama M1
  • Windows tetap bertahan di halaman 4K bahkan pada AArch64
  • Linux mendukung beragam ukuran halaman. Asahi memakai 16K

• Penasaran apakah peningkatan ukuran halaman berdampak negatif pada performa I/O atau umur flash

  • Juga penasaran apakah unit tulis perangkat flash modern yang dikelola lebih besar daripada 4KB atau 16KB

• Peningkatan performa telah terukur

  • Terutama aplikasi kamera bisa mulai lebih cepat
  • Penasaran dengan kemungkinan optimasi lainnya
  • Bertanya-tanya apakah kode inisialisasi bisa diminimalkan dengan cara seperti "image dump" di Lisp

• Peningkatan performa 5-10% tampak cukup besar

  • Jika page walk memang semahal itu, muncul pertanyaan apakah seharusnya ada TLB yang lebih besar
  • Kenaikan penggunaan memori sebesar 9% juga tampak besar
  • Penasaran bagaimana dampaknya terhadap penggunaan memori

[gurugio]

• Penyimpanan modern menyimpan IO di cache internal storage, jadi diperkirakan tidak akan ada perbedaan berarti meskipun IO terjadi dalam 16KB.
• Kinerja perangkat yang membutuhkan performa tinggi dan mendapat alokasi halaman berurutan, seperti kamera dan GPU, akan meningkat.
• Karena TLB adalah cache perangkat keras, biayanya tampaknya akan menjadi masalah.
• Tampaknya mereka menilai peningkatan penggunaan memori sebesar 10% bukan masalah besar dibanding kapasitas memori model-model terbaru.
• Mendukung 4k/16k secara bersamaan mengharuskan modifikasi mulai dari core CPU hingga bagian kernel core, jadi saya pribadi menganggapnya hampir mustahil. Karena kernel sudah lama memanfaatkan fitur halaman besar seperti hugepage, saya rasa operasi 16k sendiri tidak akan menjadi masalah besar. Di luar kernel, masalah yang muncul pada fitur Android atau aplikasi tampaknya harus ditangani Google.
• Bagaimanapun, dalam situasi core 64-bit dan kapasitas memori yang terus membesar, pembesaran ukuran halaman sudah lama dibahas di pasar server. Saya rasa kini smartphone juga mau tak mau harus menerapkannya.