GMC–RUN a été évalué de deux manières différentes. D’abord d’une manière théorique, ce qui nous donne une indication des pires performances possibles de notre algorithme. En particulier, nous prouvons que GMC–RUN n’a jamais besoin de plus de processeurs pour ordonnancer un système à criticité mixte que si celui–ci est ordonnancé comme un système à criticité multiple. Puis en calculant le facteur speed–up, nous déterminons l’écart entre les performances de notre algorithme et un algorithme optimal clairvoyant. Cependant,
10.6. Évaluation de GMC–RUN
cet indicateur de performance est pessimiste puisque cet écart peut n’arriver que dans le cas de systèmes très particuliers et non représentatifs des systèmes pouvant être rencontrés dans l’industrie.
C’est pourquoi nous évaluons aussi expérimentalement notre algorithme afin d’avoir une idée sur les performances de notre algorithme pour des lots de tâches que nous con- sidérons comme représentatifs.
10.6.1 Évaluation théorique
Nous rappelons d’abord un certain nombre de notations. UΓ(HI)(HI) est l’utilisation en
mode HI des tâches HI du lot Γ. UΓ(HI)(LO) est l’utilisation en mode LO des tâches
HI du lot Γ. UΓ(LO)(LO) est l’utilisation en mode LO des tâches LO du lot Γ. Enfin,
un système à multiple criticités est ordonnançable par un algorithme d’ordonnancement multi–processeur optimal sur m processeurs si UΓ(HI)(HI) +UΓ(LO)(LO)≤ m.
L’évaluation théorique de GMC–RUN se fait en deux temps.
D’abord, nous donnons et prouvons la borne supérieure du nombre de processeurs req- uis pour ordonnancer un système à criticité mixte. Puis, nous calculons son facteur speed– up. Ce facteur donne une indication sur l’éloignement des performances de l’algorithme de celles d’un algorithme optimal clairvoyant.
Nombre de processeurs
Nous nous intéressons ici à déterminer si pour ordonnancer un système à criticité mixte, GMC–RUN peut avoir besoin de plus de processeurs que si le système est ordonnancé comme un système à criticité multiple. Le théorème suivant donne une borne supérieure et une borne inférieure sur le nombre de processeurs requis pour ordonnancer un système à criticité mixte avec GMC–RUN:
Theorem 15. Le nombre de processeurs P requis pour ordonnancer un système à criticité mixte vérifie les inégalités suivantes:
dmax(UΓ(HI)(HI),UΓ(LO)(LO) +UΓ(HI)(LO))e ≤ P ≤ dUΓ(HI)e (10.2)
Remarquer que nous avons prouvé que GMC–RUN ne requiert jamais plus de pro- cesseurs que l’ordonnancement du système à criticité multiple ordonnancé par un al- gorithme d’ordonnancement temps réel optimal classique. Ce résultat est par ailleurs indépendant de la méthode choisie pour effectuer l’allocation des tâches LO dans les serveurs modaux.
Facteur speed–up
Le théorème suivant donne la valeur du facteur speed–up pour GMC–RUN: Theorem 16. Le facteur speed–up de GMC–RUN est 2.
Ce facteur speed–up est le deuxième meilleur facteur speed–up parmi les algorithmes d’ordonnancement pour systèmes à criticité mixte. Elle est par ailleurs vraie pour n’importe quel algorithme optimal multi–processeur utilisé dans notre hiérarchie d’ordonnancement, et pas seulement pour RUN.
10.6.2 Évaluation expérimentale
Nous avons ensuite évalué expérimentalement GMC–RUN et l’avons comparé avec d’autres algorithmes d’ordonnancement à criticité mixte, à savoir MC–DP–Fair [34] et fpEDF– VD [53]. Cette évaluation se base sur deux critères. Le premier est le taux de succès d’ordonnançabilité. Le second le nombre de préemptions engendrées. Nous avons pour cela généré aléatoirement des lots de tâches. L’implémentation de notre algorithme évo- lutionnaire est basé sur le framework Distributed Evolutionary Algorithms pour Python (DEAP) [75].
La génération des lots de tâches est basée sur une méthode décrite dans [53]. Cette méthode permet de générer des lots de tâches à partir de différentes valeurs de période, taux d’utilisation et proportions de tâches HI.
Le taux de succès d’ordonnançabilité
Le ratio d’acceptation est le pourcentage de lot de tâches considéré ordonnançable par un algorithme d’ordonnancement. Nous avons comparé les ratios d’acceptation de GMC– RUN, fpEDF–VD et MC–DP–Fair. La figure10.3montre le taux de succès d’ordonnançabilité pour différentes utilisations normalisées UBound/mpour 2 processeurs.
Les résultats montrent que GMC–RUN a de meilleures ratio d’acceptation que fpEDF– VD et qui sont proches de ceux de MC–DP–Fair, quelque soit la proportion de tâches HI. Par exemple, avec deux processeurs, 30% de tâches HI et une utilisation normalisée de 0.7, GMC–RUN ordonnance 95% des lots de tâches contre 100% pour MC–DP–Fair et moins de 40% pour fpEDF–VD. Cependant, GMC–RUN est meilleur que MC–DP–Fair pour des hautes utilisations et pour des une proportion de tâches HI égale à 70%.
Les meilleurs performances de GMC–RUN et MC–DP–Fair par rapport à celles de fpEDF–VD confirment notre intuition initiale que les meilleurs algorithmes d’ordonnancement
10.6. Évaluation de GMC–RUN 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 Normalized Utilization 0.0 0.2 0.4 0.6 0.8 1.0
Acceptance ratio fpEDF-VD GMC-RUN MC-DP-FAIR (a) PHI=0.3 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 Normalized Utilization 0.0 0.2 0.4 0.6 0.8 1.0
Acceptance ratio fpEDF-VD GMC-RUN MC-DP-FAIR (b) PHI=0.5 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 Normalized Utilization 0.0 0.2 0.4 0.6 0.8 1.0
Acceptance ratio fpEDF-VD GMC-RUN MC-DP-FAIR
(c) PHI=0.7
Figure 10.3: Taux de succès d’ordonnançabilité pour des utilisation normalisées (UBound/m) pour différentes proportions de tâches HI sur 2 processeurs.
à criticité se base sur les meilleurs algorithmes d’ordonnancement classiques. En ef- fet, GMC–RUN et MC–DP–Fair ont été conçus à partir d’algorithme d’ordonnancement multi–processeur optimaux classiques.
Les meilleurs résultats de GMC–RUN pour des proportions de tâches HI élevées peu- vent s’expliquer par le fait que plus la proportion de tâches HI est élevée plus le taux d’utilisation du lot de tâches correspond à celui des tâches HI seules. Par ailleurs, une grande proportion de slack time devient disponible en mode LO, ce qui facilite l’allocation de tâches LO dans les serveurs modaux et donc de réduire l’utilisation du système. Le nombre de préemptions engendrées
Le nombre de préemptions engendrées par un algorithme d’ordonnancement influence sa capacité à pouvoir ordonnancer ou non un lot de tâches. Le choix de RUN s’est fait en parti sur ce critère, et pour lequel il excelle en engendrant très peu de préemptions. Mais comme les serveurs modaux ont des budgets limités, leur utilisation peut découper
l’exécution des tâches qui leur sont allouées. Ainsi, leur utilisation peut engendrer des préemptions supplémentaires. 2 3 4 5 6 7 8 9 10 11 Number of Tasks 0 1 2 3 4 5 6
Average number of preemption per jobs
MxC-RUN
MC-DP-Fair
Figure 10.4: Nombre moyen de préemptions par job pour des lots constitués d’un nombre variable de tâches.
Nous avons comparé le nombre de préemptions engendrées par job pour GMC–RUN et MC–DP–Fair. Pour cela nous avons utilisé la même méthode de comptage que celle décrite dans le papier sur RUN: pour chaque job et en ignorant celles dues à une activation ou à la complétion d’un job. Nous n’avons effectué ce comptage que pour le mode LO, car le mode HI revient à ordonnancer les tâches HI avec RUN et donnerait des résultats similaires à ceux présentés dans [42] et qui montrent que RUN est bien meilleur qu’un algorithme similaire à DP–Fair. Les résultats sont présentés dans le figure10.4.
Le nombre moyen de préemptions est reproduit en fonction du nombre de tâches. Comme attendu, GMC–RUN engendre en moyenne au moins cinq fois moins de préemp- tions que MC–DP–Fair. Par ailleurs, l’écart se creuse à mesure que le nombre de tâches augmente.