Como é que o Android gere as frequências do processador?

Com a grande poliferação do Android é importante percebermos como é que o nosso telemóvel escolhe as frequências do processador conforme as tarefas que vão sendo realizadas. Esta regulação é feita ao nível do Kernel e é ao mesmo tempo uma benção como uma maldição pois tão depressa melhora a bateria dos nossos dispositivos como a causa gastos de energia excessivos.

Vamos então conhecer as drivers responsáveis e como é que funcionam.

O Android é composto por várias camadas de software até chegarmos ao nível físico, o hardware. O Kernel é a camada mais baixa a nível do software e faz a ligação entre o userspace (ambiente de trabalho por exemplo) e os componentes do dispositivo. É como se fosse o motor de um carro. Sem um Kernel não haveria sistemas operativos.

Na directoria das drivers do Kernel há um conjunto de ficheiros que controlam a forma como as frequências, em megahertz, com que os nossos processadores funcionam. Este conjunto de algoritmos que estão directamente ligados com as drivers da arquitectura do processador é provavelmente um dos componentes mais importantes de um Kernel. Existem 4 algoritmos de base num Kernel: Performance, Ondemand, Conservative e Powersave. Estes algoritmos são chamados de Governors e estão presentes em todos os Kernels seja Android ou Linux.

A estrutura de dados que vai guardar as informações do CPU passa então a ter acesso às várias frequências do CPU (que são definidas nas drivers da arquitectura do mesmo). Vamos ter então três parametros para ter em atenção: frequencia_maxima, frequencia_minima e frequencia_actual. A frequencia_maxima é a velocidade máxima que o CPU pode atingir, a frequencia_minima é a velocidade mínima que o processador pode atingir e a frequencia_actual é a velocidade num instante de tempo em que o CPU está a funcionar. Se por exemplo o processador tiver uma tabela de frequências de 1000, 800, 400, 200, 100 (todos estes valores em megahertz) e definirmos freq_max = 1000, freq_min = 400 o Governor faz a gestão de uso de frequências que fiquem entre a freq_max e a freq_min. Essa gestão é feita com base na percentagem de load que o sistema está a usar do processador. Quanto mais load houver maior será a frequência a ser usada e vice-versa (tudo dentro da freq_max e freq_min como expliquei acima). E então é aqui que o algoritmo do Governor entra em acção.

Performance

O Governor Performance é muito simples, faz uma chamada às drivers da arquitectura do processador e pergunta lhes qual a frequência máxima que este consegue funcionar e quando recebe a resposta avisa o Android que o CPU passa a funcionar com a frequência mínima igual à frequência máxima, ou seja o CPU vai estar sempre à velocidade da freq_max independentemente do load. Este Governor é muito utilizado para fins de benchmarks pois não haverá latência na mudança de frequência durante todo o processo de bench. Fora isto este Governor vai ser muito caro a nível de energia e o dispositivo vai durar muito menos tempo. Quanto maior for a frequência utilizada maior é a quantidade de voltagem que o CPU necessita, logo maior será o consumo de energia.

Powersave

O Governor Powersave funciona exactamente ao contrário do Performance. Em vez da freq_min ficar igual à freq_max os papéis invertem-se e a frequência máxima vai ficar igual à mínima. Este Governor não tem nenhum interesse a nível real, e na minha opinião já deveria ter sido retirado.

Ondemand

O Governor Ondemand é um caso interessante e é aqui que as coisas se complicam um pouco. Este Governor aumenta ou diminui a frequência_actual conforme o load do sistema. Falando em valores defeito (isto pode ser tudo modificado facilmente, mas para explicar vamo-nos reger por valores que vêm de origem) quando o load for maior que 95% em 100% (100% significa que o CPU está a ser totalmente usado pelo, sistema) o algoritmo aumenta a frequência_actual para a freq_max. Por exemplo: freq_actual = 400, freq_max = 1000; quando load >= 98% freq_actual = freq_max (ficando então freq_actual = 1000). A freq_actual vai ficar ao máximo até o load for menor que 20%, só aí então é que a actual volta ao valor mínimo. Parece mais complicado do que parece mas é bastante simples, mas nenhuma destas "trocas" são perceptíveis ao utilizador comum pois isto é muito baixo nível. Este Governor é o escolhido por defeito em 99% dos telemóveis pois é o mais equilibrado em termos de bateria e performance.

Conservative

Por último temos o Governor Conservative. É em tudo igual ao Ondemand apenas com uma diferença, quando se atinge um load igual ou superior a 80% o algoritmo em vez de saltar para a freq_max salta apenas uma frequência acima da actual e vai saltando uma a uma até chegar à freq_max. Por exemplo: freq_actual = 100, freq_max = 1000; Quando load >= 80% freq_actual = 200; Se o load continuar a >= 80% durante X milisegundos freq_actual = 400, e por aí adiante até chegar ao máximo que neste caso seria 1000. Para voltar para trás usa exactamente o mesmo procedimento, uma a uma até chegar à freq_min. Este Governor é muito bom a nível de poupança de bateria, mas acaba por custar um bocado em termos de performance pois tem uma latência acrescida que vem das várias chamadas de sistema para ir mudando de frequência uma a uma e para verificar se o load ficou maior que 80% a cada X milisegundos.

Apesar de cariz ligeiramente técnico espero que este artigo possa servir para conhecerem melhor a forma como o Android e o Kernel gere a forma como o CPU se comporta quando estão a utilizar os vossos telemóveis.

Para alterarem os parâmetros dos Governors precisam de root e é tão simples quanto usarem a linha de comandos para mudarem os valores directamente na interface sysfs (fica para um artigo futuro). Caso não estejam familiarizados com terminal ou com adb podem usar a aplicação SetCPU (paga no Market, mas free para membros do XDA Developers).

Qualquer dúvida não hesitem em perguntar no espaço de comentários abaixo.