Android : gouverneur CPU, ordonnanceur...

android 20 mars 2015

Je participe régulièrement sur le forum XDA-developers, en particulier pour les tests et développement de CyanogenMod (dans sa version 12 actuellement, base Android 5.0.2) sur le LG G3 (d855) et le Google/LG Nexus 4 que je possédais, mais que j’ai offert à la dame de mes pensées en remplacement de son smartphone agonisant. Je faisais la même chose avant avec mes anciens téléphones/tablettes.

Et j’ai pu constater une chose : deux des paramètres clés du paramétrage de son noyau Android (à savoir l’ordonnanceur et le gouverneur du processeur) sont souvent balancés « tel quel », sans explications.Si le lecteur ne sait pas ce que représentent ces réglages, ni ce qui différencie tel ou tel ensemble de réglages d’un autre, comment peut-il choisir celui qui lui convient le mieux ?

On va donc voir aujourd’hui en quoi consistent ces réglages, et en passer quelques-uns en revue (au moins ceux intégrés au noyau de CyanogenMod 12) pour vous aider à choisir celui qui serait a priori le plus adapté à vos besoins.

 

cid_cm
Cid, la mascotte de CyanogenMod

 

Un gouverneur de CPU, ça sert à quoi ?

Tout simplement, ça sert à adapter la fréquence à laquelle fonctionne le processeur de votre smartphone/tablette à l’utilisation qui en est faite à un moment donné, le but étant de monter cette fréquence lorsque vous demandez au bouzin de faire quelque chose et de la baisser lorsque vous l’utilisez moins/pas. Une fréquence de fonctionnement élevée, c’est davantage de consommation énergétique, donc une autonomie sur batterie bien moindre…

Reste à voir quelle stratégie correspond le mieux à ce que vous attendez : un téléphone qui réagit à la moindre sollicitation ? Un téléphone moins rapide mais qui tient plus de 2h sur batterie ? Chacun son choix !

Pour qu’un processeur réalise davantage d’opérations par seconde, il faut augmenter sa fréquence d’horloge. Disons qu’à chaque impulsion électrique, le processeur effectue un calcul. Plus j’envoie d’impulsions sur un même laps de temps, plus il va réaliser de calculs dans ce même laps de temps. La fréquence, c’est ça : 1 Hertz correspond à un cycle d’horloge (soit l’impulsion et le « temps mort » avant la prochaine impulsion). Plus on monte la fréquence, plus on a d’impulsions sur un même laps de temps, plus le traitement des informations par le microprocesseur est rapide. Ces impulsions étant toujours les mêmes en terme de signal électrique, si mon processeur consomme x Watt/heure à une fréquence de 1,5GHz, alors si je monte sa fréquence à 3GHz, il va consommer 2x Watt/heure (deux fois plus de courant). Voilà pour la relation entre la consommation et la performance brute. D’où l’intérêt de trouver le compromis qui vous correspond le mieux !

Dans le noyau stock de CM12 (alors, stock signifie que c’est le noyau d’origine, non trafiqué par un développeur tiers, vu que vous pouvez très bien décider de changer de noyau pour tout un tas de raisons), on trouve 6 gouverneurs (ce ne sont pas les seuls !) : ondemand, interactive, conservative, userspace, powersave et performance. Détaillons-les.

 

 

 

Ondemand

C’est le gouverneur par défaut de la plupart des noyaux, même si Interactive (voir en dessous) est également assez répandu. Basiquement, son rôle est de faire monter le processeur à sa fréquence maximale quand celui-ci reçoit une tâche, afin de donner à l’utilisateur l’impression d’un système réactif. Une fois la tâche effectuée, il redescendra par paliers à sa fréquence minimale, sauf si l’utilisateur effectue une autre tâche entre temps. Ses paramètres par défaut (évaluer la charge processeur à un instant t très court [en fonction de la liste des tâches à effectuer à ce moment, en fait], ce qui ne reflète que rarement l’utilisation réelle du processeur) provoquent de très nombreux sauts de fréquence, ce qui consomme pas mal d’énergie. Et en plus, ces sauts sont un handicap pour les utilisateurs à la recherche de performance. Cela dit, c’est un bon compromis pour l’utilisateur moyen.

 

Interactive

Ce gouverneur fonctionne globalement comme Ondemand : il adapte dynamiquement la fréquence du CPU en fonction de la charge de travail qu’il reçoit de l’utilisateur. Interactive est clairement assez sensible et a tendance à monter rapidement à la fréquence maximale autorisée. Par rapport à Ondemand, il gère bien mieux les enchaînements de tâches et fait donc moins « yo-yo » entre les fréquences max et min, ceci en particulier parce qu’il évalue la charge réelle du processeur sur un intervalle de temps plus long. Autre conséquence de cet état de fait : interactive a tendance à utiliser davantage les paliers intermédiaires dans les fréquences du processeur : c’est transparent pour l’utilisateur, et ça permet d’économiser un peu la batterie !

Interactive part également du principe que si l’utilisateur allume l’écran du périphérique, c’est qu’il va l’utiliser. Du coup, l’allumage de l’écran déclenche un saut rapide à la fréquence maximale, et le gouverneur reprend ensuite sa logique basée sur un timer.

C’est le gouverneur par défaut de CyanogenMod 12.

 

Conservative

Ce gouverneur demande au CPU de rester le plus souvent possible à sa fréquence minimale. En gros, avant de sauter à la fréquence maximale, il faudra appliquer au processeur une charge plus importante (et plus longtemps !) que dans le cas de Ondemand ou Interactive. Conséquences majeures : l’autonomie s’en trouve grandement améliorée, mais l’utilisateur risque d’avoir souvent l’impression d’utiliser un gros diesel : le téléphone va « ramer » un peu, puis tout va s’accélérer, puis ralentir, et ainsi de suite. Pour mieux vous représenter la chose, c’est un genre de Ondemand en plus lent.

 

Userspace

C’est un gouverneur que l’on ne trouve que dans peu de noyaux, à dire vrai. Concrètement, il ne prend pas en compte ses propres réglages de fréquence, mais laisse à l’application qui s’exécute le choix de la fréquence à laquelle il doit faire tourner le processeur. On le trouve bien plus souvent sur les serveurs ou les PC de bureau…  où une application X ou Y (typiquement un programme qui gère des profils de performance) doit pouvoir adapter cette fréquence elle-même. Attention à la consommation de batterie, du coup.

 

Powersave

Celui-ci est tout simple : la fréquence du processeur est bloquée sur la fréquence minimale définie par l’utilisateur. Alors ça se ressent évidemment sur l’autonomie, qui s’en sort grandie. Mais côté performances… Un processeur à 4 cœurs bloqué à 300MHz au lieu des 2,5GHz maximum (le cas de mon smartphone, à titre d’exemple), ça fait mal. Faut pas en demander plus que l’envoi de quelques SMS, quoi. Mais pour l’utilisateur qui se sert d’un smartphone comme d’un 3310 (et ça n’est pas une critique), c’est parfait !

 

Performance

C’est l’opposé de Powersave : la fréquence d’horloge du processeur est bloquée sur la fréquence maximale définie par l’utilisateur. Réactivité de fou, fluidité maximale, le téléphone avale les tâches sans sourciller. M’enfin à ce niveau là, ne sortez jamais sans chargeur, quoi.

 

Évidemment, cette liste n’est pas exhaustive : d’autres gouverneurs ont été développés, souvent à partir de ceux décrits ici, afin d’améliorer l’autonomie, ou les performances, ou de créer un équilibre entre les deux… Si vous utilisez un gouverneur particulier que vous voudriez voir figurer ici, demandez !

 

Android-Developer2

 

Et les ordonnanceurs, c’est quoi ?

C’est le second paramètre essentiel dont nous allons causer aujourd’hui. L’ordonnanceur, c’est le composant du noyau d’Android qui gère l’ordre d’exécution des tâches par le processeur : si un processus est crucial pour le fonctionnement du périphérique, il semble évident qu’il doit être exécuté plus rapidement (voire avant) votre envoi de Snapchat. T’façons, si le téléphone crashe, il ne sera pas envoyé non plus, alors autant faire les choses dans l’ordre.

L’ordonnanceur est donc chargé d’attribuer un processus à un cœur de votre processeur (c’est ce qu’on appelle l’affinité), et de prioriser certaines tâches, quitte à en interrompre une en cours de traitement pour laisser le processus jugé plus important s’exécuter en priorité. Il gère également les accès au support de stockage (recherche, lecture/écriture…). Il s’assure aussi d’éviter un phénomène qu’on appelle la famine : ce serait le cas où un processus se fait « doubler » dans la file d’attente par les autres processus, sans que lui n’atteigne jamais le bout de la file. Il ne serait alors jamais traité… Et c’est un vrai problème. Un ordonnanceur doit garantir qu’en un temps fini, tout processus ait une probabilité non nulle d’être traité.

 

 

Dans le noyau stock de CyanogenMod 12, on trouve les ordonnanceurs suivants, que nous allons détailler : noop, deadline, row, et cfq.

 

Noop

Cet ordonnanceur d’Entrées/Sorties (E/S pour la suite, parce que je suis une grosse feignasse) traite les demandes dans l’ordre d’arrivée : First In, First Out. Il est cependant capable de fusionner des requêtes compatibles (faut pas déconner non plus). C’est un mode de fonctionnement qui convient bien aux mémoires flash de nos smartphones, qui ne reposent pas sur un mouvement mécanique (contrairement aux disques durs) et ne demandent donc pas de réorganiser les requêtes pour minimiser les déplacements du bras.

Un avantage indéniable, c’est que Noop traite les demandes d’E/S avec un minimum de cycles processeur. Il serait plus économe en batterie.

 

Deadline

Le but de Deadline, c’est ni plus ni moins que de réduire au maximum la latence d’E/S (le temps entre l’arrivée d’une requête et son traitement). Pour cela, l’ordonnanceur utilise 5 files d’attente pour réorganiser dynamiquement les requêtes, et c’est agressif, il ne tergiverse pas trop sur la réorganisation et/ou la fusion, celui-ci.

L’avantage, c’est que Deadline se rapproche énormément d’un ordonnanceur « temps réel » et qu’il est très efficace pour réduire les temps d’accès. Il est très approprié pour les recherches en base de données. Il calcule vite et bien le temps processeur à allouer à tel ou tel processus. Comme Noop, il est plutôt orienté vers les mémoires flash et disques SSD.

 

ROW

ROW (Read Over Write), comme son nom l’indique, favorise les requêtes de lecture sur celles d’écriture.

Il a été développé spécifiquement pour les périphériques mobiles : qu’attend l’utilisateur ? De la réactivité. Quand il demande quelque chose, il faut le lui fournir rapidement. Donc lecture avant tout. Et c’est efficace.

C’est l’ordonnanceur E/S par défaut de CyanogenMod, aussi bien sur la mémoire flash interne que sur la carte SD externe.

 

CFQ

CFQ (Completely Fair Queuing) est un peu l’ordonnanceur passe-partout. Il cherche l’équilibre entre lecture et écriture. De fait, il n’excelle ni sur l’un, ni sur l’autre, étant donné qu’il alloue autant de bande passante à l’un qu’à l’autre… CFQ fait des statistiques pour « deviner » quel bloc du disque sera demandé par quel processus, cela lui sert pour définir les priorités de traitement.

Il est très bon sur les systèmes à plusieurs processeurs.

 

Pour finir…

Alors comme je l’ai déjà précisé, je traite ici les gouverneurs et ordonnanceurs « par défaut » de CyanogenMod. Il en existe beaucoup d’autres, dans d’autres noyaux.

Je sens la question arriver, donc j’anticipe : si CyanogenMod permet de modifier certains de ces paramètres via le menu « Performances » des paramètres système, il existe des applications (moult applications, même) qui, moyennant l’octroi des droits superutilisateur (le fameux root), feront la même chose et plus encore, comme définir les paliers de fréquence, les conditions de saut de fréquence… ce que ne fait pas CyanogenMod de base.

Ma préférence va à Kernel Audiutor, croisé par hasard dans le dépôt logiciel de mon smartphone, j’ai nommé F-Droid. Kernel Audiutor est libre et gratuit.

Au menu :

  • gestion du processeur (gouverneur, fréquences, tensions)
  • gestion du processeur graphique (gouverneur, fréquences)
  • gestion de la colorimétrie de l’écran
  • réveil du téléphone (sweep2wake, doubletap2wake)
  • amélioration de la qualité sonore (support de Faux, un ensemble d’améliorations quant au volume, aux distorsions…)
  • gestion de la batterie (dont la charge rapide, si le périphérique le supporte)
  • ordonnanceur E/S
  • Kernel Samepage Merging (réduit l’utilisation de la mémoire vive, mais augmente l’utilisation du processeur)
  • Low Memory Killer (qui définit en gros à quel moment « tuer » une application en arrière-plan, dans le cas où on manquerait de mémoire vive)
  • et plein d’autres !

 

Je vous laisse donc vous amuser avec tout ça ! Et si vous voulez que vos changements soient permanents, n’oubliez pas le petit bouton « appliquer au démarrage » ! 😉

Mots clés