Capacidade é a quantidade total de algum recurso (CPU, GPU, etc.) que um dispositivo possui durante um determinado período de tempo. Esta página descreve como identificar e resolver problemas de instabilidade relacionados à capacidade.
Governador demora a reagir
Para evitar interrupções, o regulador de frequência da CPU precisa ser capaz de responder rapidamente a cargas de trabalho em rajadas. A maioria dos aplicativos de UI segue o mesmo padrão básico:
- O usuário está lendo a tela.
- O usuário toca a tela: toca em um botão, rola, etc.
- A tela rola, altera a atividade ou é animada de alguma forma em resposta à entrada.
- O sistema é desativado conforme novo conteúdo é exibido.
- O usuário volta a ler a tela.
Os dispositivos Pixel e Nexus implementam aumento de toque para modificar o comportamento do regulador de frequência da CPU (e do agendador) no toque. Para evitar uma rampa lenta para uma frequência de clock alta (o que pode fazer com que o dispositivo perca quadros ao toque), o aumento de toque geralmente define um limite mínimo de frequência na CPU para garantir que haja bastante capacidade da CPU disponível no toque. Um piso dura algum tempo após o toque (geralmente cerca de dois segundos).
O Pixel também usa o cgroup schedtune fornecido pelo Energy Aware Scheduling (EAS) como um sinal adicional de aumento de toque: os principais aplicativos recebem peso adicional por meio do schedtune para garantir que obtenham capacidade de CPU suficiente para serem executados rapidamente. O Nexus 5X e 6P têm uma diferença de desempenho muito maior entre os pequenos e grandes clusters de CPU (A53 e A57, respectivamente) do que o Pixel com CPU Kryo. Descobrimos que o pequeno cluster de CPU nem sempre era adequado para uma renderização suave da IU, especialmente devido a outras fontes de instabilidade no dispositivo.
Da mesma forma, no Nexus 5X e 6P, o touch boost modifica o comportamento do agendador para aumentar a probabilidade de os aplicativos em primeiro plano migrarem para os grandes núcleos (isso é conceitualmente semelhante ao piso da frequência da CPU). Sem a alteração do agendador para aumentar a probabilidade de os aplicativos em primeiro plano migrarem para o grande cluster de CPU, os aplicativos em primeiro plano podem ter capacidade de CPU insuficiente para renderização até que o agendador decida balancear a carga do thread para um grande núcleo de CPU. Ao alterar o comportamento do agendador durante o touch boost, é mais provável que um thread de UI seja executado imediatamente em um grande núcleo e evite instabilidade, sem forçá-lo a sempre ser executado em um grande núcleo, o que pode ter impactos graves no consumo de energia.
Estrangulamento térmico
A aceleração térmica ocorre quando o dispositivo deve reduzir sua produção térmica geral, geralmente realizada reduzindo os clocks da CPU, GPU e DRAM. Não é de surpreender que isso geralmente resulte em instabilidade, pois o sistema pode não ser mais capaz de fornecer capacidade suficiente para renderizar dentro de um determinado intervalo de tempo. A única maneira de evitar o estrangulamento térmico é usar menos energia. Não há muitas maneiras de fazer isso, mas com base em nossas experiências com SOCs anteriores, temos algumas recomendações para fornecedores de sistemas.
Primeiro, ao construir um novo SOC com arquiteturas de CPU heterogêneas, certifique-se de que as curvas de desempenho/W dos clusters de CPU se sobreponham. A curva geral de desempenho/W de todo o processador deve ser uma linha contínua. Descontinuidades na curva perf/W forçam o escalonador e o regulador de frequência a adivinhar o que uma carga de trabalho precisa; para evitar interrupções, o agendador e o regulador de frequência erram ao fornecer à carga de trabalho mais capacidade do que ela requer. Isso resulta no gasto excessivo de energia, o que contribui para o estrangulamento térmico.
Imagine um SOC hipotético com dois clusters de CPU:
- O cluster 1, o pequeno cluster, pode gastar entre 100-300mW e pontuar entre 100-300 em um benchmark de rendimento, dependendo dos clocks.
- O cluster 2, o grande cluster, pode gastar entre 1.000 e 1.600 mW e pontuar entre 800 e 1.200 no mesmo benchmark de rendimento, dependendo dos clocks.
Neste benchmark, uma pontuação mais alta é mais rápida. Embora não seja mais desejável que mais lento, mais rápido == maior consumo de energia.
Se o agendador acreditar que uma carga de trabalho de UI exigiria o equivalente a uma pontuação de 310 nesse benchmark de taxa de transferência, sua melhor opção para evitar erros é executar o grande cluster na frequência mais baixa, desperdiçando energia significativa. (Isso depende do comportamento da CPU e da corrida para a inatividade; SOCs com curvas contínuas de desempenho/W são mais fáceis de otimizar.)
Segundo, use cpusets. Certifique-se de ter habilitado cpusets em seu kernel e em seu BoardConfig.mk . Você também deve configurar as atribuições reais do cpuset no init.rc específico do dispositivo. Alguns fornecedores deixam isso desabilitado em seus BSPs na esperança de poder usar outras dicas para influenciar o comportamento do escalonador; achamos que isso não faz sentido. cpusets são úteis para garantir que o balanceamento de carga entre CPUs seja feito de uma forma que reflita o que o usuário está realmente fazendo no dispositivo.
O ActivityManager atribui aplicativos a diferentes cpusets com base na importância relativa desses aplicativos (superior, primeiro plano, segundo plano), com aplicativos mais importantes obtendo mais acesso aos núcleos da CPU. Isso ajuda a garantir a qualidade do serviço para aplicativos em primeiro plano e principais.
Os cpusets são úteis em configurações de CPU homogêneas, mas você não deve enviar um dispositivo com uma configuração de CPU heterogênea sem os cpusets habilitados. O Nexus 6P é um bom modelo de como usar cpusets em configurações de CPU heterogêneas; use isso como base para a configuração do seu próprio dispositivo.
Os cpusets também oferecem vantagens de energia, garantindo que threads de segundo plano que não são críticos para o desempenho nunca tenham carga balanceada para grandes núcleos de CPU, onde poderiam gastar significativamente mais energia sem qualquer benefício percebido pelo usuário. Isso também pode ajudar a evitar o estrangulamento térmico. Embora o estrangulamento térmico seja um problema de capacidade, as melhorias no jitter têm um impacto enorme no desempenho da UI durante o estrangulamento térmico. Como o sistema estará rodando mais perto de sua capacidade de renderizar 60FPS, é necessário menos instabilidade para causar a queda de um quadro.