Android'e 16 KB sayfa boyutu ekleniyor

• Sayfalar, işletim sisteminin belleği yönettiği en küçük birimdir
• CPU'ların çoğu 4 KB sayfa boyutunu destekler ve Android OS ile uygulamalar 4 KB sayfa boyutuna göre optimize edilmiştir
• ARM CPU'lar 16 KB sayfa boyutunu destekler ve Android bu boyutu kullandığında performans %5-10 artarken bellek kullanımı yaklaşık %9 yükselir
• Genel işletim sistemi performansını iyileştirmek ve cihaz üreticilerine bu ödünleşimi seçme imkanı vermek için Android 15, 4 KB veya 16 KB sayfa boyutuyla çalışabilecek
• 16 KB sayfa boyutunu destekleyen ilk Android sistemleri, bazı cihazlarda geliştirici seçeneği olarak sunulacak

16KB sayfa boyutuna dair teknik ayrıntılar

• Çoğu CPU'da, bir programın kullandığı adresleri bellekteki fiziksel konumlara çeviren bellek yönetim birimi (MMU) adlı özel donanım bulunur
• Bu çeviri, sayfa boyutu birimiyle yapılır
  • Program her daha fazla belleğe ihtiyaç duyduğunda işletim sistemi devreye girip "sayfa tablosu" girdilerini doldurmalı ve ilgili bellek parçasını sürece tahsis etmelidir
• Sayfa boyutu 4 kat büyüdüğünde, kayıt tutma işi 4 kat azalır.
  • Böylece sistem, videoları güzel göstermeye, oyunları iyi çalıştırmaya ve uygulamaları akıcı yürütmeye daha fazla zaman ayırabilir; düşük seviyeli işletim sistemi evrak işlerine ise daha az zaman harcar
• Sayfa boyutu bir Application Binary Interface (ABI) değildir
• Yani uygulamalar sayfa boyutundan bağımsız olacak şekilde düzeltilirse, aynı uygulama ikilisi hem 4KB hem de 16KB cihazlarda çalışabilir
• Android 15'te Android, farklı sayfa boyutlarında çalışabilecek şekilde baştan refactor edilerek sayfa boyutundan bağımsız hale getirildi

Başlıca OS değişiklikleri

• Android 15 tabanlı cihazlar:
  • Derleme zamanı PAGE_SIZE makrosu, çalışma zamanı getpagesize(2) ile değiştirildi
  • Tüm OS ikilileri 16 KB hizalıdır (üçüncü taraf uygulamalar/kütüphaneler 16KB hizalı olmayabilir)
  • Tüm OS ikilileri, sürece eşlenen tüm bellek bölgelerini okuyabilmek için ayrı yüklenebilir segmentlerle oluşturulur; bazı uygulamalar buna bağımlıdır
  • Birden fazla OS bileşeni, sayfa boyutunu varsaymayacak ve daha büyük sayfa boyutları için optimize edilecek şekilde yeniden yazıldı

Dosya sistemi

• İyi performans için dosya sistemi blok boyutunun sayfa boyutuyla eşleşmesi gerekir. EROFS ve F2FS dosya sistemleri ile UFS depolama katmanı 16KB uyumludur
• 4KB sistemlerde, 16KB hizalama için eklenen padding nedeniyle ELF çalıştırılabilir dosyalarının boyutu artar; ancak çeşitli optimizasyonlarla bu maliyet önlenir
• Sparse salt okunur dosya sistemi, 16KB hizalama için eklenen fazladan padding nedeniyle oluşturulan 0 sayfalarının diske yazılmamasını sağlar
• Okuma/yazma yapılabilen dosya sistemleri 0 sayfalarını duruma göre işler

Bellek yönetimi

• Linux sayfa önbelleği, bu ekstra padding alanları için önceden okuma yapmayacak şekilde değiştirildi; böylece gereksiz bellek yüklemesi önlenir
• Bu sayfalar boş padding'dir ve program bunları asla okumaz. Bunlar yalnızca hizalama amacıyla, programın kullanılabilir kısımları arasındaki alanlardır

Linux çekirdeği

• Linux çekirdeği belirli sayfa boyutlarına derinden bağlıdır; bu nedenle çekirdeği derlerken kullanılacak sayfa boyutu seçilmelidir ve işletim sisteminin geri kalanı aynı kalır

Android uygulamaları

• Yerel kodu veya bağımlılıkları olan tüm uygulamalar, 16KB sayfa boyutlu cihazlarla uyumlu olacak şekilde yeniden derlenmelidir
• Android uygulamaları ve SDK'lar içindeki yerel kodun büyük kısmı 4KB sayfa boyutu düşünülerek derlendiği için, ikililerin hem 4KB hem de 16KB cihazlarla uyumlu olması adına 16KB'ye göre yeniden hizalanması gerekir
• Çoğu uygulama ve SDK için bu iki aşamalı bir süreçtir:
  1. Yerel kodu 16KB hizalama ile yeniden derleme
  2. Sayfa boyutuna dair sabit kodlanmış varsayımlar varsa 16KB cihaz/emülatörde test edip düzeltme

16 KB cihaz geliştirme

• Halihazırda üretimde olan Android cihazlar 16 KB sayfa boyutunu desteklemiyor
  • Bunu çözmek için iş ortaklarımızla birlikte mevcut cihazlarda geliştirici seçeneklerini kullanılabilir hale getirmek üzere çalışıyoruz
• 16 KB sayfa boyutu desteği geliştirici seçeneği olarak sunulacak
• Android Studio'da 16 KB emülatör hedefi kullanılabilir

16 KB geliştirici seçeneği

• Android 15'te, 16 KB ve 4 KB sayfa boyutları arasında geçiş yapabilen bir geliştirici seçeneği uygulanmıştır
• Pixel 8 ve Pixel 8 Pro'da kullanılabilir, ek cihazlara da gelecek
• Geliştirici seçeneğini kullanmak için cihazı sıfırlamak ve bootloader kilidini açmak gerekir

x86_64 masaüstünde 16 KB

• x86_64 emülatörde 16 KB sayfa boyutu emüle edilebilir
• Android Studio SDK Manager üzerinden 16 KB sayfa emülatörü indirilebilir ve çalıştırılabilir

Gelecek

• Android 15 ve AOSP, 16 KB sayfaları destekliyor ve bu özellik geliştirici seçeneğiyle etkinleştirilebiliyor
• Uygulama ve SDK geliştiricilerinin bu seçeneği kullanarak daha performanslı ve verimli Android cihazlara hazırlanması umuluyor

GN⁺ görüşü

• 16KB sayfa boyutuna geçiş, Android cihazların performansını ve verimliliğini artırmaya yönelik önemli bir değişiklik
• Daha büyük sayfa boyutu kullanmak, bellek yönetimi ek yükünü azaltıp genel sistem performansını iyileştirebilir
• Ancak bu değişiklik, özellikle yerel koda dayanan uygulama ve SDK'larda uyumluluk sorunlarına yol açabilir; bu nedenle geliştiricilerin yazılımlarını 16KB sayfa boyutunu dikkate alarak güncellemesi gerekiyor
• Google, 16KB geliştirici seçeneği ve emülatör desteğiyle geliştiricilere bu geçişi test edip hazırlanabilecekleri araçlar sunuyor
• 16KB sayfalar şu anda yalnızca ARM tabanlı Android cihazlar için geçerli olsa da gelecekte diğer donanım platformlarına genişleyebilir
• Geliştiriciler, uygulama ve SDK'larını 16KB sayfa boyutuna uyarlamanın yanı sıra, daha büyük sayfa boyutunun bellek kullanımına etkisini de değerlendirmeli ve gerekirse bellek optimizasyonu yapmalı
• 16KB sayfalara geçiş, Android ekosistemi genelinde iş birliği gerektiren önemli bir çaba; ancak sonuçta kullanıcılara daha iyi performans ve verimlilik sağlayacak

[GN⁺]

Hacker News görüşleri

• Debian çekirdeğinde ARM64 çekirdeğini 16KiB sayfa boyutuyla derleme çalışmaları kısa süre önce başladı

  • 64KiB sayfa boyutu da ayrıca tartışılıyor
  • Apple M1'in DART IOMMU'su en az 16KiB sayfa boyutu gerektirdiği için verimliliğin artması bekleniyor

• İlk 16KB destekli Android sistemleri, bazı cihazlarda geliştirici seçeneği olarak sunulacak

  • Geliştirici seçeneği üzerinden test ve düzeltme yapılabilecek
  • Sayfa boyutundan bağımsız uygulama ikilileri hem 4KB hem de 16KB cihazlarda çalışabilecek

• Uygulamaların hangi durumlarda sayfa boyutundan bağımsız olmadığı merak ediliyor

  • Bunun hangi koşullarda sorun çıkardığını bilmek istiyorum

• 4KB ve 16KB süreçlerini aynı anda desteklemeden 16KB'yi varsayılan yapmak sorunlu görünüyor

  • Eski ikililer bozulabilir ve emülatör performansında düşüş yaşanabilir
  • 4KB sayfaları da destekleyen bir çekirdek gerekli
  • CPU tasarımında 16KB sayfa tablosu girdilerinin 4KB birimler halinde eşlenebilmesine izin vermek mantıklı olabilir

• iOS, 64 bit geçişinden beri 16KB sayfa kullanıyor

  • ARM Mac'ler de bu tasarımı devraldı

• RHEL geçmişte AARCH64 üzerinde 64KB sayfayı denedi, ancak çok sayıda hata nedeniyle sonunda geri döndü

  • Google'ın çabası etkileyici ama başarılı olup olmayacağı belirsiz

• Asahi'nin 16KB sayfaları etkinleştiren çekirdek ve ekosistem çalışmalarına ne kadar katkı sağladığı merak ediliyor

  • RISC-V'nin 4KB sayfalara sabitlenmiş olması bir hata gibi görünüyor

• iOS uzun zamandır 16K sayfa kullanıyor

  • OSX, M1 ile birlikte 2020'de 16K sayfaya geçti
  • Windows, AArch64'te bile 4K sayfalarda kaldı
  • Linux çeşitli sayfa boyutlarını destekliyor. Asahi 16K kullanıyor

• Sayfa boyutunun artmasının I/O performansı ya da flash ömrü üzerinde olumsuz etkisi olup olmadığı merak ediliyor

  • Modern yönetilen flash aygıtlarında yazma biriminin 4KB ya da 16KB'den daha büyük olup olmadığı da soruluyor

• Performans iyileşmesinin ölçüldüğü belirtiliyor

  • Özellikle kamera uygulaması daha hızlı açılıyor
  • Başka hangi optimizasyonların mümkün olabileceği merak ediliyor
  • Lisp'teki "image dump" benzeri bir yöntemle başlatma kodunun en aza indirilip indirilemeyeceği soruluyor

• %5-10'luk performans artışı büyük görünüyor

  • Sayfa yürüyüşü bu kadar maliyetliyse daha büyük bir TLB olması gerekmez mi diye soruluyor
  • Bellek kullanımındaki %9 artış da büyük görünüyor
  • Bunun bellek kullanımı üzerindeki etkisinin ne olduğu merak ediliyor

[gurugio]

• Modern depolama birimlerinde I/O depolama içindeki önbelleğe yazıldığı için, I/O 16 KB olarak gerçekleşse bile kayda değer bir fark olmayacağı tahmin ediliyor.
• Kamera, GPU gibi performansın önemli olduğu ve ardışık sayfa tahsisi alan aygıtların performansı iyileşir.
• TLB bir donanım önbelleği olduğu için maliyet tarafının sorun olabileceği düşünülüyor.
• Bellek kullanımının %10 artmasının, güncel modellerin bellek kapasitesiyle kıyaslandığında büyük bir sorun olmayacağı yönünde değerlendirildiği anlaşılıyor.
• 4k/16k'yi aynı anda desteklemek için CPU çekirdeğinden kernel çekirdeği kısmına kadar değişiklik yapmak gerekeceğinden, bunun neredeyse imkansız olduğunu düşünüyorum. Kernel büyük sayfa özelliklerini hugepage gibi mekanizmalarla uzun süredir kullandığı için, 16k çalışmanın büyük bir sorun yaratmayacağını düşünüyorum. Kernel dışındaki Android işlevlerinde ya da uygulamalarda ortaya çıkacak sorunları ise Google'ın yönetmesi gerekecektir.
• Her halükarda, 64 bit çekirdeklerde belleğin giderek büyüdüğü bir ortamda sayfa boyutunu artırma konusu sunucu pazarında zaten uzun zamandır tartışılıyordu. Artık bunun akıllı telefonlarda da kaçınılmaz olarak uygulanması gerektiğini düşünüyorum.