O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Otimizando os tempos de inicialização

Este documento fornece orientação aos parceiros para melhorar os tempos de inicialização de dispositivos Android específicos. O tempo de inicialização é um componente importante do desempenho do sistema, pois os usuários devem aguardar a conclusão da inicialização antes de usar o dispositivo. Para dispositivos como carros, onde a inicialização a frio ocorre com mais frequência, fazer uma inicialização rápida é fundamental (ninguém gosta de esperar dezenas de segundos apenas para inserir um destino de navegação).

O Android 8.0 permite tempos de inicialização reduzidos, oferecendo suporte a várias melhorias em uma variedade de componentes. A tabela a seguir resume essas melhorias de desempenho (medidas em dispositivos Google Pixel e Pixel XL).

Componente Melhoria
Bootloader
  • 1.6s salvos removendo o registro UART
  • 0,4s salvos ao mudar para LZ4 de GZIP
Kernel do dispositivo
  • 0,3s salvos removendo configurações de kernel não utilizadas e reduzindo o tamanho do driver
  • 0,3s salvos com otimização de pré-busca dm-verity
  • 0.15s salvos para remover espera / teste desnecessário no driver
  • 0,12s salvos para remover CONFIG_CC_OPTIMIZE_FOR_SIZE
Ajuste de I / O
  • 2s salvos na inicialização normal
  • 25s economizados na primeira inicialização
init. *. rc
  • 1.5s salvos paralelamente aos comandos init
  • Salvou 0,25s ao iniciar o zigoto mais cedo
  • Salvo 0,22s por cpuset tune
Animação de inicialização
  • Iniciado 2s antes da inicialização sem fsck acionado, muito maior na inicialização com inicialização acionada por fsck
  • Economizei 5 segundos no Pixel XL com desligamento imediato da animação de inicialização
Política SELinux 0.2s salvos em por genfscon

Otimizando Bootloader

Para otimizar o bootloader para melhores tempos de inicialização:

  • Para registro:
    • Desative a gravação de log no UART, pois pode demorar muito com muitos logs. (Nos dispositivos Google Pixel, descobrimos que ele retarda o bootloader 1.5s).
    • Registre apenas as situações de erro e considere armazenar outras informações na memória com um mecanismo separado para recuperação.
  • Para descompressão do kernel, considere usar LZ4 para hardware contemporâneo em vez de GZIP ( patch de exemplo). Lembre-se de que diferentes opções de compactação do kernel podem ter diferentes tempos de carregamento e descompactação e algumas opções podem funcionar melhor do que outras para o seu hardware específico.
  • Verifique os tempos de espera desnecessários para depuração / entrada no modo especial e minimize-os.
  • Passe o tempo de boot gasto no bootloader para o kernel como cmdline.
  • Verifique o clock da CPU e considere a paralelização (requer suporte a vários núcleos) para carregar o kernel e inicializar E / S.

Otimizando Kernel

Use as dicas a seguir para otimizar o kernel para tempos de inicialização aprimorados.

Minimizando a configuração do dispositivo

Minimizar a configuração do kernel pode reduzir o tamanho do kernel para descompactação de carregamento mais rápida, inicialização e superfícies de ataque menores. Para otimizar a definição do dispositivo:

  • Identifique drivers não utilizados . Revise os /dev e /sys e procure nós com rótulos SELinux gerais (o que indica que esses nós não estão configurados para serem acessíveis pelo espaço do usuário). Remova qualquer um desses nós, se encontrado.
  • Desconfigurar CONFIGs não utilizados . Revise o arquivo .config gerado pela construção do kernel para remover explicitamente qualquer CONFIG não utilizado que foi ativado por padrão. Por exemplo, removemos os seguintes CONFIGs não utilizados do Google Pixel:
    CONFIG_ANDROID_LOGGER=y
    CONFIG_IMX134=y
    CONFIG_IMX132=y
    CONFIG_OV9724=y
    CONFIG_OV5648=y
    CONFIG_GC0339=y
    CONFIG_OV8825=y
    CONFIG_OV8865=y
    CONFIG_s5k4e1=y
    CONFIG_OV12830=y
    CONFIG_USB_EHCI_HCD=y
    CONFIG_IOMMU_IO_PGTABLE_FAST_SELFTEST=y
    CONFIG_IKCONFIG=y
    CONFIG_RD_BZIP2=y
    CONFIG_RD_LZMA=y
    CONFIG_TI_DRV2667=y
    CONFIG_CHR_DEV_SCH=y
    CONFIG_MMC=y
    CONFIG_MMC_PERF_PROFILING=y
    CONFIG_MMC_CLKGATE=y
    CONFIG_MMC_PARANOID_SD_INIT=y
    CONFIG_MMC_BLOCK_MINORS=32
    CONFIG_MMC_TEST=y
    CONFIG_MMC_SDHCI=y
    CONFIG_MMC_SDHCI_PLTFM=y
    CONFIG_MMC_SDHCI_MSM=y
    CONFIG_MMC_SDHCI_MSM_ICE=y
    CONFIG_MMC_CQ_HCI=y
    CONFIG_MSDOS_FS=y
    # CONFIG_SYSFS_SYSCALL is not set
    CONFIG_EEPROM_AT24=y
    # CONFIG_INPUT_MOUSEDEV_PSAUX is not set
    CONFIG_INPUT_HBTP_INPUT=y
    # CONFIG_VGA_ARB is not set
    CONFIG_USB_MON=y
    CONFIG_USB_STORAGE_DATAFAB=y
    CONFIG_USB_STORAGE_FREECOM=y
    CONFIG_USB_STORAGE_ISD200=y
    CONFIG_USB_STORAGE_USBAT=y
    CONFIG_USB_STORAGE_SDDR09=y
    CONFIG_USB_STORAGE_SDDR55=y
    CONFIG_USB_STORAGE_JUMPSHOT=y
    CONFIG_USB_STORAGE_ALAUDA=y
    CONFIG_USB_STORAGE_KARMA=y
    CONFIG_USB_STORAGE_CYPRESS_ATACB=y
    CONFIG_SW_SYNC_USER=y
    CONFIG_SEEMP_CORE=y
    CONFIG_MSM_SMEM_LOGGING=y
    CONFIG_IOMMU_DEBUG=y
    CONFIG_IOMMU_DEBUG_TRACKING=y
    CONFIG_IOMMU_TESTS=y
    CONFIG_MOBICORE_DRIVER=y
    # CONFIG_DEBUG_PREEMPT is not set
    
  • Remova CONFIGs que levam a testes desnecessários em cada inicialização . Embora úteis no desenvolvimento, tais configurações (isto é, CONFIG_IOMMU_IO_PGTABLE_FAST_SELFTEST) devem ser removidas em um kernel de produção.

Minimizando o tamanho do driver

Alguns drivers no kernel do dispositivo podem ser removidos se a função não for usada para reduzir ainda mais o tamanho do kernel. Por exemplo, se a WLAN estiver conectada por meio de PCIe, o suporte SDIO não é usado e deve ser removido durante o tempo de compilação. Para obter detalhes, consulte o kernel do Google Pixel: net: wireless: cnss: add opção para desativar o suporte SDIO.

Removendo a otimização do compilador para tamanho

Remova a configuração do kernel para CONFIG_CC_OPTIMIZE_FOR_SIZE. Esse sinalizador foi originalmente introduzido quando a suposição era que um código de tamanho menor resultaria em acertos de cache ativo (e, portanto, seria mais rápido). No entanto, essa suposição não é mais válida, pois os SoCs móveis modernos se tornaram mais poderosos.

Além disso, remover o sinalizador pode ativar o aviso do compilador para variáveis ​​não inicializadas, que é suprimido nos kernels do Linux quando o sinalizador CONFIG_CC_OPTIMIZE_FOR_SIZE está presente (fazer essa mudança por si só nos ajudou a descobrir muitos bugs significativos em alguns drivers de dispositivo Android).

Adiando a inicialização

Muitos processos são iniciados durante a inicialização, mas apenas os componentes no caminho crítico (carregador de inicialização> kernel> init> montagem do sistema de arquivos> zigoto> servidor do sistema) afetam diretamente o tempo de inicialização. Crie um perfil de initcall durante a inicialização do kernel para identificar periféricos / componentes que são lentos e não críticos para iniciar o processo de inicialização e, em seguida, atrase esses periféricos / componentes para mais tarde no processo de inicialização movendo-se para módulos carregáveis ​​do kernel. Mover para a análise de dispositivo / driver assíncrona também pode ajudar a paralelizar componentes lentos em kernel> caminho crítico de inicialização.

BoardConfig-common.mk:
    BOARD_KERNEL_CMDLINE += initcall_debug ignore_loglevel

driver:
    .probe_type = PROBE_PREFER_ASYNCHRONOUS,

Nota: As dependências do driver devem ser resolvidas com cuidado adicionando o suporte EPROBEDEFER .

Otimizando a eficiência de E / S

Melhorar a eficiência de E / S é fundamental para tornar o tempo de inicialização mais rápido, e ler qualquer coisa desnecessária deve ser adiada até após a inicialização (em um Google Pixel, cerca de 1,2 GB de dados são lidos na inicialização).

Ajustando o sistema de arquivos

A leitura do kernel Linux é ativada quando um arquivo é lido do início ou quando os blocos são lidos sequencialmente, tornando necessário ajustar os parâmetros do agendador de E / S especificamente para inicialização (que tem uma caracterização de carga de trabalho diferente dos aplicativos normais).

Os dispositivos que oferecem suporte a atualizações contínuas (A / B) se beneficiam muito do ajuste do sistema de arquivos na primeira inicialização (por exemplo, 20s no Google Pixel). Por exemplo, ajustamos os seguintes parâmetros para o Google Pixel:

on late-fs
  # boot time fs tune
    # boot time fs tune
    write /sys/block/sda/queue/iostats 0
    write /sys/block/sda/queue/scheduler cfq
    write /sys/block/sda/queue/iosched/slice_idle 0
    write /sys/block/sda/queue/read_ahead_kb 2048
    write /sys/block/sda/queue/nr_requests 256
    write /sys/block/dm-0/queue/read_ahead_kb 2048
    write /sys/block/dm-1/queue/read_ahead_kb 2048

on property:sys.boot_completed=1
    # end boot time fs tune
    write /sys/block/sda/queue/read_ahead_kb 512
    ...

Diversos

  • Ative o tamanho de pré-busca de hash dm-verity usando a configuração do kernel DM_VERITY_HASH_PREFETCH_MIN_SIZE (o tamanho padrão é 128).
  • Para melhor estabilidade do sistema de arquivos e uma verificação forçada eliminada que ocorre a cada inicialização, use a nova ferramenta ext4 generation configurando TARGET_USES_MKE2FS em BoardConfig.mk.

Analisando I / O

Para entender as atividades de I / O durante a inicialização, use os dados ftrace do kernel (também usados ​​pelo systrace):

trace_event=block,ext4 in BOARD_KERNEL_CMDLINE

Para dividir o acesso a cada arquivo, faça as seguintes alterações no kernel (apenas kernel de desenvolvimento; não use em kernels de produção):

diff --git a/fs/open.c b/fs/open.c
index 1651f35..a808093 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -981,6 +981,25 @@
 }
 EXPORT_SYMBOL(file_open_root);
 
+static void _trace_do_sys_open(struct file *filp, int flags, int mode, long fd)
+{
+       char *buf;
+       char *fname;
+
+       buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
+       if (!buf)
+               return;
+       fname = d_path(&filp-<f_path, buf, PAGE_SIZE);
+
+       if (IS_ERR(fname))
+               goto out;
+
+       trace_printk("%s: open(\"%s\", %d, %d) fd = %ld, inode = %ld\n",
+                     current-<comm, fname, flags, mode, fd, filp-<f_inode-<i_ino);
+out:
+       kfree(buf);
+}
+
long do_sys_open(int dfd, const char __user *filename, int flags, umode_t mode)
 {
 	struct open_flags op;
@@ -1003,6 +1022,7 @@
 		} else {
 			fsnotify_open(f);
 			fd_install(fd, f);
+			_trace_do_sys_open(f, flags, mode, fd);

Use os scripts a seguir para ajudar na análise do desempenho de inicialização.

  • system/extras/boottime_tools/bootanalyze/bootanalyze.py Mede o tempo de inicialização com uma análise de etapas importantes no processo de inicialização.
  • system/extras/boottime_tools/io_analysis/check_file_read.py boot_trace Fornece informações de acesso para cada arquivo.
  • system/extras/boottime_tools/io_analysis/check_io_trace_all.py boot_trace Fornece detalhamento no nível do sistema.

Otimizando init. *. Rc

Init é a ponte do kernel até que a estrutura seja estabelecida, e os dispositivos geralmente passam alguns segundos em diferentes estágios de inicialização.

Executar tarefas em paralelo

Embora o init do Android atual seja mais ou menos um processo de thread único, você ainda pode executar algumas tarefas em paralelo.

  • Execute comandos lentos em um serviço de script de shell e junte-se a eles mais tarde, aguardando uma propriedade específica. O Android 8.0 oferece suporte a esse caso de uso com um novo comando wait_for_property .
  • Identifique operações lentas no init. O sistema registra o comando init exec / wait_for_prop ou qualquer ação que leve muito tempo (no Android 8.0, qualquer comando leva mais de 50 ms). Por exemplo:
    init: Command 'wait_for_coldboot_done' action=wait_for_coldboot_done returned 0 took 585.012ms

    A revisão deste registro pode indicar oportunidades de melhorias.

  • Inicie os serviços e habilite os dispositivos periféricos no caminho crítico antecipadamente. Por exemplo, alguns SOCs exigem o início de serviços relacionados à segurança antes de iniciar o SurfaceFlinger. Revise o log do sistema quando o ServiceManager retornar "aguardar serviço" - isso geralmente é um sinal de que um serviço dependente deve ser iniciado primeiro.
  • Remova todos os serviços e comandos não utilizados em init. *. Rc. Tudo o que não for usado no init em estágio inicial deve ser adiado para a inicialização completa.

Nota: o serviço de propriedade faz parte do processo init, portanto, chamar setproperty durante a inicialização pode levar um longo atraso se init estiver ocupado em comandos internos.

Usando o ajuste do planejador

Use o ajuste do agendador para inicialização antecipada. Exemplo de um Google Pixel:

on init
    # boottime stune
    write /dev/stune/schedtune.prefer_idle 1
    write /dev/stune/schedtune.boost 100
    on property:sys.boot_completed=1
    # reset stune
    write /dev/stune/schedtune.prefer_idle 0
    write /dev/stune/schedtune.boost 0

    # or just disable EAS during boot
    on init
    write /sys/kernel/debug/sched_features NO_ENERGY_AWARE
    on property:sys.boot_completed=1
    write /sys/kernel/debug/sched_features ENERGY_AWARE

Alguns serviços podem precisar de um aumento de prioridade durante a inicialização. Exemplo:

init.zygote64.rc:
service zygote /system/bin/app_process64 -Xzygote /system/bin --zygote --start-system-server
    class main
    priority -20
    user root
...

Iniciando o zigoto cedo

Dispositivos com criptografia baseada em arquivo podem iniciar o zigoto mais cedo no gatilho de início do zigoto (por padrão, o zigoto é iniciado na classe principal, que é muito posterior ao zigoto-início). Ao fazer isso, certifique-se de permitir que o zigoto seja executado em todas as CPUs (já que a configuração incorreta do cpuset pode forçar o zigoto a ser executado em CPUs específicas).

Desativar economia de energia

Durante a inicialização do dispositivo, a configuração de economia de energia para componentes como UFS e / ou controlador de CPU pode ser desativada.

Cuidado: A economia de energia deve ser ativada no modo carregador para maior eficiência.

on init
    # Disable UFS powersaving
    write /sys/devices/soc/${ro.boot.bootdevice}/clkscale_enable 0
    write /sys/devices/soc/${ro.boot.bootdevice}/clkgate_enable 0
    write /sys/devices/soc/${ro.boot.bootdevice}/hibern8_on_idle_enable 0
    write /sys/module/lpm_levels/parameters/sleep_disabled Y
on property:sys.boot_completed=1
    # Enable UFS powersaving
    write /sys/devices/soc/${ro.boot.bootdevice}/clkscale_enable 1
    write /sys/devices/soc/${ro.boot.bootdevice}/clkgate_enable 1
    write /sys/devices/soc/${ro.boot.bootdevice}/hibern8_on_idle_enable 1
    write /sys/module/lpm_levels/parameters/sleep_disabled N
on charger
    # Enable UFS powersaving
    write /sys/devices/soc/${ro.boot.bootdevice}/clkscale_enable 1
    write /sys/devices/soc/${ro.boot.bootdevice}/clkgate_enable 1
    write /sys/devices/soc/${ro.boot.bootdevice}/hibern8_on_idle_enable 1
    write /sys/class/typec/port0/port_type sink
    write /sys/module/lpm_levels/parameters/sleep_disabled N

Adiar inicialização não crítica

A inicialização não crítica, como ZRAM, pode ser adiada para boot_complete.

on property:sys.boot_completed=1
   # Enable ZRAM on boot_complete
   swapon_all /vendor/etc/fstab.${ro.hardware}

Otimizando a animação de inicialização

Use as dicas a seguir para otimizar a animação de inicialização.

Configurando o início antecipado

O Android 8.0 permite iniciar a animação de inicialização antecipadamente, antes de montar a partição de dados do usuário. No entanto, mesmo ao usar a nova cadeia de ferramentas ext4 no Android 8.0, o fsck ainda é acionado periodicamente por motivos de segurança, causando um atraso no início do serviço de bootanimation.

Para fazer com que a animação de inicialização comece mais cedo, divida a montagem do fstab em duas fases:

  • Na fase inicial, monte apenas as partições (como system/ e vendor/ ) que não requerem verificações de execução e, em seguida, inicie os serviços de animação de inicialização e suas dependências (como servicemanager e surfaceflinger).
  • Na segunda fase, monte as partições (como data/ ) que requerem verificações de execução.

A animação de inicialização será iniciada muito mais rápido (e em tempo constante), independentemente do fsck.

Acabamento limpo

Depois de receber o sinal de saída, a animação de inicialização desempenha a última parte, cuja duração pode diminuir o tempo de inicialização. Um sistema que inicializa rapidamente não precisa de longas animações, o que poderia ocultar efetivamente quaisquer melhorias feitas. Recomendamos fazer o loop de repetição e o finale curtos.

Otimizando SELinux

Use as dicas a seguir para otimizar o SELinux para tempos de inicialização aprimorados.

  • Use expressões regulares limpas (regex) . Uma regex mal formada pode levar a uma grande sobrecarga ao combinar a política SELinux para sys/devices em file_contexts . Por exemplo, o regex /sys/devices/.*abc.*(/.*)? força por engano uma varredura de todos os subdiretórios de /sys/devices que contêm "abc", permitindo correspondências para /sys/devices/abc e /sys/devices/xyz/abc . Melhorar este regex para /sys/devices/[^/]*abc[^/]*(/.*)? irá habilitar uma correspondência apenas para /sys/devices/abc .
  • Mova rótulos para genfscon . Este recurso SELinux existente passa prefixos de correspondência de arquivo para o kernel no binário SELinux, onde o kernel os aplica aos sistemas de arquivos gerados pelo kernel. Isso também ajuda a corrigir arquivos criados pelo kernel com rótulos incorretos, evitando condições de corrida que podem ocorrer entre os processos do espaço do usuário que tentam acessar esses arquivos antes que ocorra a reclassificação.

Ferramenta e métodos

Use as seguintes ferramentas para ajudá-lo a coletar dados para alvos de otimização.

Bootchart

Bootchart fornece análise de carga de CPU e E / S de todos os processos para todo o sistema. Não requer a reconstrução da imagem do sistema e pode ser usado como uma verificação rápida de sanidade antes de mergulhar no systrace.

Para habilitar o bootchart:

adb shell 'touch /data/bootchart/enabled'
adb reboot

Após a inicialização, busque o gráfico de inicialização:

$ANDROID_BUILD_TOP/system/core/init/grab-bootchart.sh

Quando terminar, exclua /data/bootchart/enabled para evitar a coleta de dados todas as vezes.

Systrace

O Systrace permite coletar os traços do kernel e do Android durante a inicialização. A visualização do systrace pode ajudar na análise de problemas específicos durante a inicialização. (No entanto, para verificar o número médio ou o número acumulado durante toda a inicialização, é mais fácil examinar o rastreamento do kernel diretamente).

Para habilitar o systrace durante a inicialização:

  • Em frameworks/native/cmds/atrace/atrace.rc , mude:
      write /sys/kernel/debug/tracing/tracing_on 0
      write /sys/kernel/tracing/tracing_on 0

    Para:

      #    write /sys/kernel/debug/tracing/tracing_on 0
      #    write /sys/kernel/tracing/tracing_on 0
  • Isso ativa o rastreamento (que é desativado por padrão).

  • No arquivo device.mk , adicione a seguinte linha:
    PRODUCT_PROPERTY_OVERRIDES +=    debug.atrace.tags.enableflags=802922
    PRODUCT_PROPERTY_OVERRIDES +=    persist.traced.enable=0
  • No arquivo BoardConfig.mk do dispositivo, adicione o seguinte:
    BOARD_KERNEL_CMDLINE := ... trace_buf_size=64M trace_event=sched_wakeup,sched_switch,sched_blocked_reason,sched_cpu_hotplug
  • Para análise detalhada de E / S, adicione também block e ext4 e f2fs.

  • No arquivo init.rc específico do dispositivo, adicione o seguinte:
    on property:sys.boot_completed=1          // This stops tracing on boot complete
    write /d/tracing/tracing_on 0
    write /d/tracing/events/ext4/enable 0
    write /d/tracing/events/f2fs/enable 0
    write /d/tracing/events/block/enable 0
    
  • Após a inicialização, busque o rastreamento:

    adb root && adb shell atrace --async_stop -z -c -o /data/local/tmp/boot_trace
    adb pull /data/local/tmp/boot_trace
    $ANDROID_BUILD_TOP/external/chromium-trace/systrace.py --from-file=boot_trace