Gestion de la r´eactivit´e sur un syst`eme charg´e

Bien que les m´ethodes de scrutation pr´esent´ees dans la section pr´ec´edente permettent de d´etecter ra-pidement les ´ev´enements lorsque l’ordonnanceur a la main, elles souffrent d’un probl`eme de r´eactivit´e lorsque tous les processeurs sont constamment utilis´es. Le temps de r´eaction, born´e `a la dur´ee d’un

quan-tum de temps(timeslice), peut s’av´erer beaucoup trop ´elev´e pour les applications sensibles `a la latence. Il est alors n´ecessaire d’utiliser les fonctions de rappels bas´ees sur des interruptions que la biblioth`eque de communication fournit. Malgr´e le surcoˆut engendr´e par ces m´ethodes de d´etection, le temps de r´eaction ainsi obtenu est largement inf´erieur `a celui obtenu par scrutation dans ce contexte pr´ecis.

L’utilisation de m´ethodes bloquantes peut toutefois ˆetre probl´ematique dans le module de d´etection des ´ev´enements. En effet, celui-ci s’ex´ecute directement dans le contexte de la biblioth`eque de communi-cation ou de l’ordonnanceur. Un appel bloquant risque alors de bloquer l’ordonnanceur de thread ou la biblioth`eque de communication. Il convient donc de prendre certaines pr´ecautions et d’´eviter les appels bloquants dans un contexte non maˆıtris´e. Nous proposons d’utiliser des threads suppl´ementaires d´edi´es aux appels bloquants. Ces threads, endormis la plupart du temps, sont r´eveill´es pour effectuer un appel

54 CHAPITRE 5. PROPOSITION

bloquant `a la place d’un autre thread afin que ce dernier ne soit pas bloqu´e. Ainsi, les threads de l’appli-cation ne sont pas bloqu´es par les callbacks bloquants fournis au module de d´etection des ´ev´enements.

Le principe de fonctionnement de ces threads d´edi´es aux appels bloquants est d´ecrit par la Figure 5.2. Une r´eserve de threads est cr´e´ee `a l’initialisation du module de d´etection des ´ev´enements (1) afin de r´eduire le risque de souffrir du coˆut de cr´eation d’un thread pendant l’ex´ecution de l’application. Ces threads suppl´ementaires sont bloqu´es la plupart du temps en attendant une commande. Ils ne consomment donc pas de temps processeur et ne gˆenent pas les threads de l’application. Lorsqu’une fonction de rappel bloquante doit ˆetre ex´ecut´ee, un des threads suppl´ementaires est r´eveill´e et l’iden-tifiant de la requˆete `a traiter lui est transmise (2). Lorsque le thread suppl´ementaire est ordonnanc´e, il peut ex´ecuter le callback bloquant et ainsi attendre l’´ev´enement souhait´e (3). Un thread de l’application peut alors reprendre son calcul sur le processeur lib´er´e par le thread suppl´ementaire (4). Lorsque la carte r´eseau d´etecte la communication attendue, elle envoie une interruption et le thread de l’application est interrompu. Le thread bloqu´e en attente de cet ´ev´enement est alors r´eveill´e et il peut traiter la commu-nication (5). En traitant l’´ev´enement, le thread suppl´ementaire peut signaler `a l’application la fin d’une communication ou effectuer un traitement de communication (r´epondre `a un rendez-vous par exemple). Lorsque le callback se termine, le thread suppl´ementaire rejoint les autres threads suppl´ementaires en at-tente de nouvelles requˆetes et un thread de l’application – pas forc´ement celui qui vient d’ˆetre pr´eempt´e – peut reprendre son calcul.

Ce m´ecanisme permet donc au module de d´etection des ´ev´enements d’ex´ecuter des fonctions de rappel bloquantes sans gˆener les threads de l’application. Toutefois, un probl`eme de priorit´e peut survenir si le nombre de threads actifs est sup´erieur au nombre d’unit´es de calcul. Le thread suppl´ementaire risque alors de ne pas ˆetre r´eveill´e d`es que l’´ev´enement est d´etect´e, entraˆınant un temps de r´eaction plus long. En fonction des politiques d’ordonnancement du syst`eme d’exploitation, le comportement sera diff´erent : certaines strat´egies d’ordonnancement vont donner imm´ediatement la main au thread r´eveill´e, alors que d’autres se contentent de remettre le thread dans la liste des threads prˆets `a s’ex´ecuter et recalculer la priorit´e des threads pour en choisir un. Lorsque cela est possible, il est donc important de choisir une strat´egie permettant un ordonnancement rapide du thread. Si ce type de strat´egie d’ordonnancement n’est pas disponible, l’augmentation de la priorit´e des threads suppl´ementaires permet de donner une indica-tion `a l’ordonnanceur. Ainsi, mˆeme si le thread r´eveill´e ne sera pas toujours ordonnanc´e imm´ediatement, l’ordonnanceur aura quand mˆeme tendance `a lui donner la main rapidement.

Si l’utilisation de threads suppl´ementaires permet d’assurer un certain niveau de r´eactivit´e, le surcoˆut engendr´e par le traitement des interruptions et les changements de contexte a un impact certain sur le temps de r´eaction. Il convient donc de n’utiliser ce m´ecanisme que dans certains cas. D’une mani`ere g´en´erale, les appels bloquants ne doivent ˆetre utilis´es que lorsque le m´ecanisme de scrutation entraˆınerait un temps de r´eaction ´elev´e, par exemple lorsque tous les processeurs sont occup´es par des threads de l’application. Concevoir un m´ecanisme de d´ecision “parfait” (i.e. qui choisit toujours la m´ethode la plus adapt´ee) est impossible car cela n´ecessite de connaˆıtre le d´eroulement futur des communications. La d´ecision doit donc ˆetre prise en fonction d’une heuristique qui, en fonction de l’´etat de la machine, choisit une des m´ethodes disponibles. Outre l’occupation des processeurs, cette heuristique prend en compte les directives de la biblioth`eque de communication qui, dans certains cas, peut savoir s’il vaut mieux utiliser la scrutation plutˆot qu’un appel bloquant sur un thread suppl´ementaire. Cette heuristique reste imparfaite et n´ecessiterait un approfondissement afin de prendre en compte des directives donn´ees par l’application qui connaˆıt plus pr´ecis´ement les sch´emas de communication.

5.2. INT ´EGRATION DES COMMUNICATIONS DANS L’ORDONNANCEUR DE THREADS 55 1 2 3 4 6 5 Th4 Th3 Th2 Th1 Th4 Th3 Th2 Th1 Th1 Th2 Th3 Th4 Th4 Th3 Th2 Th1 Th4 Th3 Th2 Th1 STh1 _STh2 STh3 STh1 _STh2 STh3 STh1 _STh2 STh3 MX_wait Th4 Th3 Th2 Th1 STh2 STh3 STh1 STh1 STh1 _{STh2 STh3} STh2 STh3 CPU

CPU CPU CPU

CPU

CPU CPU

CPU CPU

CPU CPU CPU

56 CHAPITRE 5. PROPOSITION

Temps

CPU1 CPU2 CPU2

MPI_Isend MPI_Wait Accusé de Réception Données CPU1 MPI_Wait Récepteur Emetteur MPI_Irecv RendezVous

FIGURE5.3 – Progression des communication en arri`ere-plan grˆace au moteur de progression.