Surveillance de l’application

La partie surveillance est une partie primordiale pour garantir la réactivité de la mé- thode de Load-Balancing en alimentant les parties suivantes de la méthode avec des données et statistiques à jour. Plusieurs paramètres clés, identifiés dans le chapitre précédent et in- tégrés dans le modèle applicatif, sont donc surveillés sur une période T par cette partie pour chaque étage (ou acteur) i :

— T di : le temps nécessaire au calcul de chaque donnée,

— Rini : le nombre de données consommées sur une période T ,

— Routi : le nombre de données produites sur la période T ,

74 CHAPITRE 4. SUPPORT DE LA DYNAMICITÉ

Figure 4.3 – Les trois étapes de la méthode d’équilibrage de charge proposée : la surveillance de l’application qui permet de détecter un mauvais parallélisme, le calcul du nouveau pa- rallélisme, l’adaptation du parallélisme au nombre de ressources de calcul et la vérification de l’intérêt du changement de parallélisme.

Figure 4.4 – Chaque lecture ou écriture de donnée est comptée, ceci permet de quantifier le nombre de données lues et écrites sur une période et de déduire le temps nécessaire au calcul de chaque donnée.

4.3. APPROCHE PROPOSÉE POUR L’ÉQUILIBRAGE DE CHARGE 75

Ces paramètres sont mesurés en surveillant les échanges de données entre les tâches (Figure 4.4). Ainsi, à chaque fois qu’une tâche souhaite lire ou écrire une donnée dans les mémoires FIFO, une requête est envoyée. Ensuite, dès que la donnée est disponible, le temps d’attente est comptabilisé. Les nombres de données consommées et produites sont mesurés de la même manière.

L’application étant très dynamique, les données mesurées fournissent une information sur le comportement instantané. Il est donc important de calculer à partir de ces données le comportement moyen de l’application et pas uniquement le comportement instantané. Pour cela, un lissage des données mesurées est effectué en filtrant les mesures qui s’écartent du comportement moyen. Le lissage des données est réalisé au travers d’une moyenne glissante qui permet de calculer la moyenne des valeurs mesurées sur une fenêtre de temps donnée.

Figure 4.5 – Exemple de moyenne glissante sur 10 et 50 données. Les données d’origine proviennent de l’étage rasterizer (temps par donnée T d). Ensuite deux moyennes glissantes sont affichées, sur une fenêtre de 10 (EMAd 10 valeurs) et 50 données (EMAd 50 valeurs).

Sur la Figure 4.5, on peut remarquer l’impact du lissage des données. Sur 10 données, le lissage est plus réactif aux modifications, tandis que sur 50 données, le lissage est insensible aux grandes variations et ne donne ainsi que la tendance moyenne.

Il existe plusieurs méthodes pour calculer une moyenne glissante, les principales sont : — classique : on garde les N derniers échantillons et on calcule la moyenne, ce qui

impose de sauvegarder toutes les valeurs de la fenêtre ;

— pondérée : des coefficients peuvent être ajoutés afin de donner davantage d’impor- tance à certaines valeurs, comme les plus récentes par exemple ;

— exponentielle : la moyenne glissante est recalculée à chaque nouvelle valeur, ce qui évite de stocker les valeurs intermédiaires (équation 4.1).

EM At= EM At 1+ ↵⇥ (compteur EM At 1) (4.1)

Le principal avantage de la moyenne exponentielle est qu’il n’y a pas besoin de stocker toutes les valeurs. De plus, le nombre de valeurs moyennées ne dépend que d’un coefficient ; il est alors facile de changer le nombre de valeurs en ajustant ce coefficient.

Le temps passé à attendre la disponibilité des données est indicateur de la bonne pa- rallélisation de l’application. Un temps faible signifie que toutes les tâches ont des données

76 CHAPITRE 4. SUPPORT DE LA DYNAMICITÉ

disponibles immédiatement et, par conséquent, que les données sont produites au rythme auquel elles sont consommées. Si elles sont produites trop vite, la mémoire intermédiaire va se remplir et dans ce cas, ce sera la tâche émettrice de la donnée qui sera bloquée, dans l’attente d’une place dans la mémoire de sortie. Dans le cas où les données seraient consommées plus vite que le rythme auquel elles sont produites, le temps d’attente des données en entrée sera important car la mémoire FIFO d’entrée sera vide.

L’application étant dynamique, le parallélisme n’est jamais idéal pour l’application à l’instant t. Il est donc important de définir un seuil pour ce temps de blocage, à partir duquel on décide de lever une alerte qui pourra amener à remettre en question la parallélisation (Figure 4.6). Ce seuil peut être mesuré pour chaque tâche ou par étage. Dans le premier cas, le seuil est fixe, par exemple 50 % du temps de la période de mesure. Dans le second cas, le seuil va dépendre du nombre de tâches de l’étage. Si celui-ci ne comporte qu’une seule tâche, le seuil peut être le même que celui de l’exemple précédent. Cependant, si l’étage comporte cinq tâches, le seuil sera plus bas car, par exemple, 20% de temps de blocage signifie qu’en moyenne, il y a constamment une tâche en attente de données et, dans ce cas là, une modification du parallélisme peut s’avérer utile. De manière générale, un seuil trop bas risque de créer des remises en question du parallélisme non désirées et inversement, un seuil trop haut engendre une insensibilité qui peut conduire à des changements de parallélisme tardifs.

Figure 4.6 – L’évaluation du temps d’attente se fait en mesurant les temps pendant lesquels la tâche est bloquée. Ici par exemple, la tâche 1 ne travaille pas entre 3 et 5 ms, on peut donc en déduire que pour une période de 10 ms, le processeur a été bloqué pendant 40 % du temps. Du point de vue de l’étage, toutes les tâches le constituant doivent être prises en compte pour le calcul du temps de blocage.

Les paramètres clés identifiés dans la partie surveillance sont mesurés pour chaque étage de notre application pipeline et sont moyennés. Pour cela, plusieurs paramètres sont définis :

— T : la période pendant laquelle les données (nombre de données consommées et produites) sont mesurées avant d’être moyennées,

4.3. APPROCHE PROPOSÉE POUR L’ÉQUILIBRAGE DE CHARGE 77

données sont moyennées ; elle est donc supérieure au paramètre précédent, — Si : le seuil de temps de blocage au-delà duquel on décide de lever une alerte,

— Pinhib : la période d’inhibition des alertes pendant laquelle aucune alerte ne sera

envoyée, ce qui évite de remettre en question le parallélisme juste après l’avoir modifié.