FR2881244A1 - Procede de comptage d'instructions pour journalisation et rejeu d'une sequence d'evenements deterministes - Google Patents

Abstract

La présente invention concerne un procédé transparent et non intrusif de suivi et de gestion du déroulement des tâches exécutées dans un processeur informatique, en particulier dans des systèmes multiprocesseurs présentant une architecture parallèle. Cette gestion permet un enregistrement du déroulement de ces tâches sous forme de données de journalisation, ainsi qu'un rejeu correspondant à ce déroulement.Au cours d'une période d'activité (SchJ, SchR) dans un processeur informatique doté d'un compteur de suivi et de performance (PMC) présentant une certaine erreur relative, ce procédé comprend d'une part, une évaluation d'un nombre d'instructions exécutées (NR, NJ) en au moins un point déterminé de ladite période d'activité, à l'aide dudit compteur ; etd'autre part une génération d'une signature (SGJ, SGR) à partir de l'état du processeur correspondant à au moins un point déterminé de ladite période d'activité.

Description

Procédé de comptage d'instructions pour journalisation et rejeu d'une

séquence d'évènements déterministes

La présente invention concerne un procédé transparent et non intrusif de suivi et de gestion du déroulement des tâches exécutées dans un ou plusieurs processeurs informatiques, en particulier dans des systèmes multiprocesseurs présentant une architecture parallèle. Elle s'applique en particulier aux différentes tâches d'une application transactionnelle multitâche exécutée en réseau. Cette gestion permet en particulier un enregistrement du déroulement de ces tâches sous forme de données de journalisation, ainsi qu'un rejeu de ce déroulement à partir de telles données de journalisation de façon à présenter un comportement et un résultat correspondant à ceux obtenus lors de la journalisation.

L'invention concerne également un système mettant en oeuvre un tel 15 procédé dans la gestion du fonctionnement des applications logicielles qu'il exécute.

Une gestion de fonctionnement non intrusive et transparente vis à vis de l'application gérée est très intéressante à implémenter, en particulier pour pouvoir utiliser les nombreuses applications existantes, dans leur état d'origine ( legacy applications ), avec plus de souplesse ou de fiabilité ou de performance.

Des techniques de gestion de fonctionnement non intrusive par capture intermédiaire et restauration de l'état d'une application lors d'un point de synchronisation ou point de reprise ( checkpoint ) ont déjà été proposées par les mêmes demandeurs dans la demande de brevet FR 04 07180. De façon complémentaire, des techniques non intrusives de journalisation et rejeu ont déjà été proposées par les mêmes demandeurs, en particulier dans les demandes de brevet FR 05 00605 à FR 05 00613.

Cependant, la journalisation d'un ou plusieurs évènements représente toujours une surcharge de travail pour l'application journalisée ou le système qui l'exécute, qu'il est intéressant de minimiser le plus possible.

Parmi les évènements constituant le déroulement d'une application, ceux qui ont un comportement non déterministe vis à vis de l'état de l'application doivent être journalisés et rejoués en mémorisant leur résultat dans des données de journalisation, pour pouvoir forcer ou réinjecter ce résultat lors d'un rejeu ultérieur. Il est donc intéressant de réduire le plus possible le nombre d'évènements devant être traités comme non déterministes.

Les évènements externes à l'application ou au système qui l'exécute ont souvent un comportement non déterministe par nature, et doivent être en général être mémorisés, par exemple comme décrit dans les demandes citées plus haut.

Les évènements internes, par contre, ont le plus souvent un comportement déterministe et constituent de plus la majorité des opérations exécutées dans le déroulement d'une application. Il est donc intéressant de regrouper et d'optimiser la journalisation des évènements non déterministes, en particulier internes.

Lorsque tous les évènements d'une portion du déroulement sont déterministes, l'ensemble de cette portion peut être journalisée de façon économique en mémorisant simplement l'état de départ de l'application, par exemple sous la forme d'un point de reprise. Le rejeu s'obtient alors par exemple en restaurant l'application dans l'état de point de reprise tel que mémorisé, et en lançant simplement l'exécution de ces évènements déterministes. On peut alors parler d'un modèle d'exécution déterministes par morceaux ( piecewise dterministic execution model ), comprenant un assemblage de portions déterministes composées uniquement d'évènements déterministes. Les portions déterministes sont alors en général bornées par des évènements non déterministes, par exemple commençant par une arrivée d'un message externe et se terminant par un autre événement non déterministe.

Un but de l'invention est de simplifier ou d'optimiser la journalisation et le rejeu d'une telle portion déterministe.

De plus, certains types d'architecture informatique peuvent inclure des causes de non déterminisme par fois inhérentes à leur nature même, en particulier les système à architecture parallèle, parfois qualifiée de parallélisme physique ou réel.

Un autre but de l'invention est alors faciliter ou d'optimiser l'implémentation de fonctions de journalisation et rejeu, et de diminuer les causes de non-déterminisme au sein d'un environnement parallèle, en particulier pour les applications multitâches.

Dans le cadre d'une gestion de fonctionnement en architecture redondant, un autre but de l'invention est alors de fiabiliser le fonctionnement d'une application multitâche exécutée en environnement parallèle.

Une portion déterministe, de par sa nature, donnera toujours le même résultat si elle part d'une même situation et exécute les mêmes instructions. Pour journaliser et rejouer une telle portion déterministe, il est donc possible de ne mémoriser et restaurer que la situation de départ, et de laisser l'exécution se faire à partir du même fichier exécutable pendant le nombre d'instructions correspondant à la longueur de cette portion.

Cependant, si cela n'est pas prévu dans l'application d'origine, l'implémentation d'un comptage des instructions exécutées représente une charge de travail importante pour la ou les machines exécutant ces instructions. Avec les techniques connues, une telle surcharge est souvent inacceptable ou limite une telle implémentation à des situations expérimentales, et est peu utilisable en situation d'exploitation.

Un but de l'invention est de pallier tout ou partie de ces 20 inconvénients.

Pour cela, l'invention propose un procédé de gestion d'une tâche informatique, dite cible, au cours d'une période déterminée d'exécution, dite période d'activité, au sein d'un système informatique, dans un processeur informatique doté de moyens de suivi ou d'estimation de performance incluant un compteur pouvant présenter en plus ou en moins une erreur déterminée dite relative.

Ce procédé comprend d'une part, une évaluation d'un nombre d'instructions exécutées en au moins un point déterminé de ladite période d'activité, à l'aide dudit compteur; et d'autre part une génération de données, dites signature, lue ou calculée à partir de l'état du processeur ou du système informatique correspondant à au moins un point déterminé de ladite période d'activité.

Avantageusement, l'évaluation du nombre d'instructions exécutées depuis le début de la période gérée utilise au moins une instruction d'appel système comme barrière de synchronisation conjointement au compteur.

Ce procédé est particulièrement intéressant pour gérer une tâche au cours d'une période d'activité composée d'une suite d'opérations déterministes entre deux opérations non déterministes.

L'invention propose alors de gérer une tâche en cours de journalisation dans un processeur, dit de journalisation, et comprend une mémorisation de données de journalisation correspondant à cette période d'activité de ladite tâche, dite période journalisée. De telles données de journalisation comprennent alors au moins une valeur supposée du nombre d'instructions exécutées ainsi que la signature dite journalisée correspondant à la fin de ladite période journalisée.

Il est alors possible journaliser l'utilisation d'un processeur en mémorisant de façon ordonnée dans au moins un fichier dit journal de processeur des données de journalisation représentant la journalisation d'une succession de périodes d'activité d'une pluralité de tâches exécutées dans ledit processeur et comprenant pour chacune de ces périodes une donnée identifiant la tâche exécutée.

A partir de telles données de journalisation, l'invention propose aussi un rejeu de la période journalisée en gérant une tâche dite rejouée exécutée par un processeur dit de rejeu au sein d'un système informatique de rejeu, à partir d'un état correspondant à l'état du processeur ou du système de journalisation au début de la période journalisée. Le procédé comprend alors en outre: - une phase d'exécution sous surveillance à partir du début de la période de rejeu d'un nombre d'instructions, évalué par le compteur, inférieur ou égal à la valeur supposée du nombre d'instructions de la période journalisée diminuée de l'erreur relative dudit compteur; une phase de confirmation comprenant une itération des étapes suivantes interruption de l'exécution de la tâche de rejeu en un point déterminé du rejeu; - test de comparaison entre la signature journalisée et la signature correspondant au point d'interruption du rejeu; En particulier, la signature journalisée inclut une donnée dite de pointeur journalisé représentant la valeur du pointeur d'instruction de la tâche journalisée à la fin de la période journalisée. Le procédé comprend alors en outre une mise en place d'un point d'arrêt sur l'instruction de rejeu correspondant à la donnée de pointeur journalisé.

Selon l'invention, la surveillance de l'exécution de la tâche de rejeu comprend en particulier un débordement du compteur, préalablement initialisé de façon à évaluer le nombre d'instructions devant exécutées à partir du début de la période de rejeu et dont le débordement cause une interruption de la tâche de rejeu.

Cependant, du fait que ce type de compteur n'est pas prévu pour un usage aussi exact, une telle interruption peut intervenir avec un certain 15 retard par rapport au débordement du compteur.

L'invention propose alors d'initialiser le compteur au début de la période de rejeu avec une certaine marge, de façon à déborder suffisamment tôt pour que, dans le cas d'une période de latence existant entre le débordement du compteur et l'interruption de la tâche qui l'a causé, le nombre d'instructions exécutées par la tâche de rejeu soit inférieur ou égal à la valeur supposée du nombre d'instructions de la période journalisée diminuée de l'erreur relative dudit compteur.

De plus, à titre de sécurité, la phase de confirmation peut comprendre une étape de sécurité signalant une erreur lorsque le nombre d'instructions rejouées dépasse la valeur supposée du nombre d'instructions journalisées augmentée d'un nombre déterminé d'instructions.

A partir d'un journal représentant plusieurs périodes journalisées de cette façon, l'invention permet alors de réaliser, dans un processeur dit de rejeu, un rejeu de l'utilisation d'un processeur journalisé, à partir ensemble ordonné de données de journalisation d'une succession de périodes d'activité journalisées dans ledit processeur journalisé.

Par ailleurs, l'invention prévoit une journalisation d'une succession d'accès continus attribués portant sur une ressource partagée dite cible, accédée par une pluralité de tâches journalisées, ce procédé transmettant - h - ou mémorisant en outre au moins un fichier dit journal de ressource. Ce journal de ressource comprend alors des données de journalisation représentant une identification de la succession des différentes tâches ayant obtenu ces accès continus.

A partir de ces techniques, l'invention propose de gérer le fonctionnement d'au moins deux tâches applicatives, au sein d'un logiciel système gérant par activation séquentielle l'exécution desdites tâches dans un système informatique, dit de journalisation, doté d'une structure parallèle comprenant des moyens de calcul aptes à exécuter plusieurs tâches applicatives simultanément dans au moins deux unités de calcul. Pour de telles tâches applicatives accédant à au moins une ressource partagée, le procédé comprend, d'une part les étapes suivante: une journalisation d'une première succession de périodes d'activation de l'une ou l'autre de ces tâches dans une première unité de calcul; et -une journalisation d'une deuxième succession de périodes d'activation de l'une ou l'autre de ces tâches dans une deuxième unité de calcul; et une journalisation d'une succession d'attributions à l'une ou l'autre de ces tâches dite accédante, en réponse à une demande d'accès à ladite ressource cible, d'un accès dit continu à ladite ressource cible, c'est à dire de façon à exclure tout accès à ladite ressource cible par une autre de ces tâches pendant la totalité de la période d'activation de la tâche accédante suivant immédiatement ladite demande d'accès; D'autre part, le procédé comprend en outre une combinaison, en une structure ordonnée dite sérialisation de rejeu, des données de journalisation représentant les successions de périodes d'activation dans chacune des unités de calcul avec les données de journalisation représentant la succession des accès continus attribués. Cette combinaison est agencée de façon à conserver l'ordre de succession des périodes d'activation au sein de chaque tâche et vis à vis de ladite ressource partagée.

Selon l'invention, les données de la sérialisation de rejeu peuvent être utilisées dans un système informatique de rejeu pour rejouer le déroulement journalisé des tâches journalisées.

De plus, le procédé peut comprendre une virtualisation, au sein du système informatique de rejeu, de tout ou partie des ressources logicielles accessibles aux tâches journalisées lors de la journalisation.

Le procédé selon l'invention peut réaliser en particulier une réplication dite active du fonctionnement d'une application journalisée comprenant au moins deux tâches, exécutées sur au moins un noeud à structure parallèle dit noeud primaire d'un réseau d'ordinateurs et accédant à au moins une ressource partagée. Cette réplication comprend alors un rejeu, dans au moins une application de rejeu sur un système de rejeu, d'une sérialisation de rejeu issue de données de journalisation transmises du noeud primaire vers le noeud secondaire au fur et à mesure de leur génération.

Dans un mode de réalisation, l'invention peut alors réaliser une fiabilisation d'une application comprenant au moins deux tâches, exécutées sur au moins un noeud à structure parallèle dit noeud primaire d'un réseau d'ordinateurs et accédant à au moins une ressource partagée. Cette fiabilisation comprend alors en outre un basculement de service, du noeud primaire vers au moins un noeud secondaire en lieu et place du noeud primaire, déclenché à la suite d'une détection d'un événement ou d'une défaillance au sein du noeud primaire.

Dans un autre mode de réalisation, l'invention peut aussi réaliser une répartition ou un ajustement de charge de travail au sein d'un réseau d'ordinateurs exécutant sur au moins un noeud secondaire une réplique active d'une application cible exécutée sur un noeud primaire. Cette répartition de charge comprend alors en outre un basculement vers la réplique active de tout ou partie du service assuré par l'application gérée.

Ainsi, le procédé selon l'invention peut être mis en oeuvre au sein d'au moins un noeud d'un réseau d'ordinateurs, par exemple un réseau constituant un cluster géré par une ou plusieurs applications de gestion de fonctionnement de type middleware. Le procédé peut alors permettre d'étendre ou d'optimiser les performances et fonctionnalités de cette gestion de fonctionnement, en particulier en journalisation et rejeu de séquence d'instructions.

Dans le même esprit, l'invention propose aussi un système comprenant mettant en oeuvre le procédé, appliqué à un ou plusieurs système informatiques de type parallèle ou constituant un système parallèle, et possiblement utilisés en réseau.

D'autres particularités et avantages de l'invention ressortiront de la description détaillée d'un mode de mise en oeuvre nullement limitatif, et des dessins annexés sur lesquels: - les figures 1 et 2 illustrent une journalisation de l'ordonnancement de l'exécution des tâches au sein d'un processeur, par comptage des tâches selon l'invention; - les figures 3 et 4 illustrent selon l'invention un rejeu d'une période d'activité d'une tâche par comptage d'instructions dans un processeur; -la figure 5 illustre selon l'invention un rejeu déterministe d'une application multitâche dans un système monoprocesseur, obtenu à partir d'une journalisation, par comptage d'instructions, de l'ordonnancement des tâches dans un processeur; - la figure 6 est une illustration du fonctionnement, selon l'art antérieur, de l'accès à une mémoire commune entre deux tâches exécutées en parallèle par deux processeurs différents; - la figure 7 illustre, selon l'invention, la création et le maintien, au sein d'une tâche, d'une structure permettant le contrôle d'accès à des pages de mémoire partagées entre plusieurs tâches exécutées en parallèle sur plusieurs processeurs différents d'un même environnement; - la figure 8 illustre, selon l'invention, le fonctionnement du contrôle d'accès à des pages de mémoires partagées par deux tâches exécutées en parallèle sur deux processeurs différents d'un même environnement; - la figure 9 illustre, selon l'invention, une journalisation d'une application multitâche sur un ordinateur multiprocesseurs et son rejeu au fur et à mesure sur une machine monoprocesseur.

Les techniques décrites ici correspondent à des modes de réalisation de l'invention utilisant certaines caractéristiques des processeurs des types employés dans des ordinateurs de type PC, par exemple des processeurs de type Athlon de la société AMD ou des processeurs Pentium de la société Intel. D'autres processeurs actuels, par exemple utilisés dans des stations de travail, ou futurs peuvent bien sûr présenter tout ou partie de ces caractéristiques ou de caractéristiques similaires, et être employés pour réaliser l'invention.

Les figures 1 à 2 présentent une technique de journalisation des différentes portions d'évènements internes déterministes exécutées successivement par un même processeur pProX ou unité de calcul.

Ainsi qu'illustré en figure 1, différentes tâches TA et TB peuvent être exécutées par portions, appelées périodes d'activation Schl à Sch3, successivement lancées par l'ordonnanceur SCH, faisant partie d'un agent système appelé gestionnaire de contexte et qui gère ces alternances ou entrelacement.

Parmi les différentes tâches exécutées au sein du système informatique ou d'un processeur, certaines peuvent faire partie d'une application que l'on cherche à gérer et seront qualifiées de monitorées .

Ces tâches sont identifiées par l'état (mis à 1) d'un bit de donnée habituellement inutilisé au sein du descripteur de tâche, ici appelé bit de gestion MmA ou MmB (cf. figure 7). Au sein de la succession des périodes d'activation exécutées dans un processeur peuvent alterner des tâches monitorées et d'autres qui ne le sont pas.

Pour les tâches monitorées TA et TB, marquées en figure 1 par une lettre m , les périodes d'activation sont établies de façon à n'être composées que d'événements déterministes. Ces périodes déterministes sont définies par un ou plusieurs agents logiciels de journalisation. Cet agent de journalisation peut comprendre des éléments exécutés dans l'espace mémoire utilisateur du système informatique, en tant que tâche d'une application de gestion de fonctionnement. Cet agent de journalisation peut aussi comprendre ou utiliser des éléments modifiés ou ajoutés au sein du logiciel système, par exemple au sein de l'ordonnanceur.

Du fait que la majorité des évènements d'une application sont des évènements internes, et que nombres d'entre eux sont déterministes, une grande partie de chaque tâche gérée se compose d'évènements déterministes. Chaque fois qu'intervient un événement déterministe, l'agent de journalisation clôture une période déterministe. L'évènement non déterministe détecté est alors exécuté, possiblement sous la forme d'une 10 - tâche non monitorée, et est journalisé avec son résultat selon une méthode connue. A l'issue de cet événement non déterministe, l'agent de journalisation définit le début d'une nouvelle portion déterministe et relance le comptage des instructions.

La journalisation, et possiblement le traitement, des évènements non déterministes est réalisée en dehors des périodes d'activation déterministes, par exemple dans une période d'exécution K1 ou K2 en mode kernel KLv c'est à dire lorsque le mode privilégié du processeur ( processor privilege mode ) est à la valeur 0, par opposition à la valeur 3 pour le mode utilisateur ( user mode ) Ulv.

Pour pouvoir rejouer chaque période d'activation de façon identique que lors de la journalisation, l'invention réalise un comptage des instructions exécutées au cours de cette portion déterministe lors de la journalisation. Lors d'un rejeu RSCH (cf. figures 3 et 4) ultérieur de ces tâches, cette portion journalisée n'a donc qu'à être lancée à partir d'un même état que lors de la journalisation, pour s'exécuter seule jusqu'à un nombre d'instructions de rejeu correspondant exactement au nombre d'instructions exécutées lors de la journalisation par cette même portion et pour cette même tâche. Ce rejeu s'effectue alors sans intervention de forçage de résultats au sein d'une portion déterministe, puis que celle-ci ne contient que des évènements déterministes.

Lorsqu'une portion déterministe s'étale sur plusieurs périodes d'activation établies par l'ordonnanceur, chacune de ces périodes d'activation comprend une partie de cette portion déterministe qui peut être traitée elle-même comme une portion déterministe complète. Dans la suite de la description, on ne décrira que la journalisation de périodes d'activation déterministes, mais il est clair que plusieurs périodes d'activation déterministes peuvent se suivre au sein d'une même portion déterministe.

Selon l'invention, ce comptage des instructions d'une période d'activation déterministe utilise un compteur de performance et de suivi, qui est une particularité matérielle existant actuellement dans un grand nombre de processeurs, par exemple à partir du Pentium 2 pour la famille Pentium de la société Intel. Ce compteur de performance et de suivi ( Performance and Monitoring Counter ) est prévu pour mesurer le fonctionnement du - 11 - processeur, en durée ou en nombre d'événement et sert principalement à mesurer les performances, par exemple pour réaliser des analyses statistiques de profils d'applications, par échantillonnage périodique de ses valeurs. Les constructeurs de processeurs précisent d'ailleurs que ces compteurs de performances ne présentent pas une exactitude garantie et doivent être utilisés à titre de mesures relatives ou différentielles pour l'optimisation d'application.

L'invention propose d'utiliser une des caractéristiques de ce compteur de performance PMC, à savoir le comptage des instructions dites retirées, c'est à dire qui sont résolues ou ont quitté la liste des instructions à exécuter, indépendamment des diverses techniques spéculatives ou de cache pouvant faire exécuter certains instructions à l'avance pour des raisons de performances.

Cependant, ce comptage d'instructions retirées présentent certaines caractéristiques limitatives qui sont décrites dans les documentations des sociétés Intel et AMD. Une première de ces caractéristiques est que les instructions de lecture ( RDPMC ) de ce compteur ne sont pas intégrées directement dans les instructions à résoudre, ce qui n'a pas de conséquence directe sur l'utilisation de ce compteur dans le cadre de l'invention.

Par contre, deux autres caractéristiques limitatives peuvent être à l'origine d'imprécisions dans le comptage d'instructions pour journalisation et rejeu et doivent être prises en compte.

Une quatrième caractéristique pouvant constituer un handicap est le fait que l'interruption de l'exécution par débordement du compteur peut intervenir avec un certain retard après l'instruction ayant provoqué ce débordement.

Ces limites d'imprécision concernent d'une part les cas de certaines instructions complexes qui peuvent être comptées deux fois si interrompues avant résolution, et d'autre part des instructions avec interruption matérielle qui peuvent causer un non-comptage d'une instruction. Pour pallier à cette imprécision, l'invention utilise une technique de confirmation complémentaire qui permet de lever les doutes sur la détermination exacte de la fin d'une période d'activation.

- 12 - Ainsi qu'illustré en figure 1, une succession de périodes d'activation déterministes Schi, Sch2 et Sch3, exécutées dans un processeur pProX sont journalisées et enregistrées dans un fichier journal JpProX.

Au cours d'une période d'activation journalisée Sch3 où le processeur exécute une tâche TA monitorée, une ou plusieurs lectures RDPMC de la valeur UIVX du compteur PMC fournit un nombre N33 d'instructions retirées. A la suspension (fin Sch3) de cette période Sch3, l'agent de journalisation JSCH utilise une ou plusieurs données d'état issues de l'état de la tâche TA et de son contexte pour calculer une ou plusieurs données représentant cet état de façon suffisamment univoque pour lever les doutes pouvant exister sur le nombre exact d'instructions exécutées au cours de cette période d'activation Sch3. Ces données d'état constituent une signature SG3 correspondant à cette fin de période Sch3. Cet signature comprend en particulier la valeur exacte IPJX3 du pointeur d'instruction immédiatement après la dernière instruction de cette période, c'est à dire une identification exacte de la position, au sein de l'exécutable de la tâche TA, de l'instruction de programme exécutée en dernier. Cette signature comprend aussi une donnée de contrôle ( checksum ) calculée à partir des valeurs lues dans registre RegJX3 et la pile d'appel PileJX3 du contexte de la tâche TA lors de cette suspension (fin Sch3).

Pour chacune des périodes SchJ (figure 3) journalisées, le journal pProX de ce processeur comprend ainsi une ligne associant en particulier: une identification de la tâche TJ exécutée dans cette période, par exemple le PID de cette tâche; - la valeur du nombre d'instructions retirées NJ renvoyé par le compteur PMC; - la signature SGJ calculée pour la fin de cette période.

Ainsi, pour la succession des tâches TA puis TB puis TA illustrée en figure 1, le journal du processeur pProX comprendre les lignes successives 30 suivantes: idA: NJ3: SG3 idB: N32: SG2 idA: N31: SG1 -13 - Ainsi qu'illustré en figure 2, la succession des différentes tâches journalisées d'une application journalisée APPJ au sein d'un processeur déterminé pProX peut aussi être transmise d'abord par l'agent de journalisation JSCH à une file d'attente de journalisation QJpProX de type FIFO ( First In First Out ). Les lignes de journalisation en sortie de cette file d'attente sont lues par une tâche de mémorisation de journal TJpProX, qui déclenche la mémorisation dans de ces lignes de façon ordonnée dans le journal JpProX de ce processeur, soit en local MEM soit par une transmission TRANS vers un autre noeud ou une station ou un périphérique de sauvegarde. L'utilisation d'une telle file d'attente de journalisation sert en particulier de zone tampon pour réguler le flot de données de journalisation et éviter de perturber l'application journalisée ou l'application réalisant cette journalisation.

Cet avantage est particulier sensible dans le cas d'une architecture globale où les données de journalisation sont transmises au fur et à mesure à une autre application rejouant le même déroulement, par exemple sur une machine de secours pour réaliser un fonctionnement avec tolérancede panne et continuité de service.

Dans cette techniques de comptage, il peut être avantageux d'utiliser les instructions d'appel système comme points de synchronisation pour le comptage des instructions. Il s'agit alors d'instrumenter les routines d'appels système de façon à ce qu'elles incrémentent un compteur d'appels système. Le comptage des instructions par compteur matériel PMC peut alors travailler sur des valeurs qui restent peu élevées, ce qui améliore ses performances.

Les figures 3 et 4 présentent une technique de rejeu dans un processeur de rejeu pProZ, d'une période journalisée SchJ. La figure 3 représentent les derniers états TRI à TR4 d'une tâche rejouée TR, au sein du processeur. La figure 4 représente un diagramme de flux de la méthode utilisée pour mettre en oeuvre un tel rejeu. Selon les modes de réalisation ou les paramètres d'utilisation, le rejeu peut aussi se faire se faire dans le même processeur que la journalisation, par exemple pour une gestion de fonctionnement de type traçage d'application, selon le même principe que pour un processeur de rejeu différent.

- 14 - Lors d'un tel rejeu, par exemple en tant que période d'activation ordonnancée par l'ordonnanceur SCH possiblement modifier pour inclure un agent de rejeu RSCH, la tâche concernée TJ est restaurée dans le processeur visé avec son contexte, puis cette tâche est libérée (41) et son exécution est lancée.

Pour pouvoir être restaurée et exécutée, dans un système informatique de rejeu différent de celui où a été faite la journalisation, tout ou partie des ressources accessibles à une tâche ou une application doit être virtualisée, c'est à dire instanciées ou recrées, par exemple de façon virtuelle, de façon à apparaître à l'application rejouée de la même façon que lors de la journalisation. Sont concernées en général les identificateurs de tâches, threads (TIP) ou processus (PID), ainsi que la plupart des ressources accédées par l'application et qui dépendent du système hôte. Cette virtualisation est réalisée au début de la tâche ou de l'application rejouée, et est modifiée au fur et à mesure du rejeu de façon à évoluer de la même façon que lors de la journalisation, en fonction de données mémorisées lors de cette journalisation.

De façon avantageuse, cette virtualisation est faite en mode kernel, ce qui permet en particulier d'éviter que ses opérations soient prises en compte dans le comptage des instructions par le compteur de performances PMC.

La documentation de la société Intel précise que l'erreur due à une interruption matérielle est limitée à une erreur relative de plus ou moins une instruction. Pour une période déterministe journalisée comprenant au plus une seule interruption matérielle, c'est à dire celle qui a provoqué sa clôture, la surveillance nécessite la prise en compte de deux valeur du compteur PMC: la valeur au début de la période de rejeu et la valeur au point de surveillance. L'erreur relative maximale est donc de plus ou moins deux instructions.

Tout au long de l'exécution de la tâche de rejeu TR au titre du rejeu de la tâche journalisée TJ, l'agent de rejeu RSCH surveille le nombre d'instructions retirées en lisant (RDPMC) le compteur PMC du processeur pProZ réalisant ce rejeu et en comparant cette lecture avec les données de journalisation IdJ, NJ, SGJ correspondant à cette tâche journalisée TJ. Cette - 15 - surveillance est agencée de façon à interrompre l'exécution de la tâche TR de rejeu une fois atteinte l'instruction dont la valeur ordinale dans cette exécution de rejeu vaut NJ-2. Cette interruption est faite par exemple en programmant un débordement ( overflow ) du compteur PMC à la valeur voulue.

Du fait de la quatrième caractéristique limitative citée plus haut, l'existence d'un temps de latence entre le débordement et l'interruption peut être compensée en programmant le débordement 41 (figue 4) avec une certaine marge, de façon à être certain que l'interruption se produise avant la valeur recherchée de NJ-2. Cette marge peut être déterminée par expérimentation et peut être par exemple de l'ordre de 50 instructions.

L'exécution initiale de la période SchR rejouée s'interromps alors à un nombre d'instruction entre NJ-50 et NJ-2. L'agent de rejeu RSCH positionne 42 alors un point d'arrêt d'exécution BK ( breakpoint ) au sein de l'exécutable de la tâche de rejeu TR, sur l'instruction de programme BKI correspondant à la valeur IPJ du pointeur d'instruction mémorisée dans la signature SGJ. L'exécution est alors relancée jusqu'à interruption 43 par ce oint d'arrêt BK, et ce en testant 44 le nombre d'instruction du compteur PMC jusqu'à ce que le nombre d'instructions rejoué soit supérieur ou égal au nombre d'instruction journalisé moins deux instructions, soit NR>=NJ-2.

La position exacte de la fin réelle de la période journalisée SchJ se situe alors dans les quatre exécutions suivantes d'instruction unitaires InstrO, à Instr3, de valeurs ordinales respectives NJ-1 à NJ+2, c'est à dire à une position relative comprise entre moins deux et plus deux par rapport à la position Ni de la fin supposée de cette même période SchJ.

Une phase de confirmation 40 (figure 4) permet alors de déterminer cette position réelle, par comparaison entre la signature SGJ et une valeur SG1 à SG4 calculée de la même façon à partir de l'état TRI à TR4 de la tâche de rejeu TR, après les exécutions unitaires d'instructions suivantes Instrl à Instr4.

Au début de cette phase de confirmation, l'agent de rejeu vérifie 45 la valeur SGO d'une signature de rejeu SGR calculée d'après l'état de la tâche de rejeu TR immédiatement après l'interruption provoquée par la surveillance précédente.

- 16 - Selon l'invention, si les signatures SGJ et SGO ne correspondent pas, l'exécution de la tâche TR est alors relancée, et s'arrête 46 à la première nouvelle exécution TR2 de cette instruction d'arrêt BKI.

Il peut cependant subsister un doute quant à celle nouvelle position d'arrêt TR2, par exemple si la tâche journalisée TJ a réalisée une boucle très courte en exécutant plusieurs fois cette instruction d'arrêt BKI avant d'être suspendue. A chaque arrêt TR2, TR4 de l'exécution sur cette instruction d'arrêt BKI, l'agent de rejeu vérifie 47 alors à nouveau la concordance des signatures SGJ et SGR et relance l'exécution jusqu'à obtenir la concordance.

Lorsque les signatures correspondent SGJ=SG4, c'est que la dernière exécution Instr4 de l'instruction d'arrêt BKI correspond à la dernière opération journalisée dans la période journalisée SchJ. L'agent de rejeu clôture 48 alors la période de rejeu SchR.

Par ailleurs, l'invention prévoit un mécanisme de sécurité, par exemple un test 49 interrompant le rejeu TR et renvoyant 401 une erreur de rejeu au delà d'un certain nombre d'exécutions unitaires d'instructions pour éviter une boucle infini en cas d'erreur, par exemple au bout de huit exécutions unitaires.

Pour rejouer une pluralité de périodes journalisées, par exemple lors d'un rejeu d'une application de rejeu APPR correspondant à l'application journalisée APPJ, l'agent de rejeu RSCH lit successivement les différentes lignes du journal JpProX, utilise chacune d'elle pour rejouer une période d'activation correspondant à la ligne concernée.

Ainsi qu'illustré en figure 5, les différentes lignes de ce journal JpProX sont reçues TRANS directement ou lues MEM en local par une tâche de lecture de journal TpProZ exécutée dans le processeur de rejeu pProZ.

Toutes les lignes de ce journal JpProX, correspondant chacune à une période journalisée, sont alors transmises à une file d'attente de rejeu QJpProZ de type FIFO, dans l'ordre où elles ont été journalisées. A la sortie de cette file d'attente, l'agent de rejeu RSCH utilise chacune de ces lignes du journal pour faire rejouer la période qu'elle représente par la tâche rejouée TA', TB' et TC' correspondant à la tâche journalisée TA, TB et TC.

Pour réaliser l'ordonnancement de ces périodes au sein du processeur de rejeu pProZ, l'agent de rejeu RSCH utilise le fonctionnement de - 17 l'ordonnanceur SCH tel qu'il existe dans le logiciel système standard sans changement sémantique. Cet aspect permet en particulier de garder la compatibilité avec les autres tâches TNM exécutées dans le même processeur. Pour obtenir le même ordonnancement que lors de la journalisation sans perturber le fonctionnement normal de l'ordonnanceur SCH, l'agent de rejeu RSCH se contente de bloquer 55b, 55c la libération de chaque tâche de rejeu TB', TC' tant que sont identifiant, TID ou PID, ne correspond pas à l'identifiant idA mémorisé dans la ligne qu'il doit faire rejouer.

Ces techniques de journalisation et rejeu de périodes déterministes permettent d'optimiser les performances et les fonctionnalités d'une application de gestion de fonctionnement au sein d'un ou plusieurs ordinateurs mono-processeurs, telle que décrite dans les demandes citées plus haut.

Dans le cas d'une architecture parallèle, telle qu'un ordinateur multiprocesseurs ou un réseau comprenant plusieurs ordinateurs travaillant en parallèle, l'utilisation de ressources partagées accessibles par plusieurs tâches ajoute une cause de non déterminisme qui peut être à l'origine d'importantes pertes de performances dans le cadre de cette gestion de fonctionnement, voire d'impossibilités d'implémentation de certaines fonctionnalités importantes et utiles.

Pour lever tout ou partie de ces causes de non déterminisme, l'invention propose un procédé permettant de gérer ou contrôler l'accès aux ressources partagées, en particulier à accès direct, de façon à ce que chaque tâche puisse obtenir un accès exclusif aux ressources partagées pendant la totalité d'une période où elle est activée par le système.

En figure 6 est illustré un exemple de fonctionnement d'un environnement multiprocesseur parallèle, comprenant un premier processeur pProX et un deuxième processeur pProY dans un environnement multiprocesseurs, par exemple un système de type Linux. Ces deux processeurs exécutent en parallèle chacun une tâche, respectivement TA et TB, au sein d'un même espace de mémoire de travail RAM, et sont coordonnées par un ordonnanceur SCH. Au cours d'une période d'activation de chaque tâche TA et TB, une séquence SchA, SchB des instructions de son - 18 - programme EXEA, EXEB va être exécutée dans un processeur pProX, pProY. Lors de l'exécution d'une instruction InstrA, InstrB de cette séquence, le processeur pourra utiliser des ressources qui lui sont internes telles des régistres RegA, RegB une pile PiIA, PilB.

Au sein de la mémoire de travail RAM, plusieurs zones de mémoire partagées ShMPi à ShMPk sont définies, par exemple par une instruction de type map , et accessibles depuis les différentes tâches TA et TB directement par leur adresse physique.

La figure 6 illustre une situation de l'art antérieur, où les tâches TA et TB sont exécutées en parallèle sur une période commune et comprennent chacune une instruction InstrA et InstrB demandant un accès à une même zone de méoire partagée ShMPi. Ces deux demandes d'accès vont être traitées 11, 13 de façon indépendantes par le module gestionnaire de mémoire MMU de chaque processeur, et vont parvenir 12, 14 à cette zone mémoire partagée indépendamment l'une de l'autre.

Pour les ressources qui ne sont accessibles qu'à partir de certaines instructions de type appel système, il est possible d'instrumenter les routines systèmes réalisant ces instructions, c'est à dire de modifier ces routines ou d'insérer des éléments dans le système qui interceptent ou réagissent à ces appels systèmes. Dans le cadre d'une gestion de fonctionnement par journalisation et rejeu, cette instrumentation peut permettre en particulier d'enregistrer leur comportement pour pouvoir le rejouer ultérieurement à l'identique, ou de modifier ce comportement de façon à ce qu'il devienne déterministe et n'ait pas besoin d'être enregistré.

Pour des ressources accessibles directement sans appel système, donc potentiellement depuis n'importe quelle instruction de programme, la plupart des systèmes d'exploitation et en particulier ceux de type Unix ou Linux, ne permettent pas de contrôler l'ordre d'arrivée de ces accès au niveau de cette zone de mémoire partagée ShMPi.Pour résoudre ce problème, ainsi qu'illustré en figures 7 et 8, l'invention propose de modifier le code de certains éléments du logiciels système, ou d'en ajouter certains autres, de façon à détourner ou étendre certaines fonctions matérielles existantes, actuellement utilisées pour d'autres fonctions.

- 19 - En particulier, il est possible de résoudre ce problème en modifiant un petit nombre d'éléments d'un logiciel système de type Unix ou Linux, et sans modifier les caractéristiques matérielles de processeurs courants. Il est alors possible d'utiliser des machines d'un type courant, donc économiques et bien au point, pour exécuter et gérer des applications multi-tâches peu ou pas modifiées, en n'apportant aux logiciels systèmes existants que quelques modifications qui ajoutent des fonctionnalités sans compromettre leur compatibilité ascendante.

L'invention utilise pour cela certains mécanismes existant dans nombres de micro-processeurs récents, tels que les processeurs utilisés dans les architectures de type PC, par exemple les processeurs Pentium de la société Intel, ou Athlon de la société AMD. Ces processeurs, en particulier depuis le Pentium 2, intègrent au sein de leur gestionnaire de mémoire MMU ( Memory Management Unit ) un mécanisme de gestion de mémoire virtuelle. Ce mécanisme est utilisé pour décharger dans le disque dur certaines pages définies dans la mémoire de travail quand elles ne sont pas utilisées, et les y entreposer pour libérer l'espace correspondant au sein de la mémoire physique. Pour les applications en cours d'exécution ces pages sont toujours répertoriées dans la mémoire de travail, mais elles doivent être chargées à nouveau en mémoire physique à partir du disque dur pour qu'une tâche puisse y accéder réellement.

Pour gérer cette mémoire virtuelle, ainsi qu'illustré en figure 8, le logiciel système comprend un gestionnaire de mémoire virtuelle VMM ( Virtual Memory Manager ), qui crée, pour chaque page de mémoire virtualisable, une table d'entrée de page PTE ( Page Table Entry ) au sein de chacun des différents processus applicatifs. Ainsi, pour deux tâches TA et TB exécutées chacune s sous forme de processus, c'est à dire avec un contexte d'exécution qui lui est propre, chacune des pages ShMPi à ShMPk se verra attribuer une table d'entrée de page PTEiA à PTEkA dans le processus de la tâche TA, ainsi qu'une table d'entrée de page PTEiB à PTEkB dans le processus de la tâche TB.

Le gestionnaire de mémoire virtuelle VMM comprend un agent logiciel chargeur de page PL, qui charge et décharge des pages mémoires dans un fichier de swap du disque dur, par exemple un fichier avec extension 20 - .swp dans le système Windows de la société Microsoft. Lors de chaque chargement ou déchargement d'une page ShMPi, son état de présence ou non en mémoire physique est mémorisé et tenu à jour 30 par le gestionnaire VMM dans chacune des tables d'entrée de pages PTEiA et PTEiB qui lui correspondent. Au sein de ces tables PTEiA et PTEiB, cet état de présence est mémorisé sous la forme d'un bit de donnée PriA et respectivement PriB, à la valeur 1 pour une présence et à la valeur 0 pour une absence.

Au sein de chaque processeur pProX et pProY, le gestionnaire de mémoire MMUX ou MMUY comprend un mécanisme PFIntX ou PFIntY d'interruption sur erreur de page ( Page Fault Interrupt ) par lequel passe toute demande d'accès en provenance d'une instruction de programme InstrAou InstrB en cours d'exécution. Lorsqu'une instruction InstrA d'une tâche TA exécutée par le processeur pProX demande 33 un accès portant sur une page de mémoire ShMPi, le mécanisme d'interruption PFIntA du processeur vérifie si cette page est présente en mémoire physique RAM, en prenant connaissance de la valeur de son bit de présence PriA dans la table d'entrée PTEiA correspondante.

Si ce bit PriA indique la présence de la page, le mécanisme d'interruption PFIntA autorise l'accès. Dans le cas contraire, ce mécanisme d'interruption PFIntA interromps l'exécution de la tâche TA et transmet les paramètres de l'erreur à un agent logiciel gestionnaire d'erreur de page PFH ( Page Fault Handler ) appartenant au gestionnaire de mémoire virtuelle VMM du logiciel système. C'est alors ce gestionnaire d'erreur PFH qui s'exécute et gère les conséquences de cette erreur au sein du logiciel système et vis à vis des applications.

La figure 7 illustre la façon dont ces mécanismes existants sont modifiés et adaptés ou détournés pour gérer l'accès aux ressources partagées selon l'invention.

Pour gérer ces accès de la part d'une application APP exécutée dans un tel environnement parallèle, on utilise un logiciel lanceur LCH pour lancer l'exécution de cette application, par exemple dans un système de type Unix ou Linux. Lors de son lancement, l'application APP est crée avec une première tâche TA sous la forme d'un processus comprenant un fil - 21 d'exécution ou thread ThrAl, et utilisant une table de données formant un descripteur de tâche TDA.

Au sein de ce descripteur de tâche TDA, le lanceur mémorise 21 le fait que cette tâche TA doit être gérée, ou monitorée , en modifiant à 1 l'état d'un bit de donnée habituellement inutilisé, ici appelé bit de gestion MmA.

Les différentes zones de mémoire partagées en mémoire de travail, ici qualifiées de pages de mémoire partagée ShMPi, ShMPj, et ShMPk, sont répertoriées au sein de la tâche TA dans une table de données formant une structure de pages mémoires PMStrA. Dans cette structure PMStrA, les pages partagées sont décrites et mises à jour sous la forme de tables d'entrées de pages PTEiA1 à PTEkA1, comportant chacune un bit de données PriAl à PrKA1 utilisé par le gestionnaire de mémoire virtuelle VMM comme décrit précédemment. Typiquement, cette structure de pages PMStrA est crée en même temps que la tâche TA, et mise à jour 20 au fur et à mesure des changements dans la mémoire partagée par les différentes routines système qui assurent ces changements, telles que les routines de type map .

Au cours de l'exécution de l'application gérée APP, d'autres tâches peuvent être créer par des instructions CRE de type create , à partir de cette première tâche TA ou à partir d'autres crées de la même façon. Lors de toute création d'une nouvelle tâche TB, celle-ci comprend aussi un thread ThrBl et un descripteur de tâche TB,ainsi qu'une structure de pages mémoires PMStrB. Par relation d'héritage INH à partir de sa tâche mère, la nouvelle structure de pages PMStrB comprend elle aussi les différentes tables d'entrée de pages mages PTEiB1 à PTEkB1, avec leur bit de présence PriBl à PrkBl, qui sont maintenues à jour de la même façon.

Lors de la création CRE d'une nouvelle tâche TB à partir d'une tâche TA monitorée, le nouveau descripteur de tâche TDB comprend aussi un bit de gestion MmB, dont la valeur est héritée INH de celle du bit de gestion MmA de la tâche mère TA.

Au cours de l'exécution de l'application gérée APP, d'autres threads peuvent être créés au sein d'une tâche TB qui fonctionnait initialement avec sous la forme d'un processus à un seul thread ThrBl.

- 22 - Au sein d'une tâche TB existante et monitorée, tout nouveau thread ThrB2 est créé par un appel système, telle qu'une instruction clone . Typiquement, une tâche sous forme de processus multi-threads ne comporte qu'un seul jeu de tables d'entrée PTEiB1 à PTEkB1 au sein de sa structure de pages PMStrB. Selon l'invention, le fonctionnement de toute routine système pouvant créer un nouveau thread, telle que l'appel système clone est modifiée, par exemple en lui intégrant une partie supplémentaire CSUP. Cette modification est réalisée de façon à ce que toute création d'un nouveau thread ThrB2 dans une tâche existante TB comprend la lecture 22 du jeu de tables existantes PTEiB1 et la création 23 d'un nouveau jeu de tables d'entrée de pages PTEiB2 à PTEkB2, correspondant aux mêmes pages partagées ShMPI à ShMPk et fonctionnant spécifiquement avec le nouveau thread ThrB2. Cette modification peut par exemple se faire par une instrumentation de ces routines CLONE en utilisant une technique d'interposition dynamique par chargement de bibliothèques partagées au sein du système, tel que décrit dans le brevet FR 2 820 221 des mêmes demandeurs.

Cette création est faite de façon à ce que les nouvelles tables PTEiB2 à PTEkB2 soient aussi mises à jour 24, 25 de façon similaire à leurs tables mères PTEiB1 à PTEkB1, soit en les inscrivant pour mise à jour auprès des routines systèmes MAP gérant cette mise à jour, soit en instrumentant aussi ces routines systèmes MAP, par exemple en leur intégrant une partie supplémentaire MSUP.

La figure 8 illustre le fonctionnement de la gestion d'accès utilisant cette structure appliqué à un exemple comprenant deux tâches monothreads TA et TB exécutées en parallèle dans deux processeurs pProX et pProY. Il est à noter que l'extension de la structure des tables d'entrées de page PTE à chaque thread ThrB2 cloné au sein de chaque tâche permet aussi de gérer de la même façon les accès venant de tous les thread appartenant à des tâches monitorées, qu'elles soient mono-thread ou multithreads.

Dans le mode de réalisation décrit ici, la gestion d'accès selon l'invention est agencée pour garantir à chaque tâche, au sens du processus TA mais aussi au sens de chaque thread ThrBl ou ThrB2, un accès aux - 23 pages mémoires partagées qui soit exclusif sur tout la durée d'une période d'activation ou leur cohérence (ou consistence) est garantie par le logiciel système. Une telle période est ici décrite comme étant une période d'activation allouée et gérée par l'ordonnanceur SCH du logiciel système. Il est clair que d'autres types de période de cohérence peuvent être choisies dans le même esprit.

De même, les ressources partagées dont l'accès est géré ou contrôlé sont ici décrite sous la forme de mémoire partagée définies en tant que zones unitaires de mémoire ou pages mémoire. Le même concept peut bien sûr aussi s'appliquer à d'autres types de ressources moyennant une instrumentation similaire des routines systèmes leur correspondant.

La mise en oeuvre de l'invention peut comprendre une modification de certains éléments du logiciel système, de façon à ce qu'ils fonctionnent tel que décrit ci-après. Le niveau de modification nécessaire peut bien sûr varier suivant le type ou la version du logiciel système. Dans le cas d'un système de type Linux, ces modifications comprennent en général l'instrumentation des routines de type clone et map tel que décrit précédemment, ainsi que des modifications et ajouts de code au sein des agents réalisant l'ordonnanceur SCH, le gestionnaire d'erreur de page PFH ( page fault handler ), et le chargeur de page PL. Les fonctionnalités systèmes à modifier pour réaliser le type de contrôle d'accès décrit ici peuvent avantageusement constituer exclusivement des extensions par rapport aux fonctionnalités du système standard, c'est à dire sans suppression de fonctionnalité ou du moins sans compromettre la compatibilité ascendante avec les applications développées pour la version standard.

Par ailleurs, bien qu'utilisant le mécanisme matériel prévu dans le processeur pour la gestion de la mémoire virtuelle, le contrôle d'accès décrit peut être ne nécessite pas forcément la désactivation de cette mémoire virtuelle et peut être compatible avec elle. Le chargeur de page PL peut par exemple être instrumenté ou modifié de façon à ce que le chargement en mémoire physique RAM d'une page virtuelle ShMPi ne soit pas répercuté dans le bit de présence PriB de cette page auprès d'une tâche TB monitorée si cette page est déjà utilisée par une autre tâche TA.

- 24 - Au début d'une de ses périodes d'activation SchA, une tâche TA est libérée par l'ordonnanceur SCH en un instant SCHAL. Avant de libérer cette tâche, l'ordonnanceur SCH teste 31 le bit de gestion MmA de cette tâche TA pour savoir si le contrôle d'accès doit s'appliquer à elle. Si c'est le cas, l'ordonnanceur SCH va alors 32 positionner à 0 tous les bits de présence PriA à PrkA des tables PTE correspondant à toutes les pages partagées concernées par ce contrôle d'accès, de façon à ce que toute demande d'accès de cette tâche TA provoque par défaut une erreur de page au niveau du mécanisme d'interruption PFIntX de tous les processeurs pProX où pourra être exécutée cette tâche TA.

Au cours de cette période d'activation SchA au sein du processeur pProX, une instruction InstrA demande 33 un accès à une page de mémoire partagée ShMPi. Du fait que le bit de présence PriA correspondant est à 0, le mécanisme d'interruption PHIntX du processeur pProX suspend l'exécution de cette demande d'accès et appelle le gestionnaire d'erreur de page PFH du logiciel système, en lui transmettant l'identification de la page et de la tâche concernées.

Lors du traitement de cette erreur, une fonctionnalité supplémentaire PFHSUP du gestionnaire d'erreur de page PFH effectue alors une opération de test et/ou modification au sein d'une table de données formant l'agent noyau de structure de la mémoire KMStr ( Kernel Memory Structure ) à l'intérieur du gestionnaire de mémoire virtuelle VMM du logiciel système.

Typiquement, cet agent noyau de structure mémoire KMStr mémorise de façon univoque pour l'ensemble de l'environnement de travail, ou de la mémoire de travail, des informations représentant la structure des ressources de mémoire et leur évolution. Selon l'invention, cet agent noyau de structure mémoire KMStr comprend également un ensemble de bits de données, appelés ici bits d'accès KSi, KSj et KSk qui représentent, pour chacune des pages partagées ShMPi à ShMPk concernées, le fait qu'un accès à cette page est actuellement accordé (bit à 1) ou non (bit à 0) à une tâche.

Lorsque le gestionnaire d'erreur page PFH traite l'erreur transmise par le processeur pProX, il consulte 34 le bit d'accès KSi correspondant à la page concernée ShMPi. Si ce bit d'accès n'indique pas d'accès en cours, il - 25 - modifie 34 ce bit d'accès KSi pour mémoriser qu'il accorde un accès à cette page, et modifie 35 aussi le bit de présence PriA correspondant de la tâche TA demandeuse (bit passant à 1) pour mémoriser le fait que cette tâche TA a maintenant un accès exclusif à la page concernée ShMPPi.

Il est à noter que ces opérations de test et modification du bit d'accès KSi de la structure noyau de mémoire KMStr constituent une opération 34 qui est implémentée de façon atomique, c'est à dire dont il est garanti qu'elle se déroule soit complètement soit pas du tout, même en environnement multi-processeurs.

Une fois que le gestionnaire d'erreur page PFInt a attribué l'exclusivité sur la page demandée ShMPi, il relance l'exécution de l'instruction InstrA de façon à ce qu'elle accède 36 effectivement au contenu de cette page.

Si une instruction InstrB d'une autre tâche TB monitorée quelle qu'elle soit, exécutée en parallèle par un autre processeur pProY, demande 37 alors un accès à cette page ShMPi déjà attribuée, le mécanisme d'interruption PFIntY de ce processeur va lui aussi consulter le bit deprésence PriB de cette page pour la tâche TB demandeuse. Puisque la tâche TB est une tâche monitorée, le bit de présence PriB consulté est en position d'absence (valeur à 0). Le mécanisme d'interruption PFIntY va donc suspendre l'instruction InstrB demandeuse et transmettre 38 une erreur au gestionnaire d'erreur de page PFH.

Cette fois, ce gestionnaire d'erreur page PFH constate que le bit d'accès KSi de cette page est à 1, indiquant qu'une exclusivité a déjà été accordée sur cette page ShMPi à une autre tâche. Le gestionnaire d'erreur PFH va alors déclencher 39 une suspension de l'ensemble de la tâche TB demandeuse, par exemple en mettant fin à sa période d'activation auprès du gestionnaire de changement de contexte du logiciel système. Lors de sa prochaine période d'activation, cette tâche TB reprendra alors son exécution exactement au point où elle s'était interrompue, et pourra tenter à nouveau d'accéder à cette même page ShMPi.

Dans le cas où la tâche demandeuse est un thread ThrB2 (figure 7) appartenant à un processus multi-threads, l'existence d'un jeu de tables d'entrée de pages PTEiB2 spécifiques à ce seul thread ThrB2 permet de ne 26 - suspendre que le thread qui demande l'accès à une page déjà allouée en accès exclusif, et non les autres threads ThrBl qui n'entreraient pas en conflit avec cette exclusivité.

A l'issue SCHAS de la période SchA d'activation de chaque tâche, l'ordonnanceur suspend l'exécution de cette tâche et sauvegarde son contexte d'exécution.

Lors de cette suspension SCHAS ou lors d'une suspension 39 sur une demande de page déjà allouée, l'invention prévoit aussi une phase de libération de toutes les pages de mémoires partagées pour lesquelles cette tâche a reçu un accès exclusif. Ainsi, lorsque l'ordonnanceur SCH constate 301 par le bit de gestion MmA que la tâche TA en cours de suspension est monitorée, il parcourt l'ensemble des tables d'entrée de page PTEiA à PTEkA de cette tâche pour savoir sur quelles pages elle dispose d'un accès exclusif, en consultant l'état des différents bits de présence PriA à PrkA. A partir de cette information il va alors libérer l'ensemble de ces pages ShMPi en réinitialisant à 0 leur bit d'accès KSi dans la structure noyau de mémoire KMStr.

Dans d'autres variantes non représentées, il est aussi possible de découpler la notion de gestion ou monitorage en plusieurs types de gestion, par exemple en prévoyant plusieurs bits de gestion au sein d'un même descripteur de tâche. Ainsi une tâche peut être monitorée de façon à bénéficier d'un accès exclusif vis à vis de certaines catégories de tâches. De même, une tâche peut ne se voir exclue que par certaines catégories de tâches.

Ainsi, en suspendant toutes les tâches qui cherchent à accéder à une page déjà allouée, on obtient une exclusivité de cette page pour la première tâche qui la demande, sans perturber la cohérence du déroulement des autres tâches ainsi suspendues.

En évitant toute modification d'une même zone de mémoire partagée par deux tâches s'exécutant en même temps, on évite ainsi toute interférence entre elles dans l'évolution du contenu de cette zone mémoire.

A partir d'un état initial déterminé, pour cette zone mémoire, au début de chaque période d'activation d'une tâche qui y accède, l'évolution de son contenu ne dépend donc que des actions de cette tâche au cours de cette 27 - période d'activation. Pour une séquence déterminée d'instructions exécutées par cette tâche, par exemple une période d'activation ordonnancée, et en partant d'un état initial connu, il est ainsi possible d'obtenir un déroulement de cette séquence qui soit déterministe et répétable vis à vis de cette tâche.

Du fait, en particulier, de l'utilisation d'une opération atomique pour mémoriser l'allocation d'exclusivité sur la zone de mémoire accédée, le procédé permet d'éviter ou de diminuer les risques d'interblocage ( deadlock ) d'une même ressource partagée entre plusieurs tâches cherchant à y accéder concurremment.

Avantageusement, lors de l'attribution à une tâche accédante TA d'un accès exclusif pour le reste de sa période à la page mémoire partagée ShMPi, l'agent gestionnaire d'erreur page PFH, PFHSUP peut préparer une donnée de journalisation représentant cette attribution. Cette donnée de journalisation comprend une identification de la tâche TA à laquelle cet accès continu a été attribué, et possiblement d'autres informations complémentaires portant sur le contexte ou représentant la position de l'instruction demandeuse InstrA dans le déroulement de la tâche concernée TA, ainsi que le nombre d'instructions exécutées par cette tâche TA pendant la durée de l'accès continu obtenu.

Au sein du logiciel système, ces données de journalisation peuvent être regroupées en un journal des accès représentant la succession des accès continus attribués pendant une certaine durée de temps ou d'exécution. Ce journal comprend en particulier un ensemble ordonné de données identifiant, par exemple par leur PID ou TID, la succession des tâches ayant obtenu ces accès continu. Chaque ressource accédée par une tâche monitorée peut ainsi donner lieu à l'établissement d'un journal qui lui est propre, et regroupe la succession des tâches ayant obtenu un accès continu sur cette ressource.

En combinant ces techniques de contrôle d'accès (figures 7 à 8) avec les techniques de journalisation des périodes déterministes décrites plus haut (figures 1 à 5) ainsi des techniques checkpointing et de journalisation et rejeu décrites dans les demandes citées plus haut, l'invention propose 28 - d'implémenter aussi dans des systèmes à architecture parallèle les différents types de gestion de fonctionnement décrits précédemment.

La figure 9 illustre ainsi, selon l'invention, une journalisation d'une application multitâche APPJ exécutée dans un système multiprocesseurs MP1 et son rejeu au fur et à mesure dans un système monoprocesseur UP2.

Auprès de l'application journalisée APPJ, l'agent de journalisation JSCH journalise, pour chaque processeur pProX ou pProY, la succession de toutes les périodes d'activation des différentes tâches monitorées TA, TB et TC. Ainsi que décrit plus haut, il les transmet séparément à autant de files d'attente, respectivement QJpProX et QJpProY. Il est à noter que si une tâche est exécutée une fois dans un processeur et une fois un autre processeur, des périodes d'activation de cette seront présentes dans les deux files d'attente.

Auprès des ressources partagées ShMPi à ShMPk accédées par l'application journalisée APPJ, un agent de journalisation JVMM enregistre, pour chacune de ces ressources, des données de journalisation représentant la succession des accès continus alloués sur cette ressource. Ces données de journalisation des accès continus sont générées au sein du gestionnaire de mémoire virtuelle VMM, par le gestionnaire d'erreur de page PFH, au fur et à mesure des accès continus qu'il alloue aux différentes tâches.

Chaque enregistrement de ces données de journalisation d'accès comprend en particulier: - un identifiant univoque de la ressource partagée concernée, par exemple une adresse pour une zone de mémoire partagée; - un identifiant (PID ou TIP) de la tâche qui a obtenu cet accès; la durée de cet accès exclusif, par exemple obtenue selon la technique de comptage décrite ici; - les informations complémentaires permettant de compenser l'imprécision de ce comptage, par exemple une signature comme 30 décrit précédemment; - ainsi que certaines informations complémentaires utiles, par exemple, pour la virtualisation des ressources système et des différents évènements externes ou d'entrée/sortie.

- 29 - Ces données de journalisation sont transmises à une file d'attente de journalisation QJShMPi de type FIFO.

Selon les modes de réalisation, il est bien sûr possible de mémoriser le contenu de ces files d'attente dans un ou plusieurs fichiers journal, par exemple pour un usage ultérieur.

A partir de ces files d'attentes, les différentes données de journalisation sont transmises au système de rejeu UP2, par des moyens de communication tel qu'un réseau de communication informatique.

Les données de chaque file d'attente sont reçues par une file d'attente de rejeu qui correspond à la file d'attente émettrice.

En sortie de ces données de journalisation des différents processeurs journalisés pProX et pProY sont combinées entre elles, en fonction des données de journalisation d'accès, de façon à restituer la sérialisation combinée des périodes d'activation journalisées et des accès continus (exclusifs) alloués.

Une fois cette sérialisation, ou ordonnancement, de rejeu est définie au sein du système de rejeu, son exécution est lancée dans le processeur de rejeu.

Il est à noter que le nombre de processeurs au rejeu peut ne pas avoir d'importance en dehors des performances au rejeu, du moment que les tâches leurs sont réparties d'une façon qui ne brise pas l'ordonnancement de cette sérialisation de rejeu.

A partir d'une application journalisée APPJ sur un système multiprocesseur MP1, on peut ainsi obtenir un rejeu des périodes déterministes de ses différentes tâches TA, TB, TC sous la forme de tâches de rejeu TA', TB', TC' sur une machine de rejeu UP2. En combinant ce rejeu des périodes déterministes avec un journalisation et un rejeu des évènements non déterministes et en particulier des évènements externes, l'invention permet d'obtenir de façon performante une application de rejeu APPJ reproduisant le déroulement de l'application journalisée APPJ.

En transmettant les données de journalisation du système journalisé au système de rejeu au fur et à mesure de leur génération, on peut réaliser une application de rejeu suiveuse ou shadow qui se déroule exactement de la même façon que l'application journalisée, simplement avec un retard - 30 - temporel. On peut parle dans ce type de situation d'une configuration active-active , où les deux applications sont en cours d'exécution, par exemple par opposition aux techniques mémorisant l'état de l'application en prévision du futur.

Dans une telle configuration active-active , on peut considérer que l'application de rejeu APPR constitue une réplique active de l'application maître ou primaire. Cette réplique active présente un retard temporel qui peut dépendre de facteurs tels que les performances comparées des deux systèmes, auxquels s'ajoutent principalement les temps de transmission et de traitement des données de journalisation.

En première étude, les techniques décrites ici peuvent permettre d'implémenter une gestion de fonctionnement qui ne représente qu'une faible surcharge ( overhead ) par rapport à l'application d'origine ( legacy ), et une perte de performance pouvant être acceptable dans une situation d'exploitation.

L'invention permet avantageusement d'appliquer ce type de configuration active-active à l'implémentation d'une fiabilisation d'application, où la réplique active peut être utilisée comme une application miroir de l'original et prendre son relais en cas de défaillance ou sur un événement particulier. Par rapport à des implémentations matérielles de systèmes miroirs, l'invention permet beaucoup plus de souplesse dans le fonctionnement comme dans la gestion du matériel, du fait de sa meilleure indépendance par rapport aux caractéristiques matérielles des machines employées.

Une telle configuration permet alors d'apporter des fonctionnalités de tolérance de panne à une application existante, de façon souple et non intrusive tout en limitant les pertes de performances et sans y compris en architecture parallèle.

Ces avantages existent également en utilisant une telle configuration active-active pour réaliser une répartition ou un ajustement de charge de travail ( Joad balancing ), en redistribuant tout ou partie des services de l'application journalisées vers la réplique active. Il peut s'agir par exemple d'optimiser l'utilisation du matériel, ou d'en libérer une partie pour réaliser une maintenance relocative.

- 31 - Il est à noter que les différents mécanismes décrits ici utilisent la partie logicielle de façon bien dissociée de la partie matérielle. On obtient ainsi une bonne indépendance par rapport au matériel, ce qui, en particulier, rend l'implémentation plus simple et plus fiable et conserve de bonnes performances en laissant l'architecture gérer elle-même au mieux le parallélisme des différents éléments de calcul, qu'il s'agisse de processeurs ou d'ordinateurs.

De plus, du fait de l'implémentation le plus souvent purement logicielle de l'invention, il est possible d'utiliser du matériel standard avec les avantages que cela comporte.

L'invention permet en particulier d'étendre aux environnements parallèles des techniques de gestion de fonctionnement développées pour des applications multi-tâches fonctionnant en temps partagé sur un seul élément de calcul. L'invention permet ainsi en particulier d'intégrer de tels environnements parallèles dans des réseaux ou clusters, dans lesquels cette gestion de fonctionnement est implémentée au sein d'une application de type middleware, par exemple pour gérer des applications distribuées ou des applications à déploiement variable fournissant un service à la demande ( on demand ) Bien sûr, l'invention n'est pas limitée aux exemples qui viennent d'être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l'invention.

- 32 -

Claims (19)

REVENDICATIONS

1. Procédé de gestion d'une tâche informatique, dite cible, au cours d'une période déterminée d'exécution, dite période d'activité (SchJ, SchR) , au sein d'un système informatique, dans un processeur informatique doté de moyens de suivi ou d'estimation de performance incluant un compteur (PMC) pouvant présenter en plus ou en moins une erreur déterminée dite relative, ce procédé comprenant d'une part, une évaluation d'un nombre d'instructions exécutées (NR, Ni) en au moins un point déterminé de ladite période d'activité, à l'aide dudit compteur; et d'autre part une génération de données, dites signature (SGJ, SGR), lue ou calculée à partir de l'état du processeur ou du système informatique correspondant à au moins un point déterminé de ladite période d'activité.

2. Procédé selon la revendication 1, caractérisé en ce que l'évaluation du nombre d'instructions exécutées (Ni, NR) depuis le début de la période gérée utilise au moins une instruction d'appel système comme barrière de synchronisation conjointement au compteur (PMC).

3. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce qu'il gère une tâche au cours d'une période d'activité composée d'une suite d'opérations déterministes entre deux opérations non déterministes.

4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce qu'il gère une tâche (TJ) en cours de journalisation dans un processeur, dit de journalisation (pProX), et comprend une mémorisation de données de journalisation correspondant à cette période d'activité de ladite tâche, dite période journalisée (Sch3, SchJ), ces données de journalisation comprenant au moins une valeur supposée (Ni) du nombre d'instructions exécutées ainsi que la signature (SGJ) dite journalisée correspondant à la fin de ladite période journalisée.

- 33 -

5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce qu'il journalise l'utilisation d'un processeur (pProX) en mémorisant de façon ordonnée dans au moins un fichier dit journal de processeur (JpProX) des données de journalisation représentant la journalisation d'une succession de périodes d'activité (Schl, Sch2, Sch3) d'une pluralité de tâches (TA, TB, TA) exécutées dans ledit processeur et comprenant pour chacune de ces périodes une donnée (idJ) identifiant la tâche (TJ) exécutée.

6. Procédé selon la revendication 5, caractérisé en ce qu'il réalise, à partir des données de journalisation, un rejeu de la période journalisée (SchJ) en gérant une tâche dite rejouée (TR) exécutée par un processeur dit de rejeu (pProZ) au sein d'un système informatique de rejeu, à partir d'un état correspondant à l'état du processeur ou du système de journalisation au début de la période journalisée, le procédé comprenant en outre: - une phase d'exécution sous surveillance à partir du début de la période de rejeu d'un nombre d'instructions (NR), évalué par le compteur (PMC), inférieur ou égal à la valeur supposée (NJ) du nombre d'instructions de la période journalisée diminuée de l'erreur relative dudit compteur; - une phase de confirmation comprenant une itération des étapes suivantes interruption (46) de l'exécution de la tâche de rejeu en un point déterminé (TRIO, TRI2, TRI4) du rejeu; - test (47) de comparaison entre la signature journalisée (SGJ) et la signature (SGR) correspondant au point d'interruption du rejeu; 25

7. Procédé selon la revendication 6, caractérisé en ce que la signature journalisée (SGJ) inclue une donnée dite de pointeur journalisé (IPJ) représentant la valeur du pointeur d'instruction (IPJX3) de la tâche journalisée à la fin de la période journalisée (SchJ), le procédé comprenant en outre une mise en place (42) d'un point d'arrêt (BK) sur l'instruction de rejeu (BKI) correspondant à la donnée de pointeur journalisé (IPJ).

- 34 -

8. Procédé selon l'une des revendications 6 ou 7, caractérisé en ce que la surveillance de l'exécution de la tâche de rejeu (TR) comprend un débordement du compteur (PMC), préalablement initialisé de façon à évaluer le nombre d'instructions (NR) devant exécutées à partir du début de la période de rejeu et dont le débordement cause une interruption (41) de la tâche de rejeu.

9. Procédé selon la revendication 8, caractérisé en ce que le compteur (PMC) est initialisé au début de la période de rejeu avec une certaine marge, de façon à déborder (41) suffisamment tôt pour que, dans le cas d'une période de latence existant entre le débordement du compteur et l'interruption de la tâche qui l'a causé, le nombre d'instructions exécutées (NR) par la tâche de rejeu (TR) soit inférieur ou égal à la valeur supposée (Ni) du nombre d'instructions de la période journalisée diminuée de l'erreur relative dudit compteur.

10. Procédé selon l'une des revendications 6 à 9, caractérisé en ce que la phase de confirmation comprend une étape de sécurité signalant une erreur lorsque le nombre d'instructions rejouées (NR) dépasse la valeur supposée (NJ) du nombre d'instructions journalisées augmentée d'un nombre déterminé d'instructions.

11. Procédé selon l'une des revendications 6 à 10, caractérisé en ce qu'il réalise, dans un processeur de rejeu (pProZ), un rejeu de l'utilisation d'un processeur (pProX) journalisé, à partir ensemble (JpProX) ordonné de données de journalisation d'une succession de périodes d'activité (Schl, Sch2, Sch3) journalisées dans ledit processeur journalisé.

12. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il réalise une journalisation d'une succession d'accès continus attribués portant sur une ressource partagée dite cible (ShMPi), accédée par une pluralité de tâches journalisées, ce procédé transmettant ou mémorisant en outre au moins un fichier dit journal de ressource (JShmPi), comprenant au - 35 - moins une identification de la succession des différentes tâches ayant obtenu ces accès continus.

13. Procédé de gestion selon l'une des revendications 1 à 12, caractérisé en ce qu'il gère le fonctionnement d'au moins deux tâches applicatives (TA, TB), mis en oeuvre au sein d'un logiciel système gérant par activation séquentielle l'exécution desdites tâches (TA, TB) dans un système informatique, dit de journalisation, doté d'une structure parallèle comprenant des moyens de calcul aptes à exécuter plusieurs tâches applicatives simultanément dans au moins deux unités de calcul (pProX, pProY), ces deux tâches applicatives (TA, TB) accédant à au moins une ressource partagée (ShMPi), le procédé comprenant: - une journalisation d'une première succession de périodes d'activation de l'une ou l'autre de ces tâches dans une première unité de calcul (pProX) ; et une journalisation d'une deuxième succession de périodes d'activation de l'une ou l'autre de ces tâches dans une deuxième unité de calcul (pProY) ; - et une journalisation d'une succession d'attributions à l'une ou l'autre de ces tâches dite accédante, en réponse à une demande d'accès (InstrA) à ladite ressource cible, d'un accès dit continu à ladite ressource cible, c'est à dire de façon à exclure tout accès à ladite ressource cible (ShMPi) par une autre de ces tâches pendant la totalité de la période d'activation (SchA) de la tâche accédante suivant immédiatement ladite demande d'accès; le procédé comprenant en outre une combinaison, en une structure ordonnée dite sérialisation de rejeu, des données de journalisation (QJpProX, QJpProY) représentant les successions de périodes d'activation dans chacune des unités de calcul avec les données de journalisation (QJShmPi) représentant la succession des accès continus attribués, de façon à conserver l'ordre de succession des périodes d'activation au sein de chaque tâche (TA, TB, TC) et vis à vis de ladite ressource partagée (ShmPi).

- 36 -

14. Procédé selon la revendication 13, caractérisé en ce que les données de la sérialisation de rejeu sont utilisées dans un système informatique de rejeu (UP2) pour rejouer (TA', TB', TC') le déroulement journalisé des tâches journalisées (TA, TB, TC).

15. Procédé selon l'une des revendications 13 ou 14, caractérisé en ce qu'il comprend une virtualisation, au sein du système informatique de rejeu (UP2), de tout ou partie des ressources logicielles accessibles aux tâches journalisées lors de la journalisation.

16. Procédé selon l'une des revendications 14 à 15, caractérisé en ce qu'il réalise une réplication dite active du fonctionnement d'une application journalisée (APPJ) comprenant au moins deux tâches, exécutées sur au moins un noeud à structure parallèle dit noeud primaire d'un réseau d'ordinateurs et accédant à au moins une ressource partagée, cette réplication comprenant un rejeu, dans au moins une application de rejeu sur un système de rejeu, d'une sérialisation de rejeu issue de données de journalisation transmises du noeud primaire vers le noeud secondaire au fur et à mesure de leur génération.

17. Procédé selon la revendication 16, caractérisé en ce qu'il réalise une fiabilisation d'une application comprenant au moins deux tâches, exécutées sur au moins un noeud à structure parallèle dit noeud primaire d'un réseau d'ordinateurs et accédant à au moins une ressource partagée, cette fiabilisation comprenant en outre un basculement de service, du noeud primaire vers au moins un noeud secondaire en lieu et place du noeud primaire, déclenché à la suite d'une détection d'un événement ou d'une défaillance au sein du noeud primaire.

18. Procédé selon la revendication 16, caractérisé en ce qu'il réalise une répartition ou un ajustement de charge de travail au sein d'un réseau d'ordinateurs exécutant sur au moins un noeud secondaire une réplique active (APPR) d'une application cible (APPJ) exécutée sur un noeud primaire, - 37 - cette répartition de charge comprenant un basculement vers la réplique active de tout ou partie du service assuré par l'application gérée.

19. Système mettant en oeuvre un procédé selon l'une des revendications 5 1 à 18.