Android adiciona suporte a páginas de 16 KB

• Página é a unidade mínima com que o sistema operacional gerencia a memória
• A maioria das CPUs oferece suporte a tamanho de página de 4 KB, e o Android OS e os aplicativos são otimizados para páginas de 4 KB
• CPUs ARM oferecem suporte a tamanho de página de 16 KB, e quando o Android usa esse tamanho, o desempenho melhora de 5% a 10%, enquanto o uso de memória aumenta cerca de 9%
• Para melhorar o desempenho geral do sistema operacional e permitir que fabricantes de dispositivos escolham esse trade-off, o Android 15 pode rodar com tamanho de página de 4 KB ou 16 KB
• O primeiro sistema Android com suporte a tamanho de página de 16 KB será disponibilizado como opção de desenvolvedor em alguns dispositivos

Detalhes técnicos sobre o tamanho de página de 16 KB

• A maioria das CPUs tem um hardware dedicado chamado unidade de gerenciamento de memória (MMU), que converte os endereços usados pelos programas em localizações físicas na memória
• Essa conversão é feita em unidades do tamanho da página
  • Sempre que um programa precisa de mais memória, o sistema operacional precisa intervir para preencher entradas da "tabela de páginas" e atribuir esse bloco de memória ao processo
• Se o tamanho da página ficar 4 vezes maior, o trabalho de bookkeeping cai 4 vezes.
  • Assim, o sistema pode dedicar mais tempo a exibir vídeos com qualidade, rodar jogos melhor e executar apps com mais fluidez, e menos tempo a tarefas administrativas de baixo nível do sistema operacional
• Tamanho de página não é uma Application Binary Interface (ABI)
• Ou seja, se os aplicativos forem ajustados para não depender do tamanho da página, o mesmo binário de aplicativo poderá rodar tanto em dispositivos de 4 KB quanto de 16 KB
• No Android 15, o Android foi refatorado desde a base para poder rodar com vários tamanhos de página, tornando-se independente desse tamanho

Principais mudanças no SO

• Dispositivos com Android 15:
  • A macro PAGE_SIZE em tempo de compilação foi substituída por getpagesize(2) em tempo de execução
  • Todos os binários do SO são alinhados em 16 KB (aplicativos/bibliotecas de terceiros podem não estar alinhados em 16 KB)
  • Todos os binários do SO são construídos com um segmento carregável separado para permitir leitura de todas as regiões de memória mapeadas no processo, algo do qual alguns aplicativos dependem
  • Vários componentes do SO foram reescritos para não assumir um tamanho de página fixo e para serem otimizados para páginas maiores

Sistema de arquivos

• Para operações de alto desempenho, o tamanho do bloco do sistema de arquivos deve corresponder ao tamanho da página. Os sistemas de arquivos EROFS e F2FS, assim como a camada de armazenamento UFS, são compatíveis com 16 KB
• Em sistemas de 4 KB, o tamanho dos executáveis ELF aumenta por causa do padding adicional usado para alinhamento em 16 KB, mas várias otimizações evitam esse custo
• O sistema de arquivos esparso somente leitura garante que páginas zero geradas para o padding extra de alinhamento em 16 KB não sejam gravadas no disco
• Sistemas de arquivos com leitura/gravação tratam páginas zero caso a caso

Gerenciamento de memória

• O page cache do Linux foi modificado para não fazer prefetch desse espaço extra de padding, economizando carregamentos de memória desnecessários
• Essas páginas são padding vazio e o programa nunca as lê. É apenas espaço entre partes utilizáveis do programa para fins de alinhamento

Kernel Linux

• Como o kernel Linux é profundamente acoplado a um tamanho de página específico, é preciso escolher o tamanho da página ao compilar o kernel, enquanto o restante do sistema operacional permanece igual

Aplicativos Android

• Todos os aplicativos com código nativo ou dependências precisam ser recompilados para serem compatíveis com dispositivos com tamanho de página de 16 KB
• Como a maior parte do código nativo em aplicativos Android e SDKs foi construída pensando em páginas de 4 KB, é necessário realinhar para 16 KB para que os binários sejam compatíveis tanto com dispositivos de 4 KB quanto de 16 KB
• Para a maioria dos aplicativos e SDKs, isso é um processo em 2 etapas:
  1. Recompilar o código nativo com alinhamento de 16 KB
  2. Testar e corrigir em dispositivos/emuladores de 16 KB caso existam suposições codificadas diretamente sobre o tamanho da página

Desenvolvendo para dispositivos de 16 KB

• Atualmente, dispositivos Android em produção não oferecem suporte a tamanho de página de 16 KB
  • Para resolver isso, estão trabalhando com parceiros para disponibilizar essa opção de desenvolvedor em dispositivos existentes
• Está previsto oferecer suporte a tamanho de página de 16 KB como opção de desenvolvedor
• É possível usar um alvo de emulador de 16 KB no Android Studio

Opção de desenvolvedor de 16 KB

• No Android 15, foi implementada uma opção de desenvolvedor para alternar entre tamanhos de página de 16 KB e 4 KB
• Disponível no Pixel 8 e Pixel 8 Pro, com suporte planejado para mais dispositivos
• Para usar a opção de desenvolvedor, é preciso redefinir o dispositivo e desbloquear o bootloader

16 KB em desktop x86_64

• É possível emular tamanho de página de 16 KB em um emulador x86_64
• É possível baixar e executar um emulador de páginas de 16 KB no Android Studio SDK Manager

Futuro

• Android 15 e o AOSP oferecem suporte a páginas de 16 KB, com implementação disponível por opção de desenvolvedor
• A expectativa é que desenvolvedores de aplicativos e SDKs aproveitem essa opção para preparar dispositivos Android mais rápidos e eficientes

Opinião do GN⁺

• A transição para tamanho de página de 16 KB é uma mudança importante para melhorar o desempenho e a eficiência de dispositivos Android
• O uso de páginas maiores pode reduzir o overhead de gerenciamento de memória e melhorar o desempenho geral do sistema
• No entanto, essa mudança também pode causar problemas de compatibilidade, especialmente para apps e SDKs que dependem de código nativo, então desenvolvedores precisam atualizar seu software pensando em páginas de 16 KB
• O Google está fornecendo ferramentas para que desenvolvedores testem e se preparem para essa transição, com a opção de desenvolvedor de 16 KB e suporte em emulador
• As páginas de 16 KB atualmente se aplicam apenas a dispositivos Android baseados em ARM, mas no futuro podem se expandir para outras plataformas de hardware
• Além de adaptar apps e SDKs ao tamanho de página de 16 KB, desenvolvedores também devem considerar o impacto de páginas maiores no uso de memória e fazer otimizações de memória quando necessário
• A transição para páginas de 16 KB é um esforço importante que exige colaboração de todo o ecossistema Android, mas no fim deve entregar melhor desempenho e eficiência aos usuários

[GN⁺]

Comentários no Hacker News

• Recentemente começaram o trabalho, no kernel do Debian, para compilar o kernel ARM64 com tamanho de página de 16KiB

  • Também está em discussão adicionar tamanho de página de 64KiB
  • O DART IOMMU do Apple M1 exige no mínimo páginas de 16KiB, então é esperada uma melhora de eficiência

• O primeiro sistema Android com suporte a 16KB deverá ser disponibilizado em alguns dispositivos por meio das opções de desenvolvedor

  • Será possível testar e corrigir via opções de desenvolvedor
  • Binários de aplicativos independentes do tamanho de página podem rodar tanto em dispositivos de 4KB quanto de 16KB

• Há curiosidade sobre quando um aplicativo não é independente do tamanho de página

  • Gostaria de saber em que situações esse problema acontece

• Usar 16KB como padrão sem dar suporte simultâneo a processos de 4KB e 16KB é problemático

  • Binários antigos podem quebrar e há preocupação com queda de desempenho em emuladores
  • É necessário um kernel que também suporte páginas de 4KB
  • Parece razoável que o design da CPU permita mapear entradas de tabela de páginas de 16KB em unidades de 4KB

• O iOS usa páginas de 16KB desde a transição para 64 bits

  • Os Macs ARM também herdaram esse design

• O RHEL tentou no passado usar páginas de 64KB em AARCH64, mas acabou revertendo por causa de muitos bugs

  • O esforço do Google é impressionante, mas há dúvidas sobre se terá sucesso

• Há curiosidade sobre quanto o Asahi ajudou no trabalho de kernel e ecossistema para viabilizar páginas de 16KB

  • O fato de o RISC-V ter ficado fixo em páginas de 4KB parece um erro

• O iOS usa páginas de 16K há muito tempo

  • O OSX mudou para páginas de 16K em 2020 com o M1
  • O Windows continua em páginas de 4K mesmo no AArch64
  • O Linux suporta vários tamanhos de página. O Asahi usa 16K

• Há curiosidade se o aumento do tamanho de página afeta negativamente o desempenho de I/O ou a vida útil do flash

  • Também há curiosidade se a unidade de gravação dos dispositivos flash gerenciados modernos é maior que 4KB ou 16KB

• Foram medidas melhorias de desempenho

  • Em especial, o app da câmera inicia mais rápido
  • Há curiosidade sobre outras possibilidades de otimização
  • Há curiosidade se seria possível minimizar o código de inicialização de um jeito parecido com o "image dump" do Lisp

• Um ganho de desempenho de 5-10% parece bastante significativo

  • Se o page walk é tão caro, fica a dúvida se não deveria haver um TLB maior
  • Um aumento de 9% no uso de memória também parece significativo
  • Há curiosidade sobre o impacto no uso de memória

[gurugio]

• Como os storages mais recentes armazenam o IO em caches internos, é esperado que não haja muita diferença mesmo que o IO ocorra em 16 KB.
• O desempenho de dispositivos para os quais páginas contíguas são alocadas, como câmera e GPU, deve melhorar, já que desempenho é importante nesses casos.
• Como a TLB é um cache de hardware, parece que o custo pode ser um problema.
• Parece que avaliaram que um aumento de 10% no uso de memória não será um grande problema, considerando a quantidade de memória dos modelos mais recentes.
• Acho que oferecer suporte simultâneo a 4k/16k é quase impossível, porque seria necessário modificar desde os núcleos da CPU até partes do kernel. Como o kernel já usa recursos de páginas grandes, como hugepage, há muito tempo, acredito que o funcionamento em 16k não trará grandes problemas. Já eventuais problemas em recursos do Android ou em apps fora do kernel terão de ser gerenciados pelo Google.
• De qualquer forma, em um cenário de núcleos 64 bits e memória cada vez maior, aumentar o tamanho da página já vem sendo discutido há bastante tempo no mercado de servidores. Acho que agora os smartphones também terão de adotar isso inevitavelmente.