4.3
Problématique de thèse
Comme expliqué ci-dessus, la maîtrise des interférences sur les processeurs multi- cœurs, nécessaire pour calculer un WCET, demande de définir une stratégie d’utilisation ainsi qu’une stratégie de contrôle sur le processeur.
Les politiques d’arbitrage TDMA constituent une stratégie d’utilisation applicable sur des processeurs COTS. Cette solution n’est sûrement pas la plus efficace, dans la mesure où elle interdit tout parallélisme alors que les processeurs COTS peuvent effectuer un certain nombre de traitements en parallèle. Néanmoins elle résout le problème de la stratégie d’utilisation.
À l’inverse, le problème de la stratégie de contrôle est ouvert. En effet, on sait que le processeur ne permet pas d’offrir un niveau de contrôle adéquat sans une intervention du logiciel, que nous appelons logiciel de contrôle. On ne sait pas non plus comment concevoir un tel logiciel, ni comment ce dernier doit utiliser les ressources matérielles à sa disposition.
Nous nous intéressons à l’approche présentée par Jegu et al. dans un brevet d’Airbus [54], et résumée dans la section 3.3.3. Les auteurs présentent un concept de logiciel de contrôle, qui a vocation à être déployé sur chaque cœur du processeur et à exécuter une tâche par cœur en contrôlant ses accès aux ressources communes. Chaque tâche est découpée en une séquence de phases d’exécution interne et de phases de communication avec les ressources communes. Durant une phase d’exécution, les données et instructions nécessaires sont stockées dans une mémoire cache privée. Les phases de communication sont réalisées par le logiciel de contrôle à des dates définies statiquement, lors desquelles il effectue les transferts utiles et charge les données et instructions pour la phase d’exécution suivante. Ainsi, on a bien une stratégie de contrôle mise en œuvre par du logiciel, puisque les dates de tous les accès aux ressources communes sont maîtrisées.
Bien que cette piste soit un candidat sérieux pour résoudre notre problème, elle pré- sente plusieurs limites, qui portent sur l’absence de rétrocompatibilité avec le logiciel existant (cf. contrainte (iii) page 54 ), ainsi que l’absence d’implémentation de ce logiciel de contrôle. Notre problématique de thèse porte donc sur l’opportunité de mettre en place une stratégie de contrôle du processeur mettant en œuvre un logiciel de contrôle, tout en assurant la rétrocompatibilité avec le logiciel applicatif existant. Nous nous inté- ressons à deux aspects du logiciel de contrôle, portant respectivement sur sa faisabilité sur un processeur donné, et sur l’existence d’une implémentation efficace dans un certain domaine d’applications.
Chapitre 4. Problématique
4.4
Synthèse
La problématique que nous abordons dans cette thèse détaille un problème de haut niveau : la maîtrise des WCET d’un ensemble de tâches déployées sur un processeur multi- cœurs COTS. Cette maîtrise est actuellement impossible à cause d’interférences dans le processeur dont on ne connait ni les circonstances dans lesquelles elles se manifestent, ni leur impact sur le temps d’exécution du logiciel. Nous cherchons à améliorer une approche existante, quoique peu développée, à base de logiciel de contrôle, qui vise à éliminer les interférences. Cette approche adresse ce problème dans un contexte proche du nôtre, sans la contrainte de rétrocompatibilité du logiciel existant.
Notre problématique de thèse s’articule autour des deux questions suivantes : • Comment concevoir et valider un logiciel de contrôle sur un processeur donné,
tout en préservant la rétrocompatibilité du logiciel existant ?
• Pour un processeur donné, existe-t-il une implémentation efficace du logiciel de contrôle sur un domaine d’application représentatif de l’avionique ?
Nous présentons dans le chapitre suivant une vue d’ensemble de l’approche que nous adoptons pour traiter cette problématique.
Chapitre 5
Approche
Sommaire
5.1 Définition et existence du logiciel de contrôle . . . . 59 5.2 Prototypage et étude de l’efficacité du logiciel de contrôle 61 5.2.1 Vue d’ensemble du prototype . . . 61 5.2.2 Efficacité du logiciel de contrôle . . . 62
Nous avons présenté dans le chapitre précédent notre problématique de thèse, qui porte sur les points suivants :
• la définition et l’étude de l’existence d’un logiciel de contrôle sur un processeur donné.
• l’existence d’une implémentation efficace du logiciel de contrôle sur un certain type d’applications.
Nous distinguons dans la suite du manuscrit le logiciel de contrôle du logiciel utile, qui fait l’objet du contrôle. Le logiciel utile sera selon les utilisations du logiciel applicatif, mais également un système d’exploitation.
Cette section présente l’approche que nous avons suivie dans cette thèse.
5.1
Définition et existence du logiciel de contrôle
Le logiciel de contrôle est en charge de mettre en œuvre une stratégie d’utilisation du processeur basée sur une politique d’arbitrage TDMA. À ce titre, son rôle majeur est d’effectuer lui-même, à des dates maîtrisées, toutes les opérations sur les ressources communes dont le logiciel utile a besoin pour s’exécuter correctement. Cela concerne les données et instructions du logiciel utile, qui sont stockées dans la mémoire principale, mais également les lectures et écritures sur les entrées/sorties.
De plus, nous attendons du logiciel de contrôle qu’il soit rétro-compatible vis-à-vis du logiciel avionique existant.
Chapitre 5. Approche
Pour définir le logiciel de contrôle, nous effectuons une analogie avec le cadre de virtualisation de Popek et Goldberg [69]. Dans ce cadre, les auteurs introduisent un logiciel appelé gestionnaire de machines virtuelles, ou hyperviseur dans la littérature plus récente. Cet hyperviseur est une forme de logiciel de contrôle, dans le sens où il se substitue au logiciel utile –appelé logiciel invité– pour effectuer toutes les opérations d’allocation de ressources matérielles. Cela concerne par exemple l’allocation d’espace mémoire, ou encore l’allocation de droits d’accès à un périphérique. En se substituant au logiciel utile, il peut effectuer un certain nombre d’opérations, par exemple vérifier que ce dernier a le droit de s’allouer ces ressources.
Popek et Goldberg définissent un hyperviseur comme un logiciel vérifiant les propriétés suivantes :
Contrôle de ressources. Le logiciel de contrôle intervient dans la totalité des cas où le logiciel invité tente de s’allouer des ressources. Il est en mesure d’effectuer correctement les opérations d’allocation pour le compte du logiciel invité, de telle sorte que ce dernier puisse s’exécuter correctement.
Équivalence. À l’exception de son temps d’exécution, le logiciel invité ne peut distinguer une exécution sous contrôle de l’hyperviseur d’une exécution sans hyperviseur, au cours de laquelle il s’alloue lui-même les ressources matérielles.
Efficacité. Toute opération neutre, i.e. non sensible vis-à-vis de l’allocation des res- sources ne fait pas l’objet d’un contrôle par l’hyperviseur.
Dans notre cas, le contrôle ne porte pas sur l’allocation de ressources mais sur les accès à ces mêmes ressources. Nous définissons notre logiciel de contrôle sur la base des deux premières propriétés, à savoir le contrôle des ressources et l’équivalence. La notion d’efficacité selon Popek et Goldberg est trop restrictive pour notre contexte, mais nous en adoptons une définition proche. Mis à part ces détails, les propriétés que nous attendons de notre logiciel de contrôle sont les mêmes. De plus, la propriété d’équivalence assure que le logiciel de contrôle préserve la rétrocompatibilité sur le logiciel existant. L’analogie entre les deux approches est donc pertinente.
Popek et Goldberg introduisent un théorème de virtualisation, qui conditionne l’exis- tance d’un hyperviseur vérifiant les trois propriétés ci-dessus. Nous cherchons à appliquer ce théorème, ou une version proche, pour notre logiciel de contrôle.
Dans notre contribution, développée dans le chapitre 6, nous montrons que le théo- rème de virtualisation de Popek et Goldberg ne permet pas d’assurer l’existence d’un logiciel de contrôle sur les accès aux ressources communes. Nous proposons à cet effet une généralisation de ce théorème, que nous appelons théorème de contrôlabilité. Le reste de cette contribution porte sur l’application du théorème de contrôlabilité, dans un premier temps sur un modèle simple de processeur, puis sur un processeur COTS. Il s’agit du P5040, de la gamme QorIQ commercialisée par Freescale, gamme à laquelle l’industrie avionique s’intéresse.
Cette contribution se termine par la spécification d’un logiciel de contrôle, dont nous étudions l’efficacité dans la seconde partie de la contribution.
5.2. Prototypage et étude de l’efficacité du logiciel de contrôle