A capacidade é a quantidade total de algum recurso (CPU, GPU, etc.) que um dispositivo possui em 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 instabilidade, o governador de frequência da CPU precisa ser capaz de responder rapidamente a cargas de trabalho em rajadas. A maioria dos aplicativos de interface do usuário segue o mesmo padrão básico:
- O usuário está lendo a tela.
- O usuário toca na tela: toca em um botão, rola, etc.
- A tela rola, altera a atividade ou anima de alguma forma em resposta à entrada.
- O sistema é desativado quando o novo conteúdo é exibido.
- O usuário volta a ler a tela.
Os dispositivos Pixel e Nexus implementam o impulso de toque para modificar o comportamento do governador 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 deixe cair quadros ao toque), o aumento de toque geralmente define um piso de frequência na CPU para garantir que a capacidade da CPU esteja disponível no toque. Um piso dura algum tempo após o toque (geralmente cerca de dois segundos).
O Pixel também usa o schedtune cgroup fornecido pelo Energy Aware Scheduling (EAS) como um sinal de aumento de toque adicional: os principais aplicativos ganham peso adicional via 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 clusters de CPU pequenos e grandes (A53 e A57, respectivamente) do que o Pixel com a CPU Kryo. Descobrimos que o pequeno cluster de CPU nem sempre era adequado para renderização suave da interface do usuário, especialmente devido a outras fontes de jitter no dispositivo.
Assim, no Nexus 5X e 6P, o touch boost modifica o comportamento do agendador para tornar mais provável que os aplicativos em primeiro plano se movam para os grandes núcleos (isso é conceitualmente semelhante ao piso na frequência da CPU). Sem a alteração do agendador para tornar os aplicativos em primeiro plano mais propensos a se mover para o cluster de CPU grande, os aplicativos em primeiro plano podem ter capacidade de CPU insuficiente para renderizar até que o agendador decida balancear a carga do thread para um núcleo de CPU grande. Ao alterar o comportamento do agendador durante o aumento de toque, é mais provável que um thread de interface do usuário seja executado imediatamente em um núcleo grande e evite instabilidade, sem forçar a execução sempre em um núcleo grande, o que pode ter impactos severos no consumo de energia.
Estrangulamento térmico
A limitação térmica ocorre quando o dispositivo deve reduzir sua saída térmica geral, geralmente realizada reduzindo os clocks da CPU, GPU e DRAM. Sem surpresa, isso geralmente resulta em instabilidade, pois o sistema pode não ser mais capaz de fornecer capacidade suficiente para renderizar em 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 para 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 instabilidade, o escalonador e o governador de frequência erram ao dar à carga de trabalho mais capacidade do que ela requer. Isso resulta em gastar muita 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 de 100-300 em um benchmark de taxa de transferência dependendo dos clocks.
- O cluster 2, o grande cluster, pode gastar entre 1.000 e 1.600 mW e pontua entre 800 e 1.200 no mesmo benchmark de taxa de transferência, dependendo dos clocks.
Neste benchmark, uma pontuação mais alta é mais rápida. Embora não seja mais desejável do que mais lento, mais rápido == maior consumo de energia.
Se o agendador acredita que uma carga de trabalho de interface do usuário exigiria o equivalente a uma pontuação de 310 nesse benchmark de taxa de transferência, sua melhor opção para evitar instabilidade é executar o cluster grande na frequência mais baixa, desperdiçando energia significativa. (Isso depende do comportamento do cpuidle e da corrida para ocioso; SOCs com curvas perf/W contínuas são mais fáceis de otimizar.)
Em segundo lugar, 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 em seu init.rc específico do dispositivo. Alguns fornecedores deixam isso desabilitado em seus BSPs na esperança de que possam usar outras dicas para influenciar o comportamento do agendador; sentimos que isso não faz sentido. cpusets são úteis para garantir que o balanceamento de carga entre CPUs seja feito de uma maneira 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 (parte 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.
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 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.
cpusets também oferecem vantagens de energia, garantindo que os 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 eles poderiam gastar significativamente mais energia sem nenhum benefício percebido pelo usuário. Isso também pode ajudar a evitar o estrangulamento térmico. Embora a limitação térmica seja um problema de capacidade, as melhorias de jitter têm um impacto desproporcional no desempenho da interface do usuário durante a limitação térmica. Como o sistema estará rodando mais próximo de sua capacidade de renderizar 60FPS, é preciso menos jitter para causar uma queda de quadro.