Android agrega tamaño de página de 16 KB

• La página es la unidad mínima con la que el sistema operativo administra la memoria
• La mayoría de los CPU admiten un tamaño de página de 4 KB, y el sistema operativo Android y las aplicaciones están optimizados para un tamaño de página de 4 KB
• Los CPU ARM admiten un tamaño de página de 16 KB, y cuando Android usa este tamaño, el rendimiento mejora entre 5 y 10% y el uso de memoria aumenta alrededor de 9%
• Para mejorar el rendimiento general del sistema operativo y permitir que los fabricantes de dispositivos elijan este equilibrio, Android 15 puede ejecutarse con tamaños de página de 4 KB o 16 KB
• Los primeros sistemas Android compatibles con tamaño de página de 16 KB estarán disponibles como opción para desarrolladores en algunos dispositivos

Detalles técnicos sobre el tamaño de página de 16 KB

• La mayoría de los CPU tienen hardware dedicado llamado unidad de administración de memoria (MMU) que traduce las direcciones que usa un programa a ubicaciones físicas en la memoria
• Esta traducción se realiza en unidades del tamaño de página
  • Cada vez que un programa necesita más memoria, el sistema operativo debe intervenir para llenar entradas de la "tabla de páginas" y asignar ese bloque de memoria al proceso
• Si el tamaño de página es 4 veces mayor, el trabajo de registro se reduce 4 veces.
  • Por lo tanto, el sistema puede dedicar más tiempo a hacer que el video se vea bien, que los juegos funcionen bien y que las apps se ejecuten con fluidez, y menos tiempo al papeleo de bajo nivel del sistema operativo
• El tamaño de página no es una Application Binary Interface (ABI)
• Es decir, si una aplicación se modifica para que sea independiente del tamaño de página, el mismo binario de la aplicación puede ejecutarse tanto en dispositivos de 4 KB como de 16 KB
• En Android 15, Android fue refactorizado desde cero para poder ejecutarse con distintos tamaños de página y volverse independiente del tamaño de página

Cambios principales en el SO

• Dispositivos basados en Android 15:
  • La macro PAGE_SIZE en tiempo de compilación se reemplaza por getpagesize(2) en tiempo de ejecución
  • Todos los binarios del SO se alinean a 16 KB (las aplicaciones/bibliotecas de terceros podrían no estar alineadas a 16 KB)
  • Todos los binarios del SO se construyen con un segmento cargable separado para que se puedan leer todas las regiones de memoria mapeadas en el proceso, y algunas aplicaciones dependen de ello
  • Varios componentes del SO se reescribieron para no asumir un tamaño de página fijo y optimizarse para tamaños de página más grandes

Sistema de archivos

• Para operaciones de buen rendimiento, el tamaño de bloque del sistema de archivos debe coincidir con el tamaño de página. Los sistemas de archivos EROFS y F2FS, y la capa de almacenamiento UFS, son compatibles con 16 KB
• En sistemas de 4 KB, el tamaño de los ejecutables ELF aumenta por el relleno adicional agregado para la alineación a 16 KB, pero varias optimizaciones evitan este costo
• El sistema de archivos disperso de solo lectura evita que las páginas de 0 generadas para el relleno adicional de alineación a 16 KB se escriban en disco
• Los sistemas de archivos de lectura/escritura manejan las páginas de 0 caso por caso

Administración de memoria

• La page cache de Linux fue modificada para no hacer lectura anticipada de este espacio de relleno extra, ahorrando cargas de memoria innecesarias
• Esta página es un relleno vacío y el programa nunca la leerá. Es solo espacio entre las partes utilizables del programa con fines de alineación

Kernel de Linux

• Como el kernel de Linux está profundamente ligado a un tamaño de página específico, al compilar el kernel se debe elegir el tamaño de página a usar, mientras que el resto del sistema operativo permanece igual

Aplicaciones Android

• Cualquier aplicación con código nativo o dependencias debe recompilarse para ser compatible con dispositivos con tamaño de página de 16 KB
• Como la mayor parte del código nativo dentro de las aplicaciones Android y los SDK fue construido pensando en un tamaño de página de 4 KB, debe realinearse a 16 KB para que los binarios sean compatibles tanto con dispositivos de 4 KB como de 16 KB
• En la mayoría de las aplicaciones y SDK, este es un proceso de 2 pasos:
  1. Volver a compilar el código nativo con alineación de 16 KB
  2. Probar y corregir en dispositivos/emuladores de 16 KB si existen suposiciones codificadas de forma rígida sobre el tamaño de página

Desarrollo para dispositivos de 16 KB

• Los dispositivos Android que se producen actualmente no admiten tamaño de página de 16 KB
  • Para resolver esto, se está trabajando con socios para permitir opciones de desarrollador en dispositivos existentes
• Está previsto ofrecer compatibilidad con tamaño de página de 16 KB como opción para desarrolladores
• En Android Studio se puede usar un objetivo de emulador de 16 KB

Opción para desarrolladores de 16 KB

• En Android 15 se implementó una opción para desarrolladores que permite alternar entre tamaños de página de 16 KB y 4 KB
• Disponible en Pixel 8 y Pixel 8 Pro, y se espera soporte en más dispositivos
• Para usar la opción para desarrolladores, hay que restablecer el dispositivo y desbloquear el bootloader

16 KB en escritorio x86_64

• Es posible emular un tamaño de página de 16 KB en el emulador x86_64
• El emulador de páginas de 16 KB puede descargarse y ejecutarse desde el SDK Manager de Android Studio

Futuro

• Android 15 y AOSP admiten páginas de 16 KB, y pueden implementarse mediante la opción para desarrolladores
• Se espera que los desarrolladores de aplicaciones y SDK aprovechen esta opción para preparar dispositivos Android más rápidos y eficientes

Opinión de GN⁺

• La transición al tamaño de página de 16 KB es un cambio importante para mejorar el rendimiento y la eficiencia de los dispositivos Android
• Usar un tamaño de página mayor puede reducir la sobrecarga de administración de memoria y mejorar el rendimiento general del sistema
• Sin embargo, este cambio también puede provocar problemas de compatibilidad, especialmente en apps y SDK que dependen de código nativo, por lo que los desarrolladores deben actualizar su software pensando en páginas de 16 KB
• Google está proporcionando a los desarrolladores herramientas para probar y prepararse para esta transición mediante la opción para desarrolladores de 16 KB y el soporte del emulador
• Las páginas de 16 KB actualmente solo se aplican a dispositivos Android basados en ARM, pero en el futuro podrían ampliarse a otras plataformas de hardware
• Además de adaptar apps y SDK al tamaño de página de 16 KB, los desarrolladores también deben considerar el impacto que un tamaño de página mayor tiene en el uso de memoria y realizar optimizaciones si es necesario
• La transición a páginas de 16 KB es un esfuerzo importante que requiere colaboración en todo el ecosistema Android, pero al final ofrecerá mejor rendimiento y eficiencia a los usuarios

[GN⁺]

Opiniones de Hacker News

• Debian empezó recientemente a trabajar en compilar el kernel ARM64 con tamaño de página de 16 KiB

  • También se está discutiendo agregar tamaño de página de 64 KiB
  • Se espera una mayor eficiencia porque el DART IOMMU del Apple M1 requiere un tamaño mínimo de página de 16 KiB

• El primer sistema Android con soporte para 16 KB estará disponible en algunos dispositivos como opción para desarrolladores

  • Será posible probar y corregir mediante las opciones para desarrolladores
  • Los binarios de aplicaciones independientes del tamaño de página pueden ejecutarse tanto en dispositivos de 4 KB como de 16 KB

• Hay curiosidad sobre cuándo una aplicación no es independiente del tamaño de página

  • Quieren saber en qué situaciones ocurre este problema

• Usar 16 KB como valor predeterminado sin soportar simultáneamente procesos de 4 KB y 16 KB sería problemático

  • Los binarios antiguos podrían romperse y existe preocupación por una caída en el rendimiento del emulador
  • Se necesita un kernel que también soporte páginas de 4 KB
  • Parecería razonable que el diseño de CPU permita mapear entradas de tabla de páginas de 16 KB en unidades de 4 KB

• iOS ha usado páginas de 16 KB desde la transición a 64 bits

  • Las Mac con ARM también heredaron este diseño

• RHEL intentó en el pasado usar páginas de 64 KB en AARCH64, pero al final revirtió el cambio por muchos bugs

  • El esfuerzo de Google es impresionante, aunque hay dudas sobre si tendrá éxito

• Hay curiosidad sobre cuánto ayudó Asahi al trabajo de kernel y ecosistema para habilitar páginas de 16 KB

  • Que RISC-V haya quedado fijado en páginas de 4 KB parece un error

• iOS usa páginas de 16K desde hace mucho tiempo

  • OSX cambió a páginas de 16K junto con el M1 en 2020
  • Windows sigue en páginas de 4K incluso en AArch64
  • Linux soporta varios tamaños de página. Asahi usa 16K

• Hay curiosidad sobre si aumentar el tamaño de página afecta negativamente el rendimiento de I/O o la vida útil del flash

  • También quieren saber si la unidad de escritura de los dispositivos flash administrados modernos es mayor que 4 KB o 16 KB

• Se midieron mejoras de rendimiento

  • En particular, la app de cámara inicia más rápido
  • Hay curiosidad sobre otras posibilidades de optimización
  • También quieren saber si sería posible minimizar el código de inicialización con un enfoque como el "image dump" de Lisp

• Una mejora de rendimiento de 5-10% parece una cifra grande

  • Si el page walk es tan costoso, surge la duda de si no debería haber un TLB más grande
  • Que el uso de memoria haya aumentado 9% también parece una cifra grande
  • Hay curiosidad sobre el impacto que tuvo en el uso de memoria

[gurugio]

• Se espera que no haya una gran diferencia aunque el I/O ocurra en bloques de 16 KB, porque los almacenamientos más recientes guardan el I/O en la caché interna del almacenamiento.
• Mejorará el rendimiento de dispositivos como la cámara y la GPU, donde el desempeño es importante y se asignan páginas contiguas.
• Como la TLB es una caché de hardware, parece que el costo podría ser un problema.
• Parece que consideran que un aumento del 10% en el uso de memoria no será un gran problema en comparación con la cantidad de memoria de los modelos más recientes.
• Creo que soportar 4K/16K al mismo tiempo es casi imposible, porque habría que modificar desde los núcleos de CPU hasta partes del kernel. Como el kernel ha aprovechado durante mucho tiempo funciones de páginas grandes como hugepage, pienso que operar con 16K no debería ser un problema importante. Los problemas que surjan fuera del kernel, en funciones de Android o en las apps, tendrán que ser gestionados por Google.
• En cualquier caso, en una situación donde la memoria sigue aumentando en los núcleos de 64 bits, ampliar el tamaño de página es algo que ya se venía discutiendo desde hace tiempo en el mercado de servidores. Creo que ahora también será inevitable aplicarlo en los smartphones.