Synthèse de l’approche matérielle

L’utilisation d’un composant matériel pour accélérer une ou plusieurs primitives d’un sys- tème d’exploitation apporte toujours un gain très important en terme de performance. Ceci est d’autant plus vrai pour les architectures multiprocesseurs qui nécessitent davantage de contrôle. Finalement, rajouter un élément matériel supplémentaire ne contribue pas à la com- plexité du circuit. Ces quelques millimètres carrés de silicium simplifient les ressources de calcul et améliorent de manière très significative les performances du système.

Contrairement à l’approche logicielle, les accélérateurs matériels traitent avec beaucoup d’ef- ficacité les défauts liés à l’asymétrie de la structure multiprocesseur. La réduction des latences de synchronisation ou d’ordonnancement envisage une approche architecturale inconcevable jusqu’alors. De plus, ils permettent d’utiliser des ordonnancements dynamiques, voire même des ordonnancements inutilisables avec des solutions logicielles comme le LLF.

D’autre part, cette approche maîtrise et réduit les durées d’exécution du contrôle. Autrement dit, elle améliore le déterminisme et les temps de réponse de manière conséquente, en partie grâce à l’abandon du modèle en couches pour communiquer avec les ressources matérielles. Ceci a un effet très positif sur l’occupation des ressources de calcul. D’ailleurs, l’architecture SystemWeaver parvient à des taux d’occupation encore jamais atteints, malgré un algorithme de répartition de charge de faible complexité.

Ainsi, l’utilisation d’un composant matériel pour soutenir le système d’exploitation semble être incontournable lors de l’exécution de primitives de contrôle critiques. Le contrôle des architectures multiprocesseurs hétérogènes passe par une accélération du noyau temps-réel.

2.3 Synthèse

Ce second chapitre a permis d’explorer l’ensemble des solutions existantes pour contrôler les architectures multiprocesseurs. La première section a mis en évidence les limitations liées à l’utilisation d’une solution logicielle. L’emploi de couches d’abstraction logicielles simplifient la programmabilité des architectures, mais au détriment des performances. Là est tout le paradoxe que nous avons tenté de mettre en évidence. Finalement, aucune solution logicielle n’a été trouvée pour répondre à nos contraintes temps-réel.

Dans la seconde section, nous nous sommes intéressés à des solutions de contrôle accélérées par des éléments matériels. Elles mettent en œuvre des procédés complexes d’ordonnancement ou de synchronisation, sans trop pénaliser le système. Ainsi, elles sont les seules à pouvoir supporter la complexité du contrôle dans les architectures multiprocesseurs asymétriques. Ce- pendant, les approches qui intègrent des algorithmes d’ordonnancement ne sont pas suffisantes pour répondre aux besoins des futures applications mobiles. Elles ne permettent pas :

– de créer ou d’interrompre dynamiquement des tâches ou des applications ; – de gérer avec efficacité les synchronisations et les précédences entre les tâches ; – d’ordonnancer à la fois des tâches temps-réel et non-temps-réel ;

– de supporter l’exécution de tâches non-périodiques temps-réel ;

– de garantir au cours de l’exécution le respect des contraintes temporelles ; – de préempter et de changer dynamiquement la priorité ;

– de gérer les ressources de mémorisation et de calcul hétérogènes ; – de migrer efficacement les tâches entre les ressources de calcul ; – de gérer la consommation d’énergie ;

– et de faciliter la programmation.

Ainsi, une architecture de contrôle efficace pour les systèmes embarqués doit pouvoir ré- pondre à toutes ces exigences. Dans un premier temps, il nous faut néanmoins définir un modèle de multiprocesseur asymétrique qui doit être en mesure d’apporter une réponse aux problèmes soulevés dans la section 1.7 du premier chapitre. Dans un deuxième temps, les spécifications de l’architecture en charge du calcul doivent permettre de concevoir une archi- tecture de contrôle adaptée et de définir des solutions répondant de manière plus générale au contrôle de ces structures.

L’architecture SCMP-LC

Sommaire

3.1 Identification des problèmes liés aux multiprocesseurs . . . 50 3.1.1 Les dépendances de contrôle et de données . . . 50 3.1.2 L’occupation des ressources de calcul . . . 54 3.1.3 Le déterminisme . . . 56 3.1.4 Bilan des solutions proposées . . . 56 3.2 Présentation et caractéristiques de l’architecture SCMP-LC . . 57 3.2.1 Couplage et principe d’utilisation . . . 57 3.2.2 Caractérisation d’une tâche . . . 59 3.2.3 Modèle d’exécution . . . 60 3.3 Principe de l’exécution . . . 61 3.3.1 Exécution d’une application . . . 62 3.3.2 Exécution flot de données . . . 63 3.4 Caractérisation des ressources . . . 64 3.4.1 Ressources de calcul . . . 64 3.4.2 Ressources de mémorisation . . . 67 3.4.3 Ressources d’interconnexion . . . 69 3.5 Synthèse . . . 73

Le premier chapitre a mis en évidence l’intérêt de concevoir des architectures multipro- cesseurs pour répondre aux besoins des futures applications embarquées. Il a exploré les différentes solutions architecturales et souligné les avantages d’une approche asymétrique. Le second chapitre s’est donc intéressé au contrôle de ces architectures. Il a montré qu’une solution logicielle ne pourrait pas être utilisée, car elle pénaliserait les performances du sys- tème. En effet, même si un contrôle centralisé apporte de nombreux avantages, il devient la principale cause de limitation du système s’il n’est pas suffisamment réactif. Heureusement, l’utilisation d’un accélérateur matériel envisage à nouveau cette approche asymétrique.

Ainsi, ce chapitre présente une architecture multiprocesseur appelée (Loosely-Coupled SCa- lable Multi-Processor) (SCMP-LC). Avant d’introduire cette nouvelle architecture, il identifie les problèmes liés aux architectures multiprocesseurs, afin d’apporter une solution répondant

à toutes ces limitations. Ensuite, le modèle d’exécution de l’architecture SCMP-LC est pré- senté. Tout en étant proche du modèle CMP présenté dans le premier chapitre, notre nouveau modèle d’exécution facilite la préemption et la migration des tâches. Il met en œuvre des mé- canismes particuliers pour les communications et la gestion des ressources de mémorisation. Enfin, ce chapitre caractérise les différents éléments qui la composent et son principe d’exé- cution.

3.1 Identification des problèmes liés aux multiprocesseurs

De manière générale, les architectures composées de multiples ressources de calcul souffrent toutes de la mise en œuvre complexe des synchronisations, du partage des données et des dépendances de contrôle et de données. De plus, dans les structures hétérogènes, les problèmes de communication entre des entités de nature différente nécessitent l’utilisation d’interfaces supplémentaires [49]. D’autre part, des moyens de communication sous-dimensionnés et des temps d’exécution peu maîtrisés contribuent au non-déterminisme du système, ainsi qu’à une mauvaise utilisation de ses ressources. Pour concevoir un multiprocesseur performant, chacun de ces aspects doit être pris en compte et une réponse appropriée apportée afin de garantir des performances optimales. Dans un premier temps, nous nous intéressons aux synchronisations et aux dépendances de contrôle et de données.