Il serait raisonnable de supposer que pour le noyau, il serait assez facile de ne rien faire - mais ce n'est pas le cas. Lors de la conférence
Kernel Recipes 2018 ,
Rafael Vysotsky a parlé de ce que font les processeurs, quand ils n'ont rien à faire, comment le noyau le traite, quelle est sa stratégie actuelle et comment ses récents travaux sur le
cycle d'inactivité ont amélioré la situation énergétique des systèmes qui ne font rien. .
Le cycle d'inactivité, l'un des sous-systèmes du noyau pris en charge par Vysotsky, contrôle ce que fait le processeur lorsqu'il n'a besoin d'exécuter aucun processus. Vysotsky a donné très précisément toutes les définitions: un processeur est une entité qui peut recevoir des instructions de la mémoire et les exécuter simultanément avec d'autres entités du même système qui traitent de la même chose. Sur le système monoprocesseur le plus simple avec un seul cœur, ce cœur est le CPU. Si le processeur a plusieurs cœurs, chacun de ces cœurs est un processeur. Si chacun des cœurs possède plusieurs interfaces pour exécuter des instructions simultanément - Intel appelle un tel système "
hyperthreading " - alors chacun de ces threads sera un CPU.
Le CPU est inactif lorsqu'il n'a aucune tâche à effectuer. Ou, plus précisément, le noyau Linux possède plusieurs classes internes pour la répartition, dont l'une est une classe inactive spéciale. S'il n'y a aucune tâche sur ce CPU dans aucune des classes, à l'exception de la classe d'inactivité, le CPU est considéré comme inactif. Si l'équipement ne le permet pas, le CPU devra exécuter des instructions inutiles jusqu'à ce que le vrai travail se présente. Cependant, il s'agit d'une utilisation extrêmement inefficace de l'électricité, c'est pourquoi la plupart des processeurs prennent en charge plusieurs états à faible énergie dans lesquels le cœur les transfère jusqu'à ce qu'ils soient nécessaires pour effectuer un travail utile.
Vous ne pouvez pas simplement entrer ou sortir d'un état d'inaction. Il faut du temps pour entrer et sortir, et en outre, lorsque vous entrez dans cet état, la consommation d'énergie de l'état actuel augmente légèrement et lorsque vous le quittez, il consomme l'état dans lequel le processeur entre. Et bien que plus l'état d'inactivité est profond, moins le processeur consomme d'énergie, le coût d'entrée et de sortie dans de tels états augmente. Cela signifie que dans le cas de courtes périodes d'inactivité, la meilleure utilisation des ressources informatiques sera une inaction superficielle; pour des périodes plus longues, le coût du passage à un état d'inaction plus profond sera justifié par une augmentation de la quantité d'énergie économisée. Par conséquent, il est dans l'intérêt du noyau de prédire combien de temps le processeur sera inactif avant de décider de la profondeur de l'état d'inactivité dont il a besoin. C'est la tâche du cycle d'inaction.
Dans ce cycle, le planificateur remarque que le CPU est inactif, car il n'a aucune tâche qui pourrait lui être affectée. Ensuite, l'ordonnanceur appelle le régulateur, qui essaie de donner la meilleure prédiction de l'état d'inaction approprié, que vous pouvez entrer. Maintenant, dans le noyau, il y a deux contrôles, le menu et l'échelle. Ils sont utilisés dans différents cas, mais les deux essaient de faire à peu près la même chose: pour surveiller l'état du système lorsque le processeur passe en mode inactif et le temps qu'il a passé en inactivité. Ceci est fait afin de prédire combien de temps le CPU entrera dans un état inactif et, par conséquent, quel état est le mieux adapté à cette situation.
Ce travail est particulièrement compliqué par le temporisateur du programmateur CPU. Le planificateur démarre ce temporisateur pour partager le temps d'accès au CPU: si plusieurs tâches doivent être effectuées sur un processeur, chacune d'elles ne peut être exécutée que peu, puis reportée périodiquement au profit d'une autre tâche. Ce temporisateur n'a pas besoin d'être exécuté sur un processeur inactif, car il n'y a pas de tâches entre lesquelles le processeur doit être divisé. De plus, si le temporisateur est autorisé à s'exécuter sur un processeur inactif, cela empêchera le contrôleur de sélectionner des états de ralenti profond, limitant les intervalles pendant lesquels le processeur est inactif. Par conséquent, dans les noyaux jusqu'à 4.16, le planificateur a désactivé le temporisateur avant d'appeler le régulateur. Lorsque le CPU s'est réveillé lors d'une interruption, le planificateur a décidé s'il y avait des tâches nécessaires à l'exécution et, le cas échéant, a redémarré le temporisateur.
Si le contrôleur prédit une longue période d'inactivité, et que cette période s'avère vraiment longue, alors le contrôleur «gagne»: le CPU entre dans un état d'inactivité profonde et l'énergie est économisée. Mais si le régulateur prédit une longue période d'inactivité, et que cette période s'avère courte, alors le régulateur «perd», car le coût d'entrer dans une inaction profonde ne paie pas en économisant de l'énergie pour une courte période d'inactivité. Pire encore, lorsque le régulateur prédit un court temps d'arrêt, il «perd» quel que soit le temps d'arrêt: si la période s'est avérée longue, il a raté l'opportunité d'économiser, et s'il était court, les coûts d'arrêt et de redémarrage de la minuterie étaient perdus. Ou, en d'autres termes, étant donné que les ressources sont dépensées pour arrêter et démarrer le minuteur, cela n'a aucun sens de l'arrêter lorsque le contrôleur prédit un court temps d'arrêt.
Vysotsky a décidé d'essayer de changer le fonctionnement du régulateur, mais est parvenu à la conclusion que le principal problème est que la minuterie est arrêtée avant l'appel du régulateur, c'est-à-dire avant que l'état d'inactivité recommandé ne soit connu. Il a renvoyé un cycle d'inactivité dans le noyau 4.17 afin que la décision d'arrêter le temporisateur soit prise après que le régulateur a fait sa recommandation. S'il prédit un long temps d'arrêt, le chronomètre s'arrête pour ne pas réveiller le CPU à l'avance. Si le temps d'arrêt est supposé être court, le temporisateur est laissé de manière à ne pas gaspiller les ressources lors des arrêts. Cela signifie que le temporisateur remplit également une fonction de sécurité, réveillant le CPU si le temps d'arrêt s'avère plus long que prévu et donnant au régulateur une seconde chance pour la bonne décision.
Lorsqu'un processeur inactif se réveille par une interruption, qu'il s'agisse d'un minuteur imparable ou d'un autre événement, le planificateur prend immédiatement une décision quant à la disponibilité du travail. S'il y a du travail, la minuterie redémarre si nécessaire. Sinon, le contrôleur est appelé. Comme cela signifie que le régulateur peut maintenant être appelé à la fois lorsque la minuterie fonctionne et lorsqu'il ne fonctionne pas, le régulateur doit être appelé pour en tenir compte.
Après avoir étudié le tableau des victoires et des défaites, Vysotsky estime que ses changements amélioreront l'image. Dans le cas de la prévision d'une longue période d'inactivité, la minuterie s'arrête toujours, donc rien ne change ici; nous gagnons si le temps d'arrêt est long et nous perdons s'il est court. Mais si une courte période d'indisponibilité est prévue, nous gagnons: si la période s'avère vraiment courte, nous économiserons sur l'arrêt et le démarrage de la minuterie, et si elle est longue, une minuterie non arrêtée nous réveillera et nous donnera l'opportunité de faire une autre prédiction.
Étant donné que la théorie des jeux ne peut pas remplacer complètement la situation réelle, Vysotsky a testé cette approche sur de nombreux systèmes. Le graphique ci-dessus est typique pour tous les systèmes testés; il montre la dépendance temporelle de la consommation d'énergie sur un système inactif. La ligne verte est l'ancien cycle d'inaction, la ligne rouge est la nouvelle. Selon le nouveau schéma, moins d'énergie est consommée, en plus, elle est plus prévisible. Tous les processeurs testés n'ont pas un si grand écart entre les lignes, mais ils ont tous montré une ligne rouge plate sous un vert inégal. Comme l'a dit Vysotsky, ce nouveau schéma est moins susceptible de prédire de courtes périodes d'inactivité, mais le plus souvent, il se révèle juste quant à leur courte durée.
Répondant à une question du public, Vysotsky a déclaré que ce travail dépend de l'architecture. En particulier, les processeurs Intel en bénéficieront, car ils ont une gamme assez large d'états d'inactivité parmi lesquels le régulateur peut choisir celui qui lui donnera les meilleures chances de succès si la prédiction est correcte; mais les processeurs ARM bénéficieront également des nouveaux circuits.
Une baisse de 20% de la consommation d'énergie au repos peut sembler insignifiante, mais ce n'est pas le cas. Tout système qui veut faire face assez bien aux charges de pointe devrait avoir une réserve de puissance en mode normal, qui se manifestera pendant l'inactivité. Le graphique ci-dessus montre l'utilisation du processeur pour l'année sur mon serveur, qui traite du courrier, du transfert de fichiers, du VPN, du NTP, etc. Le jaune signifie le temps simple. Économiser 20% de cette énergie serait apprécié par mon fournisseur, et pour la planète, ce serait mieux.