Pagination en contexte temps-réel embarqué - IRISA · 2009. 10. 20. · Les systèmes temps-réel...

I R I S A

Master 2 Recherche Informatique

Pagination en contexte temps-réelembarqué

Damien HARDY

Rapport de stage de Master e�ectué sous la direction de :

Mme Isabelle PUAUT

Au laboratoire IRISA projet CAPS

Campus de Beaulieu - Rennes

Juin 2007

On a toujours assez de temps quand onl'emploie bien.

Johann Wolfgang von Goethe

2

Remerciements

Je pro�te de ce mémoire pour remercier l'ensemble de l'équipe CAPS pour son accueilet sa convivialité avec une pensée respectueuse pour André SEZNEC responsable de cetteéquipe.

Je tiens aussi particulièrement à remercier Isabelle PUAUT pour son encadrement.Ses conseils avisés m'ont été très béné�ques tant sur la démarche scienti�que que sur lestechniques de rédaction. Je salue sa disponibilité ainsi que sa volonté de me transmettreune certaine vision de la recherche.

Je ne peux oublier Erwan ABGRALL en souvenir des moments passés à la ré�exioninitiale sur ce projet.

Merci également à Jean-François DEVERGE pour les discussions intéressantes que nousavons eues et pour le regard objectif qu'il a su porter sur mes travaux. Mais aussi à KarineBRIFAULT et Christophe PAÏS pour leurs conseils et leur aide qui m'ont été d'un grandsecours et sans oublier tous les relecteurs pour leurs remarques constructives contribuantà l'élaboration de ce présent mémoire.

3

Table des matières

Remerciements 3

Introduction 5

1 Méthodes d'estimation de pire temps d'exécution (WCET) 71.1 Méthodes dynamiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Méthodes statiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3 Considérations au niveau du code . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Calcul de WCET et hiérarchie mémoire 122.1 Calcul de WCET et mémoires caches . . . . . . . . . . . . . . . . . . . . . . 122.2 Calcul de WCET et mémoire virtuelle . . . . . . . . . . . . . . . . . . . . . 20

3 Pagination statique orientée temps-réel 233.1 Vue d'ensemble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2 Pagination des pages de code . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3 Pagination des pages de données . . . . . . . . . . . . . . . . . . . . . . . . 36

4 Expérimentations 474.1 Protocole expérimental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5 Implémentation et perspectives 575.1 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Conclusion 60

Références 64

4

Introduction

Les systèmes temps-réel embarqués sont de plus en plus utilisés dans de nombreuxdomaines comme l'avionique, les centrales nucléaires ou encore l'automobile. De tels sys-tèmes doivent respecter des contraintes temporelles lors de leur exécution. Ce respect estplus ou moins important suivant que l'on se place dans le cadre du temps réel souple oustrict. Pour les systèmes souples, les contraintes sont dé�nies pour assurer une qualité deservice et le non-respect occasionnel n'entraîne pas de problèmes importants. Par contre,le respect des contraintes de temps est impératif dans les systèmes stricts pour en assurerle bon fonctionnement.

La validation quantitative des systèmes temps-réel, vis-à-vis des contraintes tempo-relles, se doit de garantir la terminaison au plus tard à l'échéance de chaque tâche com-posant le système en se basant sur la faisabilité de l'ordonnancement. Cette validationrepose sur le pire temps d'exécution (Worst Case Execution Time (WCET)) de chacunedes tâches, celui-ci représentant une borne supérieure de tous les temps d'exécution pos-sibles. Cependant, le pire temps d'exécution d'une tâche est de façon générale inconnu. Dece fait, nous cherchons à estimer une borne supérieure du WCET la plus précise possible.

Les systèmes temps-réel sont également contraints en performance et pour cela, ilsdisposent notamment d'une hiérarchie mémoire. L'intérêt principal de cette hiérarchie mé-moire est d'o�rir à l'utilisateur le plus grand espace mémoire disponible tout en gardantun temps d'accès le plus rapide possible en se basant sur les principes de localité spatialeet temporelle. Pour ce faire, elle dispose de di�érents types de mémoires tels que les caches,la mémoire centrale et les disques ayant chacun des capacités de stockage et des tempsd'accès di�érents.

Dans les systèmes généralistes, la gestion de cette hiérarchie mémoire est d'une parttransparente pour le programmeur et d'autre part gérée dynamiquement a�n d'améliorer letemps moyen d'exécution. Cependant, cette gestion dynamique amène de l'indéterminismesur les temps d'accès mémoire. En e�et, sur deux exécutions di�érentes, le contenu dechacun des composants de la hiérarchie mémoire est potentiellement di�érent. Ainsi, prévoirle temps d'accès à une donnée dans la hiérarchie mémoire est di�cile car il est fonctionde son emplacement lors de l'exécution. Dans les systèmes temps-réel, cette dynamicité setrouve donc être une source de di�cultés pour le calcul d'une borne supérieure précise dupire temps d'exécution. Cette di�culté est à l'origine de nombreux travaux de recherche.

Au niveau de la mémoire virtuelle, son usage introduit de l'indéterminisme di�cilementanalysable, ce qui restreint son utilisation voir l'écarte totalement dans les systèmes temps-réel actuels. Pourtant, plusieurs facteurs mettent en évidence l'intérêt d'un mécanisme depagination adapté au temps-réel. D'une part, les systèmes temps-réel actuels disposent deplus en plus souvent du matériel nécessaire pour faciliter ce mécanisme et d'autre part,le volume des applications embarquées temps-réel a tendance à augmenter. Or, l'ajout demémoire physique supplémentaire représente un coût non négligeable dans la conceptiondes systèmes.

5

TABLE DES MATIÈRES 6

En partant de cette constatation, nous rentrerons dans la problématique du stage consis-tant à élaborer un mécanisme de pagination adapté aux systèmes temps-réel souples etstricts : en d'autres termes, un système de pagination o�rant l'isolation spatiale et unmécanisme de va-et-vient mémoire-disque le tout en étant déterministe a�n de rendre pré-visible le contenu de la mémoire pour estimer précisément les temps liés aux opérationsde pagination et ainsi les intégrer dans le calcul d'une borne supérieure du WCET. Nouschercherons également à suivre une heuristique orientée pire temps a�n de minimiser cetteborne.

La suite de ce document est organisée de la manière suivante. Nous commencerons parfaire un état de l'art dans les chapitres 1 et 2. Le chapitre 1 introduira quelques notionsimportantes ainsi que des méthodes d'estimation du pire temps d'exécution et le chapitre2 présentera, au travers d'un parcours de la hiérarchie mémoire, les principes courammentutilisés pour intégrer les di�érents éléments matériels de cette hiérarchie dans le calculdu WCET. Ensuite, nous présenterons deux approches l'une revenant à un problème decoloration de graphe et l'autre utilisant la programmation linéaire en nombres entiers pourdéterminer statiquement le contenu de la mémoire physique tout en essayant de minimiserle nombre d'opérations de pagination sur le pire chemin d'exécution au chapitre 3. Lechapitre 4 sera consacré à l'expérimentation de nos approches et nous les compareronsavec des mécanismes de pagination dynamique. Finalement, nous verrons une approchepossible d'implémentation dans un système réel ainsi que des perspectives à ces méthodesau chapitre 5.

6

Chapitre 1

Méthodes d'estimation de pire tempsd'exécution (WCET)

Le pire temps d'exécution d'une tâche est une borne supérieure de tous les tempsd'exécution possibles de celle-ci. L'estimation de cette borne est calculée en nombre decycles. A�n d'être correcte et la plus exploitable possible elle doit être sûre et précise.

Dé�nition 1 Une borne du WCET d'une tâche est sûre si elle est supérieure à tous lestemps d'exécution possibles.

Cette condition permet de garantir les contraintes de temps. En e�et, lors de la phasede validation, il est nécessaire de s'assurer que chaque tâche termine bien son exécutionavant son échéance de terminaison au plus tard (deadline). Une telle véri�cation est validesi le temps d'exécution considéré est bien supérieur à tous les temps d'exécution possibles.

Dé�nition 2 Une borne du WCET d'une tâche est précise si elle est la plus proche possibledu maximum de tous les temps d'exécution possibles.

Il est important que l'approximation du WCET sur-approxime le moins possible leWCET réel. Une trop grande sur-approximation peut entraîner un échec de faisabilitésur un système donné ou amener les concepteurs à surestimer les ressources matériellesnécessaires. Cette surestimation amène à un coût de réalisation plus important, à uneconsommation d'énergie plus élevée, etc.

L'estimation des pire temps d'exécution a donné lieu à de nombreuses méthodes decalcul présentées dans [23]. Elles peuvent être regroupées dans les deux catégories sui-vantes : méthodes dynamiques et méthodes statiques.

1.1 Méthodes dynamiques

Les méthodes dynamiques consistent à fournir un jeu d'entrée à l'application et à l'exé-cuter sur un système réel ou sur un simulateur a�n de mesurer le temps d'exécution.

Les jeux d'entrées peuvent être fournis de façon explicite par l'utilisateur ou générés defaçon automatique. Cette génération peut utiliser une recherche exhaustive sur la longueurdes chemins [36] mais, le temps de génération de tous les jeux de tests ainsi que le tempsd'évaluation pour chacun d'eux est généralement très long rendant cette approche di�ci-lement exploitable. Une autre approche consiste à utiliser un algorithme génétique [33] oudu recuit simulé a�n d'obtenir des jeux de tests maximisant le temps d'exécution.

7

CHAPITRE 1. MÉTHODES D'ESTIMATION DE PIRE TEMPS D'EXÉCUTION (WCET) 8

Dans la majorité des cas, les méthodes dynamiques posent un problème vis-à-vis de lasûreté, occasionné par la di�culté de générer des entrées par rapport au plus long chemind'exécution. Elles ne sont pas en mesure de garantir que le plus grand temps d'exécutionainsi mesuré est toujours supérieur à toutes les exécutions possibles. De ce fait, elles sontsurtout utilisées pour comparer les résultats obtenus par les méthodes statiques.

1.2 Méthodes statiques

Contrairement aux méthodes dynamiques, les méthodes statiques se basent sur unmodèle d'architecture matérielle et sur une analyse de la structure du programme sansexécuter celui-ci. Elles sont de ce fait indépendantes du jeu d'entrée et garantissent ainsila sûreté de l'estimation du WCET.

Ces méthodes utilisent une représentation du programme sous la forme d'un graphe de�ot de contrôle (GFC) modélisant les chemins d'exécutions possibles. Celui-ci est le plussouvent construit à partir d'une analyse statique du code assembleur ou du code objet.

Ces méthodes sont constituées de deux phases successives. La première consiste enune analyse bas niveau prenant en compte l'architecture matérielle. La seconde consiste àcalculer une borne supérieure du WCET à partir des informations de l'analyse précédenteet du graphe de �ot de contrôle.

1.2.1 Graphe de �ot de contrôle

Un graphe de �ot de contrôle est constitué d'un ensemble de n÷uds représentant lesblocs de base du programme. Un bloc de base est constitué d'une suite d'instructionsuniquement séquentielles et possède un seul point d'entrée et de sortie. Les arcs du graphe,eux, modélisent les relations (prédécesseur, successeur) entre les di�érents blocs de base.Cette représentation permet de décrire tous les chemins d'exécutions possibles entre lesdi�érents blocs de base. La �gure 1.1 illustre ce type de graphe associé aux fonctions mainet impaire.

BB1

fonction impaire

BB4

BB2

BB3

Saut

Pas de saut

CALLimpaire

CALLimpaire

fonction main

BB7

BB5

BB6

BB8

BB11 BB10

BB9

Fig. 1.1 � Graphe de �ot de contrôle

8


Dans un cadre WCET, le graphe �ot de contrôle tel quel ne dispose pas d'informationssu�santes. En e�et, les chemins d'exécutions sont potentiellement de longueur in�nie. Ilest donc nécessaire d'y ajouter des informations comme par exemple le nombre maximumd'itérations des boucles. Ces informations sont généralement à la charge du programmeurqui annote le code source. Cette approche est due à l'impossibilité, en général, de détecterla terminaison de programme [3].

1.2.2 Analyse bas niveau

L'analyse bas niveau permet de déterminer statiquement des informations temporellessur le pire temps d'exécution d'une séquence d'instructions (bloc de base) en prenant encompte l'architecture du système.

La di�culté de cette analyse est liée à la prise en compte de certains éléments matérielscomme les pipelines introduisant du parallélisme ou encore les caches introduisant unevariation du temps d'exécution d'une instruction.

Ce document étant orienté sur la hiérarchie mémoire, nous détaillerons par la suitedi�érentes méthodes traitant des caches, car ils sont étudiés par un grand nombre detravaux. Des travaux ont également été proposés pour les pipelines mais leur étude dépassele champ de ce document.

Pour simpli�er, considérons pour le moment, dans cette vue d'ensemble, que l'on disposed'une borne supérieure du pire temps d'exécution de chacun des blocs de base et qu'ils sontconstants et indépendants du contexte.

1.2.3 Calcul du pire temps d'exécution

Le calcul d'une borne supérieure du WCET s'e�ectue à partir du graphe de �ot decontrôle et du pire temps d'exécution des blocs de base. Nous allons présenter deux ap-proches di�érentes pour ce calcul : une classe de méthodes basée sur l'énumération implicitedes chemins et une classe de méthodes basée sur l'arbre syntaxique.

Méthode d'énumération implicite des chemins

Cette méthode a été proposée par Li et al.[14] et au même moment par Puschner etal [25]. Elle repose sur une transformation du graphe de �ot de contrôle en un systèmede contraintes linéaires. Une première partie de ce système décrit la structure du graphe(contraintes de �ot) où chaque n÷ud est valué par son nombre d'occurrence (noté ni). Lasomme des occurrences des arcs prédécesseurs est égale à la somme des occurrences des arcssuccesseurs. La seconde partie du système de contraintes exprime les informations supplé-mentaires liées au graphe de �ot de contrôle comme par exemple, le nombre d'itérationsmaximal d'une boucle.

À partir de ce système de contraintes, on cherche à maximiser l'expression suivante a�nd'obtenir une borne supérieure du WCET :∑

i

ni ∗ wi

où wi représente une borne supérieure du WCET du bloc de base i fourni par l'analysede bas niveau. La maximisation de cette expression est obtenue par des méthodes utiliséesdans les problèmes de résolution de programmation linéaire.

Cette méthode, reposant uniquement sur le graphe de �ot de contrôle, est intéressantecar elle permet de prendre en compte des codes optimisés lors de la phase de compilation.

9


Méthode basée sur l'arbre syntaxique

Cette méthode proposée par Puschner et Koza [24] utilise la représentation d'un pro-gramme sous forme d'un arbre syntaxique. Chaque n÷ud de ce type d'arbre représente unestructure de contrôle du langage de haut niveau. Par exemple, un n÷ud SEQ représenteune séquence d'instructions où chacun des �ls peut être une feuille représentant un bloc debase ou une autre structure du langage (boucle, conditionnelle. . . ).

La borne supérieure du WCET est calculé de façon récursive en partant des feuillesde l'arbre syntaxique (contenant la borne supérieure du WCET des blocs de base) eten remontant l'information jusqu'à la racine de l'arbre celle-ci contenant ainsi une bornesupérieure du WCET de l'application. A chaque n÷ud, on calcule sa valeur en maximisantle temps d'exécution de ses �ls. Le tableau 1.1 illustre la valeur des principales structuresde contrôle.

Structure FormuleS1; ...;Sn WCET (S1) + ... + WCET (Sn)

if B then S1 else S2 WCET (B) + max(WCET (S1),WCET (S2))while B do S done maxiter ∗ (WCET (B) + WCET (S)) + WCET (B)

Tab. 1.1 � WCET des structures de contrôle

Nous pouvons remarquer la présence de maxiter pour la structure de boucle qui repré-sente le nombre maximum d'itérations provenant des informations ajoutées au graphe de�ot de contrôle.

Cette méthode fournit un arbre temporel contenant le pire temps d'exécution de cha-cun des n÷uds de l'arbre syntaxique. Ces informations sont intéressantes pour des phasesd'optimisations de codes car celles-ci sont directement reliées au code source et permettentd'identi�er les parties coûteuses en temps de calcul.

Remarque

Le fait d'obtenir une borne supérieure du pire temps d'exécution permet, quelque soitla classe de méthodes utilisée, d'obtenir l'un des pires chemins conduisant à cette borne.Nous précisons bien l'un des pires chemins et non pas le pire chemin car plusieurs cheminsd'exécution di�érents peuvent mener à cette borne. De plus, ce chemin peut représenter unchemin infaisable à l'exécution. La connaissance de la borne supérieure du WCET ainsi quel'un des pires chemins permet de déterminer les fréquences d'exécution sur ce pire cheminde chacun des blocs de base et des arcs les reliant.

1.3 Considérations au niveau du code

La plupart des analyses statiques de WCET considèrent certaines hypothèses restric-tives vis-à-vis du code source des programmes a�n de faciliter les analyses.

Au niveau des boucles, elles sont considérées, dans la plupart des méthodes, commeétant régulières (itération avec un pas régulier) pour simpli�er l'estimation des accès auxdonnées (les éléments d'un tableau par exemple) et elles disposent d'une borne supérieuredu nombre d'itérations possibles. De façon similaire, le nombre d'appels récursifs est bornélorsque les fonctions récursives sont prises en compte par l'analyse.

Au niveau des fonctions, les appels sont généralement considérés comme statiques pourpermettre une évaluation temporelle plus précise. En e�et, l'utilisation des pointeurs sur

10


fonctions permettant les appels indirects peut amener à une variation importante du tempsd'exécution.

Au niveau des données, les variables sont considérées comme déclarées statiquement(globales ou allouées en pile) permettant ainsi de connaître la taille et l'adresse de chaquevariable lors de l'analyse statique. Considérer l'utilisation des pointeurs, rend la prévi-sion précise du temps d'accès à la mémoire plus di�cile. En e�et, connaître statiquementl'adresse référencée est, dans le cas général, un problème indécidable. De plus, pour l'alloca-tion dynamique, l'étude de Puaut [22] montre que le ratio, entre la borne supérieure du piretemps calculée et le pire temps mesuré des principaux algorithmes d'allocation dynamiquede mémoire actuels, est important. Ceci amène à une sur-approximation signi�cative duWCET lors de la prise en compte de l'allocation dynamique pour garantir la sûreté.

11

Chapitre 2

Calcul de WCET et hiérarchiemémoire

Après avoir présenté les principes généraux liés au calcul d'une borne supérieure duWCET, nous allons maintenant aborder la prise en compte des éléments matériels com-posant la hiérarchie mémoire dans le calcul de cette borne. Nous commençons par lesmémoires caches puis nous regardons le cas de la mémoire virtuelle et de la pagination.

2.1 Calcul de WCET et mémoires caches

Un grand nombre de travaux se sont axés sur les caches [9, 16, 34, 10, 17, 27, 28,20]. Pour cette raison, nous allons passer un peu de temps sur les di�érentes techniquesexistantes pour ce composant. La plupart des méthodes proposées ne sont pas uniquementintéressantes pour les caches mais également pour leurs approches génériques qui les rendentadaptables à d'autres niveaux de la hiérarchie mémoire.

Nous commençons par quelques rappels sur l'architecture des caches puis, nous passonsaux méthodes d'analyse en détaillant les concepts. Nous discuterons des points forts maiségalement de certaines limites qui nous amèneront à étudier d'autres approches répondantà ces limitations.

2.1.1 Architectures des caches

Les mémoires cache sont des mémoires à accès rapide de faible capacité situées à proxi-mité du processeur. Elles sont constituées de plusieurs lignes (ou blocs) de taille �xe.Chaque ligne peut contenir une suite contiguë de mots mémoires (ligne mémoire).

Lors du premier accès à une donnée, celle-ci est chargée à partir de la mémoire cen-trale dans une ligne du cache pour permettre d'accélérer les accès futurs en se basantsur les principes de localité spatiale et temporelle. Lors d'un tel chargement, les donnéesdéjà présentes dans la ligne de cache concernée sont en con�its et elles sont supprimées(ou déplacées selon le type de cache) en suivant une politique de remplacement. Plusieurspolitiques existent telles que Least Recently Used (LRU), random, round-robin. . .

Parmi les caches, on distingue di�érents types : les caches à correspondance directe(direct mapped), les caches totalement associatifs (fully associative) et les caches associatifspar ensemble (set associative).

� les caches à correspondance directe disposent d'une seule ligne de cache possible pourun bloc mémoire donné (�gure 2.1.a) ;

12

CHAPITRE 2. CALCUL DE WCET ET HIÉRARCHIE MÉMOIRE 13

� les caches totalement associatifs placent les blocs mémoire dans n'importe quelle lignedu cache (�gure 2.1.b) ;

� les caches associatifs par ensemble placent les blocs mémoire dans un nombre limitéde lignes de cache. Par exemple, si le degré d'associativité est de deux alors un blocmémoire dispose de deux emplacements possibles dans le cache (�gure 2.1.c).

0

Mémoire centraleprogrammeligne de ligne Mémoire cache

de cache

0123456789

101112131415161718192122232425

246

0

(a) correspondance directe

(c) associatif par ensemble (2 voies)

(b) totalement associatif

1 243

576

6

012345

7

1

57

3

Fig. 2.1 � Représentation des caches

Nous pouvons remarquer que les caches à correspondance directe sont similaires auxcaches associatifs par ensemble dont le degré d'associativité est de un et également queles caches totalement associatifs sont similaires aux caches associatifs par ensemble dontle degré d'associativité est égal au nombre de ligne de caches. Cette vision permet deprendre en paramètre le degré d'associativité des caches et ainsi d'adapter plus facilementles di�érentes méthodes d'analyses.

Les caches permettent d'accélérer les accès mémoires en exploitant d'une part la localitéspatiale (chaque bloc du cache contient plusieurs références mémoires contiguës améliorantainsi le temps d'accès aux données proches) et d'autre part la localité temporelle (unedonnée est conservée dans une ligne de cache jusqu'à son éviction).

Cependant, le contenu des caches est dynamique et dépendant du chemin empruntélors de l'exécution. Par exemple, une conditionnelle (�gure 2.2.a) peut modi�er le contenudu cache de deux façons selon le chemin emprunté. Il est donc di�cile de prédire de façonsûre leur contenu. Cet indéterminisme est principalement lié aux interférences des donnéesprovoquant le remplacement des lignes de caches. Les données sont généralement placéesdans le cache en fonction des bits de poids faible de leur adresse mémoire. Ainsi, l'accès àdes données ayant les mêmes bits de poids faibles au sein d'une même tâche provoque uncon�it de cache, on parle d'interférences intra-tâches. De façon similaire, pour les systèmesmulti-tâches, l'accès aux données (même bits de poids faibles) de di�érentes tâches provoqueégalement un con�it et dans ce cas on parle d'interférences inter-tâches.

2.1.2 Analyse de caches

Nous présentons maintenant les principales méthodes d'analyse de caches pour les ins-tructions, les données dans un cadre mono-tâches puis ensuite dans un cadre multi-tâches.

Les analyses de caches reposent sur la connaissance de leur contenu en chaque pointde programme a�n de déterminer si les informations accédées sont présentes, dans ce cason parle de hit, ou absentes dans ce cas on parle de défaut de cache ou encore de miss. Le

13


temps de traitement d'un défaut de cache (i.e. le chargement de la donnée à partir d'unniveau plus bas de la hiérarchie mémoire) implique un temps supplémentaire à prendre enconsidération dans le calcul du pire temps.

Une approche naïve considère chaque accès à une donnée du cache comme un miss.Cette considération est très pessimiste et sur-approxime le WCET.

A�n de réaliser une analyse plus �ne, il est nécessaire de connaître toutes les adressesmémoire (instructions et données) référencées par l'ensemble du programme suivant l'en-semble des chemins. Ces références peuvent être déterminées par une analyse statique du�ot de données du programme. Ces informations sont ensuite utilisées pour déterminer lesdonnées présentes dans le cache lors de l'exécution.

Le contenu concret du cache (concrete cache state (CCS)) en un point de programmeest dépendant de l'instance d'exécution. L'énumération de tous les contenus possibles ence point de programme liée à toutes les exécutions possibles est très coûteuse en temps eten place mémoire dûe à la complexité exponentielle de ce problème.

Pour résoudre cette complexité, di�érents travaux utilisent une vision abstraite du cache(abstract cache state (ACS)). L'ACS représente de façon abstraite le contenu du cache en unpoint de programme en utilisant une notion ensembliste. Concrètement, un ACS peut êtrevu comme une union de tous les CCS en un point de programme. Il permet de considérer,dans une même structure de données, l'ensemble des chemins d'exécution possibles.

4567

0123

9

4

67

0523

94

7

0163

510

10

(a) Représentation concrète

4567

0123

9 10

4

7

01,52,63

5,96,10

(b) Représentation abstraite

âge + âge +

Fig. 2.2 � Représentation concrète et abstraite des caches

La �gure 2.2 illustre la di�érence entre la représentation concrète et abstraite d'uncache associatif par ensemble à deux voies utilisant une politique de remplacement LRU.Sur le chemin d'exécution de gauche, la ligne mémoire 9 est chargée dans le cache tandisque la 10 est chargé sur le chemin de droite ce qui amène à deux états possibles du cache(2.2.a). La représentation abstraite permet de regrouper ces deux états concrets en un seulétat abstrait (2.2.b) en réalisant l'union des deux états sur chaque ligne et chaque voie ducache.

2.1.2.1 Les caches d'instructions

Les premiers travaux d'analyse de cache se sont axés sur les caches d'instructions. Ilsconsistent à déterminer statiquement le contenu ACS du cache en "simulant"1 la politiquede remplacement en chaque point de programme en ayant préalablement calculé les adresses

1Le terme simulation désigne ici l'évolution du contenu abstrait du cache et non pas du contenu concret.

14


des instructions. Nous allons présenter ici deux méthodes : l'une basée sur l'interprétationabstraite et l'autre sur une simulation statique de cache, en se limitant dans les deux casà une politique de remplacement de type LRU.

Interprétation abstraite

La méthode proposée par Ferdinand et al. [9, 31] repose sur la théorie de l'interprétationabstraite [6] et est basée sur deux analyses : Must et May.

L'analyseMust détermine l'ensemble des blocs mémoire présents de façon certaine dansle cache en un point de programme quelque soit le chemin d'exécution emprunté. Pour cefaire, elle utilise la notion d'âge, représentant le temps de présence dans le cache, des blocsmémoire. L'opérateur t entre deux ACS produit un ACS contenant uniquement les blocsmémoire présents dans les deux ACS d'origine et conserve l'âge du plus élevé. La �gure2.3.a illustre cette opération. Le résultat de cette analyse permet de connaître de façonsûre les blocs mémoire présents dans le cache quelque soit l'exécution du programme.

L'analyseMay détermine l'ensemble des blocs mémoire susceptibles d'être dans le cacheen un point de programme. La di�érence avec l'analyse Must se situe au niveau de l'opéra-teur t. Il conserve l'ensemble des blocs mémoire présents dans l'un des deux ACS d'origineet conserve l'âge du plus récent s'ils sont présents dans les deux. La �gure 2.3.b illustre cetteopération. Le résultat de cette analyse permet de déterminer de façon certaine les blocsmémoire absents du cache en un point de programme quelque soit le contexte d'exécution.

{ }{ }{6}{7}

{4,0}{ }

{2,10}{ }

{4}

{6}{7}

{0}{5}

{2,10}{ }

{9}{0}

{7}

{4}{13}{10}{ }

{1}{2,6}

(a) Exemple analyse Must

âge +

intersection+ âge max

{0,4}{1,9}{2,6}{7}

{ }{5,13}{10}{ }

{4}

{6}{7}

{0}{5}

{2,10}{ }

{9}{0}

{7}

{4}{13}{10}{ }

{1}{2,6}

(b) Exemple analyse May

âge +

union+ âge min

Fig. 2.3 � Exemple d'analyse Must et May

Une observation au niveau des boucles montre que le contenu du cache est généralementdi�érent entre la première itération et les suivantes. En e�et, la première itération charge lesblocs mémoire manquant dans le cache et les itérations suivantes disposent de la majeurepartie de leurs blocs mémoires dans le cache. Pour prendre en considération ce caractèreparticulier, Ferdinand et al. déroulent virtuellement la première itération a�n de di�érencierle contenu du cache à l'entrée de boucle et lors des itérations successives. De façon similaire,pour les fonctions récursives, ils déroulent virtuellement le premier appel et considèrent quele nombre d'appels est borné.

Pour les fonctions, ils di�érencient le contexte d'appel pour prendre en compte uncontenu di�érent de l'ACS en entrée et en sortie de fonctions pour être représentatif del'instance d'appel. Concrètement, cette technique peut être vue comme un inlining virtueldes fonctions.

De ces analyses, ils déduisent pour chaque point de programme si une instruction esttoujours présente dans le cache (always hit), toujours absente (always miss) ou indéterminée

15


car dépendante de l'instance d'exécution. Dans le dernier cas, ils considèrent l'accès commeun miss pour garantir la sûreté de l'estimation du WCET.

Simulation statique de cache

Cette méthode présentée par Mueller et al. [16, 34] repose également sur une analysedu �ot de données permettant de déduire le contenu abstrait du cache en chaque point duprogramme. Elle utilise une méthode similaire à celle employée par l'interprétation abstraitepour déduire le contenu des ACS. La classi�cation des instructions est un peu di�érentecar ils dé�nissent quatre types d'accès : always-miss, always-hit, �rst-miss et �rst-hit.

La classi�cation d'une instruction comme always-miss ou always-hit est équivalente àla méthode détaillée précédemment. Par contre, pour gérer le cas des boucles, ils utilisentdeux classi�cations permettant de distinguer la première exécution de la boucle avec lesexécutions suivantes.

Une instruction est caractérisée comme �rst-miss si à l'entrée d'une boucle on ne peutpas garantir sa présence dans le cache mais on peut le garantir pour les itérations suivantes.Et réciproquement, une instruction est caractérisée comme �rst-hit si à l'entrée d'uneboucle on peut garantir sa présence dans le cache mais on ne peut pas le garantir pour lesitérations suivantes.

Dans leur analyse, ils di�érencient les contextes d'appels à une même procédure enutilisant un graphe d'instance d'appel. Par exemple, une fonction f appelée en deux pointsdi�érents du programme aura deux instances d'appel f1 et f2. Cette technique permet dedi�érencier le contenu du cache à l'entrée et à la sortie d'une fonction en considérant descontenus d'ACS di�érents représentatifs du contexte d'appel.

Le temps de traitement de cette analyse est important car elle est e�ectuée sur l'inté-gralité du programme. Dans [18], ils proposent de faire cette analyse en deux temps pourréduire la complexité du problème et ainsi permettre l'analyse de programmes plus impor-tants. L'idée repose sur une première phase traitant uniquement les modules du programmesans prendre en compte les appels de fonctions. Puis, dans une seconde phase, ils intègrentles appels de fonctions en repartant des résultats obtenus précédemment.

Les deux analyses présentées ici sont basées sur une politique de remplacement LRU.Dans [12], des extensions sont proposées a�n de considérer d'autres politiques de rem-placement comme Pseudo-LRU et Pseudo-Round-Robin. Cependant, ils observent que leremplacement LRU o�re généralement la possibilité d'une prédiction précise tandis que lesautres stratégies sont plus di�ciles à prédire et donc moins précises.

2.1.2.2 Les caches de données

De façon similaire à la méthode de simulation statique de cache pour les instructions,White et al. caractérisent dans [34], les accès aux données comme �rst-hit, �rst-miss,always-hit, always-miss. Leur méthode repose sur une première phase de calcul d'adressesrelatives sur du code optimisé après compilation. Ils sont ensuite en mesure de déduireles adresses en se basant sur l'organisation de l'espace d'adressage et des données danscelui-ci. A ce stade, ils peuvent caractériser les accès aux données pour chaque niveau deboucle en reprenant les classi�cations précédentes des accès mémoire. Cependant, caracté-riser comme hit ou miss la référence à une donnée est plus di�cile dans ce cas. Prenons,par exemple, un tableau parcouru de façon séquentielle par une boucle. L'accès au premierélément occasionne un miss et charge les k premiers éléments dans une ligne de cache. Lesk− 1 accès suivants occasionnent des hit tandis que l'accès à l'élément k +1 occasionne un

16


miss de façon similaire au premier accès. La présence dans le cache des données se trouveégalement dépendante du nombre d'itérations e�ectuées au sein d'une boucle.

Plus récemment, Ghosh et al. [10] ont proposé des équations de défauts de cache plusspéci�ques aux caches de données pour des programmes disposant de boucles. Dans leurméthode, ils utilisent l'espace d'itération des boucles a�n de déterminer des vecteurs deréutilisation. Ceux-ci représentent la réutilisation des données entre di�érentes itérations.La �gure 2.4.b montre l'espace d'itération associé au programme de multiplication de ma-trice (�gure 2.4.a). Le vecteur ~r représente la réutilisation de l'élément de la matrice A lorsde l'itération de la boucle la plus imbriquée.

C[j][i] += A[k][i] * B[j][k] ;for(j = 0; j < N; j++)

for(k = 0; k < N; k++)for(i = 0; i < N; i++)

(a) Multiplication de matrices

ki

j

r

(b) Espace d’itération

Fig. 2.4 � Espace d'itération pour la multiplication de matrices

Lorsque la réutilisation d'une référence mémoire est satisfaite, il en résulte un hit car laréférence est présente dans le cache. Cependant, en pratique les réutilisations ne résultentpas nécessairement un hit dû aux con�its de cache. Leur méthode consiste à déterminer lesinstances de boucles qui provoquent un miss pour une réutilisation donnée. Pour cela, ilsdé�nissent les équations cold miss et replacement miss. Ces équations sont représentativesdes di�érents cas de miss (premier accès à la donnée, dépassement de la taille d'une lignede cache et con�its de cache) pouvant survenir pour un vecteur de réutilisation.

La résolution de chacune de ces équations permet de déduire l'ensemble des miss po-tentiels d'une boucle. En combinant les résultats des di�érentes équations, ils déterminentl'ensemble des miss réels résultant lors de l'exécution d'une boucle.

La version initiale de cette méthode repose sur des considérations spéci�ques au niveaudu code : le nombre d'itérations est borné et connu, les indices des tableaux sont desfonctions linéaires des variables d'inductions de la boucle, les boucles sont parfaitementimbriquées et rectangulaires et le programme ne contient pas des données dépendantes deconditionnelles.

Des ra�nements successifs ont permis d'utiliser cette méthode sur un plus grand nombrede programmes. Dans [26], Mueller et al. permettent l'utilisation de données dépendantesde conditionnelles et de séquences de boucles pouvant être rectangulaires ou triangulaires.En�n, a�n d'obtenir une estimation plus précise, ils représentent virtuellement les donnéesscalaires par un tableau lors de cette analyse.

Les limites de ce type d'analyse sont liées à la di�culté de calculer statiquement lesadresses des données ce qui restreint, généralement, l'analyse à des programmes manipulantdes données déclarées statiquement. Ces méthodes sont principalement des adaptations,au cas du WCET, de travaux de recherche issus de l'optimisation de programmes et de laparallélisation.

17


2.1.2.3 Analyse de caches et multi-tâches

La prise en compte des caches dans l'analyse des systèmes temps-réel multi-tâchesajoute de la complexité au problème dû aux interférences inter-tâches. Pour exemple, consi-dérons la préemption d'une tâche t1 par une tâche plus prioritaire t2. Le contenu du cachelors de la préemption et à la �n de l'exécution de t2 peut être di�érent car les lignes decache utilisées par la tâche t2 peuvent remplacer celles utilisées par t1. Lors de la reprise dela tâche t1, des miss supplémentaires sont causés par ces interférences. Le temps supplé-mentaire introduit par ces miss est couramment appelé Cache-Related Preemption Delay(CRPD).

L'analyse du CRPD repose sur la connaissance du contenu abstrait du cache en chaquepoint de programme de la tâche préemptée et sur les lignes de cache utilisées par la tâcheplus prioritaire. Ces informations peuvent être déterminées par les méthodes détailléesprécédemment. Le CRPD de la tâche préemptée en un point de programme est ensuitecalculé en considérant les lignes de cache réutilisées après la préemption et remplacées lorsde l'exécution de la tâche plus prioritaire.

Dans [17] Hemendra et al. proposent une méthode pour estimer le CRPD pour lescaches d'instructions. Leur approche consiste à maximiser la valeur du CRPD. Pour cefaire, ils prennent la �n de chaque bloc de base comme point de préemption possible etcalculent pour chacun de ces points le nombre de miss résultant. La valeur du CRPD estensuite obtenue en prenant le nombre maximum de miss résultant parmi les points depréemption puis, en le multipliant par le coût d'un miss.

Cette approche peut amener à une surestimation du WCET dans le cas où la tâche estpréemptée plusieurs fois lors de son exécution (ou sa période pour les tâches périodiques).Dans [27], Ramaprasad et al. ra�nent cette estimation pour les caches de donnée en prenantle nombre de fois, noté n, où la tâche peut être préemptée pendant son exécution. Ilsdéterminent ensuite les n plus grand délais de préemption et calculent le CRPD en faisantla somme de ces n délais.

Ces méthodes permettent d'estimer de façon sûre le délai de préemption des tâcheslors de l'analyse de système multi-tâches. Dans [29], Staschulat et al. considérent que lapréemption est due à plusieurs tâches. Ils permettent ainsi d'étendre l'analyse à un ensemblede tâches que l'on souhaite ordonnancer.

2.1.2.4 Bilan

Nous venons de voir les méthodes d'analyses statique des caches d'instructions et dedonnées dans le cadre de l'estimation du pire temps d'exécution pour les systèmes temps-réel. Elles permettent d'estimer une borne supérieure du pire temps d'exécution d'unetâche tout en prenant en compte l'architecture matérielle des caches. Elles sont égalementen mesure d'estimer le temps de préemption des tâches pour les systèmes multi-tâchespréemptifs.

Ces méthodes sont génériques et adaptables aux systèmes dont on connaît les carac-téristiques des caches (capacité, degré d'associativité). La politique de remplacement estplus contraignante. En e�et, certaines politiques de remplacement comme LRU, round-robin sont modélisables et exploitables tandis que les politiques de remplacement pseudo-aléatoire sont modélisables mais rendent des résultats di�cilement exploitables car tropsurestimés. En�n, les caches disposant d'une politique de remplacement ou de remplissagenon documentée par les constructeurs se prêtent di�cilement à ce type d'analyse.

Finalement, le fait de considérer localement le temps d'un miss comme étant supérieurau temps d'un hit ne garantit pas toujours d'obtenir le pire temps d'exécution. Lundqvist et

18


Stenström montrent dans [15] qu'un miss conduit parfois à un temps d'exécution plus courtqu'un hit dû à ce qu'ils appellent timing anomalies. Ces anomalies se produisent notammentsur les processeurs out-of-order et sont liées dans ce cas à l'ordre d'allocation des ressources.Le temps d'exécution est de ce fait dépendant du contexte global de l'exécution et non plusseulement local. Ce phénomène met en défaut la sûreté des analyses précédentes sur certainstypes d'architectures matérielles.

2.1.3 Cache locking et cache partitioning

Les limitations que l'on vient de voir, au niveau des méthodes d'analyse, ont amené àdi�érentes approches a�n de contourner ces contraintes. Nous allons détailler maintenantles méthodes de cache partitioning et de cache locking en mettant l'accent sur les di�cultésqu'elles permettent d'éviter.

2.1.3.1 Cache partitioning

La méthode de cache partitioning proposée dans [28] par Sasinowski et Strosniderconsiste à partitionner les lignes de cache en plusieurs ensembles distincts et à assignerces ensembles aux di�érentes tâches. Chaque tâche dispose ainsi d'un espace réservé àelle seule dans le cache. Ceci permet de garantir la présence dans les caches du code etdes données récemment utilisées dans un système multi-tâches préemptif. Cette méthodepermet de supprimer les interférences inter-tâches rendant ainsi les délais de préemptions(CRPD) nuls. Cependant, cette approche à un impact sur l'utilisation du cache et sur letemps d'exécution car chaque tâche dispose d'un volume de cache plus limité. Une analysede cache reste nécessaire pour les interférences intra-tâche.

2.1.3.2 Cache locking

Cette méthode consiste à charger le contenu du cache avec des références mémoire dé-�nies au préalable puis, à le �ger pour qu'il reste inchangé sur une zone du programmedonnée, lors de l'exécution. Presque tous les processeurs actuels disposent de fonctionspermettant ce genre d'opérations. L'idée primordiale de cette technique est de rendre pré-visible le temps d'accès mémoire en disposant statiquement du contenu du cache en chaquepoint de programme.

Dans les travaux existants, deux approches ont été proposées : le static cache locking etle dynamic cache locking. Le static cache locking consiste à charger le contenu du cache àl'initialisation du système et celui-ci reste �gé durant toute l'exécution. Le dynamic cachelocking consiste à charger le contenu du cache au démarrage mais également à modi�er lecontenu lors de l'exécution par exemple lors de la préemption d'une tâche. Dans les deuxcas, le contenu du cache est déterminé hors-ligne.

Dans [20], Puaut et al. proposent deux algorithmes gloutons permettant de sélectionnerle contenu du cache d'instructions pour un ensemble de tâches périodiques dans un contextestatic cache locking. Le premier algorithme minimise l'utilisation du CPU pour l'ensembledes tâches en sélectionnant les accès mémoires les plus fréquents sur le pire chemin d'exécu-tion. Le second algorithme à pour but de minimiser les interférences inter-tâches le long dupire chemin d'exécution. Ces deux approches montrent qu'en utilisant le concept de cachelocking, il est possible de mettre en ÷uvre di�érentes heuristiques orientées pire temps.

Dans [19] Puaut propose une approche dynamic cache locking consistant également àdéterminer le contenu du cache d'instructions statiquement. Cependant, plusieurs points deprogramme (chargement du cache) sont déterminés par un algorithme glouton ou génétique

19


découpant ainsi le programme en zones d'utilisation. Ces points sont ensuite utilisés pourmodi�er le contenu du cache lors de l'exécution, apportant ainsi un contenu plus spéci�queà la zone de programme exécutée. Les résultats montrent que cette approche réduit lenombre de miss dans le cas de programme disposant de localité spatiale et temporelleen comparaison à une analyse de cache utilisant une politique de remplacement di�cile àprédire avec précision comme pseudo round-robin.

Le concept de cache locking permet de connaître statiquement le contenu du cache enchaque point de programme. La connaissance de ce contenu permet de prédire de façon sûreet précise le temps d'accès aux données et les délais de préemptions (ils sont constants cardépendants des lignes de cache à charger). Cela permet également de supprimer les timinganomalies identi�ées précédemment (paragraphe 2.1.2.4). En�n, cette méthode permetd'exploiter les caches utilisant une politique de remplacement pseudo-aléatoire ou nondocumentée s'ils disposent des fonctionnalités permettant le chargement et le gel de cache.

2.2 Calcul de WCET et mémoire virtuelle

Dans cette partie, nous allons détailler le fonctionnement de la mémoire virtuelle dansles systèmes généralistes puis, nous ferons un parallèle avec les caches en montrant lesdi�cultés rencontrées pour transposer les analyses précédentes. En�n, nous termineronssur son utilisation au sein des systèmes temps-réel.

2.2.1 Principe de fonctionnement

Le concept de mémoire virtuelle est conçu pour permettre aux systèmes de réserverun espace d'adressage virtuel pour chacun des processus garantissant ainsi une isolationspatiale entre les programmes et o�rant la possibilité de réimplantation dynamique. Cetteapproche permet également d'exécuter un programme dépassant la capacité de mémoirephysique disponible. Par exemple, un programme de 160 Mo peut s'exécuter sur une ma-chine disposant de 128 Mo de mémoire si les parties du programme passent du disque à lamémoire à la demande.

La plupart des systèmes d'exploitations généralistes actuels utilisent le principe depagination à la demande. Celui-ci consiste à découper un programme en morceaux de taille�xe appelés pages et à charger les pages en mémoire centrale à partir du disque lorsqu'ellessont accédées. Ce procédé utilise une politique de remplacement de pages (généralementune approximation d'un remplacement LRU) pour déterminer les pages à transférer surdisque lorsque de nouvelles pages sont accédées et que la mémoire ne dispose plus d'espacedisponible.

Les adresses manipulées par le programme sont des adresses virtuelles. Lors de l'accèsà une référence mémoire, un mécanisme de traduction est e�ectué pour faire la translationentre l'adresse virtuelle et l'adresse physique. Pour faire cette traduction, les systèmes ac-tuels utilisent une unité matérielle de gestion mémoire (Memory management unit (MMU)).Ce mécanisme, illustré par la �gure 2.5, consiste à chercher les adresses récemment tra-duites dans un cache de traduction d'adresses (Translation Lookaside Bu�er (TLB)). Sil'adresse virtuelle est présente dans ce cache, on retourne directement l'adresse physiqueassociée. En cas d'absence dans le TLB, on regarde ensuite dans la table des pages contenueen mémoire centrale. Celle-ci contient une entrée par page virtuelle permettant ainsi d'ob-tenir soit l'adresse physique associée, soit l'absence de la page dans la mémoire physiqueoccasionnant alors un défaut de page. Dans ce cas, le système devra charger cette page enmémoire depuis le disque.

20


Table des pages

TLBadresse

virtuelle

absente

présenteadressephysique

adresse physiqueou défaut de page

Fig. 2.5 � Mécanisme de traduction d'adresses

Ce mécanisme dynamique amène une variation du temps d'accès à une adresse rendantdi�cile le calcul sûr et précis d'une borne supérieure du WCET des programmes utilisantun adressage virtuel. La variation de ce temps d'accès se situe à deux niveaux.

Premièrement, elle est due à la di�culté de prédire la durée de traduction d'une adresse.Le TLB est généralement un cache totalement associatif ne pouvant contenir l'ensemble desadresses des pages présentes en mémoire. Il est donc di�cile de prédire quelles adresses sontprésentes et quelles adresses occasionnent une recherche supplémentaire dans la table despages. De plus, le TLB est de plus en plus souvent composé de deux niveaux, un niveauuni�é pour le code et les données et un niveau séparant le code des données, rendantl'analyse plus di�cile.

Deuxièmement, prédire si l'adresse virtuelle provoque un défaut de page ou non estdi�cile. En e�et, la mémoire physique est partagée entre les di�érents processus et l'algo-rithme de remplacement de pages, implémenté de façon logicielle, est généralement assezéloigné d'un LRU strict.

2.2.2 Parallèle avec les caches

Les caches disposent de nombreuses méthodes d'analyses orientées pire temps. A pre-mière vue, il semble intéressant de transposer ces méthodes pour l'analyse du TLB et dela mémoire centrale.

Pour le TLB, les analyses précédentes sont adaptables en fonction de la politique deremplacement mise en ÷uvre par celui-ci. Cependant, celle-ci n'est pas toujours bien do-cumentée (par exemple le MPC5554 n'est pas documenté). Pour la mémoire centrale, bienqu'elle puisse être vue de façon abstraite comme un cache totalement associatif de grandecapacité partagé entre les di�érentes tâches de l'application, les méthodes utilisées pour lescaches ne sont pas directement exploitables.

Cette limitation est principalement due à la complexité de l'algorithme de remplacementde pages, implémenté de façon logicielle par le système d'exploitation. L'approche logiciellepermet par exemple, d'e�ectuer des recopies de pages en parallèle avec la pagination àla demande bloquant ainsi certaines pages lors du remplacement ou encore, de remplacerune page sans se soucier du propriétaire. L'utilisation de ces di�érentes fonctionnalités estgénéralement peu documentée cependant, elles in�uent sur la gestion mémoire.

La politique de remplacement de pages est donc di�cilement analysable ce qui limited'une part la connaissance du contenu de la mémoire physique et d'autre part la connais-sance du contenu du TLB celui-ci pouvant être modi�é lors d'un remplacement de pages.

Ainsi, ce mécanisme utilisé dans les systèmes généralistes provoque certaines limitationspour son usage dans les systèmes temps-réel dû à la di�culté de prédire de façon sûre etprécise les temps de traduction et d'accès aux pages référencées.

21


2.2.3 Méthodes pour le temps-réel

Les systèmes temps-réel ont tendance à écarter l'utilisation des mécanismes liés auconcept de mémoire virtuelle a�n de garantir les temps d'exécution. Pour cela, ils chargentà l'initialisation du système l'ensemble des programmes en mémoire physique. Ainsi, ilsécartent le mécanisme de pagination à la demande. En�n, ils utilisent directement lesadresses physiques pour ne pas se confronter au mécanisme de traduction d'adresses.

Certains systèmes utilisent néanmoins l'adressage virtuel principalement dans le butd'exploiter l'isolation spatiale entre programmes. Par exemple, le système Spring [7] ex-ploite cette fonctionnalité. Pour cela, il charge à l'initialisation du système l'ensemble despages en mémoire physique pour ne pas rencontrer de défauts de pages lors de l'exécution.Cette approche limite la taille cumulée des programmes à la taille de la mémoire physique.En ce qui concerne la traduction d'adresse, le contenu du TLB est géré de façon explicitepar le système d'exploitation (chargement puis gel du contenu) a�n d'assurer la présencedans ce cache de chaque référence mémoire. Cette considération permet d'écarter la varia-tion du temps de traduction d'adresse survenant lors d'un miss du TLB (entraînant unerecherche dans la table des pages). Ce procédé limite le nombre de pages d'un programmeà la taille du TLB. Cette limitation peut être diminuée en augmentant la taille des pagespour les architectures autorisant di�érentes tailles de pages.

Dans [2], Bennett et Audsley se sont intéressés à la structure des tables de pages pourle temps-réel. Leur approche permet une recherche en temps constant dans cette table etainsi rendre déterministe le temps de traduction des adresses virtuelles.

L'utilisation de la mémoire virtuelle pour le temps-réel est donc principalement axéessur le mécanisme de traduction d'adresses o�rant ainsi l'isolation spatiale mais écartantle mécanisme de pagination à la demande. Or, le volume des applications temps-réel atendance à augmenter et l'ajout de mémoire physique représente un coût non négligeabledans la conception des systèmes. Il serait donc intéressant de disposer d'un système de pa-gination adapté au temps-réel permettant l'exécution de programme dépassant la capacitémémoire des systèmes.

22

Chapitre 3

Pagination statique orientéetemps-réel

Dans ce chapitre, nous allons détailler les travaux menés durant le stage. Ils résidentdans l'élaboration d'un système de pagination déterministe o�rant l'isolation spatiale etun mécanisme de va-et-vient mémoire-disque a�n de rendre prévisible le contenu de lamémoire pour estimer précisément les temps liés aux opérations de pagination et ainsiles intégrer dans le calcul d'une borne supérieure du WCET. Nous considérons dans cettepartie le cas des systèmes mono-tâche. L'approche consiste à établir un plan de pagination,c'est à dire l'ensemble des informations relatives au mécanisme de pagination de façon horsligne. Ainsi, nous cherchons à dé�nir statiquement les points de chargements, décharge-ments, d'allocations et de désallocations des pages virtuelles d'un programme en mémoirephysique en précisant l'emplacement de chacune d'elles dans cette mémoire. L'objectif decette approche est double, nous cherchons à obtenir un système de pagination déterministea�n de pouvoir calculer une borne supérieure du pire temps d'exécution et nous cherchonségalement à minimiser cette borne en suivant une heuristique WCET. Pour ce faire, noustravaillons sur les �chiers binaires des programmes a�n de déterminer le graphe de �otde contrôle ainsi que les adresses des instructions et des données manipulées. Nous com-mencerons par une vue d'ensemble de notre approche. Puis nous traiterons le cas de lapagination pour les pages de code au travers de deux méthodes que nous étendrons ensuiteà la pagination des pages de données.

3.1 Vue d'ensemble

Comme la plupart des méthodes présentées précédemment, nous considérons dans notreapproche des programmes ayant les restrictions couramment utilisées pour l'estimationd'une borne supérieure du WCET. Principalement, nous considérons que chaque boucledispose d'une borne maximum d'itération, que le graphe d'appel des fonctions est connustatiquement (pas de pointeurs sur fonctions) et qu'il est acyclique.

Lors de notre analyse, nous manipulons des programmes représentés sous la forme d'ungraphe de �ot de contrôle noté par la suite GFC. Ce graphe est légèrement di�érent dela représentation de la �gure 1.1 (rappelée par la �gure 3.1.a) car au lieu de considérerun GFC par fonction, nous considérons un super graphe incluant les appels et retours defonctions. Le point d'entrée de chaque fonction est ainsi relié à chacun de ces appelantset les retours de fonctions sont reliés aux successeurs de chaque appelant. La �gure 3.1.billustre cette représentation.

23

CHAPITRE 3. PAGINATION STATIQUE ORIENTÉE TEMPS-RÉEL 24

BB1

fonction impaire

BB4

BB2

BB3

Saut

Pas de saut

CALLimpaire

CALLimpaire

fonction main

BB7

BB5

BB6

BB8

BB11 BB10

BB9

BB1

BB4

BB2

BB3 BB7

BB5

BB6

BB8

BB11 BB10

BB9

fonction mainfonction impaire

a. Graphe de flot de contrôle b. Super graphe de flot de contrôle

first

last

Fig. 3.1 � Représentation d'un programme

Ce graphe est composé d'un doublet (V,E) avec V l'ensemble des n÷uds du graphereprésentant chacun des blocs de base et E l'ensemble des arcs représentant le �ot decontrôle (branchements conditionnels et inconditionnels, appels et retours de fonctions).Nous ajoutons également un n÷ud virtuel de début noté first (relié au point d'entrée) etun n÷ud virtuel de �n noté last (relié à chaque point de sortie) ne référençant aucune pagevirtuelle a�n de déterminer les chargements initiaux et les déchargements �naux.

Nous supposons que l'ensemble des pages virtuelles référencées par chacun des blocs debase est connu statiquement et également que chaque bloc de base référence un nombre depages virtuelles inférieur ou égal au nombre de pages physiques du programme, noté n .Naturellement, le nombre total de pages virtuelles du programme peut être supérieur aunombre total de pages physiques. Cette hypothèse est introduite pour travailler au niveaudes blocs de base. Elle n'est pas limitative car un bloc de base peut être divisé en plusieurssous blocs ceux-ci étant composés uniquement d'une suite d'instructions séquentielles.

Le principe général de notre approche revient à dé�nir statiquement le contenu dela mémoire physique ainsi que les points de programme où ce contenu sera modi�é lorsde l'exécution. Ces informations, relatives aux mécanisme de pagination, sont associées àchacun des arcs du graphe de �ot de contrôle comme le montre la �gure 3.2 avec les pointsde chargement et de déchargement d'une page virtuelle donnée à l'entrée et à la sortie deszones de présence en mémoire1 (celles contenant les n÷uds grisés). La principale contrainteest de garantir que chaque bloc de base dispose bien de l'ensemble des pages virtuelles qu'ilréférence en mémoire physique.

Notre étude étant portée sur les systèmes temps-réel, notre objectif est de minimiser lenombre d'opérations liées au mécanisme de pagination le long d'un pire chemin d'exécution(un des pires chemins d'après la remarque sur le calcul du pire temps d'exécution 1.2.3),ce dernier pouvant être déterminé par des outils d'analyse statique de WCET. A�n degarantir la sûreté du calcul de la borne supérieure du WCET, les temps au pire cas doivent

1dans cet exemple, il serait plus e�cace de ne jamais décharger la page à l'intérieur de la boucle. Mais,ce n'est pas nécessaire possible si le système ne dispose pas d'un nombre de page physique su�sant pourcontenir l'ensemble des pages virtuelles référencées par les n÷uds de la boucle.

24


a

f

e

dc

b

g

déchargement

chargement

chargement

déchargement

Fig. 3.2 � Points de chargement et de déchargement

être considérés pour les accès disque, les allocations et les désallocations mémoire.A�n d'atteindre notre objectif, nous cherchons à déterminer les pages virtuelles les plus

intéressantes à conserver dans les pages disponibles de la mémoire physique, typiquementdans le cas de blocs de base référençant un nombre de pages virtuelles inférieur à n. Pourcela, nous proposons deux approches. La première consiste à partir des régions de présencemaximales en mémoire physique des pages virtuelles et de réduire ensuite ces zones. Laseconde consiste à partir des régions minimales de chaque page virtuelle et de les étendreensuite.

Dans ces deux approches, les fréquences initiales sur un pire chemin des arcs et desblocs de base sont obtenues par une évaluation du WCET. Celle-ci prend en compte lescoûts de chargement et de déchargement des pages virtuelles pour chacune des zones lesréférençant comme illustré par la �gure 3.2 pour une page virtuelle. Une telle allocationexiste bien qu'elle soit pessimiste car elle considère un chargement (resp. un déchargement)au début (resp. à la �n) de chaque zone d'utilisation de chacune des pages virtuelles.

3.2 Pagination des pages de code

Dans cette partie, nous nous intéressons à la pagination des pages de code. Nous consi-dérons que l'ensemble des pages de code référencées par chacun des blocs de base est connustatiquement. Ceci peut être réalisé par une analyse des adresses de chaque instruction àpartir du �chier binaire. Nous commencerons par présenter une approche par colorationde graphe issue d'une précédente étude [21], améliorée durant ce stage. Puis, une secondeapproche utilisant une méthode de programmation linéaire en nombres entiers (PLNE),intégralement dé�nie au cours de ce stage.

3.2.1 Approche par coloration de graphe

Cette approche est similaire à l'approche par coloration de graphe proposée par Chaitin[4] pour le problème d'allocation de registres couramment utilisée dans les compilateurs.A la di�érence que notre allocation porte sur l'intégralité du programme tandis que pourles registres, l'allocation est déterminée au niveau de chaque fonction. Ce problème estidenti�é comme NP-Complet, nous utilisons dans notre cas une heuristique de colorationgloutonne orientée WCET.

Notre approche considère les régions de programme où les pages virtuelles sont présentes

25


en mémoire physique. De telles régions que nous appelons webs2 peuvent être dé�niescomme des doublets (p, S) où p représente une page virtuelle du programme et S représenteun ensemble de sommets connexes du GFC (S ⊆ V ). Une web correspond donc à laprésence en mémoire physique d'une page virtuelle pour un ensemble de sommets donnés.L'idée ensuite revient à associer à chaque web une couleur (équivalent à une page physiquedonc n couleurs disponibles) pour déterminer l'emplacement en mémoire physique de lapage virtuelle associée à la web. De plus, il faut garantir que chaque paire de webs ayantun ou plusieurs sommets en commun (les webs interférentes) ont des couleurs distinctes.Lors de cette phase, si une web se trouve non coloriable, elle sera scindée en plusieurs websplus petites, celles-ci devenant ainsi coloriables.

3.2.1.1 Ensemble initial

Idéalement, si le système dispose d'un nombre de pages physiques su�sant, l'intégra-lité du programme tient alors en mémoire. Ainsi, les pages virtuelles sont chargées avantleur première utilisation et déchargées après leur dernière utilisation. Cette vision idéaleconsidère les zones de présence en mémoire physique des pages virtuelles comme étenduesau maximum limitant ainsi le nombre d'opérations de pagination. Par conséquent, nouspartons de cet ensemble a�n de réaliser le plan de pagination.

Le point de départ de cette méthode prend donc un ensemble de webs, que nous qua-li�ons de maximales, pour chacune des pages virtuelles. Une web maximale est associée àune page virtuelle p et est constituée de l'ensemble de tous les blocs de base référençantp ainsi que de l'ensemble des blocs de base se trouvant sur le chemin entre deux blocs debase référençant p. Plus formellement :

web_maximale(p) =

{x ∈ V | p ∈ pagesx

∨∃(y, z) ∈ V | p ∈ pagesy ∧ p ∈ pagesz

∧ x ∈ sucs(y) ∧ z ∈ sucs(x)}

avec pagesx l'ensemble des pages virtuelles référencées par le bloc de base x et sucs(x)l'ensemble des successeurs transitifs de x. La �gure 3.3 illustre la web maximale associée àune page virtuelle p.

a

f

e

dc

b

web maximalepour la page p

p dans PAGES

p dans PAGES

p dans PAGES

b

c

f

Fig. 3.3 � Exemple d'une web maximale

2en référence à l'allocation de registres

26


Cependant, l'ensemble des webs maximales est dans le cas général, pas directementcoloriable, par exemple, si un sommet i du GFC est associé à n+ 1 webs (soit n+ 1 pagesvirtuelles) avec n pages virtuelles référencées par i. Si de plus la web associée à la pagevirtuelle non référencée est coloriée lors de la phase de coloration gloutonne alors, la phasede coloration ne pourra pas terminer car il sera impossible d'associer une couleur à unedes webs associée à une page virtuelle référencée lors de l'exécution de i. Il est de ce faitnécessaire de garantir auparavant la faisabilité de la phase de coloration.

Pour assurer cette contrainte, il est nécessaire que chaque sommet du GFC soit associéà au plus n webs. Il faut donc choisir, pour chaque sommet i associé à plus de n websmaximales, les webs dont il faudra enlever i de leur ensemble de sommets. Ce choix estréalisé en suivant une heuristique WCET associant un poids à chacune des webs avecfrequence(x) la fréquence sur le pire chemin du sommet x.

Poids(web) =∑

i∈web|p∈pagesi

frequence(i)

Le poids d'une web est ainsi égal à la somme des fréquences des blocs de base apparte-nant à la web et référençant la page virtuelle p.

Les webs choisies sont celles de plus faible poids associées aux pages virtuelles nonréférencées par i. Nous avons expérimenté deux approches pour réaliser ce traitement. Lapremière, plus agressive, consiste à scinder les webs sélectionnées en les réduisant unique-ment aux zones référençant leur page virtuelle (i.e. les blocs de base connexes contenanttous la page virtuelle dans leur ensemble pages). Cette méthode que nous appelons COLGréalise une découpe globale des webs sur l'ensemble du programme. La seconde méthodeque nous appelons COLZ, consiste à retirer le sommet i des webs sélectionnées a�n deréaliser une découpe au niveau des zones de programme concernées. Cette découpe plus�ne nécessite un traitement supplémentaire pour assurer la propriété de connexité dessommets appartenant aux webs. Si après le retrait du sommet i, cette propriété n'est plusvéri�ée alors la web concernée est transformée en plusieurs sous webs contenant chacuneun ensemble de sommets connexes.

La �gure 3.4 illustre ces deux types de traitement. La web maximale initiale est celle dela �gure 3.3 (rappelée par la �gure 3.4.a), nous considérons que celle-ci dispose du poids leplus faible et que seul le bloc de base d est associé à plus de n webs. La �gure 3.4.b montrele traitement global (COLG) tandis que la La �gure 3.4.c montre le traitement par zone(COLZ).

a

f

e

dc

b

c

b. Découpe globale c. Découpe par zone

f

a

b

e

d

a

b

e

dc

f

a. Web maximale

p dans PAGES b

p dans PAGES

p dans PAGES

c

f

Fig. 3.4 � 2 méthodes pour la découpe d'une web

27


3.2.1.2 La phase de coloration

Une fois cette contrainte garantie, il reste la phase de coloration qui va permettre dedéterminer l'emplacement de chaque page virtuelle dans la mémoire physique. Pour cela,nous introduisons la notion de graphe d'interférence où un n÷ud de ce graphe représenteune web et un arc représente une interférence entre deux webs (i.e. les deux webs sontcomposées d'un même sous ensemble de blocs de base). La �gure 3.5.a illustre cette repré-sentation pour trois webs en montrant leur présence dans le CFG et le graphe d'interférenceassocié.

La phase de coloration colorie dans l'ordre les webs ayant un degré d'interférence su-périeur à n (celle ayant un degré inférieur étant coloriable) puis, à degré égal, la web depoids le plus fort en associant une couleur non déjà prise par ses noeuds voisins (i.e. leswebs interférentes). Si une web se trouve non coloriable car toutes les couleurs sont déjàprises par ses voisines, celle-ci est scindée en plusieurs webs. La �gure 3.5 considère unprogramme disposant de deux pages physiques. Dans ce cas, le graphe d'interférence de la�gure 3.5.a n'est pas coloriable mais après avoir scindée la webs 2, il le devient �gure 3.5.b.

��

��

��

Web 1

a

f

e

dc

b

Web 3

Web 2 Web 1 Web 3

Web 2

Web 1

a

f

e

dc

b

Web 3

Web 2.2Web 1 Web 3

Web 2.1 Web 2.2

Web 2.1(pv 1)

(pv 2)

(pv 3)

(pv 1)

(pv 3)

a. Graphe d’interférence b. Graphe d’interférence apres séparation de la web 2

Fig. 3.5 � Graphe d'interférence et coloration

La coloration ajoute un temps de transfert lié à la recopie d'une page virtuelle d'unemplacement de la mémoire physique à un autre. De ce fait, le choix des sommets à séparerest réalisé de la façon suivante. Premièrement, on détermine pour chaque web interférentel'ensemble des sommets en commun avec celle non coloriable. Puis pour chacun de cesensembles, on associe un poids représentant la somme des fréquences des arcs entrantset des arcs sortants de l'ensemble vis-à-vis du GFC (les arcs occasionnant un transfert).Les sommets contenus dans l'ensemble de poids le plus faible sont retirés de la web noncoloriable pour former de nouvelles webs.

La phase de coloration est terminée lorsque toutes les webs sont coloriées. Avec cettecoloration, nous pouvons déterminer le plan de pagination statique. Chaque arc entrantdans une web (au niveau du graphe de �ot de contrôle) représente un point de chargement,de la page virtuelle associée à la web, en mémoire physique à l'emplacement représenté parla couleur. De façon similaire, les points de déchargements se situent au niveau des arcssortants des webs et les transferts sont présents sur les arcs reliant deux webs associées àla même page virtuelle substituant ainsi le chargement et le déchargement de cette page.

Cette approche permet de déterminer l'ensemble des pages virtuelles à conserver enmémoire physique lors de l'exécution et de déterminer leur emplacement dans cette mémoiretout en suivant une heuristique WCET par l'intermédiaire de la fonction de poids.

28


3.2.2 Approche par programmation linéaire en nombres entiers

Dans cette partie, nous allons présenter une approche assimilant le problème de pa-gination statique pour les pages de code à un problème de programmation linéaire ennombres entiers 0-1. Cette approche a déjà été utilisée pour réaliser des allocations sta-tiques à di�érents niveaux de la hiérarchie mémoire : aux niveaux des registres [11] pouroptimiser le temps moyen d'exécution, au niveau des scratchpads [32, 8] pour optimiserla consommation d'énergie et respectivement le WCET. Ces approches ne sont pas direc-tement exploitable pour le cas de la pagination car l'approche traitant de l'allocation deregistres dé�nit une allocation au niveau de chaque fonction et non du programme entier.Les approches traitant des mémoires scratchpads sont également di�érentes car les accèsaux références mémoires sont possibles si la référence est présente dans la mémoire scratch-pad ou dans la mémoire physique, cela n'in�uençant que la latence d'accès. Dans notre cas,les accès directs au disque ne sont pas possibles ce qui implique de charger préalablementen mémoire physique toutes les références mémoire accédées.

Dans cette approche adaptée au cas de la pagination, nous commencerons par pré-senter les di�érentes contraintes permettant de déterminer quelles pages virtuelles sont àconserver en mémoire toujours dans un objectif WCET. Puis, nous verrons deux approchespermettant de déterminer l'emplacement en mémoire physique des pages virtuelles précé-demment sélectionnées. En�n, nous �nirons par une approche algorithmique exploitantcette représentation sous forme de contraintes, celle-ci n'étant pas su�sante pour dé�nirun plan de pagination tenant compte de la variation possible du pire chemin.

3.2.2.1 Détermination des pages à conserver

Contrairement à l'approche par coloration de graphe, dans cette méthode, l'ensemblede départ se limite aux régions de programme référençant les pages virtuelles. Nous dé-�nissons ainsi une web minimale associée à une page virtuelle p comme un ensemble den÷uds connexes du CFG dont tous les n÷uds référencent p, représentant ainsi une régiond'utilisation de p. Plus formellement :

web_minimale(p, S) ⇔

S ⊆ V∧∀i ∈ S, [ p ∈ pagesi

∧∀y ∈ (pred(i) ∪ suc(i)), p ∈ pagesy ⇒ y ∈ S

]

avec pred(x) l'ensemble des prédécesseurs directs de x et suc(x) l'ensemble des suc-cesseurs directs de x. La �gure 3.6 illustre l'ensemble des webs minimales pour une pagevirtuelle p.

Le concept principal de cette approche est d'étendre les régions minimales de présenceen mémoire physique des pages virtuelles par la résolution d'un système de contrainteslinéaires en nombres entiers tout en minimisant l'estimation du WCET.

Avant de rentrer dans l'expression des di�érentes contraintes, nous introduisons un cer-tain nombre de variables et constantes. Par la suite, les constantes du système de contraintessont notées en lettres capitales et les variables en lettres minuscules.

� n est le nombre de pages physiques ;� pv est l'ensemble des pages virtuelles du programme ;� pagesi est l'ensemble des pages virtuelles référencées par le bloc de base i ;

29


a

f

e

dc

b web

web

g

webs minimalespour la page p

p dans PAGES

p dans PAGES

p dans PAGES

b

c

f

Fig. 3.6 � Exemple de webs minimales

� f(i,j) est la fréquence d'exécution de l'arc (i, j) le long d'un pire chemin3 ;� loadCost est le coût au pire cas en cycles nécessaire au chargement d'une pagevirtuelle en mémoire physique ;

� desallocCost est le coût au pire cas en cycles nécessaire à la désallocation mé-moire d'une page virtuelle. Nous prenons le coût d'une désallocation et non d'undéchargement car les pages de code ne nécessitent pas de recopie sur disque ;

� loadp(i,j) est une variable binaire représentant le chargement d'une page virtuelle p le

long de l'arc (i, j).

loadp(i,j) =

1 la page virtuelle p doit être chargée

sur l'arc (i, j)0 sinon

Il y a une variable loadp(i,j) pour chaque n-uplet (i, j, p) avec (i, j) ∈ E et p ∈ pv.

� unloadp(i,j) est une variable binaire représentant le déchargement4 d'une page virtuelle

p le long de l'arc (i, j).

unloadp(i,j) =

1 la page virtuelle p doit être déchargée


De façon similaire aux variables loadp(i,j), il y a une variable unloadp

(i,j) pour chaquen-uplet (i, j, p).

� pvpi est une variable binaire représentant la présence en mémoire physique d'une page

virtuelle p pour le bloc de base i.

pvpi =

1 la page virtuelle p est présente en

mémoire physique0 sinon

Il y a autant de variables pvpi que de n-uplets (i, p) avec i ∈ V et p ∈ pv. Ces variables

sont instanciées lors de la résolution du système a�n de déterminer l'ensemble despages virtuelles à conserver en mémoire physiques pour chacun des blocs de base. Cet

3un des pires chemins d'après la remarque sur le calcul du pire temps d'exécution 1.2.34seul les pages de code sont considérées pour le moment, le déchargement représente dans ce cas une

désallocation mémoire. Cette vision sera revue lorsque nous ajouterons les pages de données.

30


ensemble est di�érent de pagesi qui lui représente l'ensemble des pages nécessaire àl'exécution du bloc de base i.

L'objectif de cette approche étant de réduire le temps lié au mécanisme de paginationle long du pire chemin, la fonction objective à minimiser peut s'exprimer sous la formed'une somme de chacune de ces opérations multipliée par la fréquence sur le pire chemin.∑

(i,j)∈E

∑p∈pv

f(i,j) ∗ (loadCost ∗ loadp(i,j) + desallocCost ∗ unloadp

(i,j))

Ce système nécessite des contraintes supplémentaires a�n d'assurer la cohérence entreles variables. Les deux classes de contraintes sont liées d'une part à la limitation sur lataille de la mémoire physique et d'autre part, à la présence en mémoire physique despages référencées dans ce cas, elles sont nécessairement à charger avant d'être utilisées età décharger après utilisation.

Pour la première classe de contraintes, il faut préciser que le nombre de pages virtuellesprésentes en mémoire physique pour chaque bloc de base du programme est inférieur ouégal au nombre de pages physiques n :

∀i ∈ V ,∑p∈pv

pvpi ≤ n (3.1)

La seconde classe de contraintes doit garantir la présence en mémoire physique despages référencées pour chacun des blocs de base. De ce fait, la variable pvp

i est initialisée à1 pour chacun des blocs de base où la page virtuelle p est référencée.

∀i ∈ V , ∀p ∈ pagesi, pvpi = 1 (3.2)

Le chargement d'une page virtuelle p en mémoire physique sur un arc (i, j) a lieu lorsqueelle est absente au bloc de base i (pvp

i = 0) et qu'elle est présente en mémoire au bloc debase j (pvp

j = 1). Cette condition booléenne peut s'exprimer de la façon suivante :

∀(i, j) ∈ E,∀p ∈ pv

loadp(i,j) ≤ 1− pvp

i

loadp(i,j) ≤ pvp

j

loadp(i,j) ≥ pvp

j − pvpi (3.3)

Réciproquement, le déchargement d'une page virtuelle p sur un arc (i, j) a lieu lorsqueelle est présente en mémoire pour le bloc de base i (pvp

i = 1) et pour le bloc de base j, elleest absente (pvp

j = 0). Cette condition booléenne peut s'exprimer de la façon suivante :

∀(i, j) ∈ E,∀p ∈ pv

unloadp(i,j) ≤ 1− pvp

j

unloadp(i,j) ≤ pvp

i

unloadp(i,j) ≥ pvp

i − pvpj (3.4)

Finalement, pour assurer les chargements initiaux et les déchargements �naux, toutesles pages virtuelles du programme sont considérées comme absentes de la mémoire (i.e.pvp

i = 0) pour les deux n÷uds virtuels first et last.

31


∀p ∈ pv, pvpfirst = 0

∀p ∈ pv, pvplast = 0 (3.5)

Lors de la résolution du système, le solveur de contraintes dé�nit la valeur de chacunedes variables pvp

i tel que ∀i ∈ V, p 6∈ pagesi celles-ci étant non �xées dans l'énoncé descontraintes. En d'autres termes, le solveur calcule les pages virtuelles, non référencées parun bloc de base i mais qui sont les plus intéressantes à conserver en mémoire physiquea�n de minimiser le nombre d'opérations liées au mécanisme de pagination le long dupire chemin. La �gure 3.7 illustre le résultat de la résolution du système de contraintesen considérant les blocs de base a comme first et g comme last. Les variables pvp

d et pvpe

ont été mises à la valeur 1 pour signi�er qu'il faut conserver en mémoire physique la pagevirtuelle p aux blocs de base d et e alors qu'initialement, la page p n'est pas nécessaire àl'exécution de ces deux blocs de base. La solution �xe également la valeur de la variableload pour chaque arc du GFC.

loadp( a,b ) =? loadp

( a,b ) = 1loadp

(b,c ) =? loadp(b,c ) = 0

loadp(b,d ) =? loadp

(b,d ) = 0loadp

( c,e ) =? loadp( c,e ) = 0

loadp(d,e ) =? loadp

(d,e ) = 0loadp

( e,f ) =? loadp( e,f ) = 0

loadp( f,g ) =? loadp

( f,g ) = 0pvp

a = 0 pvpa = 0

pvpb = 1 pvp

b = 1pvp

c = 1 pvpc = 1

pvpd =? pvp

d = 1pvp

e =? pvpe = 1

pvpf = 1 pvp

f = 1pvp

g = 0 pvpg = 0

a

f

e

dc

b

g

p dans PAGES b

p dans PAGES c

p dans PAGES f

Fig. 3.7 � Allocation des pages virtuelles

3.2.2.2 Placement des pages virtuelles en mémoire physique

A la di�érence de la méthode par coloration de graphe, la résolution du système decontraintes dé�nit les zones de présence en mémoire physique de chacune des pages vir-tuelles. Cependant, cette résolution n'assigne pas d'emplacement en mémoire physique pourchacune de ces pages. Dé�nir statiquement l'emplacement en mémoire physique des pagesvirtuelles n'est pas une nécessité en soi, car l'assignement peut être réalisé à l'exécution. Ce-pendant, ce côté dynamique introduit de l'indéterminisme sur les temps d'exécution. Nousproposons de lever cet indéterminisme en dé�nissant statiquement les emplacements despages virtuelles en mémoire physique. Pour ce faire, nous allons voir maintenant deux mé-thodes permettant de réaliser ce placement. La première méthode utilise un autre systèmede contraintes tandis que la seconde reprend l'approche par coloration de graphe.

32


Placement par contraintes linéaires

A�n de réaliser le placement en mémoire physique des pages virtuelles, nous dé�nissonsun second système de contraintes linéaires. Ce système reprend les mêmes notations queprécédemment à la di�érence que les variables instanciées par le premier système deviennentmaintenant des paramètres d'entrées du second. Il faut également ajouter des variables etconstantes supplémentaires. Une variable représentant le contenu de chacune des pagesphysiques phy (phy ∈ {1..n}) pour chacun des blocs de base i et ce pour chaque pagevirtuelle p :

pppi,phy =

1 la page virtuelle p est présente dans

la page physique phy au bloc de base i0 sinon

Il y a une variable pppi,phy pour chaque n-uplet (i, phy, p) tel que i ∈ V , phy ∈ {1..n}

et p ∈ pv. Cette variable permet d'associer un emplacement en mémoire physique pourchacune des pages virtuelles déterminées comme devant être présentes.

Nous ajoutons également une variable transfertp(i,j) représentant le transfert de la pagevirtuelle p d'un emplacement de la mémoire physique à un autre :

transfertp(i,j) =

1 la page virtuelle p est transférée

le long de l'arc (i, j)0 sinon

Et �nalement, la constante transfertCost représentant le coût en cycles au pire caspour réaliser le transfert d'une page virtuelle d'un emplacement de la mémoire physique àun autre.

L'objectif de ce second système est d'associer un emplacement en mémoire physique àchaque page virtuelle devant être présente en mémoire (i.e. pvp

i = 1) tout en minimisantle nombre de transferts mémoire le long du pire chemin. La fonction objective peut s'ex-primer sous la forme d'une somme du coût de chaque transfert mémoire en considérant lesfréquences sur un pire chemin :∑

(i,j)∈E

∑p∈pv

f(i,j) ∗ transfertCost ∗ transfertp(i,j)

Cette fonction objective ne permet que de réduire, voire au mieux d'annuler les tempsde transfert, le pire temps ainsi que le pire chemin étant quasiment �xés par les chargementsdéterminés par le premier système de contraintes linéaires.

Pour réaliser ce placement, il est nécessaire d'ajouter certaines contraintes a�n de ga-rantir que chaque page virtuelle dispose bien d'un emplacement en mémoire physique(contrainte 3.6) et que chacune des pages physiques contient au plus une page virtuellepour un bloc de base donné (contrainte 3.7).

∀i ∈ V,∀p ∈ pv,

n∑phy=1

pppi,phy = pvp

i (3.6)

∀i ∈ V,∀phy ∈ {1..n},∑p∈pv

pppi,phy ≤ 1 (3.7)

33


En�n, un transfert mémoire sur un arc (i, j) a lieu lorsqu'une page virtuelle p estprésente en mémoire physique pour les blocs de base i et j (i.e. pvp

i = 1 ∧ pvpj = 1) et que

la page physique contenant p en i est di�érente de celle contenant p en j.Pour formuler cette contrainte, nous introduisons une variable diffp

(i,j),phy représentant

la di�érence entre les deux variables pppi,phy et ppp

j,phy. Celle-ci marque la di�érence decontenu de la page physique phy aux deux blocs de base i et j pour la page virtuelle p.

diffp(i,j),phy =

1 les valeurs de ppp

i,phy etppp

j,phy sont di�érents0 sinon

sous la contrainte suivante représentant un ou exclusif :

∀(i, j) ∈ E,∀p ∈ pv,∀phy ∈ {1..n},ppp

i,phy + pppj,phy ≥ diffp

(i,j),phy

pppj,phy + diffp

(i,j),phy ≥ pppi,phy

pppi,phy + diffp

(i,j),phy ≥ pppj,phy

pppi,phy + ppp

j,phy + diffp(i,j),phy ≤ 2 (3.8)

Finalement, un transfert d'une page virtuelle p entre deux emplacements de la mémoirephysique peut se formuler ainsi :

transfertp(i,j) ≤ pvpi

transfertp(i,j) ≤ pvpj

transfertp(i,j) ≤n∑

phy=1

diffp(i,j),phy

transfert(i,j) ≥ pvpi + pvp

j + (n∑

phy=1

diffp(i,j),phy)− 3 (3.9)

Cette formulation par contraintes linéaires permet de réduire au minimum le nombrede transferts mémoire le long du pire chemin en associant un emplacement en mémoirephysique pour chaque page virtuelle présente et pour chacun des blocs de base.

Placement par coloration

Le placement des pages virtuelles en mémoire physique peut se résoudre par une ap-proche de coloration de graphe en reprenant la phase de coloration de la méthode présentéeen 3.2.1.2.

En remplaçant l'ensemble pagesi par l'ensemble des pages virtuelles présentes en mé-moire pour chaque bloc de base, celles déterminées par le système de contraintes linéaires,nous construisons un ensemble de webs sur le principe des webs minimales. Cet ensemblesert ainsi de point de départ à la phase de coloration. D'après la contrainte 3.1 du système,chacun des blocs de base du programme dispose d'au plus n pages virtuelles en mémoireet donc chaque bloc de base est contenu par au plus n webs. Ainsi, l'hypothèse nécessairepour assurer la faisabilité de la coloration est satisfaite.

Cette seconde approche permet de réaliser un placement en mémoire physique des pagesvirtuelles en suivant une heuristique WCET. De ce fait, elle permet également de limiterle nombre de transferts mémoire sur le pire chemin.

34


3.2.2.3 Algorithmique

Dans cette partie, nous allons détailler l'approche algorithmique exploitant le systèmede contraintes au travers de deux algorithmes. Le premier consiste à résoudre le système decontraintes puis à déterminer le plan de pagination en considérant le pire chemin commeconstant pendant tout le processus. Cependant, cette considération est fausse dans le casgénéral. En e�et, les programmes peuvent être composés de chemins d'exécutions multiples.Dans ce cas, faire des choix a�n de réduire la borne supérieure du WCET peut amener àune variation du pire chemin [37] et rendre alors un plan de pagination ne favorisant pasce dernier. Dans notre cas, le simple fait d'allouer certaines pages virtuelles est susceptiblede faire varier le pire chemin. Pour pallier ce phénomène, nous présenterons ensuite uneapproche itérative tenant compte de cette variation.

Résolution en une étape

Ce premier algorithme considère les fréquences des blocs de base et des arcs sur le pirechemin comme constantes. Le système de contraintes est résolu et le solveur détermineles pages virtuelles référencées ainsi que les plus intéressantes à conserver en mémoirephysique. Avec ces informations, il est ensuite possible de déterminer l'emplacement despages virtuelles en mémoire physique en utilisant l'une des deux méthodes précédentes, cequi permet de �naliser l'élaboration du plan de pagination.

Résolution itérative

La principale limitation de l'algorithme précédent est de considérer le pire chemincomme constant pendant toute la résolution. Cependant, pour trouver un plan de pa-gination optimal, il serait nécessaire d'évaluer l'ensemble de tous les plans de paginationpossibles. Or, une évaluation exhaustive serait trop coûteuse en temps de calcul étantdonné la combinatoire. Nous nous sommes portés sur une heuristique gloutonne utilisantun processus d'allocation itératif.

Notre approche itérative consiste à résoudre à chaque itération le système de contraintespuis, à choisir de façon dé�nitive (gloutonne) une partie des pages virtuelles à allouer enmémoire physique et à réévaluer le WCET avec une allocation tenant compte des choixréalisés.

L'heuristique se situe donc au niveau du choix des pages virtuelles à conserver. Pource faire, nous construisons, sur le principe des webs minimales, deux ensembles de webs àchaque itération. Le premier ensemble noté PRE est construit à partir des pages virtuellesprésentes dans pagesi. Le second noté POST est construit à partir des pages virtuelles,déterminées par le système de contraintes, comme présentes en mémoire.

A partie de ces deux ensembles, nous déterminons les webs étendues à l'itération cou-rante par la di�érence POST \ PRE (i.e. l'ensemble des webs non présentes dans lesparamètres de l'itération).

Nous associons un poids (avec la fonction de poids présentée en 3.2.1.1) à chacune deswebs appartenant à cet ensemble résultant (POST \ PRE). Il reste ensuite à sélectionnerla web disposant du poids le plus important et d'ajouter à chacun des sommets i présentsdans cette web la page virtuelle associée dans l'ensemble pagesi. Le fait d'ajouter des pagesvirtuelles dans cet ensemble permet de �xer pour les itérations suivantes, les pages sélec-tionnées à l'itération courante comme devant impérativement être présentes en mémoire.Ce processus itératif se termine lorsque la di�érence entre l'ensemble POST et PRE estvide.

35


La �gure 3.8 illustre cette procédure pour un programme contenant trois pages virtuelleset s'exécutant avec deux pages physiques. L'initialisation est faite avec les webs minimalesde chacune des pages virtuelles (schéma a). La première itération détermine, parmi leswebs non présentes initialement (POST \ PRE) soit les webs en pointillées du schémab, la web la plus intéressante à conserver en mémoire en l'occurence la web associée à lapage 2 (schéma c). L'ensemble, avant l'itération, enrichi de cette web devient l'ensemble dedépart de l'itération suivante.

a

e

c

a

f

e

dc

b

f

d

b

e

c

a

f

d

b

pv 1pv 2pv 3

Légende

a. Paramètre de la 1ere itération c. Paramètre de la 2eme itérationb. Sélection d’une web

résolution PLNE

sélection

évaluationWCET

+

web 1.1

web 2.1

web 2.2

web 3

web 1.2

web 3web 2

web 1.1

web 2

web 3

web 1.2

web 1

Fig. 3.8 � Allocation itérative

Cette approche itérative prend en compte la variation du pire chemin en le réévaluant defaçon régulière pendant le processus d'allocation en mémoire physique des pages virtuelles.Une fois le processus terminé, nous pouvons déterminer le placement en mémoire physiquede chacune des pages virtuelles comme précédemment.

3.3 Pagination des pages de données

Dans cette partie, nous allons étendre notre approche a�n de prendre en compte lespages de données des programmes. La prise en compte des pages des données nécessitede connaître statiquement l'ensemble des données potentiellement référencées par chaqueinstruction. Dans le cas des pages de code, chaque instruction est associée à une adressemémoire s'obtenant par lecture du �chier binaire. Par contre, pour les données, une mêmeinstruction peut référencer di�érentes données lors de ses di�érentes exécutions et donc ac-céder à di�érentes adresses mémoire. C'est le cas, par exemple, lors de l'accès aux élémentsd'un tableau dans une boucle où l'élément référencé est fonction de l'itération courante.L'accès aux données peut également être dépendant des données d'entrées du programmeou encore lié à l'utilisation de pointeurs. De plus, pour les données, les opérations de pa-gination sont di�érentes suivant que les accès sont des lectures ou des écritures et que lesdonnées sont initialisées ou non.

A�n de travailler sur la pagination des pages de données, nous avons réalisé un outil per-mettant d'analyser statiquement l'ensemble des adresses référencées en imposant certainespropriétés sur les programmes que nous présenterons dans un premier temps. Ensuite, nousétendrons le système de contraintes linéaires a�n de considérer les pages de données dansl'établissement d'un plan de pagination et en�n, nous verrons les possibilités d'extensionde l'approche par coloration de graphe vis-à-vis des pages de données.

36


3.3.1 Analyse d'adresses

Dans cette partie, nous présentons un outil permettant l'analyse statique des adressesde données d'un programme a�n d'étendre notre étude à la pagination des pages de don-nées. Notre analyse supporte tous les types d'accès aux données (globaux et locaux) sauf lesdonnées dynamiques utilisant les pointeurs. Elle détermine l'ensemble, éventuellement unsur-ensemble, des pages virtuelles manipulées par chacun des blocs de base a�n de garantirla sûreté de l'analyse. Elle est également non contextuelle, c'est à dire indépendante des va-riables d'induction de boucles et des di�érents contextes d'appels des fonctions. Ainsi, dansle cas d'un accès à l'élément d'un tableau, nous considérons l'intervalle d'adresse contenantle tableau comme devant être présent en mémoire physique. De même, pour les accès àla pile, nous considérons l'ensemble des frames lié aux di�érents contextes d'appels d'unefonction comme devant être en mémoire. La granularité de l'analyse est donc gros grainpour les accès tableaux et les accès piles tandis qu'elle est �ne pour les données scalairesglobales. Ces considérations permettent une rapidité de l'analyse d'adresses cependant,elles peuvent amener à surestimer les besoins mémoire. Pour les tableaux par exemple, lesaccès réguliers sont prévisibles et les chargements/déchargements peuvent avoir lieu à desitérations déterminées. Par contre, pour les accès irréguliers ou dépendants des données, ilfaut considérer un chargement/déchargement à chaque accès (hypothèse pire cas) si l'in-tégralité du tableau n'est pas présent en mémoire. Finalement, nous considérons, dans unpremier temps, des programmes n'utilisant pas de pointeurs a�n de simpli�er l'analyse auxseuls accès directs sans prendre en compte les indirections. L'analyse de pointeurs est déjàun sujet d'étude en soi.

Di�érentes approches ont déjà été proposées a�n d'analyser les adresses des données.Dans [8], il extrait les informations relatives à l'analyse d'adresses e�ectuée au sein d'uncompilateur tandis que dans [35], l'analyse est e�ectuée par une analyse du �ot de donnéesdu �chier binaire (plus précisément du binaire désassemblé). Dans notre analyse, nous noussommes orientés vers cette seconde approche en analysant le contenu des registres avantet après chaque instruction. Contrairement au développement dans un compilateur, cetteapproche permet d'être indépendante de la version et du compilateur utilisé en o�rant unevision générique du concept bien que dépendant de certaines spéci�cités de l'architecturecible.

L'analyseur d'adresses que nous allons présenter maintenant est développé pour desbinaires générés pour une architecture MIPS. Nous commençons par étudier l'organisationde la mémoire virtuelle et les spéci�cités de cette architecture puis, nous verrons l'analysedes accès à la pile ainsi qu'aux variables globales.

3.3.1.1 Organisation mémoire et architecture MIPS

L'organisation de la mémoire virtuelle est générique quelque soit l'architecture cible.Elle est composée de di�érentes zones dans l'espace mémoire contenant respectivement lecode (.text), les données et la pile. La zone contenant les données est divisée en plusieursparties distinctes contenant notamment les données initialisées (.data), les données noninitialisées (.bss) et les données accédées uniquement en lecture (.rodata). La �gure 3.9illustre cette division en di�érentes zones. Les adresses de début de chaque section ainsique leur taille sont accessibles par la table des symboles présente dans le �chier binaire.Cette table permet également de connaître les adresses et tailles des données statiques duprogramme.

Du côté de l'architecture MIPS, elle utilise un certain nombre de registres (32 registres

37


$gp

.bss

pile

$sp

.data

.text

.rodata

Adresse basse

Adresse haute

Fig. 3.9 � Organisation de la mémoire virtuelle

entiers et 32 registres �ottants) dont deux registres spéci�ques $gp et $sp. $gp est unregistre dont la valeur pointe vers une adresse de la zone réservée aux données globalespermettant ainsi de faire un accès aux données avec un décalage relatif par rapport à celui-ci. La valeur du registre $gp est �xée et est connue statiquement (présent dans la tabledes symboles). Le registre $sp est un pointeur vers le haut de la zone de pile. Sa valeurinitiale est égale à la plus grande adresse de l'espace virtuel et donc connue statiquement.Evidemment, cette valeur est modi�ée lors de l'exécution en fonction des réservations deslocaux et des appels de fonctions. L'accès à la pile se fait également de façon relative parrapport à $sp. La spéci�cation complète de l'architecture est détaillée dans l'ApplicationBinary Interface MIPS [1].

3.3.1.2 Analyse des accès à la pile

Cette analyse détermine les accès à la pile en ayant une granularité se limitant auxframes des fonctions. L'utilisation de la zone de pile est relativement simple pour l'archi-tecture MIPS. Les premières instructions d'une fonction réservent la frame de la pile enmodi�ant la valeur du registre $sp. Cette frame contient les variables locales de la fonction,la sauvegarde de certaines valeurs (l'adresse de retour de la fonction par exemple) ainsi queles paramètres transmis aux fonctions appelées comme l'illustre la �gure 3.10. Les dernièresinstructions d'une fonction réalisent de façon similaire la libération de la frame. Le corpsde la fonction ne modi�e pas la taille de la frame mais réalise uniquement des accès enlecture et en écriture à sa frame et à la zone de ses paramètres contenue dans la frame del'appelant.

Cette gestion de la pile est relativement simple à analyser au niveau des frames. En e�et,la taille de la frame de chacune des fonctions peut être déterminée par sa première instruc-tion. Par exemple, le code assembleur addiu $sp,$sp,-8 e�ectue une réservation de 8octets dans la pile. De plus, l'accès à un élément de la pile est généralement5 réalisé par undécalage relatif par rapport à $sp. Par exemple, le code assembleur lw $v0,10($sp) ef-fectue un accès en lecture au premier paramètre de la frame de l'appelant. Il est ainsipossible de déterminer le décalage maximum par rapport à $sp et donc de connaître lenombre d'éléments accédés dans la frame de l'appelant (l'accès aux paramètres de la fonc-tions). De ce fait, pour chacune des fonctions, nous sommes en mesure de déterminer lataille et donc l'intervalle d'adresses de la frame. Il reste à déterminer l'adresse de début de

5le cas où la valeur de $sp est a�ectée dans un registre sera traité par l'analyse de �ot de données

38


Adresse haute

Frameappelant+16

old $sp +0

locaux

zone de sauvegardedes registres

Framefonction courante

paramètresde l’appelé$sp +0 Adresse basse

paramètresde l’appelé

zone de sauvegardedes registres

locaux

Zone accédée parla fonction courante

Fig. 3.10 � Organisation d'une frame

la frame, c'est à dire l'ensemble des valeurs de $sp (une valeur par contexte distinct) pourchacune des fonctions.

Le graphe d'appel des fonctions est considéré connu statiquement et sans cycle (hy-pothèses liées au cadre temps-réel), le nombre de valeurs possibles pour $sp est donc �ni.Pour un appelant donné d'une fonction f , l'ensemble des valeurs de $sp de f est égal àl'ensemble des valeurs de $sp de l'appelant auquel on ajoute pour chaque valeur la taillede la frame de f . L'union de chacun des ensembles obtenus pour chaque appelant est doncl'ensemble des valeurs possibles de $sp pour la fonction f . L'ensemble des valeurs de $sppour chacune des fonctions peut être déterminé par une itération point �xe avec commeensemble de départ pour chaque fonction l'ensemble vide excepté pour la fonction main duprogramme qui contient la valeur initiale de $sp.

3.3.1.3 Analyse du �ot de données pour les accès aux données statiques

Déterminer statiquement l'accès aux données statiques pour chacun des blocs de basedu programme est quelque peu di�érent par rapport aux accès pile. L'adresse de la donnéeaccédée est calculée en plusieurs étapes successives di�érentes suivant les cas.

L'accès à une donnée de type scalaire s'e�ectue directement avec un simple décalagepar rapport à $gp comme le montre la partie gauche du tableau 3.1.

L'accès à l'élément d'un tableau par contre, nécessite un calcul d'adresse réalisé avantl'accès lui même. L'adresse est calculée par plusieurs instructions utilisant au moins unregistre contenant à la �n du calcul l'adresse accédée. La partie droite du tableau 3.1montre un exemple pour ce type d'accès.

Accès scalaire Accès tableaulw $v0,-32736($gp) lui $v1,0x44

addiu $v1,$v1,544

lw $a0,0($v1)

Tab. 3.1 � Code assembleur pour les accès aux données

Il est donc nécessaire de déterminer le contenu de chacun des registres avant et aprèschaque instruction a�n de pouvoir calculer les adresses référencées par chacun des blocs debase.

Nous cherchons donc à déterminer les valeurs possibles du contenu des registres utiliséeslors d'un accès mémoire. Les valeurs cherchées sont RPe(inst) pour le contenu des registres

39


en entrée de l'instruction inst et RPs(inst) le contenu des registres en sortie de cetteinstruction. Ces deux ensembles appartiennent à Reg x V al a�n d'associer à chaque registre(∈ Reg) une valeur (∈ V al) avec V al l'ensemble des valeurs possibles enrichi de ⊥ signi�antune valeur non dé�nie (par exemple dans le cas où le registre n'a pas été a�ecté lors d'uneinstruction précédente) et > signi�ant l'ensemble des valeurs possibles dans le cas d'unchargement à partir de la mémoire, celle-ci n'étant pas analysée.

Nous limitons cette analyse à une analyse intra bloc de base. De ce fait, l'état desregistres en sortie d'une instruction devient l'état d'entrée de l'instruction suivante. Nousinitialisons l'état d'entrée de la première instruction de chaque bloc de base à ⊥ pourchacun des registres, excepté pour les registres $gp et $sp qui contiennent leur propre nompour simpli�er l'analyse des accès mémoires une fois l'analyse de �ot de données e�ectuée.$sp prendra alors l'ensemble des valeurs déterminé par l'analyse de pile.

L'analyse s'e�ectue en avant avec les équations de �ot suivante :

RPe(inst) =

RPs(inst′) avec inst′ l'instruction précédente

du bloc de base si elle existe{(r,⊥) | r ∈ (Reg \ {gp, sp})} ∪ {(gp, gp), (sp, sp)} sinon

RPs(inst) = (RPe(inst) \ kill(inst)) ∪ gen(inst)

avec gen(inst) l'ensemble des couples (r, v) des valeurs a�ectées aux registres par l'ins-truction inst et kill(inst) l'ensemble des couples (r, v) des registres modi�és par l'instruc-tion.

Le nombre d'instructions di�érentes étant important, nous présentons les équations degen et kill pour trois types d'instructions représentant respectivement le chargement d'unevaleur dans un registre, la non modi�cation du contenu des registres ainsi que le calcul desadresses.

Commençons par l'instruction load $r, v. Celle-ci charge dans un registre r une valeurv. La valeur v peut être une constante ou une valeur contenue dans une adresse mémoire.Le contenu du registre, après l'instruction, contient donc soit la valeur de la constante, soit> dans le cas d'un accès mémoire.

gen(load $r, v) ={

{(r, v)} si v est une constante{(r,>)} si v est une adresse mémoire

kill(load $r, v) = {(r, x) | x ∈ V al}

L'instruction store $r, @mem charge la valeur contenu dans le registre r à l'adressemémoire @mem. Cette instruction ne modi�e pas le contenu des registres donc leur étatdemeure inchangé.

gen(store $r, @mem) = ∅kill(store $r, @mem) = ∅

L'instruction add $r1, $r2, v réalise l'addition [r2] + v et a�ecte le résultat dans leregistre $r1. La valeur v peut être soit une valeur contenue dans un registre, soit uneconstante.

40


gen(add $r1, $r2, v) =

{(r1, v)} si r2 = > et v est une constante ou

un registre contenant la valeur v{(r1,⊥)} si r2 = ⊥ ou v est un registre contenant ⊥

{(r1, [r2] + v)} sinon

kill(add $r1, $r2, v) = {(r1, x) | x ∈ V al}

Une fois le contenu des registres déterminé par cette analyse, nous sommes en mesurede déduire les variables accédées par chacun des accès mémoire des instructions load etstore en fonction de l'adresse contenue dans le registre de référence de l'instruction. Cetteadresse référence une entrée de la table des symboles, nous permettant donc de déduireles pages référencées (les pages contenant la variable) pour chacun des blocs de base duprogramme. Dans le cas où la valeur du registre est à > ou à ⊥ l'analyse d'adresse n'est pasvalide. Cette situation peut arriver dans le cas de programmes ne respectant pas l'ensembledes restrictions mentionnées précédemment (utilisation de pointeurs par exemple).

3.3.2 Pagination des pages de données par contraintes linéaires

Nous allons maintenant étendre le système de contraintes traitant des pages de code a�nde prendre en compte les pages de données des programmes. Leur prise en compte nécessitel'introduction de nouvelles variables et constantes a�n de gérer leurs particularités. Ene�et, la gestion de toutes les pages de code est identique. La page est à charger en mémoireà partir du disque et à désallouer après utilisation. Dans le cas des pages de donnéespar contre, il faut di�érencier les chargements qui sont soit des chargements à partir dudisque (données initialisées ou données présentes dans la zone de swap), soit des allocations(données non-initialisées et pile lors du premier accès). De façon similaire, les déchargementssont soit des réécritures sur disque (données accédées en écriture et utilisées dans la suitedu programme), soit des désallocations (données accédées uniquement en lecture ou plusutilisées dans la suite du programme).

Nous allons maintenant traiter le cas des chargements et des déchargements des pagesde données en reprenant les notations du système de contraintes linéaires précédent. Cetteextension du système tient également compte des pages de code, il permet ainsi de dé�nirun plan de pagination pour l'ensemble des pages virtuelles du programme. Comme pré-cédemment, les constantes du système sont notées en lettres capitales et les variables enlettres minuscules.

Réécriture sur disque

A�n de formuler la contrainte représentant le fait qu'une page de données peut êtreà réécrire sur disque, nous introduisons des variables et constantes supplémentaires ausystème de contraintes :

� writeCost est une constante représentant le coût en cycles au pire cas d'une ré-écriture sur disque ;

� pages_writei est l'ensemble des pages virtuelles accédées en écriture par le blocde base i (pages_writei ⊂ pagesi) ;

� datapv est l'ensemble des pages virtuelles de données du programme (datapv ⊂pv) ;

41


� deadp(i,j) est une variable binaire marquant le fait qu'une page virtuelle p n'est pas

référencée après l'arc (i, j). Cette variable intermédiaire permet d'éviter la recopiesur disque des pages virtuelles non référencées dans la suite du programe.

deadp(i,j) =

1 la page virtuelle p n'est pas

référencée après l'arc (i, j)0 sinon

� writepi est une variable binaire marquant le fait qu'une page virtuelle p a été accédée

en écriture depuis sont chargement en mémoire par au moins un des chemins menantau bloc de base i. Cette variable intermédiaire permet d'éviter la recopie sur disquedes pages virtuelles accédées uniquement en lecture.

writepi =

{1 la page virtuelle p est accédée en écriture0 sinon

� unloadwp(i,j) est une variable binaire représentant le déchargement en écriture de la

page virtuelle p sur l'arc (i, j).

unloadwp(i,j) =

1 la page virtuelle p est réécrite sur disque


� desallocp(i,j) est une variable binaire représentant la désallocation de la page virtuelle

p sur l'arc (i, j).

desallocp(i,j) =

1 la page virtuelle p est désallouée


� unloadp(i,j) est la variable binaire du système de contraintes traitant des pages de code

et modélisant un déchargement. Cette variable représente un déchargement génériquepouvant être soit un déchargement en écriture, soit une désallocation.

∀(i, j) ∈ E,∀p ∈ pv, unloadp(i,j) = unloadwp

(i,j) + desallocp(i,j) (3.10)

A�n de garantir la cohérence vis-à-vis de ces variables, il est nécessaire d'ajouter uncertain nombre de contraintes au système. Tout d'abord, la variable writep

j doit être à lavaleur 1 si au moins un des prédécesseurs de j noté i a la valeur de writep

i égal à 1 et qu'iln'y a pas de déchargement sur l'arc (i, j) de la page p.

∀(i, j) ∈ E,∀p ∈ pv,

writepj ≥ writep

i − unloadp(i,j)

writepj ≤

∑i∈pred(j)

writepi + α (3.11)

avec α égal à 1 si la page virtuelle p est accédée en écriture par le bloc de base j et égalà 0 sinon. De plus, il faut initialiser cette variable pour chacun des blocs de base et pourchaque page virtuelle accédée en écriture :

∀i ∈ V,∀p ∈ pages_writei, writepi = 1 (3.12)

42


Pour la variable deadp(i,j) nous cherchons à remonter le GFC pour propager le fait que

la page virtuelle p n'est plus référencée. Une page virtuelle p n'est pas référencée après unbloc de base i si aucun de ses successeurs ne référence la page virtuelle p et si elle n'est pasutilisée après chacun des successeurs.

∀(i, j) ∈ E,∀p ∈ pv,

deadp(i,j) ≥ (

∑k∈succ(j)

deadp(j,k)) + (1− pvp

j )− | succ(j) |

deadp(i,j) ≤ 1− pvp

j

deadp(i,j) ≤ deadp

(j,k),∀k ∈ succ(j) (3.13)

Il faut également initialiser, pour chacune des pages de données du programme, la valeurde la variable dead à 1 pour tous les arcs menant au n÷ud virtuel last et à 0 sinon :

∀(i, last) ∈ E, ∀p ∈ datapv, deadp(i,last) = 1

∀(i, last) ∈ E, ∀p 6∈ datapv, deadp(i,last) = 0 (3.14)

Une réécriture sur disque d'une page virtuelle a lieu sur un arc (i, j) lorsque la pagevirtuelle est à décharger, qu'elle a été accédée en écriture depuis son chargement en mémoireet qu'elle est référencée par l'un des successeurs transitifs de i :

∀(i, j) ∈ E,∀p ∈ pv,

unloadwp(i,j) ≥ unloadp

(i,j) + writepi + (1− deadp

(i,j))− 2

unloadwp(i,j) ≤ unloadp

(i,j)

unloadwp(i,j) ≤ writep

i

unloadwp(i,j) ≤ 1− deadp

(i,j) (3.15)

Finalement, la désallocation d'une page virtuelle a lieu sur un arc (i, j) lorsque la pagevirtuelle est à décharger et qu'elle n'est pas à réécrire sur disque. Cette condition estréalisée par la contrainte 3.10 précisant qu'un déchargement est soit une réécriture, soitune désallocation. Les pages de code du programme sont toujours dans ce cas.

Cet ensemble de contraintes permet de traiter le cas des réécritures sur disque pour lespages virtuelles accédées en écriture et le cas des désallocations pour les pages virtuellesaccédées uniquement en lecture ou celles qui ne sont plus référencées dans la suite duprogramme.

Allocation du premier accès

Comme énoncé précédemment, le chargement initial d'une page de données contenantuniquement des données non initialisées ou une page de pile nécessite uniquement une allo-cation de la page en mémoire physique car aucune donnée n'est à charger à partir du disque.Pour prendre en compte cette condition, nous introduisons des variables supplémentairesau système de contraintes.

� pvnoinit est l'ensemble des pages virtuelles des pages de pile et des pages de donnéesnon initialisées du programme (pvnoinit ⊆ datapv ⊂ pv) ;

43


� allocCost est une constante représentant le coût en cycles au pire cas d'une allo-cation en mémoire physique ;

� defp(i,j) est une variable binaire représentant le fait que la page virtuelle p n'a pas

encore été référencée sur l'ensemble de tous les chemins menant à i et qu'elle n'estpas référencée par le bloc de base i. Cette variable intermédiaire permet d'éviter lechargement à partir du disque des pages virtuelles non initialisées et accédées pour lapremière fois. Cette variable permet de di�érencier les di�érents cas de chargementsliés aux chemins multiples menant au bloc de base j. Par exemple, dans le cas où jest le point d'entrée d'une fonction disposant de contextes d'appels multiples.

defp(i,j) =

1 la page virtuelle p n'a pas été référencée

sur l'ensemble des chemins menantau bloc de base i ainsi qu'en i

0 sinon

� allocp(i,j) est une variable binaire représentant une allocation de la page virtuelle p

sur l'arc (i, j).

allocp(i,j) =

1 la page virtuelle p est allouée


� loadfdp(i,j) est une variable binaire représentant un chargement à partir du disque de

la page virtuelle p sur l'arc (i, j).

loadfdp(i,j) =

1 la page virtuelle p est chargée à partir

du disque sur l'arc (i, j)0 sinon

A�n de garantir la cohérence vis-à-vis de ces variables, il est nécessaire d'ajouter uncertain nombre de contraintes au système.

Pour la variable defp(i,j) nous cherchons à descendre le GFC pour propager le fait que

la page virtuelle p n'est pas encore référencée. Une page virtuelle p n'est pas référencéeavant un bloc de base i si aucun de ces prédécesseurs ne référence la page virtuelle p etqu'elle n'est pas utilisée avant chacun des prédécesseurs.

∀(i, j) ∈ E,∀p ∈ pv,

defp(i,j) ≥ (

∑k∈pred(i)

defp(k,i)) + (1− pvp

i )− | pred(i) |

defp(i,j) ≤ 1− pvp

i

defp(i,j) ≤ defp

(k,i),∀k ∈ pred(i) (3.16)

De plus, il faut initialiser pour chacune des pages de données non initialisées du pro-gramme, la valeur de la variable def à 1 pour tous les arcs sortant du n÷ud virtuel firstet à 0 sinon :

∀(first, j) ∈ E, ∀p ∈ pvnoinit, defp(first,j) = 1

∀(first, j) ∈ E, ∀p 6∈ pvnoinit, defp(first,j) = 0 (3.17)

44


L'allocation en mémoire d'une page virtuelle p a lieu sur un arc (i, j) lorsque la pagevirtuelle est à placer en mémoire, qu'elle appartient aux pages de données non initialiséeset que le programme réalise le premier accès à celle-ci :

∀(i, j) ∈ E,∀p ∈ pv,

allocp(i,j) ≥ loadp

(i,j) + defp(i,j) − 1

allocp(i,j) ≤ loadp

(i,j)

allocp(i,j) ≤ defp

(i,j) (3.18)

Finalement, un chargement a lieu lorsque la page virtuelle est à placer en mémoire etque celle-ci n'appartient pas aux pages de données non initialisées ou que la page a déjà étéaccédée. En d'autres termes, la page virtuelle est chargée lorsque qu'il n'y a pas d'allocationmais que celle-ci doit être placée en mémoire physique. Les pages de code du programmesont toujours dans ce cas.

∀(i, j) ∈ E, ∀p ∈ pv, loadfdp(i,j) = loadp

(i,j) − allocp(i,j) (3.19)

Cet ensemble de contraintes permet de traiter le cas des allocations en mémoire physiquede certaines pages virtuelles. Cette allocation est moins coûteuse en nombre de cycles parrapport à un chargement à partir du disque.

Fonction objective

Finalement, pour prendre en compte l'ensemble des possibilités liées à la prise en comptedes pages de code et des di�érents types de pages de données la fonction objective àminimiser dans notre approche devient la suivante :

∑(i,j)∈E

∑p∈pv

f(i,j)∗ ( loadCost ∗ loadfdp(i,j) + allocCost ∗ allocp

(i,j)

+ writeCost ∗ unloadwp(i,j) + desallocCost ∗ desallocp

(i,j) )

représentant la somme de chacun des mécanismes liés à la pagination en fonction de lafréquence sur le pire chemin de chacun d'eux.

L'ensemble de ce système de contraintes permet ainsi d'obtenir un plan de paginationorienté WCET traitant les pages de code, les pages de données initialisées, non initialiséesainsi que les pages de pile. En ce qui concerne les pages de pile, le fait de considérer,l'ensemble des pages de pile liées à tous les contextes d'appels possibles des fonctions,engendre un nombre de pages physiques nécessaires plus important. Suivant le contexted'appel, l'ensemble des frames considérées peut appartenir en partie à l'appelant dansun contexte et appartenir totalement à l'appelé dans un autre contexte ce qui engendredes traitements di�érents. Les opérations dé�nies par le système de contraintes sur lespages de pile sont contextuelles. En e�et, les variables def et dead associées aux arcsdu GFC permettent, en fonction de chaque chemin possible et donc de chaque contexte,d'associer soit une allocation, soit un chargement à partir du disque et respectivement soitune désallocation, soit une réécriture sur disque.

45


3.3.3 Approche par coloration de graphe

Pour étendre l'approche par coloration de graphe, présentée pour les pages de code, ilfaut modi�er l'heuristique sur le choix des webs à conserver en modi�ant la fonction depoids associée aux webs. Cette fonction doit prendre en compte le type d'accès réalisé parles n÷uds contenus dans la web sur la page virtuelle associée. Nous associons un poidsplus important à une web accédant à la page virtuelle en écriture car dans ce cas, ledéchargement de la page associée provoquera une recopie sur disque. Cette fonction peutêtre formulée ainsi :

Poids(web) = β ∗∑

i∈web|p∈pagesi

frequence(i)

avec la valeur de β égale à 2 si la page pv est accédée en écriture par au moins un desn÷uds de la web et égale à 1 si tous les accès sont des lectures.

Cette formulation permet de di�érencier les pages accédées en lecture des pages accédéesen écriture. Cependant, pour di�érencier les di�érents types de pages de données a�n deréaliser une allocation ou un chargement sur le premier accès et un déchargement sur disqueou une désallocation, cette approche présente certaines limites.

En e�et, il est possible de déterminer de façon similaire aux variables def et dead (dusystème de contraintes précédent) le premier accès à une page de données non-initialiséeou de pile et le dernier accès aux pages de données. Cependant, prendre en compte cesinformations dans l'heuristique s'avère plus di�cile. La di�culté provient du fait d'associerun poids à chacune des webs. Si on associe un poids di�érent aux webs ayant un premieraccès aux pages de données non initialisées ou de pile comparativement aux poids desautres webs, deux cas sont possibles :

� un poids plus faible, la web se trouve alors privilégiée pour être scindée. Cependant,celle-ci peut tout de même avoir un impact important sur le WCET et le fait de lascinder ajoute dans ce cas un nombre de chargements important sur le pire cheminpour chacune des webs résultantes ;

� un poids plus fort, la page virtuelle associée à la web est privilégiée pour être conservéeen mémoire physique. Cependant, celle-ci peut n'avoir qu'un faible impact sur leWCET et son poids important force les webs ayant un impact plus important à êtrescindées ce qui provoque également un nombre de chargements important sur le pirechemin.

Un raisonnement similaire peut être conduit pour les derniers accès aux pages de don-nées. Cette di�culté limite donc la possibilité de prendre en compte les di�érentes phasesd'accès aux pages de données (premier accès, accès intermédiaire et dernier accès) dansl'approche par coloration. Nous faisons le choix de ne pas di�érencier les types d'accès auxpages de données dans la fonction de poids. Ce choix dé�nit une heuristique moins précisecomparativement au système de contraintes mais évite de prendre des décisions menant àune augmentation du nombre d'opérations liées à la pagination sur le pire chemin.

46

Chapitre 4

Expérimentations

Après avoir présenté nos approches permettant d'établir un plan de pagination sur l'in-tégralité des pages virtuelles d'un programme de manière statique, nous allons maintenantévaluer les résultats obtenus par ces méthodes. Nous commençons par décrire le protocoleexpérimental utilisé pour obtenir les résultats que nous présentons et commentons dans unsecond temps.

4.1 Protocole expérimental

Nos expérimentations ont été réalisées sur des programmes binaires compilés pour unearchitecture MIPS R2000/R3000 avec l'option de compilation -O0. Nous avons utilisé dixbenchmarks provenant du groupeMälardalen WCET research1dont les caractéristiques sontprésentées dans le tableau 4.1.

Le calcul de la borne supérieure du pire temps d'exécution ainsi que le calcul desfréquences du pire chemin sont e�ectués par le logiciel d'analyse statique de WCET Hep-tane2 [5]. La méthode d'énumération implicite des chemins d'Heptane est utilisée pour cecalcul. La phase d'analyse bas niveau (pour le cache d'instruction, la prédiction de bran-chement. . . ) est désactivée et le temps d'exécution d'une instruction est �xé à 1 cycle. Cesdeux considérations sont prises pour visualiser exclusivement les e�ets de la pagination.De plus, Nous utilisons le logiciel commercial CPLEX 10.03 pour résoudre le système decontraintes linéaires.

Les temps de chargement ainsi que les temps de recopie sur disque (dans la zone deswap) sont �xés à un million de cycles (représentant un temps de pagination de 10 ms pourun processeur à 1 Ghz). L'allocation et la désallocation d'une page virtuelle en mémoirephysique représentent quelques accès à la mémoire physique (mise à jour d'une entrée de latable des pages virtuelles), ces temps sont �xés à 100 cycles et en�n, le temps de transfertd'une page à l'autre est �xé à 200 cycles. Ces valeurs respectent l'ordre de grandeur destemps nécessaires à l'exécution de chacun de ces mécanismes sans pour autant se baser surune architecture matérielle précise. L'important est d'observer les comportements de nosapproches applicables à di�érentes architectures matérielles.

Pour les expérimentations menées uniquement sur les pages de code, la taille des pagesvirtuelles est �xée à 128 octets tandis que pour les expérimentations comprenant les pagesde code et de données, cette taille est �xée à 512 octets. Dans les deux cas, cette taille

1Mälardalen WCET research : http ://www.mrtc.mdh.se/projects/wcet/benchmarks.html2Heptane est un logiciel open-source disponible à l'adresse http ://www.irisa.fr/aces/software/software.html .3ILOG CPLEX - High-performance software for mathematical programming and optimization :

http ://www.ilog.com/products/cplex/.

47

CHAPITRE 4. EXPÉRIMENTATIONS 48

Nom Description Taille du code Taille du .data Taille du .bss(octets) (octets) (octets)

compress Compression d'une image de 128x 128 pixels utilisant la transfor-mée en cosinus discrète

3064 0 70656

matmult Multiplication de deux matricescarrées de 50 x 50 entiers

808 0 30000

crc Contrôle de redondance cyclique 1236 274 768jfdctint Transformée en cosinus discrète

sur un bloc de 8 x 8 pixels3204 0 256

qurt Calcul des racines d'une équationdu second degré

1760 4 56

�t Transformée de Fourier rapide 3624 64 64bubble Tri à bulle sur un tableau de 10

éléments536 0 400

insertsort Tri par insertion 420 0 0minver Calcul de valeurs �ottantes dans

une matrice 3 x 34604 72 408

statemate Automate généré automatique-ment par STARC (STAtechartReal-time-Code generator)

11704 0 290

Tab. 4.1 � caractéristiques des benchmarks

est volontairement inférieure à celles utilisées dans des systèmes réels pour augmenter lapression mémoire, les benchmarks ayant des tailles restreintes.

Les temps de calcul mesurés pour les di�érentes méthodes sont e�ectués sur une machinedisposant d'un processeur Intel Pentium 4 3.6 GHz avec 2 Go de RAM. Pour la mesuredu temps de calcul de chaque méthode, le début s'e�ectue après l'obtention des fréquencesinitiales, celle-ci étant commune aux trois méthodes et s'arrête une fois le plan de paginationdéterminé, en n'incluant pas le temps de calcul d'Heptane.

Nous réalisons une étude comparative sur les comportements pire cas des programmesen se basant sur des évaluations statiques. Cette comparaison sera portée d'une part surles performances entre nos approches de pagination statique (coloration et contraintes li-néaires) et d'autre part en analysant le comportement pire cas d'une méthode de paginationdynamique LRU. Cette dernière est e�ectuée en reprenant l'idée de la simulation statiquede contenu de cache (partie 2.1.2.1) et en considérant la mémoire physique comme uncache totalement associatif. La comparaison est e�ectuée sur les pages de code en pre-nant l'analyse bas niveau d'Heptane pour les caches d'instructions avec une politique deremplacement LRU strict.

Nous réalisons également une étude comparative vis-à-vis du comportement à l'exécu-tion des méthodes de pagination. Pour cela, nous utilisons le micro système d'exploitationNachos4 s'exécutant sur une machine MIPS émulée. Ce système implémente un algorithmede remplacement de pages pseudo-LRU basé sur l'algorithme de l'horloge [30] dont nousmesurons le nombre d'opérations de pagination e�ectuées à l'exécution.

La métrique utilisée pour comparer les di�érentes méthodes est le nombre de défautsde pages dans le cas des expérimentations portant uniquement sur les pages de code. Pourles expérimentations comprenant l'ensemble des pages virtuelles, nous prenons le nombrede chargements à partir du disque additionné avec le nombre de recopies sur disque. L'al-location ainsi que la désallocation ne sont pas prises en compte celles-ci s'avérant n'avoir

4Nachos est disponible à l'adresse http ://www.cs.washington.edu/homes/tom/nachos/.

48


qu'un très faible impact étant donné la di�érence d'ordre de grandeur avec les accès disque.Cette métrique est obtenue par analyse statique ou par exécution suivant le type d'expé-rimentation mené.

4.2 Résultats

Cette partie présente les résultats obtenus par chacune des méthodes proposées. Les ex-périmentations sont portées principalement sur des plans de pagination complets intégrantles pages de code et de données. Pour l'approche par contraintes linéaires, nous utilisonsle placement en mémoire déterminé par coloration, le temps de calcul nécessaire au place-ment par contraintes étant peu exploitable en pratique (plusieurs heures même pour desbenchmarks de petites tailles). Nous commençons par comparer les méthodes proposéesentre-elles puis, nous regardons le cas de la réévaluation du pire chemin lors du processusd'allocation. Pour �nir, nous comparons nos méthodes avec d'une part, une simulationstatique d'un remplacement de pages LRU et d'autre part, en mesurant les opérations depagination d'un système dynamique pseudo-LRU.

4.2.1 Évaluation pire-cas par analyse statique des méthodes de pagina-tion

Nous comparons dans cette partie le comportement pire-cas des programmes avec nosapproches de pagination statique ainsi qu'avec une analyse statique d'un algorithme deremplacement de pages LRU strict.

4.2.1.1 Comparaison contraintes linéaires / coloration

Nous commençons par la comparaison entre l'approche par coloration utilisant d'unepart, une découpe par zone (COLZ) et d'autre part, une découpe globale (COLG) avecl'approche par contraintes linéaires (PLNE). Cette comparaison est portée sur le nombred'opérations de pagination sur le pire chemin ainsi que sur les temps de calcul nécessairesà l'élaboration d'un plan de pagination. La �gure 4.1 propose une vision graphique desrésultats obtenus avec sur l'axe des abscisses le nombre de pages physiques et sur l'axe desordonnées, soit le nombre d'opérations de pagination sur le pire chemin, soit le temps decalcul en secondes. Dans tous les cas, il n'y a pas de réévaluation du pire chemin lors duprocessus d'allocation.

Pour les trois méthodes, nous pouvons remarquer que le nombre d'opérations de pa-gination sur le pire chemin a tendance à diminuer plus le nombre de pages physiquesdisponibles augmente. Ce comportement est prévisible car plus l'espace mémoire augmenteplus les pages virtuelles peuvent rester en mémoire physique.

Rentrons maintenant dans la comparaison entre les trois méthodes. Sur l'ensemble desbenchmarks le nombre d'opérations de pagination obtenu par l'approche utilisant le systèmede contraintes linéaires en nombres entiers est globalement inférieur aux deux méthodespar coloration avec dans certains cas une diminution importante pour �t (jusqu'a 70%)et compress (jusqu'a 90%). Nous expliquons cette variation importante pour ces deuxbenchmarks par le fait qu'ils disposent de boucles imbriquées dans leur code source. Lesboucles imbriquées sur une partie du programme augmentent le poids de certaines websde façon importante ce qui privilégie leur conservation sur l'intégralité du programmebloquant alors des améliorations possibles sur d'autre partie du programme. Le systèmede contraintes linéaires, quand à lui, dé�nit un plan de pagination de manière plus �neen réduisant les mécanisme de pagination sur l'ensemble du programme. Au niveau des

49


Fig. 4.1 � Comparaison contraintes linéaires / coloration

50


méthodes de coloration, l'approche de découpe par zone (COLZ) o�re de meilleurs résultatscomparativement à l'approche par découpe globale (COLG) et globalement, l'écart diminueplus le nombre de pages physiques augmente.

Les temps de calcul nécessaires à l'élaboration d'un plan de pagination de chacunede ces méthodes ont des comportements di�érents. Pour COLG o�rant globalement lesmeilleurs performances en terme de temps de calcul, la tendance générale montre que letemps augmente en fonction du nombre de pages physiques puis diminue ensuite lorsquel'on se rapproche du nombre total de pages virtuelles du programme. Ce comportements'explique par la phase de coloration qui est rapide pour un nombre de page physique faibleétant donné la découpe importante des webs, puis plus coûteuse car le graphe d'interférencedevient plus complexe à colorier (moins de découpes e�ectuées donc plus d'interférencesentre les webs). Cette complexité �nit par se réduire jusqu'à devenir directement colo-riable lorsque le nombre de couleurs disponibles tend vers le nombre de pages virtuelles duprogramme.

Pour COLZ, le temps de calcul a globalement tendance à être élevé lorsque le nombre depages physiques disponibles est faible puis à décroître ensuite lorsque ce nombre augmente.Ce comportement s'explique par l'approche de découpe par zone. Contrairement à COLG,dont la découpe est rapide à e�ectuer, cette découpe est plus coûteuse car elle nécessite devéri�er que chaque web dispose bien d'un ensemble de sommets connexes après le retraitde l'un d'entre eux ce qui revient à chercher les composantes connexes des sommets deswebs pour chaque découpe. Cette découpe est d'autant plus coûteuse quand on disposed'un nombre de pages physiques restreint car le nombre de webs à traiter dans ce casest plus important. Pour un nombre faible de pages physiques, nous remarquons tout demême que le temps de calcul à tendance à augmenter avec le nombre de pages physiques.Nous expliquons ceci par deux raisons. Premièrement, comme pour COLG la phase decoloration à tendance à augmenter sur cette partie de la courbe et deuxièmement, le tempsde découpe n'est pas strictement décroissant. En e�et, la phase de découpe des webs estamenée à découper plus ou moins de webs en fonction du nombre de pages physiques etdonc prendre plus ou moins de temps.

Finalement, pour l'approche par contraintes linéaires, le comportement du temps decalcul est globalement croissant. Dans cette approche deux opérations sont coûteuses :la résolution du système et le placement en mémoire physique. Premièrement, Le tempsde résolution du système est globalement croissant. Cependant, il est variable en fonctiondu nombre de pages physiques. Le solveur cherche à trouver une solution optimale enfonction des paramètres d'entrées du système. Cette recherche prend plus ou moins detemps sur un même programme en fonction du nombre de pages physiques disponibles (i.e.le paramètre du système qui varie). Cela explique la présence de pics sur certaines courbescomme statemate et compress. Deuxièmement, pour le placement en mémoire, la solutiondu système dé�nit une occupation importante (tendant vers une utilisation totale) de lamémoire physique quelque soit le nombre de pages physiques. La construction de l'ensembledes webs minimales revient à trouver l'ensemble des composantes connexes du GFC pourl'ensemble des pages virtuelles. Le temps lié à cette construction est polynomial et donccroissant en fonction du nombre de pages physiques.

Sur les benchmarks de petite taille, le temps de calcul de l'approche par contrainteslinéaires est faible et souvent inférieur à l'approche par coloration COLZ. Par contre, pourles benchmarks de taille plus conséquente comme statemate et compress, le temps de calculse trouve nettement plus important. Ce cas est plus représentatif du comportement destemps de calcul que l'on peut obtenir sur des programmes réels.

Le temps de calcul de chacune des méthodes est globalement inversé par rapport au

51


nombre d'opérations de pagination. De ce fait, un compromis peut être à e�ectuer dans lecadre d'une utilisation sur des programmes réel entre la qualité du plan de pagination etle temps nécessaire à son obtention.

4.2.1.2 Comparaison contraintes linéaires avec et sans réévaluation

Cette comparaison a pour but d'illustrer la prise en compte de la variation du pirechemin lors de l'allocation des pages virtuelles en mémoire physique. Les résultats sontobtenus sur les benchmarks disposant de chemins d'exécutions multiples. La �gure 4.2propose une vision graphique des résultats obtenus pour statemate avec des pages de codeet de données et compress avec les pages de code.

Fig. 4.2 � Comparaison contraintes linéaires avec et sans réévaluation

Les résultats obtenus avec et sans réévaluation sont identiques pour tous les benchmarks.Nous expliquons cette situation par le fait que les coûts liés à la pagination sont trèsimportants et �xent, d'après une allocation initiale, le pire chemin d'exécution de façondé�nitive. Le fait de dé�nir un plan de pagination en fonction d'un des pires cheminspossibles n'entraîne visiblement pas de variation. Cette considération s'avère ainsi sanslimitation majeure vis-à-vis de l'élaboration d'un plan de pagination.

4.2.1.3 Comparaison entre l'évaluation statique d'une pagination statique etl'évaluation statique d'une pagination LRU

Cette comparaison, e�ectuée sur les pages de code uniquement 5, permet d'estimer ladi�érence entre nos approches et une simulation statique de contenu de la mémoire utilisantun remplacement de page LRU. Celle-ci permet de comparer l'ordre de grandeur entre uneévaluation statique pire cas du nombre de défauts de pages d'un algorithme LRU et nosapproches, visant à réduire le nombre de défauts de pages en déterminant statiquementl'intégralité du contenu de la mémoire. Cependant, elle ne permet pas une comparaisonpoussée car les systèmes réels n'implémentent généralement pas un LRU strict mais uneapproximation ajoutant de l'indéterminisme. La �gure 4.3 propose une vision graphiquedes résultats obtenus.

Globalement, le nombre de défauts de pages calculé par la simulation statique ducontenu mémoire est supérieur au nombre de défauts de pages déterminé par le système decontraintes linéaires. Cette di�érence s'explique à deux niveaux. Premièrement, lorsque le

5car Heptane ne dispose pas d'une analyse de caches de données

52


Fig. 4.3 � Évaluation statique d'une pagination statique / évaluation statiqued'une pagination LRU

nombre de pages physiques est faible, les accès circulaires aux pages à l'intérieur de bouclesentraînent un nombre de défauts important. En e�et une page retirée de la mémoire phy-sique peut être utilisée juste après et provoquer un défaut de page. Ce phénomène présentédans [13] est dû à la politique de remplacement LRU elle-même. Deuxièmement, lorsquele nombre de pages physiques est proche du nombre de pages virtuelles du programme, lesvaleurs obtenues par simulation statique sont également plus importantes. Ce comporte-ment est, dans ce cas, dû à la classi�cation des accès de l'analyse statique considérant queles boucles peuvent itérer zéro fois. De ce fait, en sortie de boucles certaines pages sontconsidérées absentes pour la sûreté de l'analyse et elles occasionnent donc des chargementssupplémentaires.

Pour l'approche par coloration COLZ, les résultats étant plus pessimistes que le systèmede contraintes, la simulation statique rend des résultats inférieurs sur plusieurs benchmarkscependant, l'ordre de grandeur du nombre de défauts de pages reste le même.

Pour les deux approches de pagination statiques, les résultats sont déterministes tandis

53


que la simulation d'une pagination LRU l'est moins étant donné que les systèmes réelsimplémentent une version assez éloignée d'un LRU strict. Pour l'approche par contrainteslinéaires, les résultats sont de surcroît généralement plus performants.

4.2.2 Évaluation dynamique du comportement des méthodes de pagina-tion

Cette comparaison vise à estimer la di�érence entre nos approches statiques avec lecomportement à l'exécution d'une politique de remplacement de pages se trouvant dans lessystèmes réels. Elle porte également sur le pire-cas et donc sur un pire chemin d'exécution.Pour cette raison, nous prenons des programmes disposant d'un chemin d'exécution uniquecar les résultats obtenus de façon dynamique sur des programmes à chemins multiples nesont pas nécessairement représentatifs d'un pire chemin.

Pour les méthodes statiques de pagination nous prenons le nombre d'opérations de pagi-nation déterminé statiquement en absence d'une implémentation concrète qui sera abordéedans la partie perspectives. Au détail d'implémentation près, le nombre d'opération de pa-gination obtenu reste tout de même très proche de ce que l'on peut attendre à l'exécution.La �gure 4.4 propose une vision graphique des résultats obtenus.

Les deux approches statiques favorisent la conservation en mémoire physique des pagesde données accédées en écriture pour limiter le nombre de recopie sur disque en préférantle déchargement des pages de code et de données non utilisées dans la suite du programme.Ce principe se trouve ignoré dans le cas de la politique de remplacement pseudo-LRU.

La comparaison avec l'approche par coloration COLZ montre que globalement les résul-tats obtenus par coloration sont moins bons tout en conservant le même ordre de grandeur.L'utilisation de l'approche par coloration COLZ a�n d'obtenir un déterminisme nécessaireau calcul de la borne supérieure de WCET n'engendre donc pas une perte en performancetrop importante.

Le système de contraintes linéaires, déterminant des plans de pagination occasionnantun nombre d'opérations de pagination plus faible, permet de mettre en évidence certainsphénomènes. Globalement, sur l'ensemble des benchmarks, les résultats obtenus par lesystème de contraintes sont plus performants que le pseudo-LRU dynamique ce qui nouspermet de visualiser les cas contredisant cette tendance.

Le premier phénomène observé est sur jfdctint où les résultats sont supérieurs pourcertains nombres de pages physiques. Nous expliquons ce phénomène par le fait que ceprogramme dispose d'une fonction appelée en de nombreux points de programmes ce quiengendre des fréquences sur le pire chemin élevées pour les arcs de cette fonction. De plus,l'analyse statique est non contextuelle et de ce fait quelque soit le contexte d'appel de cettefonction, les chargements à e�ectuer sont identiques dans le cas statique (i.e. le contenude la mémoire physique en un point de programme est identique pour tous les contextesd'appels) alors que les résultats du pseudo-LRU dynamique sont quand à eux contextuels.Dans ce cas, notre approche statique est plus pessimiste car elle impose des chargementset déchargements pas toujours utiles à tous les contextes d'appels. Pour ce programme,nous avons également testé une version utilisant une macro à la place de la fonction etdans ce cas, ce comportement disparaît et les résultats obtenus statiquement respectentla tendance générale. Dans le cadre des systèmes temps-réel, cette observation n'est pastrop contraignante. En e�et, le nombre d'appels à une même fonction est restreint. Pourles fonctions appelées fréquemment, elles sont réduites à quelques instructions permettantainsi leur inlining sans pour autant augmenter la taille du code de façon importante.

Le second phénomène observé surminver est lié à la surestimation de l'analyse d'adresse

54


Fig. 4.4 � Évaluation statique, pagination statique / évaluation dynamique, pa-gination pseudo-LRU

pour les pages de données. Lorsque le système dispose d'un nombre de pages physiques su-périeur ou égal au nombre de pages virtuelles du programme, le nombre de chargementsmesuré est inférieur au nombre de chargements déterminé statiquement. Ceci s'explique parle fait que minver dispose d'un tableau de taille importante comparativement à la tailledes pages et que celui-ci n'est pas accédé en intégralité lors de l'exécution dynamique alorsque l'approche statique considère un accès sur l'ensemble du tableau et donc elle le chargeintégralement en mémoire. Ce phénomène entraîne un nombre d'opérations de paginationglobalement plus importante sur ce programme. Sur l'ensemble des benchmarks, ce cas estisolé car les éléments d'un tableau sont généralement parcouru en intégralité par l'intermé-diaire de boucles. Ce même phénomène peut arriver dans le cas de programme disposantde fonctions avec contextes d'appels multiples dû au fait de prendre l'ensemble des framesd'une fonction. Pour �t et qurt rentrant dans ce cadre, cette limitation est réduite par unnombre de contextes d'appels distincts faible et également par la taille réduite des framescomparativement à la taille des pages qui peuvent alors contenir l'ensemble des pages des

55


di�érents contextes.D'un point de vue général, notre approche apporte un système de pagination détermi-

niste sans pour autant dégrader le nombre d'opérations de pagination comparativement àun algorithme de remplacement de pages dynamique.

56

Chapitre 5

Implémentation et perspectives

Dans ce chapitre, nous allons présenter une approche possible pour une implémentationconcrète dans un système réel de notre mécanisme de pagination déterminant statiquementles points de modi�cation de la mémoire physique. Puis, nous évoquerons certaines pers-pectives pour notre approche de pagination en contexte temps-réel.

5.1 Implémentation

Une question reste ouverte, celle d'une implémentation concrète prenant en compte leplan de pagination déterminé statiquement. Une approche possible, indépendante d'unearchitecture spéci�que, pour répondre à cette question consiste à dé�nir un appel système.Cet appel serait réalisé par le programme lui même pour signaler au système d'exploitationde réaliser la modi�cation attendue du contenu de la mémoire physique. Cependant, celanécessite de modi�er le programme binaire après avoir établi le plan de pagination a�nd'ajouter les appels systèmes aux points de programmes nécessitant la modi�cation ducontenu de la mémoire. Cette modi�cation du �chier binaire entraîne un décalage dansles adresses des instructions et donc du contenu des pages virtuelles, invalidant le plande pagination déterminé précédemment. De ce fait, il semble nécessaire de modi�er unepremière fois le contenu du �chier binaire en laissant des emplacements disponibles danschaque page virtuelle proportionnellement au nombre d'arcs entre blocs de base qu'ellecontient (par l'ajout d'instructions nop par exemple) comme l'illustre la �gure 5.1 entre leschéma de gauche et du milieu.

Cette modi�cation permet ainsi d'établir un plan de pagination et d'ajouter les appelssystème sans pour autant modi�er le nombre d'instructions contenu dans chacune despages, illustrée par le schéma de droite avec les points sur les arcs. L'ajout des appelssystèmes réduit alors le nombre d'emplacements disponibles (i.e. le nombre de nop) voireau mieux l'utilise complètement.

Du côté système d'exploitation, le système doit déterminer quelles actions sont à réaliseren fonction du paramètre transmis par l'appel système. Une possibilité consiste à repré-senter la succession d'appels système du programme sous la forme d'un automate d'états�ni et à associer à chacune des transitions entre états les actions à réaliser. Cet automate,transmis au système, peut être implémenté par des structures de données permettant l'ac-cès aux opérations à réaliser en temps constant pour garder le déterminisme sur les tempslié à la pagination.

57

CHAPITRE 5. IMPLÉMENTATION ET PERSPECTIVES 58

g

f

e

a

dc

b

page virtuelle 1

page virtuelle 2

g

f

e

a

f

e

dc

b

g

page virtuelle

a

dc

b

page virtuelle 1

page virtuelle 2

Transformation

Ajout de NOP

Ajout

appels système

appel système

appel système

appel systèmeZone de NOP

Zone de NOP Zone de NOP

Zone de NOP

Fig. 5.1 � Modi�cations pour l'implémentation

5.2 Perspectives

Nous nous sommes concentrés sur l'élaboration d'un plan de pagination déterministeen considérant les temps liés aux chargements et aux déchargements du disque commeétant les pires temps d'accès. Ces temps étant importants, l'utilisation de di�érents typesde mémoire morte pourrait être envisagée dans la réalisation d'un système concret commepar exemple les mémoires �ash, celle-ci disposant de temps d'accès nettement plus rapideque les disques durs traditionnels. Cependant, l'utilisation de mémoire �ash amène uneautre di�culté. En e�et, ce type de mémoire est composée de zone mémoire disposantd'un nombre d'écriture limité. Généralement, le placement des données se trouve alorsréparti a�n de ne pas user prématurément certaines de ces zones. Dé�nir statiquementle placement mémoire pour ce type de mémoire doit inclure la prise en compte de cettecontrainte inexistante pour les disques durs traditionnels.

Les résultats entre nos approches statiques et un fonctionnement dynamique montrentque la granularité de l'analyseur d'adresses de données in�ue sur la qualité du plan de pagi-nation. Une analyse plus �ne des adresses référencées pourrait, en considérant les variablesd'induction de boucles ou encore en di�érenciant les contextes d'appels des fonctions, rendredes résultats plus précis. Cette précision ne serait pas sans conséquence car elle augmente-rait, de façon importante, le temps nécessaire à l'analyse d'adresses. De plus, pour prendreen compte ces éléments, il semble nécessaire de disposer d'une procédure s'exécutant auniveau runtime a�n de déterminer en fonction des variables d'inductions et des contextesd'appels les traitements nécessaires à réaliser. Cette procédure ajouterait un temps nonnégligeable dans le processus de pagination ainsi que des pages virtuelles supplémentairesdevant être résidantes durant toute la durée de l'exécution. Pour les accès dépendant desdonnées d'entrées et les accès irréguliers, il serait nécessaire de considérer un défaut depage dans le cas où la donnée accédée ne serait pas totalement présente en mémoire, ce quirevient en partie à notre approche.

Nous n'avons pas abordé les mécanismes de traduction d'adresses virtuelles en adressesphysiques. Ceux-ci sont néanmoins un facteur intéressant à prendre en compte pour rendre

58


déterministe l'intégralité des mécanismes liés à l'utilisation de la pagination. En reprenantla structure de la table des pages décrite dans [2], la traduction d'une adresse contenuedans cette table se fait en temps constant. Cependant, des éléments matériels comme leTLB permettent de conserver les adresses virtuelles récemment traduites a�n d'accélérerle temps de traduction futur de ces mêmes adresses. Généralement, la gestion du TLB estgérée de façon dynamique engendrant de l'indéterminisme sur les temps de traduction etpour cette raison son utilisation s'en trouve restreinte dans les systèmes temps-réel actuels.Pourtant, une utilisation déterministe de la traduction d'adresses nous semble possible etintéressante pour les systèmes temps-réel. L'idée serait de minimiser le temps de traductiondes adresses des pages virtuelles les plus accédées sur le pire chemin en les a�ectant dansune des entrées du TLB. En reprenant un concept similaire à celui présenté pour déterminerle contenu de la mémoire physique, nous pouvons déterminer statiquement le contenu duTLB en chaque point de programme en suivant une heuristique WCET. Pour l'approchepar coloration, la principale di�érence serait de modi�er la fonction de poids des webs a�nde prendre en compte le nombre d'accès à chacune des pages virtuelles et ce pour chacundes blocs de base. De façon similaire, pour l'approche par contraintes linéaires, il faudraitintégrer dans la fonction objective le nombre d'accès à chacune des pages virtuelles dechaque bloc de base et de minimiser la somme des coûts de traduction entre les adressesprésentes dans le TLB et les adresses présentes uniquement dans la table des pages enajoutant les coûts liés à la modi�cation du contenu du TLB. La problématique est quelquepeu di�érente, tout de même, car une adresse virtuelle n'a pas la nécessité d'être présentedans le TLB pour être traduite ceci in�uençant uniquement la latence de traduction. Ene�et, nous disposons d'un accès direct à la table des pages présente en mémoire physiquece qui n'est pas le cas avec la pagination vis-à-vis des accès disques.

Une autre piste intéressante est celle de l'intégration de notre approche dans les sys-tèmes multi-tâches. En reprenant l'approche des caches et le concept de Cache-RelatedPreemption Delay, il est possible de déterminer pour la pagination, le temps lié au rem-placement de pages dû à une préemption. Nos approches tentent d'utiliser au maximuml'espace physique disponible de ce fait, le temps lié à la préemption serait le retrait detoutes les pages virtuelles de la tâche préemptée (avec comme pire cas uniquement desrecopies sur disque) et le chargement des pages virtuelles de la tâche plus prioritaire (aveccomme pire cas uniquement des chargements à partir du disque). Cependant, étant donnéle coût d'un accès disque, le coût d'une préemption peut être très important. Une autrepossibilité revient à découper l'ensemble de la mémoire physique en partitions de taillespotentiellement di�érentes et à associer à chaque tâche une partition. La taille de la parti-tion d'une tâche peut être déterminée par la borne supérieure de WCET calculée par nosméthodes pour chaque taille de partition (i.e. pour tous les nombres possibles de pagesphysiques disponibles) et en reprenant l'approche de cache memory partitioning [28] pré-sentée en 2.1.3.1. Cette approche limite cependant l'espace en mémoire physique de chacundes processus réduisant alors leurs performances durant leur exécution.

59

Conclusion

Dans ce rapport, nous nous sommes placés dans le cadre des systèmes temps-réel dontla principale di�culté est de garantir le bon fonctionnement des applications en assurantle respect des contraintes temporelles. Pour cela, nous avons commencé par introduire lanotion de pire temps d'exécution qui s'avère être une composante essentielle dans le proces-sus de validation des systèmes temps-réel. Après avoir présenté des méthodes généralistespermettant d'estimer une borne supérieure de ce pire temps d'exécution, nous nous sommesintéressés tout particulièrement aux méthodes existantes permettant de prendre en comptel'architecture matérielle et plus précisément les di�érents composants de la hiérarchie mé-moire de ces systèmes. Comme nous avons pu le voir, de nombreux travaux ont été e�ectuésau niveau des caches. Des méthodes d'analyses pour les caches d'instructions, de donnéesainsi que leur prise en compte dans les systèmes multi-tâches préemptifs. Certaines limita-tions ont donné lieu à des méthodes exploitant les fonctionnalités de chargement explicitedes caches permettant ainsi de déterminer statiquement leurs contenus. Nous nous sommesensuite intéressés à l'utilisation de la mémoire virtuelle dans le cadre des systèmes temps-réel. Son utilisation, introduisant de l'indéterminisme dans les durées d'exécution, se limiteà l'heure actuelle, soit à exploiter le principe d'isolation spatiale, soit à l'écarter totalement.Pourtant, plusieurs facteurs mettent en évidence l'intérêt d'un mécanisme de paginationadapté au temps-réel. D'une part, les systèmes temps-réel actuels disposent de plus en plussouvent du matériel nécessaire pour faciliter ce mécanisme comme les MMU et TLB etd'autre part, le volume des applications temps-réel embarqués a tendance à augmenter orl'ajout de mémoire physique représente un coût non négligeable dans la conception dessystèmes.

En partant de cette constatation, nous sommes rentrés dans la problématique de cestage consistant à élaborer un mécanisme de pagination adapté aux systèmes temps-réel, end'autres termes un système de pagination déterministe permettant d'une part de connaîtrestatiquement le contenu de la mémoire a�n de connaître précisément les temps liés auxopérations de pagination pour les prendre en compte dans le calcul d'une borne supérieuredu WCET et d'autre part, ce système tente de réduire le nombre d'opérations de paginationsur le pire chemin d'exécution pour minimiser cette borne.

L'approche que nous avons développée reprend le principe général du dynamic cachelocking en déterminant statiquement le contenu de la mémoire physique ainsi que les pointsde programme où ce contenu sera modi�é lors de l'exécution. L'approche est quelque peudi�érente néanmoins car dans notre cas, il est nécessaire que toutes les pages référencéessoit présentes en mémoire physique tandis que cette condition est absente pour le dynamiccache locking.

Nous avons présenté deux approches di�érentes a�n d'établir statiquement un plan depagination pour les pages de code et les di�érents types de pages de données, en fonctiond'un pire chemin d'exécution. La première méthode assimile le problème de paginationstatique à une coloration de graphe et la seconde méthode modélise l'ensemble des mé-

60


canismes de pagination par un système de contraintes linéaires. Nous avons montré quel'approche par coloration dispose de certaines limites notamment pour la prise en comptedes di�érents types de pages de données et également pour la prise en compte de la varia-tion du pire chemin lors du processus d'allocation. Ce dernier s'avère tout de même peulimitatif sur l'ensemble des programmes testés. Les résultats entre ces méthodes montrentque notre approche par contraintes linéaires détermine un nombre d'opérations de pagi-nation sur le pire chemin généralement inférieur à l'approche par coloration de graphe.Cependant le temps de calcul est quand à lui supérieur avec le système de contraintes pourles programmes disposant d'une taille signi�cative. Dans le cas de programmes réels uncompromis peut être à faire entre la qualité du plan de pagination et le temps de calculnécessaire à son obtention.

Nous avons également comparé les résultats obtenus avec une simulation statique ducontenu de la mémoire physique en transposant une analyse existante au niveau des cachesd'instructions et en considérant la mémoire physique comme un cache totalement associatif.Les résultats obtenus montrent que globalement le nombre d'opérations de pagination res-pecte le même ordre de grandeur entre la simulation statique et nos approches. L'approchepar simulation statique reste tout de même moins précise dû d'une part aux déchargementsdes références cycliques natif au LRU tandis que nos approches suivent une heuristiqueWCET favorisant la conservation en mémoire des références fréquente sur le pire chemin.D'autre part, avec le pessimisme de l'analyse statique considérant dans certains cas l'ab-sence de la page physique en mémoire a�n de garantir la sûreté de l'analyse alors que dansnos approches, le contenu est dé�ni statiquement en chaque point de programme.

Finalement, nous avons comparé nos résultats avec le comportement dynamique d'unalgorithme de remplacement de page pseudo-LRU en mesurant les opérations de pagina-tion liées à l'exécution des programmes. Les résultats montrent que globalement l'ordre degrandeur du nombre d'opérations de pagination est similaire entre notre approche et uneexécution réelle. Les résultats du système de contraintes sont globalement meilleurs pourdes programmes disposant de fonctions avec peu de contextes d'appels. Plusieurs facteurssont à l'origine d'un certain pessimisme occasionnant des résultats moins performants. Lesfonctions appelées de nombreuses fois avec des contextes multiples, dans ce cas notre ap-proche dé�ni un contenu mémoire unique quelques soit le contexte d'appel. Une solutionà ce phénomène réside dans l'inlining des fonctions provoquant celui-ci. Le second facteurest lié à notre analyse d'adresses gros grain considérant l'ensemble des frames d'une fonc-tion et l'intégralité des tableaux comme résidant intégralement en mémoire lors de chaqueaccès. Le pessimisme intervient dans le cas de programme n'accédant pas à l'intégralité deséléments des tableaux ou pour des programmes disposant de fonctions avec des frames detaille importantes. Nous suggérons une analyse plus contextuelle a�n de réduire ce phéno-mène. Ces deux phénomènes n'engendre pas de dégradation importantes des performances.Finalement, nos approches permettent d'obtenir le déterminisme nécessaire aux systèmestemps-réel tandis que les politiques de remplacement de pages dynamique sont di�cilementanalysable et donc di�cilement exploitable.

61

Bibliographie

[1] MIPS Application Binary Interface.http ://www.sco.com/developers/devspecs/mipsabi.pdf.

[2] M. D. Bennett and N. C. Audsley. Predictable and e�cient virtual addressing forsafety-critical real-time systems. pages 183�190, Delft, The Netherlands, June 2001.

[3] L Burkholder. The halting problem. SIGACT News, 18(3) :48�60, 1987.

[4] Gregory J. Chaitin, Marc A. Auslander, Ashok K. Chandra, John Cocke, Martin E.Hopkins, and Peter W. Markstein. Register allocation via coloring. Comput. Lang.,6(1) :47�57, 1981.

[5] A. Colin and I. Puaut. A modular and retargetable framework for tree-based WCETanalysis. pages 37�44, Delft, The Netherlands, June 2001.

[6] P. Cousot and R. Cousot. Basic Concepts of Abstract Interpretation, pages 359�366.Kluwer Academic Publishers, 2004.

[7] J. Stankovic D. Niehaus, E. Nahum and K. Ramamritham. Architecture and os sup-port for predictable real-time systems. Technical report, University of Massachusetts,Mar. 1992.

[8] JF. Deverge and I. Puaut. WCET-directed dynamic scratchpad memory allocation ofdata. In Proceedings of the 19th Euromicro Conference on Real-Time Systems, Pisa,Italy, July 2007. To appear.

[9] Christian Ferdinand, Reinhold Heckmann, Marc Langenbach, Florian Martin, MichaelSchmidt, Henrik Theiling, Stephan Thesing, and Reinhard Wilhelm. Reliable andprecise WCET determination for real-life processor. In EMSOFT '01 : Proceedings ofthe First International Workshop on Embedded Software, volume 2211, pages 469�485,Tahoe City, CA, USA, October 2001.

[10] Somnath Ghosh, Margaret Martonosi, and Sharad Malik. Cache miss equations : acompiler framework for analyzing and tuning memory behavior. ACM Trans. Program.Lang. Syst., 21(4) :703�746, 1999.

[11] David W. Goodwin and Kent D. Wilken. Optimal and near-optimal global registerallocation using 0-1 integer programming. Softw., Pract. Exper., 26(8) :929�965, 1996.

[12] R. Heckmann, M. Langenbach, S. Thesing, and R. Wilhelm. The in�uence of processorarchitecture on the design and the results of WCET tools. Proceedings of the IEEE,vol.9, n R©7, 2003.

[13] Ben Juurlink. Approximating the optimal replacement algorithm. In CF '04 : Pro-ceedings of the 1st conference on Computing frontiers, pages 313�319, 2004.

[14] Y.-T. S. Li and S. Malik. Performance analysis of embedded software using implicitpath enumeration. In Richard Gerber and Thomas Marlowe, editors, LCTES '95 :Proceedings of the ACM SIGPLAN 1995 workshop on Languages, compilers, & toolsfor real-time systems, volume 30, pages 88�98, New York, NY, USA, November 1995.

62

BIBLIOGRAPHIE 63

[15] T. Lundqvist and P. Stenström. Timing anomalies in dynamically scheduled micro-processors. In IEEE Real-Time Systems Symposium, pages 12�21, 1999.

[16] Frank Mueller. Timing analysis for instruction caches. Real-Time Syst., 18(2-3) :217�247, 2000.

[17] Hemendra Singh Negi, Tulika Mitra, and Abhik Roychoudhury. Accurate estima-tion of cache-related preemption delay. In CODES+ISSS '03 : Proceedings of the 1stIEEE/ACM/IFIP international conference on Hardware/software codesign and systemsynthesis, pages 201�206, New York, NY, USA, 2003. ACM Press.

[18] Kaustubh Patil, Kiran Seth, and Frank Mueller. Compositional static instructioncache simulation. SIGPLAN Not., 39(7) :136�145, 2004.

[19] I. Puaut. Wcet-centric software-controlled instruction caches for hard real-time sys-tems. In Proc. of the 18th Euromicro Conference on Real-Time Systems, Dresden,Germany, July 2006.

[20] I. Puaut and D. Decotigny. Low-complexity algorithms for static cache locking inmultitasking hard real-time systems. In Proc. of the 23rd IEEE International Real-Time Systems Symposium, Austin, TX, USA, December 2002.

[21] I. Puaut and D. Hardy. Predictable paging in real-time systems : a compiler approach.In Proceedings of the 19th Euromicro Conference on Real-Time Systems, Pisa, Italy,July 2007. To appear.

[22] Isabelle Puaut. Real-time performance of dynamic memory allocation algorithms. InECRTS '02 : Proceedings of the 14th Euromicro Conference on Real-Time Systems,page 41, Washington, DC, USA, 2002. IEEE Computer Society.

[23] P. Puschner and A. Burns. A review of worst-case execution-time analysis. Real TimeSystems Journal, 18(2-3) :115�128, May 2000. Guest Editorial.

[24] P. Puschner and Ch. Koza. Calculating the maximum execution time of real-timeprograms. Real-Time Syst., 1(2) :159�176, 1989.

[25] P. Puschner and A. V. Schedl. Computing maximum task execution times � a graphbased approach. In Proceedings of IEEE Real-Time Systems Symposium, volume 13,pages 67�91, 1997.

[26] Harini Ramaprasad and Frank Mueller. Bounding worst-case data cache behaviorby analytically deriving cache reference patterns. In RTAS '05 : Proceedings of the11th IEEE Real Time on Embedded Technology and Applications Symposium, pages148�157, Washington, DC, USA, 2005. IEEE Computer Society.

[27] Harini Ramaprasad and Frank Mueller. Bounding preemption delay within data cachereference patterns for real-time tasks. In RTAS '06 : Proceedings of the 12th IEEEReal-Time and Embedded Technology and Applications Symposium, pages 71�80, Wa-shington, DC, USA, 2006. IEEE Computer Society.

[28] J. E. Sasinowski and J. K. Strosnider. A dynamic programming algorithm for cachememory partitioning for real-time systems. IEEE Trans. Comput., 42(8) :997�1001,1993.

[29] Jan Staschulat, Simon Schliecker, and Rolf Ernst. Scheduling analysis of real-timesystems with precise modeling of cache related preemption delay. In ECRTS '05 :Proceedings of the 17th Euromicro Conference on Real-Time Systems, pages 41�48,Washington, DC, USA, 2005. IEEE Computer Society.

[30] Andrew S. Tanenbaum. Operating systems : design and implementation. Prentice-Hall,Inc., Upper Saddle River, NJ, USA, 1987.

63

BIBLIOGRAPHIE 64

[31] Henrik Theiling, Christian Ferdinand, and Reinhard Wilhelm. Fast and precise wcetprediction by separated cache and path analyses. Real-Time Syst., 18(2-3) :157�179,2000.

[32] Manish Verma and Peter Marwedel. Overlay techniques for scratchpad memories inlow power embedded processors. IEEE Transactions on Very Large Scale IntegrationSystems, 14(8) :802�815, Aug. 2006.

[33] Joachim Wegener and Frank Mueller. A comparison of static analysis and evolutionarytesting for the veri�cation of timing constraints. Real-Time Syst., 21(3) :241�268, 2001.

[34] R. White, F. Mueller, C. Healy, D. Whalley, and M. Harmon. Timing analysis fordata caches and set-associative caches. In RTAS '97 : Proceedings of the 3rd IEEEReal-Time Technology and Applications Symposium, pages 192�202, June 1997.

[35] Randall T. White, Frank Mueller, Christopher A. Healy, David B. Whalley, and Ma-rion G. Harmon. Timing analysis for data and wrap-around �ll caches. Real-TimeSystems, 17(2-3) :209�233, 1999.

[36] Nicky Williams, Bruno Marre, Patricia Mouy, and Muriel Roger. Pathcrawler : Auto-matic generation of path tests by combining static and dynamic analysis. In EDCC,pages 281�292, 2005.

[37] W. Zhao, W. Kreahling, D. Whalley, C. Healy, and F. Mueller. Improving WCETby optimizing worst-case paths. In Proceedings of the IEEE Real-Time and EmbeddedTechnology and Applications Symposium, March 2005.

64

Pagination en contexte temps-réel embarqué - IRISA · 2009. 10. 20. · Les systèmes temps-réel...

Documents

Transcript of Pagination en contexte temps-réel embarqué - IRISA · 2009. 10. 20. · Les systèmes temps-réel...