systÈmes temps rÉel embarquÉs ordonnancement optimal …doxa.u-pec.fr/theses/th0211370.pdf ·...

179
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 IEF, Université Paris Sud, Orsay M. Michel AUGUIN, Rapporteur I3S UNSA – CNRS, Sophia-Antipolis M. Zoubir MAMMERI, Rapporteur IRIT, Université Paul Sabatier, Toulouse M. Yvon TRINQUET, Rapporteur IRCCyN, Ecole Centrale de Nantes M. Yacine AMIRAT, Examinateur LIIA, Université Paris XII – Val de Marne M. Gilles MERCIER, Directeur de thèse LIIA, Université Paris XII – Val de Marne

Upload: others

Post on 27-May-2020

9 views

Category:

Documents


0 download

TRANSCRIPT

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 IEF, Université Paris Sud, Orsay M. Michel AUGUIN, Rapporteur I3S UNSA – CNRS, Sophia-Antipolis M. Zoubir MAMMERI, Rapporteur IRIT, Université Paul Sabatier, Toulouse M. Yvon TRINQUET, Rapporteur IRCCyN, Ecole Centrale de Nantes M. Yacine AMIRAT, Examinateur LIIA, Université Paris XII – Val de Marne M. Gilles MERCIER, Directeur de thèse 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

II.3.3. 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

II.3.4. Ordonnancement multiprocesseur………………………………………….. 29

II.3.4.1. Propriétés concernant l’ordonnancement des tâches indépendantes…. 30

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

III.3. 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

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. Conclusions et perspectives………………………………………………... 111

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

IV.3. 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.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……………………………………………………………….. 151

xi

LISTE DES FIGURES

Figure I.1.

Domaines concernés par la consommation énergétique optimale au niveau du/des processeur(s)…………………………………………. 3

Figure II.1. 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

Figure II.9. 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

Figure III.3. MP - vitesses optimales différentes pour des itérations différentes de la même tâche………………………………………………………... 70

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. ji

T1

et parties des deux tâches différentes, synchrones, avec

, exécutées par deux processeurs différents……………… ki

T2

kijiCC

21= 87

Figure III.8. Durant d’autres tâches asynchrones par rapport à

s’exécutent sur le premier processeur…...…………………………… ji

C1 ji

T1

88

Figure III.9. 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 2≥kπ , k=1,2…………………………………………. 102

Figure III.13. 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

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

Tableau IV.2. 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

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 plate-forme 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 :

( ) R∈≥= ppSSg p ,2 , ,

et d’autres, par une fonction polynomiale de degré minimum 2 :

( ) rj ,a ,r ,r ,Sa Sg j

r

j

jj ,,12

1K=∀∈≥∈= ∑

=

RN ,

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 (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’).

rii SaSg =)(

D’autre part, nous avons considéré le problème d’optimisation énergétique des plates-formes 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 ( ) MAXii

niSDC ≤

= ,,1max

K

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 : . 12 556,0 EE ≤

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 plate-forme 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 Etat de l’art II.1 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 pire-cas, 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 quelques-uns 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 quelques-

19

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 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 . 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].

NPR ∈

NPR ∈

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

i i

i

PCU

1,

et du facteur de charge du/des processeurs pour une configuration de n tâches périodiques :

∑=

=n

i i

i

DCCH

1.

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 Etat de l’art II.3.2.1. “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é 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 :

( )tL

( ) ( ) ( )tCtDtL −= .

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 :

ireelii DCL −= , ,

et le but est de minimiser la valeur maximale du retard :

iniLL

,,1max maxK=

= ,

avec un ordonnancement sans préemption, le problème d’optimisation se formalise comme :

max1 L nopmtn 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 :

max1 L nopmtn .

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 :

max,1 L r nopmtn i 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 :

max1,,1 L C r nopmtn ii = .

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 :

max,1 L r pmtn i .

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 : 1≤CH , et une condition nécessaire est : . 1≤U

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 : . 1≤U

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 [ 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.

[L,0

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

i i

i nnPC

112

1

.

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 NP-hard. 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 :

∑ réelii Cw ,1 ,

est donné par toute séquence qui met les tâches dans l’ordre non décroissant des rapports iii wCq = .

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 :

∑ réeliii Cw D ,1 .

Mais, par contre :

28

Chapitre II Etat de l’art Théorème II.17 : La solution du problème suivant est un algorithme polynomial optimal :

∑ réelii C D ,1 .

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 ts×

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 : . mU ≤

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

un ordonnancement faisable si n,1,i NDC

Di

i K=∀∈ , , où ( )nDDD ,,pgcd 1 K= .

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 : , ,

( ) kDTkR ii ≤= M1

( ) kDetkLTkR iii >≤= M2 ( ) kLTkR ii >= M3 , et ( ) (∑ )∑∈∈

−−−=21

*Ri

iRi

i LkCmkkF pour

, une fonction mesure du « surplus » de puissance de calcul du système pour les prochaines k unités de temps.

*N∈k

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 : ( ) 00,,0 ≥>∀ kF k .

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 non-pré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 : ( )L1017 pour FF et BF, où L représente le nombre minimal de processeurs, ( )L911 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érielTâche de fond Noyau ISRs Processus I Processus J

Programme

Processus matériel

Commutation vers un autre programme

BIOS

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

Exécution ISR Placement de l’appel système

Exécution de la fonction système

Retour de l’appel système

Ordonnancement de la nouvelle tâche

Exécution Bottom Half si nécessaire

L’exécution de la tâche continue

Commutation vers le code noyauIRQ

Lent

Rapide

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.

Partie matérielle

Noyau Temps Réel (RTLinux, RTAI, ...)

Tâche TR Tâche TR Tâche TR

Noyau Linux

Bibliothèques système

Processus Linux

Processus Linux

Niveau utilisateur

Niveau noyau

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 Optimisation de la consommation d’énergie

III.1. 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.

( )tCυCL

ic(t)

Vdd

A0 :

An

PMOS

NMOS

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] :

fuitecircuit-courtncommutatiomoyenne PPPP ++=

ddfuiteddcchorloge2

ddL10 VIVIfVC ++= →α .

Le premier terme représente le composant de la puissance dissipée dû aux commutations: est la capacité de charge, - la tension d’alimentation, - la

fréquence de l’horloge (le nombre de cycles d’horloge par seconde) et - 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, , 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,

, qui peut résulter du substrat d’injection et des effets de sous seuil ; il est déterminé par

LC ddV horlogef

10→α

ccI

fuiteI

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 :

2ddeffective

horloge

moyennetransition VC

fP

E == ,

où L10effective CC →= α

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 continue hachée continue 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

( )2tdd

dd

VV

VkT

−= ,

où k représente une constante et la tension seuil. tV

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 prend la valeur 1 pour la tension d’alimentation égale à la tension de référence, , ainsi que la vitesse normalisée . La formule a

été déduite pour et , et elle est donnée par :

nP

refdd VV = nS

V3,3=refV V8,0=tV

( ) nnnnnnnnn SSSSSSSSP ⋅+⋅+⋅+⋅⋅⋅+⋅+⋅= 059,0277,0147,0173,0512,1893,0164,0)( 2223 .

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 :

( ) R∈≥= ppSSg p ,2 , ,

et ceux des Aydin et al. [AYD 01a,b,c] avec une fonction polynomiale de degré minimum 2 :

( ) rjarrSaSg j

r

j

jj ,,1 , ,2 , ,

1K=∀∈≥∈= ∑

=

RN ,

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 :

( ) R∈≥= ppSSg p ,2 , .

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 : i

ii S

Ct = .

La fonction ( )Sgi 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 [ ]21 ,tt correspondant à l’exécution de la tâche Ti pendant cette période est donnée par :

( ) ( )( )∫=2

1

21 ,t

tii dt tSg ttE .

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 :

, où et représentent les valeurs extrêmes normalisées des vitesses du processeur.

10 maxmin =≤≤< SSS minS maxS

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.

( )

⎪⎪⎪⎪

⎪⎪⎪⎪

==≤≤

≤− ∑ ∑

∑ ∑

= =

= =

)4(S avec faisablement ordonnanceun existe Il

)3(,,1,,1

)2(

)1(min

)(

ij

maxmin

1

/

1

1

/

1

iij

n

i

PP

j ij

i

n

i

PP

jiji

PPjniSSS

PSC

SE

OPTPOWi

i

KK

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

i i

i

Pt

11.

60

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 :

iiikij P

PkjSSS ≤≤≤== 1, .

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é ( )nnO log2 [AYD 01a]. Ce problème est obtenu à

partir de POW-OPT par les changements de variables : i

ii t

CS = , ( )iii

ii tE

tCE '=⎟

⎠⎞

⎜⎝⎛ ,

maxSCl i

i = ,

minSCu i

i = et pour , et prend la forme exprimée par le problème d’optimisation

OPT-LU ci-dessous :

iii ltt += ' ni ,,1K=

( )( )

⎪⎪⎪

⎪⎪⎪

=−≤≤

≤+

+

− ∑∑

=

=

')3(,,1'0

')2('

')1(''min

)(1

1

nilut

PltPP

ltEPP

LUOPT

iii

n

iii

i

n

iiii

i

K

.

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 ( ), alors la solution optimale est constante et donnée par

niggi ,,1K=∀= , totUSS ,max min= , 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 Optimisation de la consommation d’énergie

III.2.3.3. 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 : représente le temps d’exécution pire-cas restant, au moment t, pour la tâche T

( )twSi

i, 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 assignées aux tâches. ∗id

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 SSi =ˆ , 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 niSSi ,...,1,ˆ =∀= .

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*.

( ) iSii wtrem ˆ=

4. A tout évènement (activation/fin d’une tâche), la valeur

de , qui correspond au premier élément de l’irem α -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. ; xx SS ˆ=5.1. Consultation de l’α -queue et calcul de l’indicateur de la plus proche terminaison de Tx :

( ) ( ) ( )∑∗∗ ≤

−=xi

x

ddi

Sxix twtremt

ˆε ;

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ù ( )tY xε≤≤0 .

6. A tout évènement de préemption ou de terminaison d’une

tâche Ti : , où représente le temps écoulé depuis le dernier dispatching de la tâche T

tSi

Si

ii ww ∆−= t∆i.

Procédure Réduction_vitesse(Tx, B, S)

1. SBwwS Sx

Sxx ⋅+=

2. Si alors minSSx < minSS x =

3. retourne xS

Théorème III.2 : A tout moment t de l’exécution du GDRA, pour toute tâche Ti :

( )tremtw iSi

i ≤)(ˆ .

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 , alors S

( ) 0>−−= twtNTAZ xSx

x = 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 : , 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.

10 maxmin =≤≤< SSS

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 ( )iji SE est une fonction convexe et

croissante stricte, si ( )iji Sg 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 ( )iji SE l’énergie consommée durant l’itération j de la tâche Ti, la durée qui

correspond à son exécution et le nombre de cycles processeur qui correspondent à cette

activation de la tâche. Comme

aijP

ijC

ijija

ij SCP = on peut déduire :

( ) ( ) ( ) ( )ijiijijia

ijP

ijiiji ShCSgPdtSgSEij

=== ∫ ,

où : ( ) ( ) SSgSh ii = .

Dans ces conditions, comme est une constante positive, la consommation énergétique

est une fonction convexe croissante si la fonction est convexe et croissante. Mais cette propriété de la fonction n’est pas du tout une conséquence des propriétés de convexité et de croissance de la fonction (et ni de la forme polynomiale). Bien au contraire, comme nous l’indiquons dans l’exemple suivant.

ijC iE

ih

ih

ig

65

Chapitre III Optimisation de la consommation d’énergie

Exemple : Soit la fonction de la puissance dissipée par le processeur donnée par :

( ) 432

121

31

21 SSSSg +−= .

En calculant les dérivées de premier et de deuxième ordre on obtient :

( )3

'3

2 SSSSg +−=

et, respectivement : ( ) ( ) 0121" 22 ≥−=+−= SSSSg .

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 ( ) 00' =g , on obtient 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].

( ) 0' ≥Sg

En ce qui concerne la fonction h, les résultats sont les suivants :

( ) ( ) 32

121

31

21 SSS

SSgSh +−== ,

( ) 2

41

32

21' SSSh +−=

et, respectivement,

( ) SSh21

32" +−= ,

d’où :

( )⎪⎩

⎪⎨

>>

≤≤

340340

"S pour

S pour Sh .

Donc, la fonction n’est ni convexe ni croissante stricte pour l’entier intervalle et, en conséquence, la consommation énergétique ne l’est pas pour cet intervalle.

"h[ +∞,0 [

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.

( ) ( ) ( )2

''S

SgSSgSh −=

( ) ( )2

'S

SgSSg

−= ,

d’où la deuxième dérivée est donnée par :

( ) ( ) ( )′

⎟⎟⎠

⎞⎜⎜⎝

⎛−

′⎟⎠⎞

⎜⎝⎛= 2

'"S

SgSSgSh

66

Chapitre III Optimisation de la consommation d’énergie

( ) ( ) ( ) ( )4

2

2

2S

SSgSgSS

SgSgS −′−

′−′′=

( ) ( ) ( ) ( )[ ]SSgSgSSgSSgSS

21 2234 +′−′−′′=

( ) ( ) ( )[ ]SgSgSSgSS

221 23 +′−′′= .

Notons aussi que, si la puissance dissipée a une forme polynomiale :

( ) rjarrSaSg j

r

j

jj ,,0 , ,2 , ,

0K=∀∈≥∈= ∑

=

RN ,

le terme libre indique la puissance dissipée si le processeur est arrêté (S=0) et il doit être positif ou nul.

0a

Exemple 1 : Soit , avec des coefficients réels, où et . Alors les fonctions et

( ) 2210 SaSaaSg ++= 00 ≥a 02 ≥a

( )Sg ( ) ( ) SSgSh = sont convexes.

Démonstration : Le calcul de la dérivée de deuxième ordre de la fonction g fournit :

( ) 02 2 ≥=′′ aSg , donc g est une fonction convexe.

Le calcul de la dérivée de deuxième ordre de la fonction h fournit :

( ) ( ) ( )[ ]221021

223 22221 SaSaaSSaaSa

SSh ++++−=′′

( )2210

221

223 2224221 SaSaaSaSaSa

S+++−−=

02

30 ≥=

Sa

,

donc h est une fonction convexe.

Exemple 2 : Soit . Alors les fonctions et ( ) 0 ,k , ,2 , >∈∈≥= kppkSSg p RR ( )Sg( ) ( ) SSgSh = sont convexes.

Démonstration : Le calcul de la dérivée de deuxième ordre de la fonction g fournit :

( ) ( ) 0pour ,01 2 ≥≥−=′′ − SpSpkSg p ,

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

( ) ( )( ) 0pour ,021 2 ≥≥−−=′′ − SSppkSh p ,

donc h est une fonction convexe.

Notons que la forme de la fonction g prise en compte par Yao et al. ([YAO 95]) est :

( ) R∈≥= ppSSg p ,2 , ,

et que les fonctions considérées dans les exemples de simulation proposés par Aydin et al. ([AYD 01b,c]) sont :

( ) 0 ,k ,3 >∈= kkSSg R ,

avec ou suivant une distribution uniforme dans l’intervalle 6,4,2=k [ ]8,1 . Par conséquent, les deux cas s’inscrivent dans l’exemple 2 ci-dessus mentionné.

Exemple 3 : Soit , où les fonctions ( ) ( )∑=

=A

SgSg1α

α ( ) SSgh αα = sont convexes pour

N , ∈= AA,,1Kα . Alors la fonction ( ) ( ) SSgSh = est convexe.

Démonstration : Le calcul de la dérivée de deuxième ordre de la fonction h fournit :

( ) ( ) ( ) ( )⎥⎦

⎤⎢⎣

⎡+′−′′=′′ ∑∑∑

===

AAA

SgSgSSgSS

Sh111

23 221

αα

αα

αα

( ) ( ) ( )[ ]∑=

+′−′′=A

SgSgSSgSS1

23 221

αααα

( )∑=

′′=A

Sh1α

α .

Or 0 convexe ≥′′⇒ αα hh ,

d’où , donc h est convexe. 0≥′′h

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 associées aux dissipations de puissance par la formule

ih

ig ( ) ( ) SSgSh ii = sont convexes et croissantes, il y a une solution optimale qui suppose une vitesse constante pour chaque évolution de la tâche Ti :

iiikij P

PkjSSS ≤≤≤== 1, .

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, iC , sont tous égaux à 6, et leurs fonctions de dissipation de puissance sont données par , et . ig 3

1 )( SSg = 32 8)( SSg = 3

3 27)( SSg =

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 1811 =S et , donc les temps d’exécution

92 =S3111 =C et 322 =C , 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 2412 =S et , donc les temps d’exécution

83 =S4112 =C et 433 =C .

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 T4=T1, T2, T3, T4 de 4 tâches périodiques, indépendantes, à échéance sur requête, ayant toutes la même périodicité P=1. Les coûts d’exécution pire cas iC et les coefficients pour les fonctions de dissipation de puissance sont présentées dans le Tableau III.1.

ia3)( SaSg ii =

Ti ai iC

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 : 182211 == SS , , 93 =S 241221 == SS et 84 =S , et donc les temps d’exécution sont : 312211 == CC , 323 =C , 412112 == CC et 434 =C .

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 totUSS ,max min= . 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, , 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

. D’autre part, la démonstration donnée suggère l’idée de prendre pour la valeur

totU

1max =S 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 ( ), alors la solution optimale est constante et donnée par

niggi ,,1K=∀= , totMIN SSS ,max= , et représente la vitesse d’exécution de chaque

tâche pour toute itération. est la vitesse qui pourrait assurer une charge du processeur égale à 1.

totS

Note : La formule qui exprime est obtenue comme suit : totS

∑=

==n

i i

itot P

tU

11

∑=

=⇔n

i i

SC

Ptot

i

11

70

Chapitre III Optimisation de la consommation d’énergie

∑=

=⇔n

i i

itot P

CS

1.

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 [ [ R→+∞0,g : , 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 [ [ R→+∞0,g : une fonction croissante, convexe et dérivable de deuxième ordre, pour laquelle la fonction [ [ R→+∞0,h : donnée par ( ) ( ) xxgxh = 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 : , d’où ( ) ( )xxhxg = ( ) ( ) ( )xxhxhxg '' += . Par la dérivabilité au deuxième ordre de g et h, on

obtient : )('')('2)('' xxhxhxg += .

La convexité de la fonction g implique ( ) 0" ≥xg pour tout [ [+∞∈ 0,x , donc

( ) ( ) ( ) ,00"00'20" ≥+= hhg et par la suite :

( ) .00' ≥h

La convexité de la fonction h donne ( ) 0" ≥xh pour tout [ [+∞∈ 0,x , et en conséquence la fonction est croissante. Comme 'h ( ) 00' ≥h , on déduit ( ) 0' ≥xh pour tout et donc la fonction h est croissante.

[ +∞∈ 0,x [

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 : 1≤U .

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 : , où et r

ii SaSg =)( 0>ia 2≥r .

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 sont exprimées par , où t ig r

ii SaSg =)( 0>ia e 2≥r , pour tout , alors il y a une solution optimale qui suppose une vitesse constante pour chaque évolution de la tâche T

ni ,,1K=

i , donnée par :

ri

n

j

rjj

i

Da

aCS 1

1

1

∑== .

73

Chapitre III Optimisation de la consommation d’énergie

Démonstration : Soit 1)()( −== ri

ii Sa

SSgSh . La convexité des fonctions (voir l’Exemple 2

ci-dessus) assure, pour une solution optimale, une vitesse constante pour l’exécution de chaque tâche.

ih

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 DCC =+ 21 , ce qui peut être écrit comme DSC

SC

=+2

2

1

1 .

Soit 02

1 >=SSx , d’où 21 xSS = . On obtient ⎟⎟

⎞⎜⎜⎝

⎛+=+= 2

1

22

2

2

1 1 Cx

CSS

CxSCD et

xCCDS 1

22 =− , donc 022

1 >−

=CDS

Cx .

L’énergie consommée s’exprime par :

)()( 222111 ShCShCE += 1

2221

111−− += rr SaCSaC

1222

1211 )( −− += rr SaCxSaC

⎥⎥⎦

⎢⎢⎣

⎡+⎟⎟

⎞⎜⎜⎝

−=

−22

1

22

111

12 aC

CDSCaCS

rr

( ) ⎥⎥⎦

⎢⎢⎣

⎡+

−= −

−221

22

11

12 aC

CDS

CaS r

rr .

Comme cette énergie est minimale, sa dérivée par rapport à est nulle. 2S

( ) ( )r

rr

r

r

ir

CDS

DCraSaCCDS

CaSrSE22

11

12221

22

1222

)1()1()('−

−−+

⎥⎥⎦

⎢⎢⎣

⎡+

−−= −

−−

( ) ( ) ⎥⎥⎦

⎢⎢⎣

−−+

−−= −

−r

r

r

r

ir

CDS

DCaSaCCDS

CaSr22

112221

22

122)1(

( ) ( )⎥⎥⎦

⎢⎢⎣

⎡−−

−+−= −

22222

1122

22)1( DSCDS

CDS

CaaCSr r

rr

( ) ⎥⎥⎦

⎢⎢⎣

−−−= −

r

rr

CDS

CaaCSr22

1122

22)1( .

En imposant et compte tenu que , on obtient : 0)(' 2 =SE 02 >S

74

Chapitre III Optimisation de la consommation d’énergie

( ) 022

112 =

−− r

r

CDS

Caa

r

CDSC

aa

⎟⎟⎠

⎞⎜⎜⎝

−=⇔

22

1

1

2 .

Parce que 022 >− CDS (car x>0), on arrive à la solution unique comme suit :

22

1

1

1

2

CDSC

aa r

−=⎟⎟

⎞⎜⎜⎝

r

aaCCDS

1

2

1122 ⎟⎟

⎞⎜⎜⎝

⎛=−⇔

r

rr

Da

aCaCS 1

2

1

22

1

112

+=⇔ .

En changeant les notations entre les deux tâches, on obtient également la valeur de , ainsi finissant le cas n=2 :

1S

r

rr

Da

aCaCS 1

1

1

22

1

111

+= .

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 :

ri

k

j

rjj

i

aD

aCS 1

1

1

'

∑== ,

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

commune des tâches. Par conséquent, la vitesse est donnée par 1+kStD

CS kk −

= ++

11 et,

conformément à l’hypothèse d’induction, les vitesses des k premières tâches sont données par la formule suivante :

ri

ri

k

j

rjj

i

ta

A

ta

aCS 11

1

1

==∑

= ,

75

Chapitre III Optimisation de la consommation d’énergie

où on a introduit la notation ∑=

=k

j

rjjaCA

1

1

.

L’énergie consommée pour les k+1 tâches peut être exprimée par :

∑+

=+ =

1

11 )(

k

iiiik ShCE

∑+

=

−=1

1

1k

i

riii SaC

11

111

111

1 −+

++

=−

⎟⎟⎠

⎞⎜⎜⎝

⎛−

+

⎟⎟⎠

⎞⎜⎜⎝

⎛= ∑

rk

kk

k

ir

ri

r

r

iitD

CaC

at

AaC

11

11

111

1

)( −

++

=

−−

−+= ∑ r

rk

k

k

i

rr

iir

r

tDCaaC

tA

)1(11

)1( )( −−++

−− −+= rrkk

rr tDCatA .

La valeur minimale pour la consommation d’énergie s’obtient pour une valeur de t pour laquelle . Un calcul direct donne : 0)(1 =′+ tEk

rrkk

rrk tDCartArtE −

++−

+ −−+−−=′ )()1()1()( 111

[ ]rrrrkkrr tDAtCa

tDtr )(

)(1

11 −−−

−= ++ ,

d’où est équivalent à : 0)(1 =′+ tEk

0)(11 =−−++rrrr

kk tDAtCa

r

rkk

r

ACa

ttD 11 ++=⎟

⎠⎞

⎜⎝⎛ −

⇔ .

Comme , il existe une solution unique à l’équation ci-dessus, obtenue par la suite : 0>− tD

A

Cat

tD krk

11

1+

+=−

ACtatD k

rk11

1+

+=−⇔ ,

qui revient à :

ACa

Dtk

rk11

11 +++

= ,

d’où :

∑+

=

= 1

1

1k

j

rjj aC

DAt .

76

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 :

DA

aC

a

AS

k

j

rjj

ri

i

∑+

=⋅=

1

1

1

1

ri

k

j

rjj

Da

aC

1

1

1

1

∑+

== ,

et aussi :

ACta

CSk

rk

kk

11

1

11

++

++ =

DA

aC

a

A

k

j

rjj

rk

∑+

=

+

⋅=

1

1

1

1

1

rk

k

j

rjj

Da

aC

1

1

1

1

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 iC , exprimé en cycles processeur, et sa fonction de dissipation de puissance , donnée par , où

t ig r

ii SaSg =)(0>ia e 2≥r , pour tout . ni ,,1K=

Alors, il existe un ordonnancement optimal pour Tn qui suppose une vitesse constante pour chaque évolution de la tâche Ti, donnée par :

ri

n

j

rj

j

j

i

a

aPC

S 1

1

1

∑== .

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 iPP tâches de T’, notées par Tij (pour j=1,…, iPP ) 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 :

ri

n

k

PP

l

rkk

ij

Pa

aCS

k

11 1

1

∑∑= ==

ri

n

k

rkk

k

Pa

aCPP

11

1

∑==

ri

n

k

rk

k

k

a

aPC

11

1

∑== .

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

i ii

in

i i

i

SPC

PC

11

∑∑=

=

⋅=n

ir

k

rkk

k

ri

i

i

aCP

P

PaPC

1

1

1

1

1

111

1

1

1 == ∑∑

=

=

n

i i

rii

r

k k

rkk

PaC

PaC

.

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, iC , sont tous égaux à 6, et leurs fonctions de dissipation de puissance sont données par : , et

. ig 3

1 )( SSg = 32 8)( SSg =

33 27)( SSg =

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 : , et 211 =S 5,102 =S 73 =S , d’où les temps d’exécution : 721 =C ,

78

Chapitre III Optimisation de la consommation d’énergie

742 =C et 763 =C . 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 . 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(n

rii SaSg =)(

2logn) 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 qui assure le fonctionnement du système et supérieurement par la valeur maximale 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.

MINS

MAXS

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 :

aoodo nCC ∗= 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 :

iC : 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 ;

iC : 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 est donnée par : iS

i

ii S

CC = ;

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ù iPPjni ,,1et ,,1 KK == .

Kij : le nombre de dispatchings (commutations de contexte) survenus pendant l’exécution de la tâche Tij. Pour tout iPPjni ,,1et ,,1 KK == on a :

1≥ijK .

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 iPPjni ,,1et ,,1 KK == , on obtient :

iijjKK ≤max .

Tijk : l’activation k de la tâche Tij ; pour tout iPPjni ,,1et ,,1 KK == .

ijkC : le nombre de cycles processeur pour l’activation k de la tâche Tij. La relation entre ijkC et iC est donnée par l’égalité :

∑=

=ijK

kiijk CC

1 ,

pour tout iPPjni ,,1pour tout et ,,1 KK == .

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 :

ijk

ijkijk S

CC = .

Par conséquent :

∑=

=ijK

k ijk

ijki S

CC

1

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.

MINS : la vitesse minimale du processeur qui assure le fonctionnement du système.

MAXS : la vitesse maximale que le processeur peut atteindre.

( )tLij : la laxité (§II.3.2.2) de la tâche dans sa jiT ème itération, au moment t, le

moment de son dispatching est exprimée par : ( )tkij

( )( )

∑=

−=tk

k ijk

ijkiij

ij

SC

DtL1

,

83

Chapitre III Optimisation de la consommation d’énergie

où représente le nombre d’activations de la tâche jusqu’au moment t ; donc :

.

( )tkij ijT

( ) ijij Ktk ≤≤1

( )Sgi : 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 :

- fonction convexe croissante stricte ; ( )Sgi

( ) ( ) SSgSh ii = - 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 [ ]21 ,tt correspondante à l’exécution de la tâche Ti pendant cette période est donnée par la formule :

( ) ( )( )∫=2

1

21 ,t

tii dt tSg ttE .

L’utilisation totale du (des) processeur(s) par l’ensemble de tâches Tn s’exprime par :

∑ ∑∑= ==

==n

ij

K

k kij

kij

i

n

i i

itot

i

iij

i

i

S

C

PPC

U1; 11

1 .

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 iC , exprimé en cycles processeur. Il existe un ordonnancement faisable de l’ensemble de tâche Tn si et seulement si

( ) MAXiini

SDC ≤= ,,1max

K,

où représente la vitesse maximale qui peut être prise par le processeur considéré pour l’estimation des coûts des tâches.

MAXS

Démonstration : « Nécessité » : Supposons l’existence d’un processeur pour lequel la vitesse maximale qu’il peut atteindre, , satisfait la condition MAXS ( ) MAXii

niSDC ≤

= ,,1max

K. Soit une

machine à n processeurs, ayant chaque processeur dédié à l’exécution d’une tâche. Comme pour toute tâche Ti l’inégalité MAXii SDC ≤ est vraie, on obtient : iMAXi DSC ≤ . Autrement dit, si le processeur dédié à la tâche Ti exécute celle-ci avec la vitesse , 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 .

MAXS

MAXS

« 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 ikC cycles processeur. Soit la vitesse maximale parmi les vitesses des processeurs qui correspondent à l’exécution de chaque partie de la tâche, . Si toutes les parties qui composent la tâche étaient exécutées avec cette vitesse, , alors l’exécution de

la tâche finirait plus tôt, avec une durée donnée par :

MAXiS

MAXMAXi SS ≤

MAXiS

iMAXiii DSC ≤=τ . On peut écrire

maintenant les inégalités suivantes :

MAXMAXi

i

i

i

i SSCDC

≤=≤τ

.

En conséquence, pour toute tâche Ti, l’inégalité MAXii SDC ≤ est vraie, d’où :

( ) MAXiini

SDC ≤= ,,1max

K.

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 iC , 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) ( ) MAXii

niSDC ≤

= ,,1max

K, où représente la vitesse maximale que le processeur

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 . La condition mentionnée assure le respect de toutes les échéances, d’où la faisabilité de cet ordonnancement.

MAXS

MAXS

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 , une des tâches pour laquelle au

moins une partie s’exécute sur le premier processeur, et soit une partie de la même tâche

qui s’exécute, à un moment donné, sur le processeur p,

niTi

≤≤ 11 ,1

jiT

1

mp ≤<1 . 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

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 la

durée d’exécution de selon l’ordonnancement considéré.

jiT

1

jiC

1

jiT

1

Cas I : Durant le processeur 1 exécute la partie de la tâche , qui

commence au même instant et qui prend la même durée. ji

C1 ki

T2

212 ,1 ,2

iiniTi

≠≤≤

La solution consiste à inverser l’emplacement d’exécution de ces deux parties de tâches, et , comme l’indique la figure ci-dessous. La situation est la même si

plusieurs parties de tâches s’exécutent sur le premier processeur strictement dans l’intervalle d’exécution de ou dans une partie inférieure à celle-ci, dans le reste le processeur tournant

à 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 qui s’exécutera sur le processeur 1.

jiT

1 jiT

2

jiT

2

jiT

1

Figure III.7. et parties des deux tâches différentes, synchrones, avec , ji

T1 ki

T2 kiji

CC21

=

exécutées par deux processeurs différents.

Cas II : Au moment d’activation de , ou/et au moment de fin d’exécution de ,

la partie de la tâche est en train de s’exécuter sur le processeur 1.

aji

t1 ji

T1

fji

t1 ji

T1

jiT

2212 ,1 ,

2iiniT

i≠≤≤

Alors, en coupant aux moments et , avec la partie qui s’exécute entre ces

deux bornes on peut faire le même raisonnement que dans le premier cas. Il faut remarquer que si, par exemple, la partie ne peut pas être coupée juste au moment suite au fait

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

jiT

2

aji

t1

fji

t1

jiT

2

aji

t1

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 d’autres tâches asynchrones par rapport à ji

C1 ji

T1

s’exécutent sur le premier processeur.

De cette manière, toutes les parties qui composent la tâche pourront être exécutées

par le premier processeur. Avec le même raisonnement, les autres processeurs pourront exécuter en intégralité une tâche chacun.

1iT

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 [ ]MAXMIN SS , , 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, , à laquelle s’ajoute la consommation minimale ( ) d’un processeur qui « tourne à vide » ( tâche de fond) :

mEe

eEE mm +≤+1 .

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, , à qui s’ajoute la consommation minimale ( e ) d’un processeur qui « tourne à vide » :

.

mE

eEE mm +≤+1

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 ni ,,1K= , iiMIN DCS ≤ . 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 :

et . ii DC < jj DC <

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 MINjj SDC ≥ , 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

ijiii CCCDC >+=′ ,min .

L’énergie consommée par ce nouvel ordonnancement est donnée par :

( ) ( ) ( ) ( )jmjmimimmm TETETETEEE 111 +++ +−+−= ,

où, par abus de notation, mais pour ne pas compliquer davantage les formules, ( )im TE et ( )jm TE représentent les énergies consommées par l’exécution de la tâche , respectivement iT

90

Chapitre III Optimisation de la consommation d’énergie

jT , dans l’ordonnancement sur m processeurs ; ainsi de même pour ( )im TE 1+ et ( )jm TE 1+ . On peut donc écrire :

⎟⎟

⎜⎜

⎛+

⎟⎟

⎜⎜

⎛−

⎟⎟

⎜⎜

′+

⎟⎟

⎜⎜

⎛−=+

j

jjj

j

jjj

i

iii

i

iiimm D

ChCCChC

CChC

CChCEE 1 ,

d’où, compte tenu de la croissance des fonctions et , et des inégalités mentionnées

auparavant ( et ), il est évident que : ih jh

ii CC >′ jj DC >

mm EE <+1 .

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 de ijkS

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 :

( ) ( ) ( ) ( )∑∑∑∑∑∑= = == ==

===n

i

PP

j

K

kijki

n

i

PP

jiji

n

ii

i iji

PEPEPEPE1 1 11 11

min minminmin ,

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, , pour l’exécution des ijkS ijkC 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 :

( ) ( ) ( ) ( ) ( ) ( )ijkiijkijkiijk

ijkijki

aijk

Pijki

aijkiijki ShCSg

SCSgPdtSgPEPE

aijk

===== ∫ ,

où ( ) ( ) SSgSh ii = . En conséquence, la condition d’optimisation de la consommation d’énergie peut être exprimée par :

( )∑∑∑= = =

n

i

PP

j

K

kijkiijk

i ij

ShC1 1 1

min .

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

• , la vitesse de la tâche à chaque activation, ijkS pour i=1,…,n, j=1,…, iPP et , sous les contraintes suivantes : ijKk ,...,1=

( )

⎪⎪⎪⎪

⎪⎪⎪⎪

≤≤≤≤<

=≤− ∑∑∑

∑∑∑

= = =

= = =

*)4(,,*)3(10

*)2(

*)1(min

*1 1 1

1 1 1

.determinés ainsi SKm avec faisable mentordonnance un existe IlKK ,SSS

SCP avec mPP

ShC

OPTPOW

ijkij

iijMAXijkMIN

ijk

ijkaijk

n

i

PP

j

K

k

aijk

n

i

PP

j

K

kijkiijk

i ij

i ij

92

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 , iC et gi , et que pour chaque i=1,…,n, l’inégalité

MAXi

iMIN S

DCS ≤≤

est satisfaite. Supposons également que les fonctions [ [ R→+∞0,hi : , associées à chaque fonction gi qui exprime la puissance dissipée, données par ( ) ( ) xxgxh ii = , 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

i i

ii D

CgPPE1

min .

Démonstration : Parce que pour chaque i=1,…,n, l’inégalité MAXii SDC ≤ 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 ii DC , 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

( ) ( )∑∑= =

=n

i

PP

jii

i

PEPE1 1

min

( )∑=

=n

iii

i

PEP

P1

1

∑ ∫= ⎟

⎜⎜

⎛=

n

i P i

ii

i i

dtDCg

PP

1

1

∑= ⎟

⎜⎜

⎛=

n

i i

ii D

CgP1

.

Note : Dans ce théorème il est important de remarquer le fait que : iiMIN DCS ≤ 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 suffisamment petit. MINS

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 [ [ R→+∞,0:g une fonction croissante et convexe et soit [ [ R→+∞,0:h la fonction donnée par ( ) ( ) xxgxh = . Alors, pour tout a, b, P>0 et ] abz −∈ ,0 [, l’inégalité suivante est vraie:

⎟⎠⎞

⎜⎝⎛ −

−+⎟⎠⎞

⎜⎝⎛ +

+>⎟⎠⎞

⎜⎝⎛+⎟

⎠⎞

⎜⎝⎛

Pzbhzb

Pzahza

Pbbh

Paah )()( .

Démonstration : g étant une fonction convexe et croissante, la fonction [ [ R→+∞,0:f

donnée par ( ) ⎟⎠⎞

⎜⎝⎛=⎟

⎠⎞

⎜⎝⎛=

PxPg

Pxxhxf est aussi convexe et croissante.

Figure III.11. Une inégalité pour les fonctions croissantes et convexes.

95

Chapitre III Optimisation de la consommation d’énergie

On a 2

)()(2

zbzaba −++=

+ . Il est évident sur la Figure III.11 que :

2)()(

2)()(

21bfafMMzbfzaf +

=<=−++ ,

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 mππ ,,1 K , m<n, tel que l’exécution de chaque tâche soit assignée à un seul processeur.

kiT π∈ 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π ,

∑∈

=ΓkiT

i

ik C

PP

π

représente le nombre de cycles processeur exécutés par le

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 mππ ,,1 K , 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 P

S iMIN

Γ<

pour tout , alors : mi ,,1K=

lmlkk

Γ≤Γ=≥ ,,12min2maxKπ

.

Démonstration : On procède par réduction à l’absurde. Supposons que l’inégalité à prouver soit fausse, donc :

mΓ>Γ 21 (1).

Avec un possible changement de numérotation des processeurs, on peut considérer k

k

Γ=Γ≥2

1 maxπ

et . lmlm Γ=Γ

= ,,1minK

Il est évident que sur le premier processeur il y a au moins une tâche, disons 11 π∈T , dont le nombre de cycles processeur correspondant à la période d’étude satisfait :

111 2

1Γ≤C

PP (2).

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π à 1−mπ 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 :

111 2

1Γ≤+Γ=Γ′ C

PP

mm (3).

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

Ω

PS i

MINΓ

< pour tout , la vitesse

d’exécution des tâches par le processeur dans l’ordonnancement

mi ,,1K=

iπ Ω est donnée par :

PS i

= , pour tout mi ,,1K= . (4)

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 P

S mm

Γ′=′ .

Faisons une comparaison des énergies consommées, ( )ΩE et , par les deux ordonnancements et Ω , pour la même période P d’étude :

( )Ω′EΩ ′

( ) ( ) =Ω′−Ω EE ( ) ( ) ( ) ( )mmmm ShShShSh ′Γ′+′Γ′−Γ+Γ 1111

( ) ( )⎟⎟⎟⎟

⎜⎜⎜⎜

⎛ +Γ

⎟⎟⎠

⎞⎜⎜⎝

⎛+Γ−

⎟⎟⎟⎟

⎜⎜⎜⎜

⎛ −Γ

⎟⎟⎠

⎞⎜⎜⎝

⎛−Γ−Γ+Γ=

P

CPP

hCPP

P

CPP

hCPPShSh

m

mmm

11

11

11

1

11

111 . (5)

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

1111

1121

Γ<Γ′=−Γ≤Γ<Γ CPP

m

et

111111

1 21

21

21

Γ=Γ+Γ<Γ+Γ≤+Γ=Γ′<Γ mmm CPP ,

ce qui nous permet d’appliquer le Lemme III.3 à la relation (5) et d’obtenir :

( ) ( ) 0>Ω′−Ω EE .

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 :

lmlkk

Γ≤Γ=≥ ,,12min2maxKπ

.

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 : ( ) *R , N, , +∈≥∈= arraSSg r 2 .

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 donnée par ,]2,1[: R→f

( )( )r

r

x

xxf

+

+=

1

1 est croissante en x.

Démonstration : En calculant la dérivée au premier ordre f’ de la fonction f, on obtient :

( ) ( ) ( ) ( ) ( )[ ]( ) r

rrrr

x

x xxxxf 21

1111'

+

′++−+

′+

=

( ) ( ) ( )( ) r

rrrr

x

x r xxrx2

11

1

111

+

++−+=

−−

( )( )[ ]rr

r xxxxr

−−++

= −+ 11

11

1

( )( ) 01

11

1 ≥−+

= −+

rr x

xr

pour tout et pour tout r nombre entier, r>1, ce qui donne le résultat souhaité. ]2,1[∈x

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 ( ) *R , N, , +∈≥∈= arraSSg r 2 . 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 2≥kπ , k=1,2. Si E2 est la consommation pour ce dernier ordonnancement alors :

1211 321

21 EEE r

r

r

+≤≤− .

Démonstration : Soit ∑∈

=ΓkiT

i

ik C

PP

π

le nombre de cycles processeur exécutés par le

processeur kπ dans un ordonnancement à deux processeurs comme dans l’énoncé, k=1,2. On

a donc ∑∈

=Γ+Γn

i TTiC21 .

Par la Proposition III.1’, l’énergie d’un ordonnancement optimal monoprocesseur est donné par :

( ) ⎟⎠⎞

⎜⎝⎛ Γ+Γ

Γ+Γ=P

h E 21211

99

Chapitre III Optimisation de la consommation d’énergie

( )1

2121

⎟⎠⎞

⎜⎝⎛ Γ+Γ

Γ+Γ=r

P a .

De même : ⎟⎠⎞

⎜⎝⎛ Γ

Γ+⎟⎠⎞

⎜⎝⎛ Γ

Γ=P

hP

hE 22

112

12

2

11

1

−−

⎟⎠⎞

⎜⎝⎛ Γ

Γ+⎟⎠⎞

⎜⎝⎛ Γ

Γ=rr

Pa

Pa .

Pour une comparaison des énergies consommées dans les deux cas, en faisant leur rapport, on obtient :

( )1

2121

12

2

11

1

1

2−

−−

⎟⎠⎞

⎜⎝⎛ Γ+Γ

Γ+Γ

⎟⎠⎞

⎜⎝⎛ Γ

Γ+⎟⎠⎞

⎜⎝⎛ Γ

Γ= r

rr

P a

Pa

Pa

EE

( )r

rr

21

21

Γ+ΓΓ+Γ

=

r

r

⎟⎟⎠

⎞⎜⎜⎝

⎛+

ΓΓ

+⎟⎟⎠

⎞⎜⎜⎝

⎛ΓΓ

=

1

1

2

1

2

1

.

Supposons que 21 Γ≥Γ (le cas 21 Γ≤Γ peut être réduit à celui-ci par un changement de notation). Le Théorème III.10 fournit 21 2Γ≤Γ . Avec le changement de notation : 21 ΓΓ=x , ces conditions reviennent à , et le rapport des énergies devient : ]2,1[∈x

( )r

r

xx

EE

++

=11

1

2 .

En appliquant le Lemme III.4 sur l’intervalle [ ]2,1 , on obtient ce qu’on a cherché à prouver :

1211 321

21 EEE r

r

r

+≤≤− .

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 , la fonction ]2,1[∈x [ [ R→+∞,2:h donnée par ( )( )

,1

1r

r

x

xrf

+

+=

est décroissante en r.

Démonstration : Soit f’ la dérivée au premier ordre de la fonction f. Alors :

100

Chapitre III Optimisation de la consommation d’énergie

( ) ( ) ( ) ( ) ( )[ ]( ) r

rrrr

x

x xxxrf 21

1111'

+

′++−+

′+

=

( ) ( )( )( ) r

rrrr

xxx xx xx

21)1ln(111ln

++++−+

=

( )( )r

rr

xxxxx

+++−

=1

)1ln(1ln

[ ]( )

01

)1ln()1ln(ln<

++−+−

= r

r

xxxxx

pour tout et pour tout r>1, d’où la décroissance de f par rapport à r. ]2,1[∈x

r Estimation du gain énergétique

2 556,095

215,0

1

2 ≅≤≤=EE

3 334,031

4125,0

1

2 ≅≤≤=EE

4 21,08117

81125,0

1

2 ≅≤≤=EE

5 046,072933

1610625,0

1

2 ≅≤≤=EE

Tableau III.2. Gain d’énergie au passage de 1 à 2 processeurs.

Note : Si l’hypothèse 2≥kπ , 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 11 =π , 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 , a>0. Supposons que leurs

coûts d’exécution pire cas

3)( aSSg =

iC vérifient la relation ∑=

=4

21 4

iiCC . La Figure III.12 illustre ce

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 : 12 2513 EE = , une estimation donc

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 2≥kπ , k=1,2.

Théorème III.12 : Soit Tn=T1, T2, …, Tn, , 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

4≥n

( ) *r a r r aSSg +∈≥∈= RN ,2,, . 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 :

112 556,03

21 EEE r

r

≤+

≤ .

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

vraie : 12 321 EE r

r+≤ . Compte tenu du résultat fourni par le Lemme III.5 (voir aussi le

Tableau III.2), on obtient 11 556,03

21 EEr

r

≤+ .

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

i i

itot P

nCPCU

11 .

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

totMIN SSS ,max= .

Pour l’étude théorique on considère que et que toute vitesse S trouvée pour les processeurs assure la fonctionnalité du système : .

MINtot SS >

MINSS ≥

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 :

( ) ( ) ( )SPgdtSgnSEEnP

n

iin === ∫∑

= 01,1 ,

où , la puissance dissipée, est donnée par : ( )Sg

( ) ∑=

=∀∈≥∈=r

ii

ii ri a r r SaSg

1,,1,,2,, KRN .

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

ii

ii ri a r r SaSg

1,,1,,2,, KRN .

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 :

( ) ( ) i

r

iii

ii

nm San

k qmk qPE ∑

=

−++=

1,

1,

où et , représente

la puissance dissipée pour leur exécution.

1,,0, −∈+= mqqmkn K ( ) ∑=

=∀∈≥∈=r

ii

ii ri a r r SaSg

1,,1,,2,, KRN

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 Snk 1+

m-q k Snk

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 :

( ) ⎟⎠⎞

⎜⎝⎛−+⎟

⎠⎞

⎜⎝⎛ +

= + SnkEqmS

nkqEE kknm ,11,1,

1

( ) ⎟⎠⎞

⎜⎝⎛−+⎟

⎠⎞

⎜⎝⎛ +

= SnkPgqmS

nkqPg 1

( ) ( ) ∑∑

==

−++

=r

i

ii

i

i

r

i

ii

i

i Snk

aPqmSn

kaqP

11

1

( ) ( )∑=

−++=

r

i

iii

ii

San

kqmkqP1

1 .

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 : ( ) r r aSSg r ,2,, ≥∈= N

, la consommation optimale d’énergie pour exécuter les n tâches identiques et indépendantes sur m processeurs, , exprimée par rapport à l’énergie optimale consommée pour leur exécution sur une machine monoprocesseur, , est donnée par la relation :

*a +∈ RnmE ,

nE ,1

( ) ( )[ ] nrr

rnm Ekqmkqn

E ,1, 11−++= .

Démonstration : À partir du Théorème III.13, particularisé pour ( ) r r aSSg r ,2,, ≥∈= N

, on obtient : *a +∈ R( ) ( ) r

r

rr

nm San

kqmkqPE

−++=

1,

( ) ( ) ( )SPgn

kqmkqr

rr −++=

1

( ) ( )[ ] nrr

r Ekqmkqn ,111

−++= .

Corollaire III.5 : Soit , la forme de la puissance dissipée, et soit , 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.

( ) *r a r r aSSg +∈≥∈= RN ,2,,*, Ν∈= kmkn

Démonstration : Comme , on obtient : *, Ν∈= kmkn

• à partir du Corollaire III.4 : nrnm Em

E ,11,1

−= , et

• à partir du Tableau III.3 : SmS 1= ,

où totMIN SSS ,max= 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 dépasse la vitesse optimale de l’exécution de n tâches

sur m processeurs, MINS

SmSm 1= , pour . nm<<

105

Chapitre III Optimisation de la consommation d’énergie

0

0,2

0,4

0,6

0,8

1

1,2

1 2 3 4 5 6 7 8

m

Em

,n/E

1,n

r=2

r=3

0

0,2

0,4

0,6

0,8

1

1,2

1 2 3 4 5 6 7 8

m

Sm

/S1

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 . ( ) *r a r r aSSg +∈≥∈= RN ,2,,

Cas I : kn 2=

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

, le gain théorique d’énergie au passage de 1 à 2 processeurs est au minimum 50%.

( ) ,, N∈= r aSSg r

*a r +∈≥ R,2

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 2SS= (conformément au Théorème III.13).

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 Optimisation de la consommation d’énergie

( ) ( )[ ] nrr

rnm E k qmk qn

E ,1, 11−++= , on obtient :

( ) .2

122

21,11,1,1,2 nrnrr

r

nr

rn EEkk

Ekn

E −===α

Par conséquent, nn EE ,1,2 21β

≤ pour 2≥∀r , et a une décroissance logarithmique par

rapport à , relatif à l’argument r, le degré de la fonction polynomiale qui indique la consommation d’une tâche.

nE ,2

nE ,1

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 : 12 += kn

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 Sk

k12 + , et les autres k+1

tâches sont exécutées avec la vitesse Skk

12 + (conformément au Théorème III.13).

Figure III.15. Le passage de 1 à 2 processeurs pour n=2k +1 tâches identiques.

En appliquant les valeurs m=2 et q=0 dans la formule ( ) ( )[ ] nrr

rnm EkqmkqnE ,1, 11 −++=

(donnée par le Corollaire III.4), on obtient :

( )[ ] ( )( ) nr

rr

nrr

rn Ek

kkEkknE ,1,1,2 12

111

+

++=++= .

Lemme III.6 : Pour tout k, nombre entier positif, la fonction , donnée par RΝ →:f

( ) ( )( )r

rr

k

kkrf

12

1

+

++= , 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

( )( )

( )( ) 1

11

12

1

12

1+

++

+

++>

+

++r

rr

r

rr

k

kk

k

kk

( ) ( )[ ] ( ) 11 1112 ++ ++>+++⇔ rrrr kkkkk

( ) ( )( ) ( )( )rrrr kkkkkkkk 1111212 +++>++++⇔

( ) ( ) 011 >+++⇔ rr kkkk ,

ce qui est évident pour tout k et r nombres entiers positifs.

Lemme III.7 : Pour tout r, nombre entier, r>1, la fonction , donnée par RΝ →:f

( ) ( )( ) ,

121r

rr

kkk

kf+

++= est décroissante en k.

Démonstration : Soient : r un nombre entier, r>1, la fonction décrite par : RR →+:g

( ) ( )( )r

rr

xxx

xg121

+

++= , et ( )xg' la dérivée de premier ordre de la fonction g. On a :

( ) ( )[ ] ( ) ( )[ ] ( )[ ]( ) r

rrrrrr

x

x xxxxxxg 212

121121'

+

′+++−+

′++

=

( )[ ]( ) ( )[ ] ( )( ) r

rrrrrr

x

x r xxx xrrx2

111

12

1221121

+

+++−+++=

−−−

( )( ) ( ) ( ) ( )[ ]rrrr

r xxxxxxx

r 1221211212

111 +−−++++

+= −−

+

( )( ) ( ) ([ ]22121212

1211

1 −−+++−++

= −−+ xxxxxx

xr rr

r )

( )( )[ ] 01

1211

1 xx x

r rrr <+−

+= −−

+

pour tout x nombre réel positif et pour tout r nombre entier, r>1.

Par conséquent, la fonction définie par RR →+:g ( ) ( )( )

,12

1r

rr

x

xxxg

+

++= est

décroissante, donc la fonction , définie par RΝ →:f ( ) ( )( )

,12

1r

rr

kkk

kf+

++= est une fonction

décroissante.

108

Chapitre III Optimisation de la consommation d’énergie

Corollaire III.6 : Pour tout k et r nombres entiers, avec et 1≥k 2≥r , l’inégalité suivante est valable:

( )( )

556.095

12

1≅≤

+

++r

rr

k

kk

Démonstration : ( )

( )( )

( ) 95

321

12

1

12

12

227 Lemme

2

226 Lemme=

+≤

+

++≤

+

++

k

kk

k

kkr

rr

.

Théorème III.15 : Soit un ensemble de tâches identiques, indépendantes, prêtes à s’exécuter au même moment, et , 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.

( ) *r a r r aSSg +∈≥∈= RN ,2,,

Démonstration : ( )

( ) nnnr

rr

n EEEk

kkE ,1,1

6Cor

,1

5Cor

,2 556.095

12

1≅≤

+

++= .

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

⎭⎬⎫

⎩⎨⎧

==PCnSSS totMIN ,max ;

3. Calcul de la consommation optimale d’énergie pour m processeurs : pour m=1 à n :

déterminer : les nombres entiers k et q : 1,,0, −∈+= mqqmkn K ;

déterminer : Snk 1+ et Sn

k ;

si minSSnk

≥ alors

q CPUs exécutent, chacun, k+1 tâches avec la vitesse SnkS qm

1,

+= ;

m-q CPUs exécutent, chacun, k tâches avec la vitesse SnkS qmm =−, ;

la consommation d’énergie : ( ) ( )

∑=

−++=

r

i

iii

ii

nm San

kqmkqPE

1,

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 :

( ) ( )[ nrr

rnm Ekqmkqn

E ,1, 11−++= ] , donnée par le Corollaire III.4 pour une puissance

dissipée ayant la forme : . ( ) *r a r r aSSg +∈≥∈= RN ,2,,

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 puissance

consommée n = nombre de tâches

m = nombre de processeurs n

nm

EE

,1

, S

S qmm −,

2 10 1 1 1 2 10 2 0,5 0,5 2 10 3 0,34 0,3 2 10 4 0,26 0,2 2 10 5 0,2 0,2 2 10 6 0,18 0,1 2 10 7 0,16 0,1 2 10 8 0,14 0,1 2 10 9 0,12 0,1 2 10 10 0,1 0,1 3 10 1 1 1 3 10 2 0,25 0,5 3 10 3 0,118 0,3 3 10 4 0,07 0,2 3 10 5 0,04 0,2 3 10 6 0,034 0,1 3 10 7 0,028 0,1 3 10 8 0,022 0,1

110

Chapitre III Optimisation de la consommation d’énergie

3 10 9 0,016 0,1 3 10 10 0,01 0,1 2 100 1 1 1 2 100 2 0,5 0,5 2 100 3 0,3334 0,33 2 100 4 0,25 0,25 2 100 5 0,2 0,2 2 100 6 0,1668 0,16 2 100 7 0,143 0,14 2 100 8 0,1252 0,12 2 100 9 0,1112 0,11 2 100 10 0,1 0,1 3 100 1 1 1 3 100 2 0,25 0,5 3 100 3 0,111178 0,33 3 100 4 0,0625 0,25 3 100 5 0,04 0,2 3 100 6 0,027844 0,16 3 100 7 0,02047 0,14 3 100 8 0,0157 0,12 3 100 9 0,012376 0,11 3 100 10 0,01 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

⎭⎬⎫

⎩⎨⎧

==PCnSSS totMIN ,max . Pour passer à deux processeurs il faut au moins que :

totMIN SSS =≤2 .

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 : ( ) *r a r r aSSg +∈≥∈= RN ,2,, , le gain d’énergie au passage de 1 à m processeurs ne dépend pas du nombre de tâches.

Démonstration : Pour *, Ν∈= kmkn , conformément au Corollaire III.4, on obtient :

nrnm EmE ,11,1

−= .

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 plates-formes 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 : ( ) 2 ,R , , * ≥∈= + rraSaSg i

rii (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 plates-formes, 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 plate-forme, 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 qui assure le fonctionnement du système, et supérieurement par la valeur maximale 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).

MINS

MAXS

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 plates-formes 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 Multi-Processor (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 variable en ligne, en fonction de la tâche, les vitesses étant connues a priori.

UP adapté pour prendre en compte la variation de la vitesse du processeur.

Proposition III.1’, Corollaire III.5, Théorème III.14,

Monoprocesseur, à vitesse constante à tout moment.

UP

120

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 sur la vitesse.

UP adapté pour prendre en 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.

SMP adapté pour permettre aux processeurs d’avoir des vitesses différentes, mais constantes pour chaque processeur et connues a priori.

Proposition III.2 Multiprocesseur, à vitesse variable en fonction du processeur et de la tâche.

Migration des tâches interdite.

Synchronisation entre les processeurs au début de l’exécution de chaque tâche.

MUP adapté pour prendre en compte la variation de la vitesse de chaque processeur.

La 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, à vitesse variable en fonction du processeur et de la tâche.

SMP adapté pour prendre en compte la variation de la vitesse de chaque processeur.

Théorème III.10, Théorème III.11, Théorème III.12.

Multiprocesseur, à vitesse variable en fonction du processeur et de la tâche.

Migration interdite pour certaines tâches.

SMP adapté pour prendre en compte la variation de la vitesse de chaque processeur.

Assignations de certaines tâches aux processeurs.

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 (

RT_TASK *task, // tâche 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 lui-mê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. Field-Programmable 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

ARM à partir de v6,

RealView Developper Suite

Carte mère Integrator/AP

RedHat Linux [ARM 03]

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.

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.

Migration des tâches interdite.

Synchronisation entre les processeurs au début de l’exécution de chaque tâche.

ARM à partir de v6

RealView Developper Suite

Carte mère Integrator/AP

RedHat Linux [ARM 03]

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.

Migration interdite pour certaines tâches.

ARM à partir de v6

RealView Developper Suite

Carte mère Integrator/AP

RedHat Linux [ARM 03]

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 lui-mê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é quelques-unes 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 : , avec et ( ) r

ii SaSg = R , *+∈rai 2≥r . 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 (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é.

12 556,0 EE ≤

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 Etude de cas

A1.3.2. 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 à pixel-reconstruit, 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 sens-la, 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 ReN 2= et le nombre de connecteurs lui correspondant est 12 −+= GNc R . La recherche d’une relation pour échapper à la complexité de la matrice de connexion induit une nouvelle contrainte: la différence entre deux vecteurs, et , correspondant à des cellules excitées de la mémoire virtuelle pour deux entrées consécutives (ex. et

m m′( yx, ) ( )yx ,1+ or ( )1, +yx ), est donnée par un seul élément

du vecteur. Donc la matrice généralisée de dimension 43421 KN

GGG ××× pour variables d’entrée,

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]

nous donne le nombre de cellules de mémoire virtuelle,

N

mN ⎥⎦⎥

⎢⎣⎢ −+

GNC= GNNm

1 . Les valeurs

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é MAXSDC ≤ 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 DCSMIN ≤ et la fonction

( ) ( ) SSgSh = 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 ( )DCDg4 , les quatre processeurs exécutant chacun une tâche avec la vitesse

DC .

La condition de convexité de la fonction ( ) ( ) SSgSh = 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 DCSMIN ≤ n’est pas vérifiée, alors la vitesse d’exécution des tâches sur la plate-forme à 4 processeurs est et l’énergie consommée . 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 à 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.

MINS ( MINSDg4 )

MAXS

Nombre de

processeurs Restrictions Vitesses Energie consommée

MINSDC ≤/4 MINS ∑=

r

i

iMINi

MIN

SaSC

14

1

MAXMIN SDCS ≤< /4 DC /4 ∑=

r

ii

ii

i DCaD

1

4

MINSDC ≤/2 MINS ∑=

r

i

iMINi

MIN

SaSC

14

2

MAXMIN SDCS ≤< /2 DC /2 ∑=

r

ii

ii

i DCaD

1

22

3 MINSDC ≤/2 MINS ∑=

r

i

iMINi

MIN

SaSC

14

149

ANNEXE 1 Etude de cas

DCSDC MIN /2/ ≤≤

2CPU – 1 tâche – MINS

1CPU – 2 tâches – DC /2

∑∑==

+r

ii

ii

i

r

i

iMINi

MIN DCaDSa

SC

11

22

DCSMIN /<

2CPU – 1 tâche – DC /

1CPU – 2 tâches – DC /2

∑∑==

+r

ii

ii

i

r

ii

i

i DCaD

DCaD

11

22

MINSDC ≤/ MINS ∑=

r

i

iMINi

MIN

SaSC

14

4

MAXMIN SDCS ≤< / DC / ∑=

r

ii

i

i DCaD

14

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 Interface mémoire Puissance Core DDR-266 DDR-200 SDR-133 SDR-100

SKU MHz V Température maximale MHz MHz MHz MHz TDP

933 1,3 133 – 133 – 9,0 W 800 1,2 133 – 133 – 6,8 W 667 1,1 133 – 133 – 5,1 W 533 1,0 133 – 133 – 3,7 W 400 0,9 133 – 133 – 2,6 W

TM58EX-933 (mémoire à 133 MHz)

300 0,8

100°C

100 – 100 – 1,7 W 900 1,30 – 100 – 100 8,8 W 800 1,20 – 100 – 100 6,8 W 700 1,15 – 100 – 100 5,6 W 600 1,05 – 100 – 100 4,3 W 500 0,975 – 100 – 100 3,3 W 400 0,90 – 100 – 100 2,6 W

TM58EX-933 (mémoire à 100 MHz)

300 0,80

100°C

– 100 – 100 1,7 W 800 1,20 133 – 133 – 6,8 W 667 1,10 133 – 133 – 5,1 W 533 1,00 133 – 133 – 3,7 W 433 0,925 108 – 108 – 2,9 W

TM58EL-800 (mémoire à 133 MHz)

300 0,80

100°C

100 – 100 – 1,7 W 800 1,20 – 100 – 100 6,8 W 700 1,15 – 100 – 100 5,6 W 600 1,05 – 100 – 100 4,3 W 500 0,975 – 100 – 100 3,3 W 400 0,90 – 100 – 100 2,6 W

TM58EL-800 (mémoire à 100 MHz)

300 0,80

100°C

– 100 – 100 1,7 W 667 1,10 133 – 133 – 5,1 W 533 1,00 133 – 133 – 3,7 W 433 0,925 108 – 108 – 2,9 W

TM55EL-667 (mémoire à 133 MHz)

300 0,80

100°C

100 – 100 – 1,7 W 600 1,05 – 100 – 100 4,3 W 500 0,975 – 100 – 100 3,3 W 400 0,90 – 100 – 100 2,6 W

TM55EL-667 (mémoire à 100 MHz)

300 0,80

100°C

– 100 – 100 1,7 W

Tableau A2. Caractéristiques des modèles Crusoe SE TM 55E/TM58E [CRU 03].

151

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. 498-523, 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 temps réel et 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 Hard-Real-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 Real-Time 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

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 Real-Time 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, Addison-Wesley, 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 Real-Time 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 pour VRTX, 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

,

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 ; RTAI-Linux 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