Paramétrage des algorithmes

Les deux algorithmes d'optimisation sont tous deux dotés d'une fonction de coût et d'une fonction de valeur pour les opérations (c'est-à-dire pour l'EBO, selon la terminologie développée en4.4). Dans le cas de l'algorithme FGH (décrit dans le chapitre1), nous avons également besoin d'une relation d'ordre entre les threads, pour pouvoir eectuer un tri de ceux-ci. Comme nous l'avons montré, nous pouvons congurer ces fonctions grâce à des théorèmes REAL. Pour dé- montrer cette possibilité, nous avons eectué deux processus d'optimisation distincts en utilisant des fonctions de valeur diérentes : une fonction dite basée sur les périodes (PB) et un fonction dite basée sur les connexions (CB). Le choix de ces critères est essentiellement motivé par la volonté de démontrer la modularité de notre approche : en aucun cas nous ne prétendons qu'ils soient optimaux.

Dans notre cas d'étude, nous n'avons pas pris en compte la gestion des priorités : chaque thread garde une même priorité durant son exécution, quelle que soit la call sequence qu'il est en train d'exécuter. En eet, l'architecture actuelle du code généré rendait problématique la génération du code associé. Assurer que la solution initial est ordonnançable dans un système non préemptif permet donc d'assurer l'ordonnançabilité du système optimisé, puisque l'impact de la fusion sur l'ordonnancabilité du système va être de réduire le nombre de préemptions possibles. Il s'agit d'une politique conservatrice, puisque le système optimisé n'éliminera qu'une partie des préemptions possibles dans le système original.

Dans cette partie, nous justions et décrivons ces deux critères, théorèmes REAL à l'ap- pui. Nous justions et fournissons également la relation d'ordre entre les threads nécessaire à l'algorithme FGH.

Fonction de valeur basée sur les connexions

Nous avons vu que le principal facteur susceptible de modier l'évaluation du WCET est la suppression des connexions inter-threads. Dans une moindre mesure, le coût de l'ordonnancement local (en terme d'ajouts de context_switchs) a également un certain impact.

−− _{C a l c u l e l a r e d u c t i o n de WCET due a l a s u p p r e s s i o n s de} −− _{communications i n t e r −t h r e a d s} theorem i n t e r _ t h r e a d _ c o n n e c t i o n s _ v a r i a t i o n foreach t h r i n l o c a l _ s e t do emiter_cnx := { cnx i n c o n n e c t i o n _ s e t | i s _ a c c e s s i n g _ t o ( cnx , t h r ) } ; o t h e r s := { th i n l o c a l _ s e t | is_accessed_by ( th , emiter_cnx ) and th <> t h r } ; i n t e r _ c n x := { cnx i n emiter_cnx | i s _ a c c e s s i n g _ t o ( cnx , o t h e r s )

and i s _ a c c e s s i n g _ t o ( cnx , t h r ) } ; var c o n n e c t i o n _ c o s t := 5500; −− Comes from e m p i r i c a l s t u d i e s var t o t a l _ t r a n s m i s s i o n _ c o s t := c o n n e c t i o n _ c o s t ∗ C a r d i n a l ( i n t e r _ c n x ) ; r e t u r n (Msum ( t o t a l _ t r a n s m i s s i o n _ c o s t ) ) ; end i n t e r _ t h r e a d _ c o n n e c t i o n s _ v a r i a t i o n ;

Listing 7.5  Fonction de valeur : coût des connexions supprimées

−− _{C a l c u l e une borne s u p e r i e u r e pour l e cout de l ' ordonnancement} −− l o c a l

theorem i n t r a t h r e a d _ s c h e d u l i n g _ c o s t _ v a r i a t i o n foreach s i n system_set do

tmp := { l i n Local_Set | (1 = 1 ) } ;

var thread_min := min ( p r o p e r t y ( tmp , " P e r i o d " ) ) ; var thread_gcd := gcd ( p r o p e r t y ( tmp , " P e r i o d " ) ) ; var r e l a t i v e _ c o s t := ( ( thread_min / thread_gcd ) −1) ∗

( 1 0 0 0 . 0 / thread_min ) ; var s c h e d u l i n g _ c o s t := 2 0 0 . 0 ;

−− A c t u a l c o s t o f a c o n t e x t s w i t c h on ERC32/Ork s y s t e m s var b a l a n c i n g _ f a c t o r := 1 . 0 ;

−− _{We want to e x a g e r a t e the overhe ad due to non−e q u a l s d e a d l i n e s} r e t u r n (MSum ( r e l a t i v e _ c o s t ∗

s c h e d u l i n g _ c o s t ∗ b a l a n c i n g _ f a c t o r ) ) ; end i n t r a t h r e a d _ s c h e d u l i n g _ c o s t _ v a r i a t i o n ;

Listing 7.6  Fonction de valeur : coût des context switch ajoutés

La première valeur peut être estimée grâce au théorème REAL du listing 7.5. On peut obtenir une valeur approchée de la seconde valeur en calculant la diérence entre le minimum des périodes des threads d'origine et le quantum du thread fusionné (donc le PGCD des périodes des threads d'origine). Le listing7.6donne le code REAL correspondant à ce calcul. Finalement, nous assemblons ces deux indicateurs avec le théorème présenté dans le listing7.7.

−− _{Impact e s t i m e du merge des t h r e a d s c o n t e n u s dans l o c a l _ s e t} −− _{s u r l e WCET} theorem compute_wcet_variation foreach s i n system_set do var i n t r a := compute i n t r a t h r e a d _ s c h e d u l i n g _ c o s t _ v a r i a t i o n ( l o c a l _ s e t ) ; var i n t e r := compute i n t e r _ t h r e a d _ c o n n e c t i o n s _ v a r i a t i o n ( l o c a l _ s e t ) ; r e t u r n (msum ( i n t e r − i n t r a ) ) ; end compute_wcet_variation ;

7.2. Procédure de tests

Listing 7.7  Fonction de valeur basée sur les connexions Fonction de valeur basée sur les périodes

Nous avons vu que, pour un thread fusionné  et à ordonnanceur constant, le nombre de context switch augmente avec la diérence entre la période minimale des threads et leur PGCD. Un autre élément à prendre en compte est que la faisabilité d'un merge diminue au fur et à mesure que le PGCD des périodes des threads candidats au merge diminue. Il en résulte que des merges eectués entre des threads ayant des périodes proches (en terme de décomposition en nombre premiers) font moins diminuer la faisabilité du système. Un critère de fusion qui favorise l'exploration de l'espace des solutions est donc de minimiser la distance entre la période des threads fusionnée. Le listing7.8est un théorème REAL calculant cette valeur.

−− _{C a l c u l e l a d i s t a n c e e n t r e l e max des p e r i o d e s e t l e u r PGCD} theorem compute_merging_cost_variation

foreach s i n system_set do

s e t := { s2 i n l o c a l _ s e t | (1 = 1 ) } ;

var old_threads_max_period := (max ( p r o p e r t y ( se t , " p e r i o d " ) ) ) ; var new_thread_period := (GCD ( p r o p e r t y ( se t , " p e r i o d " ) ) ) ; var b a l a n c i n g _ f a c t o r := 100000;

−− The b a l a n c i n g f a c t o r i s put i n o r d e r to b a l a n c e the r e s u l t −− _{with the memory v a l u e}

var d i s t a n c e := ( ( new_thread_period / old_threads_max_period ) ∗ _{b a l a n c i n g _ f a c t o r ) ;}

r e t u r n (msum ( d i s t a n c e ) ) ;

end compute_merging_cost_variation ;

Listing 7.8  Fonction de valeur basée sur les périodes Fonction de valeur : inuence de l'occupation mémoire

Nous avons proposé des fonctions de valeur prenant en compte le coût en WCET ou la faisabilité future d'une opération. Il nous faut cependant prendre en compte la réduction poten- tielle de l'empreinte mémoire. A cet eet, nous proposons le théorème REAL 7.9. Le résultat de la fonction d'évaluation sera la combinaison linéaire du résultat de ce théorème et d'un des précédents.

−− Compute

theorem memory_consumption_variation foreach s i n system_set do

var t h r e a d s _ d e l e t e d := compute deleted_thread_number ( l o c a l _ s e t ) ; var t h r e a d _ v a r i a t i o n := i f t h r e a d s _ d e l e t e d > 0

e l s e 0 ; r e t u r n (msum ( t h r e a d _ v a r i a t i o n ∗ 7 ) ) ;

−− An AADL t h r e a d t a k e s around 70 KB o f memory end memory_consumption_variation ;

−− Compute the memory f o o t p r i n t o f a g i v e n theorem deleted_thread_number

foreach t i n l o c a l _ s e t do r e t u r n (Msum ( 1 ) ) ;

end deleted_thread_number ;

Listing 7.9  Fonction de valeur : calcule de la mémoire

On remarquera que le coût d'un thread en mémoire est considéré comme constant. Il s'agit bien sur d'une simplication : un calcul plus précis devrait prendre en compte les proprié- tés AADL standard Source_Data_Size, Source_Stack_Size et Source_Heap_Size. En ce qui concerne la seconde valeur, celle-ci peut être calculée à partir d'un outil adapté, ou déduite de la connaissance de la taille de la pile du code métier, et de la surcharge apportée par le processus d'optimisation. La troisième valeur vaut toujours 0, car l'allocation dynamique est interdite par nos options de compilation, en accord avec le prole haute intégrité pour Ada Ravenscar. Relation d'ordre entre les threads

Finalement, il fallait déterminer une relation d'ordre qui permette d'eectuer un tri sur les threads en fonction d'un thread donné. Ce tri devrait ranger les autres threads du process dans l'ordre de gain potentiel en cas de tri avec le premier thread. Il nous faut donc déterminer une fonction qui permette de déterminer le résultat (en terme de performances) d'une fusion entre deux threads (et non entre N threads, comme dans le cas de la fonction d'évaluation).

Nous proposons une solution similaire à la fonction d'évaluation CB : simplement compter les connexions entre les deux threads. Le listing 7.5est toujours applicable.