Gestion du manque d’information sur les processeurs COTS

Le premier obstacle est lié à la contrainte d’utilisation de processeurs COTS. Il s’agit du manque d’informations communiquées par les fabricants sur leurs processeurs.

L’architecture des cœurs est en général correctement documentée pour permettre le développement de compilateurs optimisés. À l’inverse, la documentation du reste du processeur est en général restreinte à une description fonctionnelle des périphériques. Cette description peut être volontairement rendue incomplète par le fabricant pour éviter de communiquer des secrets industriels. C’est le cas notamment pour les interconnexions, qui sont dimensionnantes pour les performances du processeur. Une bonne connaissance de l’architecture d’une interconnexion est pourtant nécessaire pour y mener une analyse d’interférences.

Pour pouvoir définir correctement l’espace d’état d’une interconnexion, il est néces- saire de connaître avec un niveau de détails suffisant son architecture, les politiques d’arbitrages supportées, ainsi que son interface de configuration. Lorsque le processeur contient plusieurs niveaux d’interconnexions, cette exigence s’applique à chaque niveau.

3.2. Applicabilité des méthodes mono-cœurs dans un cadre multi-cœurs Or, on ne dispose que rarement de la totalité de ces informations. On rencontre les situations suivantes :

Architecture non documentée. Parfois, l’interconnexion est une boîte noire, comme

CoreNet, qui équipe les processeurs de la gamme QorIQ développée par Freescale, à laquelle l’industrie aéronautique s’intéresse. Seul le protocole de communication est décrit dans un brevet de Freescale [33].

Politique d’arbitrage non documentée. On peut relever les processeurs DSP26 _de

la gamme TMS320 fabriquée par Texas Instruments [93]. Pour cette famille de processeurs, l’interconnexion, appelée TeraNet, est décrite dans le manuel de ré- férence, incluant la matrice d’interconnexion et les registres de priorité. Toutefois, la politique d’arbitrage, qui se base sur des priorités statiques, n’est pas précisée. Description limitée à certaines IP. On dispose de spécifications assez détaillées de certaines IP comme CoreLink [15], développée par ARM. Toutefois, les proces- seurs de la famille ARM qui l’embarquent contiennent également un bus d’inter- connexion appelé Snoop Control Unit (SCU) qui est dépendante de l’implémen- tation et non documenté par ARM.

En pratique, l’architecture d’un processeur est rarement une boîte noire dont on n’a aucune information, mais plutôt une boîte plus ou moins grise. Il est possible d’effectuer des analyses d’interférences en utilisant des méthodes prenant en compte ce manque d’informations. Roger et Brindejonc [78] ont proposé le modèle Initiateur-Cible (initiator- target), à partir duquel ils identifient les cas de tests nécessaires pour une analyse d’in- terférences. Cette approche n’aborde cependant pas la question du nombre d’itérations à effectuer sur un cas de test donné pour obtenir une couverture correcte des interférences, qui à notre connaissance est toujours ouverte.

La gestion du manque d’information représente donc un premier obstacle, pour lequel la seule approche recommandée dans la littérature consiste à réduire la couverture de tests à un nombre atteignable, et faire en sorte que l’utilisation du processeur reste toujours couverte par ces tests.

3.2.3

Techniques d’analyse d’interférences

Supposons le point précédent résolu, et considérons un processeur pour lequel nous disposons d’un bon niveau d’informations sur l’architecture. Nous disposons des données permettant d’effectuer l’analyse d’interférences.

Pour effectuer une analyse d’interférences sur le processeur, on peut évaluer pour chaque composant la variabilité du temps de traitement –ou de traversée dans le cas d’une interconnexion– d’une requête, en faisant varier son état interne et les types de requêtes entrantes. L’objectif est d’identifier le pire cas d’interférences pour chaque composant.

Nous détaillons ci-après différents types d’analyses d’interférences, ou assimilées, que nous avons rencontré dans l’état de l’art.

26. Digital Signal Processing

Chapitre 3. Évaluation du WCET dans les processeurs multi-cœurs

Approches empiriques par benchmarks ciblés

La plupart des approches ciblant les processeur COTS sont empiriques, et visent à stresser un composant en particulier avec différents types de benchmarks pour observer les perturbations dues aux interférences. Elles doivent adresser les difficultés suivantes :

• Il est difficile de cibler un composant du processeur en particulier dans un bench- mark de stress. Ce dernier est limité par la possibilité d’un cœur, qui exécute le benchmark, à initier un stress efficace [24].

• Il faut distinguer les interférences de la variabilité naturelle du temps de traitement des requêtes entrantes par un composant. Or on observera systématiquement la somme des deux.

D’une manière générale, atteindre avec des benchmarks de stress la pire situation d’interférences dans un composant est un problème complexe, et non résolu dans la majeure partie des cas [75]. Toutefois, certaines approches rencontrées dans la littérature proposent des méthodes permettant d’estimer des pénalités d’interférences réalistes :

• Bin [24] a proposé la notion de signature d’une application, visant à quantifier le stress que celle-ci exerce sur chaque composant. Cette signature est obtenue par des benchmarks stressant de manière ciblée chaque composant. La combinaison des signatures de plusieurs applications permet d’estimer la charge globale exercée sur chaque composant du processeur, et d’identifier les composants à l’origine d’interférences. L’expérimentation de cette méthode est effectuée sur un P4080, qui est un processeur octo-cœurs fabriqué par Freescale.

• Radojkovic [75] propose une démarche proche de celle de Bin, expérimentée sur un processeur Intel Atom.

• Nowotsch [65] propose la notion de WCET sensible aux interférences (isWCET) dans laquelle chaque application dispose d’un budget en terme de stress exercé sur chaque ressource commune. Le WCET est calculé en appliquant une pénalité d’interférences déterminée à partir des budgets alloués aux différentes applications. À l’exécution, le système d’exploitation vérifie que chaque application respecte son budget.

Analyse d’interférence dans l’interconnexion

L’interconnexion est l’élément central dans un processeur multi-cœurs. Elle assure la propagation de requêtes, souvent appelées transactions dans la littérature. Le temps de traversée d’une interconnexion est la combinaison d’une latence technologique et d’une durée d’arbitrage, qui correspond au temps où une transaction est mise en attente pour obtenir l’autorisation d’être propagée. Selon la manière dont l’interconnexion est conçue, l’arbitrage peut être centralisé ou distribué. Une transaction peut même se faire arbitrer plusieurs fois au cours de sa traversée.

Les analyses d’interférences effectuées sur l’interconnexion portent principalement sur l’analyse des politiques d’arbitrage. Un recensement effectué par Bourgade [28, section 2.3] montre que certaines politiques n’amènent pas à une pénalité d’interférences bor-

3.2. Applicabilité des méthodes mono-cœurs dans un cadre multi-cœurs née. C’est le cas des protocoles à priorités fixes, et de certaines politiques “First In First Out”, pour lesquelles le temps de mise en attente dépend de la charge en nombre de transactions émise par chaque cœur. À l’inverse, l’auteur relève des familles de poli- tiques d’arbitrage qui permettent d’obtenir une pénalité d’interférences acceptable. Ces politiques sont basées sur un ordonnancement statique des accès de chaque cœur aux ressources communes. On parle souvent de politique TDMA27.

Le protocole d’interconnexion peut également être à l’origine d’interférences. Une étude de ce type a été effectuée par Shah [88] sur le protocole AMBA, qui est répandu dans les architectures ARM. Il a mis en évidence des phénomènes de verrouillage de bus (bus locking) qui peuvent entraîner un ralentissement entre des transactions successives, après la phase d’arbitrage. L’auteur relève que ce type d’interférence est souvent négligé dans les analyses menées sur l’interconnexion.

La politique d’arbitrage ainsi que celle du protocole d’interconnexion sont des élé- ments déterminants de l’analyse d’interférences. Sur des architectures simples on dispose de solutions qui sont prometteuses. La difficulté consiste à les appliquer sur des proces- seurs COTS, sur lequels la politique d’arbitrage est complexe, optimisée pour certaines opérations, et surtout non documentée. À notre connaissance, ce problème n’a pas été résolu dans la littérature.

Interférences causées par la cohérence de cache

Le trafic lié à la cohérence de caches est une source d’interférences connue dans les processeurs multi-cœurs, au point que divers travaux [45; 56] recommandent d’éviter son usage en désactivant les mécanismes associés. En effet, la cohérence de cache entraîne un trafic qui est propagé vers tout ou partie des cœurs, et qui augmente de manière quadratique avec le nombre de cœurs. C’est un des facteurs limitant pour l’augmentation du nombre de cœurs dans les processeurs qui offrent ce mécanisme.

L’exemple le plus frappant a été décrit par Nowotsch et Paulitsch [66] sur un pro- cesseur P4080, qui est un octo-cœurs fabriqué par Freescale. Les auteurs ont montré que dans des conditions où tous les cœurs initient un trafic important dans des plages mémoire proches, ce qui stresse les mécanismes de cohérence de caches, le trafic global est ralenti d’un facteur 20.

Dans un contexte IMA où le logiciel est fonctionnellement indépendant sur chaque cœur, la cohérence de caches n’est pas nécessaire au bon fonctionnement du logiciel embarqué, dans la mesure où il n’y a pas de partage de ressources entre les cœurs. Nous considérons donc dans nos travaux la question des interférences dues au trafic de cohérence de caches comme secondaire.

27. Time Division Multiple Access

Chapitre 3. Évaluation du WCET dans les processeurs multi-cœurs

Interférences sur les caches partagés

La plupart des processeurs multi-cœurs possèdent un niveau de cache partagé. Du point de vue d’un cœur, son contenu est susceptible d’être altéré de manière arbitraire, selon l’exécution du logiciel sur les autres cœurs. Divers travaux dans la littérature visent à borner cet impact, par exemple l’approche développée par Hardy [50] ou encore par Li [58].

Par ailleurs, il est souvent possible de partitionner ces caches, ce qui a pour finalité de simuler des caches privés, l’accès restant concurrent. Sur la plupart des processeurs, les caches partagés peuvent également être configurés comme des mémoires statiques, dont le contenu est déterminé à l’avance. Dans un contexte IMA où le logiciel concurrent n’est pas toujours connu, cette approche est recommandée.

Interférences sur les contrôleurs DRAM

Les contrôleurs de mémoires de type DRAM effectuent de nombreux types d’opéra- tions. Ils gèrent une mémoire organisée en banques, dont ils contrôlent l’état ouvert ou fermé, avec un nombre limité de banques ouvertes simultanément. Lorsqu’une banque est ouverte, son contenu peut être lu et modifié. La banque est organisée en lignes, que le contrôleur charge, et en colonnes qui sont toutes accessibles dans la ligne ouverte. Les ouvertures de lignes et ouvertures de banques entraînent des retards dans la réponse des contrôleurs de mémoire. De plus, ces derniers gèrent des files d’attente de requêtes entrantes qu’ils réordonnent pour minimiser les ouvertures de banques et/ou de lignes. Ces mécanismes sont à l’origine de nombreuses interférences.

Ainsi, Moscibroda a montré [63] que des applications peuvent interférer jusqu’à ralen- tir d’un facteur 3 lorsqu’elles utilisent le même contrôleur mémoire. L’auteur insiste sur le faible niveau de stress exercé par ses applications sur l’interconnexion, ce qui ramène toutes les interférences sur le contrôleur de mémoire.

On rencontre des méthodes d’analyse d’interférences sur les contrôleurs DRAM. Ainsi, Wu [101] propose d’intégrer une analyse d’interférences sur le contrôleur DRAM au cours de l’évaluation du WCET. Les résultats obtenus permettent d’améliorer les WCET obtenus par rapport à des contrôleurs de mémoire déterministes. À notre connaissance, cette méthode n’a pas été étendue à des contrôleurs de processeurs COTS.

Synthèse

Il existe un ensemble assez vaste de techniques d’analyses d’interférences que l’on peut appliquer sur un processeur, en supposant que l’on dispose d’informations sur son architecture et son comportement. Ces techniques sont pour la plupart locales à un composant, comme une interconnexion, un cache ou un contrôleur de mémoire, ou à des mécanismes, par exemple la cohérence de caches.

3.3. Alternatives pour l’évaluation du WCET sur des processeurs multi-cœurs