Os smartphones Google Pixel estão entre os telefones Android mais rápidos do mercado. O Energy Aware Scheduling (EAS) é em parte o motivo pelo qual o telefone é tão suave.
No passado, quando o Linux era apenas uma ideia na mente de Linus Torvalds, as CPUs eram entidades de núcleo único que exigiam uma imensa quantidade de energia com pouca energia. O primeiro processador disponível comercialmente, o Intel 4004, funcionava a uma freqüência de 740kHz em um único núcleo. Naquela época, não havia necessidade de um agendador de carregamento. O agendamento de carga foi reservado para os "gigantes" dual-core, como o IBM Power 4, lançado algumas décadas depois. Eles funcionavam a uma velocidade bestial de 1,1 GHz a 1,9 GHz e exigiam que os programas e o sistema utilizassem esses núcleos corretamente. Como passamos dessas máquinas para algoritmos de software que fazem uso de múltiplos núcleos? Você já deve ter ouvido falar do Energy Aware Scheduling (EAS) em nossos fóruns. É parte da razão pela qual os smartphones Google Pixel têm um desempenho tão bom. O que há de tão bom no EAS e como chegamos a esse ponto? Antes de podermos explicar isso, precisamos falar sobre os agendadores de carregamento do Linux.
A evolução dos agendadores de carga do Linux
Agendamento Round-Robin
O processamento round robin é um conceito simples de explicar e compreender, e ainda mais simples de compreender suas desvantagens. Round-robin usa divisão de tempo para alocar tempo para cada processo. Vamos supor que temos quatro processos em execução no nosso computador.
- Processo A
- Processo B
- Processo C
- Processo D
Agora, vamos fazer o trabalho do agendador round-robin. Alocaremos 100 milissegundos (divisão de tempo) para cada processo antes de passar para o próximo. Isso significa que o Processo A pode levar 100 milissegundos para ser processado, depois passa para o Processo B e assim por diante. Se o trabalho de um aplicativo leva 250 milissegundos para ser concluído, ele precisará passar por esse processo 3 vezes apenas para finalizar seu trabalho! Agora dimensione isso em diferentes núcleos, de modo que o Processo A e o Processo B sejam alocados para o núcleo 1, e o Processo C e o Processo D sejam alocados para o núcleo 2. Isso foi substituído pelo agendamento O(n) (que era como round-robin, mas usando épocas e permitindo a alocação dinâmica de tempo), depois agendamento O(1) (sobrecarga minimizada, suporte ilimitado ao processo) e, finalmente, o Agendador Completamente Justo (CFS). O CFS foi incorporado ao kernel Linux versão 2.6.23 em outubro de 2007. Ele foi revisado desde então e ainda é o agendador padrão em sistemas Linux.
Agendador Completamente Justo
O Completely Fair Scheduler existe no Android desde o seu início e é usado em empresas não grandes. PEQUENOS dispositivos. Ele usa um algoritmo inteligente para determinar a ordem de processamento, o tempo alocado, etc. É um exemplo de implementação funcional do algoritmo de escalonamento bem estudado denominado "enfileiramento justo ponderado". Basicamente, isso se concentra em fornecer prioridade aos processos do sistema e outros processos de alta prioridade em execução no máquina. Se fosse para funcionar em grande. PEQUENO dispositivo, todos os núcleos seriam percebidos como iguais. Isso é ruim, pois núcleos de baixo consumo de energia podem ser forçados a executar aplicações intensivas ou, pior ainda, pode ocorrer o contrário. A decodificação para ouvir música pode ser feita no grande núcleo, por exemplo, aumentando desnecessariamente o consumo de energia. É por isso que precisamos de um novo agendador para grandes projetos. LITTLE, aquele que pode realmente reconhecer e utilizar a diferença de núcleos de maneira eficiente em termos de energia. É aí que entra o multiprocessamento heterogêneo (HMP), o agendador de carregamento padrão que a maioria dos telefones Android está executando agora.
Multiprocessamento heterogêneo
Este é o agendador de carregamento padrão para qualquer grande. PEQUENO dispositivo lançado nos últimos anos, além do Google Pixel. O HMP faz uso do grande. Arquitetura POUCA, delegando trabalho de baixa prioridade e menos intensivo aos pequenos núcleos que consomem menos energia. O HMP é "seguro" porque sabe o que deve ir para os núcleos grandes e o que deve ir para os núcleos pequenos, sem cometer erros. Ele simplesmente funciona e requer muito menos esforço para ser configurado no lado do desenvolvimento do que algo como o EAS, do qual falaremos em breve. O HMP é apenas uma extensão do CFS para torná-lo consciente do poder.
O HMP não aceita suposições nem prevê processos futuros. Isso é bom, mas é por isso que o dispositivo não pode ser tão fluido quanto aqueles que executam EAS e também por que consome um pouco mais de bateria. Isso, finalmente, nos leva ao Energy Aware Scheduling (EAS), que acredito firmemente ser o futuro no desenvolvimento de ROM e kernel à medida que mais OEMs o adotam.
Agendamento com consciência de energia
O Energy Aware Scheduling (EAS) é a próxima grande novidade sobre a qual os usuários em nossos fóruns estão falando. Se você usa um OnePlus 3 (ou Google Pixel, obviamente), com certeza já ouviu falar dele nos fóruns. Ele foi lançado no mercado com o Qualcomm Snapdragon 845, portanto, se você possui um desses dispositivos, já possui um smartphone habilitado para EAS. EAS na forma de kernels como RenderZenith e ROMs como Vertex OS e PureFusion estavam conquistando os fóruns do OnePlus 3 em seu auge. Claro, o Google Pixel também vem com EAS. Com as promessas de maior duração da bateria e melhor desempenho, qual é o problema?
O Energy Aware Scheduling não é tão simples quanto não é universal para todos os dispositivos como CFS ou HMP. O EAS requer uma compreensão do processador em que está sendo executado, com base em um modelo de energia. Esses modelos de energia são feitos por equipes de engenheiros testando e trabalhando constantemente para oferecer um desempenho ideal. Como o Snapdragon 820 e 821 são basicamente iguais, os kernels personalizados no OnePlus 3 usam o modelo de energia do Google Pixel. Dispositivos com Snapdragon 845 podem utilizar EAS, e o OnePlus 6 o faz até certo ponto. Não é tão ajustado quanto um dispositivo Google Pixel seria, mas dá conta do recado. Aqui está um exemplo de como, apesar do OnePlus 6 ter um processador melhor com EAS, o Pixel 2 XL ainda supera em suavidade. Ambas as imagens foram tiradas do nosso revisão orientada para a velocidade do OnePlus 6.
Se você tiver dificuldade para entender os gráficos, dê uma olhada na imagem abaixo para orientação. Qualquer coisa que exceda a linha verde indica queda de quadros e, no pior dos casos, gagueira perceptível.
A implementação do EAS no OnePlus 6 é interessante, pois não parece ser uma implementação completa como você encontraria em um Google Pixel com o mesmo SoC. Os ajustes do agendador também não fazem muito sentido, então isso provavelmente explica por que não é tão eficiente em termos de desempenho quanto você esperaria. É extremamente conservador no consumo de energia, com o sistema priorizando os núcleos de baixo consumo de energia para a maior parte do trabalho.
Tunables são simplesmente um conjunto de parâmetros que são passados ao governador da CPU, que altera a forma como o governador reage a determinadas situações em termos de frequência. O escalonador então decide onde colocará as tarefas em diferentes processadores. Os ajustáveis do OnePlus 6 são configurados para priorizar o trabalho em núcleos de baixa potência. Também não ajuda o fato de o Google Pixel 2 ter um grande aumento de entrada, mantendo todos os 8 núcleos online o tempo todo. O Google também usa um balanceador de interrupção o que ajuda a remover quedas de quadros e melhorar o desempenho.
Então, como funciona o EAS? Por que é tão eficiente apenas em certas condições?
O Energy Aware Scheduling introduz a necessidade de usar um modelo de energia e, como mencionado acima, requer muitos testes e trabalho para torná-lo perfeito. O EAS tenta unificar três partes principais diferentes do núcleo, que atuam de forma independente, e o modelo energético ajuda a unificá-las.
- Agendador Linux (CFS, mencionado acima)
- CPU do Linux
- CPUfreq do Linux
Unificar todas as 3 partes do programador e calculá-las em conjunto proporciona um potencial de poupança de energia, uma vez que calculá-las em conjunto permite que sejam tão eficientes quanto possível. CPUIdle tenta decidir quando a CPU deve entrar no modo inativo, enquanto CPUFreq tenta decidir quando aumentar ou diminuir a CPU. Ambos os módulos têm como objetivo principal economizar energia. Além disso, ele categoriza os processos em quatro cgroups, sendo top-app, system-background, foreground e background. As tarefas a serem processadas são colocadas em uma dessas categorias e, em seguida, a categoria recebe energia da CPU e o trabalho é delegado em diferentes núcleos da CPU. top-app é a prioridade mais alta de conclusão, seguida por primeiro plano, segundo plano e, em seguida, segundo plano do sistema. O plano de fundo tecnicamente tem a mesma prioridade que o plano de fundo do sistema, mas o plano de fundo do sistema geralmente também tem acesso a mais núcleos pequenos. Na verdade, o Energy Aware Scheduling está pegando partes essenciais do kernel Linux e unificando tudo em um único processo.
Ao ativar o dispositivo, o EAS escolherá o núcleo no estado ocioso mais superficial, minimizando a energia necessária para ativar o dispositivo. Isso ajuda a reduzir a energia necessária no uso do dispositivo, pois ele não ativará o cluster grande se não for necessário. O rastreamento de carga também é uma parte extremamente importante do EAS e há duas opções. "Per-Entity Load Tracking" (PELT) geralmente é usado para rastreamento de carga, as informações são então usadas para decidir frequências e como delegar tarefas na CPU. "Window-Assisted Load Tracking" (WALT) também pode ser usado e é o que é usado no Google Pixel. Muitas ROMs EAS em nossos fóruns, como VertexOS, optam por usar WALT. Muitas ROMs lançarão duas versões do kernel com WALT ou PELT, então cabe ao usuário decidir. WALT é mais intermitente, com picos altos na frequência da CPU, enquanto o PELT tenta permanecer mais consistente. Na verdade, o rastreador de carga não afeta a frequência da CPU, apenas informa ao sistema qual está o uso da CPU. Um uso mais alto da CPU requer uma frequência mais alta e, portanto, uma característica consistente do PELT é que ele faz com que a frequência da CPU aumente ou diminua lentamente. O PELT tende a se desviar para relatórios de maior carga de CPU, portanto pode fornecer maior desempenho com maior custo de bateria. Ninguém pode realmente dizer neste momento qual sistema de rastreamento de carga é melhor, já que ambos os métodos de rastreamento de carga estão sendo continuamente corrigidos e refinados.
De qualquer forma, é óbvio que, independentemente do método de rastreamento de carga utilizado, há um aumento na eficiência. Em vez de apenas processar tarefas em qualquer processador, a tarefa é analisada e a quantidade de energia necessária para executá-la é estimada. Esse posicionamento inteligente de tarefas significa que as tarefas são concluídas de maneira muito mais eficiente, ao mesmo tempo que torna o sistema como um todo mais rápido. O objetivo do EAS é obter a interface de usuário mais suave possível com uso mínimo de energia. É aqui que outros componentes externos, como o schedtune, entram em ação.
Schedtune é definido em cada cgroup por dois ajustáveis que garantem um controle mais preciso sobre as tarefas a serem concluídas. Ele não apenas controla a distribuição de tarefas em várias CPUs, mas também se a carga percebida deve ser aumentada para garantir que tarefas urgentes sejam concluídas mais rapidamente. Dessa forma, os aplicativos e serviços em primeiro plano que o usuário utiliza não ficarão lentos e causarão problemas de desempenho desnecessários.
Embora o Energy Aware Scheduling seja a próxima grande novidade, também pode-se argumentar que já está aqui e já existe há algum tempo. Com cada vez mais dispositivos chegando ao mercado com o Energy Aware Scheduling, uma nova era de eficiência de processamento móvel está aqui.
Os prós e contras do Round-Robin, CFS, HMP e EAS
Embora minhas habilidades gráficas sejam inferiores, criei uma imagem que deve resumir quais são os prós e os contras de cada um desses agendadores.
Gostaria de estender um agradecimento especial ao Colaborador Reconhecido do XDA Mostafa Wael cujas explicações sobre vários aspectos do EAS ajudaram muito a tornar este artigo possível. Também gostaria de agradecer ao desenvolvedor reconhecido pelo XDA alegre, Desenvolvedor reconhecido pelo XDA Renderização quebrada e Mostafa Wael por seu artigo sobre EAS. Para aqueles que se interessaram por peças relacionadas ao EAS, Linaro tem muita documentação sobre EAS que você pode ler.