{"id":265,"date":"2011-03-04T16:00:01","date_gmt":"2011-03-04T15:00:01","guid":{"rendered":"http:\/\/www.blaess.fr\/christophe\/?p=265"},"modified":"2011-03-04T16:00:01","modified_gmt":"2011-03-04T15:00:01","slug":"temps-reel-et-economie-d-energie-1","status":"publish","type":"post","link":"https:\/\/www.blaess.fr\/christophe\/2011\/03\/04\/temps-reel-et-economie-d-energie-1\/","title":{"rendered":"Temps-r\u00e9el et \u00e9conomie d’\u00e9nergie (1)"},"content":{"rendered":"

(Cet article est un extrait de la version pr\u00e9paratoire de mon livre \u00ab\u00a0Applications temps-r\u00e9el avec Linux<\/em>\u00a0\u00bb en cours d’\u00e9criture)<\/p>\n

 <\/p>\n

\u00c9conomie ou performance : arbitrage pour le temps-r\u00e9el embarqu\u00e9 (Partie 1)<\/h1>\n

Sur la plupart des syst\u00e8mes interactifs, la charge du processeur varie en permanence entre des \u00e9tats d’intense activit\u00e9 (calcul, compilation, compression, encodage, etc.) et des p\u00e9riodes de repos durant lesquelles aucune op\u00e9ration n’a lieu, jusqu’\u00e0 la prochaine sollicitation provenant de l’utilisateur.<\/p>\n

\n\n<\/p>\n

En fait, sur un syst\u00e8me de type bureautique, la charge est g\u00e9n\u00e9ralement tr\u00e8s basse, et la puissance compl\u00e8te du processeur n’est n\u00e9cessaire que pendant des pics d’activit\u00e9 ponctuels. Voici par exemple la charge de la station Linux sur laquelle je r\u00e9dige ces lignes\u00a0:<\/p>\n

$ uptime<\/strong>\n11:44:07 up 29 days,  2:26,  9 users,  load average: 0.11, 0.10, 0.08\n$<\/pre>\n
La commande uptime(1)<\/a> permet de voir la charge du syst\u00e8me (le nombre moyen de t\u00e2ches en ex\u00e9cution ou en attente d’ex\u00e9cution) pour la derni\u00e8re minute (0.11 ici), les cinq (0.10) et quinze (0.08) derni\u00e8res minutes. Nous pouvons estimer que sur cet exemple le processeur n’est utilis\u00e9 en moyenne que 10% du temps environ. Naturellement, il y a d’autres moments o\u00f9 la charge peut-\u00eatre beaucoup plus \u00e9lev\u00e9e (compilation d’un noyau Linux par exemple).<\/p>\n
Un processeur qui fonctionne \u00e0 plein rendement consomme de l’\u00e9nergie et s’\u00e9chauffe sensiblement (ce qui n\u00e9cessite la mise en marche d’un ventilateur consommant \u00e0 son tour de l’\u00e9nergie \u00e9lectrique). Pour limiter la consommation \u00e9lectrique et retarder le vieillissement pr\u00e9matur\u00e9 du processeur surchauff\u00e9, plusieurs techniques sont utilis\u00e9es de nos jours.<\/p>\n
Variation de fr\u00e9quence d’horloge<\/h2>\n
Pour les processeurs r\u00e9cents, il est possible de contr\u00f4ler la fr\u00e9quence de fonctionnement du CPU (par exemple gr\u00e2ce \u00e0 la technologie SpeedStep d’Intel<\/a> ou Cool’n’Quiet d’AMD<\/a>). Lorsque la charge est faible on se contentera d’une vitesse d’ex\u00e9cution du code basse. Si la charge augmente, on pourra \u00e9lever (suivant divers crit\u00e8res) la fr\u00e9quence d’interpr\u00e9tation des instructions-machine. La consommation \u00e9lectrique du processeur est proportionnelle \u00e0 sa fr\u00e9quence. Le noyau Linux est tout \u00e0 fait capable de prendre en charge cette variation de fr\u00e9quence, en utilisant un algorithme dont l’heuristique (le\u00a0governor<\/em>)\u00a0est configurable par l’administrateur (par le biais du pseudo-fichier\u00a0\/sys\/devices\/system\/cpu\/<\/code>(num\u00e9ro de cpu)\/cpufreq\/scaling_governor<\/code>). La liste des heuristiques disponibles se trouvent dans le pseudo-fichier\u00a0\/sys\/devices\/system\/cpu\/<\/code>(num\u00e9ro de cpu)\/cpufreq\/scaling_available_governors<\/code>. Il existe par exemple les heuristiques suivantes :<\/p>\n