Adaptabilité à la QoS et amélioration de la scalabilité

8.4.3.1 Prise coordonnée de points de contrôle avec réduction du

nombre des diffusions

Compte tenu de sa simplicité dans la synchronisation d’un état global, cohérent et sans faute, la prise coordonnée de points de contrôle est préférable dans la pratique. Cepen-dant, avec le nombre croissant de PEs, la méthode coordonnée souffre d’une mauvaise scalabilité [EP04]. Ceci est dû au fait que la synchronisation globale nécessaire pour construire un état global cohérent induit un surcoût de communication important pour les grands systèmes, ce qui augmente la latence des points de contrôle (le temps nécessaire à

Chapter 8. Résumé en français (French Summary)

l’exécution du protocole pour enregistrer un nouveau point contrôle, y compris la syn-chronisation globale). La période minimale de points de contrôle est limitée par la latence de points de contrôle. Par conséquent, une grande latence de points de contrôle force des périodes de points de contrôle plus larges. En cas de défaillance, ces périodes plus larges donnent lieu à des plus ample restaurations, et par conséquent à des temps de récupération plus importants (puisque l’intervalle d’exécution depuis le point de contrôle est perdu), impactant ainsi la performance du système. En outre, si la durée de synchro-nisation est plus grande que le MTTF, il n’y a pas de temps pour prendre de nouveaux points de contrôle global entre deux défaillances successives. Dans de tels cas, des récupérations sont effectuées au même ancien point de contrôle et donc, l’exécution de l’application n’avance pas. Dans le cas d’une coordination de la prise de points de contrôle, la durée de synchronisation globale est aussi appelée durée de point de contrôle (global). Par conséquent, dans le cas d’une coordination de la prise de points de contrôle, non seulement la surcharge induite par la prise des points de contrôle local doit être réduite, comme dans le cas de la prise non coordonnées de points de contrôle, mais aussi la durée de synchronisation globale, puisque les points de contrôle locaux n’ont pas de sens tous seuls dans ce cas (c.-à-d. CC).

Notre objectif est d’améliorer la scalabilité du mécanisme de récupération par points de contrôle en réduisant la durée de synchronisation globale et donc la latence de point de contrôle.

Lorsque le protocole classique de prise de points de contrôle coordonnée est utilisé, plusieurs diffusions (broadcasts) sont effectuées. Les diffusions qui chargent de façon significative la structure de communication sont celles qui sont envoyées entre les tâches pour s’informer mutuellement qu’elles ont commencé leurs phases de prise de point de contrôle. Ces messages sont appelés CK_START et sont marqués par des lignes pointil-lées sur la Fig. 8-5.a. Ils introduisent une surcharge d’environ n² messages dans le réseau, où n représente le nombre de PEs dans le système. Ce nombre devient important lorsque le nombre de PEs augmente : 12 messages pour un NoC en maille 4x4, mais 65280 messages pour un NoC en maille 16x16! En outre, l’envoi de ces messages est un processus en rafale, et aura tendance à créer de la congestion, et par conséquent, à augmenter la latence de points de reprise.

a. Protocole coordonné classique b. Protocole avec nombre réduit de diffusions

Fig. 8-5 Réduire le nombre de diffusions dans le protocole coordonné

Dans le protocole coordonné optimisé, les diffusions « tous-à-tous » entre les tâches sont remplacées par la transmission d’un seul message par tâche (CK_START envoyé à la RMU par toutes les tâches) et une diffusion (CK_START_ALL envoyée à toutes les tâches par la RMU). Ces messages sont marqués par une ligne pointillée sur la Fig. 8-5.b.

Chapter 8. Résumé en français (French Summary)

Le nombre de messages de synchronisation est donc réduit de O(n²) à O(n). Le protocole de restauration associé est inchangé.

Les résultats de simulation montrent une amélioration significative de la scalabilité lorsque la prise de points de contrôle utilise le protocole avec un nombre réduit de diffusions.

8.4.3.2 Prise de points de contrôle coordonnée bloquante et non

bloquante

La prise de points de contrôle coordonnée avec blocage (B) et coordonnée sans blocage (NB) ont été toutes deux proposées (les tâches bloquent ou non leur exécution normale au cours de la prise de points de contrôle).

Les durées de prise de points de contrôle avec et sans blocage sont approximative-ment les mêmes pour des charges très faibles de trafic. Toutefois, avec l’augapproximative-mentation de la charge de trafic, cette durée augmente de manière significative dans le cas non-bloquant, alors que dans le cas non-bloquant, celle-ci n’est pas affectée. Ceci s’explique par l’existence ou non du trafic « supplémentaire » dans le NoC, dû à l’application. Dans le cas non-bloquant, le trafic de récupération est considérablement retardé par le trafic des applications. Dans le cas avec blocage, comme le trafic de l’application est arrêté, le trafic de récupération n’est pas retardé.

Normalement, l’exécution globale de l’application est retardée dans l’approche avec blocage, puisque l’application est bloquée durant les phases de prise de points de contrô-le. Cela peut être observé pour des taux de défaillance relativement faibles. Toutefois, pour des taux de défaillance plus élevés, l’approche avec blocage induit une latence inférieure à celle de l’approche sans blocage. En outre, l’approche non-bloquante devient inefficace pour des taux de défaillance plus élevés, ce qui n’est pas le cas pour celle avec blocage. En fait, comme la durée de prise de points de reprise est plus grande dans le cas sans blocage que dans celui avec le blocage, l’intervalle de temps entre deux défaillances successives n’est pas assez long pour pouvoir prendre un nouveau point de contrôle sans blocage. Ainsi, dans l’approche non-bloquante, la probabilité de restauration à partir du même ancien point de contrôle augmente. En conséquence, des parties de l’application sont ré-exécutées à plusieurs reprises, ce qui conduit à une latence extrêmement élevée. Pour des charges de trafic supérieures, la même tendance est maintenue, mais le point d’intersection entre les deux approches se produit pour une valeur inférieure du taux de défaillance.

Ainsi, des approches différentes (avec blocage ou sans blocage) sont préférables pour des charges de trafic et taux de défaillance différents.

Nos deux protocoles coordonnés (le protocole de base et celui avec le nombre réduit de diffusions) peuvent être réalisés avec ou sans blocage de l’exécution de la tâche durant la prise de point de contrôle. La même séquence d’actions est exécutée dans les deux approches, si ce n’est que l’exécution de la tâche est bloquée pendant la prise bloquante. Toutefois, pendant la prise de point de contrôle, les messages tardifs (late) sont enregistrés et feront partie du point de contrôle. Ce choix (au lieu d’attendre que les canaux du réseau soient vides) réduit la durée de prise de points de contrôle. Puisque le protocole avec blocage et celui sans blocage sont les mêmes, chaque tâche peut participer à la prise globale de points de contrôle, en bloquant ou non son exécution normale, indépendamment des autres tâches. Un état global cohérent est sauvegardé, indépen-damment de la configuration (bloquante / non-bloquante) des tâches.

Chapter 8. Résumé en français (French Summary)

La décision de bloquer ou non l’exécution normale peut être prise pour chaque tâche et pour chaque point de contrôle global, en fonction des exigences de qualité de service de l’application et du trafic dans le NoC. Par exemple, si l’exécution d’une tâche est critique à l’application ou en temps réel et ne doit pas être interrompue pendant la prise du point de contrôle global, celle-ci participera à la prise de point de contrôle sans bloquer son exécution. D’autre part, si une tâche entraîne une charge de trafic élevé, mais que son exécution n’est pas critique, elle sera bloquée. Cela est dû au fait que la durée de prise de points de contrôle peut être étirée exactement par le trafic élevé dans le NoC ; ainsi, bloquer les tâches qui induisent un tel trafic peut contribuer à la réduction de cette période.

Dans notre modèle, la décision B-NB d’une tâche est indépendante des choix des au-tres tâches, car les tâches peuvent enregistrer leur état à tout moment. Sans cette possibilité, d’autres restrictions sur le choix de B-NB doivent être considérées, comme la décision commune pour les groupes de tâches communicantes.

8.4.3.3 Diffusion optimisée

Dans la sous-section 8.4.3.1, nous avons montré que lorsque le nombre de diffusions (broadcasts) est réduit dans le protocole de synchronisation CC, la scalabilité en est améliorée. Cependant, une seule diffusion peut provoquer de la congestion dans le réseau, si un routage classique point-à-point est utilisé. Dans cette sous-section nous proposons l’utilisation d’une diffusion optimisée pour la synchronisation globale des tâches. Nous considérons des topologies en maille (mesh) pour l’illustrer, mais le même raisonnement peut être appliqué pour d’autres topologies.

Un algorithme classique de diffusion à n nœuds injecte n messages dans le réseau. Comme il n’y a pas de lien dédié entre tous les PEs, les messages envoyés par une diffusion suivent certains liens communs avant d’arriver à leurs destinations respectives. Ainsi, un nœud près de la source de diffusion doit passer plusieurs messages à d’autres nœuds, alors que leur contenu est identique. La Fig. 8-6.a illustre le chargement des liens dans un scénario classique de diffusion à partir du nœud central d’un maillage 9x9, en utilisant un routage statique XY. Les liens horizontaux sur la même ligne que le nœud expéditeur doivent supporter une charge de trafic très élevée, en particulier les liens plus proches de l’expéditeur. Il peut être observé dans la figure que la charge sur les liens est très déséquilibrée.

a. Diffusion classique par routage XY b. Diffusion optimisée

Fig. 8-6 Diffusion classique vs. diffusion optimisée

Un exemple de diffusion efficace « un-à-tous » pour les réseaux maillés est illustré dans la Fig. 8-6.b, pour le même maillage 9x9. Cette diffusion est basée sur un algorithme simple [YW99] qui implique la duplication de message à la volée. Le nœud

Chapter 8. Résumé en français (French Summary)

source envoie le message à diffuser uniquement à ses voisins de premier rang (distance Manhattan de 1). Ensuite, chaque nœud fournit le message à son PE associé et transmet des copies de celui-ci à ses voisins de premier rang, de façon que chaque nœud reçoive le message une seule fois. La charge de trafic sur les liens en est alors équilibrée et minimale.

Les résultats obtenus montrent l’efficacité de cette technique appliquée à la prise coordonnée de points de contrôle par rapport à une diffusion XY classique. Les résultats de simulation indiquent que l’amélioration relative, en termes de latence et de surcoût mémoire, devient plus importante avec l’augmentation du nombre de PEs, en améliorant significativement la scalabilité du mécanisme de récupération par points de contrôle.

8.4.3.4 Configuration des partitions

Les applications fonctionnant sur les plates-formes MPSoC peuvent être partitionnées en plusieurs groupes de communication. En outre, plusieurs applications distinctes peuvent fonctionner en même temps dans un MPSoC. Ainsi, on peut considérer séparément les différentes partitions de l’application(s) pour les points de reprise. Ainsi, les caractéristi-ques essentielles des protocoles de tolérance aux fautes peuvent être améliorées, c’est-à-dire que le temps pour déterminer la ligne de récupération (dans le cas de UC) et la durée de synchronisation globale (dans le cas de CC) peuvent être réduits. Nous proposons deux configurations de récupération optimisées pour le protocole coordonné, qui peuvent également être adaptées et appliquées à l’approche non coordonnée de prise de points de contrôle.

Les configurations de récupération optimisées profitent des phases d’opération de NoC lorsque le modèle de communication est partitionné. Ainsi, afin de réduire la latence de point de contrôle, il suffit que chaque tâche prenne son point de contrôle en coordination seulement avec les tâches de sa propre partition. Dans la Fig. 8-7, les deux configurations optimisées de RMU (unité de gestion de récupération) sont représentées : RMU partagée et RMU multiples. Les nœuds exécutant des tâches dans la même parti-tion sont représentés avec la même texture (dans cet exemple nous supposons que si plusieurs tâches sont en cours d’exécution sur une même unité de calcul, ils appartien-nent à la même partition de l’application).

a. RMU partagée b. RMU multiples

Fig. 8-7 Configurations optimisées de RMU

Pour le cas RMU partagée (Fig. 8-7.a), la même RMU est utilisée par toutes les partitions pour toutes leurs synchronisations intra-partition. Une RMU partagée est plus complexe, car elle doit être capable de gérer les synchronisations de plusieurs partitions. Symboliquement, elle est représentée de plusieurs parties gérant indépendamment chaque partition. Toutefois, les synchronisations de partition ne sont pas traitées séquentiellement (c’est-à-dire une nouvelle synchronisation d’une partition ne doit pas attendre la fin de l’actuelle), ainsi cette RMU réduit ces latences en permettant le recouvrement des synchronisations des partitions différentes.

Chapter 8. Résumé en français (French Summary)

Dans la configuration RMU multiples (Fig. 8-7.b), chaque partition a une RMU dé-diée pour ses synchronisations intra-partition. Chaque RMU est représentée avec la même texture que la partition correspondante. Dans cette configuration, les RMUs ont besoin de gérer les synchronisations dans une seule partition ; ils agissent comme des RMUs simples pour leur partition respective. Cette solution nécessite des coûts plus élevés, vu que plusieurs RMUs doivent être disponibles dans le NoC. Toutefois, elle permet de meilleures performances lorsque les tâches de communication sont localisées, car chaque RMU peut être située à proximité de sa partition, ou, idéalement, dans le point central de la partition. Ainsi, la latence de communication entre les tâches et la RMU correspondante est réduite.

Afin de suggérer l’avantage de la localisation de RMUs multiples, les tâches d’une même partition sont représentées comme localisées dans la Fig. 8-7.b et non localisées dans la Fig. 8-7.a. Toutefois, les deux configurations peuvent être utilisées que les partitions soient localisées ou non.

Les résultats de simulation montrent que les configurations de RMU partagée et multiples améliorent considérablement les capacités de récupération du système pour des taux de défaillance élevés. Pour un maillage de 4x4, les performances entre RMU partagée et RMU multiples sont comparables, mais avec un coût plus réduit pour le cas RMU partagée. De plus, il est à noter que d’autres configurations peuvent également être utilisés, tels que plusieurs RMUs partagées.

8.5 Routage inter-couche tolérant aux fautes