processeur théorie

Université Paris XII – Val de Marne
Faculté des Sciences et Technologies
Année : 2004
THÈSE
pour obtenir le grade de
Docteur de l’Université Paris XII – Val de Marne
Discipline : Informatique
SYSTÈMES TEMPS RÉEL EMBARQUÉS
Ordonnancement optimal de tâches
pour la consommation énergétique du processeur
Présentée et soutenue publiquement par
Dana - Mihaela ROHÁRIK VÎLCU
le 19/02/2004
Membres du jury :
M. Roger REYNAUD, Président
M. Michel AUGUIN, Rapporteur
M. Zoubir MAMMERI, Rapporteur
M. Yvon TRINQUET, Rapporteur
M. Yacine AMIRAT, Examinateur
M. Gilles MERCIER, Directeur de thèse
IEF, Université Paris Sud, Orsay
I3S UNSA – CNRS, Sophia-Antipolis
IRIT, Université Paul Sabatier, Toulouse
IRCCyN, Ecole Centrale de Nantes
LIIA, Université Paris XII – Val de Marne
LIIA, Université Paris XII – Val de Marne
A Costin
REMERCIEMENTS
Le déroulement d’une thèse suppose des tâches à accomplir, des échéances à
respecter, des énergies à dépenser… A la fin, mes pensées vont vers ceux qui y ont contribué.
Je suis honorée que Monsieur Roger REYNAUD ait accepté la présidence du jury.
Messieurs Michel AUGUIN, Zoubir MAMMERI et Yvon TRINQUET m’ont fait
l’honneur d’accepter de rapporter sur cette thèse. Je leur suis redevable pour l’intérêt
manifesté, pour le temps accordé à la lecture d’une version préliminaire, pour toutes leurs
suggestions qui ont permis une amélioration de ce travail. Un remerciement tout particulier
va vers Monsieur Yvon TRINQUET pour la journée de discussions autour du sujet abordé
dans ma thèse et vers Monsieur Zoubir MAMMERI pour les remarques et corrections sur le
manuscrit.
Mes remerciements vont aussi vers Monsieur Yacine AMIRAT en tant que membre du
jury et directeur adjoint du LIIA, Laboratoire d’Informatique Industrielle et d’Automatique.
Je suis reconnaissante à Monsieur Gilles MERCIER, mon directeur de thèse, pour sa
disponibilité, sa persévérance et sa confiance en moi au fil de ces années, malgré les
échéances que je n’ai pas toujours pu respecter. Sa bonne humeur et son amitié m’ont permis
de dépasser certains moments difficiles et d’accomplir cette thèse.
Je remercie tous mes collègues de laboratoire et d’université. Monsieur Jean
PONTNAU, le directeur du LIIA, m’a accueillie et a facilité les tâches administratives
inhérentes. Monsieur Jacques LEMOINE a trouvé le temps de parcourir une version
préliminaire et de me conseiller sur certaines améliorations. Monsieur Laurent GEORGE
m’a offert la possibilité de commencer cette thèse dans le domaine du temps réel. Le regard
critique sur mon travail de Sebastien, Yan et Karim m’a aidé à avancer. La présence de
Marie-France a fait les journées plus sereines.
Messieurs Dave BROOKE (ARM Ltd) et Paolo MONTEGAZZA (Université
Polytechnique de Milan) ont aimablement répondu à mes questions et je leur adresse ici mes
vifs remerciements.
Une pensée chaleureuse va vers Madame Luminiţa STATE, ma directrice d’étude à
l’Université de Bucarest. Je lui remercie pour avoir su me former et préparer pour une thèse,
pour l’avoir eue à mes cotés, malgré la distance, dans des moments très difficiles.
Je remercie Madame Jacqueline KELLER dont l’amitié et l’intérêt pour mon travail
m’ont donné des forces. Travailler à coté d’elle a été une vraie joie.
Je remercie tous mes amis, trop nombreux pour les mentionner individuellement, pour
leurs encouragements au fil de ces années.
J’ai laissé à la fin les pensés que j’adresse à toute ma famille ; je ne trouve pas les
mots justes pour leur exprimer ma reconnaissance. A mes parents, pour leur confiance en
moi. A Ionela et Mihai pour avoir su être à coté de moi et prêts à m’aider ; sans leur
générosité cette thèse n’aurait pas pu commencer, sans leur lecture du manuscrit elle serait
loin de sa forme actuelle. A Marian Alexandru, mon sage petit garçon. A mon mari Costin, a
qui je dédie cette thèse.
v
TABLE DES MATIERES
Remerciements……………………………………………………………….
v
Table des matières…………………………………………………………...
vii
Liste des figures………………………………………………………………
xiii
Liste des tableaux…………………………………………………………….
xv
I
INTRODUCTION………………………………………………………….
1
II
ETAT DE L’ART…………………………………………………………..
11
II.1.
Introduction…………………………………………………………………...
12
II.2.
Sur la conception des systèmes embarqués……………………………..
13
II.2.1.
Concepts……………………………………………………………………….
13
II.2.2.
Conception……………………………………………………………………..
14
II.2.3.
Les aspects de la consommation d’énergie et le cycle de vie
d’un système temps réel embarqué…………………………………………
15
II.3.
Théorie de l’ordonnancement……………………………………………...
17
II.3.1.
Concepts de base……………………………………………………………..
18
II.3.2.
Algorithmes d’ordonnancement……………………………………………...
21
II.3.2.1. “Rate-monotonic” (RM)……………………………………………….
22
II.3.2.2. “Inverse Deadline” (ID) ou “Deadline Monotonic” (DM)…………...
22
II.3.2.3. “Least Laxity First” (LLF)…………………………………………….
23
II.3.2.4. “Earliest Deadline First” (EDF)………………………………………
23
Ordonnancement monoprocesseur………………………………………….
24
II.3.3.1. Propriétés concernant l’ordonnancement des tâches indépendantes….
24
II.3.3.2. Restrictions imposées aux tâches par l’implantation et conséquences...
27
Ordonnancement multiprocesseur…………………………………………..
29
II.3.4.1. Propriétés concernant l’ordonnancement des tâches indépendantes….
30
II.3.3.
II.3.4.
vii
Table des matières
II.3.4.2. Restrictions imposées aux tâches par l’implantation et conséquences...
33
II.3.4.3. Problème des « sacs à dos » (bin packing) - une autre approche pour
l’ordonnancement multiprocesseur……………………………………………..
35
II.3.5.
Conclusions…………………………………………………………………….
35
II.4.
Systèmes d’exploitation et temps réel……………………………………
36
II.4.1.
Notions générales……………………………………………………………..
37
II.4.2.
Implantation des applications temps réel et fonctionnement du noyau….
39
II.4.3.
Les noyaux temps réel Linux………………………………………………...
41
II.4.3.1. Le noyau Linux…………………………………………………………
41
II.4.3.2. Implantation de noyau temps réel Linux……………………………….
44
II.5.
Conclusions…………………………………………………………………...
48
III
CONTRIBUTION À LA DEFINITION DE LA
CONFIGURATION D’UN SYSTEME TEMPS REEL
EMBARQUE POUR L’OPTIMISATION DE LA
CONSOMMATION ENERGETIQUE………………………………..
51
III.1.
Introduction…………………………………………………………………...
52
III.2.
Etat de l'art…………………………………………………………………….
53
III.2.1. Considérations sur la consommation énergétique du processeur……….
53
III.2.2. L’ordonnancement des tâches et la consommation d’énergie : concepts
et idées…………………………………………………………………………
57
III.2.3. Consommation optimale de l’énergie. Modèle de tâches périodiques
indépendantes…………………………………………………………………
59
III.2.3.1. Notations, définitions, concepts……………………………………….
59
III.2.3.2. Solution statique optimale…………………………………………….
59
III.2.3.3. Solution dynamique optimale………………………………………….
61
Contribution : analyse critique de la solution actuelle pour le cas
monoprocesseur et compléments………………………………………….
64
III.3.1. Analyse critique, corrections et compléments des travaux présentés
dans §III.2.3…………………………………………………………………....
65
III.3.2. Résultats généraux concernant l’optimalité………………………………...
71
III.3.3. Formule générale pour la solution statique optimale……………………...
73
III.3.
viii
Table des matières
III.4.
Contribution : le problème d’optimisation pour plate-forme
multiprocesseur……………………………………………………………….
79
III.4.1. Plate-forme multiprocesseur dans l’optimisation de l’énergie…………….
79
III.4.2. Coût de l’ordonnancement. Implications sur la consommation d’énergie
81
III.4.3. Mise à jour des notions pour processeurs à vitesse variable…………….
82
III.4.4. Premiers résultats sur la faisabilité d’ordonnancement des tâches
indépendantes…………………………………………………………………
84
III.4.5. Premiers résultats sur la consommation d’énergie………………………...
88
III.5.
Contribution : étude sur la configuration d’un système temps réel
embarqué afin de minimiser la consommation énergétique - modèle
de tâches périodiques indépendantes……………………………………..
91
III.5.1. Définition du problème………………………………………………………..
91
III.5.2. Solution statique……………………………………………………………….
92
III.5.3. Solution dynamique…………………………………………………………...
94
III.6.
Contribution : étude sur la configuration d’un système temps réel
embarqué afin de minimiser la consommation énergétique - modèle
de tâches périodiques indépendantes, avec la même fonction de
puissance dissipée……………………………………………………………
95
III.6.1. Une condition d’optimalité…………………………………………………….
95
III.6.2. Estimations sur le gain énergétique au passage de m à m+1
processeurs…………………………………………………………………….
98
III.7.
Contribution : étude sur la configuration d’un système temps réel
embarqué afin de minimiser la consommation énergétique - modèle
de tâches identiques indépendantes, ayant le même moment
d’activation et la même échéance…………………………………………
103
III.7.1. Notations, définitions, concepts……………………………………………...
103
III.7.2. Consommation optimale d’énergie sur une machine multiprocesseur…..
103
III.7.3. Cas particulier : le passage de un à deux processeurs…………………...
106
III.7.4. Méthodologie de calcul du nombre optimal de processeurs pour une
minimisation de la consommation d’énergie. Evaluations………………...
109
III.8.
111
Conclusions et perspectives………………………………………………...
ix
Table des matières
IV
UNE APPROCHE DE L’IMPLANTATION D’UNE
APPLICATION TEMPS REEL POUR L’OPTIMISATION DE
LA CONSOMMATION ENERGETIQUE DU
PROCESSEUR...............................................................................................
115
IV.1.
Introduction…………………………………………………………………...
116
IV.2.
La consommation énergétique et les aspects du noyau et de
l’implantation d’une application temps réel……………………………..
117
IV.2.1. Les plates-formes multiprocesseur homogènes à mémoire commune….
117
IV.2.1.1. Les principes de fonctionnement des ordonnanceurs proposés par
RTAI……………………………………………………………………………...
118
IV.2.1.2. Les ordonnanceurs proposés par RTAI, les plus appropriés pour les
résultats sur la consommation optimale d’énergie……………………………...
120
IV.2.2. L’influence de l’ordonnanceur et des politiques d’ordonnancement sur la
consommation d’énergie……………………………………………………... 122
IV.2.2.1. Le coût de l’ordonnanceur et la consommation énergétique des tâches
122
IV.2.2.2. Les politiques d’ordonnancement et la consommation énergétique des
tâches…………………………………………………………………………….
123
IV.2.3. L’implantation de l’application et la consommation énergétique………….
125
IV.2.3.1. L’espace noyau, l’espace utilisateur, l’application temps réel et la
consommation énergétique………………………………………………………
125
IV.2.3.2. Le modèle réel des tâches……………………………………………...
126
Vers des validations physiques…………………………………………….
129
IV.4.1. Solution Transmeta Crusoe™………………………………………………..
129
IV.3.2. Solution Altera Nios……………………………………………………………
132
IV.3.3. Solution ARM…………………………………………………………………..
135
IV.3.
IV.4.
Conclusions…………………………………………………………………… 137
V
CONCLUSIONS ET PERSPECTIVES.................................................
139
A1
ANNEXE 1. Etude de cas…………………………………………………..
143
A1.1.
Motivation……………………………………………………………………... 143
A1.2.
Introduction…………………………………………………………………… 143
x
Table des matières
A1.3.
Principes de l’application…………………………………………………… 144
A1.3.1. Architecture globale de l’application…………………………………………
144
A1.3.2. Filtrage par ondelette………………………………………………………….
144
A1.3.3. Transmission sans fil………………………………………………………….
145
A1.3.4. Principe et application de CMAC…………………………………………….
146
A1.4. Résultats de la simulation…………………………………………………... 147
A1.5.
Principes d’implantation et consommation énergétique………………. 148
A1.6. Conclusions…………………………………………………………………… 150
A2
ANNEXE 2. Caractéristiques concernant la gestion de puissance
pour les modèles Crusoe SE TM 55E/TM58E………………………….. 149
Bibliographie………………………………………………………………..
xi
151
LISTE DES FIGURES
Figure I.1.
Domaines concernés par la consommation énergétique optimale au
niveau du/des processeur(s)………………………………………….
3
Energie consommée par les différentes composantes d’un WebPad
typique………………………………………………………………..
16
Figure II.2.
Modèle canonique de tâche…………………………………………..
18
Figure II.3.
Rate-monotonic………………………………………………………
22
Figure II.4.
Inverse Deadline……………………………………………………...
22
Figure II.5.
Least Laxity First…………………………………………………….
23
Figure II.6.
Earliest Deadline First………………………………………………..
24
Figure II.6.
EDF et LLF dans l’ordonnancement multiprocesseur……………….
32
Figure II.8.
Anomalie de Richard causée par la diminution du temps d’exécution
d’une tâche…………………………………………………………...
34
Anomalie de Richard causée par l’augmentation du nombre de
processeurs……………………………………………………………
34
Figure II.10.
Structure d’un micronoyau…………………………………………...
38
Figure II.11.
Bloc de contrôle du thread……………………………………………
40
Figure II.12.
Le processus matériel………………………………………………...
43
Figure II.13.
Partie du flux de contrôle des tâches…………………………………
43
Figure II.14.
Noyau hybride Temps Réel Linux……………………………………
45
Figure II.15.
FIFO temps réel………………………………………………………
46
Figure II.16.
Architecture RTAI……………………………………………………
47
Figure III.1.
Modélisation de la consommation dynamique des portes CMOS……
53
Figure III.2.
UP - vitesses optimales différentes pour des itérations différentes de
la tâche T1…………………………………………………………….
69
MP - vitesses optimales différentes pour des itérations différentes de
la même tâche………………………………………………………...
70
Figure II.1.
Figure II.9.
Figure III.3.
xiii
Liste des figures
Figure III.4.
Procédure de réduction d’un ordonnancement monoprocesseur à
EDF…………………………………………………………………...
72
Figure III.5.
Exemple d’ordonnancement optimal à des vitesses différentes……...
79
Figure III.6.
Illustration des notations……………………………………………...
83
Figure III.7.
Ti j et Ti k parties des deux tâches différentes, synchrones, avec
1
2
C i j = C i k , exécutées par deux processeurs différents………………
1
Figure III.8.
2
Durant C i
1
j
d’autres tâches asynchrones par rapport à Ti
1
j
s’exécutent sur le premier processeur…...……………………………
Figure III.9.
87
88
Les tâches ne peuvent pas être assignées chacune à un processeur,
sauf certains cas………………………………………………………
88
Figure III.10.
Le passage de m à m+1 processeurs, pour économiser l’énergie…….
90
Figure III.11.
Une inégalité pour les fonctions croissantes et convexes…………….
95
Figure III.12.
Les estimations du Théorème III.8 ne sont pas valables sans
l’hypothèse π k ≥ 2 , k=1,2………………………………………….
102
La consommation optimale d’énergie et la vitesse correspondante
pour les m processeurs relatives à la solution optimale
monoprocesseur………………………………………………………
106
Figure III.14.
Le passage de 1 à 2 processeurs pour n=2k tâches identiques……….
106
Figure III.15.
Le passage de 1 à 2 processeurs pour n=2k +1 tâches identiques……
107
Figure IV.1.
La hiérarchie logicielle du processeur Crusoe™ SE…………………
131
Figure IV.2.
Les points de gestion de la puissance par LongRun, pour le
processeur Crusoe™ à 933 MHz……………………………………..
132
Figure IV.3.
Blocs diagrammes du processeur Nios à 32 bits……………………..
134
Figure IV.4.
Intégration multiprocesseur de Nios sur un seul chip………………..
135
Figure IV.5.
ARM Integrator/AP AHB ASIC……………………………………..
136
Figure A1.1.
Synoptique……………………………………………………………
144
Figure A1.2.
La transformation par ondelette discrète de niveau 2………………..
145
Figure A1.3.
Architecture CMAC prédictive pour les variations des coefficients
de l’ondelette…………………………………………………………
146
Figure III.13.
xiv
LISTE DES TABLEAUX
Tableau III.1.
Coûts d’exécution et coefficients des fonctions de dissipation de
puissance…………………………………………………………...
69
Tableau III.2.
Gain d’énergie au passage de 1 à 2 processeurs……………………
101
Tableau III.3.
La distribution de n tâches identiques sur m processeurs, et leurs
vitesses d’exécution………………………………………………..
104
Tableau III.4.
Gain d’énergie au passage de 1 à m processeurs…………………..
110
Tableau IV.1.
Plates-formes RTAI proposées pour la validation des résultats
obtenus au Chapitre III…………………………………………….
121
Plates-formes physiques et outils de développement proposées
pour la validation des résultats obtenus au Chapitre III……………
130
Tableau A1.
Estimations pour les vitesses des tâches et l’énergie consommée…
150
Tableau A2.
Caractéristiques des modèles Crusoe SE TM 55E/TM58E………..
151
Tableau IV.2.
xv
CHAPITRE I
Introduction
Chapitre I
Introduction
Si nous observons l’environnement de notre société, nous pouvons constater qu’une
multitude de systèmes embarqués nous entoure, à partir des téléphones portables et jusqu’aux
systèmes de contrôle des voitures ou des avions. Ces systèmes existent dans la vie
quotidienne, mais on les trouve également très répandus dans l’industrie. Dans cette
thèse nous nos intéressons aux systèmes temps réel embarqués. Tout au long de ce travail
nous considérons comme système temps réel embarqué un système informatique qui est :
•
dédié à une application logicielle ayant des contraintes strictes en terme
d’échéance pour ses tâches spécifiques, et
•
autonome relativement à une source externe d’énergie.
Dès le début, nous précisons que les concepts présentés sont traités pour le cas d’un
système centralisé – vu comme un système où « les décisions, la gestion des ressources,
l’algorithmique et la cohérence de données sont déterminées par l’existence d’informations
dans une mémoire commune accessible à toutes les tâches du système » [COT 00] – et ils sont
appliqués à des architectures monoprocesseur et, respectivement, multiprocesseur à
mémoire commune.
Ce qui nous intéresse ce sont les aspects concernant à la fois la faisabilité et
l’autonomie des systèmes temps réel embarqués. Il faut tout d’abord noter que les deux
notions, temps réel et embarqué, apportent des concepts différents qui doivent être pris en
compte simultanément dans cette étude.
Pour ce qui concerne la faisabilité d’un système temps réel embarqué, il faut analyser
comment la théorie classique de l’ordonnancement des tâches peut s’appliquer dans le cas
précis d’une application et d’un système d’exploitation donnés. L’application doit être
interprétée du point de vue du système d’exploitation afin de déterminer toutes les tâches
agissant dans le système durant l’exécution de cette application, ainsi que leurs
caractéristiques – coûts d’exécution, modèle spécifique, scénarios possibles – afin de
permettre l’application des résultats de la théorie de l’ordonnancement. Malheureusement, à
l’heure actuelle les deux domaines (théorie de l’ordonnancement et systèmes d’exploitation)
sont assez distincts et les repères qui pourraient aider à la transposition de la théorie
d’ordonnancement au niveau d’un système d’exploitation sont généralement laissés à la
découverte, l’étude et la compétence du développeur d’un système temps réel. Et parce que
nous évoquons plus spécifiquement les systèmes embarqués, deux situations apparaissent : la
faisabilité en conditions normales de fonctionnement, et en conditions limites de décharge de
la batterie. Dans cette thèse nous traitons le premier cas.
Quant à l’autonomie, elle est directement liée à la consommation d’énergie durant le
fonctionnement du système. Le thème de l’économie d’énergie pour les systèmes temps réel
embarqués se situe à la confluence de plusieurs domaines assez lointains les uns des autres :
la conception des systèmes embarqués, y compris les connaissances technologiques à jour sur
les performances des diverses composantes à utiliser, la théorie algorithmique et
mathématique de l’ordonnancement mono et multiprocesseur, la théorie des systèmes
d’exploitation temps réel et la connaissance de ceux actuellement existants. C’est la raison
pour laquelle cette thèse présente des notions diverses venant de ces domaines et ayant
comme point commun l’influence sur la consommation énergétique. Evidement, proposer de
réaliser un exposé détaillé sur tous ces domaines serait une tâche extrêmement difficile à
accomplir, voire même irréalisable dans le cadre d’une seule thèse. Nous plaçons notre étude
au niveau de la consommation énergétique du (des) processeur(s), engendrée par l’exécution
des tâches, donc à la confluence de ces domaines. Nous essayons aussi d’exprimer des
2
Chapitre I
Introduction
influences et des contraintes imposées par ces résultats aux domaines énumérés ci–dessus, ce
qui fait que les chapitres qui suivent touchent particulièrement aux intersections des
diagrammes illustrées dans la Figure I.1 pour désigner les domaines impliqués.
Figure I.1. Domaines concernés par la consommation énergétique optimale
au niveau du/des processeur(s).
Selon notre conception, l’intérêt d’assurer la plus grande autonomie possible d’un tel
système consiste à trouver la configuration optimale processeur(s)-vitesse(s) du point de vue
de la consommation d’énergie, tout en garantissant la faisabilité de l’application. Les travaux
dans ce domaine sont encore peu nombreux ; cependant, les premiers résultats théoriques
publiés indiquent, tenant compte du gain important sur l’énergie consommée, que cette
approche pourrait s’avérer très utile dans l’avenir pour les développeurs des systèmes temps
réel embarqués. Afin de trouver les solutions aux questions posées par cette nouvelle
problématique les résultats de la théorie d’ordonnancement ont une importance particulière.
Aussi la démarche qui consiste à approcher celle-ci de la théorie des systèmes d’exploitation
s’averre primordiale pour les estimations a priori sur la consommation énergétique du/des
processeur(s), de même que sur la configuration la plus approprié de la plate-forme à utiliser
pour un modèle réel de tâches. Pour la suite, chaque fois que l’expression « consommation
d’énergie » sera employée, elle fera référence à la consommation d’énergie au niveau du/des
processeur(s) durant l’exécution d’une application.
Pour prendre en considération tous ces aspects, la structure de cette thèse est la
suivante.
Le Chapitre II, Etat de l’art, introduit une présentation sur les différents aspects liés
aux problématiques de la faisabilité des applications temps réel tels qu’ils sont abordés
actuellement, sur les notions fondamentales sur la conception des systèmes embarqués, et
passe en revue des systèmes d’exploitation temps réel Linux.
3
Chapitre I
Introduction
Le Chapitre III, Optimisation de la consommation d’énergie. Contribution à la
définition de la configuration d’un système temps réel embarqué, est le cœur de notre étude. Il
traite de la consommation d’énergie au niveau du processeur (ou des processeurs), engendrée
par l’exécution des tâches et leur ordonnancement, le but étant de trouver, pour différents
modèles de tâches, le nombre de processeurs et les vitesses d’exécution des tâches qui
assurent l’existence d’un algorithme à la fois faisable pour le fonctionnement de l’application
et optimal pour la consommation énergétique. Ce chapitre donne des résultats fondamentaux
sur le modèle des tâches indépendantes. Le résumé qui suit cette courte présentation de la
thèse indique plus en détail les principales idées développées, ainsi que les principaux
résultats.
Le Chapitre IV, Une approche de l’implantation d’une application temps réel pour
l’optimisation de la consommation énergétique du processeur, présente d’une part l’influence
que les résultats obtenus au chapitre précédent ont sur le système d’exploitation envisagé afin
de permettre leur validation, ainsi que la démarche à faire pour permettre cette connexion
entre les résultats théoriques et leurs équivalents obtenus en pratique. L’existence d’une plateforme pourrant assurer cette validation étant indispensable, ce chapitre propose, dans une
deuxième étape, des plates-formes existantes qui répondent aux assertions énoncées au
préambule des résultats du chapitre précédent. Ce chapitre constitue une première approche
vers la mise en pratique des résultats mentionnés et une ouverture pour des projets de
validation par des applications, ultérieurs à cette étude.
Le Chapitre V met en évidence les conclusions et les perspectives de notre étude,
autant au niveau recherche théorique que pratique.
Nous présentons par la suite un résumé plus détaillé du contenu de chaque chapitre.
Le Chapitre II est un Etat de l’art sur les principaux aspects concernant les domaines
impliqués dans cette étude : la conception des systèmes embarqués, la théorie
d’ordonnancement, les systèmes d’exploitation temps réel et l’implantation des applications
temps réel. Etant un domaine nouveau, une présentation des concepts actuellement employés
et concernant la consommation d’énergie du/des processeur(s) est laissée pour le chapitre
suivant.
Pour ce qui concerne « l’embarqué », ce qui nous intéresse c’est l’autonomie du
système. Cette autonomie vient d’un choix judicieux des composantes, selon les
caractéristiques désirées de l’application, mais également des techniques d’implantation
utilisées. Pour faciliter la discussion des chapitres suivants, la section §II.2 évoque les
concepts généraux (§II.2.1) liés aux systèmes embarqués et, en grandes lignes, les phases de
la conception d’un tel système. A la fin (§II.2.3), quelques repères sur les implications sur le
processus de développement d’un système temps réel embarqué, issues de la nécessité de
minimiser la consommation d’énergie, sont évoqués.
Parce que le cœur de notre travail concerne la connexion entre l’ordonnancement des
tâches et la consommation d’énergie du/des processeur(s) due à l’exécution de tâches, ce
chapitre prête une attention particulière à l’ordonnancement. Après une énumération des
concepts utilisés dans la théorie d’ordonnancement (§II.3.1), les algorithmes les plus utilisés
sont présentés (§II.3.2) ainsi que les principaux résultats sur l’ordonnancement
monoprocesseur (§II.3.3) et multiprocesseur (§II.3.4) des tâches périodiques indépendantes.
La présentation est limitée à ce modèle de tâches car c’est celui-ci qui sera traité par la suite
pour étudier l’autonomie des systèmes temps réel embarqués.
4
Chapitre I
Introduction
Pour répondre à la problématique de la faisabilité d’une application temps réel, l’étude
sur la théorie d’ordonnancement doit être approchée de l’étude des systèmes d’exploitation.
La section §II.4 porte sur les systèmes d’exploitation temps réel. Les notions générales
(§II.4.1), l’implantation des applications temps réel et le fonctionnement du noyau (§II.4.2)
sont d’abord exposées, pour présenter à la fin les principales caractéristiques des noyaux
temps réel Linux (§II.4.3), car un de ces noyaux (RTAI) sera utilisé dans le Chapitre IV afin
d’illustrer les notions présentées au chapitre précédent.
Nous concluons (§II.5) en reprenant les idées fondamentales, ce qui nous permet de
mettre en évidence les concepts sur lesquels nous intervenons dans les chapitres qui suivent.
Le Chapitre III, Optimisation de la consommation d’énergie. Contribution à la
définition de la configuration d’un système temps réel embarqué, est le cœur de cette étude.
L'autonomie est un élément essentiel dans la conception d'un système embarqué. De
multiples mécanismes de préservation de l'énergie sont mis en place dans la plupart de ces
systèmes. L’optimisation de la consommation d’énergie d’un système embarqué peut se faire
à plusieurs niveaux, mentionnés au début de ce chapitre. Notre approche concerne la
consommation énergétique du processeur, due à l’exécution des tâches. Le problème abordé
concerne les plates-formes multiprocesseur homogènes, avec des processeurs à vitesse
ajustable en ligne. Le but est de définir, pour une application donnée, la configuration de
la plate-forme en termes de nombre de processeurs, de vitesses d’exécution des tâches à
chaque activation et d’ordonnancement, pour une consommation minimale d’énergie.
Peu de travaux sur ce sujet ont été réalisés à ce jour et ceux existants sont très récents
et encore incomplets. Après l’introduction au chapitre (§III.1), nous les présentons au §III.2,
l’état de l’art sur le sujet. Ces travaux sont essentiellement théoriques et les résultats offerts
sont issus de simulations. Les différentes approches ont pour base l’idée de trouver la vitesse
optimale d’exécution de chaque tâche, et cela soit en fonction du modèle de tâches et de la
machine, connues a priori, soit en introduisant différentes heuristiques. A notre connaissance,
seul le cas monoprocesseur a été pris en compte jusqu’à présent. Il est supposé que la vitesse
du processeur soit modifiable, et cela jusqu’à proposer des algorithmes d’ordonnancement en
ligne qui modifient la vitesse du processeur en fonction de l’état réel de déroulement de
l’application. L’élément essentiel dans le calcul de la puissance consommée est la fonction de
puissance dissipée (g) caractéristique à chaque tâche. Elle dépend de la tâche par l’intermède
de son implantation et de la machine qui l’exécute. Certains auteurs la considèrent comme
ayant la forme donnée par :
g (S ) = S p , p ≥ 2, p ∈ R ,
et d’autres, par une fonction polynomiale de degré minimum 2 :
r
g (S ) = ∑ a j S j , r ∈ N , r ≥ 2 , a j ∈ R , ∀j = 1, K , r ,
j =1
où S représente la vitesse du processeur.
Le point de départ de notre approche est constitué par les travaux de Aydin et al.,
présentés ces dernières années dans une série d’articles [AYD 01a,b,c]. Le principe de ces
travaux peut être décrit comme suit : étant donné un ensemble de tâches et une machine
monoprocesseur, il faut trouver l’ordonnancement optimal – y compris les vitesses
respectives des tâches – pour minimiser la consommation du processeur, en considérant des
5
Chapitre I
Introduction
estimations des fonctions de puissance dissipée des tâches. Deux assertions ont été
considérées comme hypothèses : premièrement, le changement de la vitesse du processeur ne
peut se produire que pendant la commutation du contexte et, deuxièmement, chaque tâche Ti
garde, durant la période qui correspond à son instance j, une vitesse constante Sij. La solution
qui propose a priori certaines vitesses pour l’exécution de chaque tâche et, éventuellement, un
ordonnancement est nommée solution statique. L’idée principale pour la trouver est de
charger au maximum le processeur. La solution dynamique part de la solution statique et
suppose l’ajustement en ligne de la vitesse du processeur comme suit : si une tâche finit son
exécution plus vite que prévu par la solution statique, la tâche suivante commence son
exécution et cela se poursuit avec une vitesse qui lui permet d’utiliser la durée prévue a priori
pour son exécution plus la durée restante non utilisée par la tâche précédente. Les principaux
résultats présentés dans ces articles, qui concernent les tâches indépendantes et qui nous
intéressent sont :
1. la solution statique pour les tâches périodiques indépendantes : il y a une solution
optimale qui suppose une vitesse constante pour toutes les évolutions de la tâche
Ti, et cela pour chaque tâche ;
2. la solution statique pour les tâches périodiques indépendantes ayant la même
dissipation de puissance : il y a une solution optimale qui suppose une vitesse
constante d’exécution de chaque tâche à tout moment, et la formule qui indique sa
valeur est donnée ;
3. la solution dynamique pour les tâches périodiques indépendantes, dont l’idée a été
présentée ci-dessus.
Notre travail et notre contribution se sont développés en trois directions. Le modèle de
tâches traité a été celui de tâches périodiques indépendantes.
D’une part, nous avons complété le fondement théorique et les résultats connus pour le
problème monoprocesseur. La sous-section §III.3.1. contient une analyse critique de la
solution actuelle pour le cas monoprocesseur [AYD 01a,b,c], ce qui nous a permis d’y ajouter
quelques compléments. De nombreux exemples illustrent nos observations.
§III.3.2 transpose, dans le nouveau contexte de processeur à vitesse variable, deux
résultats classiques de la théorie d’ordonnancement : l’optimalité algorithmique et
énergétique du EDF (Théorème III.3) et la condition nécessaire et suffisante
d’ordonnancement sur une machine monoprocesseur (Théorème III.4).
Nous avons obtenu ensuite (§III.3.3) une formule pour les vitesses des différentes
parties des tâches dans la solution statique optimale, dans le cas général où les tâches ont les
fonctions gi de puissance dissipée données par g i ( S ) = ai S r (Théorème III.5). Ce théorème
élargit le deuxième résultat mentionné de Aydin et al. (voir ci-dessus et Proposition III.1’) et
complète le premier résultat mentionné (voire ci-dessus et Théorème III.1’).
D’autre part, nous avons considéré le problème d’optimisation énergétique des platesformes multiprocesseur. Nous avons développé les notions théoriques nécessaires, ainsi que
des résultats de base et essentiels sur la faisabilité et l’optimalité (§III.4). Des exemples en
(
)
sont le Théorème III.6, qui donne la condition nécessaire et suffisante max C i Di ≤ S MAX
i =1,K, n
pour la faisabilité d’un ensemble de tâches indépendantes et synchrones, ainsi que la
décroissance d’énergie avec le nombre de processeurs, obtenue dans la Proposition III.3 et le
Théorème III.8.
6
Chapitre I
Introduction
Pour une machine donnée, l’ordonnancement optimal d’un ensemble de tâches donné
est l’ordonnancement pour lequel la consommation d’énergie associée est minimale par
rapport à tous les ordonnancements du même ensemble de tâches en utilisant la même
machine. Nous définissons l’ordonnancement global optimal comme l’ordonnancement pour
lequel la consommation d’énergie associée est minimale par rapport à tous les
ordonnancements optimaux du même ensemble de tâches (et donc par rapport à toutes les
plates-formes). Ce concept s’appuie sur une nouvelle approche dans la théorie
d’ordonnancement multiprocesseurs, et celle-ci constitue la deuxième direction de notre
étude. Nous avons redéfini le problème comme suit :
Pour une configuration optimale d’un système temps réel embarqué, il faut
déterminer :
le nombre m de processeurs,
les vitesses d’exécution des tâches à tout moment de leur exécution (après
chaque préemption),
tout en assurant la faisabilité d’ordonnancement pour une minimisation de la
consommation d’énergie sur l’exécution de l’ensemble des tâches.
Dans la théorie de l’ordonnancement, l’approche qui consiste à prendre comme
variable à déterminer le nombre de processeurs nécessaire pour la faisabilité d’un ensemble
de tâches est peu abordée (voir le problème du « sac à dos » dans §II.3.4.3) et incomplètement
valorisée à ce jour ; néanmoins, cette approche s’avère particulièrement utile pour l’optimalité
de l’ordonnancement, comme le montrent les résultats de ce chapitre. Nous remarquons ici
que, tel qu’il a été formulé pour la faisabilité d’ordonnancement d’un ensemble de tâches, le
problème du « sac à dos » est différent de celui pour l’optimalité de l’ordonnancement, car il
suppose déterminer le nombre minimal de processeurs afin d’assurer l’exécution d’un
ensemble de tâches (voir §II.2). Par contre, afin de minimiser la consommation du processeur,
notre approche montre que le nombre de processeurs doit être maximal.
Basé sur le concept d’ordonnancement global optimal nous avons pu fournir (§III.5) la
solution statique (Théorème III.9) et dynamique (§III.5.3) pour le cas général des tâches
périodiques indépendantes avec des fonctions de dissipation de puissance différentes.
Il se peut que, selon les caractéristiques des tâches, la solution théorique globale
optimale soit difficile à obtenir du point de vue technologique, par exemple à cause d’un
nombre trop élevé de processeurs à utiliser ou de vitesses des tâches trop basses.
Pour cela nous avons abordé une troisième direction d’étude (§III.6.1), en déterminant
une condition nécessaire d’optimalité pour un ordonnancement sur une plate-forme ayant un
nombre donné de processeurs (au moins deux), condition que nous avons nommée le principe
d’uniformité (Théorème III.10). Comme application de cette condition, nous avons obtenu
(§III.6.2) des évaluations concrètes de gain énergétique pour le passage de un à deux
processeurs, pour le modèle de tâches ayant la même fonction de puissance dissipée
(Théorèmes III.11 et III.12). Ces estimations théoriques indiquent une diminution
considérable : E 2 ≤ 0,556 E1 .
Le modèle des tâches identiques est traité en détail dans la section III.7. Nous avons
donné les ordonnancements optimaux, en comparant la consommation énergétique optimale
d’une plate-forme à m processeurs avec celle d’une machine à m+1 processeurs (Théorèmes
III.13, III.14 et III.5).
Nous concluons dans la section §III.8 en présentant des perspectives que la
7
Chapitre I
Introduction
problématique de l’ordonnancement optimal et cette nouvelle approche ouvrent.
Le Chapitre IV, Une approche de l’implantation d’une application temps réel pour
l’optimisation de la consommation énergétique du processeur, est conçu en deux parties, afin
d’approcher les concepts et les résultats théoriques de leur mise en pratique. La première
partie traite de l’influence de la transposition des résultats du chapitre précédent au niveau du
système d’exploitation ; une deuxième partie mentionne des plates-formes qui peuvent être
utilisés pour la validation des résultats du Chapitre III. Ainsi élaboré, ce chapitre suggère des
points de départ pour un certain nombre de projets d’ingénierie, consécutifs à notre étude
théorique du troisième chapitre.
Parler de la faisabilité d’exécution d’une application temps réel à échéances strictes
implique les faits suivants. Durant la conception d’une application temps réel à échéances
strictes, on connaît a priori les tâches qui composent l’application et le fonctionnement désiré
de celle-ci. Cela permet d’exprimer un scénario théorique de tâches et d’estimer pour
l’ensemble des tâches données la garantie théorique de leurs échéances. Cependant, c’est le
comportement réel de l’application qui est important. Afin d’y parvenir, cette étude préalable
est basée sur des estimations pire-cas du temps d’exécution des tâches. Est-ce que cela suffit,
et quelle est la différence entre l’application théorique et son exécution effective ? Nous
pensons ici non seulement à la différence entre le temps d’exécution réel des tâches et le
temps pire-cas, mais également aux autres tâches que le système d’exploitation pourrait
ajouter, à part les tâches effectives de l’application, pour permettre leur exécution. Pour y
répondre, une comparaison entre le scénario théorique et le scénario effectif des tâches
s’impose.
Après son introduction (§IV.1), dans un premier temps, le Chapitre IV présente ces
aspects et prend comme exemple le noyau RTAI-Linux (IV.2). Le choix de ce noyau n’a pas
été nécessairement lié aux critères de performances par rapport aux autres noyaux. Les
critères qui nous ont intéressés sont les suivants : la disponibilité des sources, l’existence
d’une version embarquée, l’existence des implantations pour des plates-formes différentes, y
compris multiprocesseur, l’existence des différentes fonctionnalités spécifiques aux noyaux
temps réel, une documentation suffisamment riche et une liste de discussions active. Celles-ci
nous permettent d’entrer dans les détails de l’implantation du noyau liés à la consommation
d’énergie par le(s) processeur(s). Ce qui nous intéresse dans cette sous-section c’est de
présenter comment les résultats du chapitre précédent peuvent être utilisés dans l’analyse a
priori de l’implantation d’une application temps réel, et où – dans le processus de
développement de l’application – ces aspects interviennent. Cette étude étant surtout générale,
il est évidemment possible qu’au passage effectif à l’implantation d’une application
particulière, d’autres aspects puissent intervenir, surtout parmi ceux spécifiques à la plateforme utilisée. Nous limitons notre présentation aux aspects généraux et aux principes
communs à toutes les plates-formes. Des modifications dans la conception d’un noyau temps
réel permettant de minimiser la consommation d’énergie peuvent être envisagées. Nous nous
contenterons de les mentionner.
Dans ce contexte, la section IV.2.1, traite de La consommation énergétique et les
aspects du noyau et de l’implantation d’une application temps réel. Tout d’abord, il est
vérifié que les ordonnanceurs proposés par RTAI correspondent aux assertions faites
concernant les plates-formes pour lesquelles les résultats mentionnés ont été obtenus. Après
une brève description des principes de fonctionnement des ordonnanceurs (de RTAI), nous
constatons que ceux-ci sont conçus d’une manière correspondant à quelques-unes de nos
8
Chapitre I
Introduction
assertions et permettent les modifications appropriées pour qu’elles puissent correspondre
aussi aux autres. Elles peuvent être utilisées telles quelles pour les cas des applications sans
changement de la vitesse du processeur durant l’exécution, aussi bien pour les cas mono que
multiprocesseur. Pour les cas avec changement de vitesse, cette situation doit être prise en
compte par une nouvelle implantation de RTAI.
Dans une deuxième étape (§IV.2.2), nous nous intéressons à l’influence de
l’ordonnanceur et des politiques d’ordonnancement sur la consommation d’énergie. Le coût
de l’ordonnanceur est le coût dû à l’exécution des lignes de code du noyau spécifiques à la
politique d’ordonnancement, mais ces lignes de code ne constituent pas une tâche
supplémentaire du système. La théorie d’ordonnancement ne dit pas où ce coût doit être pris
en compte et, pour une analyse détaillée il faut connaître les situations où l’ordonnanceur
s’active. Pour RTAI-Linux, l’exécution de l’ordonnanceur doit être prise en compte dans
l’estimation du temps d’exécution de la tâche qui a été interrompue pour l’exécution de
l’ordonnanceur. Nous indiquons les facteurs qui influencent le coût de l’ordonnanceur et nous
parlons des politiques d’ordonnancement mono coup et périodique, ainsi que du choix à faire
entre les deux du même point de vue de la minimisation de la consommation d’énergie.
Il est possible que, pour son fonctionnement, l’application se serve de certains services
offerts par le système, mais aussi que certaines fonctionnalités du système ne soient pas prises
en compte par l’application. Pour le système d’exploitation tous ces services constituent des
tâches. Afin de permettre une analyse a priori sur la faisabilité et la consommation
énergétique due à l’exécution de l’application, toutes les tâches existant dans le système
durant cette période doivent être prises en compte ; autrement dit, les tâches induites par le
système d’exploitation doivent faire partie du modèle réel des tâches de l’application. La
section §IV.2.3 traite de cet aspect pour le cas du RTAI. L’idée principale est que l’exécution
de l’application doit se dérouler entièrement dans l’espace noyau : les tâches proprement
dites, aussi bien que toute tâche (service) système. D’autre part, nous constatons que pour
l’évaluation préalable du coût énergétique, un même processus doit être suivi comme pour
l’estimation de la faisabilité du système du point de vue de l’ordonnancement des tâches.
Dans sa deuxième partie (§IV.3), le Chapitre IV propose un aperçu des plates-formes
physiques actuellement disponibles ainsi que sur des outils logiciels, qui pourraient permettre
une validation des résultats sur les estimations de la consommation énergétique présentés au
Chapitre III. Cette section constitue une démarche qui vient de compléter la section §IV.2,
afin de permettre le début d’un projet de validation réel. Les solutions proposées vont vers les
processeurs Transmeta Crusoe™ [TRA 03] (voir aussi l’Annexe 2), les architectures ARM v6
[ARM 03] et Altera Nios [ALT 03], avec des outils de développement conçus par les
constructeurs respectifs ou avec des outils disponibles pour Linux, afin de faire migrer le
noyau RTAI-Linux vers ces plates-formes. Dans leurs versions actuelles les plates-formes
proposées vérifient les assertions qui ont constitué les hypothèses pour certains résultats
concernant la solution statique. Pour les autres des modifications s’imposent, mais par leur
philosophie de conception ces plates-formes semblent bien se prêter à ces modifications.
L’implantation effective ou la modification d’un noyau pouvant gérer les changements
de vitesse du/des processeur(s), les modifications au niveau de la plate-forme de
développement et la mise en œuvre de toutes les conséquences pratiques dans l’implantation
d’une application liées à la consommation d’énergie – bien qu’intéressantes et utiles pour
atteindre le plus d’aspects possibles issus de l’optimisation de la consommation d’énergie –
dépassent le cadre de cette thèse. Ici nous avons voulu premièrement approfondir la théorie
sur la consommation énergétique et deuxièmement passer aux implications dans les domaines
9
Chapitre I
Introduction
pratiques. Sans minimiser l’importance de l’implantation, des projets d’ingénierie devront
être menés consécutivement à notre étude pour la validation expérimentale de notre approche.
Au Chapitre V nous concluons les travaux développés/présentés dans les chapitres
précédents et présentons leurs perspectives. L’idée peut être résumée en disant que les deux
axes développés convergent vers une même solution : affiner l’étape de développement de
l’application pour superposer le mieux possible les notions théoriques et l’implantation réelle
et ainsi trouver la configuration la plus appropriée du système en termes de :
•
nombre de processeurs à utiliser,
•
algorithmes d’ordonnancement,
•
techniques d’implantation des tâches.
Nous indiquons aussi ce qui reste à faire dans la poursuite de ces travaux : des projets pour
passer de l’état théorique de la nouvelle approche à sa mise en pratique, par une implantation
du noyau RTAI sur une architecture physique multiprocesseur, ensuite compléter la théorie
des deux domaines indiqués au début de ce résumé. Tous ces travaux constituent autant de
perspectives de développement pour notre étude, ce qui nous semble, une conséquence
normale de la nouveauté du domaine abordé.
Le but de l’Annexe 1, Etude de cas, est de montrer brièvement que des modèles
mathématiques assez simples – voir même simplistes – peuvent correspondre aux applications
sophistiquées ; c’est le cas du modèle de tâches identiques indépendantes, considéré dans les
chapitres antécédents, obtenu dans une application embarquée temps réel de transmission des
images médicales dans un réseau local sans fil. Nous y présenterons un résumé des travaux
publiés la concernant, réalisés durant la préparation de cette thèse.
10
CHAPITRE II
Etat de l’art
Chapitre II
II.1
Etat de l’art
Introduction
Le thème de l’économie d’énergie pour les systèmes temps réel embarqués se situe à
la confluence de plusieurs domaines assez éloignés les uns des autres : la conception des
systèmes embarqués, y compris les connaissances technologiques à jour sur les performances
des diverses composantes à utiliser, la théorie algorithmique et mathématique de
l’ordonnancement mono et multiprocesseur, la théorie des systèmes d’exploitation temps réel
et la connaissance de ceux actuellement existants. Pour cela cette thèse touche à des domaines
divers, afin d’établir les influences issues de l’optimisation de la consommation énergétique.
Evidemment, proposer de réaliser un exposé détaillé sur tous ces domaines serait une tâche
difficile à accomplir, voire même irréaliste dans le cadre d’une thèse. Par conséquent, le cœur
de cette thèse s’appuie sur nos contributions à la théorie de l’ordonnancement avec
minimisation de la consommation énergétique des processeurs. Nous essayons aussi
d’exprimer des influences et des contraintes imposées par ces résultats sur ces domaines.
Nous présentons donc quelques aspects concernant le déterminisme et l’autonomie des
systèmes temps réel embarqués. Il faut tout d’abord noter que les deux notions, « temps réel »
et « embarqué », apportent des concepts différents qui doivent être pris en compte
simultanément dans l’étude du déterminisme et de l’autonomie.
Dès le début, nous précisons que les concepts présentés sont traités dans le cas d’un
système centralisé - vu comme système où « les décisions, la gestion des ressources,
l’algorithmique et la cohérence des données sont déterminées par l’existence d’informations
dans une mémoire commune accessible à toutes les tâches du système » ([COT 00]) – et ils
sont appliqués aux architectures monoprocesseur et, respectivement, multiprocesseur à
mémoire commune.
Quand nous parlons de « déterminisme » dans ce contexte, nous pensons aux faits
suivants. Durant la conception d’une application temps réel à échéances strictes, nous
connaissons a priori les tâches qui composent l’application et le fonctionnement désiré de
l’application. Cela nous permet d’exprimer un scénario théorique des tâches et d’estimer pour
l’ensemble de tâches données la garantie théorique de leurs échéances. Cependant, ce qui est
important c’est le comportement réel de l’application. Afin d’y parvenir, cette étude préalable
est basée sur des estimations pire-cas du temps d’exécution des tâches. Cela suffit-il, et quelle
est la différence entre l’application théorique et son exécution effective ? Nous pensons ici
non seulement aux différences entre les temps d’exécution réels des tâches et les temps pirecas, mais également aux autres tâches que le système d’exploitation pourrait ajouter, autres
que les tâches effectives de l’application, afin de permettre leur exécution. Autrement dit,
pour un ensemble de tâches donné, quel est, selon l’implantation, l’effet sur le système réel ?
Pour y répondre, une comparaison entre le scénario théorique et le scénario effectif des tâches
s’impose.
Dans cet esprit, chaque concepteur d’un système temps réel doit être familiarisé avec
les résultats les plus importants de la théorie d’ordonnancement et de leurs implications. Nous
passons en revue ces résultats, ainsi que les différents aspects liés à la problématique du
déterminisme de l’exécution des applications temps réel, de la manière dont ils sont
actuellement traités. Après une énumération des concepts utilisés dans la théorie
d’ordonnancement (§II.3.1), les différents algorithmes sont présentés (§II.3.2) ainsi que les
principaux résultats sur l’ordonnancement monoprocesseur (§II.3.3) et multiprocesseur
(§II.3.4) des tâches périodiques indépendantes. La présentation est limitée à ce modèle de
tâches car celui-ci sera traité par la suite pour étudier le deuxième aspect annoncé sur les
12
Chapitre II
Etat de l’art
systèmes temps réel embarqués, l’autonomie. Pour répondre à la problématique du
déterminisme, l’étude sur la théorie d’ordonnancement doit être approchée de l’étude des
systèmes d’exploitation. La section §II.4 porte sur les systèmes d’exploitation temps réel : sur
les notions générales (§II.4.1), sur l’implantation des applications temps réel et le
fonctionnement du noyau (§II.4.2), pour terminer par les caractéristiques principales des
noyaux temps réel Linux (§II.4.3), car un tel noyau sera utilisé dans le Chapitre IV afin
d’illustrer les notions présentées.
Concernant le second concept, « embarqué », ce qui nous intéresse c’est l’autonomie
du système. L’autonomie d’un tel système dépend du choix judicieux des composantes, selon
les caractéristiques désirées de l’application, mais également des techniques d’implantation
utilisées. Dans le chapitre suivant on s’intéresse au deuxième aspect, et notamment à
l’ordonnancement des tâches et la consommation d’énergie au niveau du/des processeur(s).
En traitant le cas des tâches périodiques indépendantes, le développement des idées sera
fortement lié aux notions d’ordonnancement présentées dans la section §II.3. Mais il serait
également intéressant et utile de comprendre les implications de ces résultats théoriques sur la
conception d’un système embarqué. Pour faciliter cette discussion, la section §II.2 évoque les
concepts généraux (§II.2.1) liés aux systèmes embarqués et, en grandes lignes, les phases de
la conception d’un tel système, pour marquer à la fin (§II.2.3) quelques repères sur les
implications issues de la nécessité de minimiser la consommation d’énergie dans le processus
de développement d’un système temps réel embarqué.
Nous concluons (§II.5) en reprenant les idées fondamentales, ce qui nous permet
d’introduire les concepts sur lesquels nous intervenons dans les chapitres qui suivent.
II.2. Sur la conception des systèmes embarqués
II.2.1. Concepts
En reprenant la définition proposée par Wayne Wolf [WOL 00], on considérera
comme système embarqué tout dispositif programmable qui n’est pas un ordinateur dans le
sens proprement dit du terme et qui, compte tenu des caractéristiques de l’application, a une
conception appropriée à celles-ci.
Une classification des systèmes embarqués pourrait être réalisée en rapport à la source
d’énergie utilisée : les systèmes embarqués connectés à une source externe d’énergie (ex.
l’imprimante, le téléviseur, la machine à laver, etc.) et les autres, qui dépendent d’une source
d’énergie autonome ayant une durée de vie finie et souvent faisant partie du même système
(ex. le PDA, le téléphone portable, les différents composants des automobiles modernes, etc.).
Nous nous intéressons à ces derniers systèmes, autonomes du point de vue énergétique.
Pour la plupart des cas, les systèmes embarqués doivent accomplir leurs tâches sous
certaines contraintes de temps. Nous nous intéressons dans le cadre de cette thèse à ceux qui
correspondent à des applications à contraintes strictes.
Pour le processus de développement d’un système embarqué, afin de minimiser le coût
de développement mais également celui du produit final même, une méthodologie de
développement doit être utilisée. Une telle méthodologie consiste en un cadre sémantique et
13
Chapitre II
Etat de l’art
son schéma notationnel – les deux constituant un langage de modélisation (ex. UML, SML) –,
un ensemble de séquences d’activités et un ensemble d’artéfacts de travail. Le processus de
développement décrit les activités qui gouvernent l’utilisation des éléments du langage et
l’ensemble des artéfacts du design ; il représente l’application de ceux-ci dans une séquence
d’activités définies.
II.2.2. Conception
Douglas [DOU 99] identifie les phases de développement d’un système embarqué,
d’une manière générale pour ce qui concerne sa partie logicielle. Elles restent néanmoins les
mêmes pour le développement entier d’un système embarqué, si on ne prend pas en
considération la nécessité de développer un matériel spécifique à l’application, ou ce qu’on
appelle un co-design (construction simultanée de la partie matérielle et logicielle du système).
Ces phases sont les suivantes :
La phase d’analyse – elle consiste à identifier les caractéristiques essentielles de
toutes les solutions possibles pour engendrer le système désiré.
La phase de conception – c’est la phase qui ajoute des éléments à l’analyse afin de
définir une solution particulière qui optimise certains critères.
La phase de implantation – ou la phase qui, automatiquement ou manuellement,
fournit le code source de la partie logicielle du système, pour aboutir à
l’exécutable ; par extension du terme, elle peut représenter aussi la phase qui
fournit les composantes matérielles spécifiques, définies dans la phase de design.
La phase de test – une phase pendant laquelle il est vérifié que l’implantation est
équivalente à la conception, et qui valide que l’implantation respecte tous les
critères de correction identifiés dans la phase d’analyse.
Le modèle d’un système est un ensemble organisé et cohérent d’abstractions qui
collaborent afin d’atteindre la description du système à un certain niveau de détail et de
maturité. Avec cette définition et compte tenu des différentes phases de développement, on
peut parler d’un modèle de l’analyse, de la conception, de l’implantation et du test, des
modèles qui ne sont que des vues différentes du même modèle du système.
Regardant plus profondément dans la phase d’analyse, on constate qu’elle-même
consiste en plusieurs sous phases, plus ou moins détaillées, en fonction de la complexité du
système. Il s’agit de :
L’analyse des conditions requises – ou l’identification des conditions requises par
l’utilisateur et leur structuration dans une forme compréhensible.
L’analyse du système – ou la construction d’un modèle plus rigoureux basée sur
les conditions requises, une construction qui fait une partition du comportement du
système en composantes mécaniques, électroniques et logicielles.
Ces deux phases d’analyse fournissent les éléments de la décomposition fonctionnelle
et comportementale du système, utilisés dans le modèle du système. Ce modèle et les
conditions requises forment les spécifications du système.
L’analyse objet – représente une phase d’analyse généralement approchée de la
phase de développement de la partie logicielle ; elle consiste en une analyse
structurelle d’objet (identifie les unités structurelles de la décomposition d’un
14
Chapitre II
Etat de l’art
objet, comme les classes et les objets proprement dits, leurs unités
organisationnelles et les relations entre ces éléments) et en une analyse
comportementale d’objet (définit les modèles essentiels de comportement
dynamique pour les classes identifiées).
Note : On comprend par objet une partie de la décomposition d’un système. Les objets
collaborent en clusters pour accomplir un certain but.
Pour ce qui concerne la phase de conception, on parle d’une conception :
Architecturelle – qui donne une vue organisationnelle ou déployée des
composantes de l’analyse objet, une vue de développement (les artéfacts non
exécutables sont divisés en différentes parties afin d’être distribués aux différentes
équipes, et les interactions entre les artéfacts sont définies) et une vue
concurrentielle, pour identifier le contexte de concurrence existant entre les
différents objets du système.
Mécanistique – le processus de mettre ensemble les différents mécanismes
identifiés, pour faciliter la collaboration des objets du système.
Détaillée – qui met ensemble toutes les informations données par le design
architecturel et mécanistique, et qui définit les translations qui doivent être
effectuées – en termes de structures à être codées –, la visibilité et le type de
données, la réalisation des associations, agrégations et compositions dans le
langage de programmation choisi.
Ces concepts permettent de penser au processus de développement d’un système
embarqué comme un cycle de vie. Ce cycle de vie, selon la forme dont les différentes phases
s’enchaînent, peut être de type : cascade (angl. « waterfall »), itérative ou par création de
prototypes (« throw-away » ou jeté : ex. les GUI) et/ou en suivant un développement
incrémental, de type « penser à l’horizontale, réaliser à la verticale».
W. Wolf [WOL 00] évoque plusieurs niveaux d’abstraction d’un système embarqué :
les conditions requises, la spécification, l’architecture, le design des composantes,
l’intégration du système. Les mêmes abstractions se retrouvent, sous différents noms de
modèles du système, dans la conception plus détaillée d’un système embarqué proposée par
Douglas [DOU 99]. En ce qui concerne le processus de développement même, [WOL 00]
présente deux techniques : « top-down » – à partir d’une description très abstraite, travailler
jusqu’aux plus petits détails, et « bottom-up » – construire le système en commençant par les
plus petites composantes. D’habitude, la conception réelle est basée sur l’utilisation des deux
techniques simultanément, bien que les phases de raffinement conduisent plutôt à une
approche de type cascade.
Evidement, les étapes générales proposées pour la réalisation d’un système embarqué
deviennent plus concrètes pour une application temps réel précise.
II.2.3. Les aspects de la consommation d’énergie et le cycle de vie d’un
système temps réel embarqué
Il est nécessaire que toute personne travaillant dans la conception des systèmes (temps
réel) embarqués soit familière avec certains résultats classiques concernant chaque phase de
développement d’un tel système, c'est-à-dire des résultats de la théorie d’ordonnancement – y
compris la théorie de la complexité et celle d’optimisation – et aussi de la théorie des
15
Chapitre II
Etat de l’art
systèmes d’exploitation temps réel. Certes, la connaissance de ces résultats ne donne que
rarement une solution directe pour un problème concret, et pourtant leurs implications offrent
des indications importantes pour le bon développement et aident souvent à éviter les choix
inappropriés ou même erronés [STA 95].
Comme on a vu, la phase de conception définit une solution particulière du système
qui optimise certains critères. C’est dans cette phase que plusieurs questions deviennent
essentielles :
Quelles sont les composantes matérielles nécessaires et leurs caractéristiques : la
puissance du/des processeur(s), la taille de la mémoire, etc. ?
Quelle solution adopter pour respecter les échéances : utiliser des composantes
matérielles rapides ou un logiciel bien mis au point ?
Comment minimiser certains critères de coût, parmi lesquels la puissance
consommée ?
On pourrait dire que la conception d’un système temps réel embarqué doit chercher à
couvrir les aspects suivants : la performance, la fonctionnalité et l’interface utilisateur (si
nécessaire), le coût de fabrication, la puissance consommée, la dimension physique, etc. En
voici donc quelques critères à optimiser.
Le fait d’ajouter à l’étude d’optimisation d’énergie la problématique induite par un
système temps réel peut compliquer les choses en apparence. Bien au contraire, l’obligation
de garantir les échéances des tâches d’un tel système permet, pour une étude théorique, de
faciliter la construction d’un modèle mathématique plus précis. Cette partie théorique du
problème est traitée dans le chapitre suivant, qui apporte des résultats nouveaux concernant
l’ordonnancement des tâches et la consommation du/des processeur(s).
Du fait spécifique du problème étudié – l’optimisation énergétique – quelques-uns de
nos résultats théoriques ont un degré d’utilité assez avancé. Ils deviennent généralement utiles
pour les phases d’analyse et de design, afin de choisir une meilleure solution pour la phase de
translation, car ces résultats indiquent, par exemple, le nombre optimal de processeurs à
utiliser et leurs types (à vitesses variables), ainsi que leurs vitesses respectives pour
l’exécution de chaque tâche.
Figure II.1. Energie consommée par les différentes composantes d’un WebPad typique.
Une question pourrait se poser : est-ce que la part d’énergie consommée au niveau du
processeur est significative par rapport aux autres composantes d’un système embarqué pour
justifier une étude à ce niveau ? Un exemple fourni par une étude IDC (International Data
16
Chapitre II
Etat de l’art
Corporation) [IDC 02] indique pour une application WebPad typique que la consommation du
processeur représente environ 30% de la consommation totale du système, la distribution de la
consommation des différentes composantes étant celle indiquée dans la Figure II.1. Bien que
système embarqué, un WebPad, en tant que dispositif d’accès à l’Internet, n’est pas un
système temps réel. Mais pour un tel système l’inexistence d’un dispositif d’affichage
performant (LCD) ne fait qu’augmenter l’importance énergétique des autres composantes, et
notamment celle du processeur.
Par ailleurs, suite à la puissance de plus en plus élevée des processeurs et par
conséquence à une croissance importante de l’énergie consommée ([INT 99], [TRA 03]), les
travaux dans ce domaine ont proliféré même pour les systèmes qui ne sont pas
énergétiquement autonomes. Cela confirme la nécessité de poursuivre les efforts pour mieux
maîtriser l’interaction application – processeur du point de vue énergétique.
Principalement pour les systèmes embarqués autonomes de point de vue
énergétique, mais pas uniquement pour eux, il est utile d’étudier comment
minimiser la puissance consommée. Dans cette thèse nous nous intéressons à
cet aspect, et plus particulièrement à la consommation énergétique du/des
processeur(s) due à l’exécution des tâches de l’application, pour les systèmes
temps réel à échéances strictes.
Il est également utile de voir les implications des résultats théoriques
mentionnés pour les différentes phases du cycle de vie d’un système temps réel
embarqué. Ainsi nous avons évoqué les quelques notions sur le développement
d’un tel système. A cause du fait qu’il faut tout d’abord comprendre la
signification et les implications de cette approche, on ne peut pas les
mentionner à ce stade ; elles seront évoquées au fur et à mesure qu’elles se
révèleront utiles dans le développement de ce travail. Toutes ces informations
seront réunies à la fin, parmi les conclusions présentées dans le dernier
chapitre.
II.3. Théorie de l’ordonnancement
La littérature concernant la théorie d’ordonnancement est si vaste qu’on ne peut
prétendre ici en présenter tous les aspects. Nous allons nous contenter d’indiquer ceux qui
sont à la fois les plus importants et utiles au développement ultérieur de la thèse. Plusieurs
travaux contenant une synthèse plus ou moins détaillée existent actuellement, dont quelquesuns ont particulièrement servi à cette rédaction : [BON 99], [COF 76], [COT 00], [DEP 02],
[GAR 79], [GEO 96], [GEO 00], [GOO 02], [KAT 93], [LIU 00], [MOK 93], [PAR 02] et
particulièrement [STA 95]. Pour les résultats les plus importants nous indiquerons la
référence d’origine.
Les concepts de base sont d’abord présentés (§II.3.1) et ensuite les principes des
principaux algorithmes d’ordonnancement (§II.3.2). Les sections §II.3.3 et §II.3.4 traitent des
différents aspects de l’ordonnancement mono et, respectivement, multiprocesseur : la
faisabilité des ensembles de tâches, l’optimalité des algorithmes d’ordonnancement selon les
17
Chapitre II
Etat de l’art
caractéristiques des tâches et la complexité des différents problèmes d’ordonnancement,
surtout dans le cas multiprocesseur. Vu la multitude de résultats, la présentation est restreinte
aux plus importants concernant les tâches indépendantes et les tâches périodiques
indépendantes, qui seront prises en considération dans les chapitres suivants. La sous-section
§II.3.4.3 présente une approche différente de l’ordonnancement d’un ensemble de tâches, peu
abordée jusqu’à présent, où le nombre de processeurs nécessaires pour garantir les échéances
des tâches est à déterminer. Des aspects comme le partage des ressources et la surcharge des
processeurs seront évoqués (§II.3.3.2 et §II.3.4.2), pour montrer des difficultés liées à la
transposition d’une application temps réel en pratique, difficultés qui peuvent être surmontées
jusqu’à un certain point par les connaissances théoriques.
II.3.1. Concepts de base
Les tâches sont les entités de base de l’ordonnancement temps réel et elles sont
périodiques ou apériodiques, à contraintes temporelles strictes ou relatives [COT 00]. Les
stratégies d’ordonnancement sont des règles qui sélectionnent la prochaine tâche qui doit
être exécutée dans un système multitâche. Autrement dit, elles décident de l’ordre dont les
tâches vont accéder à la ressource la plus importante du système, le processeur. Au niveau du
noyau du système d’exploitation ces stratégies constituent l’ordonnanceur (angl. scheduler).
L’algorithme d’ordonnancement détermine, selon la politique (la stratégie d’ordonnancement)
implantée, l’ordre effectif d’exécution des tâches : l’ordonnancement ou, autrement dit, le
scénario des tâches.
Différentes méthodes d’implantation de l’ordonnanceur sont envisagées, selon le type
de machine mono ou multiprocesseur. Pourtant, dans les deux cas, les politiques
d’ordonnancement reposent sur les mêmes principes, et les informations dont elles ont besoin
représentent les différents paramètres des tâches.
Les paramètres spécifiques pour le modèle canonique des tâches sont illustrés dans la
Figure II.2 :
Figure II.2. Modèle canonique de tâche [COT 00].
où la signification des symboles est la suivante :
•
R – le moment de la première requête d’exécution de la tâche,
•
C – la durée d’exécution maximale de la tâche, quand elle dispose du processeur
pour elle seule (le coût d’exécution),
•
D – le délai critique acceptable pour l’exécution de la tâche (l’échéance),
•
P – la période, s’il s’agit d’une tâche périodique.
18
Chapitre II
Etat de l’art
Si l’échéance et la périodicité de la tâche sont égales (D=P), la tâche est à échéance
sur requête.
D’autres contraintes peuvent être ajoutées pour compléter ces paramètres de base, en
définissant différents modèles de tâches : relations de précédence sur l’ensemble (ou sur une
partie) des tâches, partage des ressources entre les tâches, préemption, dépendance des tâches,
priorité externe, gigue maximale, urgence.
Note : Pour la suite, nous appellerons tâches temps réel les tâches à contraintes temporelles
(échéances) strictes. Les modèles de tâches qui nous intéressent sont les modèles de tâches
indépendantes.
On
appelle
algorithme
d’ordonnancement
statique
un
algorithme
d’ordonnancement qui suppose connues a priori les différentes caractéristiques des tâches
présentées auparavant. Par contre, un algorithme d’ordonnancement dynamique suppose
une connaissance complète de l’ensemble des tâches actives à un moment donné ; d’autres
tâches peuvent s’activer ultérieurement sans que l’algorithme d’ordonnancement le sache à ce
moment.
Une autre typologie des stratégies d’ordonnancement fait référence au moment où les
décisions d’ordonnancement sont prises, et on parle d’ordonnancement hors ligne ou en
ligne.
Un ordonnancement hors ligne se fait à chaque analyse sur le design d’un système
temps réel, pour évaluer si l’algorithme à appliquer au système réel sera statique ou
dynamique. Si la connaissance a priori sur le système indique un environnement très
dynamique, il est évident qu’un algorithme statique n’est pas envisageable, et qu’un
ordonnancement dynamique s’impose, bien que celui-ci soit analysé tout d’abord hors ligne.
Suite à l’analyse préalable et après l’implantation nécessaire, l’ordonnancement en ligne va
appliquer au fonctionnement du système l’algorithme d’ordonnancement choisi.
Une caractéristique importante qui doit être prise en compte dans la stratégie
d’ordonnancement est liée à la préemption des tâches. Une tâche est préemptible si, une fois
élue, l’exécution de celle-ci peut être arrêtée et la tâche remise à l’état prêt, pour
réquisitionner le processeur au profit d’une autre tâche (jugée plus urgente). Dans le cas
contraire, si la tâche en cours d’exécution ne peut pas être arrêtée avant la fin de son
exécution, celle-ci est dite non préemptible. Du même point de vue, il existe aussi le cas dit
« hybride » selon que les tâches (ou des sections de tâches) peuvent être ou non préemptibles.
On appelle ordonnancement faisable (séquence valide) d’un ensemble
(configuration) de tâches temps réel, l’ordonnancement qui respecte les échéances de toutes
les tâches (i.e. la séquence délivrée par un algorithme d’ordonnancement, où toutes les tâches
respectent leurs contraintes temporelles). Un ensemble (configuration) de tâches est
ordonnançable s’il admet un ordonnancement faisable (i.e. s’il existe un algorithme capable
de fournir un ordonnancement faisable, ou séquence valide, pour cette configuration). Des
résultats importants ont été obtenus concernant la faisabilité des différents ensembles de
tâches. Ces résultats représentent le point de départ pour toute étude sur le déterminisme de
l’exécution d’une application temps réel.
La théorie de l’ordonnancement classique utilise différentes métriques afin de
comparer les résultats des différents ordonnancements, et d’estimer la complexité des
différents problèmes d’ordonnancement. Pour les designers de systèmes temps réel quelques19
Chapitre II
Etat de l’art
unes d’entre elles s’avèrent utiles, malgré le fait qu’elles ne prennent pas en compte les
échéances des tâches. Parmi ces métriques nous citons : la somme pondérée d’achèvement des
temps des tâches, la longueur de l’ordonnancement, le nombre de processeurs nécessaires, la
valeur maximale du retard des tâches, etc. A part les informations fournies par ces métriques,
et plus important pour les applications temps réel, c’est de minimiser le nombre de tâches qui
ratent leurs échéances ou de trouver des algorithmes d’ordonnancement optimaux dans le sens
suivant.
Un ordonnanceur (algorithme d’ordonnancement) est dit optimal dans le sens
suivant : si un ordonnancement qui respecte toutes les échéances peut être produit par un
algorithme quelconque, l’algorithme optimal mène aussi vers un ordonnancement qui
garantisse les échéances de toutes les tâches [DER 89].
Dans l’analyse d’un système temps réel, il est aussi important de connaître la
complexité du modèle de tâches traité, en fonction de la machine (i.e. le nombre de
processeurs à prendre en compte) et de la métrique utilisée pour formuler le problème
d’ordonnancement de l’ensemble de tâches qui constitue l’application. Selon [LAW 83], trois
paramètres sont présents dans la notation qui décrit la définition d’un problème
d’ordonnancement sous la forme :
α β γ
où α indique le type de la machine (nombre de processeurs), β indique le modèle des tâches
(préemptibles ou non, indépendantes ou non, contraintes de précédence, échéances, etc.), et γ
indique le critère d’optimalité pris en compte, selon la métrique utilisée. Ce formalisme
permet d’exprimer un problème d’ordonnancement comme un problème d’optimisation et,
par la suite, de traiter sa complexité. Il est important de savoir qu’il y a beaucoup de
problèmes d’optimisation NP-complets ou NP-hard, et il faut s’assurer de ne pas se trouver
dans un tel cas.
On note par NP la classe de tous les problèmes de décision qui peuvent être résolus
dans un temps polynomial par une machine non déterministe. Un problème de reconnaissance
R est NP-complet si R ∈ NP et si tout autre problème NP est transformable polynomial en R.
Un problème de reconnaissance ou d’optimisation R est NP-hard si tous les problèmes NP
sont transformables polynomial à R, mais il n’est pas possible de prouver que R ∈ NP . Pour
plus de détails sur la théorie de la complexité nous indiquons comme monographie de
référence [GAR 79], qui inclut aussi un chapitre concernant les problèmes d’ordonnancement.
Pour une liste contenant les résultats à jour sur la complexité des différents problèmes
d’ordonnancement on peut consulter [ORD 03].
Nous introduisons ici quelques notations qui caractérisent la relation entre les tâches et
le processeur qui les exécute. Il s’agit du facteur d’utilisation du/des processeurs pour une
configuration de n tâches périodiques :
n
C
U =∑ i ,
i =1 Pi
et du facteur de charge du/des processeurs pour une configuration de n tâches périodiques :
n
C
CH =∑ i .
i =1 Di
Dans les sous-sections suivantes concernant la théorie de l’ordonnancement, nous
présentons les principes des algorithmes d’ordonnancement principaux (§II.3.2), ainsi que les
différents résultats liés à l’ordonnancement des tâches indépendantes à échéances strictes, et
plus particulièrement pour les tâches périodiques, par les machines mono (§II.3.3) et,
20
Chapitre II
Etat de l’art
respectivement, multiprocesseurs (§II.3.4).
Toute référence à une machine monoprocesseur suppose une vitesse constante de
fonctionnement du processeur. Aussi, toute référence à une machine multiprocesseur
suppose une vitesse de fonctionnement constante et égale pour tous les processeurs.
II.3.2. Algorithmes d’ordonnancement
Cette sous-section expose brièvement les principes des différents algorithmes
d’ordonnancement, en fournissant aussi des exemples de leur fonctionnement [COT 00] dans
le cas monoprocesseur, et pour des tâches indépendantes et préemptibles.
Dans la littérature on distingue quatre catégories principales d’algorithmes
d’ordonnancement [BON 99] :
• statiques pilotés par table ;
• statiques préemptifs basés sur des priorités ;
• dynamiques basés sur une planification de l’exécution ;
• dynamiques basés sur la notion du meilleur effort (best effort).
Les algorithmes dynamiques sont les plus flexibles car ils permettent la prise en
compte d’événements « non prévus ». Parmi ceux-ci les principaux sont :
• l’ordonnancement par priorités fixes :
premier arrivé, premier servi (First-Come, First-Served – FCFS) où toutes
les tâches ont la même priorité ;
le tour de rôle ou tourniquet (Round Robin – RR) ;
monotone par fréquences (Rate-Monotonic – RM) ;
monotone par échéances (« Invers Deadline » - ID, ou « Deadline
Monotonic » -DM)
• l’ordonnancement par priorités dynamiques :
Earliest Deadline First – EDF ;
Least Slack Scheduling – LLS, ou Least Laxity First – LLF, ou Shortest
Slack Time – SST.
Dans un cadre plus général, les mêmes principes d’ordonnancement s’appliquent aux
tâches sur une machine monoprocesseur comme sur une plate-forme multiprocesseur. Dans ce
dernier cas quelques hypothèses spécifiques à l’existence de plusieurs processeurs sont prises
en compte :
•
l’exécution d’une tâche n’est pas associée à un processeur déterminé ;
•
à tout instant une tâche ne peut s’exécuter que sur un seul processeur.
Pour certaines situations spécifiques aux applications, la première hypothèse peut ne
pas être valable ; cette thèse ne traite pas cet aspect.
21
Chapitre II
II.3.2.1.
Etat de l’art
“Rate-monotonic” (RM)
Principe de fonctionnement : l’algorithme « rate-monotonic » est un algorithme statique qui
attribue la plus haute priorité à la tâche ayant la fréquence la plus élevée (la plus petite
période) [LIU 73].
La Figure II.3 indique l’ordonnancement « rate-monotonic » de trois tâches
périodiques à échéances sur requêtes : T1(R1=0, C1=3, P1=20), T2(R2=0, C2=2, P2=5) et
T3(R3=0, C3=2, P3=10). La tâche la plus prioritaire est la tâche T2 (P2=5), et la tâche la moins
prioritaire est la tâche T1(P1=20). La séquence est décrite sur l’intervalle [0,20] =
[0,ppcm(Pi)], et les trois tâches respectent leurs contraintes temporelles. A observer la
répétitivité de la séquence durant tout intervalle ayant la forme [k∗ppcm(Pi),(k+1)∗ppcm(Pi)],
k≥0, k∈Ν, où ppcm(Pi) représente le plus petit multiple commun des périodes Pi.
Figure II.3. Rate-monotonic.
Notons que l’utilisation de la périodicité comme critère d’ordonnancement limite
l’applicabilité de cet algorithme aux seules tâches périodiques à échéance sur requête.
L’utilisation de cet algorithme pour d’autres types de tâches ne donne aucune garantie pour le
respect des échéances.
II.3.2.2.
“Inverse Deadline” (ID) ou “Deadline Monotonic” (DM)
Principe de fonctionnement : l’algorithme « inverse deadline » est un algorithme statique où
les priorités des tâches sont exprimées en fonction de leurs délais, la tâche la plus prioritaire
étant celle qui a le plus petit délai [LEU 80].
La Figure II.4 indique l’ordonnancement « inverse deadline » des trois tâches
périodiques suivantes : T1(R1=0, C1=3, D1=7, P1=20), T2(R2=0, C2=2, D2=4, P2=5) et T3(R3=0,
C3=2, D3=9, P3=10). La tâche la plus prioritaire est la tâche T2 (D2=4), et la tâche la moins
prioritaire est la tâche T3(D3=9). La séquence est décrite sur l’intervalle [0,20] = [0,ppcm(Pi)],
et les trois tâches respectent leurs contraintes temporelles.
Figure II.4. Inverse Deadline.
22
Chapitre II
Etat de l’art
Notons que, par rapport à l’algorithme Rate-monotonic, étant basé sur la notion
d’échéance, cet algorithme s’applique aussi bien pour d’autres modèles de tâches que ceux
des tâches à échéances sur requêtes.
II.3.2.3. “Least Laxity First” (LLF)
La laxité L(t ) d’une tâche au moment t représente son retard maximum par rapport à
son échéance pour (re)prendre son exécution, quand la tâche s’exécute seule :
L (t ) = D (t ) − C (t ) .
Principe de fonctionnement : L’algorithme “least laxity first” attribue, à l’instant t, la plus
haute priorité à la tâche ayant la plus petite laxité. Le calcul des laxités des tâches peut se
faire :
•
aux dates de réveil des tâches – cas où la séquence produite est équivalente à celle
produite par EDF,
•
à chaque instant – cas qui entraîne plus de changements de contexte.
La Figure II.5 indique un ordonnancement donné par LLF des trois tâches
périodiques : T1(R1=0, C1=3, D1=7, P1=20), T2(R2=0, C2=2, D2=4, P2=5) et T3(R3=0, C3=1,
D3=8, P3=10). A l’instant t=0 la tâche la plus prioritaire est la tâche T2 (L2=2), et la tâche la
moins prioritaire est la tâche T3(L3=7). Le calcul des laxités est fait aux dates de réveil des
tâches et, si deux tâches ont la même laxité au même instant, celle qui s’exécute en première
est celle d’indice plus petit (comme le montre le cas de l’instant t=5 où les tâches T2 et T3 ont
la même laxité, 2). La séquence est décrite sur l’intervalle [0,20] = [0,ppcm(Pi)], et les trois
tâches respectent leurs contraintes temporelles.
Figure II.5. Least Laxity First.
II.3.2.4. “Earliest Deadline First” (EDF)
Principe de fonctionnement : L’algorithme “Earliest Deadline First” attribue, à l’instant t,
la plus haute priorité à la tâche ayant la plus proche échéance.
La Figure II.6 indique un ordonnancement donné par EDF des trois tâches
périodiques : T1(R1=0, C1=3, D1=7, P1=20), T2(R2=0, C2=2, D2=4, P2=5) et T3(R3=0, C3=1,
D3=8, P3=10). A l’instant t=0 la tâche la plus prioritaire est la tâche T2 (D2=4), et la tâche la
moins prioritaire est la tâche T3(D3=8). Les priorités des tâches, et donc l’ordre de leur
exécution, évoluent les unes par rapport aux autres en fonction de leur urgence. La séquence
est décrite sur l’intervalle [0,20] = [0,ppcm(Pi)], et les trois tâches respectent leurs contraintes
temporelles.
23
Chapitre II
Etat de l’art
Figure II.6. Earliest Deadline First.
Note : EDF* est la notation utilisée pour l’algorithme EDF où, parmi les tâches ayant la
même échéance, celle qui arrive en première sera élue.
II.3.3. Ordonnancement monoprocesseur
Cette section constitue un état de l’art sur l’ordonnancement monoprocesseur des
tâches indépendantes, à échéances strictes, et plus particulièrement pour les tâches
périodiques. Les propriétés concernant l’ordonnancement pour ces modèles de tâches
(§II.3.3.1) sont présentés, pour mettre ensuite en évidence quelques restrictions imposées au
niveau des tâches par une implantation effective et certaines de leurs conséquences (§II.3.3.2).
II.3.3.1. Propriétés concernant l’ordonnancement des tâches indépendantes
Les résultats suivants portent sur l’importance de la préemption, et sont
particulièrement connus et liés à la loi de Jackson. Soit Tn={T1,T2,…,Tn} un ensemble de n
tâches indépendantes, prêtes à s’exécuter au même instant t=0 ; chaque tâche Ti est
caractérisée par son coût d’exécution Ci et son échéance Di. Pour chaque séquence
d’ordonnancement, l’exécution réelle de la tâche finit dans Ci,réel unités de temps. Si le retard
de la tâche Ti est défini comme :
Li = C i ,reel − Di ,
et le but est de minimiser la valeur maximale du retard :
{ }
Lmax = max Li ,
i =1,K, n
avec un ordonnancement sans préemption, le problème d’optimisation se formalise comme :
1 nopmtn Lmax
et sa solution est donnée par :
Théorème II.1 : (Loi de Jackson) Toute séquence d’ordonnancement monoprocesseur sans
préemption d’un ensemble de n tâches indépendantes prêtes à s’exécuter au même instant
t=0, qui met les tâches dans l’ordre non décroissant de leurs échéances, est optimale pour le
problème formalisé comme :
1 nopmtn Lmax .
24
Chapitre II
Etat de l’art
L’algorithme donné par ce théorème est connu sous le nom de « earliest due date »
(EDD), i.e. « l’échéance premier d’abord », et c’est un algorithme statique qui permet
facilement d’avoir une première information sur la faisabilité d’un ordonnancement d’un tel
ensemble de tâches. Notons que la préemption n’apporte rien à la faisabilité dans cette
situation. De plus, si le modèle de tâches est plus général, le problème se complique :
Théorème II.2 : [LEN 77] Le problème d’ordonnancement monoprocesseur sans préemption
d’un ensemble de n tâches indépendantes, ayant des moments d’activations ri différents :
1 nopmtn, ri Lmax
est NP-hard.
Par contre, dans cette situation, si les tâches ont des coûts d’exécution unitaires, alors :
Théorème II.3 : [LAW 83] Il existe une solution polynomiale pour le problème :
1 nopmtn, ri , C i = 1 Lmax .
Aussi, si les préemptions sont permises alors le problème a une solution et sa
complexité est polynomiale. Le résultat est basé sur la loi de Jackson modifiée :
Théorème II.4 : [STA 95] Toute séquence d’ordonnancement monoprocesseur permettant les
préemptions d’un ensemble de n tâches indépendantes, ayant des moments d’activation ri
différents, qui à tout moment met les tâches dans l’ordre non décroissant de leurs échéances,
est optimale pour le problème formalisé comme :
1 pmtn, ri Lmax .
La conclusion que l’on peut tirer est que la préemption est extrêmement bénéfique de
point de vue de la complexité des ordonnancements. Aussi, si nous mettons la condition
d’avoir le retard maximal inférieur ou égal à zéro, alors l’ordonnancement devient faisable,
assurant les échéances de toutes les tâches. En étendant l’étude aux tâches périodiques,
d’autres résultats s’ajoutent :
Théorème II.5 : Pour des tâches quelconques, indépendantes, une condition suffisante
d’ordonnancement sur une machine monoprocesseur est : CH ≤ 1 , et une condition
nécessaire est : U ≤ 1 .
Si on ajoute aux tâches la condition d’être à échéance sur requête, on obtient une
condition nécessaire et suffisante pour l’ordonnancement :
Théorème II.6 : [LIU 73] Pour un ensemble de tâches périodiques, indépendantes, à
25
Chapitre II
Etat de l’art
échéance sur requête, une condition nécessaire et suffisante d’ordonnancement sur une
machine monoprocesseur est : U ≤ 1 .
Avec ces conditions générales sur la faisabilité, il est utile de connaître les propriétés
des différents algorithmes d’ordonnancement, appliqués aux différents modèles de tâches, et
leur puissance d’applicabilité. Nous en citons ici les plus importants, en commençant par le
plus performant, l’EDF.
Il est dénommé période active du scénario synchrone, la période [0, L[ délimitée par
deux périodes distinctes où le processeur travaille à vide dans l’ordonnancement de
l’ensemble de tâches considérées synchrones (i.e. prêtes à s’exécuter à l’instant t=0). Le
résultat suivant indique la période d’étude qui permet d’en tirer une conclusion sur la
faisabilité d’un ordonnancement avec EDF.
Théorème II.7 : [LIU 73], [KAT 93] Tout problème d’ordonnancement d’un ensemble de
tâches non-concrètes (i.e. les moments d’activation des tâches ne sont pas connus a priori)
périodiques ou sporadiques, avec Di=Pi, ordonnancé par EDF, est faisable si et seulement si
aucune tâche ne rate son échéance absolue pendant la première période active du scénario
synchrone.
Sur cette période, il a été démontré que :
Théorème II.8 : Pour l’ordonnancement monoprocesseur de tâches périodiques,
indépendantes, à échéance sur requête, il existe des algorithmes d’ordonnancement optimaux,
parmi lesquels EDF [LIU 73] et LLF [MOK 83].
Mais l’algorithme EDF se montre également puissant pour d’autres modèles de
tâches :
Théorème II.9 : [DER 74] L’ordonnanceur EDF est optimal pour des tâches préemptibles,
pas nécessairement périodiques.
Comme nous l’avons vu, la préemption des tâches peut simplifier le problème
d’ordonnancement mais d’autre part, avoir un nombre élevé de préemptions engendre des
temps de calcul supplémentaires. Pour cela le résultat suivant indique une comparaison entre
le nombre de préemptions nécessaires dans l’ordonnancement d’un même ensemble de tâches
par des algorithmes différents. Une fois de plus l’algorithme EDF s’avère le plus puissant.
Théorème II.10 : [DER 89] Le nombre de préemptions durant l’exécution d’un ensemble de
tâches selon l’ordonnancement imposé par EDF est au maximum la moitié du nombre de
préemptions induites par tout autre ordonnancement.
26
Chapitre II
Etat de l’art
En ce qui concerne les algorithmes à priorités statiques, nous faisons référence aux
propriétés de Rate-monotonic et de Inverse Deadline et nous avons les résultats suivants.
Théorème II.11 : L’algorithme « rate-monotonic » est optimal dans la classe des algorithmes
à priorité statique pour le cas d’une plate-forme monoprocesseur exécutant des
configurations de tâches à échéance sur requête.
Théorème II.12 : [LIU 73] Un ensemble de n tâches indépendantes périodiques peut être
ordonnancé par l’algorithme Rate-monotonic si
(
n
)
1
Ci
n
≤
n
2
−1 .
∑
P
i =1 i
Cottet et al. indiquent [COT 00] que la même condition de suffisance a été montrée
pour l’algorithme Inverse Deadline (en remplaçant Pi par Di).
En interprétant ce résultat, nous constatons que pour un nombre élevé de tâches, la
limite supérieure de la charge processeur afin de permettre un ordonnancement avec RM est
inférieure à 69%. Par contre, si les tâches sont harmoniques (toutes les périodes sont multiples
ou sous-multiples des autres périodes), cette limite est 1. Dans son étude expérimentale sur
des tâches avec des périodes et des coûts d’exécutions aléatoires, Lehoczky [LEH 89] a
obtenu en moyenne une limite de 88%.
II.3.3.2. Restrictions imposées aux tâches par l’implantation et conséquences
Nous avons pu voir certaines propriétés concernant l’ordonnancement des tâches
indépendantes, et constater que souvent la préemption peut rendre un problème insoluble
facile à résoudre (Th. II.2, Th. II.4). D’autre part, si dans le système temps réel, suite à
l’implantation, il y a un partage de ressource, pour traiter les sections critiques des tâches,
une solution est de rendre le code nonpréemptible, ce qui peut conduire à un problème NPhard. Dans ce sens, il y a quelques résultats, qui concernent surtout les ordonnancements
totalement en ligne, dont nous mentionnons les suivants.
Théorème II.13 : [MOK 83] Il est impossible de trouver un ordonnanceur optimal totalement
en ligne si les tâches ont des contraintes d’exclusion mutuelle.
Théorème II.14 : [MOK 83] Soit T un ensemble de tâches périodiques qui utilisent
uniquement les sémaphores pour traiter les exclusions mutuelles. Décider si T est ordonnable
est un problème NP-hard.
Selon Mok [MOK 83], ce résultat est dû au fait que les exclusions mutuelles ont des
temps de calcul différents pour différentes tâches et, par conséquent, une solution serait de
forcer à rendre égaux les temps d’exécution des blocs d’exclusion mutuelle.
27
Chapitre II
Etat de l’art
Une autre solution est connue sous le nom d’héritage de priorité ([KAI 81], [SHA
90]). Elle est basée sur l’idée d’héritage, par la tâche ayant le contrôle de la ressource, de la
priorité la plus élevée des tâches en attente de cette ressource. Celle-ci a été conçue pour
fonctionner avec RM, et a été étendue ultérieurement pour fonctionner avec EDF [CHE 90].
Comme il est montré dans [SHA 90] et [RAJ 95], cela permet de résoudre les cas simples,
mais il peut apparaître des blocages successifs qui peuvent allonger de manière considérable
le temps d’exécution d’une tâche. Yodaiken [YOD 01] apporte encore d’autres informations
et exemples sur les dangers de l’héritage de priorité. [RAJ 95] modifient l’algorithme, en
formulant le Priority Ceiling Protocol qui, selon eux, permet de résoudre le problème de
blocage en chaîne.
Pour le même problème de partage des ressources, Baker [BAK 91] propose un
protocole similaire : Stack Resource Policy, qui gère des situations plus générales. L’idée de
base est de bloquer la tâche qui a besoin d’une ressource utilisée par une autre tâche au
moment de sa demande de préemption.
Un autre problème qui se pose dans un système temps réel, même dans le cas des
tâches indépendantes, est le comportement de celui-ci en cas de surcharge. Il a été montré par
des expérimentations [LOC 86] que la performance de EDF et LLF se dégrade rapidement
dans les périodes de surcharge.
Dans le cas de EDF, il y a un effet de « domino » parmi les tâches qui ratent leurs
échéances. Dans de telles situations, EDF ne fournit aucune garantie sur les tâches qui
respectent leurs échéances, cas totalement impropre pour un système temps réel à échéances
strictes. Certains algorithmes heuristiques ont été proposés pour traiter les cas de surcharge et
renforcer la puissance de EDF ([HAR 91], [THA 89]).
Pour permettre de gérer les situations de surcharge, la solution générale employée est
d’associer à chaque tâche une valeur qui exprime son importance parmi les autres et, en cas
de surcharge, d’ordonnancer les tâches selon ces valeurs. Parmi les études concernant cette
idée nous mentionnons [DEL 94, 96, 98]. Un algorithme est donné par la loi de Smith :
Théorème II.15 : (loi de Smith) [SMI 56] Trouver un ordonnancement optimal pour :
1
∑w C
i
i , réel
,
est donné par toute séquence qui met les tâches dans l’ordre non décroissant des rapports
qi = C i wi .
D’autre part, si on impose des restrictions à l’ensemble des tâches, les résultats
changent :
Théorème II.16 : [LEN 77] Le problème suivant est NP-complet :
1 Di
∑w C
i
Mais, par contre :
28
i , réel
.
Chapitre II
Etat de l’art
Théorème II.17 : La solution du problème suivant est un algorithme polynomial optimal :
1 Di
∑C
i , réel
.
De plus, Baruah et al. [BAR 91] ont montré qu’il existe une borne supérieure de la
performance de tout algorithme en ligne préemptif dans des conditions de surcharge. Le
résultat est basé sur la notion de facteur de compétitivité, estimé par rapport à un algorithme
clairvoyant (un algorithme qui connaît le futur), et exprimé par le rapport entre la valeur
cumulative de l’algorithme même et celle de l’algorithme clairvoyant. Cette valeur
cumulative est donnée par la métrique suivante : la valeur associée à une tâche coïncide avec
le temps d’exécution réel si la tâche finit son exécution tout en respectant son échéance ; dans
le cas contraire la valeur associée est nulle.
Théorème II.18 : [BAR 91] Il n’existe pas d’algorithme d’ordonnancement en ligne avec un
facteur de compétitivité supérieur à 0,25.
Il faut noter que la marge indiquée par ce théorème a une valeur théorique et générale,
et qu’elle varie en fonction de la charge effective du système [STA 95] : 1 pour une charge de
1, entre 0,385 et 0,25 pour une charge entre 1 et 2, et inférieure à 0,25 pour toute charge
supérieure à 2.
Une autre solution propose d’assigner des importances aux tâches en fonction du
temps et plusieurs algorithmes ont été développés (voir [COT 00]), le but étant de maximiser
la somme des importances des tâches garanties.
Pour les tâches périodiques, deux approches existent (voir [COT 00]). L’une est la
méthode du mécanisme à échéance, où chaque tâche a une version dite primaire, qui produit
une bonne qualité de service mais au bout d’un temps indéterminé, et une version dite
secondaire, qui fournit un résultat suffisamment acceptable au bout d’un temps dont la durée
est connue à l’initialisation. Dans l’autre approche, la méthode du calcul approché, chaque
tâche est décomposée en deux parties : une partie obligatoire qui fournit un résultat approché
en garantissant l’échéance, et une partie optionnelle qui affine le résultat, et qui est exécutée
s’il reste assez de temps. Il reste à voir, en fonction du type de l’application, si l’une ou l’autre
de ces méthodes est applicable, ou si une autre solution (par exemple l’augmentation de la
puissance de calcul de la machine) doit être employée.
II.3.4. Ordonnancement multiprocesseur
Les travaux concernant l’ordonnancement temps réel multiprocesseur à contraintes
strictes sont généralement basés sur la supposition que tous les processeurs sont identiques et
à mémoire commune. Pourtant, les théoriciens de l’ordonnancement font bien la distinction
entre au moins trois types différents de machines multiprocesseurs [GOO 02] :
•
Machines parallèles identiques : machine à plusieurs processeurs identiques
(ayant la même capacité de calcul) ;
•
Machines parallèles uniformes : chaque processeur est caractérisé par sa propre
capacité de calcul s (une tâche qui demande t cycles CPU, s’exécutera en s×t
29
Chapitre II
Etat de l’art
unités de temps) ; ceci généralise le cas précédent ;
•
Machines parallèles sans relation (le cas le plus général) : pour chaque paire (Ti,
Pj), où Ti représente une tâche et Pj un processeur, le taux associé rij indique que la
tâche Ti, dans une exécution durant t unités de temps sur le processeur Pj, complète
de rij×t son temps d’exécution.
L’ordonnancement multiprocesseur s’averre particulièrement difficile, d’une part suite
à la complexité de ces problèmes et d’autre part suite au manque d’expérience pratique dans
le domaine. Les principaux résultats que nous indiquons le montrent. Malgré ceci, il existe de
plus en plus de systèmes temps réel multiprocesseur et, comme nous le montrons dans le
chapitre suivant, l’utilisation des plateformes multiprocesseurs SoC permettant de faire des
économies d’énergie significatives.
Ce chapitre traite des différentes techniques d’ordonnancement relatives aux machines
parallèles identiques à mémoire commune, le cas habituellement utilisé par la théorie de
l’ordonnancement. Comme dans le cas monoprocesseur, les tâches indépendantes sont
concernées. Les deux derniers types de machines parallèles seront pris en compte dans les
chapitres suivants, sur l’ordonnancement des tâches, optimal du point de vue de la
consommation d’énergie. La troisième architecture mentionnée, qui correspond à une
machine parallèle sans relation, s’avérera particulièrement utile pour notre étude en tant que
machine multiprocesseur à mémoire commune et à vitesse variable, selon la tâche à exécuter ;
notamment au chapitre suivant de la thèse, qui porte sur l’ordonnancement et la
consommation d’énergie au niveau du/des processeur(s).
II.3.4.1. Propriétés concernant l’ordonnancement des tâches indépendantes
Nous commençons la présentation par mettre en évidence les connaissances
nécessaires sur l’ensemble de tâches qui permettront de connaître l’existence d’un algorithme
d’ordonnancement optimal pour un ensemble de tâches donné. Comme la notion d’échéance
est particulièrement importante, le principal résultat porte sur les algorithmes basés sur
l’échéance des tâches.
Théorème II.19 : [DER 89] (Le problème de la connaissance insuffisante) Un algorithme
d’ordonnancement basé sur la notion d’échéance ne peut pas être optimal pour une machine
multiprocesseur, sans avoir une connaissance a priori complète sur les durées d’exécution
des tâches, leurs échéances et leurs moments d’activation.
Ceci dit, la connaissance a priori des trois paramètres les plus importants des tâches
conduit forcement à des études hors ligne et à une étroite liaison entre l’ensemble des tâches
et l’algorithme utilisé. Les algorithmes d’ordonnancement classique qui ont besoin des
moments d’activation peuvent ne pas être optimaux dans une utilisation en ligne, et on ne peut
pas espérer trouver un algorithme optimal pour le cas général.
Dans ce cas, il serait aussi très utile d’avoir des conditions nécessaires et suffisantes
pour la faisabilité d’un ensemble de tâches, et de connaître les propriétés des algorithmes par
rapport aux différents modèles de tâches. L’analyse est encore loin des résultats précis et
concis du cas monoprocesseur. Il n’existe pas, à l’heure actuelle, de condition à la fois
nécessaire et suffisante, au moins pour les tâches périodiques, indépendantes, à échéance sur
30
Chapitre II
Etat de l’art
requête. Ci-dessous sont présentés les principaux résultats :
Théorème II.20 : [DER 89] Pour un ensemble de tâches périodiques, indépendantes, à
échéance sur requête, une condition nécessaire d’ordonnancement sur une machine à m
processeurs est : U ≤ m .
Théorème II.21 : [DER 89] Pour un ensemble de tâches périodiques, indépendantes, à
échéance sur requête, qui respectent la condition nécessaire de faisabilité (Th. II.20), il existe
C
un ordonnancement faisable si D i ∈ N , ∀i = 1,K , n , où D = pgcd D1 ,K, Dn .
Di
(
)
La notation « pgcd » représente le « plus grand diviseur commun » de l’ensemble de nombres
mentionné entre les parenthèses qui suivent.
Elargissant l’étude vers les tâches indépendantes quelconques, les résultats sont encore
plus complexes, comme le montrent les deux théorèmes suivants qui indiquent une condition
suffisante (Th. II.21) et des informations sur les connaissances nécessaires pour l’ensemble
des tâches (Th. II.22) afin de pouvoir simplifier le problème d’ordonnancement et de
permettre de faire a priori des appréciations sur la faisabilité.
Il est à noter que ces résultats, conformément à la manière dont la théorie
d’ordonnançabilité a été développée, ont à la base l’idée que la machine à utiliser pour
l’ordonnancement est soit monoprocesseur à vitesse constante, soit multiprocesseur avec des
processeurs identiques, en nombre défini auparavant, et ayant tous la même vitesse, constante,
durant l’exécution des tâches.
Les notations suivantes sont utiles pour le Théorème II.21 : R1 (k )= {Ti M D i ≤ k },
R 2 (k )= {Ti MLi ≤ k et D i > k }, R 3 (k )= {T i M L i > k }, et F (k )= k *m − ∑ C i − ∑ (k − Li ) pour
i∈ R1
i∈ R 2
k∈N* , une fonction mesure du « surplus » de puissance de calcul du système pour les
prochaines k unités de temps.
Théorème II.21 : [DER 89] (Condition nécessaire d’ordonnançabilité sur m processeurs
identiques, d’un ensemble de tâches indépendantes) Une condition nécessaire pour la
faisabilité d’un ensemble de tâches indépendantes ayant le même moment d’activation
est donnée, avec les notations ci-dessus, par : ∀ k > 0 , F (k , 0 ) ≥ 0 .
Théorème II.22 : [DER 89] Si un ensemble de tâches indépendantes ayant le même moment
d’activation est faisable pour une machine à m processeurs, alors le même ensemble de
tâches est ordonnançable en ligne par la même machine, même si les moments d’activation
sont différents, et non connus a priori. La connaissance des échéances et des temps de calcul
pour chaque tâche est suffisante pour la faisabilité de l’ordonnancement. “Least Laxity
First” est un algorithme d’ordonnancement en ligne qui assure la faisabilité de
l’ordonnancement.
31
Chapitre II
Etat de l’art
Ce théorème fournit deux résultats importants. D’une part, il permet de résoudre le
problème de la faisabilité d’un ensemble de tâches indépendantes pour lesquelles les moments
d’activation sont différents et non connus a priori par une machine à m processeurs, en le
réduisant au problème de la faisabilité du même ensemble de tâches, mais ayant le même
moment d’activation cette fois-ci, sur la même machine.
Note : Pour cela, sans perdre de la généralité du problème, dans le cadre de cette thèse, dans tous
les cas où la faisabilité d’un ensemble de tâches indépendantes est cherchée, celles-ci sont
considérées comme ayant le même moment d’activation.
D’autre part, le Théorème II.22 indique les connaissances suffisantes qui permettent
de répondre au problème de la faisabilité d’un ensemble de tâches indépendantes sur une
machine avec un nombre de processeurs fixe. (LLF est indiqué comme l’algorithme
d’ordonnancement qui assure cette faisabilité.)
Les résultats donnés par ces deux théorèmes seront complétés au Chapitre III, par une
condition nécessaire et suffisante sur l’ordonnancement d’un ensemble de tâches
indépendantes, suite à la nouvelle approche proposée.
Les théorèmes suivants montrent la difficulté de trouver un ordonnancement nonpréemptif d’un ensemble de tâches indépendantes ayant la même échéance. Pour les tâches
indépendantes quelconques on peut imaginer que la situation est au moins de même
complexité.
Théorème II.23 : [GAR 75] Le problème d’ordonnancement non-préemptif sur 2
processeurs, sans aucune ressource, d’un ensemble de tâches indépendantes avec des temps
d’exécution arbitraires ayant la même échéance, est NP-complet.
Théorème II.24 : [GAR 75] Le problème d’ordonnancement non-préemptif sur 3 ou
plusieurs processeurs et une ressource partagée, d’un ensemble de tâches indépendantes avec
des temps d’exécution unitaires et avec la même échéance, est NP-complet.
Le Théorème II.25 montre un exemple où, pour une certaine métrique, la préemption
n’apporte aucun avantage. Malgré cela, trouver un algorithme sans ou avec préemption reste
un problème NP-hard (Th. II.26), ce qui signifie que pour résoudre le problème il y a besoin
d’heuristiques.
Théorème II.25 : [MNA 59] Pour tout problème d’ordonnancement préemptif sur m
processeurs, avec minimisation de la somme pondérée des durées effectives d’exécution des
tâches, il y a un ordonnancement sans préemption pour lequel la somme des durées
d’exécution est aussi petite que pour tout ordonnancement avec un nombre fini de
préemptions.
Théorème II.26 : [LAW 83] Le problème d’ordonnancement préemptif sur m processeurs
d’un ensemble de tâches, afin de minimiser le nombre de tâches en retard, est NP-hard.
32
Chapitre II
Etat de l’art
Les résultats sur les ordonnancements dynamiques sont peu nombreux. Il a été essayé
de transférer des résultats de l’ordonnancement monoprocesseur vers multiprocesseur
concernant l’optimalité des algorithmes et, déjà, comme le montre le Théorème II.19, il est
nécessaire d’avoir une connaissance complète des caractéristiques des tâches. Ce résultat,
ainsi que le Théorème II.22 sont complétés par :
Théorème II.27 : [MOK 83] EDF n’est pas optimal dans le cas multiprocesseur.
Pour illustrer cette affirmation, la Figure II.6 montre un exemple dans lequel
l’ordonnancement d’un même ensemble de tâches par 2 processeurs échoue avec EDF, mais il
est faisable avec LLF. L’ensemble de tâches est donné par les trois tâches périodiques à
échéance sur requête : T1(R1=0, C1=1, D1=2), T2(R2=0, C2=1, D2=2) et T3(R3=0, C3=3, D3=3),
et c’est la tâche T3 qui rate son échéance. Notons que la condition nécessaire de faisabilité
(Th. II.20) est respectée, mais non la condition de suffisance (Th. II.21).
Figure II.6. EDF et LLF dans l’ordonnancement multiprocesseur.
Pour toutes ces raisons démontrées théoriquement, ainsi qu’à cause de la difficulté de
réaliser des analyses précises sur les différents modèles dans le pire cas, les études ont été
menées sur des heuristiques probabilistes et des analyses stochastiques des conditions ([RAM
90], [ZHA 87]). Mais ces analyses sont coûteuses pour être réalisées en ligne, et demandent
souvent l’utilisation de matériel supplémentaire, notamment un chip d’ordonnancement. Ces
analyses nous concernant moins pour l’étude actuelle, nous n’entrons pas dans d’autres
détails.
II.3.4.2. Restrictions imposées aux tâches par l’implantation et conséquences
Comme dans le cas monoprocesseur, on rencontre des problèmes similaires à
l’implantation des applications, même pour les tâches indépendantes, comme par exemple le
partage des ressources du système ou la surcharge.
Conformément à [STA 95], beaucoup de chercheurs pensent que les techniques pour
résoudre le problème de partage de ressource dans un système monoprocesseur ne sont pas
applicables aux systèmes multiprocesseurs. Pour de tels systèmes, les ressources partagées
sont typiquement adressées par des algorithmes de planification en ligne [RAM 90], [SHE
93], [ZHA 87].
En ce qui concerne la surcharge du système, pour des tâches sporadiques, préemption
permise, et pour l’utilisation d’une machine à deux processeurs, la valeur attribuée à une tâche
33
Chapitre II
Etat de l’art
étant égale à son temps d’exécution si l’échéance est assurée, ou nulle en cas contraire, on a :
Théorème II.28 : [BAR 91] Aucun algorithme d’ordonnancement en ligne ne peut garantir
une valeur cumulative supérieure à 0,5 de la valeur obtenue pour les deux processeurs.
Par rapport au cas monoprocesseur, le problème d’ordonnancement multiprocesseur se
complique encore suite à des anomalies qui peuvent apparaître, connues sous le nom de
« anomalies de Richard ». Le résultat donné par le théorème suivant s’applique aux ensembles
de tâches avec contraintes de précédence, mais il est évident qu’il est valable aussi dans les
cas de tâches indépendantes en situation de partage de ressource, dont nous en indiquons deux
exemples.
Théorème II.29 : [GRA 76] Soit un ensemble de tâches avec conditions de précédence, avec
durées d’exécution fixes, ordonnancé optimal selon un critère de priorité quelconque sur une
machine à nombre fixe de processeurs. Changer le critère de priorité, augmenter le nombre
de processeurs, diminuer les temps d’exécution ou affaiblir les conditions des précédences,
peut engendrer l’augmentation de la durée d’ordonnancement.
Un premier exemple, donné par la Figure II.8, porte sur la diminution du temps
d’exécution des tâches. C’est peut-être la situation la plus fréquente, car les analyses de
l’ordonnancement sont basées sur des estimations pire cas des temps d’exécution des tâches.
A droite, on peut constater une diminution du temps d’exécution de la tâche T1. Cela entraîne
le lancement plus rapide de la tâche T2 qui est en exclusion mutuelle avec la tâche T4. Comme
on le voit, celle-ci commence son exécution plus tard que prévu, et la séquence
d’ordonnancement devient plus longue.
Figure II.8. Anomalie de Richard causée par la diminution du temps d’exécution d’une tâche.
Figure II.9. Anomalie de Richard causée par l’augmentation du nombre de processeurs.
34
Chapitre II
Etat de l’art
Le deuxième exemple, présenté dans la Figure II.9, porte sur l’augmentation du
nombre de processeurs. L’anomalie est due également à l’exclusion mutuelle. Les tâches T3 et
T4 ont chacune deux zones d’exclusion mutuelle réciproque. Le passage de 2 à 3 processeurs,
tout en gardant l’ordre d’exécution des tâches, détermine en conséquence l’augmentation de la
durée d’ordonnancement.
II.3.4.3. Problème des « sacs à dos » (bin packing) - une autre approche pour
l’ordonnancement multiprocesseur
Comme on a pu le constater, le problème d’exécution d’un ensemble de tâches à
contraintes temporelles est généralement traité afin de vérifier la faisabilité de
l’ordonnancement sur une machine à nombre fixé de processeurs. Une autre approche,
beaucoup moins connue et étudiée, est de trouver combien de processeurs sont nécessaires
pour que l’exécution de l’ensemble de tâches soit faisable.
Cette approche qui conduit, dans une première étape, au problème d’algorithmique
connu sous le nom du problème des « sacs à dos » (angl. « bin packing »). En reprenant l’idée
de ce problème d’algorithmique, selon un certain ordre (donné par les caractéristiques des
tâches), les tâches sont prises l’une après l’autre et un processeur (le sac à dos) leur est alloué
si celui-ci a la capacité d’assurer les contraintes de la tâche. Cette allocation des tâches aux
processeurs peut se faire selon différents algorithmes de placement : Next Fit – NF (si le
processeur courrant ne satisfait pas les besoins de la tâche à placer, le prochain processeur est
pris), First Fit – FF (si le processeur courrant ne satisfait pas les besoins de la tâche à placer,
la liste des processeurs est parcourue, en commençant avec le premier processeur et ensuite
les autres, jusqu’à ce qu’un processeur ou un nouveau processeur assure l’échéance de la
tâche), Best Fit – BF (pour la tâche à ordonnancer, la liste de processeurs est parcourue
entièrement afin de déterminer selon un certain critère le meilleur processeur qui garantit
l’échéance de la tâche), ou bien encore First Fit Decreasing – FFD ou Best Fit Decreasing –
BFD (versions des FF et BF où les tâches sont placées dans une liste ordonnant non-croissant
leur temps d’exécution, avant d’appliquer l’algorithme de placement). Bien sur, ces
algorithmes de placement peuvent encore être combinés avec les algorithmes
d’ordonnancement déjà présentés [OHS 95].
Certains résultats concernant le nombre de processeurs nécessaires pour l’exécution
d’un ensemble de tâches indépendantes, avec la même échéance, ont conduit [GRA 76], pour
un nombre élevé de tâches, à des estimations comme : (17 10 )L pour FF et BF, où L
représente le nombre minimal de processeurs, (11 9 )L pour FFD, et il est connu que la borne
pour BFD est inférieure ou égale à celle pour FFD, ou, encore [OHS 95], au moins 1,66
supérieur pour RM-FD par rapport à celle fournie par un algorithme clairvoyant et optimal.
II.3.5. Conclusions
Dans la section II.3 nous avons fait un état de l’art sur la théorie d’ordonnancement en
ce qui concerne les notions nécessaires aux chapitres suivants de la thèse. Les concepts de
base ont été d’abord présentés (§II.3.1) et ensuite les principes des principaux algorithmes
d’ordonnancement (§II.3.2). Les sections §II.3.3 et §II.3.4 ont traité les différents aspects de
l’ordonnancement mono et, respectivement, multiprocesseur. Vu la multitude de résultats, la
présentation a été particulièrement orientée vers les principaux résultats concernant les tâches
indépendantes et les tâches périodiques indépendantes, car elles seront prises en considération
35
Chapitre II
Etat de l’art
dans les chapitres suivants. Les problèmes de faisabilité des ensembles de tâches, de
l’optimalité des algorithmes d’ordonnancement selon les caractéristiques des ensembles de
tâches et de complexité des différents problèmes d’ordonnancement, surtout dans le cas
multiprocesseur, ont été abordés. Toutes ces considérations supposent une machine à nombre
défini de processeurs sur laquelle un ensemble de tâches doit être ordonné afin de garantir les
contraintes des tâches. La sous-section §II.3.4.3 présente une approche différente, peu
abordée jusqu’à présent, où le nombre de processeurs nécessaire pour garantir les échéances
des tâches doit être déterminé. C’est une perspective sur la théorie de l’ordonnancement qui
sera exploitée au chapitre suivant, du point de vue de la minimisation de la consommation
d’énergie du/des processeur(s) due à l’exécution des tâches. Des aspects liés à l’implantation
des algorithmes, notamment le partage des ressources et la surcharge des processeurs ont été
évoqués (§II.3.3.2 et §II.3.4.2), pour montrer certaines difficultés issues de l’implantation des
applications temps réel, difficultés qui peuvent être maîtrisées dans une certaine mesure grâce
à quelques connaissances théoriques.
Ce regard sur la théorie d’ordonnancement a pour but de faciliter le développement
des idées du chapitre suivant.
II.4. Systèmes d’exploitation et temps réel
Dans cette section, nous sommes intéressés à mettre en évidence les notions de base
spécifiques aux systèmes d’exploitation temps réel (§II.4.1) et aux modalités d’implantation
des applications temps réel (§II.4.2). Sans entrer dans les détails, nous rappelons les notions et
les principes, afin de pouvoir rendre la présentation du Chapitre IV plus fluide, sans revenir
sur ces notions de base, mais plutôt de les utiliser dans le cas particulier traité. D’autres
notions, également importantes mais pas indispensables à notre travail, seront volontairement
évitées. C’est le cas, par exemple, de la communication entre tâches, car nous sommes
intéressés, dans cette première démarche, par les tâches indépendantes.
Une étude comparée des performances et des services des systèmes d’exploitation
temps réel actuellement disponibles serait très utile pour approfondir les idées présentées dans
cette thèse ; néanmoins, une telle étude dépasserait l’intention et les limites de ce travail.
Ainsi, nous ne tenterons pas d’émettre des jugements sur les performances des systèmes
actuels afin de trouver celui qui pourrait être le meilleur, mais de présenter les caractéristiques
générales que ces systèmes offrent (§II.4.3.1). Pour ce qui concerne les performances, la
meilleure solution est de consulter les sites des vendeurs pour avoir les informations à jour.
D’ailleurs, en fonction de leurs performances sur l’un ou l’autre des aspects temps réel, ils
peuvent s’avérer plus appropriés pour certains types d’applications que pour d’autres. Pour
prendre un exemple que l’on utilisera dans le Chapitre IV, nous avons choisi de particulariser
la présentation aux systèmes Linux temps réel (§II.4.3.2), et d’insister plus particulièrement
sur RTAI.
Il existe de nombreux travaux sur les principes des systèmes d’exploitation en général
et sur ceux temps réel en particulier ; nous en citons ceux que nous avons utilisés pour la
rédaction de cette section : [BON 99], [FEC 01], [LIU 00], [NUT 00], [SIL 00]. Pour ce qui
concerne les principes de Linux, à part les sources et les différents sites Internet que nous
36
Chapitre II
Etat de l’art
citerons au fur et à mesure que cela s’avérera nécessaire, ils ont été utiles pour les notions
présentées : [BAR 97], [BAR 00a], [BAR 00b], [BLA 00], [BOV 01], [CAM 98], [FEC 01],
[HOL 02], [NIL 00], [NUT 01], [RUB 02], [RUS 99].
II.4.1. Notions générales
Par rapport aux systèmes d’exploitation généraux, un système d’exploitation temps
réel doit être modulaire et extensible, basé sur un micronoyau (pour le besoin d’être
embarqué) qui fournit d’une manière simple les services essentiels en respectant certains
critères de sécurité. Tout le comportement d’un tel système d’exploitation doit être sans
surcharge au niveau du processeur ou avec des surcharges minimales et prévisibles. Le travail
présenté dans cette sous-section consiste essentiellement à introduire la terminologie et à
décrire la structure générale d’un micronoyau temps réel et les principaux services qu’il
fournit. Les principaux systèmes d’exploitation temps réel commerciaux seront énumérés par
la suite.
Les propriétés traditionnelles qui font qu’un système d’exploitation soit temps
réel sont [FEC 01] :
• L’existence d’un noyau multitâche :
− avec la notion de priorité fixe ou dynamique implantée ;
− permettre la préemption.
• L’existence des mécanismes de communication entre tâches (IPC – angl. « Inter
Process Communication ») :
− sémaphores, queues de messages, etc. ;
− des protocoles de gestion des ressources (ex. héritage de priorité, voir §II.3.3.2).
• L’existence des pilotes de périphériques nécessaires intégrés.
• L’existence d’un serveur d’interruption (« handler »).
On ajoute à celles-ci la/les politique(s) d’ordonnancement, qui gèrent la ressource la
plus importante, et le(s) processeur(s), qui doivent permettre un comportement prévisible de
l’application.
A certaines exceptions près, un système d’exploitation temps réel consiste en un
micronoyau qui fournit les fonctions de base, comme il est illustré dans la Figure II.10.
Certaines notions qui apparaissent dans la figure trouveront leur place dans la section
suivante, §II.4.2, car l’implantation des applications temps réel et le fonctionnement du noyau
sont fortement liés à celles-ci.
Certaines caractéristiques sont communes à tous les systèmes temps réel
commerciaux : conformité aux standards (Real-Time POSIX API Standard), modularité,
rapidité et efficacité (par l’utilisation d’un micronoyau), utilisation des appels système,
traitement des interruptions en plusieurs étapes, ordonnancement, plusieurs niveaux de
priorité, contrôle de l’inversion de priorité, une certaine résolution de(s) horloge(s), gestion
mémoire, services réseau. Parmi ces systèmes on trouve : LynxOS [LOS 03], pSOSystem
[pSO 03], QNX/Neutrino [QNX 03], VRTX [VRT 03], VxWorks [VxW 03].
Bien que ces systèmes, du point de vue de leurs fonctionnalités, soient identiques ou
37
Chapitre II
Etat de l’art
presque, on retrouve certaines différences concernant les caractéristiques les plus importantes
pour le temps réel, suite à des stratégies différentes qui ont été utilisées, mais également suite
à des astuces différentes d’implantation. Dans la plupart des cas il s’agit du gestionnaire
d’interruptions, du support pour un modèle de protocole de priorité plafond en
multiprocesseur (MPCP – angl. « multiprocessor priority-ceiling protocol »), de l’héritage de
priorité basé sur les messages, des « crochets » pour des extensions au niveau utilisateur, du
support pour le partage de mémoire en multiprocesseur, de la modularité qui offre la
possibilité d’enlever les mécanismes inutiles à une application particulière.
Pour ce qui concerne les performances, les différences sont données par : la durée de
commutation du contexte, la latence d’interruption et de dispatching, la durée nécessaire pour
bloquer et émettre un signal, pour accorder les sémaphores, pour le traitement des fichiers et
les systèmes réseau. Ces performances sont souvent indiquées par le constructeur et
constituent, généralement, la raison de choisir l’un ou l’autre des systèmes parmi ceux qui
offrent des fonctionnalités similaires.
Figure II.10. Structure d’un micronoyau [LIU 00].
Aussi, parmi les systèmes d’exploitation multitâches les plus répandus, des propriétés
temps réel ont été ajoutées. Nous pensons à Windows NT et à Linux. Pour ce qui concerne
Linux, il existe actuellement plusieurs versions embarquées, ainsi que des modules qui le
transforment en un véritable noyau temps réel. Nous reviendrons sur Linux et ses versions
38
Chapitre II
Etat de l’art
temps réel dans la section §II.4.3, car c’est l’un de ces systèmes que nous avons choisi comme
exemple pour notre présentation.
II.4.2 Implantation des applications temps réel et fonctionnement du noyau
Nous sommes intéressés ici par les moyens offerts par le système d’exploitation pour
l’implantation d’une application temps réel ou, autrement dit, pour identifier quelles sont les
composantes d’une application temps réel si on se situe au niveau du système d’exploitation ;
pour cela, le fonctionnement du noyau est aussi traité.
Trois mécanismes essentiels sont utilisés actuellement pour l’implantation d’un
système d’exploitation. Car la transposition de toute application temps réel du point de vue
système d’exploitation a, dans la plupart des cas, des points communs avec les trois
mécanismes suivants : les modes du processeur (dont nous parlerons par la suite), le noyau
(les principales notions ont été présentées dans la section §II.4.1 et ensuite nous présenterons
certains principes de fonctionnement) et les méthodes d’appeler les services du système (les
appels système et le passage de messages).
Pour ce qui concerne les modes du processeur, les processeurs actuels ont un mode bit
de fonctionnement pour définir la possibilité d’exécuter un programme par le processeur.
L’idée est la suivante : si ce bit indique le mode superviseur alors le processeur peut exécuter
toute instruction, y compris celles qui ont accès direct à la partie matérielle du système. Par
contre, en mode utilisateur, seulement un certain nombre d’instructions peuvent être
exécutées. Parmi les instructions qui ne peuvent être exécutées qu’en mode superviseur, on
trouve les instructions d’entrée/sortie, ainsi que toute instruction de protection mémoire ou
des registres de base. Aussi, les systèmes d’exploitation récents ont étendu ce mécanisme
pour définir deux zones mémoire distinctes ; on parle alors d’espace utilisateur et d’espace
système. Ainsi, les instructions qui s’exécutent en mode superviseur ont le droit d’accéder les
deux partitions de mémoire ; par contre, en mode utilisateur seulement l’espace utilisateur
peut être accédé. Le mode bit peut être changé par l’intermède d’une instruction en mode
utilisateur appelée « trap », ou instruction d’appel superviseur. Elle permet le passage du
mode utilisateur en mode superviseur et le branchement du programme dans l’espace
système, afin de permettre l’exécution en mode superviseur seulement du code sûr, le code du
noyau.
La notion utilisée au niveau du système d’exploitation et qui correspond à celle de
« tâche » est la notion de « thread ». Le thread, en tant qu’implantation de tâche, représente
l’unité de base pour l’ordonnanceur. Sa création par le noyau consiste en : (i) l’initialisation
d’une structure de données, le bloc de contrôle du thread (TCB – angl. « Thread Control
Block »), qui définit les caractéristiques du thread (voir Figure II.11) et qui est utilisée par
l’ordonnanceur, (ii) une allocation d’espace mémoire et (iii) le transfert dans la mémoire du
code qui doit être exécuté par le thread. Sa destruction signifie l’effacement de son TCB et la
libération de sa zone mémoire.
Selon le type de la tâche associée, le thread peut être périodique, apériodique ou
sporadique. Dans certains systèmes d’exploitation la période est incluse dans la définition du
thread et les différents paramètres (moment de la première activation, période, échéance
relative, nombre d’instanciations) sont gardés dans le TCB du thread concerné. Mais la
plupart des systèmes d’exploitation commerciaux n’offrent pas cette possibilité. Dans ce cas,
la tâche périodique est implantée au niveau utilisateur comme un thread qui, après chaque
exécution, s’endort jusqu’au début de la nouvelle période. De même manière, on peut
39
Chapitre II
Etat de l’art
implanter un thread sporadique ou un thread apériodique, leurs dates de réveil pouvant être
gérées à l’aide des interruptions externes.
Figure II.11. Bloc de contrôle du thread [LIU 00].
En correspondance avec les différents états des tâches, on retrouve les mêmes états
pour les threads : prêt, exécution, suspendu, terminé.
Selon l’espace mémoire où s’exécute le thread, deux types de thread peuvent exister
dans un système qui offre des protections mémoires : les threads utilisateur et les threads
noyau. Notons que plusieurs systèmes d’exploitation embarqués ne fournissent pas de
protection mémoire, les threads utilisateur et noyau s’exécutant dans le même espace [LIU
00].
Dans certaines situations, il est utile que le noyau prenne le contrôle du thread en cours
d’exécution pour exécuter lui-même certaines fonctionnalités. Comme c’est indiqué dans la
Figure II.9, les principales situations sont : la réponse à un appel système, l’ordonnancement
et les services de temps (certains systèmes permettent aux threads d’avoir leur propre moyen
de compter le temps, associé à une des horloges existantes, et tout est géré au niveau noyau),
la gestion des interruptions externes.
Les applications ont accès aux données et au code du noyau par l’intermède de
certaines fonctions, nommées « Application Program Interface » (API), qui vont exécuter le
travail demandé au nom du thread qui a fait l’appel, mais au niveau noyau. L’appel à une des
fonctions API est nommé appel système. Un appel système est soit synchrone (le noyau
prend le contrôle pour exécuter la fonction API et, une fois l’appel système terminé, le noyau
exécute le retour d’une exception et le système revient en mode utilisateur), soit asynchrone
(le thread qui fait l’appel système continue son exécution dès qu’il fait l’appel, et le noyau
fournit un autre thread pour répondre à l’appel).
L’ordonnanceur, la partie principale du noyau (voir §II.3.1 pour sa définition),
s’exécute chaque fois que l’état d’un thread change. Pour cela l’horloge système émet
périodiquement des interruptions. A chacun de ces tics d’horloge, le noyau exécute
principalement les routines suivantes : traitement des événements timer, mise à jour des
threads avec la même priorité, actualisation de la queue de tâches prêtes et renvoi du contrôle
au thread prêt, le premier parmi ceux ayant la plus grande priorité. Certains systèmes
permettent aussi l’exécution de l’ordonnanceur à chaque apparition d’un nouvel événement.
La gestion des événements matériels, i.e. des interruptions externes, est
particulièrement importante car les routines comme celles qui traitent les accès au disque dur
ou aux périphériques réseau peuvent demander entre des dizaines de microsecondes et des
40
Chapitre II
Etat de l’art
centaines de microsecondes. Ce temps de réponse à un événement externe est nommé la
latence de l’interruption et représente un des critères qui indiquent la performance d’un
système d’exploitation temps réel ; une caractérisation des éléments pris en compte dans le
calcul de la latence est indiquée dans [LIU 00, Ch. 12]. A cause de la durée variable et
importante de la latence de l’interruption, dans la plupart des systèmes d’exploitation, la
gestion des interruptions est divisée en deux parties : le service d’interruption immédiat et le
service d’interruption ordonnancé. Leur traitement est toujours fait au niveau noyau. De plus,
aux interruptions différentes, selon le matériel, des priorités différentes peuvent être assignés,
et celles-ci sont supérieures aux priorités logicielles des threads.
Nous limitons notre présentation à ces quelques notions de base qui serviront à
introduire, dans le Chapitre IV, les détails nécessaires, spécifiques au cas particulier de noyau
temps réel qui sera pris en considération.
II.4.3. Les noyaux temps réel Linux
Pour choisir un noyau temps réel afin d’illustrer notre approche, nous avons porté cette
étude sur l’un de ceux que l’on trouve dans la famille de noyaux temps réel Linux. Nous
précisons que ce choix n’est pas basé sur des critères de performance que ce noyau pourrait
avoir par rapport aux autres, mais plutôt sur la coté didactique de ce système. Les critères qui
nous ont intéressés sont les suivants : la disponibilité des sources, l’existence d’une version
embarquée, l’existence des implantations pour des plates-formes différentes, y compris
multiprocesseur, les différentes fonctionnalités spécifiques aux noyaux temps réel prises en
compte, une documentation suffisamment riche et, éventuellement, une liste de discussions
active. Nous précisons aussi que nous ne traiterons pas du sujet de la dimension du noyau et
des outils existant déjà sur le marché, permettant une configuration spécifique au système à
développer, car celle-ci dépasserait le cadre de ce travail.
Actuellement il existe plusieurs versions de noyaux de type Linux dits « temps réel »,
développés soit comme modules du noyau Linux, soit par la réécriture du noyau même, afin
de lui offrir les caractéristiques d’un noyau temps réel. Cela est accepté facilement par le
noyau Linux même, car il est conforme à la norme POSIX 1003.13, standard définissant le
profil d’un système d’exploitation multiutilisateurs temps réel permettant le blocage des
tâches temps réel en mémoire et qui possède un ordonnanceur adapté pour assurer au mieux
un ordonnancement prédictif pour les tâches temps réel.
Tout d’abord nous décrirons le noyau Linux avec son comportement et les problèmes
qu’il pose aux applications temps réel (§II.4.3.1). Ensuite, après une présentation de la
philosophie générale des principes de fonctionnement des différents modules temps réel
existants, nous passerons en revue ces noyaux (§II.4.3.2) : RTLinux, RTAI, KURT, RED
Linux, TimeSys Linux/RT™, et le noyau «hard real-time » de MontaVista.
II.4.3.1. Le noyau Linux
Le noyau Linux fournit quelques caractéristiques spécifiques aux noyaux temps
réel [NUT 01] :
• un blocage mémoire (mlock) compatible POSIX : il permet le blocage des tâches
temps réel dans la mémoire en évitant leur transfert sur le disque dur, d’où un gain
de temps d’exécution des tâches et du coût du noyau ;
41
Chapitre II
Etat de l’art
• des appels système pour l’ordonnancement (sched_setsched) : ils permettent de
choisir différentes politiques d’ordonnancement pour les tâches, parmi celles
implantées dans le noyau ;
• des signaux POSIX RT.
Les entités ordonnançables en Linux sont nommées processus ; le processus est le
terme équivalent à la notion de tâche dans la théorie d’ordonnancement, et à la notion de
thread employé dans §II.4.1 et §II.4.2. Les processus Linux sont divisés en deux classes :
•
la classe des processus temps réel, avec les politiques d’ordonnancement associées
SCHED_FIFO et SCHED_RR (Round Robin), et
•
la classe par partage de temps (le type de processus par défaut), SCHED_OTHER,
avec un algorithme de type vieillissement des tâches par rapport à l’utilisation du
processeur.
La priorité des processus temps réel est définie au niveau de l’application et elle est
plus grande que la priorité des processus par partage de temps.
Le noyau Linux prévoit ainsi des entités non ordonnançables ; leur traitement
demande un certain temps d’exécution et par conséquent elles devront être prises en compte
pour l’analyse du comportement de toute application temps réel. Il s’agit :
•
du serveur d’interruption (les interruptions se voient avec des priorités attribuées,
et elles peuvent être imbriquées),
•
des « bottom halves » (les instructions à exécuter après le traitement d’une
interruption, mais qui ne doivent pas faire partie du code associé à l’interruption
même) et
•
des queues de tâches (elles sont traitées à l’ordonnancement, en retour d’un appel
système ou d’une interruption).
Pour ce qui concerne le comportement du noyau Linux au démarrage de l’ordinateur
le matériel exécute un « processus » que l’on pourrait nommer le processus matériel [NUT
01]. Ce n’est pas un processus Linux car il commence son exécution avant que le noyau
Linux soit chargé. Il se termine par la séquence de démarrage (« boot ») et, une fois que le
principal point d’entrée existe, le noyau commence ses initialisations (la table « trap », le
serveur d’interruption, l’ordonnanceur, l’horloge, les modules, etc.). La fin de cette séquence
initialise le processus manager.
Le processus matériel crée le processus initial qui occupera la première position dans
la table des descripteurs de processus du noyau. C’est le processus Linux 0. Le processus
initial lance le premier processus utile de Linux (le processus init) et commence l’exécution
d’une boucle « idle ». A partir de ce moment, il va servir pour ocuper le CPU lorsqu’aucun
autre processus ne l’utilise. On l’appelle le processus de tâche de fond (« idle »).
Le premier processus réel continue l’initialisation du système : le démarrage des
daemons, le gestionnaire de fichiers, la console système, un autre programme d’initialisation
(init), un processus (getty) sur chaque port de communication pour la connexion des
utilisateurs. Quand un utilisateur commence à utiliser le port, le processus getty lance le
processus login qui exécute le shell spécifique de l’utilisateur.
La Figure II.12 donne une description graphique intuitive [NUT 01] du comportement
du processus matériel. L’abréviation ISR utilisée (angl. « Interrupt Service Request ») désigne
la demande du service de traitements des interruptions.
42
Chapitre II
Etat de l’art
Lancement du processus matériel
Tâche de fond Noyau
ISRs
Processus I Processus J
BIOS
Programme
Processus
matériel
Commutation
vers un autre
programme
Figure II.12. Le processus matériel [NUT 01].
Le manager de processus est responsable de la création de l’abstraction de processus
et fournit les facilités qui permettent aux processus de créer, de détruire, de synchroniser et de
protéger d’autres processus.
Le gestionnaire de ressources crée les abstractions correspondant aux entités pouvant
être demandées par un processus et fournit l’interface par laquelle le processus peut
demander, acquérir et disposer des ressources.
L’ordonnanceur, comme toute autre partie du noyau, s’exécute seulement quand un
processus passe en mode superviseur, suite à un appel système ou à une interruption. La
Figure II.13 illustre une partie du flux de contrôle des tâches dans le noyau.
Tâche en exécution
IRQ
Exécution ISR
Rapide
Lent
Commutation vers le code noyau
Placement de l’appel système
Exécution Bottom Half si nécessaire
Exécution de la fonction système
Retour de l’appel système
L’exécution de la tâche continue
Ordonnancement de la nouvelle tâche
Figure II.13. Partie du flux de contrôle des tâches [NUT 01].
Une nouvelle tâche se crée quand son processus père invoque l’appel système
fork() ou clone(). Le descripteur du processus correspondant est alloué (la structure
task_struct), ainsi que la table des processus et les listes d’attente.
L’ordonnancement des tâches au niveau du processeur est réalisé par l’appel de la
fonction noyau schedule(), activée à chaque commutation vers le noyau et à chaque
retour d’un appel système. L’ordonnanceur s’exécute comme une tâche associée à un
43
Chapitre II
Etat de l’art
processus utilisateur ou à une interruption. Il détermine la tâche prête avec la plus grande
priorité et lui alloue le processeur.
Bien que le noyau Linux prévoie quelques facilités temps réel, il n’est pas approprié
au développement de vraies applications temps réel, surtout celles à échéances strictes. Parmi
les problèmes qui empêchent le noyau Linux d’être temps réel nous citons :
•
la granularité du timer : la plupart des tâches temps réel sont activées par les
interruptions du timer, et le timer de Linux standard expire à des intervalles de 10
ms ;
•
la décision d’ordonnancement n’est pas prévisible par rapport à la durée
d’exécution : les tâches sont dans une liste non-ordonnée est la décision est prise
après le parcours de toute la liste ;
•
l’inversion de priorité :
o des situations de changement de priorité inattendu peuvent apparaître ;
o il n’y a aucun mécanisme pour limiter l’inversion de priorité dans le cas du
partage des ressources.
Pour ces raisons, influencées aussi par la popularité croissante de Linux, sa modularité
et la disponibilité des sources, et parfois pour des besoins didactiques, des développeurs issus
principalement du milieu universitaire et suivis par des industriels ont passé au
développement des adaptations pour mettre en œuvre un noyau Linux temps réel. Cette
démarche est présentée dans la section suivante.
II.4.3.2. Implantation de noyau temps réel Linux
Il y a actuellement plusieurs noyaux temps réel Linux : RTLinux, RTAI, KURT, RED
Linux, TimeSys Linux/RT™, le noyau «hard real-time » de MontaVista. Deux approches
différentes ont été utilisées pour mettre en œuvre un noyau temps réel Linux :
•
l’approche qui limite l’interaction des tâches temps réel avec les tâches non-temps
réel :
o noyau « dual » : RTLinux, RTAI ;
o noyau « compliant » : LynxOS, Blue Cat Linux ;
•
l’approche qui intègre les tâches temps réel et les tâches non temps réel :
o noyau « core » : TimeSys Linux/RT, Hard Hat Linux ;
o noyau « ressource » : TimeSys Linux/RT.
La méthode d’un noyau hybride, qui se prête mieux aux applications temps réel
pour des raisons de prédiction, est présentée dans la Figure II.14. C’est cette approche qui
nous intéresse plus, nous présentons donc sa philosophie.
L’idée de base est de faire fonctionner Linux sous le contrôle d’un noyau temps réel
[BAR 97]. Lorsqu’il y a un travail en temps réel à faire, le système d’exploitation en temps
réel exécute une de ses tâches. Lorsqu’il n’y a pas de travail en temps réel à faire, le noyau
temps réel ordonnance l’exécution de Linux. En fait, Linux dévient une tâche possédant la
44
Chapitre II
Etat de l’art
plus petite priorité dans le noyau temps réel. [CAM 98]
La principale philosophie derrière ce type de systèmes, dont RTLinux et RTAI, est la
suivante : les applications temps réel doivent être séparées en deux parties. Une partie doit
répondre aux contraintes temps réel ; elle s’exécute comme une tâche sous la gestion du
noyau temps réel et copiera les données à partir du périphérique dans une interface
entrée/sortie appelée fifo temps réel. L’autre partie s’exécute comme un processus Linux
ordinaire. Les tâches temps réel sont exécutées à un niveau privilégié du noyau dans le but de
permettre un accès direct au matériel, et elles ont des allocations fixes de mémoire pour le
code et les données afin d’éviter les délais imprévisibles lorsqu’une tâche demande une
nouvelle page mémoire. Aussi, les tâches en temps réel ne peuvent pas utiliser les appels
système Linux ou des routines d’appel direct, ou accéder à des structures de données
ordinaires dans Linux.
Pour cela, les fonctionnalités qui sont placées dans le domaine temps réel ont des
ressources disponibles très limitées, par rapport aux autres qui ont la possibilité d’utiliser
toutes les ressources disponibles avec Linux. C’est le cas, par exemple, des pilotes des ports
série et parallèle qui résident dans Linux et ne peuvent être utilisés que dans le domaine qui
n’est pas temps réel. Parce que leurs utilisations peuvent s’avérer indispensables pour la partie
temps réel, les deux pilotes doivent être modifiés.
Processus
Linux
Processus
Linux
Bibliothèques système
Niveau utilisateur
Niveau noyau
Tâche TR
Tâche TR
Tâche TR
Noyau Linux
Noyau Temps Réel (RTLinux, RTAI, ...)
Partie matérielle
Figure II.14. Noyau hybride Temps Réel Linux.
Pour faire communiquer les deux domaines où des tâches de l’application temps réel
peuvent s’exécuter, on utilise des files spéciales FIFO temps réel. Elles sont construites pour
permettre le passage d’informations entre les processus temps réel et les processus Linux, et
conçues pour que les tâches temps réel ne soient jamais bloquées lorsqu’elles écrivent ou
lisent des données. La Figure II.15 illustre les FIFO temps réel.
Pour ce qui concerne l’écriture d’une application temps réel en utilisant un tel noyau,
la composante temps réel sera écrite comme un module du noyau. Linux permet ensuite de
compiler et de charger le module sans redémarrer le système.
Par la suite nous indiquons quelques caractéristiques qui font la spécificité des noyaux
temps réel Linux les plus répandus à l’heure actuelle.
45
Chapitre II
Etat de l’art
Figure II.15. FIFO temps réel [CAM 98].
RTLinux [RTL 03] met un processus temps réel en dehors de Linux et permet aux
utilisateurs d’y installer des threads temps réel ainsi que le serveur des signaux. Le pire cas
pour les latences des interruptions est de 15 ms sur un x86 générique, et meilleur sur les
processeurs PowerPC et Alpha [BAR 00]. RTLinux est conçu comme un module Linux qui,
une fois chargé, traite tout processus Linux habituel quand aucune tâche RTLinux ne
s’exécute.
RTAI (Real Time Application Interface), créé par DIAPM (Dipartimento d’Ingegneria
Aerospaziale – Politecnico di Milano) [RTA 03], offre quelques mécanismes purement temps
réel conservant en même temps toutes les fonctions et les services de l’implantation standard
de Linux.
L’architecture de RTAI (Figure II.16) est similaire à celle de RTLinux dans le sens où
le système Linux s’exécute comme étant une tâche avec la priorité la plus basse du système
d’exploitation temps réel. La communication entre les tâches temps réel et le gestionnaire
d’interruptions et les tâches usuelles du Linux se fait par l’intermédiaire d’une interface
périphérique ou par la mémoire partagée.
La différence entre RTLinux et RTAI est donnée par les modalités qui ajoutent des
caractéristiques temps réel au système Linux. RTAI fournit une couche d’abstraction
hardware (HAL – Hardware Abstraction Layer) qui correspond à une structure de pointeurs
(RTHAL – Real Time Hardware Abstraction Layer) pour les vecteurs d’interruptions et les
fonctions d’interruption on/off. HAL supporte cinq modules : rtai (l’environnement du
travail par défaut), rtai_sched (l’ordonnancement périodique ou « one-shot »),
rtai_mups (l’ordonnancement périodique simultané ou « one-shot » ou, en même temps,
deux autres ordonnancements périodiques, chacun d’entre eux utilisant une horloge séparée),
rtai_shm (partage de mémoire intra et inter Linux), et rtai_fifos (l’adaptation FIFO
pour le RTLinux). Un processus temps réel similaire à RTLinux est créé. Il est compilé
comme un module du noyau et chargé dans le noyau après les modules RTAI nécessaires.
Quelques caractéristiques de RTAI sont les suivantes [MAN 00] :
• la gigue dans l’itération périodique maximale : 0-13µs UP, 0-30µs SMP ;
• l’itération périodique maximale : 125kHz ;
46
Chapitre II
Etat de l’art
• l’interruption « one-shot » : 30kHz sur Pentium, 10kHz sur 486 ;
• la durée du changement de contexte : ~4µs.
Figure II.16. Architecture RTAI [LIS 00].
AtomicRTAI est une implantation compacte qui tient sur une disquette pour sa
dernière version, avec détection automatique d’horloge, combinée avec les outils essentiels de
mesure de performance et avec quelques programmes « hard real-time » de démonstration.
KURT (Kansas University Real-Time) [KRT 01], en tant que système d’exploitation
temps réel logiciel, étend le noyau standard avec trois modules :
• normal : un système Linux standard, avec une résolution de l’ordre de grandeur de
la microseconde, fourni par le paquetage UTIME ;
• dédié temps réel : les tâches désignées temps réel s’exécutent selon un
ordonnancement explicite ;
• temps réel mixte : combine les deux modes et permettent l’exécution simultanément
des processus Linux et des tâches temps réel dans le sens de l’ordonnancement
temps réel permis comme extension.
REDLinux (Real Time and Embedded Linux) apporte différentes nouvelles
caractéristiques à Linux [RED 03] :
47
Chapitre II
Etat de l’art
• une horloge avec une résolution plus élevée ;
• une structure d’ordonnanceur intégrant les paradigmes pour maîtriser les priorités,
l’horloge et le partage du temps processeur ;
• un émulateur logiciel pour les interruptions.
Le mécanisme du timer et l’émulation des interruptions ont été intégrés directement
dans le code source du RTLinux.
Le TimeSys Linux/RT™ [TiS 03] actualise le cœur du noyau Linux avec Ressource
Kernel (RK), ajoutant des capacités temps réel à Linux. Il fournit également un support
embarquable pour les extensions POSIX temps réel et fournit 256 niveaux de priorité.
Le noyau « hard real-time » de Montavista [MVS 03] supporte en même temps
RTLinux et intègre une nouvelle technologie de noyau préemptif. Par sa conception, il est
plutôt dédié aux applications temps réel qui ne sont pas à échéances strictes, et est utilisé
généralement dans le domaine du multimédia.
II.5. Conclusions
Sans avoir la prétention d’épuiser, au bout de quelques dizaines de pages, des
domaines informatique assez éloignés les uns des autres, que la conception des systèmes
embarqués, la théorie algorithmique et mathématique de l’ordonnancement et la théorie des
systèmes d’exploitation temps réel, nous avons présenté dans cet état de l’art seulement les
concepts et les résultats qui seront utiles pour développer les idées des chapitres suivants. La
ligne conductrice, parfois à peine visible, a été la présentation de tous ceux qui pourraient être
utilisés dans l’étude sur la consommation énergétique d’un système temps réel embarqué au
niveau processeur ; cette ligne conductrice sera plus visible par la suite, à fur et à mesure du
déroulement de notre travail.
Pour mieux encadrer les conclusions sortant de notre étude dans le processus de
développement d’un système embarqué, la section §II.2 de ce chapitre a introduit les
principales notions et étapes de ce processus.
La partie principale de ce chapitre (§II.3) expose les principaux mécanismes
d’ordonnancement et les résultats les plus importants concernant le modèle de tâches
périodiques indépendantes, les deux cas mono et multiprocesseur étant traités. La
présentation a été limitée à ce modèle car le chapitre suivant, le cœur de notre travail, qui
traite de l’ordonnancement et de la consommation énergétique au niveau du/des processeur(s),
fait référence au même modèle et les résultats obtenus sont fortement liés aux résultats sur
l’ordonnancement.
Il est bien connu que la transposition d’une application temps réel en pratique induit
des coûts supplémentaires au niveau de l’exécution des tâches, voire même des tâches
supplémentaires, non prévues dans la conception théorique préalable, dues au comportement
du système d’exploitation. Pour cela, toute étude préalable devrait prendre en compte les
différentes caractéristiques du système d’exploitation à utiliser, afin de mieux prévoir le
48
Chapitre II
Etat de l’art
comportement réel de l’application finale. Comme on le verra, une meilleure évaluation de la
consommation énergétique demande aussi de prendre en compte tous les coûts induits par le
système. Nous avons donc présenté les caractéristiques et les fonctionnalités spécifiques aux
systèmes d’exploitation temps réel (§II.4.1) et à l’implantation des applications temps réel et
le comportement du noyau (§II.4.2), pour passer après en revue les noyaux temps réel Linux
(§II.4.3). Cela permet de prendre à titre d’exemple, au niveau du Chapitre IV, un système
d’exploitation temps réel (RTAI) afin de mettre en évidence d’une part ce que l’implantation
d’un ensemble de tâches périodiques indépendantes entraîne au niveau du système et, d’autre
part, les éventuelles modifications du noyau pour mieux maîtriser la consommation d’énergie
au niveau du/des processeur(s).
Il est évident que toute extension de l’étude de la consommation d’énergie et du
déterminisme de l’application à d’autres modèles de tâches demandera une présentation plus
détaillée pour ce qui concerne la théorie de l’ordonnancement, afin de permettre le traitement
des autres modèles de tâches. Il est aussi évident que le passage à une validation effective des
notions nécessitera, en plus d’une étude comparée plus approfondie des systèmes
d’exploitation existants, des estimations effectives sur les coûts supplémentaires induits. Bien
sûr, la conception d’une plateforme concrète demandera de compléter la méthodologie de
développement d’un système embarqué. Le but de cette thèse étant de présenter des premiers
résultats d’une nouvelle approche d’ordonnancement avec minimisation de la consommation
d’énergie au niveau du/des processeur(s) et de marquer les implications de ces résultats au
niveau du processus de développement d’un système temps réel embarqué, nous limitons –
avec regrets – l’état de l’art aux notions présentées jusqu’ici.
49
CHAPITRE III
Contribution à la configuration
d’un système temps réel embarqué
pour l’optimisation de la consommation énergétique
Chapitre III
III.1.
Optimisation de la consommation d’énergie
Introduction
L'autonomie est un élément essentiel dans la conception d'un système embarqué. De
multiples mécanismes de préservation de l'énergie sont mis en place dans la plupart de ces
systèmes, notamment dans les dispositifs mobiles basés sur la communication sans fil.
L’optimisation de la consommation d’énergie d’un système embarqué peut se faire à plusieurs
niveaux. Parmi les techniques utilisées au niveau matériel on trouve [XIL 03]: l’élimination
des pointes de courant durant les séquences de mise sous puissance ou de mise en veille du
processeur, la gestion du profil de décharge de la batterie en fonction de sa technologie, la
gestion efficace des accès aux périphériques d’entrée/sortie, la minimisation de l’activité
d’accès au bus, la réduction de la capacité du bus, la réduction des bruits de commutations.
Des investigations ont été menées au niveau plus haut de l’architecture, pour définir
une coopération entre le système d’exploitation et l’application afin que la consommation
d’énergie soit optimisée en fonction des ressources du système [FLI 99], [NOB 97], [NOB
00].
Au niveau du système d’exploitation, d’autres approches proposent différentes
adaptations de ces caractéristiques [LEB 00], [VAH 00]. Une caractérisation énergétique des
systèmes d’exploitation temps réel peut être trouvée dans [THI 00] et [WEI 99], et pour les
systèmes d’exploitation embarqués dans [DIC 00]. Plus profondément dans le système
d’exploitation, les travaux de [AYD 01a,b,c], [HON 98], [ISH 98], [KRI 00], [SHI 99], [ZHU
01] sont basés sur l’idée de la variation de la vitesse du processeur. Ils cherchent à trouver des
ordonnancements efficaces de point de vue énergétique pour différents modèles de tâches.
Passant vers l’application même, [LEE 96] présente des évaluations de la consommation
d’énergie au niveau du code des tâches.
Pour ce qui concerne un système temps réel aux échéances strictes, deux problèmes
nécessitent d’être traités :
•
l’optimisation de la consommation de l’énergie, tout en préservant le déterminisme
de l’exécution de l’application ;
•
le comportement déterministe du système en fin de ressource d’énergie.
Le deuxième aspect étant fortement lié à l’application à exécuter, on se pose le
problème de la sauvegarde et de l’exécution des tâches indispensables. On lance alors une
application de sauvegarde et l’ordonnancement des tâches préalables devient moins
primordial ; il subit une sélectivité sur d’autres critères.
Dans ce chapitre, nous nous intéressons uniquement au premier aspect, et nous
proposons une étude sur l’énergie consommée par le (les) processeur(s) d’un système temps
réel embarqué, du fait de l’exécution des tâches. Le problème concerne les plates-formes
multiprocesseur homogènes, avec des processeurs à vitesse ajustable en ligne. Le but est de
définir, pour une application donnée, la configuration de la plate-forme en termes de nombre
de processeurs, de vitesses d’exécution des tâches à chaque activation et de
l’ordonnancement.
Peu de travaux sur ce sujet ont été réalisés à ce jour et ceux existants sont très récents
et encore incomplets. Nous les présentons au §III.2, l’état de l’art sur ce sujet. La section
§III.3 consiste en une analyse critique de la solution actuelle pour le cas monoprocesseur, ce
qui nous a permis d’apporter quelques compléments. Ensuite, nous étendons cette approche
au cas multiprocesseur (§III.4) où nous avons obtenu quelques premiers résultats sur la
52
Chapitre III
Optimisation de la consommation d’énergie
faisabilité et l’optimalité des ordonnancements des tâches périodiques indépendantes. Des
évaluations sur le gain d’énergie ont été mises en évidence dans la section §III.6 pour les
tâches avec la même fonction de puissance dissipée et, respectivement, dans §III.7 pour les
tâches identiques. Les conclusions et les perspectives sont présentées dans §III.8.
III.2.
Etat de l'art
III.2.1. Considérations sur la consommation énergétique du processeur
La consommation énergétique du processeur est basée sur des évaluations réalisées
pour différentes architectures CMOS. Weste et Eshragian ont décrit les principes du design
des VLSI CMOS [WES 88]. Les premières évaluations sur la consommation d’énergie par
différents circuits CMOS, a partir de la cellule de base et jusqu’au DSP, ainsi que des
propositions technologiques pour minimiser cette consommation ont été étudiées et présentées
dans [CHA 92] et [BRO 95], par des groupes de recherche de MIT (Massachusetts Institute of
Technology) et de l’Université de Californie, réunis autour de Brodersen et Chandrakasan.
Vdd
A0
:
An
PMOS
ic(t)
NMOS
CL
υC (t )
Figure III.1. Modélisation de la consommation dynamique des portes CMOS.
La Figure III.1 constitue le schéma du modèle de base d’une cellule conçue sur la
technologie CMOS. Un circuit digital CMOS présente trois sources majeures de dissipation
de la puissance [WES 88] :
Pmoyenne = Pcommutation + Pcourt -circuit + Pfuite
= α 0→1C LVdd2 f horloge + I ccVdd + I fuiteVdd .
Le premier terme représente le composant de la puissance dissipée dû aux
commutations: C L est la capacité de charge, Vdd - la tension d’alimentation, f horloge - la
fréquence de l’horloge (le nombre de cycles d’horloge par seconde) et α 0→1 - la probabilité
d’apparition d’une consommation de puissance de transition durant un cycle d’horloge (le
facteur d’activité). Le deuxième terme est dû au courant de court-circuit, I cc , apparaissant
quand les deux transistors NMOS et PMOS sont simultanément actifs, conduisant le courant
d’alimentation directement vers la terre. La puissance de fuite est due au courant de fuite,
I fuite , qui peut résulter du substrat d’injection et des effets de sous seuil ; il est déterminé par
53
Chapitre III
Optimisation de la consommation d’énergie
des considérations technologiques.
La composante dominante de la puissance dissipée étant la puissance de commutation
[CHA 92], souvent les deux sont confondues. Ainsi, l’énergie consommée par la transition est
approximée par :
Pmoyenne
E transition =
= C effectiveVdd2 ,
f horloge
où
C effective = α 0→1C L
représente la capacité effective due aux commutations nécessaires pour réaliser le calcul.
Une bonne introduction aux techniques de réduction de la consommation d’un système
embarqué temps réel est constituée par l’article de Parrain et al. [PAR 01], ainsi que par ceux
de Pedram [PED 96] ou bien Havinga et al. [HAV 00]. Ils mentionnent les principaux travaux
dans ce domaine, tant au niveau matériel que logiciel, jusqu’à la date de parution de ces
articles.
Différentes considérations technologiques concernant le design des circuits, liées à la
réduction de la consommation, ont été présentées dans [CHA 92] et [BRO 95] ; sans entrer
dans les détails nous en mentionnons :
•
la logique dynamique contre la logique statique ;
•
le style d’implantation de la logique par CPL (angl. Complementary Passgate
Logic) contre la logique conventionnelle CMOS ;
•
l’échelle des seuils de la tension d’alimentation du circuit ;
•
les stratégies de mise hors tension.
Toutes ces considérations montrent que l’énergie consommée est différente pour
différents circuits CMOS, même si le calcul théorique reste le même.
Au niveau submicronique, on peut agir sur deux paramètres pour adapter la
consommation du processeur : la tension d’alimentation et la fréquence du processeur. Selon
l’équation qui exprime la puissance dissipée par un circuit CMOS, il est évident que la façon
la plus efficace ([CHA 92], [BRO 95]) de la réduire est de diminuer la tension d’alimentation,
pour exploiter la dépendance quadratique entre la puissance et la tension. L’évolution de la
technologie a permis cette diminution et, si au début la tension d’alimentation était à 5V,
aujourd’hui elle est généralement inférieure à 3,3V, et certains systèmes peuvent descendre
jusqu’à 1,1V [BRE 95]. En effet, une tension plus basse nécessite le recours à une technologie
de gravure plus fine : 0,8µm pour une tension de 5,5V et 0,5µm ou 0,35µm pour 3,3V [TIW
98]. Malheureusement, ceci peut se répercuter au niveau de l’effet transistor et de réduire le
rapport signal/bruit, ce qui rend le composant plus sensible aux perturbations externes [CHA
96]. En effet, l’ajustement en ligne de la tension du processeur ne nous semble pas réaliste,
par ce que, d’une part, d’autres éléments du système ne se prêtent pas nécessairement à la
variation de cette tension, et que, d’autre part, le dispositif de variation de tension
nécessiterait une conversion continuelhachéelcontinue avec un rendement faible.
D’autre part, la diminution de la tension d’alimentation entraîne des retards dans le
circuit et réduit aussi la fréquence de l’horloge. Le délai de la porte peut être exprimé ([CHA
92], [BRO 95], [HON 99]) par :
54
Chapitre III
Optimisation de la consommation d’énergie
T =k
(V
Vdd
dd
− Vt
)
2
,
où k représente une constante et Vt la tension seuil.
En tenant compte aussi du fait que la vitesse∗ du processeur est proportionnelle avec la
fréquence de l’horloge et de proportionnalité inverse avec le délai de la porte, Hong obtient
[HON 99] la courbe puissance versus vitesse pour un cas particulier (de machine et des tâches
à accomplir) où la puissance normalisée Pn prend la valeur 1 pour la tension d’alimentation
égale à la tension de référence, Vdd = Vref , ainsi que la vitesse normalisée S n . La formule a
été déduite pour Vref = 3,3V et Vt = 0,8V , et elle est donnée par :
(
)
Pn ( S n ) = 0,164 ⋅ S n3 + 0,893 ⋅ S n2 + 1,512 ⋅ S n ⋅ 0,173 ⋅ S n2 + 0,147 ⋅ S n + 0,277 ⋅ S n2 + 0,059 ⋅ S n .
On doit noter la complexité de cette fonction qui exprime, dans une première
approximation, la puissance dissipée en fonction de la vitesse.
Des résultats expérimentaux de relevé de consommation d’énergie ont été obtenus
d’abord sur un processeur Intel DX2-486 à 40Mhz [MAL 94], puis sur un processeur DSP
Fujitsu CMOS à 40Mhz [LEE 96]. La conclusion que l’on peut en tirer est qu’à des nombres
égaux de cycles processeur, la dissipation de puissance varie en fonction des instructions
utilisées. On se situe donc au niveau assembleur : les instructions de base n’utilisent pas
nécessairement les mêmes ressources internes du processeur, ni les mêmes accès mémoire
extérieurs.
On peut donc déduire que, pour une tâche donnée, écrite en langage évolué, il existe,
selon le code assembleur utilisé, un codage assembleur optimal qui minimise la dissipation
énergétique du processeur. Par ailleurs, pour deux tâches ayant la même durée d’exécution sur
le même type de processeur, la consommation d’énergie ne sera pas nécessairement la même.
Pour toutes les raisons décrites auparavant, on ne peut pas établir une formule générale
permettent d’exprimer la puissance dissipée en fonction de la vitesse du processeur. Pourtant,
vu les résultats expérimentaux obtenus pour des cas particuliers, les travaux théoriques sur la
consommation d’énergie ont eu à la base l’idée généralement acceptée selon laquelle la
puissance dissipée g est une fonction convexe, strictement croissante. Nous citons ici les
travaux de Yao [YAO 95], qui a utilisé une fonction de puissance ayant la forme :
g (S ) = S p , p ≥ 2, p ∈ R ,
et ceux des Aydin et al. [AYD 01a,b,c] avec une fonction polynomiale de degré minimum 2 :
r
g (S ) = ∑ a j S j , r ∈ N, r ≥ 2, a j ∈ R, ∀j = 1, K , r ,
j =1
les fonctions pouvant varier selon la tâche.
En effet, les deux approches représentent des techniques logicielles sur la
minimisation de la consommation énergétique, liées à l’ordonnancement de tâches à
accomplir.
∗
La vitesse du processeur est mesurée en cycles processeur par seconde. Le cycle processeur signifie l’opération
unique et complète (atomique) que le processeur peut exécuter.
55
Chapitre III
Optimisation de la consommation d’énergie
Ces approches théoriques ont à la base la capacité d’un processeur de pouvoir modifier
sa vitesse. Ceci suppose l’existence d’un mécanisme permettant au processeur d’influer sur sa
propre vitesse d’horloge. Certaines études ([WEI 94], [YAO 95], [GOV 95], [HON 98])
prennent comme hypothèse qu’il est possible de faire varier la fréquence de manière continue
entre la valeur maximale et une borne inférieure, et que les temps de transition sont
négligeables.
Pour certains spécialistes, de telles hypothèses ne semblent pas réalistes : il y a des
recherches sur les régulateurs de tension variable qui montrent que le temps de transition ne
peut pas être diminué en dessous de plusieurs millisecondes par Volt [NAM 97], auxquelles il
faut ajouter le temps de propagation du nouveau signal d’horloge dans les autres composants,
ce qui pourrait conduire finalement à un délai de plusieurs dizaines de secondes pour la
transition d’une fréquence de fonctionnement à une autre [WEI 94].
Malgré ces critiques, les études mentionnées constituent une première approche et un
premier modèle qui fournit des résultats importants sur la consommation d’énergie au niveau
du processeur et qui permettra par la suite d’affiner le modèle théorique pour chaque cas
particulier à traiter.
De plus, le progrès de la technologie fait qu’à l’heure actuelle nous disposons de
processeurs permettant un changement de vitesse dans un spectre continu ([GUT 96], [NAM
97]) ainsi que des processeurs qui permettent le changement de leur vitesse en-ligne, comme
les processeurs Crusoe de Transmeta ([TRA 03], [KLA 00], [HAL 00]) ou Intel, à partir du
Pentium III Mobile ([INT 99]).
Notre étude s’inscrit dans la ligne des travaux de Yao et Aydin, en élargissant le
contexte du problème vers les architectures multiprocesseur par une redéfinition du problème
de la consommation énergétique. La solution proposée est spécifique aux applications temps
réel à échéances strictes pour les architectures multiprocesseur SoC (engl. System on Chip).
Le but est d’établir, pour un ensemble de tâches donné, un ordonnancement faisable, optimal
du point de vue de la consommation d’énergie due à l’exécution des tâches.
La technologie CMOS est à la base des processeurs actuels et, par
conséquence, toute étude de la consommation d’énergie d’un processeur est
strictement liée à la consommation d’une cellule CMOS. Malgré cet aspect
évident et le fait que l’architecture de chaque processeur est complètement
connue, ce n’est pas suffisant pour établir une formule de consommation par
architecture processeur. Il a été montré que la consommation dépend aussi de
l’opération à accomplir, de son implantation et de la construction effective du
processeur. Pour toutes ces raisons et à partir de considérations pratiques, les
travaux menant aux résultats sur la consommation prennent comme hypothèse
le seul fait que, en exprimant la puissance dissipée en fonction de la vitesse du
processeur, on obtient une fonction convexe et strictement croissante. Nos
travaux s’inscrivent dans cette perspective et, en redéfinissant la
problématique, les résultats sont étendus aux architectures multiprocesseur
SoC à mémoire commune.
56
Chapitre III
Optimisation de la consommation d’énergie
III.2.2. L’ordonnancement des tâches et la consommation d’énergie : concepts
et idées
Dans le domaine du temps réel à échéances strictes, la connaissance des informations
sur l’ensemble de tâches qui constitue l’application pourrait permettre des évaluations de la
consommation d’énergie au niveau du/des processeur(s) qui, corroborées aux consommations
des autres composants, permettront une meilleure estimation de la durée de vie de celui-ci. Un
certain nombre de travaux ont été effectues sur ce sujet, notamment sur l’idée de trouver
l’ordonnancement optimal de point du vue énergétique pour l’ensemble de tâches donné.
Un ordonnancement faisable est dit optimal de point de vue énergétique si la
consommation d’énergie au niveau du/des processeur(s) due à l’exécution des tâches ainsi
ordonnancées est minimale par rapport à la consommation obtenue en utilisant autres
ordonnancements.
Note : Par la suite, chaque fois qu’on parle d’ordonnancement optimal on fait référence à
l’optimalité du point de vue de la consommation d’énergie.
Pour minimiser cette consommation d’énergie, deux solutions sont généralement
envisagées :
(i)
Exécuter les tâches conformément à un ordonnancement faisable pour une
vitesse du processeur, et pour tout intervalle de temps inutilisé par l’exécution
d’une tâche, mettre le processeur en mode HALT pour minimiser sa
consommation [WEI 94].
(ii)
Trouver un ordonnancement faisable, avec des vitesses minimales du CPU
pour l’exécution de chaque tâche, qui charge le processeur au maximum.
Des travaux comme [HON 98] ou [AYD 01c] montrent que la deuxième approche
préserve mieux l’énergie. Le problème qui se pose est de trouver les vitesses d’exécution des
tâches (i.e. les vitesses du processeur) qui correspondent à un ordonnancement optimal. Cela
pourrait conduire à des vitesses différentes pour les tâches, d’où la nécessité de faire varier la
vitesse du processeur. Cette variation n’est plus un concept théorique, car des processeurs
capables de changer leur fréquence avec une échelle très fine existent déjà : [HON 98], [INT
99], [TRA 03]. Mais faire varier la vitesse du processeur entraîne la variation du temps
d’exécution des différentes tâches, ce qui nécessite l’intégration de la gestion de la fréquence
à l’algorithme d’ordonnancement afin de pouvoir diminuer la consommation sans mettre en
danger le respect des contraintes temporelles des applications.
D’autre part, les approches théoriques existantes à l’heure actuelle et présentées par la
suite, utilisent des hypothèses sur l’architecture matérielle qui ne sont pas encore
technologiquement possibles. En premier, il est supposé que la fréquence du processeur peut
être fixée à une valeur quelconque, mais les processeurs actuels qui permettent ces
changements de fréquence, même ceux mentionnés, ne supportent qu’un nombre limité de
points de fonctionnement ayant chacun un couple de caractéristiques (fréquence, tension) bien
déterminé ([INT 99], [KLA 00]). Une autre hypothèse utilisée est que les temps de transition
d’une fréquence à une autre sont négligeables, or même si les données techniques sur les
processeurs à variation de fréquence sont encore peu nombreuses, il apparaît que les temps de
transition se chiffreront au moins en dizaines de cycles processeurs [INT 99]. Il est donc
nécessaire de trouver un moyen pour prendre en compte ces temps de commutation,
éventuellement dans le coût d’exécution des tâches, afin que le modèle reste valable en
pratique. Malgré cela, ces travaux constituent une première modélisation de la consommation
57
Chapitre III
Optimisation de la consommation d’énergie
d’énergie et les résultats fournis sont importants. Il est possible que ces hypothèses sur
l’architecture matérielle et les résultats qu’elles fournissent soient un des facteurs importants
qui déterminent l’évolution de la technologie.
Le problème de l’ordonnancement des tâches du point de vue de la consommation
d’énergie a été abordé pour la première fois dans [WEI 94], qui décrit quelques heuristiques
d’ordonnancement et mesure le gain d’énergie associé. Ce travail a été ultérieurement étendu
dans [GOV 95], et le formalisme mathématique mis au point dans [YAO 95]. Le modèle
proposé utilise un seul processeur à vitesse variable et s’applique à un ensemble de tâches
quelconques ; pour chaque tâche la fonction puissance dissipée par son exécution a la forme :
g (S ) = S p , p ≥ 2, p ∈ R .
La notion d’intervalle critique introduite est à la base d’un algorithme hors-ligne qui, pour un
ordonnancement donné, calcule les vitesses correspondantes des tâches en fonction de leur
position relative à cet intervalle. Deux heuristiques pouvant être utilisées par des algorithmes
en ligne sont présentées : le taux moyen associé à chaque tâche, avec la façon d’ajuster la
vitesse du processeur à un moment donné, et la disponibilité optimale, comme
ordonnancement optimal à calculer après chaque arrivée d’une nouvelle tâche. L’analyse du
taux moyen montre que la proportion de compétitivité (le rapport entre le taux moyen de
l’ordonnancement et l’énergie consommée par l’ordonnancement optimal) est constante si la
puissance a la forme mentionnée. En ce qui concerne la disponibilité optimale, les auteurs
n’ont mentionné que des résultats expérimentaux, sans une démonstration théorique sur la
proportion de compétitivité.
En 1998, Hong a proposé un algorithme, basé sur l’ordonnancement EDF, censé gérer
les tâches périodiques et sporadiques, et incluant la variation de la fréquence du processeur
dans l’ordonnancement. Le test d’acceptation d’une nouvelle tâche dans le système est
constitué par un test de faisabilité de l’ordonnancement EDF à la fréquence maximale du
processeur. Ensuite, lors de l’exécution des tâches, l’ordonnanceur fixe la fréquence de
fonctionnement du processeur en fonction de la valeur la plus grande qui correspond au plus
petit taux d’utilisation du processeur par une tâche, permettant de respecter l’échéance de
cette tâche.
Une autre approche, proposée aussi par Hong [HON 99], présente un algorithme basé
sur les régions ; le temps est divisé en intervalles délimités par des événements de type
« arrivée d’une nouvelle tâche » ou « échéance d’une tâche ». L’ordonnancement est constitué
par deux phases. Dans une première phase, l’algorithme d’ordonnancement attribue à chaque
région une tâche à exécuter selon les contraintes de l’application. La deuxième phase consiste
à ajuster les bornes et les fréquences de chaque région afin d’obtenir pour chaque nouvelle
région la fréquence de fonctionnement la plus faible possible. Pour obtenir un meilleur
ordonnancement, la phase de placement des tâches sur les régions comporte un paramètre
aléatoire qui permet à l’ordonnanceur de générer plusieurs ordonnancements ; au final, celui
qui donne la consommation la plus basse est choisi. L’évaluation de cet algorithme a été
effectuée par simulation à partir de données fournies par les constructeurs des différents
processeurs.
L’approche théorique développée dans [AYD 01c], [AYD 01b], [MEL 02] propose
des solutions d’ordonnancement statique, puis dynamique, monoprocesseur, afin d’optimiser
la consommation d’énergie, pour le cas de tâches périodiques indépendantes. Basée sur les
mêmes idées, une approche multiprocesseur est proposée dans [ZHU 01] et des algorithmes
non préemptifs sont pris en considération. Nous présentons par la suite notre point de vue sur
l’ordonnancement optimal des tâches en utilisant ces résultats (§III.2.3).
58
Chapitre III
Optimisation de la consommation d’énergie
Les travaux sur l’ordonnancement optimal des tâches sont essentiellement
théoriques et les résultats pratiques sont issus de simulations. Les différentes
approches ont à la base l’idée de trouver la vitesse d’exécution optimale de
chaque tâche, et cela soit en fonction du modèle de tâches et de la machine,
connues a priori, soit en introduisant différentes heuristiques. Il est supposé
que la vitesse du processeur soit modifiable, et cela jusqu’à proposer des
algorithmes d’ordonnancement en ligne qui modifient la vitesse du processeur
en fonction de l’état réel de déroulement de l’application.
III.2.3. Consommation optimale de l’énergie. Modèle de tâches périodiques
indépendantes
Ce paragraphe présente l’approche la plus récente, à notre connaissance, pour un
ordonnancement statique, puis dynamique, optimal pour le modèle de tâches périodiques
indépendantes. Les solutions d’ordonnancement proposées, en vue d’une optimisation de
l’énergie, sont basées sur une analyse monoprocesseur.
III.2.3.1.
Notations, définitions, concepts
Soit Tn={T1,T2,…,Tn} un ensemble de n tâches périodiques indépendantes prêtes à
s’exécuter à l’instant t=0. Chaque tâche Ti est caractérisée par :
Ci : le coût pire cas d’exécution, en cycle CPU, de la tâche Ti,
Pi : la périodicité de la tâche Ti,
Di : l’échéance de l’invocation courante de la tâche Ti .
Il est pris en compte le cas d’échéance sur requête : Pi=Di.
Le temps d’exécution de la tâche Ti en utilisant une vitesse constante Si du
processeur est donné par : ti = Ci .
Si
La fonction gi (S ) représente la puissance consommée pour l’exécution de la tâche Ti,
qui dépend de la vitesse du processeur S. Elle est une fonction convexe croissante stricte,
polynomiale de degré minimum 2 [AYD 01b].
La consommation d’énergie durant la période [t1 ,t2 ] correspondant à l’exécution de la
tâche Ti pendant cette période est donnée par :
(
t2
) ∫ g (S (t )) dt .
E i t1 , t 2 =
i
t1
III.2.3.2.
Solution statique optimale
Cette section porte sur l’ordonnancement optimal statique pour une plate-forme
monoprocesseur, développé par Aydin et al. dans une série d’articles [AYD 01a,b,c].
Les estimations pire-cas des coûts d’exécution des tâches, données par le nombre de
cycles d’horloge, sont supposées connues. Ceci permet d’évaluer le temps d’exécution de
59
Chapitre III
Optimisation de la consommation d’énergie
chaque tâche en fonction des différentes vitesses du processeur.
Deux hypothèses ont été considérées pour cette modélisation :
•
le changement de la vitesse du processeur ne peut se produire que pendant la
commutation du contexte ;
•
durant la période qui correspond à l’itération j de la tâche Ti, la tâche garde une
vitesse constante Sij.
Aussi, les auteurs considèrent que, sans perdre la généralité du problème, après une
normalisation des vitesses relative à la vitesse maximale du processeur, on peut considérer :
0 < S min ≤ S ≤ S max = 1 , où S min et S max représentent les valeurs extrêmes normalisées des
vitesses du processeur.
Le problème de trouver l’ordonnancement statique optimal du point de vue de la
consommation d’énergie, sur une machine monoprocesseur pour un ensemble de tâches
périodiques indépendantes, est formalisé [AYD 01b] comme un problème d’optimisation. Les
équations qui le composent expriment :
(1) le critère d’optimisation de la minimisation de la fonction qui calcule la
consommation d’énergie durant la période P ;
(2) la condition d’exécution des tâches durant la période P ;
(3) les limites des vitesses du processeur dans l’exécution des tâches (Smin – la
vitesse qui correspond à la tension de charge minimale qui assure le
fonctionnement du système ; Smax – la vitesse maximale que le processeur peut
atteindre).
Pour qu’une solution à ce problème d’optimisation soit une solution
d’ordonnancement optimal, elle doit assurer également la faisabilité de l’ordonnancement (4).
Par la suite, POW-OPT dénommera le problème d’ordonnancement optimal décrit par les
équations ci-dessus.
n P / Pi
⎧
Ei S ij
min
⎪
∑
∑
i
j
=
=
1
1
⎪
⎪ n P / Pi C i
⎪∑ ∑
≤P
⎨ i =1 j =1 S ij
⎪
P
⎪S min ≤ S ij ≤ S max
i = 1, K, n
j = 1,K,
Pi
⎪
⎪Il existe un ordonnancement faisable avec S
ij
⎩
( )
( POW − OPT )
{ }
(1)
(2)
(3)
(4)
Les deux énoncés qui suivent, et qui représentent les résultats les plus importants sur
l’ordonnancement optimal, sont basés sur la condition nécessaire et suffisante dans le cas
monoprocesseur, sur la faisabilité à ordonnancer des tâches à échéance sur requête (Th.II.6) :
n
ti
∑P
i =1
i
60
≤ 1.
Chapitre III
Optimisation de la consommation d’énergie
Théorème III.1 [AYD 01b] : Pour toute instance du problème POW-OPT, il y a une solution
optimale qui suppose une vitesse constante pour toutes les évolutions de la tâche Ti :
Sij = Sik = Si , 1≤ j ≤k ≤ P .
Pi
Autrement dit, pour tout ensemble spécifique des tâches qui correspond au modèle
périodique, il y a un ordonnancement optimal qui préserve une vitesse constante pendant
toutes les itérations de chaque tâche.
Note : (Solution optimale algorithmique pour le problème statique) [AYD 01b] mentionne
l’équivalence du problème POW-OPT, pour des valeurs identiques de la vitesse d’une tâche à
chaque itération, avec un problème d’optimisation dont une solution peut être obtenue
conformément à un algorithme de complexité O(n2 logn) [AYD 01a]. Ce problème est obtenu à
⎛ ⎞
partir de POW-OPT par les changements de variables : Si = Ci , Ei ⎜ Ci ⎟= E'i (ti ) , li = Ci ,
Smax
ti
⎝ ti ⎠
C
ui = i et ti =t'i +li pour i =1,K,n , et prend la forme exprimée par le problème d’optimisation
Smin
OPT-LU ci-dessous :
n
⎧
P E'i (t'i +li ) (1')
min
∑
⎪
P
i
⎪⎪ n i =1
(OPT − LU) ⎨∑ P (t'i +li )≤ P
(2') .
P
i
i
=
1
⎪
⎪
⎪⎩0≤t'i ≤ui −li i =1,K,n (3')
Proposition III.1 [AYD 01c] : (Solution spécifique pour un cas particulier) Pour toute
instance du problème POW-OPT, si la fonction qui exprime la puissance dissipée par le
processeur pour l’exécution de chaque tâche est la même ( g i = g , ∀i = 1,K, n ), alors la
solution optimale est constante et donnée par S =max{Smin,U tot }, et représente la vitesse
d’exécution de chaque tâche pour toute itération.
Note : Malheureusement, dans l’énoncé de la Proposition III.1 une erreur d’interprétation s’est
produite. Aussi, dans la démonstration de ces deux résultats une erreur mathématique est passée
inaperçue. Une discussion sur ces aspects sera menée dans la section III.3.1. Les résultats restent
cependant valables, comme on le verra, si on complète les deux énoncés et si on ajoute une
condition de plus à la fonction qui exprime la dissipation de la puissance. Pour cela, nous
continuons de présenter les autres résultats de ces auteurs, car ils restent d’une importance
majeure dans le domaine.
Corollaire III.1 : [AYD 01b] : Pour un ensemble de tâches périodiques temps réel ayant
chacune comme vitesse d’exécution constante, la vitesse optimale précédemment déterminée,
toute politique d’ordonnancement qui utilise la capacité maximale du processeur (ex. EDF,
LLF, RM-h – le « Rate Monotonic » appliqué aux cas des périodes harmoniques) pourrait
être utilisé pour obtenir un ordonnancement optimal.
61
Chapitre III
III.2.3.3.
Optimisation de la consommation d’énergie
Solution dynamique optimale
La théorie et les calculs décrits auparavant sont basés sur l’estimation pire-cas du coût
des tâches. L’idée d’une solution dynamique, introduite par Aydin et al. [AYD 01c], repose
sur le principe suivant : il faut déterminer le temps d’exécution réel de la tâche en cours
d’exécution, qui est généralement en avance sur l’estimation pire-cas, afin d’ajuster la vitesse
des tâches à venir en fonction de ce gain de temps, tout en ne pas dépassant leurs échéances
estimées. C’est cette solution que nous traitons dans cette section afin de servir de référence
pour certaines idées développées à la suite du chapitre.
Soit Scan le scénario canonique des tâches, donné par l’ordonnancement optimal
statique dans lequel, à toute activation, les tâches activées s’exécutent toutes à la vitesse
constante S , calculée conformément à la charge pire-cas (voir la Proposition III.1, sur une
solution particulière pour le problème d’optimisation statique). La terminaison anticipée de
l’exécution d’une tâche peut être identifiée à l’aide de Scan. Par conséquent, du point de vue de
l’implantation, le descripteur de processus doit contenir la vitesse actuelle d’exécution de la
tâche, mais aussi sa vitesse nominale S .
Dans l’algorithme GDRA (Generic Dynamic Reclaiming Algorithm), basé sur les
idées présentées ci-dessus, Aydin et al. proposent l’utilisation d’une structure de données
appelée « α -queue » comme moyen de sauvegarde du Scan, au sens où à tout instant t les
informations pouvant être obtenues pour chaque tâche sont :
•
i – l’identité de la tâche ;
•
ri,j – le moment de début de la jème itération de la tâche Ti (l’itération en cours) ;
•
di,j – l’échéance de l’itération en cours ;
•
remi,j(t) – le temps d’exécution restant pour la tâche Ti au moment t, dans Scan, avec
une vitesse d’exécution S .
Notation : wiS (t ) représente le temps d’exécution pire-cas restant, au moment t, pour la tâche
Ti, avec la vitesse d’exécution S.
L’ordre des tâches dans l’α-queue est donné par les priorités calculées avec
l’algorithme EDF* (§II.3.2.3) qui permet d’avoir un rang d’activation total ordonné en
fonction des priorités di∗ assignées aux tâches.
Loi d’implémentation de l’α-queue :
1. Au début, l’ α -queue est vide.
2. A chaque arrivée d’une tâche Ti, elle place dans l’ α -queue son temps d’exécution
pire-cas avec la vitesse nominale Sˆi = S , correspondant à la priorité calculée avec
EDF* ; ceci une seule fois, à la première exécution, car il n’y a pas de replacement
au retour d’une préemption.
3. Au fur et à mesure que les éléments de l’ α -queue se consomment : remi,j de la tête
de l’ α -queue est décrémenté avec le taux qui correspond au temps écoulé ; quand
il arrive à 0, l’élément est retiré de l’ α -queue et l’actualisation continue. Il n’y a
pas d’actualisation de l’ α -queue si elle est vide.
62
Chapitre III
Optimisation de la consommation d’énergie
Nous présentons ensuite l’algorithme GDRA et la procédure de réduction de vitesse,
pour faciliter la discussion sur l’ordonnancement dynamique développée au paragraphe
suivant.
Algorithme GDRA :
1. Calcul de S (§2.4.3) et attribution Sˆi = S , ∀i =1,...,n .
2. Initialisation de l’ α -queue comme une liste vide.
3. A toute arrivée d’une nouvelle tâche Ti, insertion dans
l’ α -queue de l’information la concernant :
sur la position calculée par EDF*.
remi (t )=wiSi ,
ˆ
4. A tout évènement (activation/fin d’une tâche), la valeur
de remi , qui correspond au premier élément de l’ α -queue,
est décrémentée par la durée de temps écoulé à partir du
dernier évènement. Si la valeur devient inférieur à 0, le
premier élément est retiré de la liste et le deuxième est
actualisé avec le temps écoulé restant, et ainsi de suite
jusqu’à l’utilisation du temps entier restant.
5. Si au moment t il y a le dispatching de la tâche Tx :
5.0. S x = Sˆx ;
5.1. Consultation de l’ α -queue et calcul de l’indicateur
de la plus proche terminaison de Tx :
ε x (t )=
∑rem (t )−w (t )
i
Sˆ x
x
;
i d i∗ ≤ d x∗
5.2. Réduction de la vitesse de la tâche Tx pour lui
donner Y unités de temps supplémentaire d’exécution : Sx =
Réduction_vitesse(Tx, Y, Sx), où 0≤Y ≤ε x (t ) .
6. A tout évènement de préemption ou de terminaison d’une
tâche Ti : wi i = wi i −∆t , où ∆t représente le temps écoulé
depuis le dernier dispatching de la tâche Ti.
S
S
Procédure Réduction_vitesse(Tx, B, S)
S
x
1. S x = w
⋅S
S
wx + B
2. Si S x < Smin alors S x = S min
3. retourne S x
Théorème III.2 : A tout moment t de l’exécution du GDRA, pour toute tâche Ti :
wiSi (t)≤remi (t ) .
ˆ
Corollaire III.2 : GDRA conduit à un ordonnancement faisable en utilisant EDF* pour une
charge qui n’est pas supérieure à la charge pire cas.
Une situation particulière dans l’exécution d’une tâche est la situation dans laquelle
63
Chapitre III
Optimisation de la consommation d’énergie
elle est la seule dans la file des tâches prêtes. Aydin et al. [AYD 01c] ont incorporé dans leur
algorithme la technique OTE (One Task Extension) proposée par Shin et Choi [SHI 99], qui
consiste à ralentir le temps d’exécution de cette tâche. Appliquant cette technique dans
l’algorithme précédent, on obtient :
5.3.
Si Tx est la seule tâche prête à s’exécuter, NTA le
moment
le
plus
proche
du
prochain
événement
(arrivée/échéance d’une tâche) et Z = NTA−t − wxS x (t )>0 ,
alors Sx = Réduction_vitesse(Tx, Z, Sx).
L’algorithme ainsi obtenu, et appelé DR-OTE dans [AYD 01c], assure la faisabilité de
l’ordonnancement et, conformément aux résultats expérimentaux annoncés, il assure une
minimisation de la consommation énergétique qui va jusqu’à 50% supplémentaire par rapport
à l’application unique de OTE relative à la solution statique optimale. Il peut atteindre jusqu’à
60% par rapport à la solution statique optimale qui met le processeur dans l’état HALT
lorsqu’aucune tâche n’est plus dans le système.
Les travaux de Aydin et al. proposent des solutions monoprocesseur pour un
ordonnancement optimal des tâches indépendantes périodiques. Ils montrent
que pour la solution statique les tâches doivent s’exécuter à la même vitesse, le
maximum entre la vitesse minimale du processeur et la vitesse qui permet de
charger au maximum le processeur. La solution dynamique part de la solution
statique, pour ajuster en ligne la vitesse d’exécution de tâche à venir si la
tâche précédente s’est terminée plus tôt que prévu par l’estimation et la
solution statique, afin que le processeur reste chargé au maximum. Notre
approche utilise ces résultats mais propose un autre regard sur le problème
d’optimisation de la consommation d’énergie qui permet d’élargir la
problématique vers les multiprocesseurs SoC.
III.3. Contribution : analyse critique de la solution actuelle pour le
cas monoprocesseur et compléments
Dans cette section nous effectuons d’abord (§III.3.1) une analyse critique, certaines
corrections et quelques compléments qui s’imposent au modèle présenté dans la section
§III.2.3. Ensuite, dans §III.3.2, nous indiquons deux résultats généraux mais importants dans
le nouveau contexte de processeur à vitesse variable, pour le modèle de tâches périodiques,
indépendantes, à échéance sur requête, ayant le même moment d’activation. Nous finissons
(§III.3.3) par résoudre le problème monoprocesseur d’ordonnancement optimal pour ce
modèle de tâches en fournissant une formule pour les vitesses qui exprime la solution statique
optimale.
64
Chapitre III
Optimisation de la consommation d’énergie
III.3.1. Analyse critique, corrections et compléments des travaux présentés
dans §III.2.3
Comme nous l’avons mentionné précédemment, quelques erreurs qui concernent la
solution statique sont passées inaperçues. Les résultats restent cependant valables, comme on
le verra, mais quelques précisions de plus et quelques corrections, que nous introduisons dans
cette section, s’imposent.
Bien que, depuis le début de ces articles, il soit considéré que, sans perdre de la
généralité du problème, les vitesses peuvent être normalisées relativement à la vitesse
maximale que le processeur peut avoir, et donc : 0 < S min ≤ S ≤ S max = 1 , les résultats qui
suivent ne sont pas basés sur la normalisation, d’une part, et, d’autre part, cette normalisation
crée des confusions dans l’interprétation des résultats, car elle n’a pas été répercutée dans la
formule sur la consommation d’énergie qui a été utilisée dans les démonstrations des
théorèmes, ainsi dans les exemples proposés. Pour ces raisons et afin de ne pas compliquer le
cadre, nous omettons par la suite l’idée de normalisation.
En ce qui concerne la forme de la fonction qui exprime la puissance dissipée par le
processeur due à l’exécution d’une tâche, il faut mentionner que l’hypothèse que cette
fonction soit polynomiale de puissance minimum 2 ne représente qu’un cas particulier,
comme on l’a vu dans la section §III.2.1. Notons que cette spécification n’est pas utilisée
explicitement dans la démonstration des théorèmes ; malgré cela il semble que les auteurs ont
basé les démonstrations sur cette forme et de plus le polynôme n’ayant que le terme de plus
grand degré. Les exemples de simulation considérés le confirment.
L’erreur effective vient de l’affirmation que Ei (S ij ) est une fonction convexe et
croissante stricte, si g i (S ij ) est une fonction convexe et croissante stricte, spécifiquement une
fonction polynomiale de puissance minimum 2 [AYD 01b,c]. Cette affirmation n’est pas vraie
et nous indiquons par la suite le raisonnement qui la contredit, ainsi qu’un exemple l’étayant.
Soit Ei (S ij ) l’énergie consommée durant l’itération j de la tâche Ti, Pija la durée qui
correspond à son exécution et C ij le nombre de cycles processeur qui correspondent à cette
activation de la tâche. Comme Pija = C ij S ij on peut déduire :
( ) ∫ g (S )dt = P g (S ) = C h (S ) ,
Ei S ij =
i
a
ij
ij
i
ij
ij
i
ij
Pij
où :
hi (S ) = g i (S ) S .
Dans ces conditions, comme C ij est une constante positive, la consommation énergétique Ei
est une fonction convexe croissante si la fonction hi est convexe et croissante. Mais cette
propriété de la fonction hi n’est pas du tout une conséquence des propriétés de convexité et
de croissance de la fonction g i (et ni de la forme polynomiale). Bien au contraire, comme
nous l’indiquons dans l’exemple suivant.
65
Chapitre III
Optimisation de la consommation d’énergie
Exemple : Soit la fonction de la puissance dissipée par le processeur donnée par :
g (S ) =
1 2 1 3 1 4
S − S + S .
2
3
12
En calculant les dérivées de premier et de deuxième ordre on obtient :
g ' (S ) = S − S 2 +
et, respectivement :
S3
3
g" (S ) = 1 − 2 S + S 2 = (1 − S ) ≥ 0 .
2
La dérivée de deuxième ordre indique la convexité de la fonction g, ainsi que la
croissance stricte de la première dérivée. Comme g ' (0 ) = 0 , on obtient g ' (S ) ≥ 0 pour tout S
positif, soit g fonction croissante pour les valeurs positives de S. Donc, la fonction g ainsi
choisie respecte bien les conditions imposées dans [AYD 01b,c].
En ce qui concerne la fonction h, les résultats sont les suivants :
h(S ) =
1
1
g (S ) 1
= S − S2 + S3,
S
2
3
12
h ' (S ) =
1 2
1
− S + S2
2 3
4
et, respectivement,
2 1
h" (S ) = − + S ,
3 2
d’où :
4
⎧
≤
≤
0
pour
S
⎪
3.
h" (S ) ⎨
4
⎪ > 0 pour S >
3
⎩
Donc, la fonction h" n’est ni convexe ni croissante stricte pour l’entier intervalle
[0,+∞[ et, en conséquence, la consommation énergétique ne l’est pas pour cet intervalle.
Notons, pourtant, qu’il y a de nombreux exemples dans lesquels la convexité et la
croissance stricte de la fonction g impliquent la convexité de la fonction h. Nous en indiquons
quelques uns, après les calculs qui donnent les formules pour la première et la deuxième
dérivée de la fonction h.
g ' (S )S − g (S )
h ' (S ) =
S2
=
g ' (S ) g (S )
− 2 ,
S
S
d’où la deuxième dérivée est donnée par :
′
′
⎛ g ' (S ) ⎞ ⎛⎜ g (S ) ⎞⎟
h" (S ) = ⎜
⎟ −
2
⎝ S ⎠ ⎜⎝ S ⎟⎠
66
Chapitre III
Optimisation de la consommation d’énergie
2
Sg ′′(S ) − g ′(S ) S g ′(S ) − 2Sg (S )
=
−
S2
S4
=
[
]
1 3
S g ′′(S ) − S 2 g ′(S ) − S 2 g ′(S ) + 2Sg (S )
4
S
=
[
]
1 2
S g ′′(S ) − 2 Sg ′(S ) + 2 g (S ) .
S3
Notons aussi que, si la puissance dissipée a une forme polynomiale :
r
g (S ) = ∑ a j S j , r ∈ N, r ≥ 2, a j ∈ R, ∀j = 0, K , r ,
j =0
le terme libre a 0 indique la puissance dissipée si le processeur est arrêté (S=0) et il doit être
positif ou nul.
Exemple 1 : Soit g (S ) = a 0 + a1 S + a 2 S 2 , avec des coefficients réels, où a 0 ≥ 0 et a 2 ≥ 0 .
Alors les fonctions g (S ) et h(S ) = g (S ) S sont convexes.
Démonstration : Le calcul de la dérivée de deuxième ordre de la fonction g fournit :
g ′′(S ) = 2a 2 ≥ 0 ,
donc g est une fonction convexe.
Le calcul de la dérivée de deuxième ordre de la fonction h fournit :
h′′(S ) =
=
[
(
)
(
1
2a 2 S 2 − 2 a1 + 2a 2 S S + 2 a0 + a1 S + a 2 S 2
3
S
(
1
2a 2 S 2 − 2a1 S − 4a 2 S 2 + 2a 0 + 2a1 S + 2a 2 S 2
S3
=
)]
)
2a 0
≥ 0,
S3
donc h est une fonction convexe.
Exemple 2 : Soit g (S ) = kS p , p ≥ 2, p ∈ R, k ∈ R, k > 0 . Alors les fonctions g (S ) et
h(S ) = g (S ) S sont convexes.
Démonstration : Le calcul de la dérivée de deuxième ordre de la fonction g fournit :
g ′′(S ) = k ( p − 1) pS p − 2 ≥ 0, pour S ≥ 0 ,
donc g est une fonction convexe.
Le calcul de la dérivée de deuxième ordre de la fonction h fournit :
67
Chapitre III
Optimisation de la consommation d’énergie
h ′′(S ) = k ( p − 1)( p − 2 )S p − 2 ≥ 0, pour S ≥ 0 ,
donc h est une fonction convexe.
Notons que la forme de la fonction g prise en compte par Yao et al. ([YAO 95]) est :
g (S ) = S p , p ≥ 2, p ∈ R ,
et que les fonctions considérées dans les exemples de simulation proposés par Aydin et al.
([AYD 01b,c]) sont :
g (S ) = kS 3 , k ∈ R, k > 0 ,
avec k = 2,4,6 ou suivant une distribution uniforme dans l’intervalle [1,8]. Par conséquent, les
deux cas s’inscrivent dans l’exemple 2 ci-dessus mentionné.
A
Exemple 3 : Soit g (S ) = ∑ g α (S ) , où les fonctions hα = g α (S ) S sont convexes pour
α =1
α = 1,K , A, A ∈ N . Alors la fonction h(S ) = g (S ) S est convexe.
Démonstration : Le calcul de la dérivée de deuxième ordre de la fonction h fournit :
h ′′(S ) =
1
S3
A
A
⎡ 2 A
⎤
′
′
′
(
)
(
)
−
+
S
g
S
2
S
g
S
2
g α (S )⎥
∑
∑
∑
α
α
⎢
α =1
α =1
⎣ α =1
⎦
A
[
]
1 2
S g α′′ (S ) − 2Sg α′ (S ) + 2 g α (S )
3
α =1 S
=∑
A
= ∑ hα′′ (S ) .
α =1
Or
hα convexe ⇒ hα′′ ≥ 0 ,
d’où h ′′ ≥ 0 , donc h est convexe.
Avec ces observations sur la relation entre les propriétés de la fonction qui exprime la
puissance dissipée et celle qui exprime la consommation d’énergie, la Théorème III.1 peut
être reformulée comme suit :
Théorème III.1’ : Pour toute instance du problème POW-OPT où les fonctions hi associées
aux dissipations de puissance g i par la formule hi (S ) = g i (S ) S sont convexes et
croissantes, il y a une solution optimale qui suppose une vitesse constante pour chaque
évolution de la tâche Ti :
Sij = Sik = Si , 1≤ j ≤k ≤ P .
Pi
68
Chapitre III
Optimisation de la consommation d’énergie
Note : Le Théorème III.1’ n’est pas nécessairement valable pour d’autres modèles de tâches
périodiques, ni pour le cas multiprocesseur, comme l’indiquent les exemples suivants.
Exemple 1 : Considérons un ensemble {T1, T2, T3} de 3 tâches périodiques indépendantes et
non synchrones pour lesquelles P1=1, P2 = P3 = 2, D1=D2=D3=1 ; les tâches T1 et T2 s’activent
pour la première fois à l’instant t=0, et la tâche T3 à l’instant t=1. Leurs coûts d’exécution
pire cas exprimés en cycles processeurs, C i , sont tous égaux à 6, et leurs fonctions de
dissipation de puissance g i sont données par g1 ( S ) = S 3 , g 2 ( S ) = 8S 3 et g 3 ( S ) = 27 S 3 .
La solution optimale est obtenue en découpant le problème en deux, et en appliquant
pour chacun d’entre eux le Lemme III.2 :
la solution optimale obtenue pour les intervalles [2k, 2k+1[ et l’ensemble des
tâches {T1, T2} qui fournit les vitesses optimales S11 = 18 et S 2 = 9 , donc les
temps d’exécution C11 = 1 3 et C 2 = 2 3 , et respectivement,
la solution optimale obtenue pour les intervalles [2k-1, 2k[ et l’ensemble des
tâches {T1, T2} qui fournit les vitesses optimales S12 = 24 et S 3 = 8 , donc les
temps d’exécution C12 = 1 4 et C 3 = 3 4 .
La Figure III.2 montre un ordonnancement optimal pour la situation ci-dessus
présentée.
Figure III.2. UP - vitesses optimales différentes pour des itérations différentes de la tâche T1.
Exemple 2 : Pour les plates-formes multiprocesseur il existe des ordonnancements non
préemptifs optimaux attribuant des vitesses différentes pour des itérations différentes de la
même tâche, comme l’indique la situation suivante.
Soit une plate-forme à 2 processeurs qui doit exécuter sans préemption un ensemble
T ={T1, T2, T3, T4} de 4 tâches périodiques, indépendantes, à échéance sur requête, ayant
4
toutes la même périodicité P=1. Les coûts d’exécution pire cas C i et les coefficients ai pour
les fonctions de dissipation de puissance g i ( S ) = ai S 3 sont présentées dans le Tableau III.1.
Ti
ai
Ci
1
1
6
2
1
6
3
8
6
4
27
6
Tableau III.1. Coûts d’exécution et coefficients des fonctions de dissipation de puissance.
69
Chapitre III
Optimisation de la consommation d’énergie
Les tâches T1 et T2, étant les plus petites consommatrices d’énergie, seront distribuées
sur des processeurs différents. En appliquant pour chaque processeur le Lemme III.2 pour la
période P, pour l’ordonnancement présenté par la Figure III.3, les vitesses optimales des
tâches sont : S11 = S 22 = 18 , S 3 = 9 , S 21 = S12 = 24 et S 4 = 8 , et donc les temps d’exécution
sont : C11 = C 22 = 1 3 , C 3 = 2 3 , C12 = C 21 = 1 4 et C 4 = 3 4 .
Figure III.3. MP - vitesses optimales différentes pour des itérations différentes de la même tâche.
Comme on l’a mentionné, il y a aussi une erreur dans l’énoncé de la Proposition III.1.
Elle est donnée par la formule S = max S min , U tot . En premier, comme on l’a déjà dit, les
vitesses indiquées doivent être considérées par leurs valeurs absolues et non pas normalisées.
L’autre inconvénient est donné par la confusion de notation avec celle classique de la théorie
de l’ordonnancement. D’une part, il s’agit du coût d’exécution d’une tâche qui, dans la théorie
d’ordonnancement est noté également Ci, mais il représente le temps d’exécution pire cas de
la tâche et non pas le nombre de cycles d’horloge associés. Ceci a conduit à une redéfinition
de la charge totale du processeur, U tot , introduite au début de [AYD 01c] comme étant
l’utilisation totale due à l’exécution de l’ensemble des tâches avec la vitesse maximale
S max = 1 . D’autre part, la démonstration donnée suggère l’idée de prendre pour la valeur S la
vitesse correspondant à une charge maximale du processeur (i.e. à tout moment le processeur
exécute une tâche), dont 1, si cette vitesse est supérieure à la vitesse minimale acceptable pour
le bon fonctionnement du système. La Proposition III.1 devient :
{
}
Proposition III.1’ : (Solution spécifique pour un cas particulier) Pour toute instance du
problème POW-OPT, si la fonction qui exprime la puissance dissipée par le processeur pour
l’exécution de chaque tâche est la même ( g i = g , ∀i = 1,K, n ), alors la solution optimale est
{
}
constante et donnée par S = max S MIN , S tot , et représente la vitesse d’exécution de chaque
tâche pour toute itération. Stot est la vitesse qui pourrait assurer une charge du processeur
égale à 1.
Note : La formule qui exprime S tot est obtenue comme suit :
n
U tot = ∑
i =1
n
⇔∑
i =1
ti
=1
Pi
Ci
S tot
Pi
70
=1
Chapitre III
Optimisation de la consommation d’énergie
n
⇔ S tot = ∑
i =1
Ci
.
Pi
On peut constater la coïncidence, dans la forme, avec la formule obtenue par Aydin, mais cette
valeur n’est pas une valeur normalisée, comme cela a été indiqué au début de ses travaux.
Note : La Proposition III.1’ n’est plus valable si les fonctions exprimant la consommation des
tâches sont différentes (voir Th. III.3).
On a déjà remarqué que la fonction g : [0,+∞[ → R , qui exprime la puissance dissipée
par un processeur pour l’exécution d’une tâche, est unanimement acceptée dans la littérature
comme étant croissante et convexe (voir, pour exemple, [YAO 95], [HON 99], [AYD
01a,b,c], [MEL 02], [ZHU 01]). Comme il s’agit d’une estimation, on peut aussi la considérer
dérivable au deuxième ordre. D’ailleurs, les cas particuliers qui ont été traités dans ces articles
respectent bien cette condition de dérivabilité.
Nous indiquons, par le lemme suivant, une autre propriété de la fonction h associée à
une telle fonction g, utile également dans les démonstrations des résultats présentés dans les
sections suivantes.
Lemme III.1 : Soit g : [0,+∞[ → R une fonction croissante, convexe et dérivable de deuxième
ordre, pour laquelle la fonction h : [0,+∞[ → R donnée par h( x ) = g ( x ) x est également
convexe et dérivable de deuxième ordre. Alors la fonction h est croissante.
Démonstration : Conformément à la relation qui existe entre les deux fonctions, on a :
g ( x ) = xh( x ) , d’où g ' ( x ) = h(x ) + xh' ( x ) . Par la dérivabilité au deuxième ordre de g et h, on
obtient :
g ' ' ( x) = 2h' ( x) + xh' ' ( x) .
La convexité de la fonction g implique g " ( x ) ≥ 0 pour tout x ∈ [0,+∞[ , donc
g" (0 ) = 2h' (0 ) + 0h" (0 ) ≥ 0,
et par la suite :
h' (0 ) ≥ 0.
La convexité de la fonction h donne h" ( x ) ≥ 0 pour tout x ∈ [0,+∞[ , et en conséquence la
fonction h' est croissante. Comme h' (0 ) ≥ 0 , on déduit h' ( x ) ≥ 0 pour tout x ∈ [0,+∞[ et donc
la fonction h est croissante. ■
Certaines précisions relatives aux résultats présentés par Aydin et al.
s’imposaient, notamment sur la normalisation des vitesses, et la relation entre
les propriétés de la puissance dissipée et la consommation d’énergie. De plus,
la forme générale pour la puissance dissipée permet d’avoir une classe plus
large de fonctions qui se prêtent aux résultats reformulés ; autrement dit, si la
puissance dissipée est estimée avoir ces propriétés, les résultats sont valables
pour le cas traité.
71
Chapitre III
Optimisation de la consommation d’énergie
III.3.2. Résultats généraux concernant l’optimalité
Suite à la solution optimale proposée par le Théorème III.1, le Corollaire III.1 (voir
§III.2.3.2) indique la possibilité d’utiliser EDF ou LLF pour obtenir un ordonnancement
optimal. L’argumentation s’appuie sur le fait que, ayant la même vitesse à chaque itération,
les tâches ont la même durée d’exécution à chaque itération. Par conséquent, celle-ci permet
la transformation du problème d’ordonnancement optimal énergétique monoprocesseur d’un
ensemble de tâches périodiques, indépendantes, à échéance sur requête, en un problème de
faisabilité pour le même modèle de tâches, qui charge au maximum le processeur
Ainsi formulé, ce résultat est étroitement lié au Théorème III.1, dont on a mentionné
les limites. Compte tenu de l’optimalité de l’algorithme d’ordonnancement EDF pour d’autres
modèles de tâches (voir Th. II.9), nous indiquons par le théorème suivant un résultat plus
général que le Corollaire III.1.
Théorème III.3 : Si pour un ensemble de tâches indépendantes il existe un ordonnancement
monoprocesseur optimal de point de vue énergétique, alors il en existe un autre qui est
produit par l’algorithme EDF.
Démonstration : Dans la démonstration de cette affirmation on utilise la même idée qui prouve
l’optimalité de EDF comme ordonnanceur. Supposons, pour la simplicité de l’argumentation,
qu’il existe un ordonnancement non préemptif optimal de point de vue énergétique et
différent de EDF. Il existe donc au moins deux tâches, Ti et Tj, qui s’exécutent dans l’ordre
inverse de leurs délais, Tj d’abord. Soit Ti la première tâche qui, dans cet ordonnancement,
s’exécute après Tj et qui a l’échéance avant celle de Tj (Di <Dj). Alors, toutes les tâches qui
s’exécutent après Tj et avant Ti, plus Tj, ont leurs délais après Di. Donc, leurs exécutions
peuvent être retardées chacune avec le temps Ci, nécessaire à l’exécution de la tâche Ti juste
avant Tj, tout en gardant la faisabilité, comme le montre la Figure III.4. Après un nombre fini
de telles itérations, cette procédure transforme le premier ordonnancement en EDF, tout en
gardant la faisabilité et les vitesses des tâches. Ce dernier constat indique que la
consommation énergétique de EDF est égale à celle de l’ordonnancement initial. ■
Figure III.4. Procédure de réduction d’un ordonnancement monoprocesseur à EDF.
Notons que toute cette argumentation n’a utilisé que les durées d’exécution et les
échéances des tâches. L’ordonnancement obtenu par EDF utilise les mêmes vitesses optimales
des tâches que l’ordonnancement optimal initial. En conséquence, une fois calculées, les
éventuelles variations des vitesses qui assurent l’optimalité énergétique n’interviennent pas
dans l’algorithme d’ordonnancement.
Une autre observation intéressante concerne l’argumentation de la condition
nécessaire et suffisante d’ordonnancement monoprocesseur d’un ensemble de tâches
72
Chapitre III
Optimisation de la consommation d’énergie
périodiques, indépendantes à échéance sur requête (Th. II.6). Etant donné que tous les
arguments mentionnés dans la démonstration restent valables dans le contexte de notre travail,
c'est-à-dire pour des processeurs à vitesse variable, la condition reste inchangée même si les
tâches changent de vitesse durant leur exécution.
Théorème III.4 : Pour un ensemble de tâches périodiques, indépendantes, à échéance sur
requête, une condition nécessaire et suffisante d’ordonnancement sur une machine
monoprocesseur à vitesse variable est : U ≤1 .
Notons que l’implication la plus souvent utilisée suppose connues les caractéristiques
des tâches afin de vérifier pour celles-ci l’existence d’un ordonnancement faisable. Dans le
contexte où les tâches peuvent changer leur vitesse pendant l’exécution, connaître les
caractéristiques des tâches revient à connaître pour chaque tâche le nombre de cycles
processeur concernés par chaque vitesse, afin de pouvoir calculer leurs durées d’exécution.
Ainsi, les éléments nécessaires étant connus (durées d’exécution et échéances des tâches), la
charge du processeur donnée par l’ensemble des tâches peut être calculée et la condition de
faisabilité vérifiée.
Dans le nouveau contexte de processeurs à vitesse variable, les deux résultats
de cette section ont mis en évidence une condition nécessaire et suffisante pour
l’ordonnancement des tâches périodiques, indépendantes, à échéance sur
requête, ainsi qu’un algorithme qui pourrait être utilisé pour
l’ordonnancement proprement dit. Par contre, pour pouvoir l’appliquer, la
partie importante et difficile d’un problème d’ordonnancement
monoprocesseur optimal de point de vue énergétique est de trouver les vitesses
optimales des tâches.
III.3.3. Formule générale pour une solution statique optimale
Les résultats de cette section complètent les résultats les plus importants obtenus par
Aydin et al. (Th. III.1’ et Prop. III.1’), en fournissant les formules qui correspondent aux
vitesses optimales des tâches pour des fonctions de puissance dissipée ayant la forme la plus
souvent utilisée dans des évaluations : g i ( S ) = ai S r , où ai > 0 et r ≥ 2 .
Lemme III.2 : Soit Tn={T1, T2,…, Tn} un ensemble de tâches temps réel indépendantes, avec
le même moment d’activation et la même échéance D. Si les fonctions de dissipation de
puissance g i sont exprimées par g i ( S ) = ai S r , où ai > 0 et r ≥ 2 , pour tout i = 1,K, n ,
alors il y a une solution optimale qui suppose une vitesse constante pour chaque évolution de
la tâche Ti , donnée par :
n
Si =
∑C
j
a
j =1
Da
73
1
r
i
1
r
j
.
Chapitre III
Optimisation de la consommation d’énergie
gi (S )
= ai S r −1 . La convexité des fonctions hi (voir l’Exemple 2
S
ci-dessus) assure, pour une solution optimale, une vitesse constante pour l’exécution de
chaque tâche.
Démonstration : Soit hi ( S ) =
Pour obtenir la formule donnée en énoncé, on procède par induction sur le nombre n
de tâches.
Cas n=2
On peut supposer que C1 + C 2 = D , ce qui peut être écrit comme
Soit x =
DS 2 − C 2 =
S1
> 0 , d’où
S2
C1 C 2
+
= D.
S1 S 2
⎞
C1 C 2
1 ⎛ C1
⎜
C
+
=
+
2 ⎟ et
⎟
xS 2 S 2 S 2 ⎜⎝ x
⎠
S 1 = xS 2 . On obtient D =
C1
C1
, donc x =
> 0.
x
DS 2 − C 2
L’énergie consommée s’exprime par :
E = C 1 h1 ( S 1 ) + C 2 h2 ( S 2 )
= C 1 a1 S1
r −1
+ C 2 a2 S 2
r −1
= C 1a1 ( xS 2 ) r −1 + C 2 a2 S 2
= S2
r −1
= S2
⎡
⎛
C1
⎢C 1 a1 ⎜
⎜
⎢
⎝ DS 2 − C 2
⎣
r −1
r
⎡
C1
⎢a1
⎢⎣ DS 2 − C 2
(
r −1
⎞
⎟
⎟
⎠
r −1
⎤
+ C 2 a2 ⎥
⎥
⎦
⎤
+ C 2 a2 ⎥ .
⎥⎦
)
r −1
Comme cette énergie est minimale, sa dérivée par rapport à S 2 est nulle.
E ' ( S 2 ) = (r − 1) S 2
= (r − 1) S 2
r −2
r −2
= (r − 1) S 2
r
⎡
C1
⎢a i
⎢⎣ DS 2 − C 2
(
r
⎡
C1
⎢a i
⎢⎣ DS 2 − C 2
r −2
(
)
r −1
r
⎤
− (r − 1)C 1 D
r −1
+ C 2 a 2 ⎥ + S 2 a1
r
⎥⎦
DS 2 − C 2
(
)
r −1
(
r −2
⎤
⎥
r
DS 2 − C 2 ⎥⎦
r
+ C 2 a 2 − S 2 a1
r
⎡
C1
⎢C 2 a 2 + a1
⎢⎣
DS 2 − C 2
= (r − 1) S 2
)
)
r
(DS
2
)
⎤
⎥.
r
⎥⎦
)
En imposant E ' ( S 2 ) = 0 et compte tenu que S 2 > 0 , on obtient :
74
)
⎤
− C 2 − DS 2 ⎥
⎥⎦
r
⎡
C1
C 2 ⎢a 2 − a1
⎢⎣
DS 2 − C 2
(
(
C1 D
Chapitre III
Optimisation de la consommation d’énergie
a 2 − a1
(DS
C1
2
r
−C2
=0
)
r
r
⎞
⎟ .
⎟
⎠
⎛
a
C1
⇔ 2 = ⎜⎜
a1 ⎝ DS 2 − C 2
Parce que DS 2 − C 2 > 0 (car x>0), on arrive à la solution unique comme suit :
⎛ a2
⎜⎜
⎝ a1
1
⎞r
C1
⎟⎟ =
DS 2 − C 2
⎠
⎛a
⇔ DS 2 − C 2 = C 1 ⎜⎜ 1
⎝ a2
1
⇔ S2 =
1
⎞r
⎟⎟
⎠
1
C 1 a1r + C 2 a 2r
Da
.
1
r
2
En changeant les notations entre les deux tâches, on obtient également la valeur de S1 , ainsi
finissant le cas n=2 :
S1 =
1
r
1 1
C a + C 2a
1
r
2
1
r
1
.
Da
Pas d’induction.
Supposons que les vitesses optimales de point de vue énergétique, pour exécuter un
ensemble de k tâches - ayant les propriétés données dans l’énoncé - sur un processeur, sont
données (i=1,…,k) par :
k
Si =
∑C
j
a
j =1
D' a
1
r
j
1
r
i
,
où D’ représente l’échéance commune pour ces tâches.
Supposons également que pour un ordonnancement optimal d’un ensemble de k+1
tâches, le temps d’exécution pour k d’entre eux est t, leur ordonnancement est optimal pour
cette échéance, et le temps d’exécution pour la tache k+1 est D-t, D étant l’échéance
C k +1
et,
commune des tâches. Par conséquent, la vitesse S k +1 est donnée par S k +1 =
D−t
conformément à l’hypothèse d’induction, les vitesses des k premières tâches sont données par
la formule suivante :
1
k
Si =
∑ C j a rj
j =1
ta
1
r
i
75
=
A
ta
1
r
i
,
Chapitre III
Optimisation de la consommation d’énergie
1
r
j
k
où on a introduit la notation A = ∑ C j a .
j =1
L’énergie consommée pour les k+1 tâches peut être exprimée par :
k +1
E k +1 = ∑ C i hi ( S i )
i =1
k +1
= ∑ C i ai S i
r −1
i =1
A r −1
k
= ∑ C i ai
i =1
t
r −1
⎛ 1r ⎞
⎜ ai ⎟
⎜ ⎟
⎝ ⎠
r −1
⎛ C k +1 ⎞
⎟
+ C k +1 a k +1 ⎜⎜
⎟
⎝ D −t ⎠
r −1
r
r −1
A r −1 k
C k +1
1−
= r −1 ∑ C i ai r + a k +1
t
( D − t ) r −1
i =1
r
= A r t − ( r −1) + a k +1 C k +1 ( D − t ) − ( r −1) .
La valeur minimale pour la consommation d’énergie s’obtient pour une valeur de t
pour laquelle E k′ +1 (t ) = 0 . Un calcul direct donne :
E k′ +1 (t ) = −(r − 1) A r t − r + (r − 1)a k +1 C k +1 ( D − t ) − r
r
[
]
r −1
r
a k +1 C k +1 t r − A r ( D − t ) r ,
r
t (D − t)
d’où E k′ +1 (t ) = 0 est équivalent à :
=
r
r
a k +1 C k +1 t r − A r ( D − t ) r = 0
r
r
a C k +1
⎛ D−t ⎞
.
⇔⎜
⎟ = k +1 r
A
⎝ t ⎠
Comme D − t > 0 , il existe une solution unique à l’équation ci-dessus, obtenue par la suite :
1 C
D −t
k +1
= a k +1 r
t
A
1
⇔ D − t = ta k +1 r
C k +1
,
A
qui revient à :
D
t=
1 + a k +1
C k +1
A
1
r
d’où :
t=
DA
k +1
∑C
j =1
76
j
aj
1
r
.
,
Chapitre III
Optimisation de la consommation d’énergie
En utilisant cette valeur dans les formules exprimant les vitesses en fonction de t, on
obtient, pour i=1,…,k :
k +1
A
Si =
a
⋅
1
r
i
1
∑C ja j r
j =1
DA
k +1
=
1
∑C ja j r
j =1
Da
,
1
r
i
et aussi :
S k +1 =
C k +1
1 C
k +1
ta k +1 r
A
k +1
A
=
a
1
r
k +1
⋅
∑C
j =1
ajr
DA
k +1
=
1
j
1
∑C
j
j =1
Da
ajr
1
r
k +1
.
Théorème III.5 : (Formule pour les vitesses optimales) Soit Tn={T1, T2,…, Tn} un ensemble
de n tâches périodiques indépendantes, prêtes à s’exécuter à l’instant t=0. Pour chaque tâche
Ti sont connus son échéance Di = Pi, son coût d’exécution pire cas C i , exprimé en cycles
processeur, et sa fonction de dissipation de puissance g i , donnée par g i ( S ) = ai S r , où
ai > 0 et r ≥ 2 , pour tout i = 1,K, n .
Alors, il existe un ordonnancement optimal pour Tn qui suppose une vitesse constante
pour chaque évolution de la tâche Ti, donnée par :
1
n
Cj r
a
∑
j
j =1 Pj
Si =
.
1
air
Démonstration : Le Théorème III.1’ assure l’existence d’un ordonnancement optimal qui
suppose une vitesse constante pour chaque évolution de la tâche Ti, pour i=1,…,n.
A partir de cet ensemble des tâches Tn, on construit un autre ensemble T’, où toutes les
tâches sont périodiques indépendantes, avec le même moment d’activation et la même
échéance P, par la procédure suivante : chaque tâche Ti de Tn engendre P Pi tâches de T’,
notées par Tij (pour j=1,…, P Pi ) ayant toutes les caractéristiques identiques à Ti sauf
l’échéance qui devient P au lieu de Pi.
77
Chapitre III
Optimisation de la consommation d’énergie
Pour les tâches de T’, on peut appliquer le Lemme III.2, pour chaque durée P entre
l’activation des tâches et leur échéance. On obtient ainsi les vitesses optimales :
n
P
Pk
1
∑∑ C k a kr
S ij =
k =1 l =1
Pa
1
r
i
1
n
=
P
C k a kr
∑
k =1 Pk
1
Pair
1
n
=
Ck r
ak
∑
k =1 Pk
a
1
r
i
.
Il reste à prouver que ces vitesses assurent également la faisabilité de l’ensemble des
tâches Tn. Pour cela, il suffit d’observer que l’utilisation du processeur est égale à 1 (Th.
III.4) :
n
n
Ci
Ci
=
∑
∑
i =1 Pi
i =1 Pi S i
n
=∑
i =1
Ci
⋅
Pi
Pa
r
P∑
k =1
n
1
=
Cka
∑
Pk
k =1
r
1
r
k
∑
i =1
1
r
i
1
1
C k a kr
Pk
1
r
i
Cia
= 1.
Pi
L’exemple suivant montre l’application de ce théorème pour un ensemble concret de
tâches.
Exemple : Soit T 3={T1, T2, T3} un ensemble de 3 tâches périodiques indépendantes à
échéance sur requête et prêtes à s’exécuter à l’instant t=0, de sorte que P1 = 1 et P2 = P3 = 2.
Leurs coûts d’exécution pire cas exprimés en cycles processeur, C i , sont tous égaux à 6, et
leurs fonctions de dissipation de puissance g i sont données par : g1 ( S ) = S 3 , g 2 ( S ) = 8S 3 et
g 3 ( S ) = 27 S 3 .
Le Théorème III.5 assure l’existence d’un ordonnancement optimal monoprocesseur
et, en appliquant les formules du théorème pour le calcul des vitesses, on obtient les vitesses
optimales suivantes : S1 = 21 , S 2 = 10,5 et S 3 = 7 , d’où les temps d’exécution : C1 = 2 7 ,
78
Chapitre III
Optimisation de la consommation d’énergie
C 2 = 4 7 et C 3 = 6 7 . Notons que la charge processeur est 1. La Figure III.5 indique un
ordonnancement optimal pour l’ensemble de tâches donné qui correspond à ces vitesses
d’exécution, différentes selon les tâches mais constantes pour toutes les itérations d’une tâche.
Cet ordonnancement est obtenu en appliquant l’algorithme EDF.
Figure III.5. Exemple d’ordonnancement optimal à des vitesses différentes.
Dans cette section on obtient (Th. III.5) les formules pour les vitesses
optimales d’exécution d’un ensemble de tâches périodiques indépendantes,
prêtes à s’exécuter à l’instant t=0, à échéances sur requêtes, dont les fonctions
de dissipation de puissance sont données par g i ( S ) = ai S r . Ces formules
engendrent rapidement un algorithme de complexité O(n) pour ce calcul.
Notons que, jusqu’à présent, il n’y avait (voir §III.2.3.2) qu’un algorithme de
complexité O(n2logn) pour déterminer ces vitesses, par une méthode
d’approximation successive [AYD 01b], et une formule (Prop. III.1’) pour le
cas particulier des tâches ayant la même puissance dissipée [AYD 01c].
III.4. Contribution : le problème d’optimisation pour plate-forme
multiprocesseur
Dans cette section nous présentons notre apport à la théorie de la minimisation de la
consommation d’énergie dans un système déterministe embarqué multiprocesseur. Dans un
premier temps (§III.4.1) nous mettons en évidence tous les aspects théoriques impliqués dans
une estimation de la consommation d’énergie. Ceci permet de mettre en évidence les
différences, du point de vue de la consommation énergétique, qu’une plate-forme
multiprocesseur implique par rapport au cas monoprocesseur et de redéfinir ainsi le problème.
Nous parlons aussi des implications de l’algorithme d’ordonnancement sur la consommation
d’énergie (§III.4.2). Ensuite (§III.4.3), nous mettons à jour les notions et les notations pour
processeurs à vitesses variables, ce qui conduit à fournir quelques premiers résultats
concernant la faisabilité d’ordonnancement (§III.4.4) et, respectivement, la consommation
d’énergie (§III.4.5), pour le nouveau type de problème.
III.4.1. Plate-forme multiprocesseur dans l’optimisation de l’énergie
L’étude qui suit est basée sur les hypothèses suivantes concernant l’exécution des
tâches sur une plate-forme multiprocesseur à mémoire commune :
79
Chapitre III
Optimisation de la consommation d’énergie
•
l’exécution de la tâche n’est pas associée à un processeur déterminé et, aux
activations (retour de préemption) différentes de la même tâche, son exécution
peut se poursuivre sur n’importe quel processeur ;
•
à tout instant une tâche ne peut s’exécuter que sur un seul processeur.
La structure du système multiprocesseur que nous prenons en compte pour cette étude
est adaptée aux restrictions présentées dans §III.2.3 : nous utilisons une plate-forme
multiprocesseur hétérogène, dans le sens où la valeur de la vitesse de chaque processeur est
bornée inférieurement par une valeur minimale S MIN qui assure le fonctionnement du système
et supérieurement par la valeur maximale S MAX admise par le système ; aucune autre
contrainte n’est imposée en préalable sur la vitesse de chaque processeur (conformément au
Chapitre II, ces conditions correspondent à une machine parallèle sans relation entre le
processeur et la tâche qui lui est affectée). Pour des raisons de synchronisation dans la
communication entre les processeurs, une deuxième condition sur les vitesses des processeurs
doit être respectée : le fonctionnement des processeurs est basé sur une horloge commune,
utilisée comme « base de temps absolu » ; par la suite, l’horloge propre de chaque processeur
est ajustée au multiple ou diviseur de l’horloge commune.
Nous ajoutons une hypothèse supplémentaire à celles déjà existantes (§III.2.3.2) dans
les autres études sur l’optimisation de la consommation d’énergie :
Sachant que le changement de la vitesse du processeur peut se faire pendant la
commutation du contexte, la vitesse d’exécution d’une tâche pourrait donc
changer à chaque nouvelle attribution du processeur, c’est-à-dire au retour de
chaque préemption.
Aussi, une nouvelle situation doit être prise en compte :
Des ordonnancements faisables d’un même ensemble de tâches sur des
machines multiprocesseur peuvent conduire à des consommations d’énergie
optimales différentes, compte tenu du nombre de processeurs. Il faut donc
trouver non seulement l’ordonnancement adéquat, mais également le nombre
de processeurs qui donne la consommation énergétique minimale parmi les
consommations optimales du même ensemble de tâches.
Par la suite, nous formulons ainsi le :
Problème d’optimisation de la consommation d’énergie au niveau du processeur, pour
l’exécution d’un ensemble de tâches :
Soit Tn={T1, T2, …, Tn} un ensemble de n tâches temps réel. Pour une
minimisation de la consommation d’énergie sur l’exécution de l’ensemble
des tâches Tn il faut déterminer :
•
le nombre m de processeurs et
•
les vitesses d’exécution des tâches à tout moment de leur exécution (au
retour de chaque préemption),
tout en assurant la faisabilité d’ordonnancement.
80
Chapitre III
Optimisation de la consommation d’énergie
III.4.2. Coût de l’ordonnancement. Implications sur la consommation d’énergie
Pour un ensemble de tâches temps réel, tenant compte de paramètres connus a priori,
un ordonnancement hors-ligne pourrait être trouvé ou non. Si le comportement du système
peut être décrit complètement par un ordonnancement faisable hors-ligne, alors le scénario
des tâches est connu a priori et pour l’exécution des tâches il ne sera plus nécessaire de lancer
un calcul d’ordonnancement pour allouer le processeur systématiquement aux tâches ; il
suffira d’implanter l’ordre d’exécution des tâches et de les exécuter en conséquence. Nous
pouvons citer, à titre d’exemple, le cas des tâches périodiques indépendantes.
Par contre, si l’ordonnancement ne peut être fait qu’en ligne, il faut considérer que
l’algorithme d’ordonnancement demande un temps de calcul à chaque invocation. Nous
appellerons coût d’ordonnanceur le coût de l’algorithme d’ordonnancement : le nombre de
cycles d’horloge qu’il lui faut, une fois appelé, pour choisir la tâche suivante à exécuter. Dans
toute étude théorique sur le déterminisme des applications temps réel qui nécessite
l’activation d’un ordonnanceur, le coût d’ordonnancement doit être pris en compte dans les
estimations pire cas des coûts des tâches qui composent le système. Nous appellerons
consommation de l’ordonnanceur la consommation de l’énergie due à l’exécution de
l’algorithme d’ordonnancement. Elle est liée au coût de l’ordonnanceur et à la vitesse « en
cours » du processeur.
La part due au coût de l’ordonnancement devient non négligeable dans le calcul global
de la consommation d’énergie pour l’exécution d’un ensemble de tâches. Nous appellerons
consommation due à l’ordonnancement la consommation d’énergie due aux exécutions de
l’ordonnanceur sur toute la durée de temps nécessaire pour la faisabilité d’ordonnancement
sur l’ensemble des tâches. Cette consommation est donnée par la relation :
Cdo = Co ∗ nao
où :
Cdo – consommation due à l’ordonnancement,
Co – consommation de l’ordonnanceur,
nao – nombre d’activations de l’ordonnanceur.
Avec les problèmes soulevés, pour une estimation de la consommation réelle due à
l’ordonnancement on doit évaluer :
•
le coût de tout ordonnanceur et sa dépendance sur le nombre de tâches actives dans
le système (coût constant ou variable, selon l’algorithme et l’implantation, étude
pour trouver les structures de données appropriées pour chaque cas) ;
•
le nombre d’activations de l’ordonnanceur, compte tenu du fait qu’il s’active
seulement à l’activation d’une tâche.
Des conséquences importantes s’imposent de ces faits :
•
la nécessité d’avoir une synchronisation entre les horloges des processeurs ;
•
la possibilité de gérer les appels de l’ordonnanceur avant la fin de son exécution
sur un autre processeur ;
•
revoir les notions concernant le critère d’ordonnancement et les adapter au cas
multiprocesseur à vitesses variables (ex. l’évaluation des laxités des tâches au
moment du dispatching d’une tâche, moment d’activation de l’ordonnanceur).
81
Chapitre III
Optimisation de la consommation d’énergie
Une étude comparative sur la consommation énergétique des principaux algorithmes
d’ordonnancement connus reste à faire. Dans ce contexte, un autre aspect à étudier pour
raffiner l’estimation du coût réel de l’ordonnanceur, pour une machine multiprocesseur,
représente le nombre de migrations des tâches d’un processeur à l’autre ainsi que leurs coûts
temporels.
Dans la présente étude, nous ne prenons pas en compte les coûts induits par
l’ordonnanceur et par la migration des tâches. Cela représente une première approche et un
premier modèle pour les idées qui seront présentées par la suite. Notons que d’autres études
théoriques menées sur les machines multiprocesseur ignorent, elles aussi, ces coûts ([WEI
94], [YAO 95], [GOV 95], [HON 98], [AYD 01c], [AYD 01b], [MEL 02], [ZHU 01]). Il est
évident que les résultats seront des approximations pour les cas réels, et que ces coûts doivent
être pris en compte au moins dans l’applicabilité des résultats sur chaque cas particulier.
III.4.3. Mise à jour des notions pour processeurs à vitesse variable
Dans cette section, nous présentons les notions et les notations qui seront utilisées par
la suite. Nous reprenons les notations utilisées habituellement dans la théorie
d’ordonnancement en prenant en compte les notions sur lesquelles notre étude est basée en
introduisant les notations correspondantes : les coûts d’exécution des tâches exprimés en
cycles processeur, les vitesses des processeurs durant l’exécution des tâches, le nombre de
préemption des tâches. Un exemple est également donné dans la Figure III.6 pour illustrer
toutes ces notations.
Soit Tn={T1, T2,…, Tn} un ensemble de n tâches prêtes à s’exécuter à l’instant t=0.
Chaque tâche Ti est caractérisée par plusieurs paramètres interdépendants :
Ci : le coût, en cycles processeur, engendré par l’exécution pire-cas de la tâche Ti ;
cette valeur ne dépend pas de la vitesse du processeur ;
Ci : la durée d’exécution pire-cas de la tâche Ti ; ce paramètre dépend de la vitesse du
processeur aux différents instants de l’exécution de la tâche ;
La durée d’exécution de la tâche Ti à vitesse constante Si est donnée par :
C
Ci = i ;
Si
Pi : la périodicité de la tâche Ti ;
Di : l’échéance pour l’invocation courante de la tâche Ti .
Soient :
P=ppmc(P1,P2,…,Pn), le plus petit multiple commun des périodes des tâches.
Tij : la jème invocation de la tâche Ti ; où i = 1, K , n et j = 1,K, P Pi .
Kij : le nombre de dispatchings (commutations de contexte) survenus pendant
l’exécution de la tâche Tij. Pour tout i = 1, K , n et j = 1,K, P Pi on a :
K ij ≥ 1 .
82
Chapitre III
Optimisation de la consommation d’énergie
Ki : le nombre maximal de dispatchings pouvant intervenir durant l’exécution de la
tâche Ti ; le nombre d’instructions machine atomiques qui composent la tâche Ti (la valeur
dépend de la machine et du compilateur utilisé). Pour tout i = 1, K , n et j = 1,K, P Pi , on
obtient :
max K ij ≤ K i .
j
Tijk : l’activation k de la tâche Tij ; pour tout i = 1, K , n et j = 1,K, P Pi .
Cijk : le nombre de cycles processeur pour l’activation k de la tâche Tij. La relation
entre Cijk et Ci est donnée par l’égalité :
K ij
∑C
k =1
ijk
= Ci ,
pour tout i = 1,K, n et pour tout j = 1,K , P Pi .
Sijk : la vitesse de la kème activation de la tâche Tij.
Cijk : la durée d’exécution de la kème activation de la tâche Tij, soit :
C ijk
C ijk =
.
S ijk
Par conséquent :
K ij
C ijk
k =1
S ijk
Ci = ∑
est la durée d’exécution de la j
ème
itération de la tâche Ti .
Figure III.6. Illustration des notations.
S : la vitesse de fonctionnement du processeur à un certain moment, exprimée en
cycles processeur par seconde.
S MIN : la vitesse minimale du processeur qui assure le fonctionnement du système.
S MAX : la vitesse maximale que le processeur peut atteindre.
Lij (t ) : la laxité (§II.3.2.2) de la tâche Ti dans sa jème itération, au moment t, le
moment de son dispatching kij (t ) est exprimée par :
kij (t )
Lij (t ) = Di − ∑
k =1
83
C ijk
S ijk
,
Chapitre III
Optimisation de la consommation d’énergie
où k ij (t ) représente le nombre d’activations de la tâche Tij jusqu’au moment t ; donc :
1 ≤ k ij (t ) ≤ K ij .
gi (S ) : la puissance dissipée par le processeur pour l’exécution de la tâche Ti à la
vitesse S.
Compte tenu des remarques faites dans §III.2.2 sur la forme de cette fonction
présentée dans différents travaux et des observations faites dans §III.2.1, nous considérons,
pour l’ensemble des résultats présentés par la suite, les propriétés suivantes sur la puissance
dissipée :
gi (S ) - fonction convexe croissante stricte ;
hi (S ) = g i (S ) S - fonction convexe croissante stricte.
Toute autre condition sera spécifiée au moment où elle s’avèrera nécessaire.
La consommation d’énergie durant la période [t1 ,t2 ] correspondante à l’exécution de la
tâche Ti pendant cette période est donnée par la formule :
(
t2
) ∫ g (S (t )) dt .
E i t1 , t 2 =
i
t1
L’utilisation totale du (des) processeur(s) par l’ensemble de tâches Tn s’exprime par :
U tot
C
=∑ i =
i =1 Pi
n
n
1
∑P
ji ;i =1 i
K
ij i
C ij k
∑S
k =1
i
.
iji k
Notons que la charge du processeur, ou son utilisation totale, étant dépendante des
temps d’exécution des tâches, et implicitement des vitesses des tâches, pourrait prendre des
valeurs différentes selon les itérations des tâches prises en compte.
III.4.4. Premiers résultats sur la faisabilité d’ordonnancement des tâches
indépendantes
Nous présentons ci-dessous quelques constats sur le nombre de processeurs et sur les
vitesses des différentes parties des tâches pour un ordonnancement faisable d’un ensemble de
tâches indépendantes.
Il faut remarquer ici que les résultats théoriques actuels sur l’ordonnancement ont pour
base l’idée de trouver des conditions de faisabilité pour l’ordonnancement des différents
modèles de tâches sur un nombre défini de processeurs, donc une machine donnée a priori.
Autrement dit, étant données une machine (uni ou multiprocesseur) et un ensemble de tâches,
on cherche si celui-ci est ordonnançable par cette machine.
Dans le contexte d’une machine à nombre défini de processeurs, les résultats les plus
importants pour le modèle de tâches indépendantes ont été présentés dans le Chapitre II. Il
s’agit d’une condition nécessaire et suffisante pour la faisabilité d’ordonnancement
monoprocesseur d’un ensemble de tâches périodiques, indépendantes, à échéance sur requête
(Th. II.6), d’une condition nécessaire et, respectivement d’une condition suffisante, pour
l’ordonnancement monoprocesseur des tâches périodiques indépendantes (Th. II.5), d’une
condition nécessaire (Th. II.20) et d’une condition suffisante (Th. II.21) sur l’ordonnancement
84
Chapitre III
Optimisation de la consommation d’énergie
multiprocesseur d’un ensemble de tâches périodiques, indépendantes, à échéance sur requête,
ainsi qu’une condition nécessaire d’ordonnançabilité sur m processeurs identiques, d’un
ensemble de tâches indépendantes avec le même moment d’activation (Th. II.21) et des
informations sur les connaissances nécessaires pour l’ensemble de tâches (Th. II.19) afin de
pouvoir simplifier le problème d’ordonnancement et de permettre a priori de faire des
appréciations sur la faisabilité. Notons qu’à ce jour on ne connaît pas de condition nécessaire
et suffisante pour la faisabilité d’un ensemble de tâches indépendantes pour une machine
multiprocesseur donnée.
Le fait de ne pas fixer a priori le nombre de processeurs à utiliser pour
l’ordonnancement d’un ensemble de tâches donné nous permet de compléter ces résultats par
une condition nécessaire et suffisante sur l’ordonnancement d’un ensemble de tâches
indépendantes. Quelques appréciations sur la faisabilité d’ordonnancements au changement
du nombre des processeurs seront aussi indiquées. Ces remarques s’avèreront très importantes
dans le développement des notions présentées dans ce chapitre sur l’optimisation de la
consommation d’énergie, basées sur la même idée, de trouver la machine (i.e. le nombre de
processeurs) qui répond au mieux à l’ensemble de tâches pour la consommation d’énergie
associée.
Théorème III.6 : (condition nécessaire et suffisante pour la faisabilité d’un ensemble de tâches
indépendantes et synchrones) : Soit Tn={T1, T2,…, Tn} un ensemble de tâches indépendantes,
prêtes à s’exécuter à l’instant t=0. Pour chaque tâche Ti sont connus son échéance Di et son
coût d’exécution pire cas C i , exprimé en cycles processeur. Il existe un ordonnancement
faisable de l’ensemble de tâche Tn si et seulement si
)
(
max C i Di ≤ S MAX ,
i =1,K, n
où S MAX représente la vitesse maximale qui peut être prise par le processeur considéré pour
l’estimation des coûts des tâches.
Démonstration : « Nécessité » : Supposons l’existence d’un processeur pour lequel la vitesse
(
)
maximale qu’il peut atteindre, S MAX , satisfait la condition max C i Di ≤ S MAX . Soit une
i =1,K, n
machine à n processeurs, ayant chaque processeur dédié à l’exécution d’une tâche. Comme
pour toute tâche Ti l’inégalité C i Di ≤ S MAX est vraie, on obtient : C i S MAX ≤ Di .
Autrement dit, si le processeur dédié à la tâche Ti exécute celle-ci avec la vitesse S MAX , alors
l’échéance de cette tâche sera respectée. Par conséquent, les échéances de toutes les tâches
seront respectées, donc il y a un ordonnancement faisable pour l’ensemble des tâches, celui
donné par une machine à n processeurs identiques qui exécutent, chacun d’entre eux, une
tâche, avec la vitesse S MAX .
« Suffisance » : Supposons la faisabilité de l’ensemble des tâches. Cela revient à dire qu’il y a
une machine, éventuellement multiprocesseur, dont les vitesses des processeurs sont
suffisamment élevées pour que l’échéance de chaque tâche soit respectée. Supposons que,
suite à des préemptions, l’exécution complète de la tâche Ti se fasse en k parties,
éventuellement sur des processeurs différents, chaque partie étant représentée par un nombre
85
Chapitre III
Optimisation de la consommation d’énergie
de C ik cycles processeur. Soit S iMAX la vitesse maximale parmi les vitesses des processeurs
qui correspondent à l’exécution de chaque partie de la tâche, S iMAX ≤ S MAX . Si toutes les
parties qui composent la tâche étaient exécutées avec cette vitesse, S iMAX , alors l’exécution de
la tâche finirait plus tôt, avec une durée donnée par : τ i = C i S iMAX ≤ Di . On peut écrire
maintenant les inégalités suivantes :
Ci Ci
≤
= S iMAX ≤ S MAX .
τi
Di
En conséquence, pour toute tâche Ti, l’inégalité C i Di ≤ S MAX est vraie, d’où :
(
)
max C i Di ≤ S MAX . ■
i =1,K, n
Corollaire III.3 : Soit Tn={T1, T2… Tn} un ensemble de n tâches indépendantes, prêtes à
s’exécuter à l’instant t=0 ; pour chaque tâche Ti sont connus son échéance Di et son coût
d’exécution pire cas C i , exprimé en cycles processeur. S’il y a un ordonnancement faisable
pour l’ensemble des tâches, alors il y a un ordonnancement faisable pour l’ensemble des
tâches sur une machine à n processeurs.
Démonstration : S’il y a un ordonnancement faisable de l’ensemble des tâches, alors (Th.
(
)
III.6) max C i Di ≤ S MAX , où S MAX représente la vitesse maximale que le processeur
i =1,K, n
considéré pour l’estimation des coûts des tâches peut prendre. Comme dans la démonstration
du Théorème III.6, soit une machine à n processeurs, chacun exécutant une tâche avec la
vitesse S MAX . La condition mentionnée assure le respect de toutes les échéances, d’où la
faisabilité de cet ordonnancement. ■
Le résultat suivant surmonte une difficulté induite dans la théorie de l’ordonnancement
multiprocesseur par l’utilisation des vitesses variables : la synchronisation entre les
processeurs. La nécessité de cette synchronisation est mise en évidence clairement par les
ordonnancements en ligne.
Pour simplifier les ordonnancements hors-ligne, il est suffisant de considérer des
synchronisations entre les processeurs à l’activation de chaque tâche, seulement dans le
sens suivant : le début d’une tâche impose le début d’un cycle sur chaque processeur. Les
retards induits peuvent être considérés pris en compte dans les estimations pire cas de la durée
d’exécution des tâches. Dans la proposition suivante, cette synchronisation est considérée
implicite.
Proposition III.2 : Soit une machine à m processeurs identiques et un ensemble de n tâches
temps réel indépendantes périodiques et m<n. S’il existe un ordonnancement faisable de
l’ensemble des tâches sur ces m processeurs, alors il existe un ordonnancement faisable où m
tâches ont chacune d’entre elles un processeur dédié.
86
Chapitre III
Optimisation de la consommation d’énergie
Démonstration : Selon l’ordonnancement faisable existant, les différentes parties des tâches,
avec différentes vitesses d’exécution associées, sont distribuées sur les m processeurs, tout en
assurant le respect de leurs échéances. Soit Ti , 1 ≤ i1 ≤ n , une des tâches pour laquelle au
1
moins une partie s’exécute sur le premier processeur, et soit Ti
1
une partie de la même tâche
j
qui s’exécute, à un moment donné, sur le processeur p, 1 < p ≤ m . Il est évident que, pendant
l’exécution de cette partie de tâche, aucune autre partie de la même tâche ne s’exécute sur le
premier processeur et ni sur un autre, ce qui pourrait permettre l’exécution de cette partie Ti j
1
par celui-ci, s’il n’exécutait pas une autre tâche. Si c’est le cas, une migration des parties de
tâches peut se produire. Sinon, plusieurs situations peuvent apparaître. Notons avec C i j la
1
durée d’exécution de Ti j selon l’ordonnancement considéré.
1
Cas I : Durant C i
1
j
le processeur 1 exécute la partie Ti k de la tâche Ti , 1 ≤ i2 ≤ n, i1 ≠ i2 , qui
2
2
commence au même instant et qui prend la même durée.
La solution consiste à inverser l’emplacement d’exécution de ces deux parties de
tâches, Ti j et Ti j , comme l’indique la figure ci-dessous. La situation est la même si
1
2
plusieurs parties de tâches s’exécutent sur le premier processeur strictement dans l’intervalle
d’exécution de Ti j ou dans une partie inférieure à celle-ci, dans le reste le processeur tournant
2
à vide. Un déplacement de toutes ces parties sur le processeur p, tout en gardant le moment
d’activation de chacune, sera envisagé à la place de Ti j qui s’exécutera sur le processeur 1.
1
Figure III.7. Ti
1
j
et Ti k parties des deux tâches différentes, synchrones, avec C i
2
1
j
= Ci k ,
2
exécutées par deux processeurs différents.
Cas II : Au moment t ia j d’activation de Ti j , ou/et au moment t i f j de fin d’exécution de Ti j ,
1
1
1
1
la partie Ti j de la tâche Ti , 1 ≤ i2 ≤ n, i1 ≠ i2 est en train de s’exécuter sur le processeur 1.
2
2
Alors, en coupant Ti
2
j
aux moments t ia j et t i f j , avec la partie qui s’exécute entre ces
1
1
deux bornes on peut faire le même raisonnement que dans le premier cas. Il faut remarquer
que si, par exemple, la partie Ti j ne peut pas être coupée juste au moment t ia j suite au fait
1
2
qu’un cycle processeur ne s’est pas fini, alors l’interruption sera faite dès que possible et la
commutation entre les deux tâches changera aussi leurs vitesses d’exécution afin d’assurer la
87
Chapitre III
Optimisation de la consommation d’énergie
fin de chacune au même moment que dans le premier cas.
Ainsi de même si plusieurs parties de tâches différentes sont concernées par
l’exécution sur le processeur 1 dans ce même intervalle, comme l’indique la figure ci-dessous.
Figure III.8. Durant C i
1
j
d’autres tâches asynchrones par rapport à Ti
1
j
s’exécutent sur le premier processeur.
De cette manière, toutes les parties qui composent la tâche Ti pourront être exécutées
1
par le premier processeur. Avec le même raisonnement, les autres processeurs pourront
exécuter en intégralité une tâche chacun. ■
Note : Observons que le procédé décrit dans la proposition précédente (Prop. III.2) permet
d’assigner les tâches aux processeurs, mais seulement pour un nombre de tâches égal au nombre
de processeurs. Il peut s’avérer qu’en fonction de la configuration des tâches, il est possible
d’exister au moins une tâche qui doive s’exécuter sur au moins deux processeurs, comme le
montre la figure ci-dessous.
Figure III.9. Les tâches ne peuvent pas être assignées chacune à un processeur, sauf certains cas.
En élargissant le cadre de la théorie sur la faisabilité de l’ordonnancement,
cette section propose une condition nécessaire et suffisante de faisabilité d’un
ensemble de tâches indépendantes avec le même moment initial d’activation.
Ensuite il est mentionné un constat sur l’ordonnancement faisable
multiprocesseur qui permet de supposer que, dans certains cas, il y a un
nombre de tâches au moins égal au nombre de processeurs, qui sont chacune
attribuée à un processeur.
88
Chapitre III
Optimisation de la consommation d’énergie
III.4.5. Premiers résultats sur la consommation d’énergie
Nous présentons ci-dessous quelques constats sur le nombre de processeurs et sur les
vitesses des différentes parties des tâches pour un ordonnancement optimal d’un ensemble de
tâches périodiques indépendantes. Ces résultats sont également basés sur la faisabilité
d’ordonnancement des tâches indépendantes, présentés précédemment.
Revenons avec quelques remarques sur la définition d’un ordonnancement faisable et
optimal de point de vue énergétique, donnée dans la section §III.2.2 : « un ordonnancement
faisable est dit optimal de point de vue énergétique si la consommation d’énergie au niveau
du/des processeur(s) due à l’exécution des tâches ainsi ordonnancées est minimale par
rapport à la consommation due à d’autres ordonnancements ». Il faut remarquer tout d’abord
que cette définition fait référence à une machine à nombre fixé de processeurs dont les
caractéristiques sont connues. Aussi, il faut remarquer que, dans le contexte des processeurs à
vitesses variables, la différence entre deux ordonnancements faisables et optimaux peut être
donnée autant par l’ordre d’exécution de différentes parties des tâches que par leur vitesse
d’exécution. Comme il a été remarqué (§III.4.1), à nombre différent de processeurs, la
consommation optimale d’énergie peut être différente. On définit alors l’ordonnancement
global optimal l’ordonnancement pour lequel la consommation d’énergie associée est
minimale par rapport à tous les ordonnancements optimaux du même ensemble de tâches.
Le résultat donné par le théorème suivant, bien que très important et intuitif, nécessite
une démonstration.
Théorème III.7 (existence d’un ordonnancement global optimal) : Soit Tn={T1, T2, …, Tn} un
ensemble de n tâches périodiques indépendantes, prêtes à s’exécuter à l’instant t=0. S’il
existe un ordonnancement faisable pour l’ensemble de tâches donné, alors il existe un
ordonnancement global optimal.
Démonstration : La différence entre deux ordonnancements faisables du même ensemble de
tâches, réalisés sur la même machine, est donnée par l’ordre d’exécution des tâches ou, plus
précisément, des parties des tâches, sur les différents processeurs de la machine utilisée. Mais,
d’une part, chaque tâche n’a qu’un nombre fini de parties et, d’autre part, le nombre de
processeurs d’une machine réelle est fini. Par conséquent, le nombre d’ordonnancements est
fini (1). Si l’on considère que la vitesse des processeurs peut varier en prenant toute valeur de
l’intervalle S MIN , S MAX , compte tenu du fait que la consommation d’énergie est une fonction
croissante en vitesse, pour chacun des ordonnancements il existe un ordonnancement minimal
(2). Les affirmations (1) et (2) permettent de conclure que, parmi les ordonnancements
faisables, il en existe au moins un qui soit global optimal. ■
[
]
Proposition III.3 : Soit une machine à m processeurs identiques. S’il existe un
ordonnancement optimal pour un ensemble de n tâches temps réel périodiques indépendantes
sur ces m processeurs, il y en aura aussi un sur une machine équivalente avec m+1
processeurs, et la valeur optimale de l’énergie consommée sera bornée supérieurement par la
valeur optimale de l’énergie obtenue pour m processeurs, Em , à laquelle s’ajoute la
consommation minimale ( e ) d’un processeur qui « tourne à vide » ( tâche de fond) :
E m +1 ≤ E m + e .
89
Chapitre III
Optimisation de la consommation d’énergie
Démonstration : Sur les m+1 processeurs il y a au moins un ordonnancement faisable, celui
qui a été trouvé pour les m processeurs et le nouveau processeur « tourne à vide ». Par la
suite, la valeur optimale de l’énergie consommée par les m+1 processeurs sera bornée
supérieurement par la valeur optimale de l’énergie obtenue pour m processeurs, Em , à qui
s’ajoute la consommation minimale ( e ) d’un processeur qui « tourne à vide » :
E m +1 ≤ E m + e . ■
Théorème III.8 : Soit une machine à m processeurs identiques et un ensemble de n (m<n)
tâches temps réel, périodiques indépendantes, à échéances sur requêtes, avec le même
moment d’activation, et pour tout i = 1,K , n , S MIN ≤ C i Di . S’il existe un ordonnancement
optimal sur les m processeurs, pour lequel il y a un processeur qui exécute entièrement deux
tâches, alors la valeur optimale de l’énergie consommée par m+1 processeurs est inférieure à
la valeur de l’énergie consommée pour l’ordonnancement des tâches sur les m processeurs.
Démonstration : Parce que dans l’ordonnancement optimal sur les m processeurs il y a un
processeur k qui exécute entièrement deux tâches, Ti et Tj, alors, étant donné que les tâches
sont à échéances sur requêtes, le temps d’exécution de chacune est inférieur à son échéance :
C i < Di et C j < D j .
Figure III.10. Le passage de m à m+1 processeurs, pour économiser l’énergie.
A partir de cet ordonnancement sur m processeurs, on définit un nouvel
ordonnancement sur m+1 processeurs comme suit :
Les autres processeurs, à part le processeur k, exécutent les tâches selon
l’ordonnancement précédent.
Une des tâches qui s’exécutaient sur le processeur k, disons Tj, s’exécute sur le
nouveau processeur, m+1, avec la vitesse C j D j ≥ S MIN , ce qui assure le respect
de son échéance.
Le processeur k exécute la tâche qui reste, Ti, avec une vitesse qui assure un temps
d’exécution qui doit respecter à la fois l’échéance de la tâche et la durée
d’exécution des deux tâches dans l’ordonnancement précèdent, donc, donné par
C i′ = min{Di , C i + C j } > C i .
L’énergie consommée par ce nouvel ordonnancement est donnée par :
( )
( )
( )
( )
Em+1 = Em − Em Ti + Em+1 Ti − Em T j + Em+1 T j ,
( ) et
où, par abus de notation, mais pour ne pas compliquer davantage les formules, Em Ti
( ) représentent les énergies consommées par l’exécution de la tâche T
Em T j
i
90
, respectivement
Chapitre III
Optimisation de la consommation d’énergie
( ) et
T j , dans l’ordonnancement sur m processeurs ; ainsi de même pour E m +1 Ti
( )
E m +1 T j .
On peut donc écrire :
⎛ Ci ⎞
⎛
⎞
⎛
⎞
⎛
⎞
⎟ + Ci h ⎜ Ci ⎟ − C jh ⎜ C j ⎟ + C jh ⎜ C j ⎟,
E m +1 = E m − C i hi ⎜
j
j
i
⎜ Ci ⎟
⎜ C i′ ⎟
⎜Cj ⎟
⎜ Dj ⎟
⎝
⎠
⎝
⎠
⎝
⎠
⎝
⎠
d’où, compte tenu de la croissance des fonctions hi et h j , et des inégalités mentionnées
auparavant ( C i′ > C i et C j > D j ), il est évident que :
E m +1 < E m . ■
Note : Ce théorème n’impose pas que l’ordonnancement sur m+1 processeurs soit réalisé par le
même algorithme que celui pour m processeurs, ni que les vitesses des tâches soient les mêmes
dans les deux cas (voir la note de §II.3.4.2 sur les anomalies de Richard).
Quelques résultats généraux sur l’optimalité globale de l’ordonnancement
d’un ensemble de tâches périodiques et indépendantes, ont été présentés :
l’existence d’un ordonnancement global optimal (Th. III.7), la variation
d’énergie au passage d’une machine à m processeurs vers une machine à m+1
processeurs (Prop. III.3), la diminution de la consommation énergétique d’un
ordonnancement optimal sur m+1 processeurs, parmi lesquels il existe un
processeur qui exécute entièrement au moins deux tâches, par rapport à
l’ordonnancement optimal sur m processeurs (Th. III.8). Ce sont les résultats
de base qui confirment l’approche de prendre en compte le nombre de
processeurs pour trouver l’ordonnancement global optimal. A partir de ce
point, des estimations plus précises seront déduites dans les sections suivantes
pour différents modèles de tâches.
III.5. Contribution : étude sur la configuration d’un système temps
réel embarqué afin de minimiser la consommation énergétique –
modèle des tâches périodiques et indépendantes
En continuation des résultats généraux sur l’optimalité de l’ordonnancement d’un
ensemble de tâches périodiques et indépendantes, nous prolongeons l’étude vers une solution
globale optimale (§III.5.1). Les deux solutions – statique (§III.5.2) et dynamique (§III.5.3) –
sont commentées.
III.5.1. Définition du problème
Le problème de toute instanciation du modèle des tâches périodiques indépendantes, à
échéances sur requêtes, est de trouver : le nombre de processeurs m et la vitesse S ijk de
91
Chapitre III
Optimisation de la consommation d’énergie
chaque tâche Ti à tout moment de son exécution, afin d’obtenir un ordonnancement faisable et
une minimisation de la consommation d’énergie durant la période P.
Notons que la condition d’optimisation globale de la consommation d’énergie est
donnée par la formule suivante et ne dépend pas du nombre de processeurs :
P
n
n
P
( )
Pi
Pi
n
K ij
( )
E min (P ) = min ∑ E i (P ) = min ∑∑ E i Pij = min ∑∑∑ E i Pijk ,
i =1
i =1 j =1
i =1 j =1 k =1
où Pijk représente la durée de temps comprise entre l’activation k et l’activation k+1 de la
tâche Tij. La vitesse d’exécution de la tâche Tij durant cet intervalle de temps est considérée
constante, S ijk , pour l’exécution des C ijk cycles processeur qui correspondent à cette
activation de la tâche Tij, et doit être déterminée, et 0 pour le reste de temps de cet intervalle
Pijk. Nous considérons donc que, si pendant cet intervalle la tâche se termine plus tôt, la
consommation d’énergie qui lui est associée est nulle pour le reste de l’intervalle. Cela se
traduit par :
( )
( ) ∫ g (S )dt = P
Ei Pijk = Ei Pijka =
i
a
ijk
ijk
( )
g i S ijk =
Pijka
( )
( )
C ijk
g i S ijk = C ijk hi S ijk ,
S ijk
où hi (S ) = g i (S ) S . En conséquence, la condition d’optimisation de la consommation
d’énergie peut être exprimée par :
P
n
Pi
K ij
( )
min ∑∑∑ C ijk hi S ijk .
i =1 j =1 k =1
III.5.2. Solution statique
Afin de trouver la solution statique au problème d’optimisation de la consommation
d’énergie au niveau du (des) processeur(s) d’un système embarqué, pour un ensemble de
tâches temps réel périodiques indépendantes, il faut déterminer :
•
le nombre de processeurs m,
•
le nombre d’activations Kij de chaque tâche Ti et pour chacune de ses itérations, et
•
Sijk , la vitesse de la tâche à chaque activation,
pour i=1,…,n, j=1,…, P Pi et k = 1,..., K ij , sous les contraintes suivantes :
n P Pi K ij
⎧
min
C ijk hi S ijk
⎪
∑∑∑
i =1 j =1 k =1
⎪
⎪⎪ n P Pi K ij
C
POW − OPT * ⎨∑∑∑ Pijka ≤ mP avec Pijka = ijk
S ijk
⎪ i =1 j =1 k =1
⎪0 < S MIN ≤ S ijk ≤ S MAX ,1 ≤ K ij ≤ K i
⎪
⎪⎩ Il existe un ordonnancement faisable avec m, K ij , S ijk ainsi determinés.
( )
{
92
}
(1*)
(2*)
(3*)
(4*)
Chapitre III
Optimisation de la consommation d’énergie
Nous pouvons envisager une approche par la décomposition du problème ainsi
formalisé en deux sous problèmes :
•
le problème de l’optimisation (OPT*) donné par (1*), (2*) et (3*) ;
•
la vérification de la faisabilité des solutions trouvées pour OPT*.
Cela s’avère très difficile, surtout à cause du fait que le nombre de processeurs est
aussi une variable à déterminer et que, pour un nombre fixe de processeurs, il n’existe pas de
condition nécessaire et suffisante pour la faisabilité de l’ordonnancement. Malgré cela des
solutions pour des cas particuliers peuvent être trouvées, et nous indiquons par la suite un
théorème qui donne un ordonnancement global optimal.
Théorème III.9 (ordonnancement global optimal) : Soient Tn={T1, T2,…, Tn} un ensemble de n
tâches périodiques, indépendantes, à échéances sous requêtes, prêtes à s’exécuter à l’instant
t=0, dont on connaît Pi=Di , C i et gi , et que pour chaque i=1,…,n, l’inégalité
S MIN ≤
Ci
≤ S MAX
Di
est satisfaite. Supposons également que les fonctions hi : [0,+∞[ → R , associées à chaque
fonction gi qui exprime la puissance dissipée, données par hi ( x ) = g i ( x ) x , sont convexes et
dérivables au deuxième ordre.
Alors, l’ordonnancement global optimal est assuré par une machine ayant un nombre
de processeurs égal au nombre de tâches, et la valeur de la consommation énergétique
optimale est donnée par :
n
⎛ Ci ⎞
⎟.
E min (P ) = P ∑ g i ⎜
⎟
⎜
i =1
⎝ Di ⎠
Démonstration : Parce que pour chaque i=1,…,n, l’inégalité C i Di ≤ S MAX est satisfaite,
conformément au Théorème III.6, il existe un ordonnancement faisable de l’ensemble des
tâches, donc (Cor. III.3) il existe un ordonnancement faisable sur une machine à n processeurs
et, conformément au Théorème III.7, il existe un ordonnancement global optimal.
Considérons l’ordonnancement des n tâches par n processeurs où, pour tout i=1,…,n,
le processeur i est dédié à l’exécution de la tâche Ti avec la vitesse C i Di , ce qui assure la
faisabilité de cet ordonnancement. Conformément au Théorème III.1’, cette vitesse assure la
consommation minimale pour l’exécution de cette tâche par un seul processeur, et cela pour
toutes les tâches de l’ensemble. Cela veut dire, d’une part, que ralentir la tâche davantage ne
garantira plus l’échéance et, d’autre part, que l’exécuter à une vitesse supérieure, ou à
différentes vitesses, engendrera une consommation plus élevé par la tâche. Ces affirmations
sont valables pour toutes les tâches de l’ensemble. Par conséquent, tout autre ordonnancement
ne peut engendrer qu’une consommation plus élevée, et donc l’ordonnancement proposé
constitue l’ordonnancement global optimal.
Alors, la consommation d’énergie associée à l’ordonnancement global optimal pour la
période P=ppmc( P1, P2 ,…, Pn) se calcule comme suit :
93
Chapitre III
Optimisation de la consommation d’énergie
P
n
( )
Pi
E min (P ) = ∑∑ Ei Pi
i =1 j =1
n
= P∑
i =1
n
= P∑
i =1
1
Pi
( )
1
Ei Pi
Pi
⎛ Ci
g
∫ i ⎜⎜ Di
Pi
⎝
n
⎛ Ci
= P∑ g i ⎜
⎜ Di
i =1
⎝
⎞
⎟dt
⎟
⎠
⎞
⎟.■
⎟
⎠
Note : Dans ce théorème il est important de remarquer le fait que : S MIN ≤ C i Di pour toute
tâche Ti. Ceci restreint le modèle de tâches périodiques, indépendantes, à échéances sur requêtes,
mais la classe reste encore assez large, surtout pour les processeurs avec S MIN suffisamment petit.
D’autre part, cette condition assure que la solution globale optimale ne peut pas être
obtenue que par une machine ayant le nombre de processeurs égal au nombre de tâches. Sans
cette condition, il peut s’avérer qu’une solution sur un nombre inférieur de processeurs puisse
conduire à la même consommation que la solution globale optimale.
III.5.3. Solution dynamique
Pour la solution dynamique du problème d’optimisation d’énergie multiprocesseur on
garde le même principe que celui utilisé dans le cas monoprocesseur : une fois qu’une tâche
s’achève plus tôt, l’exécution de la tâche suivante sera ralentie. Ce qui ne signifie pas que
cette tâche commencera plus tôt son exécution, comme il était proposé dans [AYD 01c] (voir
§III.2.3.3). En effet, la solution statique globale optimale (Th. III.9) suppose que chaque
processeur est dédié à l’exécution d’une seule tâche. Pour cela, et compte tenu de
l’indépendance des tâches, l’achèvement anticipé d’une tâche permet une nouvelle estimation
de sa vitesse d’exécution pour l’itération suivante.
Nous avons démontré (Th. III.9) que, sous certaines conditions, la
configuration optimale – du point de vue énergétique – pour l’exécution d’un
ensemble de n tâches périodiques indépendantes, est une plate-forme à n
processeurs ; la consommation de cette plate-forme a été également donnée.
Pour compenser l’effet pire cas, on a proposé un mécanisme d’estimation en
ligne pour le coût réel de chaque tâche.
94
Chapitre III
Optimisation de la consommation d’énergie
III.6. Contribution : étude sur la configuration d’un système temps
réel embarqué afin de minimiser la consommation énergétique –
modèle des tâches périodiques, indépendantes, avec la même
fonction de puissance dissipée
La solution globale optimale trouvée dans la section précédente pour un ensemble de
tâches périodiques et indépendantes, pourrait s’avérer, dans certains cas, insatisfaisante pour
le concepteur du système : nombre trop élevé de processeurs nécessaires, non respect de la
condition imposée dans l’énoncé du théorème qui donne l’ordonnancement global optimal.
Dans ces conditions, des estimations sur le gain d’énergie au passage de m à m +1 processeurs
s’imposent. Cette section prolonge dans cette direction l’étude sur le modèle des tâches
périodiques et indépendantes, en fournissant une condition d’optimalité (§III.6.1) et des
estimations (§III.6.2) pour le cas où les tâches ont la même fonction de puissance dissipée.
III.6.1. Une condition d’optimalité
Le résultat principal de cette sous-section indique une condition nécessaire pour qu’un
ordonnancement pour une plate-forme donnée soit optimal, condition qui sera utilisée plus
tard. Tout d’abord un résultat préliminaire, utile dans la démonstration du théorème principal.
Lemme III.3 : Soit g : [0,+∞[ → R une fonction croissante et convexe et soit h : [0,+∞[ → R
la fonction donnée par h( x ) = g ( x ) x . Alors, pour tout a, b, P>0 et z ∈ ]0, b − a [ , l’inégalité
suivante est vraie:
⎛b− z⎞
⎛a+z⎞
⎛b⎞
⎛a⎞
ah⎜ ⎟ + bh⎜ ⎟ > (a + z )h⎜
⎟.
⎟ + (b − z )h⎜
⎝ P ⎠
⎝ P ⎠
⎝P⎠
⎝P⎠
Démonstration : g étant une fonction convexe et croissante, la fonction f : [0,+∞[ → R
⎛x⎞
⎛x⎞
donnée par f ( x ) = xh⎜ ⎟ = Pg ⎜ ⎟ est aussi convexe et croissante.
⎝P⎠
⎝P⎠
Figure III.11. Une inégalité pour les fonctions croissantes et convexes.
95
Chapitre III
Optimisation de la consommation d’énergie
On a
a + b (a + z ) + (b − z )
=
. Il est évident sur la Figure III.11 que :
2
2
f (a + z ) + f (b − z )
f (a ) + f (b)
,
= M1 < M 2 =
2
2
inégalité qui est équivalente à celle souhaitée. ■
Avant de passer au résultat principal, ajoutons quelques notations. Considérons un
ensemble Tn={T1, T2,…, Tn} de tâches périodiques, indépendantes et à échéance sur requête,
pour lequel il existe un ordonnancement faisable Ω sur une plate-forme à m processeurs
π 1 ,K, π m , m<n, tel que l’exécution de chaque tâche soit assignée à un seul processeur.
{
}
Ti ∈ π k signifie que la tâche Ti est exécutée par π k ,
π k représente le nombre de tâches exécutées par π k ,
Γk =
∑π
Ti ∈
k
P
C i représente le nombre de cycles processeur exécutés par le
Pi
processeur π k durant la période P d’étude, P=ppmc(P1,P2, …,Pn).
Théorème III.10 (Principe d’uniformité) : Soit Tn={T1, T2, …, Tn} un ensemble de tâches
périodiques, indépendantes, à échéance sur requête et avec la même fonction de dissipation
de puissance, pour lequel il existe un ordonnancement faisable Ω sur une plate-forme à m
processeurs π 1 ,K, π m , m<n, tel que l’exécution de chaque tâche soit assignée à un seul
{
}
processeur. Avec les notations ci-dessus, si l’ordonnancement Ω est optimal et S MIN <
pour tout i = 1,K, m , alors :
Γi
P
max Γk ≤ 2 min Γl .
l =1,K, m
π k ≥2
Démonstration : On procède par réduction à l’absurde. Supposons que l’inégalité à prouver
soit fausse, donc :
Γ1 > 2Γm (1).
Avec un possible changement de numérotation des processeurs, on peut considérer
Γ1 = max Γk
π k ≥2
et
Γm = min Γl .
l =1,K, m
Il est évident que sur le premier processeur il y a au moins une tâche, disons T1 ∈ π 1 ,
dont le nombre de cycles processeur correspondant à la période d’étude satisfait :
1
P
C1 ≤ Γ1 (2).
2
P1
96
Chapitre III
Optimisation de la consommation d’énergie
Nous définissons un nouvel ordonnancement Ω' où le processeur π 1 n’exécute plus la
tâche T1, et le processeur π m exécute les tâches qu’il exécutait conformément à Ω et la tâche
T1. Tous les autres processeurs gardent les ordonnancements des tâches donnés par Ω . On
impose de plus que dans cet ordonnancement Ω' les deux processeurs π 1 et π m exécutent de
manière optimale les tâches leur étant assignées. Soit Γ1′ et Γm′ le nombre de cycles
processeurs qui correspondent aux processeurs π 1 et π m dans l’ordonnancement Ω' .
Vérifions la faisabilité de ce nouvel ordonnancement Ω' . Les tâches étant assignées
pour exécution chacune à un processeur, il suffit de vérifier la faisabilité des
ordonnancements des tâches sur chaque processeur. Ω étant un ordonnancement faisable, il
est évident que les tâches qui restent assignées aux mêmes processeurs dans Ω' respectent
leurs échéances, donc les ordonnancements sur les processeurs de π 2 à π m −1 sont faisables.
Le processeur π 1 n’exécute plus la tâche T1, alors la faisabilité de ceux qui restent est assurée
et nous considérons que leur exécution est optimale (Prop. III.1’). Il reste à vérifier la
faisabilité des tâches exécutées par le processeur π m .
Les inégalités (1) et (2) fournissent :
Γm′ = Γm +
1
P
C1 ≤ Γ1 (3).
2
P1
L’ordonnancement Ω étant optimal et les tâches étant assignées aux processeurs, il est
évident que chaque processeur exécute d’une manière optimale les tâches lui étant assignées.
Γ
Conformément à la Proposition III.1’ et comme S MIN < i pour tout i = 1,K, m , la vitesse
P
d’exécution des tâches par le processeur π i dans l’ordonnancement Ω est donnée par :
Si =
Γi
, pour tout i = 1,K, m . (4)
P
Compte tenu des affirmations (3) et (4) et du fait que les tâches ont la même fonction
de dissipation de puissance, il en résulte que le processeur π m assure la faisabilité du nouvel
ensemble de tâches et que dans l’ordonnancement optimal (cf. Prop. III.1’) la vitesse des
Γ′
tâches est donnée par S m′ = m .
P
Faisons une comparaison des énergies consommées, E (Ω ) et E (Ω′) , par les deux
ordonnancements Ω et Ω ′ , pour la même période P d’étude :
( )
( )
( )
( )
E (Ω ) − E (Ω′) = Γ1 h S1 + Γm h S m − Γ1′ h S1′ + Γm′ h S m′
( )
( )
= Γ1 h S1 + Γm h S m
P
P
⎞
⎛
⎞
⎛
C1 ⎟
C1 ⎟
⎜ Γm +
⎜ Γ1 −
⎛
⎞
P1
P1
P
⎟ . (5)
⎟ − ⎛⎜ Γ + P C ⎞⎟h⎜
− ⎜⎜ Γ1 −
C1 ⎟⎟h⎜
1
m
⎜
⎟
⎟
⎜
⎟
⎜
P
P
P
P
1
1
⎠ ⎜
⎝
⎠ ⎜
⎟
⎟ ⎝
⎠
⎝
⎠
⎝
Pour ce qui concerne la relation entre le nombre de cycles processeur dans les deux
ordonnancements exécutés par les processeurs π 1 et π m , on peut constater les inégalités
suivantes :
97
Chapitre III
Optimisation de la consommation d’énergie
Γm <
1
P
Γ1 ≤ Γ1 −
C1 = Γ1′ < Γ1
2
P1
et
Γm < Γ1′ = Γm +
1
1
1
P
C1 ≤ Γm + Γ1 < Γ1 + Γ1 = Γ1 ,
2
2
2
P1
ce qui nous permet d’appliquer le Lemme III.3 à la relation (5) et d’obtenir :
E (Ω ) − E (Ω′) > 0 .
Par conséquent, l’énergie consommée par l’ordonnancement faisable Ω' est inférieure
à l’énergie consommée par l’ordonnancement optimal Ω , donc Ω n’est pas un
ordonnancement optimal, ce qui contredit l’hypothèse. Alors la supposition (1) faite au début
de la démonstration est fausse, et donc :
max Γk ≤ 2 min Γl . ■
l =1,K, m
π k ≥2
Note :
1. L’exemple des trois tâches identiques exécutées par deux processeurs (les tâches étant
assignées aux processeurs) montre un cas d’égalité dans l’inégalité du théorème précédent.
2. Les hypothèses sur les ordonnancements dans le théorème précédent peuvent paraître un
peu restrictives. Néanmoins ce théorème :
a. Offre une appréciation sur la configuration d’un ordonnancement optimal d’un
ensemble de tâches par une machine donnée, où les tâches sont assignées aux
processeurs et ont la même fonction de dissipation de puissance.
b. A notre connaissance, représente la seule caractérisation d’un ordonnancement
optimal pour une machine multiprocesseur donnée.
c. Est extrêmement utile pour estimer le gain d’énergie obtenu par le passage de un
à deux processeurs (§III.6.2).
La condition d’optimalité (Th. III.10) d’un ordonnancement où les tâches ne
changent pas de processeur représente en effet un principe d’uniformité sur le
nombre de cycles processeur à exécuter par chaque processeur de la machine
donnée. L’assignation des tâches aux processeurs peut être très utile au niveau
de l’implantation, car elle élimine la commutation entre les processeurs et les
coûts induits. Néanmoins cela n’exclut pas de chercher une condition similaire
pour les ordonnancements sans cette restriction.
III.6.2. Estimations sur le gain énergétique au passage de m à m+1
processeurs
Pour la suite, nous effectuons des estimations sur le gain énergétique au passage de un
à deux processeurs pour le modèle de tâches périodiques, indépendantes, avec le même
moment d’activation et la même fonction de puissance dissipée : g(S )=aS r , r∈N, r ≥2, a∈R*+ .
98
Chapitre III
Optimisation de la consommation d’énergie
Tout d’abord, un résultat mathématique pour simplifier la démonstration du théorème qui suit.
Lemme III.4 : Pour tout r nombre entier, r>1, la fonction f : [1,2] → R, donnée par
f (x ) =
1+ xr
(1 + x )r
est croissante en x.
Démonstration : En calculant la dérivée au premier ordre f’ de la fonction f, on obtient :
′
r
r ′
1 + x r (1 + x ) − 1 + x r (1 + x )
f ' (x ) =
(1 + x )2 r
(
)
)[
(
(
)
rx r −1 (1 + x ) − 1 + x r r (1 + x )
r
=
(1 + x )2r
=
[
r
x r −1 (1 + x ) − 1 − x r
r +1
(1 + x )
=
(
]
r −1
]
)
r
x r −1 − 1 ≥ 0
r +1
(1 + x )
pour tout x ∈ [1,2] et pour tout r nombre entier, r>1, ce qui donne le résultat souhaité.
Théorème III.11 : Soit Tn={T1, T2, …, Tn}, n>4, un ensemble de tâches périodiques,
indépendantes, à échéance sur requête, prêtes à s’exécuter au même moment et ayant la
même fonction de puissance dissipée g(S )=aS r , r∈N, r ≥2, a∈R*+ . Supposons qu’il existe
pour T n un ordonnancement optimal monoprocesseur dont la consommation est notée par E1,
et un ordonnancement optimal sur deux processeurs tel que l’exécution de chaque tâche soit
assignée à un seul processeur et π k ≥ 2 , k=1,2. Si E2 est la consommation pour ce dernier
ordonnancement alors :
1
2 r −1
Démonstration : Soit Γk =
∑π
Ti ∈
k
E1 ≤ E 2 ≤
1 + 2r
E1 .
3r
P
C i le nombre de cycles processeur exécutés par le
Pi
processeur π k dans un ordonnancement à deux processeurs comme dans l’énoncé, k=1,2. On
a donc Γ1 + Γ2 =
∑C
i
.
Ti ∈T n
Par la Proposition III.1’, l’énergie d’un ordonnancement optimal monoprocesseur est
donné par :
⎛ Γ + Γ2 ⎞
E1 = (Γ1 + Γ2 ) h ⎜ 1
⎟
⎝ P ⎠
99
Chapitre III
Optimisation de la consommation d’énergie
r −1
De même :
⎛ Γ + Γ2 ⎞
= a (Γ1 + Γ2 ) ⎜ 1
⎟
⎝ P ⎠
⎛Γ ⎞
⎛Γ
E 2 = Γ1 h⎜ 1 ⎟ + Γ2 h⎜ 2
⎝P⎠
⎝P
⎛Γ ⎞
= aΓ1 ⎜ 1 ⎟
⎝P⎠
r −1
⎛Γ ⎞
+ aΓ2 ⎜ 2 ⎟
⎝P⎠
.
⎞
⎟
⎠
r −1
.
Pour une comparaison des énergies consommées dans les deux cas, en faisant leur
rapport, on obtient :
r −1
r −1
⎛ Γ1 ⎞
⎛ Γ2 ⎞
aΓ1 ⎜ ⎟ + aΓ2 ⎜ ⎟
E2
⎝P⎠
⎝P⎠
=
r −1
E1
⎛ Γ1 + Γ2 ⎞
a (Γ1 + Γ2 ) ⎜
⎟
⎝ P ⎠
r
=
Γ1 + Γ2
r
(Γ1 + Γ2 )r
⎛ Γ1
⎜⎜
Γ
=⎝ 2
⎛ Γ1
⎜⎜
⎝ Γ2
r
⎞
⎟⎟ + 1
⎠
.
r
⎞
+ 1⎟⎟
⎠
Supposons que Γ1 ≥ Γ2 (le cas Γ1 ≤ Γ2 peut être réduit à celui-ci par un changement de
notation). Le Théorème III.10 fournit Γ1 ≤ 2Γ2 . Avec le changement de notation : x = Γ1 Γ2 ,
ces conditions reviennent à x ∈ [1,2] , et le rapport des énergies devient :
E2
1+ xr
=
.
E1 (1 + x )r
En appliquant le Lemme III.4 sur l’intervalle [1,2] , on obtient ce qu’on a cherché à
prouver :
1
1 + 2r
≤
≤
E
E
E1 . ■
1
2
2 r −1
3r
Note : Ce théorème, corroboré par le lemme suivant (III.5), montre que plus r est grand, plus E2
est petite par rapport à E1. Le Tableau III.2 offre quelques estimations.
Lemme III.5 : Pour tout x ∈ [1,2] , la fonction h : [2,+∞[ → R donnée par f (r ) =
est décroissante en r.
Démonstration : Soit f’ la dérivée au premier ordre de la fonction f. Alors :
100
1+ xr
(1 + x )r
,
Chapitre III
Optimisation de la consommation d’énergie
′
′
(
1 + x ) (1 + x ) − (1 + x ) [(1 + x ) ]
f ' (r ) =
r
r
r
r
(1 + x )2 r
(
)
x r ln x (1 + x ) − 1 + x r (1 + x ) ln(1 + x)
(1 + x )2 r
r
=
=
=
(
r
)
x r ln x − 1 + x r ln(1 + x)
(1 + x )
r
x r [ln x − ln(1 + x)] − ln(1 + x)
<0
(1 + x )r
pour tout x ∈ [1,2] et pour tout r>1, d’où la décroissance de f par rapport à r. ■
r
Estimation du gain énergétique
2
0,5 =
1 E2 5
≤
≤ ≅ 0,556
2 E1 9
3
0,25 =
1 E2 1
≤
≤ ≅ 0,334
4 E1 3
4
0,125 =
1 E 2 17
≤
≤
≅ 0,21
8 E1 81
5
0,0625 =
1 E2
33
≤
≤
≅ 0,046
16 E1 729
Tableau III.2. Gain d’énergie au passage de 1 à 2 processeurs.
Note : Si l’hypothèse π k ≥ 2 , k=1,2, prise en compte dans l’énoncé du Théorème III.11, n’est
pas respectée, les estimations sur le gain d’énergie que le théorème permet ne sont pas valables,
comme le montre l’exemple suivant. Le rôle de cette hypothèse est d’exclure une situation limite.
Néanmoins, pour le cas d’un ordonnancement sur deux processeurs pour lequel π 1 = 1 , des
estimations peuvent être réalisées sans difficulté, par la même technique.
Exemple : Soit T 4={T1, T2, T3, T4} un ensemble de 4 tâches périodiques, indépendantes, à
échéance sur requête, prêtes à s’exécuter à l’instant t=0, avec la même période et la même
fonction de dissipation de puissance g donnée par g ( S ) = aS 3 , a>0. Supposons que leurs
4
coûts d’exécution pire cas C i vérifient la relation C 1 = 4∑ C i . La Figure III.12 illustre ce
i =2
cas en prenant comme axe C . Compte tenu de cette relation, un calcul similaire à celui
101
Chapitre III
Optimisation de la consommation d’énergie
effectué dans la démonstration du Théorème III.11 fournit : E 2 =
13
E1 , une estimation donc
25
différente de celle figurée dans le Tableau III.2.
Figure III.12. Les estimations du Théorème III.8 ne sont pas valables sans l’hypothèse
π k ≥ 2 , k=1,2.
Théorème III.12 : Soit Tn={T1, T2, …, Tn}, n ≥ 4 , un ensemble de tâches périodiques,
indépendantes, à échéance sur requête, prêtes à s’exécuter au même moment et ayant toutes
la même fonction de puissance dissipée g (S ) = aS r , r ∈ N, r ≥ 2, a ∈ R *+ . Soit E1 sa
consommation optimale monoprocesseur, et E2 sa consommation optimale sur deux
processeurs tel que chacun exécute entièrement au moins deux tâches. Alors :
1 + 2r
E2 ≤
E1 ≤ 0,556 E1 .
3r
Démonstration : La consommation due à un ordonnancement de Tn optimal sur deux
processeurs, tel que chaque tâche est assignée à un processeur, est supérieure ou au moins
égale à la consommation d’un ordonnancement de Tn optimal sur deux processeurs sans autres
restrictions. Par conséquent, la deuxième inégalité obtenue dans le Théorème III.11 reste
1 + 2r
vraie : E2 ≤ r E1 . Compte tenu du résultat fourni par le Lemme III.5 (voir aussi le
3
1 + 2r
E1 ≤ 0,556 E1 . ■
Tableau III.2), on obtient
3r
Les résultats de cette sous-section indiquent une diminution considérable (au
moins à 55,6%) de la consommation énergétique optimale en passant de un à
deux processeurs pour l’ordonnancement optimal sur deux processeurs où il y
a au moins deux tâches qui s’exécutent entièrement sur chacun des processeurs
(Th. III.12).
102
Chapitre III
Optimisation de la consommation d’énergie
III.7. Contribution : étude sur la configuration d’un système temps
réel embarqué afin de minimiser la consommation énergétique –
modèle des tâches identiques, indépendantes, ayant le même
moment d’activation et la même échéance
Nous menons notre étude sur un modèle de tâches périodiques, indépendantes et
identiques, ayant le même moment d’activation et la même échéance. Bien que ce soit le plus
simple modèle de tâches, il existe souvent dans les applications temps réel, au moins pendant
une durée déterminée ou pour une partie bien précise du scénario des tâches de l’application.
L’application décrite dans [MER 02] en représente un exemple. D’autre part, cela permet
d’examiner l’utilité de la nouvelle approche en commencent par un exemple simple pour
obtenir quelques premiers résultats et passer ensuite à des modèles de tâches plus complexes.
III.7.1. Notations, définitions, concepts
Soit Tn={T1,T2,…,Tn} un ensemble de n tâches périodiques, identiques et
indépendantes, prêtes à s’exécuter à l’instant t=0 et ayant la même échéance. Avec les
notations habituelles, soient : Ci =C, Pi =P, Di =D =P, pour toute tâche Ti.
Pour la suite, avec les notations ci-dessus, on considère la charge processeur :
n
Ci nC
=
≤ 1.
P
i =1 Pi
U tot = ∑
Conformément à la Proposition III.1’, une solution statique optimale est donnée par
une machine monoprocesseur qui exécute toutes les tâches avec la même vitesse
S = max S MIN , S tot .
{
}
Pour l’étude théorique on considère que S tot > S MIN et que toute vitesse S trouvée pour
les processeurs assure la fonctionnalité du système : S ≥ S MIN .
Dans le cas monoprocesseur, la consommation totale d’énergie due à l’exécution de
l’ensemble de tâches Tn, durant une période P est donnée par :
n
P
n
i =1
0
E 1 , n = ∑ E i (S )= n ∫ g (S )dt = Pg (S ) ,
où g(S ) , la puissance dissipée, est donnée par :
r
g (S ) = ∑ ai S i , r ∈ N, r ≥ 2, ai ∈ R, ∀i = 1,K, r .
i =1
III.7.2. Consommation optimale d’énergie sur une machine multiprocesseur
Nous indiquons dans cette sous-section une formule pour la puissance dissipée dans le
cas où pour le modèle de tâches cité la fonction de puissance dissipée prend la forme :
r
g (S ) = ∑ ai S i , r ∈ N, r ≥ 2, ai ∈ R, ∀i = 1,K, r .
i =1
103
Chapitre III
Optimisation de la consommation d’énergie
Théorème III.13 (formule pour la consommation) : La consommation optimale d’énergie pour
l’exécution de l’ensemble Tn de tâches identiques indépendantes sur une machine à m
processeurs est donnée par :
r q (k + 1)i + (m − q ) k i
ai S i ,
E m ,n = P ∑
i
n
i =1
r
où n=mk +q, q∈{0,K,m−1} et g (S ) = ∑ ai S i , r ∈ N, r ≥ 2, ai ∈ R, ∀i = 1,K, r , représente
i =1
la puissance dissipée pour leur exécution.
Démonstration : La distribution des n tâches identiques sur m processeurs, ainsi que leurs
vitesses d’exécution qui assurent une consommation optimale d’énergie, sont présentées dans
le Tableau III.3. Les valeurs indiquées sont issues :
•
de la Proposition III.1’ (qui propose une solution spécifique optimale pour
l’exécution des tâches périodiques indépendantes) et
•
suite à une distribution uniforme des tâches sur les processeurs.
Nombre de
processeurs
Nombre de tâches par
processeur
Vitesse des
processeurs
q
k+1
k +1S
n
m-q
k
kS
n
Tableau III.3. La distribution de n tâches identiques sur m processeurs,
et leurs vitesses d’exécution.
Le calcul de la consommation totale d’énergie devient :
⎛ k +1 ⎞
⎛k ⎞
E m,n = qE1,k +1 ⎜
S ⎟ + (m − q )E1,k ⎜ S ⎟
⎝ n
⎠
⎝n ⎠
⎛ k +1 ⎞
⎛k ⎞
= qPg ⎜
S ⎟ + (m − q )Pg ⎜ S ⎟
⎝ n
⎠
⎝n ⎠
r
= qP ∑ ai
i =1
(k + 1)i
n
i
r
S i + (m − q )P ∑ ai
i =1
ki
n
i
Si
q(k + 1) + (m − q )k i
= P∑
ai S i . ■
i
n
i =1
r
i
Deux cas particuliers sont traités par les corollaires suivants. Ils permettent d’avoir une
idée sur la variation de la consommation d’énergie avec la multiplication des processeurs.
104
Chapitre III
Optimisation de la consommation d’énergie
Corollaire III.4 : Pour une puissance dissipée ayant la forme : g (S ) = aS r , r ∈ N, r ≥ 2,
a ∈ R *+ , la consommation optimale d’énergie pour exécuter les n tâches identiques et
indépendantes sur m processeurs, Em,n , exprimée par rapport à l’énergie optimale
consommée pour leur exécution sur une machine monoprocesseur, E1,n , est donnée par la
relation :
E m ,n =
[
]
1
r
q (k + 1) + (m − q )k r E 1, n .
r
n
Démonstration : À partir du Théorème III.13, particularisé pour g (S ) = aS r , r ∈ N, r ≥ 2,
a ∈ R *+ , on obtient :
q (k + 1) + (m − q )k r
r
E m,n = P
nr
q (k + 1) + (m − q )k r
r
=
=
nr
[
aS r
Pg (S )
]
1
r
q(k + 1) + (m − q )k r E1,n . ■
r
n
Corollaire III.5 : Soit g (S ) = aS r , r ∈ N, r ≥ 2, a ∈ R *+ , la forme de la puissance dissipée, et
soit n=mk, k∈Ν* , où m représente le nombre de processeurs et n le nombre de tâches. En
passant de 1 à m processeurs, le gain d’énergie ainsi que les vitesses optimales des tâches ne
dépendent pas du nombre de tâches.
Démonstration : Comme n=mk, k∈Ν* , on obtient :
•
à partir du Corollaire III.4 : E m,n =
•
à partir du Tableau III.3 : S = 1 S ,
m
{
1
E1,n , et
m r −1
}
où S = max S MIN , S tot représente la vitesse optimale pour le cas monoprocesseur. ■
Note : La Figure III.13 montre la dépendance du gain d’énergie obtenu en fonction du nombre
m de processeurs et la consommation spécifique d’une tâche exprimée par l’exposant r. Les
estimations indiquent un gain d’énergie important qui augmente d’autant que les tâches sont des
consommatrices d’énergie importantes. Pour des considérations technologiques, il peut arriver
que la valeur de la vitesse minimale S MIN dépasse la vitesse optimale de l’exécution de n tâches
sur m processeurs, Sm = 1 S , pour m<<n .
m
105
1
r=2
r=3
0,8
1,2
1
Sm/S1
1,2
Optimisation de la consommation d’énergie
Em,n/E1,n
Chapitre III
0,6
0,8
0,6
0,4
0,4
0,2
0,2
m
0
1
2
3
4
5
6
7
8
m
0
1
2
3
4
5
6
7
8
Figure III.13. La consommation optimale d’énergie et la vitesse correspondante
pour les m processeurs relatives à la solution optimale monoprocesseur.
III.7.3. Cas particulier : le passage de un à deux processeurs
Les estimations présentées dans ce paragraphe sur le gain d’énergie au passage de 1 à
2 processeurs sont basées sur le cas particulier de la puissance dissipée pour l’exécution d’une
tâche g (S ) = aS r , r ∈ N, r ≥ 2, a ∈ R *+ .
Cas I : n=2k
Théorème III.14 : Pour un ensemble de n=2k tâches identiques, indépendantes, et une
puissance dissipée pour l’exécution de chaque tâche ayant la forme g (S ) = aS r , r ∈ N,
r ≥ 2, a ∈ R *+ , le gain théorique d’énergie au passage de 1 à 2 processeurs est au minimum
50%.
Démonstration : La solution optimale statique pour le cas monoprocesseur indique une vitesse
S . La solution optimale statique pour 2 processeurs suppose l’exécution de k tâches sur
chacun des deux processeurs, avec une vitesse S= S (conformément au Théorème III.13).
2
Figure III.14. Le passage de 1 à 2 processeurs pour n=2k tâches identiques.
En appliquant les valeurs m=2 et q=0 dans la formule donnée par le Corollaire III.4,
106
Chapitre III
E m ,n =
Optimisation de la consommation d’énergie
[
]
1
r
q (k + 1) + (m − q ) k r E 1, n , on obtient :
r
n
E 2,n
α 1
2k r
1
r
= r 2k E1,n = r r E1,n = r −1 E1,n .
2 k
2
n
( )
β
1
Par conséquent, E 2,n ≤ E1,n pour ∀r ≥2 , et E 2,n a une décroissance logarithmique par
2
rapport à E1,n , relatif à l’argument r, le degré de la fonction polynomiale qui indique la
consommation d’une tâche.
En conséquence, pour un nombre entier pair de tâches, n, la consommation sur deux
processeurs représente au maximum 50% de la consommation monoprocesseur (β), et elle
diminue de façon logarithmique (α), selon r, le degré de la fonction polynomiale qui
caractérise la puissance dissipée. ■
Cas II : n=2k +1
La solution optimale statique monoprocesseur est donnée par la vitesse S . Pour la
machine à 2 processeurs, k tâches sont exécutées avec la vitesse k S , et les autres k+1
2k +1
k
S (conformément au Théorème III.13).
tâches sont exécutées avec la vitesse
2k +1
Figure III.15. Le passage de 1 à 2 processeurs pour n=2k +1 tâches identiques.
[
]
r
En appliquant les valeurs m=2 et q=0 dans la formule E m , n = 1r q(k +1) + (m − q )k r E1 , n
n
(donnée par le Corollaire III.4), on obtient :
(k +1) + k r
r
E 2 , n = 1r (k +1 ) + k r E1 , n =
E .
n
(2 k +1)r 1 , n
[
]
r
Lemme III.6 : Pour tout k, nombre entier positif, la fonction f : Ν → R , donnée par
f (r ) =
k r + (k + 1)
(2k + 1)r
r
, est décroissante en r.
Démonstration : Il faut montrer que pour tout r, nombre entier positif :
107
Chapitre III
Optimisation de la consommation d’énergie
k r + (k + 1)
r
>
(2k + 1)r
k r +1 + (k + 1)
r +1
(2k + 1)r +1
[
]
⇔ (2k + 1) k r + (k + 1) > k r +1 + (k + 1)
r
r +1
⇔ (2k + 1)k r + (2k + 1)(k + 1) > kk r + (k + 1)(k + 1)
r
r
⇔ (k + 1)k r + k (k + 1) > 0 ,
r
ce qui est évident pour tout k et r nombres entiers positifs. ■
Lemme III.7 : Pour tout r, nombre entier, r>1, la fonction f : Ν → R , donnée par
f (k )=
k r +(k +1)
r
(2k +1)r
, est décroissante en k.
Démonstration : Soient : r un nombre entier, r>1, g : R + → R la fonction décrite par :
g(x )=
x r +(x+1)
r
(2x+1)r
, et g'(x ) la dérivée de premier ordre de la fonction g. On a :
[x
g ' (x ) =
[rx
=
=
r −1
r
+ ( x + 1)
r
]′ (2 x + 1) − [x
r
r
+ ( x + 1)
r
(2 x + 1)2 r
+ r ( x + 1)
r −1
](2 x + 1) − [x
r
r
][(2 x + 1) ]′
r
]
+ ( x + 1) 2r (2 x + 1)
r
(2 x + 1)2 r
r −1
[
r
r −1
r
x r −1 (2 x + 1) + ( x + 1) (2 x + 1) − 2 x r − 2( x + 1)
r +1
(2 x + 1)
=
[
]
]
r
r −1
x r −1 (2 x + 1 − 2 x ) + ( x + 1) (2 x + 1 − 2 x − 2)
r +1
(2 x + 1)
=
[
]
r
r −1
x r −1 − ( x + 1)
< 0
r +1
(2 x + 1)
pour tout x nombre réel positif et pour tout r nombre entier, r>1.
x r + ( x + 1)
Par conséquent, la fonction g : R + → R définie par g ( x ) =
décroissante, donc la fonction f : Ν → R , définie par
décroissante. ■
108
f (k ) =
(2 x + 1)r
k r + (k + 1)
r
, est
r
(2k + 1)r
, est une fonction
Chapitre III
Optimisation de la consommation d’énergie
Corollaire III.6 : Pour tout k et r nombres entiers, avec k ≥ 1 et r ≥2 , l’inégalité suivante est
valable:
r
k r + (k + 1)
5
≤ ≅ 0.556
r
9
(2k + 1)
Démonstration :
k r + (k + 1)
(2k + 1)
r
r
Lemme 6
≤
k 2 + (k + 1)
(2k + 1)
2
Lemme 7
2
≤
12 + 2 2
3
2
=
5
.■
9
Théorème III.15 : Soit un ensemble de tâches identiques, indépendantes, prêtes à s’exécuter
au même moment, et g (S ) = aS r , r ∈ N, r ≥ 2, a ∈ R *+ , la puissance dissipée pour exécuter
une de ces tâches, S étant la vitesse du processeur. Pour un ensemble formé par un nombre
impair de tâches, la solution optimale statique pour la consommation d’énergie suite à
l’exécution des tâches sur une machine à deux processeurs représente au maximum 56% de la
consommation énergétique donnée par la solution optimale statique monoprocesseur.
Cor 5
Démonstration : E 2,n =
(k + 1)r + k r
(2k + 1)r
Cor 6
E1,n ≤
5
E1,n ≅ 0.556 E1,n . ■
9
Les Théorèmes III.14 et III.15 montrent que les estimations théoriques sur le
gain d’énergie sont suffisamment significatives pour justifier la prise en
compte du nombre de processeurs dans l’optimisation d’énergie.
L’annexe présente l’exemple concret d’une application de transmission en
temps réel des images médicales, où l’ensemble consiste en quatre tâches
identiques, indépendantes, prêtes à s’exécuter au même moment.
III.7.4. Méthodologie de calcul du nombre optimal de processeurs pour une
minimisation de la consommation d’énergie. Evaluations
Ce paragraphe porte sur une méthodologie de détermination du nombre optimal de
processeurs. Ainsi, des évaluations sur les vitesses des processeurs et le gain d’énergie seront
présentées pour différentes plates-formes et différentes fonctions de la puissance dissipée.
Algorithme d’évaluation de la consommation énergétique pour un ensemble de tâches
1. Input :
n = le nombre de tâches ; P = leur période ;
SMINl, SMAX = les valeurs minimale et maximale de la vitesse admise par le processeur ;
C = l’estimation pire-cas pour le coût des tâches, exprimée en cycles processeurs ;
r = le degré maximal de g(S), la puissance consommée par une tâche ;
pour i=1 à r :
ai = les coefficients de la fonction polynomiale g(S) ;
2. Déterminer la valeur statique optimale pour le cas monoprocesseur :
109
Chapitre III
Optimisation de la consommation d’énergie
⎧
nC ⎫
S = max ⎨S MIN , S tot =
⎬ ;
P ⎭
⎩
3. Calcul de la consommation optimale d’énergie pour m processeurs :
pour m=1 à n :
déterminer : les nombres entiers k et q : n=mk +q, q∈{0,K,m−1} ;
déterminer : k +1S et k S ;
n
n
k
si S ≥ S min alors
n
q CPUs exécutent, chacun, k+1 tâches avec la vitesse Sm,q = k +1S ;
n
m-q CPUs exécutent, chacun, k tâches avec la vitesse Sm,m − q = k S ;
n
i
i
r q (k + 1) + (m − q )k
ai S i ;
la consommation d’énergie : E m,n = P ∑
i
n
i =1
Sinon STOP.
Le Tableau III.4 indique des gains importants d’énergie sur une machine
multiprocesseur par rapport à une machine monoprocesseur, selon la formule :
1
r
E m,n = r q(k + 1) + (m − q )k r E1,n , donnée par le Corollaire III.4 pour une puissance
n
[
]
dissipée ayant la forme : g (S ) = aS r , r ∈ N, r ≥ 2, a ∈ R *+ .
On constate en même temps que la vitesse minimale des processeurs (la dernière
colonne du tableau) présente une décroissance logarithmique avec le nombre de processeurs,
par rapport à la vitesse statique optimale pour le cas monoprocesseur S .
r = degré de la
n = nombre m = nombre de
puissance
de tâches
processeurs
consommée
2
10
1
2
10
2
2
10
3
2
10
4
2
10
5
2
10
6
2
10
7
2
10
8
2
10
9
2
10
10
3
10
1
3
10
2
3
10
3
3
10
4
3
10
5
3
10
6
3
10
7
3
10
8
110
Em,n
E1,n
1
0,5
0,34
0,26
0,2
0,18
0,16
0,14
0,12
0,1
1
0,25
0,118
0,07
0,04
0,034
0,028
0,022
Sm,m − q
1
0,5
0,3
0,2
0,2
0,1
0,1
0,1
0,1
0,1
1
0,5
0,3
0,2
0,2
0,1
0,1
0,1
S
Chapitre III
Optimisation de la consommation d’énergie
3
3
2
2
2
2
2
2
2
2
2
2
3
3
3
3
3
3
3
3
3
3
10
10
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
9
10
1
2
3
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10
0,016
0,01
1
0,5
0,3334
0,25
0,2
0,1668
0,143
0,1252
0,1112
0,1
1
0,25
0,111178
0,0625
0,04
0,027844
0,02047
0,0157
0,012376
0,01
0,1
0,1
1
0,5
0,33
0,25
0,2
0,16
0,14
0,12
0,11
0,1
1
0,5
0,33
0,25
0,2
0,16
0,14
0,12
0,11
0,1
Tableau III.4. Gain d’énergie au passage de 1 à m processeurs.
Conclusion : L’augmentation du nombre de processeurs est limitée par la valeur de
⎧
nC ⎫
S = max ⎨S MIN , S tot =
⎬ . Pour passer à deux processeurs il faut au moins que :
P ⎭
⎩
2S MIN ≤ S = S tot .
Corollaire III.7 : Dans le cas où n, le nombre de tâches, est multiple du nombre de
processeurs, pour une puissance dissipée ayant la forme : g (S ) = aS r , r ∈ N, r ≥ 2, a ∈ R *+ ,
le gain d’énergie au passage de 1 à m processeurs ne dépend pas du nombre de tâches.
Démonstration : Pour n=mk, k∈Ν* , conformément au Corollaire III.4, on obtient :
Em,n = 1r −1 E1,n . ■
m
III.8.
Conclusions et perspectives
Les dimensions des composantes des systèmes informatiques deviennent de plus en
plus réduites, ceci permettant que de plus en plus de systèmes embarqués soient conçus ; de
111
Chapitre III
Optimisation de la consommation d’énergie
même, le problème de la consommation énergétique devient de plus en plus important. Ce
marché en pleine expansion a une conséquence assez curieuse : la concurrence acerbe entre
les différents producteurs des systèmes embarqués a conduit à de nouveaux produits basés
surtout sur des travaux expérimentaux et des documentations internes.
Afin de prolonger la durée de vie des batteries d’un système temps réel embarqué,
dans ce chapitre nous avons étudié la consommation d’énergie par le(s) processeur(s), due à
l’exécution des tâches. Après une introduction et un état de l’art pour cette problématique,
notre travail et notre contribution se sont développés en trois directions. Le modèle de tâches
traité a été celui des tâches périodiques indépendantes.
D’une part, le fondement théorique et les résultats pour le problème monoprocesseur a
été complété. Après certaines critiques, corrections et compléments sur la modélisation
proposée dans [AYD 01a,b,c], on a obtenu une formule pour les vitesses des différentes
parties des tâches dans la solution statique optimale (§III.3).
D’autre part, on a considéré le problème d’optimisation énergétique sur des platesformes multiprocesseur. On a développé les notions théoriques nécessaires, ainsi que des
résultats de base et essentiels sur la faisabilité et l’optimalité (§III.4). Basé sur le concept
d’ordonnancement global optimal, on a pu fournir la solution statique et dynamique pour le
cas général (§III.5). Ce concept s’appuie sur une nouvelle approche dans la théorie
d’ordonnancement multiprocesseurs, et celle-ci constitue la deuxième direction de notre
étude. On a redéfini le problème comme suit :
Pour une configuration optimale d’un système temps réel embarqué, il faut
déterminer :
le nombre m de processeurs,
les vitesses d’exécution des tâches à tout moment de leur exécution (après
chaque préemption),
tout en assurant la faisabilité d’ordonnancement pour une minimisation de la
consommation d’énergie sur l’exécution de l’ensemble des tâches.
Dans la théorie de l’ordonnancement, l’approche qui consiste à prendre comme
variable à déterminer le nombre de processeurs nécessaire pour la faisabilité d’un ensemble de
tâches est peu abordée (voir le problème du « sac à dos » dans §II.3.4.3) et incomplètement
valorisée à ce jour ; néanmoins, cette approche s’avère particulièrement utile pour l’optimalité
de l’ordonnancement, comme le montrent les résultats de ce chapitre. Remarquons ici que, tel
qu’il a été formulé pour la faisabilité d’ordonnancement d’un ensemble de tâches, le problème
du « sac à dos » est différent de celui pour l’optimalité de l’ordonnancement, car il suppose
déterminer le nombre minimal de processeurs afin d’assurer l’exécution d’un ensemble de
tâches (voir §II.2). Par contre, notre approche montre qu’afin de minimiser la consommation
du processeur, le nombre de processeurs doit être maximal.
Il se peut que, selon les caractéristiques des tâches, la solution théorique globale
optimale soit difficile à obtenir de point de vue technologique, par exemple à cause d’un
nombre trop élevé de processeurs à utiliser ou de vitesses des tâches trop basses.
Pour cela on a abordé une troisième direction d’étude (§III.6.1), en déterminant une
condition nécessaire d’optimalité pour un ordonnancement sur une plate-forme ayant un
nombre donné de processeurs (au moins deux). Comme application de cette condition, on a
obtenu des évaluations concrètes du gain énergétique pour le passage de un à deux
processeurs, pour le modèle de tâches ayant la même fonction de puissance dissipée (§III.6.2).
112
Chapitre III
Optimisation de la consommation d’énergie
Le modèle des tâches identiques est traité en détail dans la section III.7. On a présenté
les ordonnancements optimaux, comparant ainsi la consommation énergétique optimale d’une
plate-forme à m processeurs avec celle d’une machine à m+1 processeurs.
Les résultats indiquent, pour les modèles des tâches considérés, des gains importants
d’énergie à l’augmentation du nombre de processeurs. Pour cela, malgré les inconvénients
que la technologie actuelle pourrait introduire dans une évaluation réelle, nous considérons
que ce gain d’énergie est suffisamment important pour prendre en compte cette approche
durant la période de développement d’un tel système.
Quant aux perspectives immédiates de cette approche, d’un certain intérêt pratique est
de trouver une condition suffisante pour qu’un ordonnancement d’un ensemble de tâches sur
une machine à nombre donné de processeurs (au moins deux) soit optimal. A ce moment,
seulement la condition nécessaire donnée par le Théorème III.10 existe. Une réponse à ce
problème pourrait engendrer un ordonnancement optimal sur la plate-forme donnée, pour des
tâches quelconques, et permettrait de plus la généralisation des résultats présentés dans
§III.6.2 et § III.7. La démonstration pour la convergence d’un algorithme empirique vers la
solution optimale est en cours.
On a utilisé, pour quelques résultats sur la consommation énergétique, des fonctions de
puissance dissipée ayant la forme : g i (S ) = ai S r , a i , r ∈ R *+ , r ≥ 2 (voir les Théorèmes :
III.5, III.11, III.12, III.14, III.15). Certes, celle-ci est la forme la plus souvent utilisée dans les
articles de recherche déjà mentionnés, mais la forme de cette fonction peut être plus complexe
(voir §III.2.2). La généralisation de ces résultats devrait surpasser certaines difficultés
mathématiques et reste pour l’avenir.
Des études sur d’autres modèles de tâches restent à réaliser dans de futurs travaux,
notamment pour prendre en compte les relations de précédence et les anomalies qu’elles
peuvent induire.
Des évaluations pratiques seront aussi nécessaires pour valider cette théorie, surtout
pour pouvoir estimer le coût supplémentaire induit par l’ajout de processeurs dans le système.
Afin de montrer comment il est possible de mettre en œuvre ces idées, au chapitre suivant
nous présentons une approche des notions théoriques et de l’implantation réelle d’un système.
Une autre question reste également ouverte : quel gain d’énergie la solution
dynamique peut-elle apporter pour une machine donnée, par rapport à la solution statique
globale optimale? Si intuitivement on peut penser que le gain complémentaire apporté par une
solution dynamique est insuffisant, la vraie réponse ne peut être obtenue que par une suite
d’expérimentations.
113
CHAPITRE IV
Une approche de l’implantation
d’une application temps réel pour l’optimisation
de la consommation énergétique du processeur
Chapitre IV
Sur les aspects du noyau et de l’implantation …
IV.1. Introduction
Dans un premier temps, ce chapitre met en évidence certains aspects liés à un noyau
temps réel et dans la perspective d’implantation d’une application temps réel, à l’optimisation
de la consommation énergétique au niveau du/des processeur(s) (§IV.2). Ensuite, la
présentation de quelques plates-formes (§IV.3) offre la possibilité de valider les résultats
théoriques liés à la consommation énergétique.
Pour la suite, chaque fois que l’expression « consommation d’énergie » sera utilisée,
elle fera référence à la consommation d’énergie au niveau du/des processeur(s) durant
l’exécution d’une application.
Pour traiter les aspects noyau de la consommation énergétique nous avons choisi le
noyau Linux/RTAI, dont la philosophie de conception et de fonctionnement a été brièvement
présentée dans la section II.4.3.2 de l’Etat de l’art. Comme il a été précisé, ce choix n’a pas
nécessairement été lié aux critères de performance de ce noyau par rapport aux autres. Les
critères qui nous ont intéressés sont les suivants : la disponibilité des sources, l’existence
d’une version embarquable, l’existence d’implantations pour différents types de platesformes, y compris multiprocesseurs, l’existence des différentes fonctionnalités spécifiques
aux noyaux temps réel, une documentation suffisamment riche et une liste active de
discussions. Ces critères permettent d’entrer dans les détails de l’implantation du noyau liés à
la consommation d’énergie par le(s) processeur(s). Les principes exposés seront basés sur
l’interprétation des codes sources du noyau Linux 2.4.8 et de RTAI 24.1.9, sur la
documentation disponible sur les différents sites Internet (la bibliographie mentionnée en fin
de chapitre indique quelques-uns parmi les plus complets), sur les informations échangées sur
la liste de discussions du projet RTAI, ainsi que sur d’autres références liées à ce sujet telles
que [AIV 00], [BOV 01], [HOL 02], [LIN 03], [LIS 00].
La discussion portera sur les suppositions faites au chapitre précédent afin de vérifier
comment les résultats obtenus peuvent être utilisés dans l’analyse a priori de l’implantation
d’une application temps réel et où – dans le processus de développement de l’application –
ces aspects interviennent. Parmi les principaux aspects qui doivent être pris en compte dans
une telle approche nous indiquons :
l’existence d’une version du noyau pour les plates-formes multiprocesseur
homogènes à mémoire commune ;
l’existence des ordonnanceurs qui traitent en ligne le changement de la vitesse
du/des processeur(s) ;
la méthode d’implantation de l’application et les tâches système, afin d’identifier
le scénario réel de l’application ;
la maîtrise des coûts noyau dans l’estimation des temps d’exécution des tâches ;
les implications du changement de processeur dans le cas de la reprise de
l’exécution d’une tâche sur les temps d’exécution des tâches et sur la
consommation d’énergie.
Selon la complexité de l’application il est possible que certains de ces aspects ne
soient pas concernés ; nous mentionnerons chaque fois là où les situations où elles peuvent
être omises. Par ailleurs, il est évident que lors de l’implantation effective d’une application
particulière, d’autres aspects non définis ici peuvent aussi intervenir, surtout parmi celles
spécifiques à la plate-forme utilisée. Nous limitons la présentation aux aspects généraux et
116
Chapitre IV
Sur les aspects du noyau et de l’implantation …
aux principes communs à toutes les plates-formes.
Des modifications dans la conception d’un noyau temps réel permettant de minimiser
la consommation d’énergie peuvent être envisagées. Nous nous contenterons de les
mentionner. Elles seront marquées en italique, de même pour les autres conclusions issues de
cette approche entre les résultats théoriques et la pratique que nous entreprenons. Il peut s’agir
de résultats théoriques nouveaux concernant la consommation d’énergie, mais aussi
d’observations sur la transposition de ces résultats en pratique.
L’implantation d’un noyau pouvant gérer les changements de vitesse du/des
processeur(s) et la mise en œuvre de toutes les conséquences pratiques liées à la
consommation d’énergie dans l’implantation d’une application – bien qu’intéressante et utile
pour comprendre le plus possible des aspects issus de l’optimisation de la consommation
d’énergie – dépasse le cadre de cette thèse, où nous avons voulu premièrement approfondir la
théorie sur la consommation énergétique et ensuite présenter de manière générale ses
implications dans les domaines pratiques.
Le but de la section §IV.3 est de présenter des plates-formes physiques pour les
résultats du Chapitre III, parmi celles proposées par la technologie actuelle, ainsi que les
outils logiciels qui pourraient permettre une validation de ces résultats. Cette section n’a pas
l’intention d’offrir la meilleure solution technique ; son rôle est simplement de vérifier si la
technologie actuelle permet cette validation, ou bien d’indiquer les manques qui devraient être
complétés par la technologie afin de pouvoir appliquer les résultats sur la consommation
énergétique. Sans minimiser l’importance de l’implantation et de la validation réelle, mais
plutôt pour lui donner sa place dans cette approche, ce travail – plutôt un projet d’ingénierie,
consécutif à notre étude – reste pour l’avenir.
IV.2. La consommation énergétique et les aspects du noyau et de
l’implantation d’une application temps réel
IV.2.1. Les plates-formes multiprocesseur homogènes à mémoire commune
On a vu, dans §II.4.3.2, que l’exécution des tâches temps réel était gérée par
l’ordonnanceur du RTAI. Dans cette section nous sommes intéressés à considérer les
différentes modalités de fonctionnement de l’ordonnanceur du RTAI, selon le type de la plateforme, mono ou multiprocesseur ; il s’agit de l’activation de l’ordonnanceur, des files
d’attente, de la distribution des tâches aux processeurs. Nous ne nous appuyons pas à ce
moment sur les politiques d’ordonnancement, car elles constitueront le sujet d’une autre
section. Le but ici est de mettre en concordance les types de plates-formes et les hypothèses
les concernant – sur lesquelles sont basés les résultats de l’ordonnancement – présentés au
chapitre précédent.
Les résultats du chapitre précédent pour le cas multiprocesseur ont eu comme base de
départ les assertions suivantes concernant l’exécution des tâches par une plate-forme
multiprocesseur :
•
l’exécution de la tâche n’est pas associée à un processeur déterminé et, aux
activations (retours de préemption) différentes de la même tâche, son exécution
117
Chapitre IV
Sur les aspects du noyau et de l’implantation …
peut se poursuivre sur un processeur quelconque ;
•
à tout instant une tâche ne peut s’exécuter que sur un seul processeur.
La structure du système multiprocesseur doit être adaptée aux restrictions présentées
dans la sous-section III.2.3 : une plate-forme multiprocesseur hétérogène à mémoire
commune, dans le sens où la valeur de la vitesse de chaque processeur est bornée
inférieurement par une valeur minimale S MIN qui assure le fonctionnement du système, et
supérieurement par la valeur maximale S MAX admise par le système ; aucune autre contrainte
n’est imposée en préalable sur la vitesse de chaque processeur (conformément au Chapitre
II, ces conditions correspondent à une machine parallèle sans relation entre le processeur et la
tâche qui lui est affectée).
Pour des raisons de synchronisation dans la communication entre les processeurs, une
deuxième condition sur les vitesses des processeurs doit être respectée : le fonctionnement des
processeurs est basé sur une horloge commune, utilisée comme « base de temps absolue » ;
par la suite, l’horloge propre de chaque processeur est ajustée à un multiple ou diviseur de
l’horloge commune.
Ces assertions ont été énnoncées pour étudier le cas le plus général ; cependant,
certains résultats ont été obtenus pour des cas plus particuliers. Par exemple, les cas pour
lesquels l’exécution des tâches est assignée aux processeurs (la migration des tâches entre les
processeurs est interdite). En étudiant les différentes plates-formes proposées par RTAI et les
ordonnanceurs associés, nous essayerons de déterminer :
pour les cas traités dans le chapitre précédent, la proposition de plate-forme de
RTAI la plus appropriée ;
la possibilité – pour ce système d’exploitation – de fonctionner sur des platesformes ayant des processeurs fonctionnant à des vitesses différentes ;
les inconvénients issus de l’implantation donnée par RTAI à ces plates-formes, qui
pourraient conduire à certaines différences entre les résultats théoriques et des
résultats obtenus dans la pratique.
IV.2.1.1. Les principes de fonctionnement des ordonnanceurs proposés par RTAI
La distribution de RTAI inclut trois types d’ordonnanceur, qui correspondent à trois
types de plates-formes : Uni-Processor (UP), Multi Uni-Processor (MUP) et Symetric MultiProcessor (SMP). Pour chacun des cas d’architecture proposés, l’ordonnanceur est implanté
par un fichier rtai_sched.c spécifique, et s’exécute suite à l’appel rt_schedule(). Ces
trois ordonnanceurs sont basés sur la notion de priorité des tâches et de préemption, et
comprennent les services standards pour les ordonnanceurs temps réel (resume, yield,
suspend, make_periodic, wait_until, …).
Les MUP et SMP font référence à des plates-formes multiprocesseur. Le système
d’exploitation utilise différentes techniques pour traiter les problèmes de parallélisme : l’accès
mémoire, la cohérence du cache, les E/S. L’optimisation de leur implantation de point de vue
de la durée d’exécution et donc de la consommation d’énergie conduit à d’autres domaines de
recherche, comme par exemple la gestion des ressources ou la gestion de la mémoire, qui ne
constituent pas le sujet de cette thèse.
La différence entre SMP et MUP est donnée par la manière dont les tâches prêtes à
s’exécuter sont prises en compte par l’ordonnanceur :
118
Chapitre IV
Sur les aspects du noyau et de l’implantation …
•
Le SMP est caractérisé par l’utilisation d’une seule liste d’attente pour les tâches
prêtes à s’exécuter : ainsi toute tâche prête s’exécute dès que possible, en fonction
de sa priorité et de l’algorithme d’ordonnancement mis en place, sur n’importe
quel processeur disponible.
•
Le MUP est basé sur plusieurs listes de tâches prêtes à s’exécuter, une liste par
processeur. L'exécution entière de l'application est décidée par le développeur,
dans le sens où l’affectation de chaque tâche à un processeur est définie dès le
début. Il existe aussi la possibilité de migration des tâches entre processeurs, mais
par rapport au SMP cette migration se fait selon le choix du développeur, à l’aide
des fonctions : rt_set_runnable_on_cpus.
L’ordonnanceur UP (répertoire upscheduler dans la distribution 24.1.9) est destiné
aux plates-formes monoprocesseur. Dans le cas d’une machine x86, son horloge est basée sur
le « timer » classique Intel 8254. Il fonctionne soit en mode mono-coup (angl. « one-shot »),
soit en mode périodique (les notions sont explicitées dans la sous-section §IV.2.2.1).
L’ordonnanceur SMP (répertoire smpscheduler) supporte également les « timers »
8254 ou APIC (Automatic Programmable Interface Controller), et il peut fonctionner en mode
mono-coup ou périodique. Le choix se fait à l’installation de l’application, par le module
générique rtai_sched.o. Le chargement des tâches et le traitement des interruptions sont
similaires aux opérations équivalentes de Linux SMP. Par défaut, toutes les tâches sont
susceptibles de s’exécuter sur n’importe quel processeur et elles commutent automatiquement
entre les processeurs conformément aux algorithmes d’ordonnancement et à la charge du
système ; elles peuvent également être assignées à un processeur ou à un ensemble de
processeurs à l’aide de deux fonctions : rt_set_runnable_on_cpus et
rt_set_runnable_on_cpuid [RTp 03].
L’ordonnanceur MUP (répertoire mupscheduler) est conçu exclusivement pour les
plates-formes multiprocesseurs ; il supporte simultanément les ordonnancements mono-coup
et périodique. Les ordonnancements périodiques peuvent être basés sur des périodes
différentes. Les tâches temps réel doivent être assignées aux processeurs depuis leur
initialisation. Elles peuvent être transférées d’un processeur à l’autre à l’aide de
rt_set_runnable_on_cpuid, mais non à un ensemble de processeurs comme sur une
plate-forme SMP [RTp 03].
Les fonctions qui permettent l’assignation des tâches aux processeurs (d’où une
commutation imposée en MUP, ou une assignation imposée en SMP, comme on l’a
mentionné) sont :
• rt_set_runnable_on_cpus : permet de spécifier un ensemble de processeurs à
partir desquels sera choisi celui sur lequel la tâche sera exécutée. Cette fonction
donne à la variable runnable_on_cpus, incluse dans la structure de la tâche, le
« bit map » des processeurs utilisables ; par défaut, à l’initialisation des tâches, sa
valeur est cpu_present_map, ce qui signifie que tout CPU disponible peut être
utilisé [RTp 03].
• rt_set_runnable_on_cpuid : permet de spécifier le seul processeur qui
exécutera la tâche [RTp 03].
Par contre, il faut préciser que si aucun des processeurs choisis n’est disponible,
l’appel de la tâche sélectionnera un autre processeur disponible (s’il y a en un) pour son
exécution.
De la même manière, tout service d’interruption spécifique au temps réel peut être
assigné à un processeur spécifié ; les fonctions permettant de le faire sont :
119
Chapitre IV
•
•
Sur les aspects du noyau et de l’implantation …
rt_assign_irq_to_cpu;
rt_reset_irq_to_sym_mode.
Dans les deux cas d’ordonnancement multiprocesseurs, SMP et MUP, les différents
services habituels de communication entre les processeurs sont disponibles (sémaphores,
messages, boites aux lettres).
IV.2.1.2. Les ordonnanceurs proposés par RTAI les plus appropriés pour les résultats sur
la consommation optimale d’énergie
Dans cette section nous nous sommes intéressés à mettre en concordance les résultats
sur la consommation optimale d’énergie obtenus au Chapitre III et les plates-formes RTAI : la
version existante de plate-forme la plus appropriée pour chaque résultat, les manques au
niveau de la conception de la plate-forme par rapport aux suppositions effectuées, les
spécificités des plates-formes – dues exclusivement à leur conception – qui pourraient
empiéter l’équivalence entre les résultats théoriques et les résultats réels (i.e. des suppositions
supplémentaires par rapport aux suppositions utilisées par les résultats théoriques).
Le Tableau IV.1 trie les résultats du Chapitre III par rapport aux suppositions
effectuées sur le type de plate-forme à utiliser, y compris la distribution des tâches sur les
processeurs, et indique les plates-formes RTAI les plus appropriées. La deuxième colonne du
tableau, « Type de plate-forme demandée/nécessaire », a des implications aussi au niveau du
matériel – et nous reviendrons sur cet aspect dans la section IV.3 et dans le Tableau IV.2 –
qu’au niveau du système d’exploitation et de l’implantation de l’application, et elles sont
prises en compte dans la troisième colonne de ce tableau.
Note : Les plates-formes RTAI sont actuellement conçues pour un fonctionnement à vitesse
constante et identique pour tous les processeurs. A notre connaissance, c’est aussi le cas de tous
les systèmes d’exploitation multiprocesseur existants, et il en est de même pour les plates-formes
physiques.
Nous précisons que les résultats pris en compte ici sont ceux liés à la solution statique
proposée pour différents modèles de tâches. Ceci suppose la connaissance a priori des vitesses
d’exécution des tâches. Ainsi, le changement de la vitesse du/des processeur(s) peut être
prévu a priori, c'est-à-dire au lancement de l’exécution de l’application, et pris en compte
dans l’implantation de l’application, dans la configuration initiale du noyau, par des
fonctions appropriées à développer.
Résultats obtenus
dans le Chapitre III
Type de plate-forme
demandée/nécessaire
L’offre du RTAI et
modifications proposées
Théorème III.1’,
Lemme III.2,
Théorème III.5
Monoprocesseur,
à
vitesse UP adapté pour prendre en
variable en ligne, en fonction de la compte la variation de la
tâche, les vitesses étant connues a vitesse du processeur.
priori.
Proposition III.1’,
Corollaire III.5,
Théorème III.14,
Monoprocesseur,
à
constante à tout moment.
120
vitesse UP
Chapitre IV
Sur les aspects du noyau et de l’implantation …
Corollaire III.7
Théorème III.3,
Théorème III.4
Monoprocesseur, sans précisions UP adapté pour prendre en
sur la vitesse.
compte la variation de la
vitesse du processeur.
Théorème III.6,
Corollaire III.3,
Théorème III.9,
Théorème III.13,
Corollaire III.4,
Théorème III.15
Multiprocesseur, à vitesse variable
en fonction du processeur, mais
constante pour chaque processeur
et connue a priori.
Proposition III.2
Multiprocesseur, à vitesse variable MUP adapté pour prendre en
en fonction du processeur et de la compte la variation de la
vitesse de chaque processeur.
tâche.
Migration des tâches interdite.
Synchronisation
entre
processeurs
au
début
l’exécution de chaque tâche.
SMP adapté pour permettre
aux processeurs d’avoir des
vitesses
différentes,
mais
constantes
pour
chaque
processeur et connues a priori.
La synchronisation entre les
processeurs au début de
les
l’exécution de chaque tâche.
de
Théorème III.7,
Proposition III.3,
Théorème III.8
Multiprocesseur, à vitesse variable SMP adapté pour prendre en
en fonction du processeur et de la compte la variation de la
vitesse de chaque processeur.
tâche.
Théorème III.10,
Théorème III.11,
Théorème III.12.
Multiprocesseur, à vitesse variable SMP adapté pour prendre en
en fonction du processeur et de la compte la variation de la
vitesse de chaque processeur.
tâche.
Migration interdite pour certaines Assignations de certaines
tâches aux processeurs.
tâches.
Tableau IV.1. Plates-formes RTAI proposées pour la validation
des résultats obtenus au Chapitre III.
Les notes suivantes attirent l’attention sur quelques difficultés spécifiques à
l’implantation d’une application temps réel à des contraintes strictes.
Note : Une attention particulière pendant la phase de conception, notamment pour
l’identification du scénario réel des tâches, doit être prêtée aux situations où certaines tâches sont
assignées aux processeurs à l’aide d’une des deux fonctions rt_set_runnable_on_cpus et
rt_set_runnable_on_cpuid, les autres pouvant changer le processeur. L’attention doit être
focalisée aussi sur la disponibilité des processeurs ayant des tâches assignées. Selon
l’implantation actuelle des ordonnanceurs MP et des deux fonctions mentionnées, en cas
d’indisponibilité du processeur, un autre processeur disponible peut être choisi. Ceci pourrait
modifier le scénario théorique et pourrait détourner certains résultats (voir par exemple les
Théorèmes. III.10, III.11, III.12).
D’autre part, la migration non prévue des tâches entre les processeurs entraîne des
coûts supplémentaires, autant dans la durée effective d’exécution des tâches concernées que
dans la consommation énergétique. Cette situation pourrait conduire à des coûts différents
121
Chapitre IV
Sur les aspects du noyau et de l’implantation …
pour la même tâche. Par conséquent, pour une meilleure estimation préalable de l’exécution
de l’application et de sa consommation, il est nécessaire de prévoir ce cas dans la phase de
développement, au moins par une prise en compte dans les coûts d’exécution pire cas des
tâches.
Note : Dans l’estimation des coûts des tâches dans la phase de conception, la durée de
commutation entre les processeurs doit être aussi gérée, autant pour une transposition plus
approchée du scénario théorique des tâches par rapport au scénario réel, que pour les évaluations
énergétiques dues à l’exécution des tâches. Nous y reviendrons dans §IV.2.3.2.
Note : Le principe de la solution dynamique (voir §III.2.3.3) est le suivant : pour une plate-forme
donnée, à partir de la solution statique optimale, chaque fois qu’une tâche achève son exécution
plus tôt que prévu, l’exécution de la tâche suivante est ralentie afin de charger au maximum le(s)
processeur(s). Suite à l’application de la solution dynamique telle quelle, des anomalies pourraient
apparaître pour le cas multiprocesseur (voir §II.3.4.2, §III.5.3). Il est évident que ces aspects
devraient tout d’abord être couverts par une étude théorique plus approfondie concernant les
anomalies. Ensuite il faudrait que, par leur conception, les plates-formes envisagées aient des
caractéristiques qui puissent leur assurer un fonctionnement à des vitesses variables en ligne.
Après une description des plates-formes proposées par RTAI (§IV.2.1.1), on a
pu constater (§IV.2.1.2) que le fonctionnement des ordonnanceurs proposés
semble adapté aux types de machines multiprocesseur demandés par la
solution statique de la consommation optimale, pour les différents modèles de
tâches traités dans le chapitre précédent. On a aussi présenté des
particularités qui devraient être prises en compte dans la phase d’analyse de
l’application, ainsi que quelques fonctionnalités qui devraient être ajoutées au
noyau.
IV.2.2. L’influence de l’ordonnanceur et des politiques d’ordonnancement sur
la consommation d’énergie
Nous nous sommes intéressé dans cette section à deux aspects qui concernent le
fonctionnement de l’ordonnanceur : l’influence du coût de l’ordonnanceur et des politiques
d’ordonnancement sur la consommation énergétique.
IV.2.2.1. Le coût de l’ordonnanceur et la consommation énergétique des tâches
Pour ce qui concerne le coût de l’ordonnanceur, on a énoncé certaines remarques dans
la section §III.4.2 du chapitre précédent. On a précisé qu’en ce qui concerne ce coût, la
théorie de l’ordonnancement n’indique pas où et comment il est pris en compte, bien qu’il
détermine le scénario effectif des tâches d’une part et sur la consommation énergétique des
tâches d’autre part.
Le coût de l’ordonnanceur est le coût dû à l’exécution des lignes de code du noyau
spécifiques à la politique d’ordonnancement. Ces lignes de code ne constituent pas une tâche
supplémentaire du système. Dans le cadre de RTAI, l’ordonnancement se poursuit suite à
122
Chapitre IV
Sur les aspects du noyau et de l’implantation …
l’appel système rt_schedule() issu des tâches, ou de l’activation du « timer ». La tâche en
état " PRET " ayant la plus grande priorité est choisie pour être exécutée. Les priorités vont de
0, la plus grande, à 0x3fffFfff, la plus petite ; Linux a la priorité 0x7fffFfff. Au niveau
du fonctionnement de Linux et RTAI ces lignes sont exécutées pour le compte du processus
(i.e. tâche) qui a été interrompu. Cela suggère que l’exécution de l’ordonnanceur doit être
prise en compte dans l’estimation du temps d’exécution de la tâche qui a été interrompue
pour l’exécution de l’ordonnanceur. Ainsi, le coût de l’ordonnanceur retrouve sa place dans
le coût total d’exécution des tâches et il dépend :
du modèle prévu des tâches,
du nombre de processeurs (pour une plate-forme SMP),
de la fréquence de lancement de l’ordonnanceur et
de la politique d’ordonnancement implantée.
Il est évident que, parmi ces aspects qui déterminent le coût d’ordonnancement et
implicitement les coûts des tâches, la politique d’ordonnancement a plusieurs implications.
Ainsi, dans un système à échéances strictes, elle doit être soigneusement choisie en fonction
du modèle réel des tâches ; nous y reviendrons dans la sous-section suivante.
La fréquence d’exécution des lignes de l’ordonnanceur est donnée par le type
d’ordonnancement choisi et par l’activité du système. RTAI propose deux types
d’ordonnancement, parmi lesquels le choix se fait à l’aide d’une des deux fonctions suivantes:
• rt_set_oneshot_mode(): initialise le timer en mode mono-coup ; i.e. donne
une temporisation variable aux tâches, basée sur la fréquence du processeur et qui
permet une allocation arbitraire du temps processeur aux tâches ;
• rt_set_periodic_mode(): initialise le timer en mode périodique ; i.e. une
temporisation fixe des tâches, multiple de la période définie par l’appel du
start_rt_timer. La résolution est donnée par le « timer » 8254 ou par le APIC
local, en fonction duquel le timer a été programmé. Le fonctionnement par défaut
est périodique ; l’arrêt du « timer » (stop_rt_timer) remet l’ordonnanceur à son
fonctionnement par défaut.
Note : Le choix entre les deux types d’ordonnancement est à faire en fonction de la politique
d’ordonnancement. Selon notre opinion, afin de ne pas ajouter des temps processeur non utilisés
ou de ne pas augmenter artificiellement le nombre d’activations de l’ordonnanceur, il semble plus
judicieux d’utiliser le mode « one-shot » pour les algorithmes d’ordonnancement dynamique
(EDF, LLF) et éventuellement le mode « périodique » pour d’autres politiques
d’ordonnancement.
IV.2.2.2. Les politiques d’ordonnancement et la consommation énergétique des tâches
Les politiques d’ordonnancement ont plusieurs implications sur la consommation
énergétique des tâches. Tout d’abord, nous passons en revue les politiques proposées par
RTAI, pour réaliser ensuite la connexion avec les résultats du chapitre précédent, sur la
consommation d’énergie.
A partir de la version 24.1.6 de RTAI, plusieurs politiques d’ordonnancement (voir
§IV.2.1.1) ont été proposées pour les trois plates-formes UP, SMP et MUP. Le choix se fait à
l’aide de la fonction :
123
Chapitre IV
Sur les aspects du noyau et de l’implantation …
rt_set_sched_policy(RT_TASK *task, int policy, int rr_quantum_ns), où
policy, le choix de la politique, se fait en indiquant l’une des politiques suivantes, définies
dans rtai_sched.h :
• RT_SCHED_FIFO : est la politique par défaut ;
• RT_SCHED_RR : Round Robin, avec des quantum de temps (rr_quantum_ns)
•
•
alloués aux tâches ;
RMS : Rate Monotonic Scheduling - la tâche périodique ayant la fréquence la plus
élevée est la plus prioritaire ;
EDF : la tâche ayant la plus proche échéance est la plus prioritaire ; pour son
utilisation, les tâches doivent faire appel à la fonction :
void rt_task_set_resume_end(RTIME resume_time, RTIME end_time)
à la fin de chaque exécution.
Evidemment, le choix de modifier le noyau RTAI et d’y ajouter d’autres algorithmes,
appropriés à une application particulière, est dévolu à chaque développeur. Par la suite nous
précisons certaines situations où cela s’avérera nécessaire.
Pour ce qui concerne les résultats présentés au Chapitre III, on en note un seul qui
concerne explicitement les politiques d’ordonnancement ; c’est le Théorème III.3 qui indique
l’optimalité énergétique de EDF dans le cas des tâches indépendantes, pour une plate-forme
monoprocesseur. Les autres résultats liés directement à l’optimalité énergétique
d’ordonnancement donnent des informations sur les vitesses d’exécution des tâches,
l’ordonnancement proprement dit restant à trouver par des techniques classiques. Si le modèle
de tâches et la machine à utiliser correspondent à ceux mentionnés par le Théorème III.3,
alors EDF est utilisé, ou éventuellement sa version adaptée aux vitesses variables selon les
tâches. Pour les autres modèles de tâches et d’autres types de plates-formes, il faut d’abord
trouver la solution théorique concernant l’ordonnancement énergétique optimal.
Le Théorème II.10 indique l’optimalité énergétique de EDF parmi les algorithmes
d’ordonnancement en ligne, du point de vue du nombre des commutations de contexte. Notons
ici que le coût d’une commutation de contexte est constant et ne dépend en aucun cas de
l’algorithme d’ordonnancement.
Le Théorème III.3 concerne l’ordonnancement donné par EDF où, comme on l’a
précisé dans §IV.2.2.1, les coûts des tâches prennent en compte le coût de EDF. Notons aussi
qu’afin de permettre la comparaison qui a été faite avec des ordonnancements proposés par
d’autres algorithmes, il a été supposé que les coûts des tâches sont les mêmes. Bien sûr, c’est
le cas d’une estimation pire-cas pour les coûts d’exécution des tâches. Une analyse plus fine
(à laquelle on souhaite arriver) soulève d’autres aspects, présentés par la suite.
Selon l’implantation de l’algorithme d’ordonnancement, plus précisément des
structures de données utilisées pour la gestion des files d’attente des tâches, l’ordonnanceur
peut avoir des coûts différents, selon le nombre de tâches présentes dans les différents files
d’attente aux moments de ses activations. Cette situation n’est pas désirable dans le cas d’une
application temps réel à échéances strictes. Deux solutions peuvent être envisagées afin de la
surmonter :
1. intervenir au niveau du code du noyau afin de mettre le coût de l’ordonnanceur
indépendant du nombre de tâches existantes dans système, et
2. connaître, pour l’ensemble effectif des tâches de l’application, les conditions
exactes de lancement de l’ordonnanceur, afin de réaliser une évaluation (plus)
précise de son coût.
124
Chapitre IV
Sur les aspects du noyau et de l’implantation …
Bien que difficile à mettre en œuvre, ces deux solutions méritent une étude applicative
approfondie. Sans entrer dans des détails, nous mentionnons juste que, pour le premier cas, il
s’agit plutôt de chercher à trouver les structures de données et les techniques de gestion les
plus appropriées ; il s’agit donc de techniques de programmation à trouver et à mettre en
œuvre pour RTAI et Linux, étant connu que la gestion des files d’attente est celle d’une liste
chaînée typique. Le deuxième cas est effectivement dépendant, dans sa réalisation, du modèle
de tâches, de la politique d’ordonnancement et du type d’ordonnanceur ; la difficulté est
donnée ici par la possibilité d’arriver à des situations où ces trois aspects mentionnés
conduisent à l’impossibilité réelle de trouver une réponse pratique à ce cas. Une étude
théorique plus approfondie est envisageable.
La section IV.2.2 a mis en évidence le fait que le coût de l’ordonnancement est
lié au modèle de tâches, au nombre de processeurs, à la fréquence de
lancement de l’ordonnanceur et à la politique d’ordonnancement implantée
(§IV.2.2.1). Les deux types d’ordonnancement proposés par RTAI, mono-coup
et périodiques, permettent de choisir le plus approprié pour le modèle de
tâches. Les liaisons réalisées avec les résultats du Chapitre III (§IV.2.2.2) ont
permis de montrer certains aspects qui devraient être approfondis : obtenir des
résultats théoriques sur l’optimalité de l’ordonnancement pour différents types
de plates-formes et de modeles de tâches, adapter le code de l’ordonnanceur
afin d’obtenir un coût d’exécution constant et indépendant du nombre de
tâches, connaître le scénario réel de tâches y compris les situations exactes de
lancement de l’ordonnanceur. Sur ce dernier aspect d’autres informations
seront précisées par la suite.
IV.2.3. L’implantation de l’application et la consommation énergétique
Afin de permettre une estimation a priori de la consommation énergétique, il est
nécessaire d’étudier l’application du point de vue du système d’exploitation, ce qui suppose
une bonne connaissance de celui-ci en fonction de la plate-forme utilisée. Pour arriver à cette
estimation on doit connaître le modèle réel de tâches, i.e. connaître, à part les tâches de
l’application, si le système d’exploitation en induit lui-même d’autres afin d’assurer le
fonctionnement désiré de l’application. Aussi, pour l’évaluation des coûts des tâches, autant
temporelle qu’énergétique, il faut également connaître la modalité dont les autres services du
noyau demandés par l’application interviennent dans le scénario des tâches. Dans cette section
nous montrons comment ces aspects liés à l’implantation d’une application temps réel à
échéances strictes peuvent être identifiés, en utilisant le RTAI.
IV.2.3.1. L’espace noyau, l’espace utilisateur, l’application temps réel et la consommation
énergétique
Au niveau de la sous-section §II.4.2 de « l’Etat de l’art » on a présenté les principes de
fonctionnement des deux modes du processeur, avec les deux espaces mémoire associés :
utilisateur et système. Toute partie de code qui peut être ajoutée au noyau pendant le
fonctionnement du système est appelée module. Le rôle d’un module est d’étendre les
fonctionnalités du noyau ; son code s’exécute dans l’espace noyau. RTAI est constitué par des
modules. De plus, conformément à son guide de programmation [RTp 03], l’implantation
125
Chapitre IV
Sur les aspects du noyau et de l’implantation …
d’une application temps réel à l’aide de RTAI se fait par l’utilisation d’un module noyau qui
configure le fonctionnement du noyau RTAI et lance les tâches temps réel. Par défaut, toute
tâche RTAI s’exécute dans l’espace noyau (comme l’indique d’ailleurs la Figure II.16 de
§II.4.3.2), à l’exception des tâches développées en utilisant le module LXRT de RTAI,
spécialement conçu pour le développement d’applications dans l’espace utilisateur. Pour
cela, si une tâche demande un service qui n’est pas offert par RTAI mais par Linux (ex. le
pilote d’un périphérique implanté seulement sous Linux) alors il apparaîtra la nécessité de
commutation entre les deux espaces. Comme on a vu dans §II.4.2, le passage de l’espace
utilisateur vers l’espace noyau ou vice-versa est tout à fait possible, mais basculer d’un niveau
à l’autre entraîne la commutation d’un nombre de portes, d’où une durée d’exécution et une
consommation d’énergie plus élevées que pour le cas où toutes les fonctions pourraient
s’exécuter en restant dans le même espace. Pour éviter cette consommation supplémentaire, il
serait donc souhaitable de permettre à RTAI de gérer tout service nécessaire au
fonctionnement de l’application. Le développement de l’application au niveau de l’espace
noyau a un deuxième avantage : une durée plus courte d’exécution pour les appels système,
du fait qu’il n’y a pas de commutation d’un espace à l’autre (voir [RUB 00] pour un exemple
estimatif).
IV.2.3.2. Le modèle réel des tâches
Un autre aspect lié à l’implantation est « le modèle réel de tâches ». Dans le processus
de développement d’une application, on parle de modèle théorique des tâches pour faire
référence au modèle des tâches issues de la conception de l’application. Ce modèle reste
incomplet et inapproprié aux évaluations, autant sur la faisabilité de l’application que sur la
consommation énergétique, tant qu’il n’a pas été transposé au niveau système, pour y ajouter
toute tâche système intervenant et pour pouvoir estimer le fonctionnement donné par le
système d’exploitation et ses services. Nous parlerons du modèle réel des tâches pour le
modèle qui comprend aussi les tâches système. C’est à cet aspect que nous nous intéressons
dans cette sous-section.
Les tâches proprement dites d’une application RTAI sont déclarées à l’aide de la
fonction suivante, dans le module qui lance l’application [LIS 00] :
#include "rtai_sched.h"
rt_task_init (
// tâche
RT_TASK *task,
void (*rt_thread)(int), // code du thread
int data,
// paramètre d’appel du thread
int stack_size,
// taille de la pile
int priority,
// priorité de la tâche
int uses_fpu,
// 0 = sans FPU, 1 = avec FPU
void (*signal)(void)) ; // fonction appelée dans le contexte de la tâche,
// chaque fois que celle-ci devient active
La programmation des tâches apériodiques et/ou sporadiques se fait à l’aide des
fonctions suivantes : rt_task_init – pour initialiser une tâche, rt_task_resume – pour
reprendre l’exécution d’une tâche, rt_task_yield – pour rendre la main au scheduler,
rt_task_delete – pour supprimer une tâche, rt_task_make_periodic – pour rendre
une tâche périodique et rt_task_wait_period – pour rendre la main jusqu’à la période
suivante.
126
Chapitre IV
Sur les aspects du noyau et de l’implantation …
A part les tâches temps réel (créées à l’aide des fonctions mentionnées), d’autres
lignes de code ne leur appartenant pas s’exécutent dans le système, et dans une évaluation du
scénario réel elles doivent être prises en compte. Il s’agit en principe du code du noyau. Dès
le début il faut préciser que le noyau (qu’il soit RTAI ou autre) n’est pas un processus par luimême. Il représente une collection de structures de données et de routines, chargées
constamment dans la mémoire, qui assurent le fonctionnement du système. Son code
s’exécute suite à des appels système si l’application proprement dite s’exécute en mode
utilisateur.
Un appel système représente une fonction du noyau qui est appelée à partir de
l’espace utilisateur, et c’est le seul moyen d’utiliser le noyau à partir de cet espace. Le code du
noyau qui correspond à un appel système fonctionne dans le contexte du processus appelant.
Sous RTAI, la notion d’appel système existe dans le contexte d’une application développée
avec LXRT, qui permet l’utilisation de fonctions RTAI à partir de l’espace utilisateur. Toutes
les fonctions déclarées dans rtai_lxrt.h utilisent l’interruption logicielle int 0xFC. Du
point de vue de l’optimisation de l’exécution de l’application – autant temporelle
qu’énergétique – nous considérons cette approche de développement restrictive, car :
•
les tâches LXRT sont prises en compte par l’ordonnanceur FIFO de Linux, avec
ses niveaux de priorité de 1 à 99 (donc il n’y a pas de flexibilité au niveau des
choix d’ordonnancement) ;
•
la durée de la commutation de contexte est plus grande que dans une implantation
directe sous RTAI, dans l’espace noyau.
En conséquence, la discussion sur les applications RTAI fera toujours référence aux
applications de l’espace noyau, prises en compte par l’ordonnanceur RTAI. Sous RTAI, les
tâches temps réel s’exécutant au niveau noyau peuvent faire un appel direct (i.e. sans passer
par un changement d’espace) aux différentes fonctionnalités du noyau liées aux appels
système. Notons que les coûts de ces fonctionnalités peuvent être constants ou variables. La
variation d’un coût peut être due à la tâche qui fait l’appel (coût constant pour la même tâche,
mais différent d’une tâche à l’autre, cas où il peut être estimé a priori), ou au matériel (par
exemple à la vitesse d’accès au disque dur si nécessaire, à la gestion de la mémoire, etc.).
Les tâches système sont les « threads » noyau ; ces « threads » sont habituellement
connus sous le nom de daemons. Les daemons sont lancés par le premier processus de Linux,
init, au démarrage du système, et ils sont mis en attente de l’expiration périodique du
« timer » noyau associé. Les daemons Linux les plus utilisés sont : crond – qui gère
l’exécution des tâches périodiques, keventd – qui exécute les tâches à partir de la file
d’attente d’ordonnancement, lpd – pour la gestion des impressions, inetd – le daemon
principal du réseau, et sendmail – pour l’échange de courrier à travers le réseau.
Dans une application temps réel sous RTAI, afin de ne pas passer par le contrôle de
Linux pour certains services comme ceux offerts par les daemons, il est préférable de
transférer leur contrôle sous la gestion directe de RTAI. Ensuite :
•
tous les daemons existants dans le système durant l’exécution de l’application
temps réel doivent être pris en compte en tant que tâches système pour l’analyse
du scénario réel de tâches dans une application temps réel ;
•
pour assurer l’exécution de l’application, la configuration du noyau ne doit
contenir que les daemons indispensables à celle-ci. Tout autre daemon, même s’il
127
Chapitre IV
Sur les aspects du noyau et de l’implantation …
n’est pas effectivement utilisé, restant actif dans le système, change le scénario
réel des tâches par son activation, et par ailleurs augmente inutilement la
dimension du système et la consommation d’énergie.
L’interruption est un signal que le matériel peut envoyer lorsqu’il veut attirer
l’attention du processeur. Linux gère les interruptions dans l’espace utilisateur. Il est
préférable donc de transférer la gestion des interruptions, autant matérielles que logicielles,
au niveau de RTAI, comme l’indique la Figure II.16. Le code qui gère les interruptions n’est
lié à aucun processus particulier. En conséquence, pour l’évaluation du scénario réel de
tâches, les interruptions doivent être prises en compte ailleurs que dans le cadre d’une tâche.
Les considérer comme tâches sporadiques semble la solution la plus judicieuse, bien qu’elles
n’aient pas l’aspect d’une tâche effective (e.g. n’ont pas la structure d’une tâche). Elles
peuvent aussi bien être périodiques dans le cas où il est connu que le signal qui déclanche
l’interruption intervient de manière périodique.
Le chapitre précédent a traité uniquement le cas des tâches indépendantes. Néanmoins,
des problèmes d’exclusion mutuelle ou de synchronisation entre les tâches peuvent apparaître
dans certains cas, et par conséquence le problème de communication entre les tâches doit
être pris en compte. RTAI fournit les services habituels de communications entre les tâches
(sémaphores, boites aux lettres, passage de messages ; voir le module rtai) et ces
communications restent au niveau noyau. Les services qui correspondent à ces fonctions
seront, évidemment, pris en compte dans le coût de la tâche qui fait l’appel. Nous ne
disposons pas d’informations ni sur les valeurs temporelles ni énergétiques de ces coûts. Nous
nous limitons ici à exprimer des hypothèses dont il faudra tenir compte dans toute analyse
d’évaluation énergétique préalable. En même temps, ces hypothèses ouvrent autant de
propositions de validation par la pratique, sur des plates-formes différentes. Il est évident que
les coûts de communication entre les tâches dépendent de la plate-forme utilisée et donc
restent à être évalués pour chaque cas particulier. D’autre part, certaines de ces fonctions
peuvent avoir un coût constant pour une plate-forme, et d’autres un coût variable. Il est
également possible que les coûts soient variables sur une plate-forme multiprocesseur (et
aussi plus élevés que dans le cas monoprocesseur) si la communication se fait entre des
tâches exécutées par le même processeur ou entre des tâches assignées à des processeurs
différents. Voila donc autant de situations à vérifier par expérimentation afin de permettre
une meilleure estimation du pire-temps d’exécution des tâches et du scénario réel, et
implicitement du coût énergétique induit.
Les résultats concernant la solution statique sur la consommation d’énergie présentés
au Chapitre III ont eu à la base l’idée de charger au maximum le(s) processeur(s). Malgré
cela, étant donné que toute évaluation est basée sur le pire-cas d’exécution des tâches, il se
peut qu’à certains moments, même si cela n’a pas été prévu, la tâche de fond qui existe dans
tout système d’exploitation s’exécute. Cela pourra conduire à des différences entre les
estimations théoriques et les évaluations pratiques de la consommation. Au niveau de RTAI,
Linux est considéré en tant que tâche de fond. Si sous Linux aucune tâche proprement dite ne
s’exécute, alors c’est le processus initial de Linux (init) qui sera exécuté en tant que tâche
de fond pour le compte de l’application développée sous RTAI.
128
Chapitre IV
Sur les aspects du noyau et de l’implantation …
La section IV.2.3 a mis en évidence certains aspects liés à
l’implantation effective d’une application temps réel sous RTAI afin de
minimiser la consommation énergétique. L’idée principale est que l’exécution
de l’application doit se dérouler entièrement dans l’espace noyau : les tâches
proprement dites, aussi bien que toute tâche (service) système demandées pour
le bon fonctionnement de l’application. Il est donc important que tout service
offert par Linux et demandé par l’application temps réel soit implanté sous la
gestion de RTAI. Il est aussi évident que la configuration du noyau doit
contenir seulement les services indispensables à l’application.
Un deuxième constat consiste en ce que pour l’évaluation préalable du
coût énergétique, un même processus doit être suivi pour l’estimation de la
faisabilité du système du point de vue de l’ordonnancement des tâches. La
modalité d’identifier le modèle réel des tâches a été passée en revue, ainsi que
les façons de traiter tous les facteurs intervenant pour minimiser le coût
énergétique : identification et implantation des tâches proprement dites de
l’application et des tâches système – les daemons, les interruptions –, la
communication entre les tâches, la tâche de fond.
IV.3. Vers des validations physiques
Le but de cette section est de montrer qu’il existe des plates-formes physiques
appropriées, ainsi que des outils logiciels qui pourraient permettre une validation des résultats
sur la consommation énergétique présentés au Chapitre III. Point de départ pour des potentiels
projets de validation, la présentation réalisée se contentera de suggérer quelques propositions
de plates-formes et d’outils, en faisant le lien avec les résultats correspondants.
Comme il a déjà été suggéré par les suppositions introduites au Chapitre III, notre
approche va vers l’utilisation des microprocesseurs (§III.2) pour des plates-formes mono ou
multiprocesseur, et dans ce dernier cas, plus précisément des SoC (angl. System on Chip),
afin de réduire tout coût entraîné par la migration des tâches entre les processeurs. Les
alternatives à l’utilisation des microprocesseurs pourraient être les FPGA (angl. FieldProgrammable Gate Array) ou la logique classique ; cependant, les formes de la fonction de
consommation énergétique utilisées dans l’étude théorique développée au Chapitre III sont
spécifiques pour les processeurs. D’autre part, du point de vue pratique, les microprocesseurs
actuels sont très puissants, la même logique permet de réaliser des fonctions différentes et la
conception pour des familles de produits est simplifiée. De plus, les microprocesseurs
modernes ont certaines caractéristiques qui leur permettent de contrôler la puissance dissipée
– un bref état de l’art sur le sujet a été présenté dans §III.2.1.
Nous allons donc reprendre les deux premières colonnes du Tableau IV.I, pour en
ajouter une troisième, concernant les plates-formes physiques et leurs outils caractéristiques.
Cette troisième colonne sera explicitée dans les sections suivantes.
129
Chapitre IV
Sur les aspects du noyau et de l’implantation …
Résultats obtenus
dans le Chapitre III
Type de plate-forme
demandée/nécessaire
Plate-forme physique et
outils de développement
Théorème III.1’,
Lemme III.2,
Théorème III.5
Monoprocesseur, à vitesse variable
en ligne, en fonction de la tâche, les
vitesses étant connues a priori.
Transmeta Crusoe™
[TRA 03]
Proposition III.1’,
Corollaire III.5,
Théorème III.14,
Corollaire III.7
Monoprocesseur, à vitesse constante
à tout moment.
Tout processeur ayant la
vitesse ajustée a priori
Théorème III.3,
Théorème III.4
Monoprocesseur, sans précisions sur
la vitesse.
Tout processeur ayant la
vitesse ajustée a priori
Théorème III.6,
Corollaire III.3,
Théorème III.9,
Théorème III.13,
Corollaire III.4,
Théorème III.15
Multiprocesseur à mémoire
commune ; vitesse variable en
fonction du processeur, mais
constante pour chaque processeur et
connue a priori.
ARM à partir de v6,
RealView Developper Suite
Carte mère Integrator/AP
RedHat Linux [ARM 03]
Altera Nios
GNUPro du RedHat
le kit de développement
Linux de Microtronix
Proposition III.2
Multiprocesseur à mémoire
commune ; vitesse variable en
fonction du processeur et de la
tâche.
ARM à partir de v6
Migration des tâches interdite.
RedHat Linux [ARM 03]
RealView Developper Suite
Carte mère Integrator/AP
Synchronisation entre les
processeurs au début de l’exécution
de chaque tâche.
Théorème III.7,
Proposition III.3,
Théorème III.8
Multiprocesseur à mémoire
commune ; vitesse variable en
fonction du processeur et de la
tâche.
ARM à partir de v6
RealView Developper Suite
Carte mère Integrator/AP
RedHat Linux [ARM 03]
Théorème III.10,
Théorème III.11,
Théorème III.12
Multiprocesseur à mémoire
commune ; vitesse variable en
fonction du processeur et de la
tâche.
ARM à partir de v6
Migration interdite pour certaines
tâches.
RedHat Linux [ARM 03]
RealView Developper Suite
Carte mère Integrator/AP
Tableau IV.2. Plates-formes physiques et outils de développement
proposées pour la validation des résultats obtenus au Chapitre III.
130
Chapitre IV
Sur les aspects du noyau et de l’implantation …
Sans vouloir suggérer que les plates-formes proposées sont les seules solutions
possibles, ni qu’elles sont les meilleures solutions, le Tableau IV.2 élargit le lien fait entre les
différents résultats théoriques du Chapitre III et leur application en pratique proposée dans le
Tableau IV.1. En effet, ces plates-formes constituent des éventuels points de départ pour des
projets de validation effective de nos résultats théoriques.
Nous rappelons qu’on a choisi le RTAI seulement pour illustrer les concepts communs
au système d’exploitation et ceux qui sont à la base des résultats mentionnés. Afin de
permettre l’utilisation effective de RTAI avec les modifications mentionnées dans le Tableau
IV.1 et les plates-formes correspondantes aux mêmes résultats et indiquées dans la troisième
colonne du Tableau IV.2, RTAI devrait être migré pour ces plates-formes.
IV.3.1. Solution Transmeta Crusoe™
En Janvier 2000, la société Transmeta [TRA 03] a introduit les processeurs Crusoe™,
une famille de solutions compatibles avec les processeurs x86 qui combine les performances
de calcul avec une faible consommation de puissance. Une nouvelle technologie de
conception et d’implantation de microprocesseurs a été développée ; mais réellement nouveau
est le fait que la technologie des processeurs Crusoe™ est principalement basée sur des
concepts logiciels : la puissance sauvegardée vient du remplacement d’un grand nombre de
transistors par des logiciels. Les processeurs Crusoe™ utilisent un moteur matériel
« entouré » par une couche logicielle, appelée Code Morphing™. Le moteur est un processeur
VLIW (angl. « Very Long Instruction Word ») capable d’exécuter jusqu’à quatre opérations
par cycle d’horloge. Il a été conçu spécialement pour une implantation rapide avec puissance
dissipée minimale par l’utilisation des CMOS, l’ensemble des instructions natives VLIW ne
ressemblant pas aux instructions x86. La couche logicielle donne l’impression aux
programmes x86 d’être exécutés par un x86, en transformant de manière dynamique les
instructions x86 en instructions VLIW. La Figure IV.1 indique la hiérarchie des couches
logicielles d’une machine basée sur un processeur Crusoe™. Cette technologie a changé
entièrement la conception des microprocesseurs, prouvant de manière pratique qu’ils peuvent
être implantés comme des hybrides matériels–logiciels.
Figure IV.1. La hiérarchie logicielle du processeur Crusoe™ SE [TRA 03].
131
Chapitre IV
Sur les aspects du noyau et de l’implantation …
La gestion de la puissance dissipée peut être assurée par l’intermédiaire de la couche
logicielle. Dans un premier temps, par sa conception, elle a permis de réduire
considérablement (dans les premiers modèles TM3120 et TM5400, jusqu’à un quart) le
nombre de transistors utilisés par tout autre matériel de performances similaires. Mais à part
la compatibilité x86, le Code Morphing™ fournit des interfaces avec des propriétés
spécifiques aux processeurs Crusoe™. Ce qui nous intéresse particulièrement est la facilité de
minimiser la puissance consommée, implantée sous le nom LongRun. Elle permet d’ajuster la
fréquence de l’horloge dynamiquement et extrêmement rapidement, sans rebooter le système
d’exploitation, ni passer par une séquence lente de suspension et de lancement à partir de la
RAM. Ainsi, la vitesse du processeur peut être changée au niveau logiciel afin de donner à
l’application la vitesse d’exécution qu’elle nécessite.
Les politiques de gestion de la puissance de LongRun détectent les différents scénarios
de chargement du processeur, basés sur l’information de performance aux temps d’exécution,
et adaptent la vitesse du processeur en conséquence. LongRun utilise un certain nombre de
points prédéfinis d’intervention sur la fréquence et sur la tension. La Figure IV.2 indique, à
titre indicatif, les valeurs qui correspondent au cas d’un processeur Crusoe™ SE ayant la
fréquence nominale de 933 MHz ; pour les autres modèles de processeur, il y a des courbes
similaires, dont les valeurs de la puissance pour les points prédéfinis sont données dans
l’Annexe 2. Les ajustements de la puissance sont transparents pour le système d’exploitation,
le contrôleur de la gestion de puissance et l’utilisateur. Les points effectivement marqués
représentent les points d’ajustement standard.
Figure IV.2. Les points de gestion de la puissance par LongRun,
pour le processeur Crusoe™ à 933 MHz [CRU 03].
Du point de vue matériel, le moteur VLIW du processeur Crusoe™ peut être configuré
lui-même avec les ajustements suivants :
132
Chapitre IV
Sur les aspects du noyau et de l’implantation …
La fréquence change avec un pas de 33MHz ;
Le pas de changement de la tension est de 25mV ;
Il peut effectuer jusqu’à 200 changements de fréquence/tension par seconde.
De plus, les processeurs Crusoe™, par l’intermédiaire du Code Morphing™,
supportent les modes de gestion de puissance standard conforme ACPI, avec les six états
distincts concernant la puissance du processeur : Normal, Auto Halt, Quick Start, Deep Sleep,
DSX et Off. Ces états du processeur peuvent être utilisés pour minimiser la puissance
consommée par le processeur dans les états du système qui correspondent à une activité
minimale ou inexistante du processeur. Dans le cas des processeurs Crusoe™, quand la
fréquence et la puissance du processeur ont atteint les valeurs minimales parmi les points de
fonctionnement de LongRun, le processeur commute vers les models standard de gestion de la
puissance mentionnés ci-dessus.
La facilité d’intervenir au niveau logiciel sur la vitesse du processeur permet de
prendre en considération les processeurs Crusoe™ pour la validation de nos résultats sur la
consommation énergétique (indiqués dans le Tableau IV.2) pour le cas monoprocesseur. Il
reste de transformer RTAI dans le sens indiqué dans le Tableau IV.1 pour les mêmes
résultats. A cause de la compatibilité Crusoe™-x86, la transposition compatible x86 de RTAI
représente également la version compatible Crusoe™. Par rapport aux possibilités offertes
par LongRun sur la minimisation de la consommation, deux constats sont à faire et à observer
particulièrement pendant la validation :
Le changement de la fréquence et de la tension ne se fait pas de manière continue,
ce qui doit être pris en compte dans l’analyse a priori du système et des résultats
théoriques transposés pour la variation discrète spécifique.
Le gestionnaire de la puissance LongRun est basé sur le même principe que les
résultats obtenus dans le Chapitre III (i.e., ajuster la vitesse du processeur de
manière à le faire charger au maximum à tout moment). Malgré cela, l’ajustement
réalisé par LongRun est basé sur des estimations de la charge processeur réalisées
par lui-même, ce qui peut entraîner certaines différences sur le calcul de la vitesse
d’exécution de chaque tâche par rapport aux vitesses théoriquement estimées, et
cela d’autant plus si elle est corroborée avec la première observation. La solution
pour ce problème est pourtant simple : l’utilisateur devrait pouvoir indiquer luimême à Code Morphing™ la vitesse de chaque tâche. Cela entraînerait des
changements au niveau du système d’exploitation afin de prendre en compte ces
valeurs dans l’ordonnancement des tâches, du système d’exploitation et du Code
Morphing.
Nous considérons qu’avec les changements nécessaires dans le Code Morphing™, la
solution Crusoe™ pourrait se rendre valable aussi pour les cas multiprocesseur. Notons
toutefois que, les sources n’étant pas disponibles, il faudra une version Transmeta des
processeurs Crusoe™ capable de fonctionner sur des plates-formes multiprocesseur avec les
restrictions décrites par les Tableaux IV.1 et IV.2, et tout en assurant une gestion de la
puissance similaire au cas monoprocesseur actuellement développé.
Ces quelques lignes explicatives de la conception des processeurs Crusoe™ de
Transmeta, qui montrent la raison pour laquelle on les a pris en considération, ont eu à la base
le site Internet de Transmeta [TRA 03], plus particulièrement l’article d’introduction sur cette
technologie écrit par Klaiber [KLA 00], présentant les principes de LongRun écrit par
Fleischmann [FLE 01] et la présentation des processeurs Crusoe™ pour les systèmes
embarqués TM53E/TM58E [CRU 03].
133
Chapitre IV
Sur les aspects du noyau et de l’implantation …
IV.3.2. Solution Altera Nios
Le processeur Nios [ALT 03] est une variante du processeur RISC, intégré sur circuit
PLD. La Figure IV.3 présente les blocs diagrammes de base d’un processeur Nios à 32 bits et
la Figure IV.4 illustre une intégration multiprocesseur du Nios sur un seul chip.
Pour la validation des principes développés dans cette thèse, le noyau Linux, ainsi que
le module RTAI, doivent être portés pour le processeur Nios et adaptés à une configuration
multiprocesseur, comme c’est indiqué dans le Tableau IV.2. Des outils de développement
existants facilitent ce travail. Le kit de développement GNUPro du RedHat [RED 00]
représente une plate-forme de développement croisée, qui offre une solution complète pour le
développement des applications C ou C++ pour le processeur Altera Nios. Il représente l’outil
qui permet le portage du noyau Linux et de son module RTAI pour le processeur Altera Nios.
L’implantation physique sur des composants Apex peut être assurée par le kit de
développement Linux conçu par Microtronix [MIC 03], qui est une plate-forme complète
matérielle et logicielle, complémentaire au kit de développement Nios. Celui-ci inclut
également µClinux et µClibc porté pour le processeur embarquable Nios, ce qui offre l’outil
logiciel nécessaire pour l’adaptation de RTAI et l’implantation des applications temps réel.
Les mêmes problèmes évoqués à la fin de la section précédente restent à résoudre pour une
validation effective.
Figure IV.3. Blocs diagrammes du processeur Nios à 32 bits [ALT 03].
134
Chapitre IV
Sur les aspects du noyau et de l’implantation …
Figure IV.4. Intégration multiprocesseur de Nios sur un seul chip [ALT 03].
IV.3.3. Solution ARM
Revenons au Tableau IV.2 et notons que la plupart des solutions multiprocesseur
envisagées vont vers les processeurs ARM (angl., Acorn RISC – Reduced Instruction Set
Computer – Machine), conçus par la société ARM Ltd (angl., Advanced RISC Machines)
[ARM 03].
Nous indiquons par la suite les principes qui sont à la base de cette proposition, en
précisant que nous faisons référence à l’architecture processeur ARMv6, (la dernière) conçue
par ARM Ltd. en 2002. Celle-ci, par rapport aux versions précédentes, offre une gestion
mémoire performante pour les plates-formes multiprocesseur à mémoire commune ; les outils
de développement proposés par ARM prennent en considération cette architecture et assurent
entièrement les conditions indiquées dans la deuxième colonne du Tableau IV.2, comme on
verra par la suite. A la base de la présentation faite ci-dessous se trouve la documentation
existant sur le site Internet de ARM [ARM 03], dont principalement [BRA 02], et les
réponses données à certaines questions par un des spécialistes ARM [BRO 03].
La plate-forme de développement ARM Integrator/AP AHB ASIC est conçue pour le
développement des systèmes matériels et logiciels basés sur les routines ARM et la
spécification de bus AMBA. Elle est prévue pour maximum 5 processeurs (angl. Core) ou
modules logiques (angl. Logic Modules), et dispose de multiples accessoires : 32MB de
Flash, 512K SSRAM, Boot ROM, des périphériques de système standard dans un contrôleur
de système FPGA (clavier ARM PrimeCell, souris, deux contrôleurs série et l’horloge temps
réel), 3 compteurs de temps, une E/S générale sur 32 bits, un contrôleur d’interruptions,
l’interface bus externe, un contrôleur PCI hôte-passerelle, 3 slots standard PCI avec
génération d’horloge et arbitration, une passerelle PCI-PCI, un connecteur CompactPCI et des
fonctions pour le slot système, un connecteur pour l’expansion de mémoire, et l’expansion du
système. La Figure IV.5 présente une photographie de cette carte.
135
Chapitre IV
Sur les aspects du noyau et de l’implantation …
Figure IV.5. ARM Integrator/AP AHB ASIC [ARM 03].
Cette plate-forme est conçue pour le châssis PC ATX standard et permet la
construction de toute une variété de systèmes, le PC fournissant la stabilité mécanique
nécessaire aux cartes d’expansion PCI. La plate-forme d’intégration ARM Integrator/AP
permet l’utilisation de plusieurs processeurs. Chaque « Core Module » d’un processeur
dispose d’un SDRAM DIMM ; ainsi, chaque processeur peut avoir un module SDRAM
attaché. Cette SDRAM peut être accédée directement par la routine du module même, ou elle
peut devenir alias dans la carte mémoire de tous les « Core Modules » connectés. Ainsi elles
peuvent être utilisées comme mémoire commune.
Pour chaque processeur le contrôle de la fréquence est programmable pour le « Core
Frequency », pour le bus local (Core Module) et pour le bus principal du système. Cela
permet aux processeurs d’une plate-forme multiprocesseur d’avoir des vitesses différentes (à
chacun sa vitesse). De plus, il est possible que la vitesse de chaque processeur, indépendante
des vitesses des autres processeurs, soit variable en fonction de la tâche à exécuter, car
chaque processeur est contrôlé indépendamment par le module de la routine spécifique. Par
conséquent, la fréquence de chaque routine (donc tâche) étant contrôlée par des écritures dans
les registres de la carte mémoire, elle peut être contrôlée de manière active, à son exécution.
Le développement des plates-formes ARM proposées peut se réaliser à l’aide de la
suite d’outils logiciels RealView, conçus également par ARM, et en utilisant la plate-forme
d’intégration matérielle et logicielle Integrator/AP.
Notons aussi que des versions de RTAI pour des processeurs ARM existent déjà,
notamment pour le processeur StrongARM de Intel [RTA 03].
Parce que les principes marqués en italique répondent entièrement aux assertions
indiquées dans la deuxième colonne du Tableau IV.2, entrer dans plus de détails techniques
reste pour un projet de validation effective.
Notons certains aspects à analyser pour la validation :
•
Les différences en terme de coûts énergétiques entre les plates-formes à nombre
égal de processeurs de type SoC et non-SoC, pour le développement d’une même
application.
•
Une comparaison ou/et une prise en compte, dans le développement de
l’application, des technologies de minimisation de la consommation énergétique
introduites par ARM, et leur influence sur les résultats pratiques par rapport aux
résultats théoriques.
136
Chapitre IV
Sur les aspects du noyau et de l’implantation …
• Nous ne disposons pas d’informations plus concrètes sur le seuil de variation de la
fréquence/puissance. Comme les résultats théoriques ont supposé une variation
continue, la validation introduira implicitement certaines différences par rapport à
ces résultats.
Sans avoir la prétention d’un état de l’art sur les plates-formes
physiques susceptibles de répondre aux assertions et aux contraintes imposées
par les résultats théoriques sur la minimisation de la consommation
énergétique obtenus dans le Chapitre III, la section IV.3 a présenté quelquesunes d’entre elles, ainsi que des outils de développement logiciel que la
technologie actuelle fournit pour la validation de ces concepts.
IV.4. Conclusions
Conçu en deux parties, ce chapitre représente « une approche de l’implantation d’une
application temps réel pour l’optimisation de la consommation énergétique du processeur ». Il
indique la complexité, et non pas l’impossibilité, de mettre en œuvre des projets de validation
pratique pour les estimations théoriques issues des résultats du chapitre précédent. Ainsi, il
montre que la technologie actuelle, tant au niveau du système d’exploitation qu’au niveau
matériel, offre un bon point de départ au moins pour l’utilisation d’une partie des résultats –
sur la solution statique –, comme l’indique l’union des tableaux IV.1 et IV.2.
Dans une première étape (IV.2), ce chapitre met en évidence certains aspects d’un
noyau temps réel et de l’implantation d’une application temps réel liées à l’optimisation de la
consommation énergétique au niveau du/des processeur(s). Le noyau RTAI-Linux est pris en
considération comme exemple, et on constate que le fonctionnement des ordonnanceurs
proposés semble adapté aux types de machines multiprocesseur demandés par la solution
statique de la consommation optimale. Pourtant, certaines particularités de RTAI (et
implicitement d’un système d’exploitation quelconque utilisé) devraient être prises en compte
dans la phase d’analyse de l’application ; ainsi quelques nouvelles fonctionnalités qui
devraient être ajoutées au noyau ont été spécifiées.
Un autre aspect a été évoqué : afin de permettre une analyse a priori la plus précise
possible sur la consommation due à l’exécution de l’application, une bonne connaissance du
système d’exploitation est nécessaire, car certains aspects de son fonctionnement ne sont pas
explicitement pris en considération par la théorie de l’ordonnancement et la consommation
d’énergie, comme par exemple le coût d’ordonnancement et le scénario effectif des tâches.
Pour approcher davantage notre présentation de l’implantation d’une application, certains
aspects liés au cas particulier de RTAI ont été mis en évidence : la nécessité d’exécuter
entièrement l’application dans l’espace noyau, d’où la nécessité d’implanter sous la gestion de
RTAI tout service demandé par l’application et de configurer le noyau seulement avec les
services demandés par l’application. On a constaté la similarité des processus suivis pour
l’évaluation préalable du coût énergétique et de la faisabilité du système.
La modalité d’identifier le modèle réel des tâches a été passée en revue, ainsi que les
façons de traiter tous les facteurs intervenant pour minimiser le coût énergétique :
identification et implantation des tâches proprement dites de l’application et des tâches
système, la communication entre les tâches, la tâche de fond.
137
Chapitre IV
Sur les aspects du noyau et de l’implantation …
On peut conclure que le système RTAI, ayant un nombre relativement restreint de
modifications qui restent à réaliser, se prête bien à la mise en œuvre des résultats sur la
consommation d’énergie.
Dans une deuxième étape (§IV.3), la présentation des plates-formes physiques offre la
possibilité de valider les résultats théoriques liés à la consommation énergétique. Les
propositions vont vers les processeurs Crusoe™ de Transmeta pour le cas monoprocesseur
(bien que les suivantes soient également envisageables), et vers le processeur Nios de Altera
ou/et les processeurs de ARM (à partir de l’architecture processeur ARMv6) pour les cas
multiprocesseur. En se basant sur la documentation trouvée sur les sites Internet, nous
estimons que ces architectures semblent offrir des solutions technologiques viables pour la
validation des résultats concernant la consommation énergétique.
En conséquence et correspondant aux suggestions et aux exemples introduits par cette
étude théorique, plusieurs voies de recherche applicative s’ouvrent : d’une part vers les
systèmes d’exploitation, d’autre part vers les plates-formes matérielles. Toutefois, des
validations effectives ultérieures à l’étude théorique que constitue cette thèse s’imposent, et
ces plates-formes ne représentent que des cas particuliers à prendre en compte dans ces
projets qui restent pour l’avenir.
138
CHAPITRE V
Conclusions et perspectives
Chapitre V
Conclusions et perspectives
Cette thèse a abordé le problème de l’autonomie des systèmes temps réel embarqués,
en étudiant particulièrement l’économie d’énergie pouvant être obtenue au niveau du/des
processeur(s). Comme nous en avons fait une description détaillée dans le Chapitre I
(Introduction), ici nous nous contenterons d’indiquer les directions de notre travail, en
insistant sur les problèmes qui restent à résoudre et qui constituent autant d’ouvertures et de
perspectives.
Dans le Chapitre II nous avons présenté différents aspects liés à la faisabilité des
applications temps réel, notions issues de la théorie de l’ordonnancement temps réel, les
notions fondamentales sur la conception des systèmes embarqués, et nous avons passé en
revue les systèmes d’exploitation temps réel Linux.
Le cœur de cette étude est le Chapitre III, qui expose sur l’optimisation de la
consommation d’énergie et apporte une contribution à la définition de la configuration d’un
système temps réel embarqué. Partant de l’hypothèse que la vitesse du processeur soit
modifiable en cours de fonctionnement du système, ce chapitre traite la consommation
d’énergie au niveau du/des processeur(s) produite par l’exécution des tâches et leur
ordonnancement. Le but est de trouver, pour différents modèles de tâches, le nombre de
processeurs et les vitesses d’exécution des tâches qui assurent l’existence d’un algorithme à
la fois faisable et optimal du point de vue énergétique.
Ce chapitre donne des résultats fondamentaux sur le modèle que nous avons considéré,
celui des tâches indépendantes. Notre contribution s’est développée en trois directions. D’une
part, nous avons complété le fondement théorique et les résultats connus pour le problème
d’optimisation énergétique d’une plate-forme monoprocesseur. D’autre part, après avoir
développé les notions et résultats théoriques nécessaires, basés sur le concept
d’ordonnancement global optimal, on a fourni la solution statique et dynamique
multiprocesseur pour le cas général du modèle de tâches périodiques indépendantes avec
différentes fonctions de puissance dissipée. Ce concept s’appuie sur une nouvelle approche,
qui constitue la deuxième direction de notre étude. On a redéfini le problème d’optimalité, en
considérant qu’il faut déterminer, pour une configuration optimale d’un système temps réel
embarqué, les vitesses d’exécution des tâches à tout moment (i.e. après chaque préemption) et
le nombre de processeurs. Notre approche montre que, afin de minimiser la consommation du
processeur, le nombre de processeurs doit être maximal. Pour la troisième direction d’étude,
nous avons déterminé une condition nécessaire d’optimalité pour un ordonnancement sur une
plate-forme multiprocesseur donnée, le principe d’uniformité. Comme application de ce
principe, nous avons obtenu des évaluations concrètes de gain énergétique pour le passage de
un à deux processeurs, pour le modèle de tâches ayant la même fonction de puissance
dissipée.
Notons que nous avons utilisé, pour les principales théorèmes sur la consommation
énergétique (Théorèmes III.5, III.11, III.12, III.14, III.15), des fonctions de puissance dissipée
ayant la forme : g i (S ) = a i S r , avec ai , r ∈ R *+ et r ≥ 2 . Certes, cette forme est la plus
souvent utilisée dans les articles de recherche, mais la fonction de puissance dissipée peut
être beaucoup plus complexe (voir §III.2.2). La généralisation de ces résultats devrait
surpasser certaines difficultés mathématiques et reste pour l’avenir.
Le
problème qui consiste à trouver une condition suffisante pour qu’un
ordonnancement d’un ensemble de tâches soit optimal sur une machine à nombre donné de
140
Chapitre V
Conclusions et perspectives
processeurs, nous semble d’un grand intérêt pratique. En ce moment, seulement la condition
nécessaire donnée par le Théorème III.10 existe. Une réponse à ce problème pourrait
engendrer un ordonnancement optimal sur la plate-forme donnée, pour des tâches
quelconques, et permettrait de plus la généralisation des résultats donnés dans §III.6.2 et
§III.7. La démonstration pour la convergence d’un algorithme empirique vers la solution
optimale est en cours.
Des études sur d’autres modèles de tâches restent à faire, notamment pour prendre en
compte les relations de précédence et les anomalies qu’elles peuvent induire.
Nos estimations théoriques pour le gain énergétique obtenu par le passage d’une
machine monoprocesseur à une machine multiprocesseur indiquent une diminution
considérable, par exemple E 2 ≤ 0,556 E1 (voir les Théorèmes III.11, III.12, III.14 et III.15).
Des évaluations pratiques sont nécessaires pour valider cette théorie, surtout pour pouvoir
estimer le coût supplémentaire induit par l’ajout de processeurs dans le système. Néanmoins,
et malgré les inconvénients que la technologie actuelle pourrait introduire dans une évaluation
réelle, nous considérons que les estimations théoriques obtenues sont suffisamment
importantes pour prendre en compte cette approche durant la période de développement d’un
système temps réel embarqué.
Une autre question reste aussi ouverte : quel gain d’énergie la solution dynamique
peut-elle apporter pour une machine donnée, par rapport à la solution statique globale
optimale? Une vraie réponse ne peut être obtenue que par une suite d’expérimentations.
C’est vers cette direction expérimentale, liée à l’implantation d’une application temps
réel, que s’est développé le Chapitre IV. Nous avons rapproché ici les résultats théoriques
sur l’optimisation de la consommation énergétique du processeur avec les systèmes
d’exploitation et les plates-formes matérielles existantes, afin de permettre une validation
pratique de ces résultats. Ce chapitre constitue une première approche vers la mise en
pratique des résultats mentionnés et une ouverture pour des projets de validation par des
applications, ultérieurs à cette étude.
En analysant la théorie de l’ordonnancement d’une part, et les systèmes d’exploitation
temps réel de l’autre, on trouve vite une faille qui existe entre ces deux domaines. On a mis en
évidence, au Chapitre IV, des éléments liés aux systèmes d’exploitation qui interviennent
dans la consommation énergétique, ainsi que certaines modifications qui s’imposent. Pour
illustrer cette approche nous avons pris comme exemple le noyau RTAI-Linux. Bien sûr, le
choix de prendre comme exemple le noyau RTAI est subjective ; dans ce sens, une étude
énergétique comparative des facilités des systèmes d’exploitation temps réel s’avère
nécessaire et complétera ce travail.
Les ordonnanceurs proposés par RTAI correspondent à quelques-unes des assertions
des résultats théoriques, et permettent des modifications appropriées pour qu’elles puissent
correspondre également aux autres. Ces ordonnanceurs peuvent être utilisés tels quels pour les
applications sans changement de vitesse du processeur durant l’exécution, aussi bien pour les
cas mono que multiprocesseur. Pour les cas avec changement de vitesse, cette situation doit
être prise en compte par une nouvelle implantation de RTAI.
On a ensuite indiqué les facteurs qui influencent le coût de l’ordonnanceur et on a
parlé sur les politiques d’ordonnancement mono coup et périodique, ainsi que sur le choix à
faire entre les deux du même point de vue, celui de l’optimisation énergétique.
Il est possible que, pour son fonctionnement, une application se serve de certains
services offerts par le système, mais aussi que certaines fonctionnalités du système ne soient
141
Chapitre V
Conclusions et perspectives
pas prises en compte par l’application. Pour le système d’exploitation tous ces services
constituent des tâches. Afin de permettre une analyse a priori de la faisabilité et la
consommation énergétique due à l’exécution de l’application, les tâches induites par le
système d’exploitation doivent faire partie du modèle réel des tâches de l’application. On a
traité cet aspect pour le cas du RTAI.
Dans une deuxième partie, le Chapitre IV propose un regard vers des plates-formes
physiques actuellement disponibles ainsi que sur des outils logiciels correspondants, qui
pourraient permettre une validation des résultats sur les estimations de la consommation
énergétiques présentés au Chapitre III. Cette section représente une démarche
complémentaire à la précédente, afin de permettre le début d’un projet de validation réel. Les
solutions proposées vont vers les processeurs Transmeta Crusoe™ [TRA], les architectures
ARM v6 [ARM] et Altera Nios [ALT], avec des outils de développement conçus par les
constructeurs respectifs ou avec des outils disponibles pour Linux, afin de faire migrer le
noyau RTAI-Linux vers ces plates-formes. Dans leurs versions actuelles, les plates-formes
proposées vérifient les hypothèses de certains résultats théoriques concernant la solution
statique. Pour les autres résultats, des modifications s’imposent, mais par leurs philosophies
de conception ces plates-formes semblent s’y prêter bien.
Pour résumer les perspectives issues de l’approche de cette thèse sur l’optimisation de
la consommation énergétique du processeur, quelques axes de recherches s’ouvrent :
•
continuer l’étude théorique de la consommation d’énergie sur le modèle de tâches
périodiques (des directions plus précises ont été mentionnées ci-dessus) ;
•
développer l’étude théorique de la consommation d’énergie sur d’autres modèles
de tâches ;
•
adapter des noyaux temps réel et des plates-formes physiques pour la validation
expérimentale des résultats théoriques ;
•
réaliser une étude comparative sur la consommation énergétique des principaux
algorithmes d'ordonnancement ;
•
évaluer l’apport de la solution dynamique par rapport à la solution statique
optimale obtenue suite à la théorie présentée dans cette thèse.
142
ANNEXE 1
Etude de cas
A1.1. Motivation
Le but de cette annexe est de montrer brièvement que des modèles mathématiques
assez simples – voir même simplistes, comme c’est le cas du modèle de tâches périodiques,
identiques et indépendantes – peuvent correspondre aux applications sophistiquées.
Nous présenterons dans la suite un résumé des travaux publiés dans le cours de
préparation de cette thèse, pour illustrer les différents aspects de la conception d’une
application embarquée temps réel de transmission des images médicales dans un réseau local
sans fil (pour les détails, voir [MER 01a], [MER 01b] et [MER 02]). La conception de cette
application nous a conduit vers un modèle général de tâches périodiques avec relations de
précédence, ayant un sous-ensemble principal de quatre tâches périodiques, identiques et
indépendantes. Les besoins de déterminisme de l’exécution de l’application et d’optimisation
de la consommation énergétique nous amènent vers une plate-forme multiprocesseur. Les
vitesses d’exécution des tâches sont à estimer conformément à l’approche décrite au Chapitre
III, la modalité d’implantation étant basée sur les principes présentés au Chapitre IV. La
validation physique reste à faire avec une plate-forme basée sur un processeur MPC555
[MER 01a], ou bien sur une plate-forme multiprocesseur on-chip à définir, par exemple parmi
celles présentées au Chapitre IV.
A1.2. Introduction
Il existe des situations quand, pour faciliter les mouvements dans des régions limitées,
on a besoin de disjoindre la liaison physique entre la capture d’une image et sa visualisation
(par exemple, dans une situation chirurgicale). Nous présentons dans la suite la conception
d’une application temps réel pour transmission/réception des images Dicom (angl. Digital
Imaging and Communication in Medicine) par un réseau local sans fil Bluetooth.
Les hypothèses avec lesquelles nous travaillerons sont les suivantes:
(i)
la qualité des images affichées au noeud récepteur est extrêmement
importante ;
(ii)
les images capturées sont généralement stables, elles n’ont ni beaucoup de
détails en mouvement ni de changements inattendus ;
(iii)
la capture et la visualisation des images doivent être faites en mode synchrone.
Les restrictions imposées par une transmission sans fil et la dimension des images
143
ANNEXE 1
Etude de cas
nous amènent à ces suppositions, et nous conduisent à une application impliquant plusieurs
concepts, parmi lesquels les réseaux neuronaux CMAC (angl. Cerebellar Model Articulation
Controller) ont un rôle clé.
La section A1.3 offre une image d’ensemble de l’application (§A1.3.1) et des
différentes parties du système. Nous y présentons l’intérêt d’utiliser une transformation par
ondelette (angl. discrete wavelet transformation) pour traiter les images (§A1.3.2) et les
principaux concepts concernant une transmission synchrone sans fil utilisant le standard
Bluetooth [BLU 99] (§A1.3.3). Après un rappel des concepts d’un réseau CMAC, nous
discutons dans §A1.3.4 les raisons d’employer quatre tels réseaux neuronaux identiques pour
travailler d’une façon prédictive pour notre application.
La section A1.4 montre les principaux résultats produits par une simulation en Matlab
pour vérifier la faisabilité de notre conception. Des conclusions brèves sont présentées dans la
section A1.5.
A1.3. Principes de l’application
A1.3.1.
Architecture globale de l’application
La capture des images est réalisée par une camera mobile CCD. Pour des évaluations
de laboratoire, les images Dicom sont premièrement stockées sur un disque dur. Les images
peuvent être converties en fichiers format GIF, BMP ou JPEG avec le logiciel Papyrus v.3.4,
gratuitement accessible [PAP 01]. Notre évaluation a été réalisée pour le standard BMP, qui
est le plus coûteux en termes de dimensions de la mémoire, mais qui ne présente pas d’effets
de bord (angl. « board effects ») due au carrelage de l’image, comme des autres standards (ex.
JPEG).
Figure A1.1. Synoptique.
Une transformation par ondelette discrète (DWT) de niveau 2 bi-orthogonal est
calculée en temps réel par un processeur, pour chaque image stockée. Les quatre coefficients
d’ondelette (un pour l’approximation et trois pour les détails) sont appris par quatre réseaux
CMACs en mode prédictif. Les prédictions pour les variations des coefficients d’une image
par rapport à la suivante sont ajoutées dans un seul fichier, compressé Huffman/RLE avant
d’être transmis – par le seul nœud Bluetooth du réseau sans fil – au point de réception
monitoring.
Les variations des coefficients de l’ondelette engendrent des fichiers de tailles réduites
en comparaison avec ceux correspondant aux images complètes, nous permettant ainsi
d’utiliser la largeur de bande Bluetooth en dessous de ses limites maximales, et de garder un
rythme de transmission de 10 images Dicom par seconde.
144
ANNEXE 1
A1.3.2.
Etude de cas
Le filtrage par ondelette
Le concept de filtrage par ondelettes est bien connu pour le traitement du signal et de
l’image, surtout pour ses performances en ce qui concerne le taux de compression. De plus, le
codage ne nécessite pas des blocks à longueur fixe pour les données à traiter. Et encore, pour
la transformation ondelette lui correspondant, toutes les données qui correspondent à une
fréquence spatiale sous-bande donnée sont localisées dans un seul voisinage, donc les zéros
peuvent être compressés RLE sans affecter la qualité de l’image. Par ailleurs les zéros sont
quelque chose de commun dans la quantification des bandes de fréquence.
Mallat [MAL 89] a présenté un algorithme rapide de décomposition et reconstruction
pour une transformation ondelette discrète (DWT), connu maintenant sous le nom de « codeur
par deux canaux de sous-bande » (angl., « two channel subband coder »). Nous utilisons ce
concept et appliquons une transformation bi-orthogonale; les meilleurs résultats en termes de
luminosité et contraste ont été obtenus avec une ondelette Bior 6.8.
Nous appliquons une DWT à l’image BMP. Les détails de niveau 1 (D1) peuvent être
ignorés sans perte significative d’information. Les détails de niveau 2 donnent respectivement
les coefficients ondelette vertical, horizontal et diagonal, notés pour la suite par CdV2, CdH2
et CdD2. La reconstruction des images, suivie d’une comparaison pixel-original à pixelreconstruit, a produit les mêmes résultats avec ou sans le coefficient diagonal CdD2: après 200
tests avec des images différentes, nous avons obtenu une erreur moyenne de moins de 0.1%.
L’utilisation des coefficients D1 aurait chargé sérieusement le temps de calcul. Comme les
coefficients correspondant à une image entière sont transmis une fois par seconde, leurs
variations basées sur la conversion par ondelette de l’image sans pertes permettent une
reconstruction pratiquement sans pertes pour l’image reçue.
Figure A1.2. La transformation par ondelette discrète de niveau 2.
A1.3.3.
Transmission sans fil
On peut utiliser, pour notre application, plusieurs types de systèmes de communication
sans fil (802-11, Home RF, Hyperlan1 ou 2, Bluetooth), chacun d’entre eux présentant des
avantages spécifiques (voir [MER 01c] pour une étude comparative). Nous avons choisi la
technologie Bluetooth parce qu’elle offre des communications sans fil bon marché dans la
bande de fréquence de 2.4 GHz ISM (angl. « Industrial Scientific Medical ») par l’usage de la
technologie FHSS (angl. « Frequency Hopping Spread Spectrum »), et des cartes d’émission
ou réception embarquées disponibles avec un paquet de développement complet.
Les deux composantes Bluetooth, chacune à l’intérieur du rayon d’activité de l’autre,
peuvent établir une connexion ad hoc, ainsi créant un petit réseau appelé « piconet ». Un
piconet consiste en un unique maître et jusqu’à sept unités esclaves synchronisées au maître.
Il n’y a pas de différence matérielle ou logicielle entre un maître et un esclave. La
145
ANNEXE 1
Etude de cas
communication Bluetooth de notre application est composée par un seul piconet avec un
maître (le noeud émetteur) et un esclave (le noeud recepteur). A l’instant t0 un paquet de
données avec les coefficients de l’ondelette complets est transmis par l’émetteur. La durée de
transmission de ce paquet dépasse la borne de 625µs d’un seul paquet Bluetooth. Une
communication en ACL (angl., Asynchronous Connection Link) est établie en mode émission
(angl., broadcast) de maître à esclave. L’usage d’une communication en mode « broadcast »
donne la largeur de bande maximale (723Kbps) et permet d’avoir plusieurs autres esclaves,
c'est-à-dire d’autres points de réception monitoring. Une image complète est transmise chaque
seconde. Durant chacune des autres 9 périodes (t1 à t9) d’une seconde (le standard Dicom
demande un flux de 10 images/seconde), seulement les variations des coefficients de
l’ondelette des images sont transmis synchroniquement dans un seul paquet « slot »,
permettant ainsi de se maintenir à l’intérieur de la largeur de bande de Bluetooth.
A1.3.4.
Principe de l’application de CMAC
Le concept de CMAC, présenté pour la première fois par Albus [ALB 75], appartient à
la classe de réseaux neuronaux adaptatifs multicouches. Le contrôle adaptatif d’un processus
inconnu en utilisant un réseau neuronal a été l’objet d’un grand nombre de publications,
basées surtout sur la capacité d’approximation d’un réseau multicouches avec au moins une
couche cachée. Dans un système de contrôle, la première étape du modèle prédictif est
d’entraîner le réseau neuronal pour représenter la dynamique d’évolution du système. L’erreur
de prédiction entre la sortie du système et la sortie du réseau neuronal est utilisée comme
signal pour l’entraînement du réseau. Nous avons adapté le processus de contrôle prédictif
proposé par Kraft [KRA 90], ce qui nous a conduit au synoptique représenté dans la Figure
A1.3.
Figure A1.3. Architecture CMAC prédictive pour les variations des coefficients de l’ondelette.
L’intérêt pour le modèle prédictif CMAC est justifié par la nécessité de
synchronisation entre la demande de l’esclave et le retard de réponse du master. Dans ce sensla, la variation des coefficients de l’ondelette doit être calculée avant la transmission. Pour
notre application quatre réseaux CMAC travaillent en mode parallèle pour calculer
respectivement les coefficients de l’ondelette. Les tâches correspondant à chaque CMAC
ont le même programme, et donc elles sont identiques.
L’application du CMAC suppose deux étapes de traitement. Premièrement, les
vecteurs d’entrée (habituellement codés en binaire) de dimension R (appelé résolution)
activent les détecteurs d’état d’espace, une sorte de mémoire virtuelle dont la dimension peut
146
ANNEXE 1
Etude de cas
être beaucoup plus large que celle de la mémoire physique d’un system réel. Deuxièmement,
on fait correspondre chaque élément de la “mémoire virtuelle” à un élément de la mémoire
physique. La fonction de sortie est donnée par la somme du contenu des éléments de la
mémoire physique assignés aux vecteurs d’entrée.
Les performances de l’algorithme CMAC dépendent essentiellement de deux
paramètres, la résolution R et le facteur de généralisation G. La résolution définit la précision
du réseau dans le sens de la longueur du codage d’entrée. D’autre part, elle induit des
problèmes sur la dimension de la mémoire à être utilisée, sur le nombre d’exemples utilisés et
sur la durée d’entraînement du CMAC. Le facteur de généralisation influence la correction de
la sortie du réseau dans le sens d’une certaine norme.
Pour chaque espace d’entrée, le nombre d’éléments est N e =2R et le nombre de
connecteurs lui correspondant est Nc =2 R +G −1 . La recherche d’une relation pour échapper à
la complexité de la matrice de connexion induit une nouvelle contrainte: la différence entre
deux vecteurs, m et m′ , correspondant à des cellules excitées de la mémoire virtuelle pour
deux entrées consécutives (ex. (x, y ) et (x +1, y ) or ( x, y +1) ), est donnée par un seul élément
du vecteur. Donc la matrice généralisée de dimension G
G2
×K
G pour N variables d’entrée,
1×4
4×3
N
obtenue à partir de la matrice de connections, contiendra un nombre de G éléments non nuls
disposés dans un ordre régulé. Le calcul pour la dimension de la mémoire physique [MER 95]
N N +G −1⎥
nous donne le nombre N m de cellules de mémoire virtuelle, N m = ⎢⎢ C
⎥⎦ . Les valeurs
G
⎣
correspondant à une mémoire physique utilisable par des applications réelles, pour une
résolution d’au moins 8, et pour 2, 3 ou 4 variables d’entrée, peuvent être mesurées en termes
de milliers de KBytes. Les techniques de compression « hashing », généralement utilisées
pour réduire la mémoire virtuelle à une mémoire physique [KRA 89], génèrent des positions
des points d’approximation avec du bruit blanc. Mercier [MER 94] a proposé un algorithme
modifié pour éviter les techniques de « hashing », qui réduit également le temps de calcul.
Nous utilisons cette version d’algorithme pour notre application.
Au moment t, les valeurs de position (X,Y) d’un pixel sont représentées simultanément
pour le calcul DWT et aux entrées CMAC. Les coefficients de la matrice de sortie sont de
type « floating » (4 bytes) ; une transformation concernant le type des données est nécessaire,
parce que les entrées CMAC sont de type binaire. L’entrée d’un CMAC est structurée en 2
senseurs binaires ayant la dimension de la résolution équivalente:
i)
la première entrée est une combinaison du pixel X(t) de l’image et de MSB
de la valeur prédite correspondant au coefficient de l’ondelette, et
ii)
la seconde entrée est une combinaison du pixel Y(t) de l’image et de LSB du
même coefficient de l’ondelette.
La sortie du CMAC donne la prédiction pour les coefficients à l’instant t+1; celle ci est
comparée aux coefficients correspondant à l’instant t.
La variation des coefficients calculée est quantifiée en mode binaire pour correspondre
à différents degrés d’erreur considérés comme acceptables par rapport à l’exactitude de
l’image reconstruite. La précision de la quantification de l’erreur signalée dépend du nombre
de bits de la quantification. Le prix à payer pour avoir une meilleure résolution est
l’augmentation de la dimension du fichier généré, et donc de son temps de transmission. Pour
une image Dicom, les résolutions à 2 et 3 bits sont suffisantes. Le choix de la résolution
dépendra de la dynamique des images capturées.
147
ANNEXE 1
Etude de cas
La loi d’apprentissage Widrow-Hoff utilisée avec β =1 avec un seul pas est nécessaire
pour ajuster les coefficients pondérés de CMAC, obtenant ainsi un temps d’apprentissage
minimal. Nous n’avons identifié aucune instabilité pendant les tests réalisés avec cette
quantification. Apres le scanning de tous les pixels de l’image, les 3/4 variations des
coefficients de l’ondelette sont mis dans un seul fichier, y compris les séries larges de
"décision 0". A cause du nombre important de zéros consécutives dans le fichier à
transmettre, l’algorithme RLE apporte un taux de compression importants.
A1.4. Résultats de la simulation
Une séquence de 20 images de mouvement consécutives (256x256 pixels avec 256
niveaux de gris) a été utilisée pour une simulation en Matlab. Une valeur du taux de
compression de 15:1 procure une énergie de 99,8 % avec une moyenne de zéros de 64 % pour
la transformation par ondelette discrète Bior 6.8. La dimension du fichier correspondant à une
image entière est de 4.6 Kbytes, donc en-dessous de la limite de 5.8 Kbytes. La dimension
d’un paquet de données contenant les coefficients de l’ondelette, à transmettre entièrement,
est constante pour une dimension donnée de l’image (256x256 pixels) de même type (256
niveaux de gris), et le fichier généré sans pertes est aussi constant (76 x 76 x 4bytes x
4coefficients). La transmission de l’image entière est réalisée par le maître de réseau
Bluetooth en mode « burst broadcasting » pour obtenir la plus grande largeur de bande
(723b/sec). L’émission de cette image complète doit être terminée avant la fin de la seconde
période moins le temps correspondant à un seul « slot » (1,25ms); celui-ci est nécessaire pour
transmettre les variations des coefficients de l’ondelette, calculées durant la première période
d’émission. Pour les variations maximales des coefficients de l’ondelette le fichier pour un
« slot » maître est au dessus de 0.34 Kbyte. La dimension de la mémoire utilisée par les quatre
réseaux CMAC est de 4 x 33555Kbytes.
La simulation Matlab a montré la faisabilité du système présenté. Comme les
différentes tâches de l’application doivent être exécutées en concurrence et en synchronisme
avec le message d’émission et la capture des images, un noyau temps réel est indispensable.
A1.5. Principes d’implantation et consommation énergétique
La conception de cette application conduit à un modèle général de tâches périodiques
avec relations de précédence, ayant un sous-ensemble de tâches identiques indépendantes.
Parce que les résultats de cette thèse concernent les tâches indépendantes, nous traitons par la
suite ce sous-ensemble, constitué par les quatre tâches qui implémentent le CMAC pour la
prédiction des quatre coefficients par ondelettes.
Les quatre tâches sont périodiques, identiques, indépendantes et synchrones, ce qui
nous permet d’appliquer les résultats de la section §III.7 pour déterminer le nombre de
processeurs et les vitesses d’exécution des tâches pour une minimisation de la consommation
énergétique. Nous supposons connues :
• les valeurs SMIN et SMAX pour les plates-formes envisagées,
• une estimation de la fonction de puissance dissipée g, associée à chaque tâche,
148
ANNEXE 1
Etude de cas
• le nombre de cycles de processeur C qui correspondent à chaque tâche,
• l’échéance D de chaque tâche, estimée en fonction du scénario entier des tâches.
Conformément au Théorème III.6, si l’inégalité C D ≤ S MAX est vérifiée pour au
moins une des plates-formes envisagées, alors il existe un ordonnancement faisable de
l’ensemble de tâches, et la/les plate(s)-forme(s) trouvée(s) est/sont à prendre en considération
pour les autres estimations. (Au contraire, la discussion est close par l’inexistence d’un
ordonnancement faisable.) Dans ce cas, le Théorème III.7 assure l’existence d’un
ordonnancement global optimal de l’ensemble de tâches ; si S MIN ≤ C D et la fonction
h(S ) = g (S ) S est convexe et dérivable au deuxième ordre, alors cet ordonnancement est
obtenu par une plate-forme à 4 processeurs et la valeur de la consommation énergétique
optimale est 4 Dg (C D ) , les quatre processeurs exécutant chacun une tâche avec la vitesse
C D.
La condition de convexité de la fonction h(S ) = g (S ) S est vérifiée pour le cas
particulier des fonctions de puissance dissipée évoquées généralement dans la littérature, mais
il n’est pas prouvé que cela serait valable pour toutes les plates-formes et tâches possibles.
Si la condition S MIN ≤ C D n’est pas vérifiée, alors la vitesse d’exécution des tâches
sur la plate-forme à 4 processeurs est S MIN et l’énergie consommée 4 Dg (S MIN ) . Dans ce cas
il faut vérifier la consommation optimale sur des plates-formes à nombre inférieur de
processeurs et comparer les résultats. Pour cela, supposons que la puissance dissipée peut être
approximée par une fonction polynomiale de degré minimum 2 ; des estimations sur les
vitesses des tâches et les consommations sont données dans le tableau suivant, par
l’application de l’algorithme présenté à la page 109. Les vitesses supérieures à S MAX
n’assurent pas la faisabilité de l’ordonnancement. Pour obtenir les valeurs exactes des vitesses
et de l’énergie consommée, il faut remplacer les paramètres par leurs valeurs supposées
connues par des estimations faites a priori. La solution reste à trouver en commençant par le
nombre maximal de processeurs et en vérifiant les restrictions.
Nombre de
processeurs
Restrictions
Vitesses
4C / D ≤ S MIN
S MIN
Energie consommée
4
1
r
∑a S
i =1
i
i
MIN
4i C i
D ∑ ai
Di
i =1
r
S MIN < 4C / D ≤ S MAX
4C / D
2C / D ≤ S MIN
S MIN
4
2
3
C
S MIN
C
S MIN
r
∑a S
i =1
i
i
MIN
2i C i
2 D ∑ ai
Di
i =1
r
S MIN < 2C / D ≤ S MAX
2C / D
2C / D ≤ S MIN
S MIN
149
4
C
S MIN
r
∑a S
i =1
i
i
MIN
ANNEXE 1
Etude de cas
C / D ≤ S MIN ≤ 2C / D
S MIN < C / D
C / D ≤ S MIN
2CPU – 1 tâche –
S MIN
1CPU – 2 tâches –
2C / D
2CPU – 1 tâche –
C /D
1CPU – 2 tâches –
2C / D
S MIN
4
S MIN < C / D ≤ S MAX
2
C
S MIN
r
r
i =1
i =1
i
+ D ∑ ai
∑ ai S MIN
2i C i
Di
r
2i C i
Ci
2 D ∑ ai i + D ∑ ai
Di
D
i =1
i =1
r
4
C
S MIN
r
∑a S
i =1
i
i
MIN
Ci
4 D ∑ ai i
D
i =1
r
C /D
Tableau A1. Estimations pour les vitesses des tâches et l’énergie consommée.
En ce qui concerne l’implantation de l’application, compte tenu de l’étude faite au
Chapitre IV et des propriétés du sous-ensemble de tâches traité, les plates-formes à utiliser
peuvent être les suivantes :
•
cas monoprocesseur : tout processeur ayant la vitesse ajustée a priori, et la version
RTAI pour le UP ;
•
cas multiprocesseur :
o ARM à partir de v6 avec RealView Developper Suite pour Carte mère
Integrator/AP et RedHat Linux, ou
o Altera Nios avec GNUPro du RedHat et le kit développement Linux
Microtronix.
En ce qui concerne RTAI, il faut utiliser l’ordonnanceur pour SMP, adapté pour
permettre aux processeurs d’avoir des vitesses différentes entre eux, mais
constantes pour chaque processeur et connues a priori.
A1.6. Conclusions
La conception de cette application fournit un modèle général de tâches périodiques
avec relations de précédence, ayant un sous-ensemble de tâches identiques indépendantes, et
nous a servie comme exemple pour la manière d’appliquer les résultats développés dans cette
thèse. Les besoins de déterminisme de l’exécution de l’application et l’optimisation de la
consommation d’énergie convergent vers une plate-forme multiprocesseur. La validation
physique reste à faire sur une des plates-formes présentées.
150
ANNEXE 2
Caractéristiques concernant la gestion de puissance
pour les modèles Crusoe SE TM 55E/TM58E
Le tableau suivant présente les principales caractéristiques des points standard d’intervention
du gestionnaire de puissance LongRun pour les modèles Crusoe SE TM 55E/TM58E.
Processeur
Core
SKU
TM58EX-933
(mémoire à
133 MHz)
TM58EX-933
(mémoire à
100 MHz)
TM58EL-800
(mémoire à
133 MHz)
TM58EL-800
(mémoire à
100 MHz)
TM55EL-667
(mémoire à
133 MHz)
TM55EL-667
(mémoire à
100 MHz)
MHz
V
933
800
667
533
400
300
900
800
700
600
500
400
300
800
667
533
433
300
800
700
600
500
400
300
667
533
433
300
600
500
400
300
1,3
1,2
1,1
1,0
0,9
0,8
1,30
1,20
1,15
1,05
0,975
0,90
0,80
1,20
1,10
1,00
0,925
0,80
1,20
1,15
1,05
0,975
0,90
0,80
1,10
1,00
0,925
0,80
1,05
0,975
0,90
0,80
DDR-266
Température
maximale
100°C
100°C
100°C
100°C
100°C
100°C
Interface mémoire
DDR-200 SDR-133
Puissance
SDR-100
MHz
MHz
MHz
MHz
133
133
133
133
133
100
–
–
–
–
–
–
–
133
133
133
108
100
–
–
–
–
–
–
133
133
108
100
–
–
–
–
–
–
–
–
–
–
100
100
100
100
100
100
100
–
–
–
–
–
100
100
100
100
100
100
–
–
–
–
100
100
100
100
133
133
133
133
133
100
–
–
–
–
–
–
–
133
133
133
108
100
–
–
–
–
–
–
133
133
108
100
–
–
–
–
–
–
–
–
–
–
100
100
100
100
100
100
100
–
–
–
–
–
100
100
100
100
100
100
–
–
–
–
100
100
100
100
Tableau A2. Caractéristiques des modèles Crusoe SE TM 55E/TM58E [CRU 03].
151
TDP
9,0 W
6,8 W
5,1 W
3,7 W
2,6 W
1,7 W
8,8 W
6,8 W
5,6 W
4,3 W
3,3 W
2,6 W
1,7 W
6,8 W
5,1 W
3,7 W
2,9 W
1,7 W
6,8 W
5,6 W
4,3 W
3,3 W
2,6 W
1,7 W
5,1 W
3,7 W
2,9 W
1,7 W
4,3 W
3,3 W
2,6 W
1,7 W
BIBLIOGRAPHIE
[AIV 00]
T. Aivazian, “Linux Kernel Internals”, 2000, sur le site Internet
http://www.moses.uklinux.net/patches/lki.sgml.
[ALB 75]
J. Albus, “A new approch to manipulator control: the cerebellar model
articulation controller (CMAC)”, Journal of Dynamic Systems Measurement
and Control, 1975.
[ALT 03]
“ARM-Based Embedded Processor PLD Stripe Power Consumption”, 2003,
www.altera.com/wp_expan_power_consumption.pdf .
[APX 03]
www.altera.com/apex_power_consumption_comparison.pdf, 2003.
[ARM 03]
www.arm.com pour les plates-formes et les outils de développement ARM,
2003.
[AYD 01a]
H. Aydin, R. Melhem, D. Mossé et P. Mejía-Alvarez, “Optimal Reward-Based
Scheduling for Periodic Real-Time Tasks”, IEEE Trans. on Computers, Vol.
50, No. 2, Feb. 2001.
[AYD 01b]
H. Aydin, R. Melhem, D. Mossé et P. Mejía-Alvarez, “Determining Optimal
Processor Speeds for Periodic Real-Time Tasks with Different Power
Characteristics”, Euromicro Conf. on Real-Time Systems, Jun. 2001.
[AYD 01c]
H. Aydin, R. Melhem, D. Mossé et P. Mejía-Alvarez, “Dynamic and
Aggressive Scheduling Techniques for Power-Aware Real-Time Systems”,
Real-Time Systems Symposium (RTSS’01), London, England, Dec. 2001.
[BAK 91]
T. P. Baker, “Stack-Based Scheduling of Real-Time Processes”, Journal of
Real Time Systems, N° 3, 1991.
[BAR 00a]
M. Bar, “Le Scheduler Linux. Planifier et répartir les tâches”, dans “Linux+”,
N° 4, 2000.
[BAR 00b]
M. Bar, “Linux Internals”, McGraw-Hill, 2000.
[BAR 91]
S. Baruah, G. Koren, D. Mao, B. Mishra, A. Raghunathan, L. Rosier, D.
Shasha et F. Wang, “On the Competitiveness of On-Line Real-Time Task
Scheduling”, Proceedings of Real-Time Systems Symposium, 1991.
[BAR 97]
M. Barabanov, “A Linux Based Real-Time Operating System”, M. S. Thesis,
http://rtlinux.cs.nmt.edu/~baraban/thesis/, 1997.
[BER 00]
A. Berlat, J.-F. Bouchaudy et G. Goubet, “Linux Administration”, Tsoft Ed.,
Eyrolles, 2000.
153
Bibliographie
[BLA 00]
C. Blaess, “Programmation système en C sous Linux”, Ed. Eyrolles, 2000.
[BLA 01]
C. Blaess, “Langages de scripts sous Linux”, Ed. Eyrolles, 2001.
[BLU 99]
Bluetooth Special Interest Group, “Specifications of the Bluetooth system
1.0b, Volume 1 : Core”, http://www.bluetooth.com.
[BON 99]
C. Bonnet et I. Demeurre, “Introduction aux systèmes temps-réel”, Ed.
Hermes, 1999.
[BOV 01]
D. P. Bovet et M. Cesati, “Understanding the Linux Kernel”, O’Reilly, 2001.
[BRA 02]
D. Brash, “The ARM Architecture Version 6”, ARMv6_Architecture.pdf,
[ARM], 2002.
[BRE 95]
E. Brewer, T. Burd, F. Burghardt, A. Burstein, R. Doering, K. Lutz, S.
Narayansaramy, T. Pering, B. Richards, T. Truman, R. Katz, J. Rabaey et R.
Brodersen, “Design of Wireless Portable Systems”, Proceedings of the IEEE
International Computer Society Conference (COMPCON95), pp. 169-176,
Mar. 1995.
[BRO 95]
R. W. Brodersen et A. Chandrakasan, “Minimizing Power Consumption in
Digital CMOS Circuits”, Proceedings of the IEEE, Vol. 83, No. 4, pp. 498523, Apr. 1995.
[BRO 03]
D. Brooke, Senior Product Specialist ARM Ltd., communication privée, 2003.
[CAM 98]
I. Campagna et R. Li, “Comparaison de performance entre Linux et
RTLinux”, Projet de cours, Ecole Polytechnique de Montreal, Déc. 1998.
[CHA 92]
A. P. Chandrakasan, S. Sheng et R.W. Brodersen, “Low-Power CMOS Digital
Design”, IEEE Journal of Solid-State Circuits, Vol. 27, No. 4, pp. 473-484,
Apr. 1992.
[CHA 96]
A. P. Chandrakasan, V. Gutnik et T. Xanthopoulos, “Data Driven Signal
Processing: An Approach for Energy Efficient Computing”, Proceedings of the
1996 International Symposium on Low-Power Electronics and Design, pp.
347-352, 1996.
[CHE 90]
M. Chen et K. Lin, “Dynamic Priority Ceilings : A Concurrency Control
Protocol for Real-Time Systems”, Journal of Real-Time Systems, 2, 1990.
[COF 76]
E. G. Coffman Jr., “Introduction to Deterministic Scheduling Theory”, in:
Coffman, E. G. Jr. (Edt.), “Computer and Job-Shop Scheduling Theory”,
Willey, 1976.
[COT 00]
F. Cottet, J. Delacroix, C. Kaiser et Z. Mammeri, “Ordonnancement temps
réel”, Ed. Hermes, 2000.
[CRU 03]
“Crusoe SE Processor Product Brief. TM55E/TM58E v2.1 Embedded
Processors”, TM58Ev2.1_productbrief_030206.pdf, [TRA], 2003.
[DEL 94]
J. Delacroix, “Stabilité et régisseur d’ordonnancement en temps réel”,
Technique et Science Informatique, Vol. 13, N° 2, p. 223-250, 1994.
154
Bibliographie
[DEL 96]
J. Delacroix, “Towards a stable Earliest Deadline scheduling algorithm”,
Journal of Real-Time Systems, Vol. 10, N° 3, p. 263-291, 1996.
[DEL 98]
J. Delacroix et C. Kaiser, “Un model de tâches temps réel pour la résorption
contrôlée des surcharges”, RTS’98, p. 45-61, Paris, 1998.
[DEP 02]
A.-M. Deplanche, O.-H. Roux, “Ordonnancement
Ordonnançabilité”, Réunion AS SOC, Paris, 24 juin 2002.
[DER 74]
M. Dertouzos, “Control Robotics: the procedural control of physical
processors”, Proceedings of the IFIP Congress, p. 807-813, 1974.
[DER 89]
M. L. Dertouzos et A. K. Mok, “Multiprocessor On-Line Scheduling of HardReal-Time Tasks”, IEEE Transactions on Software Engineering, Vol. 15, No.
12, December 1989.
[DIC 00]
R. P. Dick, G. Lackshminarayana, A. Raghunathan et N. K. Jha, “Power
Analysis of Embedded Operating Systems”, Design and Automation
Conference, pp. 312–315, 2000.
[DOU 99]
B. P. Douglas, “Doing Hard Time. Developing Real-Time Systems with UML,
Objects, Frameworks, and Patterns”, Addison-Wesley, 1999.
[FEC 01]
A. Feczko, “Quality of Service On Embedded Real-Time Linux”, Applied
Computing Conference 2001.
[FLE 01]
M. Fleischmann, “LongRun™ Power Management. Dyamic Power
Management for Crusoe™ Processors”, paper_mfleischmann_17jan01.pdf,
[TRA], 2001.
[FLI 99]
M. Flinn et M. Satyanarayanan, “Energy-Aware Adaptation for Mobile
Application”, ACM SOSP, pp. 48–63, Dec. 1999.
[GAR 74]
M. R. Garey et D. S. Johnson, “Complexity results for multiprocessor
scheduling under resource constraints”, Proc. Eighth Annual Princeton Conf.
Information Sciences and Systems, p. 168-172, 1974.
[GAR 75]
M. R. Garey et D. S. Johnson, “Complexity results for multiprocessor
scheduling under resource constraints”, SIAM Journal of Computing, 1975.
[GAR 77]
M. R. Garey et D. S. Johnson, “Two-processor scheduling with start times and
deadlines”, SIAM J. Comput., vol. 6, p. 416-426, 1977.
[GAR 79]
M. R. Garey et D. S. Johnson, “Computers and Intractability. A Guide to the
Theory of NP-Completeness”, Bell Telephone Laboratories, Inc., 1979.
[GEO 96]
L. George, N. Rivierre et M. Spuri, “Preemptive and Non-Preemptive RealTime Uniprocessor Scheduling”, INRIA Rocquencourt, France, Rapport de
recherché n° 2966, Septembre 1996.
[GEO 00]
L. George, P. Mühlethaler et N. Rivierre, “A Few Results on Non-Preemptive
Real Time Scheduling“, INRIA Rocquencourt, France, Research Report 3926,
2000.
155
temps
réel
et
Bibliographie
[GOO 01]
J. Goossens, S. Funk et S. Baruah, “Priority-driven scheduling of periodic
task systems on multiprocessors”, accepted for publications in “Real-Time
Systems: The International Journal of Time-Critical Computing”, 2001.
[GOO 02]
J. Goossens, S. Baruah et S. Funk, “Real-Time Scheduling on
Multiprocessors”, dans “Actes des conferences”, RTS Embedded Systems,
mars 2002.
[GOV 95]
K. Govil, E. Chan et H. Wasserman, “Comparing Algorithms for Dynamic
Speed-Setting of a Low-Power CPU”, First ACM International Conference on
Mobile Computing and Networking, 1995.
[GRA 76]
R. Graham, “Bounds on the Performance of Scheduling Algorithms”, chapitre
de “Computer and Job Shop Scheduling Theory”, John Willey and Sons, p.
165-227, 1976.
[GUT 96]
V. Gutnik et A. Chandrakasan, “An Efficient Controller for Variable Supply
Voltage Low Power Processing”, Symposium on VLSI Circuits, pp. 158-159,
1996.
[HAL 00]
T. R. Halfill, “Transmeta Breaks x86 Low-Power Barrier”, Microprocessor
Report, Fév. 2000.
[HAR 91]
J. R. Haritsa, M. Livny et M. J. Carey, “Earliest Deadline Scheduling for
Real-Time Database Systems”, Proceedings of Real-Time Systems
Symposium, 1991.
[HAV 00]
P. J. M. Havinga et G. J. M. Smith, “Design Techniques for Low Power
Systems”, Journal of Systems Architecture, Vol. 46:1, 2000.
[HOL 02]
C. Hollabaugh, “Embedded Linux. Hardware, Software and Interfacing”,
Addison-Wesley, 2002.
[HON 98]
I. Hong, G. Qu, M. Potkonjak et M. Srivastava, “Synthesis Techniques for
Low-Power Hard Real-Time Systems on Variable Voltage Processors”,
Proceedings of the 19th IEEE Real-Time System Symposium (RTSS’98),
Madrid, Dec. 1998.
[HON 99]
I. Hong, D. Kirovski, G. Qu, M. Potkonjak et M. Srivastava, “Power
Optimization of Variable-Voltage Core-Based Systems”, IEEE Transactions on
Computer-Aided Design of Integrated Circuits and Systems, Vol. 18, No. 12,
Dec. 1999.
[IDC 02]
http://www.idc.com pour International Data Corporation, 2002.
[INT 99]
Intel, “Pentium III Processor Mobile Module: Mobile Module Connector 2
(MMC-2) Featuring Intel Speed Step Technology”, Technological Report,
1999.
[ISH 98]
T. Ishihara et H. Yasuura, “Voltage Scheduling Problem for Dynamically
Variable Voltage Processor”, ISLPED, pp. 197–202, Aug. 1998.
[JAC 55]
J. R. Jackson, “Scheduling a Production Line to Minimize Maximum
Tardiness”, Research Report 43, Management Science Research Project,
University of California, Los Angeles, 1955.
156
Bibliographie
[KAI 81]
C. Kaiser, “De l’utilisation de la priorité en présence d’exclusion mutuelle”,
Rapport de recherche N° 84, INRIA, 1981.
[KAT 93]
D. I. Katcher, J. P. Lehoczky et J. K. Strosnider, “Scheduling Models of
Dynamic Priority Schedulers”, Research Report CMUCDS-93-4, Carnegie
Mellon University, Pittsburgh, 1993.
[KLA 00]
A. Klaiber, “The Technology Behind Crusoe™ Processors”, Transmeta
Corporation White Paper, [TRA 03], Jan. 2000.
[KRA 89]
L. G. Kraft, 1989, “A Comparison of CMAC Neural Network and Two
Traditional Adaptive Control Systems”, The American Control Conference
1989, IEEE Control System Magazine, 10(3), 36-43.
[KRA 90]
L.G. Kraft, D. A. Campagna, “Comparison between CMAC Neural Network
Control and two traditional Adaptive Control Systems”, American Control
Conference, Pittsburgh 1989, pp 21-23.
[KRI 00]
C. M. Krishna et Y. H. Lee, “Voltage-Clock-Scaling Adaptive Scheduling
Techniques for Low-Power in Hard Real-Time Systems”, RTAS, May 2000.
[KRT 01]
http://www.ittc.ukans.edu/kurt/ pour KURT, 2001.
[LAW 83]
E. L. Lawler, “Recent Results in the Theory of Machine Scheduling”,
Mathematical Programming: the State of the Art, A. Bachen et al. (eds.),
Springer Verlag, New York, 1983.
[LEB 00]
A. Lebeck, X. Fan, H. Zeng et C. Ellis, “Power Aware Page Allocation”,
ACM ASPLOS, pp. 105–116, Jun. 2000.
[LEE 96]
M. Tien-Chiem Lee, V. Tiwari, S. Malik et M. Fujita, “Power Analysis and
Minimization Techniques for Embedded DSP Software”, IEEE Trans. on VLSI
Systems, Dec. 1996.
[LEH 89]
J. P. Lehoczky, L. Sacha et Y. Ding, “The Rate Monotonic scheduling
algorithm: exact characterization and average case behaviour”, Proceedings
of Real-Time Systems Symposium, p. 166-171, 1989.
[LEN 77]
J. K. Lenstra et A. H. G. Rinnooy Kan, “Optimization and Approximation in
Deterministic Sequencing and Scheduling: A Survey”, Ann. Discrete Math. 5,
p. 287-326, 1977.
[LEU 80]
J. Leung et M. Merrill, “A Note on Preemptive Scheduling of Periodic RealTime Tasks”, Information Processing Letters, Vol. 11, No. 3, p. 115-118,
1980.
[LIN 03]
http://www.linux.it/kerneldocs/ pour une documentation complète sur le noyau
Linux, 2003.
[LIS 00]
S. List, “RTAI”, http://www.courseforge.fr, 2000.
[LIU 73]
C. L. Liu et J. Layland, “Scheduling algorithms for multiprogramming in a
hard-real-time environment”, JACM, Vol. 20, No. 1, January 1973.
[LIU 00]
J. W. S. Liu, “Real-Time Systems”, Prentice Hall, 2000.
157
Bibliographie
[LNO 03]
http ://www.lineo.com/ pour Lineo™, 2003.
[LOS 03]
http ://www.lynuxworks.com/rtos/lynxos.php3 pour LynxOS, 2003.
[MAL 89]
S. Mallat “A theory for multi-resolution signal decomposition the wavelet
representation”, IEEE Pattern Anal. and Machine Intell., vol. 11, no. 7, pp
674-693, 1989.
[MAL 94]
S. Malik, V. Tiwari et A. Wolfe, “Power Analysis of Embedded Software: A
First Step Towards Power Minimization”, Int. Conf. on Computer Aided
Design, San Jose, California, Nov. 1994.
[MEL 02]
R. Melhem, N. AbouGhazaleh, H. Aydin et D. Mossé, “Power Management
Points in Power-Aware Real-Time Systems”, dans “Power Aware Computing”,
R. Graybill et R. Melhem (Eds.) Plenum/Kluwer Publishers, 2002.
[MER 94]
G. Mercier, K. Madani, G. Crespy, C. Barret, “A New on-line CMAC
Algorithm for Real Time Applications”, Int. Conf. on Regional Informatics
RI'94, St. Petersburg, Russia, May 1994.
[MER 95]
G. Mercier, K. Madani, “CMAC Real-Time Adaptive Control Implementation
on a DSP Based Card”, in J. Mira, F. Sandoval (Eds.), “From Natural to
Artificial Neural Computation”, Int. Workshop on Artificial Neural Networks,
Malaga-Torremolinos, Spain, June 1995.
[MER 01a]
G. Mercier, D. Vîlcu et L. George, “Real Time Application on a CMAC
Neural Network”, ANNIE 2001 Smart Engineering Systems Design
Conference, ASME Press, Vol. 11, pp. 477-484, C. Dagli et all. (Eds.), 2001 ;
[MER 01b]
G. Mercier et D. Vîlcu, “Predictive Control Based on CMAC Networks for
colour video transmission in a wireless LAN”, 9th Int. Conf. on Applied
Mathematics and Informatics, Oct. 2001, Piteşti, Roumanie ;
[MER 01c]
A. Mercier, P. Minet, L. George, G. Mercier “An overview and comparative
evaluation of wireless protocols”, IEEE International Conference on Wireless
LANs and Home Networks (ICWLHN_2001 proceedings, to be published in
Dec 2001);
[MER 02]
G. Mercier, D. Vîlcu et S. Chebira, “Real Time Wireless Transmission of
Medical Images Using Predictive Control Based on CMAC Neural Networks”,
IEEE Communications Conf. 2002, Bucarest, Roumanie.
[MIC 03]
http://www.microtronix.com pour Linux Development Kit, 2003.
[MNA 59]
R. McNaughton, “Scheduling With Deadlines and Loss Functions”,
Management Science, 6, p. 1-12, 1959.
[MOK 83]
A. K. Mok, “Fundamental Design Problems for the Hard Real-Time
Environments”, MIT Ph.D. Dissertation, May 1983.
[MON 00]
P. Montegazza, E. Bianchi, L. Dozio, S. Papacharalambous, S. Hughes, et D.
Beal, “RTAI : Real Time Application Interface. Le temps réel sous Linux”,
dans “Linux+”, N° 4, may 2000.
[MVS 03]
http://www.mvista.com pour Montavista’s hard real-time kernel, 2003.
158
Bibliographie
[NAM 97]
W. Namgoong, M. Yu et T. Meng, “A High-Efficiency Variable-Voltage
CMOS Dynamic DC-DC Switching Regulator”, Proceedings of the ISSCC’97,
1997.
[NIL 00]
J. Nilsson et D. Rytterlund, “Real Time Linux Investigation”, Mälardalen
Real-Time Research Center Report, 2000.
[NOB 00]
B. Noble, “System Support for Mobile, Adaptive Applications”, IEEE Personal
Communications, pp. 44–49, Feb. 2000.
[NOB 97]
B. Noble, M. Satyanarayanan, D. Narayanan, J. E. Tilton, J. Flinn et K. R.
Walker, “Agile Application-Aware Adaptation for Mobility”, ACM SOSP, pp.
276–287, 1997.
[NPX 03]
www.altera.com/npx_nios.pdf, 2003.
[NUT 00]
G. Nutt, “Operating Systems. A Modern Perspective”, 2nd Edition, AddisonWesley, 2000.
[NUT 01]
G. Nutt, “Kernel Projects for Linux”, Addison-Wesley, 2001.
[OHS 95]
Y. Oh et S. H. Son, “Fixed-priority scheduling of periodic tasks on
multiprocessor systems”, Journal of Real-Time Systems, Vol. 9, N° 3, 1995.
[ORD 03]
http ://www.mathematik.uni-osnabrueck.de/research/OR/class pour la liste des
problèmes d’ordonnancement, 2003.
[PAP 01]
“Papyrus Tool Kit Download”, http://www.expasy.hcuge.ch/UIN, University
Hospital of Geneva, 2001.
[PAR 01]
F. Parain, M Banâtre, G. Cabillic, T. Higuera, V. Issarny et J.-Ph. Lesot,
“Techniques de reduction de la consummation dans un système embarqué
temps réel”, Technique et science informatiques, Vol. 20, N° 10/2001, p.
1247-1278.
[PAR 02]
F. Parain, “Ordonnancement sous contraintes énergétiques d’applications
multimédia sur une plate-forme multiprocesseur hétérogène”, Thèse
doctorale, Université de Rennes 1, mai 2002.
[PED 96]
M. Pedram, “Power Minimization in IC Design: Principles and Applications”,
ACM Transactions on Design Automation of Electronics Systems, Vol. 1:1,
pp. 3-56, Jan. 1996.
[pSO 03]
http ://www.windriver.com/products/psosystem_3/ pour pSOSystem, 2003.
[QNX 03]
http ://www.qnx.com/products/ps_neutrino/ pour QNX/Neutrino, 2003.
[RAJ 95]
R. Rajkumar, L. Sha, J. P. Lehoczky et K. Ramamritham, “An Optimal
Priority Inheritance Policy for Synchronization in Real-Time Systems”, dans
“Advances in Real-Time Systems”, S. H. Song (Ed.), Prentice-Hall, 1995.
[RAM 90]
K. Ramamritham, J. Stankovic et P. Shiah, “Efficient Scheduling Algorithms
for Real-Time Multiprocessor Systems”, IEEE Transactions on Parallel and
Distributed Computing, Vol. 1, N° 2, p. 184-194, Apr. 1990.
[RED 00]
GNUPro Toolkit®, “Users Guide for Altera Nios™”, Red Hat, 2000.
159
Bibliographie
[RED 03]
http://lingo.ece.uci.edu/~wycc/REDLinux.html pour REDLinux, 2003.
[RTA 03]
http://www.aero.polimi.it/projects/rtai/, le site de référence du projet RTAI,
2003.
[MOU 03]
P. Mourot, “RTAI Internal Presentation”, à partir de [RTA 03].
[RTb 03]
“DIAPM RTAI - Beginner's Guide”, à partir de [RTA 03], 2003.
[RTL 03]
http://www.fsmlabs.com pour RTLinux, 2003.
[RTp 03]
“DIAPM RTAI - Programming Guide 1.0”, à partir de [RTA 03], 2003.
[RUB 00]
A. Rubini, “Kernel System Calls”, Linux Magazine, Déc. 2000.
[RUB 02]
A. Rubini et J. Corbet, “Pilotes de périphériques sous Linux”, 2e édition en
français, O’Reilly, 2002.
[RUS 99]
D. A. Rusling, “The Linux Kernel”, Version 0.8-3, http://www.ibiblio.org,
1999.
[SHA 90]
L. Sha, R. Rajkumar et S. Sathaye, “Priority Inheritance Protocols : An
Approach to Real-Time Synchronization”, IEEE Transactions on Computers,
39(9), p. 1175-1185, 1990.
[SHE 93]
C. Shen, K. Ramamritham et J. Stankovic, “Resource Reclaiming in
Multiprocessor Real-Time Systems”, IEEE Transactions on Parallel and
Distributed Computing, Vol. 4, N° 4, 1993.
[SHI 99]
Y. Shin et K. Choi, “Power Conscious Fixed Priority Scheduling for Hard
Real-Time Systems”, Proc. of the 36th Design Automation Conference,
DAC’99, 1999.
[SIL 00]
A. Silberschatz, P. Galvin et G. Gagne, “Principes appliqués des systèmes
l’exploitation”, Vuibert, Paris (original : “Applied Operating System
Concepts”, First Edition 2000, John Wiley & Sons, Inc.), 2001.
[SMI 56]
W. Smith, “Various Optimizers for Single Stage Production”, Naval Research
Logistics Quarterly, 3, p. 59-66, 1956.
[STA 95]
J. A. Stankovic, M. Spuri, M. Di Natale et G. Buttazzo, “Implications of
Classical Scheduling Results for Real-Time Systems”, IEEE Computer, Vol.
28, 8, p. 16-25, 1995.
[THA 89]
P. Thambidurai et K. S. Trivedi, “Transient Overloads in Fault-Tolerant RealTime Systems”, Proceedings of Real-Time Systems Symposium, 1989.
[THI 00]
L. Thiele, S. Chakraborty et M. Naedele, “Real Time Calculus for Scheduling
Hard Real-Time Systems”, IEEE International Symposium on Circuits and
Systems, pp. 101–104, May 2000.
[TiS 03]
http://www.TimeSys.com pour TimeSys Linux/RT, 2003.
[TRA 03]
http://www.transmeta.com pour les processeurs Crusoe de Transmeta, 2003.
160
Bibliographie
[TUR 00]
A. Turier, "Etude, conception et caractérisation de mémoire CMOS, faible
consommation, faible tension en technologie submicronique", Thèse de
doctorat Informatique, Univ. Paris 6, Déc. 2000.
[VAH 00]
A. Vahdat, A. Lebeck et C. Ellis, “Every Joule is Precious: The Case for
Revisiting Operating System Design for Energy Efficiency”, ACM SIGOPS
European Workshop, 2000.
[VAN 01]
L. VanZandt, “Real-time Programming and Using Linux Therein”, 2001,
http://www.TimeSys.com.
[VIL 02]
D. Vîlcu et G. Mercier, “A New Approach to Minimize the Energy
Consumption of Hard Real Time Embedded Systems”, IEEE Communications
Conf., Bucarest, Roumanie, Déc. 2002.
[VRT 03]
http://www.acceleratedtechnology.com/embedded/vrtx.html
2003.
[VxW 03]
http://www.windriver.com/platforms/platformvdt/ pour VxWorks, 2003.
[WEI 94]
M. Weiser, B. Welch, A. Demers et S. Shenker, “Scheduling for Reduced CPU
Energy“, Proceedings of the First Symposium on Operating System Design
and Implementation, Nov. 1994.
[WEI 99]
K. Weiss, T. Steckstor et W. Rosenstiel, “Performance Analysis of an RTOS
by Emulation of an Embedded System”, IEEE International Workshop on
Rapid System Prototyping, pp. 146–151, 1999.
[WES 88]
N. Weste et K. Eshragian, “Principles of CMOS VLSI Design: A Systems
Perspective”, Addison-Wesley, MA, 1988.
[WOL 00]
W. Wolf, “Computers and Components Principles of Embedded Computing
System Design”, Morgan Kaufman Publishers, 2000.
[XIL 03]
www.xilinx.com/dsz083-2.pdf, 2003.
[YAO 95]
F. Yao, A. Demers, S. Schenker, “A Scheduling Model for Reduced CPU
Energy”, Proc. 36th Annual IEEE Symposium on Foundations of Computer
Science (FOCS’95), 1995.
[YOD 00]
V. Yodaiken, “Yodaiken comments on MontaVista « hard real-time » Linux
kernel”, 12 sep. 2000, http://linuxdevices.com.
[YOD 01]
V. Yodaiken, “The dangers of priority inheritance”, sur le site
http://citeseer.nj.nec.com/yodaiken01dangers.html.
[ZHA 87]
W. Zhao, K. Ramamritham et J. Stankovic, “Preemptive Scheduling Under
Time and Resource Constraints”, Special Issue of IEEE Transactions on
Computers on Real-Time Systems, Vol. C-36, N° 8, p. 946-960, 1987.
161
pour
VRTX,
,
Résumé : Cette thèse traite le problème d’ordonnancement des tâches avec minimisation de la
consommation énergétique au niveau du/des processeur(s), pour les systèmes temps réel embarqués.
Le modèle considéré est celui des tâches périodiques indépendantes. Premièrement, des résultats
théoriques connus pour le cas monoprocesseur sont complétés. On obtient ici une formule exprimant
les vitesses d’exécution des différentes parties des tâches pour une solution statique optimale.
Deuxièmement, on élargit le problème pour les plates-formes multiprocesseur : « pour un ensemble
donné des tâches, une configuration d’un système temps réel embarqué optimale du point de vue
énergétique nécessite la connaissance du nombre de processeurs et des vitesses d’exécution des tâches
à tout moment de leur exécution ». Des résultats fondamentaux sur la faisabilité et l’optimalité sont
obtenus. Sur la base du concept d’ordonnancement global optimal, on fournit la solution statique et
celle dynamique pour le cas des tâches ayant des consommations énergétiques différentes. Afin de
minimiser la consommation énergétique, le nombre de processeurs doit être maximal. Troisièmement,
on détermine une condition nécessaire d’optimalité pour un ordonnancement sur une plate-forme
donnée, qui permet d’évaluer théoriquement le gain énergétique à l’augmentation du nombre de
processeurs. Les résultats indiquent des gains importants, montrant ainsi l’utilité de cette approche.
Dans la démarche de transposer en pratique ces résultats et afin de prendre en compte le coût
énergétique des tâches, des modifications au niveau du système d’exploitation sont proposées ; RTAILinux est pris en compte comme exemple. Des plates-formes adaptées ou adaptables aux résultats
mentionnés sont aussi évoquées : Transmeta Crusoe, ARM v6 et Altera Nios. L’Annexe 1 présente
l’étude de cas d’un système de transmission sans fil des vidéos médicales, qui implique l’existence
d’un ensemble de tâches périodiques identiques.
Real Time Embedded Systems: tasks scheduling with optimal power consumption
Abstract: This thesis treats the problem of tasks scheduling with minimal power consumption at the
processor(s) level, in the framework of real time embedded systems. The considered model is that of
periodical independent tasks. Firstly, known theoretical results for the uniprocessor case are
completed. A formula expressing the running speeds of different parts of tasks of an optimal static
solution is obtained here. Secondly, we enlarge the problem for multiprocessor platforms: “for a given
set of tasks, an energetically optimal configuration of a real time embedded system implies the
knowledge of the number of processors and of the running speeds of tasks at each instance of their
running time”. Fundamental results on feasibility and the optimality are obtained. Based on the
concept of globally optimal scheduling, we give the static and dynamic solutions for the case of tasks
with different consumptions. In order to minimize their power consumption, the number of processors
must be maximal. Thirdly, we determine a necessary condition of optimality for a scheduling on a
given platform, who allows us to evaluate the gain of power when increasing the number of
processors. The results show important gains, thus justifying the usefulness of this approach. For the
implementation of these results and in order to be able to manage the consumption of the tasks, we
propose modifications to be done at the operating system level; RTAI-Linux is used as example. We
also present some platforms adapted or adaptable to our mentioned results: Transmeta Crusoe, ARM
v6 and Altera Nios. Annexe 1 describes a system of wireless transmission of medical video images,
which yields a set of periodical identical tasks.
DISCIPLINE : INFORMATIQUE
MOTS-CLES : système temps réel embarqué, consommation énergétique du processeur,
ordonnancement, système d’exploitation
Laboratoire d’Informatique Industrielle et d’Automatique
122, rue Paul Armangot
94400 Vitry-sur-Seine