FR3056786B1 - Procede de gestion des taches de calcul sur un processeur multi-cœurs fonctionnellement asymetrique - Google Patents

Procede de gestion des taches de calcul sur un processeur multi-cœurs fonctionnellement asymetrique Download PDF

Info

Publication number
FR3056786B1
FR3056786B1 FR1659367A FR1659367A FR3056786B1 FR 3056786 B1 FR3056786 B1 FR 3056786B1 FR 1659367 A FR1659367 A FR 1659367A FR 1659367 A FR1659367 A FR 1659367A FR 3056786 B1 FR3056786 B1 FR 3056786B1
Authority
FR
France
Prior art keywords
instructions
core
specialized
hardware
heart
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
FR1659367A
Other languages
English (en)
Other versions
FR3056786A1 (fr
Inventor
Karim Ben Chehida
Paul-Antoine ARRAS
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Original Assignee
Commissariat a lEnergie Atomique CEA
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Commissariat a lEnergie Atomique CEA, Commissariat a lEnergie Atomique et aux Energies Alternatives CEA filed Critical Commissariat a lEnergie Atomique CEA
Priority to FR1659367A priority Critical patent/FR3056786B1/fr
Priority to US16/333,974 priority patent/US10846086B2/en
Priority to EP17761281.9A priority patent/EP3519954A1/fr
Priority to PCT/EP2017/072376 priority patent/WO2018059897A1/fr
Publication of FR3056786A1 publication Critical patent/FR3056786A1/fr
Application granted granted Critical
Publication of FR3056786B1 publication Critical patent/FR3056786B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30145—Instruction analysis, e.g. decoding, instruction word fields
    • G06F9/30156—Special purpose encoding of instructions, e.g. Gray coding
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3206—Monitoring of events, devices or parameters that trigger a change in power modality
    • G06F1/3228—Monitoring task completion, e.g. by use of idle timers, stop commands or wait commands
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3885—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5044—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering hardware capabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/509—Offload
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Procédé de la gestion d'une tâche de calcul sur un processeur multi-cœurs fonctionnellement asymétrique comprenant une pluralité de cœurs (PC1 - PC4) dont au moins un comprend au moins une extension matérielle (HW1, HW2) permettant l'exécution d'instructions spécialisées, comprenant les étapes suivantes : a) démarrer l'exécution de la tâche de calcul sur un cœur du processeur ; b) effectuer un suivi d'un paramètre (QoS) indicatif d'une qualité de service de la tâche de calcul, ainsi que d'un nombre d'instructions spécialisées chargées par ledit cœur ; c) identifier des instants découpant une période applicative de la tâche de calcul en un nombre prédéterminé de portions (PTS) ; d) calculer des coûts ou gains en qualité de service et en consommation énergétique correspondant à différentes options de gestion de la tâche de calcul ; et e) effectuer un choix de gestion en fonction des coûts ou gains ainsi calculés. Produit programme d'ordinateur, processeur et système informatique pour la mise en œuvre d'un tel procédé.

Description

PROCEDE DE GESTION DES TACHES DE CALCUL SUR UN PROCESSEUR MULTI-CŒURS FONCTIONNELLEMENT ASYMETRIOUE L'invention porte sur un procédé mis en œuvre par ordinateur pour la gestion de tâches de calcul sur un processeur multi-cœurs fonctionnellement asymétrique. Elle porte également sur un produit programme d’ordinateur, un processeur multi-cœurs et un système informatique pour la mise en œuvre d’un tel procédé.
Un processeur multi-cœurs peut comprendre une ou plusieurs extensions matérielles, destinées à accélérer des parties de codes logiciels spécifiques. Par exemple, ces extensions matérielles peuvent comprendre des circuits pour du calcul en virgule flottante ou du calcul vectoriel.
Un processeur multi-cœurs est dit «fonctionnellement asymétrique » quand tous les cœurs ne possèdent pas les mêmes extensions matérielles, et par conséquent certaines extensions font défaut à certains cœurs de processeurs. Ainsi, un processeur fonctionnellement asymétrique se caractérise par une distribution (ou association) inégale des extensions aux cœurs de processeurs. Il existe un jeu d’instructions commun à tous les cœurs et des jeux d’instructions spécifiques associés à des extensions matérielles respectives, présentes dans certains cœurs. En faisant l’union de tous les jeux d’instructions des cœurs du processeur, toutes les instructions requises par l’exécution d’une tâche de calcul d’une application sont représentées.
La gestion d’un processeur multi-cœurs fonctionnellement asymétrique pose plusieurs problèmes techniques, et notamment celui de gérer efficacement le placement des tâches de calcul sur les différents cœurs de processeur.
Les applications logicielles utilisent ces extensions matérielles d’une manière dynamique, c’est-à-dire qui varie au cours du temps. Pour une même application, certaines phases de calcul vont utiliser presque à pleine charge une extension donnée (par exemple des calculs sur des données de type virgule flottante) tandis que d’autres phases de calcul l’utiliseront peu voire pas du tout (par exemple des calculs sur des données de type entier).
Utiliser une extension n’est pas toujours efficace en termes de performance ou d’énergie (« qualité » d’utilisation).
Les travaux publiés concernant le placement de tâches de calcul (ordonnancement) sur des processeurs multi-cœurs fonctionnellement asymétriques ne décrivent pas de solutions pleinement satisfaisantes. L’article de H. Shen et F. Pétrot, « Novel Task Migration Framework on Configurable Heterogeneous MPSoC Platforms », Proceedings of the 2009 Asia and South Pacific Design Automation Conférence, Piscataway, NJ, USA, 2009, pp. 733-738, décrit une technique d’ordonnancement hors ligne dite « par affinité >>, qui consiste à figer l’allocation d’une tâche à un processeur (ou à un type de processeur) avant l’exécution suite à une analyse hors ligne de l’application (faite à la main, par des outils d’analyse de code ou par le compilateur) et l’ordonnanceur en ligne suit exactement ces directives. L’inconvénient principal de cette approche est qu’aucune autre optimisation n’est permise en ligne lorsque les applications sont dynamiques et leur ratio d’utilisation des ressources varie avec le temps et les données. L’article de G. Georgakoudis, D. S. Nikolopoulos, H. Vandierendonck, et S. Lalis, « Fast Dynamic Binary Rewriting for flexible thread migration on shared-ISA heterogeneous MPSoCs >>, 2014
International Conférence on Embedded Computer Systems: Architectures, Modeling, and Simulation (SAMOS XIV), 2014, pp. 156-163, décrit une technique - dite de réécriture binaire dynamique - qui procède à une réécriture sur faute (c'est-à-dire quand une instruction spécialisée est chargée par un cœur ne la supportant pas) par émulation des instructions non supportées. C’est une technique flexible et qui peut être performante, associée à un ordonnanceur dynamique intelligent. Toutefois, les coûts de réécriture et d’émulation peuvent s’avérer très importants. L’article de T. Li, P. Brett, R. Knauerhase, D. Koufaty, D. Reddy et S. Hahn, « Operating System support for overlapping-ISA heterogeneous multi-core architectures», 2010 IEEE 16th International Symposium on High Performance Computer Architecture (HPCA), 2010, pp. 1-12 décrit une technique dite de migration sur faute. Elle consiste à migrer l’exécution d’une tâche (à la granularité d’un quantum d’instructions), dès lors qu’une instruction spécialisée non-supportée par l’unité d’exécution actuelle est rencontrée, vers une ressource possédant l’extension matérielle correspondante. Son principal point faible est qu’elle peut provoquer des migrations intempestives et un déséquilibrage de charge entre cœurs de base et cœurs avec extension.
La thèse de A. Aminot « Méthode dynamique pour améliorer le placement de tâches sur processeurs asymétriques en fonctionnalités » Université de Grenoble, France, 2015, décrit un procédé d’allocation dynamique des tâches de calcul dans lequel le choix du cœur sur lequel une tâche est exécutée est effectué à partir d’une estimation à la compilation du coût d’émulation de ladite tâche. Cette estimation est obtenue à partir de la mesure du nombre d’utilisation de différentes instructions spécialisées lors d’exécutions antérieures de la même tâche. Bien qu’intéressante dans son principe, cette technique n’est pas optimisée et nécessite aussi d’embarquer une version du binaire de la tâche par extension présente dans l’architecture ; en outre, elle ne permet pas d’assurer le respect de contraintes de qualité de service (QoS, de l’anglais « Quality of Service »). L’invention vise à surmonter, en tout ou au moins en partie, les inconvénients précités de l’art antérieur. Plus particulièrement elle vise à permettre à la fois une utilisation optimale des ressources de calcul (notamment en termes d’énergie) et le respect de contraintes de QoS. Pour ce faire, elle perfectionne l’approche proposée dans la thèse précitée de A. Aminot.
Pour atteindre ce but, l’invention apporte plusieurs améliorations à l’art antérieur, pouvant être mises en œuvre séparément ou en combinaison. En particulier :
Conformément à l’invention, les choix de gestion sont effectués à des instants clés de l’exécution de chaque application, identifiés de manière dynamique au lieu d’être prédéfinis, permettant la garantie de QoS et minimisant l’énergie consommée.
Dans certains modes de réalisation de l’invention, des moyens matériels spécifiques (compteurs...) sont prévus pour faciliter la détermination de ces instants clés.
Les choix de gestion sont effectués en prenant en compte un « coût d’opportunité » en QoS et en énergie de chaque option d’exécution. Cela permet de quantifier exactement l’écart en termes de performance par rapport à une consigne de QoS minimale qu’on cherche à garantir. Une nouvelle méthode de calcul de ce coût d’opportunité est aussi proposée. L’invention propose également, dans une première étape de caractérisation, une méthode de sélection de différentes classes d’instructions selon leurs coûts d’émulation en termes de performance et d’énergie, permettant de minimiser l’erreur d’estimation du coût d’opportunité de chaque opportunités (ou « options ») de gestion.
Un objet de l’invention est un procédé mis en œuvre par ordinateur pour la gestion d’une tâche de calcul sur un processeur multi-cœurs fonctionnellement asymétrique, l’exécution de ladite tâche comprenant une succession de périodes applicatives, ledit processeur comprenant une pluralité de cœurs partageant des instructions dites basiques, au moins un dit cœur comprenant au moins une extension matérielle, ladite ou chaque extension matérielle étant adaptée pour permettre l’exécution d’instructions, dites spécialisées, différentes desdites instructions basiques, chaque instruction spécialisée étant ainsi associée à une dite extension matérielle, le procédé comprenant les étapes suivantes : a) démarrer l’exécution de la tâche de calcul sur un cœur dudit processeur ; b) effectuer, au cours de ladite exécution, un suivi d’un paramètre indicatif d’une qualité de service de la tâche de calcul, ainsi que d’au moins un nombre d’instructions spécialisées chargées par ledit cœur; c) sur la base dudit suivi, identifier des instants découpant une période applicative de la tâche de calcul en un nombre prédéterminé de portions de telle façon que, au cours de chacune desdites portions, un nombre sensiblement égal d’instructions spécialisées associées à une extension matérielle prédéfinie soient chargées par ledit cœur ; d) calculer, auxdits instants et en fonction dudit suivi, des coûts ou gains en qualité de service et en consommation énergétique correspondant à différentes options de gestion de la tâche de calcul ; et e) effectuer un choix de gestion comprenant une décision de poursuivre l’exécution sur le même cœur du processeur ou sur un cœur différent en fonction des coûts ou gains ainsi calculés.
Selon des modes de réalisation particuliers d’un tel procédé : Ladite étape c) peut comprendre la prévision du nombre d’instructions spécialisées associées à ladite extension matérielle chargées au cours de chaque portion d’une période applicative courante à partir du nombre de dites instructions spécialisées chargées lors de portions correspondantes d’au moins une période applicative précédente.
Ladite extension matérielle prédéfinie peut être celle adaptée pour permettre l’exécution des instructions spécialisées dont l’émulation présenterait le coût en qualité de service le plus élevé.
Le choix de gestion effectué lors de l’étape e) peut comprendre la décision de poursuivre l’exécution de la tâche de calcul sur le même cœur ou sur un cœur différent de manière à minimiser la consommation énergétique du processeur tout en respectant une contrainte de qualité de service.
Plus particulièrement, ladite étape e) peut comprendre : e1) déterminer une marge de qualité de service sur une période applicative précédente ; e2) distribuer cette marge entre les portions de la période courante ; et e3) pour chaque portion de la période courante, effectuer un dit choix de gestion permettant de diminuer la consommation énergétique sous contrainte de respect de la marge de qualité de service distribuée audit portion, lorsque cela est possible.
En variante, lors de l’étape a), l’exécution de la tâche de calcul peut être démarrée sur un cœur ne comprenant pas d’extensions matérielle et, lors de ladite étape e), une décision de poursuive l’exécution de la tâche de calcul sur un autre processeur, comprenant au moins une exécution matérielle, peut être prise lorsque cela est nécessaire pour assurer le respect d’une contrainte de qualité de service.
Ledit choix de gestion peut comprendre également une décision de maintenir ou de changer un couple fréquence d’horloge - tension d’alimentation du cœur.
Les instructions spécialisées associées à chaque extension matérielle peuvent être regroupées en un nombre prédéfini de familles, ce nombre étant supérieur à 1 pour au moins une dite extension matérielle et au moins une dite famille comprenant plusieurs instructions ; et, lors de l’étape d), les instructions d’une même famille peuvent être considérées comme une seule et même instruction aux fins du calcul desdits coûts ou gains en qualité de service et en consommation énergétique.
Plus particulièrement, le nombre de familles dans lequel les instructions spécialisées associées à chaque extension matérielle sont regroupées peut être choisi de manière à minimiser des erreurs affectant le calcul des coûts ou gains en qualité de service et en consommation énergétique effectué lors de l’étape d). L’étape b) peut comprendre le suivi : du nombre d’instructions basiques; du nombre d’instructions spécialisées associées à chaque extension matérielle que ledit cœur ne comprend pas ;du nombre d’instructions spécialisées appartenant à chaque famille d’instructions spécialisées associées à chaque extension matérielle que ledit cœur comprend ; et du nombre d’instructions basiques utilisées pour l’émulation des instructions spécialisées associées à chaque extension matérielle que ledit cœur ne comprend pas ; chargées par ledit cœur.
Le procédé peut comporter également une étape préalable de chargement en mémoire d’un ensemble de paramètres de caractérisation représentatifs d’une distribution statistique des coûts d’émulation en temps et énergie des instructions spécialisées, dans lequel l’étape d) est mise en œuvre utilisant lesdits paramètres de caractérisation.
Le procédé peut comporter également une étape préalable d’étalonnage pour déterminer lesdits paramètres d’étalonnage.
Un autre objet de l’invention est un produit programme d’ordinateur stocké sur un support non-volatil lisible par ordinateur comprenant des instructions exécutables par ordinateur pour la mise en œuvre d’un tel procédé.
Un autre objet de l’invention est un processeur multi-cœurs fonctionnellement asymétrique comprenant une pluralité de cœurs partageant des instructions dites basiques, au moins un dit cœur comprenant au moins une extension matérielle, ladite ou chaque extension matérielle étant adaptée pour permettre l’exécution d’instructions, dites spécialisées, différentes desdites instructions basiques, chaque instruction spécialisée étant ainsi associée à une dite extension matérielle, caractérisé en ce qu’il comprend également : des circuits de filtrage, configurés pour trier les instructions basiques et les instructions spécialisées associées aux différentes extensions matérielles, et pour attribuer chaque instruction spécialisée à une famille ; et pour chaque cœur : un compteur d’instructions basiques chargées par le cœur ; pour chaque extension matérielle non comprise par ledit cœur, un compteur d’instructions spécialisées associées à ladite extension matérielle chargées par le cœur, ainsi qu’un compteur du nombre d’instructions basiques utilisées pour l’émulation des instructions spécialisées associées ; et pour chaque extension matérielle comprise par ledit cœur, et pour chaque famille d’instructions spécialisées associées à ladite extension matérielle, un compteur d’instructions spécialisées associées à ladite extension matérielle et appartenant à ladite famille chargées par le cœur.
Encore un autre objet de l’invention est un système informatique comprenant un tel processeur multi-cœurs fonctionnellement asymétrique et une mémoire non-volatile stockant des instructions exécutables par ledit processeur pour la mise en œuvre d’un procédé selon l’invnetion. D’autres caractéristiques, détails et avantages de l’invention ressortiront à la lecture de la description faite en référence aux dessins annexés donnés à titre d’exemple et qui représentent, respectivement :
La figure 1, un exemple de processeur multi-cœurs fonctionnellement asymétrique, dont l’architecture est connue de l’art antérieur ;
La figure 2, un histogramme du coût d’émulation d’une instruction de calcul en virgule flottante ;
La figure 3, le processeur multi-cœurs fonctionnellement asymétrique de la figure 1, équipé de compteurs matériels d’instructions conformément à un mode de réalisation de l’invention ;
La figure 4, un graphique illustrant le découpage de l’exécution d’une application en périodes applicatives, le suivi de la qualité de service pour chaque période et du nombre d’instructions spécialisées chargées pour chaque extension matérielle ;
La figure 5, un graphique illustrant le découpage des périodes applicatives en segments, conformément à un mode de réalisation de l’invention ; et
La figure 6, un graphique illustrant les choix de gestion effectués conformément à un mode de réalisation de l’invention.
Dans la suite, on entend par : « Extension matérielle », ou plus simplement « extension » (« Hardware Extension » en anglais), un circuit tel qu’une unité de calcul sur données flottantes (FPU de l’anglais « Floating Point Unit »), une unité de calcul vectoriel, une unité de traitement cryptographique, une unité de traitement du signal, etc. Une extension matérielle introduit un circuit matériel spécialisé accessible ou relié à un cœur de processeur, lequel circuit fournit de hautes performances pour des tâches de calcul spécifiques. Un tel circuit spécifique améliore les performances et l’efficacité énergétique d’un cœur pour des calculs particuliers, mais leur utilisation intensive peut conduire à réduire la performance en termes de Watt par unité de surface. Ces extensions matérielles associées au cœur de processeur sont fournies avec un jeu d’instruction qui étend le jeu standard ou par défaut (ISA). Les extensions matérielles sont généralement bien intégrées dans la chaîne de traitement (« pipeline ») du cœur, ce qui permet d’accéder efficacement aux fonctions par des instructions ajoutées à l’ensemble « basique ».
La fonction d’une extension matérielle est d’accélérer le traitement d’un jeu d’instructions spécifique: une extension matérielle peut ne pas accélérer le traitement d’un autre type d’instruction (e.g. virgule flottante versus entier). « Cœur étendu », un cœur de processeur comprenant un cœur « basique », supportant un ensemble minimal d’instructions commun à tous les cœurs du processeur, augmenté d’une ou plusieurs extensions matérielles. «Tâche de calcul» (« thread » en anglais), l’exécution d’un ensemble d’instructions du langage machine d’un processeur. Un processus comprend en général plusieurs tâches de calcul qui, du point de vue de l’utilisateur, semblent se dérouler en parallèle. Les différentes tâches d’un même processus partagent la même mémoire virtuelle, mais présentent chacune sa propre pile d’appel.
Comme cela a été évoqué plus haut, dans une architecture multi-cœurs fonctionnellement asymétrique un cœur de processeur peut être associé avec aucune (i.e. zéro), une ou plusieurs extensions matérielles. Ces extensions matérielles lui sont alors « exclusives », c'est-à-dire une extension matérielle donnée ne peut pas être accédée depuis un cœur tiers. Le cœur de processeur comprend la ou les extensions matérielles.
Un cœur de processeur (ou simplement « cœur ») est un ensemble de circuits physiques capables d’exécuter des programmes de façon « autonome ». Une extension matérielle est capable d’exécuter une partie de programme mais n’est pas « autonome » : elle requiert l’association avec au moins un cœur de processeur.
La figure 1 illustre de manière schématique l’architecture d’un processeur multi-cœurs fonctionnellement asymétrique PR intégrant quatre cœurs PC1, PC2, PC3, PC4 qui partagent une base commune appelée « cœur basique » BASE et qui peuvent posséder chacune une ou plusieurs extensions matérielles HW1, HW2, leur procurant des fonctionnalités plus ou moins étendues. Plus précisément, le cœur PC1 est « complet », c'est-à-dire qu’il comprend le cœur basique et les deux extensions matérielles disponibles ; les cœurs PC2 et PC3 comprennent, en plus du cœur basique, la seule extension HW1 ou HW2, respectivement ; et le cœur PC4 est « basique », ne comprenant pas d’extensions matérielles.
La référence MM désigne une mémoire morte stockant des instructions exécutables par le processeur PR et permettant de mettre en œuvre le procédé de l’invention.
Les cœurs de processeur autres que PC1 ne comprennent pas toutes les extensions matérielles disponibles. Ainsi, lorsqu’une tâche de calcul est exécutée par un tel cœur, il est possible que ce dernier rencontre des instructions spécifiques associées à des extensions matérielles qu’il ne possède pas. Il est donc nécessaire d’effectuer un « choix de gestion » : continuer l’exécution sur le cœur de processeur actuel en émulant les instructions spécialisées non supportées (c'est-à-dire en les convertissant en séries d’instructions basiques) ou migrer la tâche sur cœur muni des extensions matérielles requises ; dans les deux cas, il est également possible d’agir sur le couple tension-fréquence. Chacune de ces options présente un coût en termes d’énergie consommée et de Qualité de Service (QoS), ce dernier paramètre pouvant notamment être représenté par l’inverse d’un temps d’exécution. L’invention permet d’optimiser les choix de gestion grâce à une prédiction précise de la qualité de service (QoS) et de l’énergie dissipée liée à chaque opportunité de gestion possible, facilitant ainsi la prise en compte de plusieurs critères.
Cette prédiction nécessite une étape préliminaire d’étalonnage, mise en œuvre « hors ligne », consistant à caractériser les coûts en temps et en énergie d’exécution des différentes instructions spécifiques sur les cœurs basiques (en émulant ces instructions) et étendus (en les exécutants normalement sur ces cœurs). Selon un mode de réalisation préféré de l’invention, cette étape comprend la détermination (généralement empirique) de paramètres d’étalonnage représentatifs de la distribution statistique des coûts d’émulation en temps et énergie des instructions spécialisées. Par exemple, ces paramètres peuvent être le coût maximum, le coût minimum, le coût moyen et l’écart type de la distribution des coûts, mesurés sur plusieurs exécutions de ces instructions, avec des enchaînements différents et des jeux de données variées.
Avantageusement, ces paramètres ne sont pas déterminés pour chaque instruction considérée de manière isolée, mais pour des « familles » comprenant des instructions spécifiques associées à une même extension matérielle et présentant des coûts d’exécution comparables. Cela présente un double avantage : premièrement, une simplification des opérations de prédiction du coût des tâches (effectuées « en ligne »), deuxièmement - si la décomposition en familles est effectuée de manière opportune - une minimisation de l’erreur d’estimation effectuée lors de ces opérations de prédiction.
Par exemple, sur le cœur RISC-V le coût de l’émulation en nombre d’instructions basiques équivalentes pour les instructions spécifiques de type virgule flottantes varie de 150 à 470 instructions basiques. La figure 2 donne le coût d’émulation de l’instruction racine carrée en virgule flottante « fsqrt » en instructions basiques équivalentes (axe des ordonnées). Elle comporte une partie constante (rectangle en trait épais dans la figure 2) avec plus de 120 instructions équivalentes (pour la sauvegarde de contexte, sa restitution et l’appel à la routine d’émulation) et une partie dépendante de l’instruction à émuler (trait fin). Le coût moyen d’émulation de cette instruction est de 360 instructions basiques avec un écart type important, représenté par une barre d’erreur.
La solution consistant à regrouper les instructions spécifiques à virgule flottante en une seule famille et considérer un coût moyen de 282 instructions basiques, correspondant à la caractérisation hors ligne de ces instructions spécifiques, donne une erreur d’estimation de l’ordre de 25-50% sur les jeux de tests considérés, ce qui n’est pas satisfaisant.
Selon un mode de réalisation de l’invention, on propose de procéder à une décomposition par l’exploration du nombre de familles « / » et de la largeur de l’intervalle de coût de chaque famille qui minimise l’erreur d’estimation du coût d’émulation (en temps et énergie) des instructions spécifiques considérées. Cette exploration est faite sur la base de jeux de tests incluant des tests unitaires par instruction et des tests d’applications réelles issues d’ensembles de tests communément utilisées par la communauté scientifique. Elle peut être conduite de manière expérimentale / empirique, comme par l’utilisation d’une heuristique ou de tout autre algorithme de recherche opérationnelle. Par exemple, il est avantageux de regrouper les instructions possédants un écart type faible ou une fréquence d’occurrence importante ensemble afin d’éviter de dégrader l’erreur d’estimation finale. L’augmentation du nombre de familles réduit la largeur des intervalles de coûts et de la sorte l’erreur d’estimation de ces coûts. Mais si on augmente énormément le nombre de familles, un phénomène inverse est observé qui fait remonter l’erreur d’estimation dû à l’écart type du coût d’émulation de certaines instructions. Un compromis est donc à trouver aussi parce qu’ensuite, comme cela sera expliqué en détail plus loin, une surveillance est nécessaire en mettant en œuvre des compteurs spécifiques pour chaque famille d’instructions.
Une étude a été effectuée sur la base du cœur de processeur RISC-V. En imposant une erreur d’estimation maximale tolérable de 5%, il a été possible de délimiter deux familles d’instructions à virgule flottante avec une erreur moyenne de 3% et une erreur maximale de 4%.
Pour chaque extension (HWm), et une fois le nombre de familles « / » et leurs coûts moyens en termes de nombre d’instructions basiques équivalent (Coût_moy_lnst(m, et d’énergie (Coût_moy_E(rrK $ déterminés, ces caractéristiques hors ligne vont être embarquées et utilisées en ligne pour l’estimation des coûts/gains en performance et en énergie des différentes opportunités de gestion.
Pour obtenir cette estimation, il est nécessaire de mettre en œuvre - en ligne - plusieurs étapes : 1. Un suivi de la QoS et de l’exécution d’instructions spécialisées ; 2. Un découpage de chaque période applicative de la tâche de calcul considéré en « portions », effectué en fonction de ce suivi ; 3. Le calcul des coûts ou gains en qualité de service et en consommation énergétique correspondant à différentes opportunités, ou options, de gestion. Ce calcul se base sur le découpage des périodes applicatives et sur les données obtenues par le suivi. 1. Suivi de l’exécution des instructions spécialisées et de la
QoS applicative 1.1 Suivi de l’exécution des instructions spécialisées
Afin de mieux prédire l’exécution future des instructions spécialisées, un suivi (monitoring) de l’exécution passée de ces instructions et leur classement selon leurs familles respectives est nécessaire. Ce suivi consiste principalement en un comptage du nombre d’instructions spécialisées associées à chaque extension. Plus précisément, chaque cœur doit compter : le nombre d’instructions spécialisées associées à chaque extension matérielle que le cœur ne comprend pas (ces instructions provoquent une exception qui appelle une routine d’émulation) ; pour les instructions spécialisées associés aux extensions matérielles que le cœur comprend, le nombre d’instructions spécialisées associées à chaque famille (ces instructions sont exécutées directement) ; et le nombre d’instructions basiques.
Selon un mode de réalisation préféré de l’invention, le suivi est réalisé grâce à des circuits numérique de filtrage d’une partie de l’encodage binaire de chaque instruction (« opcode », de l’anglais « operation code » c'est-à-dire « code d’opération »), permettant de trier les instructions basiques et les instructions spécialisées associées aux différentes extensions matérielles et, le cas échéant, pour attribuer chaque instruction spécialisée à une famille, ainsi qu’à des compteurs matériels semblables aux compteurs communément présents dans les processeurs embarqués (compteurs de cycles, compteurs d’instructions flottantes, compteurs de défaut de caches...), qui compteraient l’occurrence des instructions de chaque famille. Ces compteurs peuvent être lus, et des remises à zéro peuvent être commandées à des instants biens spécifiques de la méthode. On privilégie le comptage d’instructions chargées par le cœur car le chargement des instructions est toujours effectué quel que soit le type de cœur (elles peuvent ensuite être exécutées si le cœur les supporte ou provoquer une exception et appeler une routine d’émulation dans le cas contraire).
Sur la figure 3 :
Le cœur PC1 comprend : un ensemble de compteurs Nb(HW1,i) comptabilisant le nombre d’instructions chargées appartenant à chaque famille « i » de l’extension matérielle « HW1 » ; un ensemble de compteurs Nb(HW2,i) comptabilisant le nombre d’instructions chargées appartenant à chaque famille « i » de l’extension matérielle « HW2 » ; et un compteur Nb_basic comptabilisant le nombre d’instructions basiques chargées.
Le cœur PC2 comprend : un ensemble de compteurs Nb(HW1,i) comptabilisant le nombre d’instructions chargées appartenant à chaque famille « i » de l’extension matérielle « HW1 » ; un compteur Nb(HW2) comptabilisant le nombre d’instructions chargées associées à l’extension matérielle « HW2 », sans distinguer les différentes familles d’instructions ; un compteur Nb_basic comptabilisant le nombre d’instructions basiques chargées ; et un compteur Nb_emul(HW2). comptabilisant le nombre d’instructions basiques utilisées pour émules les instructions spécialisées associées à l’extension matérielle « HW2 ».
Le cœur PC3 comprend : un compteur Nb(HW1) comptabilisant le nombre d’instructions chargées associées à l’extension matérielle « HW1 », sans distinguer les différentes familles d’instructions ; un ensemble de compteurs Nb(HW2,i) comptabilisant le nombre d’instructions chargées appartenant à chaque famille « i » de l’extension matérielle « HW2 » ; un compteur Nb_basic comptabilisant le nombre d’instructions basiques chargées ; et un compteur Nb_emul(HW1). comptabilisant le nombre d’instructions basiques utilisées pour émules les instructions spécialisées associées à l’extension matérielle « HW1 ».
Le cœur PC4 comprend : un compteur Nb(HW1) comptabilisant le nombre d’instructions chargées associées à l’extension matérielle « HW1 », sans distinguer les différentes familles d’instructions ; un compteur Nb(HW2) comptabilisant le nombre d’instructions chargées associées à l’extension matérielle « HW2 », sans distinguer les différentes familles d’instructions ; un compteur Nb_basic comptabilisant le nombre d’instructions basiques chargées un compteur Nb_emul(HW1). comptabilisant le nombre d’instructions basiques utilisées pour émules les instructions spécialisées associées à l’extension matérielle « HW1 » ; et un compteur Nb_emul(HW2). comptabilisant le nombre d’instructions basiques utilisées pour émules les instructions spécialisées associées à l’extension matérielle « HW2 ».
Les circuits de filtrage des instructions ne sont pas représentés pour ne pas surcharger la figure.
Avantageusement, les circuits numériques de filtrage effectuent le filtrage des instructions chargées par le cœur au moment du décodage d’instruction (filtrage d opcode) pour identifier si l’instruction courante est de type « m » (c'est-à-dire est associée à l’extension matérielle « m ») et, le cas échéant, si elle appartient à la famille « i » de cette extension. Une optimisation possible de ce mode de réalisation consiste à rectifier la découpe en familles faite dans la première étape de la méthode pour ramener ces intervalles à des classes d’instructions similaires (accès mémoire, calcul, contrôle...) qui partagent un même opcode facilitant ainsi le filtrage des instructions au moment du décodage. Un calcul de l’erreur d’estimation avec la nouvelle découpe doit être effectué pour vérifier qu’elle reste en dessous de l’erreur tolérable.
Pour le comptage des instructions basiques (Nb_basic), il peut être avantageux d’effectuer le filtrage des instructions spécialisées au moment du décodage par opcode et débrayer le compteur Nb_basic lors de l’exécution de ces instructions. Le compteur Nb_basic est aussi débrayé à l’entrée d’une exception et embrayé à sa sortie.
En principe, ces compteurs pourraient être mis en œuvre de manière logicielle, mais cela serait coûteux en temps et en énergie. Une réalisation au moins partiellement matérielle est donc préférée.
Le suivi des instructions chargées, effectué par l’intermédiaire de ces compteurs, permet de calculer le ratio d’utilisation de l’ensemble d’instructions spécialisées associées à chaque extension matérielle « m » (indépendamment du fait que ces instructions soient effectivement exécutées par l’extension matérielle idoine ou soient émulées par un cœur basique) :
[1]
Dans le cas où le comptage se fait par familles, Nb(m) est obtenu en sommant Nb(m,i) pour toutes les valeurs de « i ». 1.2 Suivi de la QoS applicative
Ce suivi peut se baser sur une technique d’instrumentation peu intrusive du code applicatif comme la technique « Heartbeat », divulguée par la publication : H. Hoffmann, J. Eastep, M. D. Santambrogio, J. E. Miller, A. Agarwal, « Application Heartbeats: A Generic Interface for Specifying Program Performance and Goals in Autonomous Computing Environments », Proceedings of the 7th International Conférence on Autonomie Computing, New York, NY, USA, 2010, pp. 79-88.
Elle permet au système de récupérer des évènements applicatifs (appelés « pulsations applicatives », ou simplement « pulsations » dans la suite) permettant de calculer une qualité de service puis de vérifier qu’elle est au-dessus d’une consigne de QoS minimale donnée par l’utilisateur. Ces évènements applicatifs servent aussi à enclencher des actions de gestion qui seraient plus ou moins agressives selon la marge sur la QoS qu’on vient de calculer. Cela est illustré sur la figure 4, qui montre un chronogramme du nombre d’instructions spécialisées chargées qui sont associées aux deux extensions matérielles considérées, HW1 et HW2 ; « t » désigne le temps d’exécution. Les pulsations PS sont indiquées par des traits verticaux, et découpent le temps d’exécution en « périodes applicatives » (ou simplement « périodes ») PRD. La qualité de service QoS est mesurée à chaque pulsation pour la période qui vient de s’écouler, et une marge MRG est calculée par rapport à un niveau de qualité minimal Qos_Min. Un niveau
de qualité maximal QoS_Max est également indiqué ; en effet, on ne souhaite généralement pas fournir un niveau de qualité inutilement élevé. 2. Un découpage de chaque période applicative de la tâche de calcul considéré en « portions »
La prédiction des exécutions futures des instructions spécialisées se base généralement sur un apprentissage de 1‘utilisation passée de l’extension. Dans la littérature, la période d’apprentissage est souvent constante, liée à des évènements de l’ordonnanceur. Pour augmenter et affiner les opportunités de gestion à l’intérieur d’une période, l’invention propose de suivre et prédire l’utilisation des instructions spécialisées sur des portions de la « période applicative » et s’adapter ainsi à des profils d’utilisation des instructions spécialisées changeants d’une période à une autre. Une « portion » est l’intervalle de temps minimum pour chaque décision de gestion de la méthode proposée.
Conformément à l’invention, chaque période est subdivisée en N « portions » de durées non constantes et ceci en fonction du nombre d’instructions spécialisées chargées associées à l’extension matérielle « HWm » dont le coût d’émulation sur cette période sera le plus pénalisant en termes de performance. Λ/est un nombre qui peut être arbitrairement fixé dès le début de l’exécution ou à la suite d’une phase d’étalonnage au début de l’exécution.
Pour définir quelle est l’extension matérielle « m » qui est la plus pénalisante en termes de performance, on effectue au démarrage de l’application, à la suite d’une phase d’étalonnage (une ou plusieurs pulsations), le calcul du coût d’émulation relatif Coût_relatif(m? n) à la fin de la période courante « n » et pour chaque extension matérielle « m »:
[2] où T (mn) représente le ratio d’utilisation de l’extension msur la période n (cf. équation [1]) . On choisit m qui donne le coût : Coût_relatif(m,n) = Maxm( Coût_re/atif(m,n))
La détermination de l’extension matérielle la plus pénalisante peut être faite hors ligne pour chaque application à exécuter sur la plateforme. Elle peut être calculée en ligne et mise à jour à chaque exécution d’une nouvelle application (donc avec une seule phase d’étalonnage au début de l’exécution de chaque application) ou au sein de la même application (dans le cas d’applications très dynamiques) après chaque « P » pulsations applicatives (on répète la phase d’étalonnage après chaque P pulsations, P étant un nombre constant et prédéfini avant l’exécution).
Le découpage d’une période applicative en portions utilise la connaissance, obtenue par le suivi décrit plus haut, du nombre global (toutes familles confondues) d’instructions spécialisées associées à l’extension matérielle « HWm» chargées à la fin de la période courante « n » : Nb(m, „)
Cette connaissance permet en effet de prédire le nombre global d’instructions spécialisées associées à l’extension matérielle « HWm» pour la période applicative suivante (Nb_Pred(m, n+i))· Cette prédiction peut, par exemple, être obtenue en calculant une moyenne mobile exponentielle (EMA), avec un facteur de lissage « a» (cr<1) adaptable selon la dynamicité de l’application. On a alors :
[3]
Pour cette extension matérielle m, une portion de la période courante s’achève lorsque le nombre prédit d’instructions spécialisées de l’extension matérielle « HWm » sur la période courante (Nb_Pred(m, nj), divisé par N, a été chargée.
Ce découpage des périodes applicatives en portions en fonction du nombre d’instructions spécialisées chargées permet d’estimer directement la QoS intermédiaire. Il permet aussi d’effectuer une prédiction de l’utilisation des instructions spécialisées sur la portion en question
indépendamment de l’allocation faite à la même portion de la période précédente (portion exécutée sur un cœur basique ou étendu).
La figure 5montre l’intérêt d’une décomposition des périodes PRD en N portions PTS (dans l’exemple, N = 3) en fonction du nombre d’instructions spécialisées chargées pour la prédiction en restant indépendante de l’allocation. Dans l’exemple considéré, la deuxième période applicative PRD2 a été exécutée sur un cœur basique et la troisième, PRD3, sur un cœur étendu (tout comme la première période PRD1). Si on se basait sur des portions de durée fixe, aucune relation simple ne pourrait être trouvée entre les données collectées à la période PRD2 pour prédire celle de la même portion à la période PRD3. Une découpe en périodes de durée fixe nécessite aussi d’une part plus d’interventions du contrôleur et d’autre part des interpolations assez coûteuses pour ramener les mesures collectées à des données exploitables pour la prédiction. Par contre, conformément à l’invention, les portions comprennent un nombre sensiblement égal d’instructions spécialisées, ce qui permet de mettre en relation des portions de même rang de périodes différentes.
Pour délimiter les portions des périodes, il est nécessaire de comptabiliser le nombre global d’instructions spécialisées chargées de l’extension « HWm ». Pour accélérer cette comptabilisation et la rendre la moins intrusive il peut être avantageux de prévoir un compteur matériel dédié qui s’incrémente à chaque chargement d’une instruction spécialisée de l’extension « HWm» et qui déclenche une interruption sur le cœur en question pour appeler une routine de suivi et de gestion système qui doit être enclenchée à chaque portion.
Dans un autre mode de réalisation, il est possible d’utiliser uncompteur de type alarme avec un quantum de temps fixe qui lève une interruption sur le cœur courant. La routine appelée par cette interruption consulte le compteur matériel du nombre d’instructions spécialisées de l’extension « HWm» et appelle la routine de gestion lorsque le nombre d’instructions spécialisées requis par portion est atteint. 3 Prédiction des exécutions futures des instructions spécialisées L’invention prévoit un suivi, pour chaque portion « k » de la période « n » : du nombre d’instructions spécialisées exécutées de chaque famille « /» identifiée dans la première étape de la méthode:
Nb(m: /, k, n) ; du nombre total d’instructions exécutées hors émulation pour les cœurs basiques et hors instructions spécialisées pour les cœurs étendus: Nb_basiC(k,n) ; du temps d’exécution effectif de la portion k de la période n : T(k,n) ; et du nombre d’instructions basiques liées à l’émulation de chaque extension « HWm» absente : Nb_emul(m!k,n).
Sauf en ce qui concerne le temps d’exécution, le suivi est réalisé au moyen des compteurs décrits plus haut en référence à la figure 3.
La méthode prévoit la prédiction, pour la même portion kde la période applicative suivant n+1 du : nombre d’instructions spécialisées de chaque famille « / » de l’extension « HWm » :
Nb_Pred(m: i, k, n+1) — 01- Nb(m, i, k, η) + ("I — 00 Nb_Pred(m, i, k, n) [4] nombre d’instructions exécutées hors émulation et hors instructions spécialisées de l’extension « HWm» :
Nb_Pred_basiC(k n+i) = a- Nb_basiC(k, n) + (1 - a) Nb_Pred_basiC(k, n) [5] nombre d’instructions basiques liées à l’émulation de chaque extension « HWm» absente:
Nb_Pred_emul(m,k,n+1 ) = a.Nb_emul(m,k,n) + (1-a) Nb_Pred_emul(m,k,n) [6]
Ces équations recoursives doivent être initialisées. Les valeurs d’initialisation peuvent par exemple être obtenue par étalonnage.
Estimation des coûts/gains en performance et en énergie des différentes opportunités de gestion
Une fois effectuée la prédiction de la future utilisation des extensions matérielles, il est possible d’estimer les coûts/gains en performance et en énergie de chacune des opportunités de gestions qui sont offertes sur la prochaine portion de la période courante. Ces opportunités sont par exemple:
Migration d’un cœur étendu (avec ses variantes Full, (base+HWf), (base+HIAQ)) (resp. basique) vers un cœur basique (resp. étendu). Cela comporte une sauvegarde du contexte d’exécution courant sur le cœur étendu (resp. basique), l’activation d’un cœur basique (resp. étendu) s’il n’y a pas de cœurs actifs et libres à ce moment-là, la migration du contexte vers ce nouveau cœur cible, la mise du cœur étendu (resp. basique) en mode non-fonctionnel basse consommation et la poursuite de l’exécution sur le cœur basique (resp. étendu).
Changement du couple tension fréquence (DVFS de l’anglais « Dynamic Voltage and Frequency Setting », c'est-à-dire ajustement dynamique de la tension et de la fréquence) sur le cœur courant : décision de poursuivre l’exécution sur le cœur courant mais avec un couple tension fréquence différent.
Toute combinaison des deux dernières opportunités (migration + DVFS) L’estimation faite des coûts/gains en performance et en énergie se fait sur la base d’une période entière. La méthode estime à cette étape la QoS et l’énergie consommée en fin de période en estimant des décisions au niveau des portions.
La QoS applicative est souvent ramenée à l’inverse d’un temps d’exécution sur la période applicative considérée. Ce temps peut être estimé en sommant les estimations des temps d’exécution sur les différentes portions de cette période. L’énergie consommée est la somme des contributions des cœurs, estimées selon l’allocation faite et selon le couple DVFS choisi sur chaque portion, puis ramenées sur la période entière.
Coût d’émulation / accélération:
Comparé à la même portion de la période précédente, le surcoût d’émulation en temps des instructions de l’extension matérielle « m » sur la portion «k», prédit pour la période n+1 et pour une fréquence d’exécution F1, est donné par :
[7] où Nb_Pred(m, i, k, n+1) est le nombre d’instructions spécialisées prédit sur la période n+1 de la famille / sur la portion k (voir équation [4]). CPI («Cycles per Instruction», c'est-à-dire «cycles par instruction»/ est le paramètre permettant de quantifier le coût moyen d’une instruction en termes de cycles processeur. En divisant ce nombre de cycles par la fréquence (ici F1) du processeur on obtient le temps moyen d’exécution d’une instruction.
Comparé à la même portion de la période précédente, le surcoût (ici négatif) d’une accélération des instructions de l’extension matérielle « m » en migrant vers un cœur avec cette extension est donné par :
[8]
Comparé à la même portion de la période précédente, le surcoût d’émulation en énergie des instructions de l’extension matérielle « m » sur la portion «k», prédit pour la période n+1 et pour une fréquence d’exécution F1, est donné par l’équation suivante pour les deux variantes:
Kemui_energîe surcoût dû à l’émulation et Kaccei_energie surcoût dû à l’accélération sur cœur avec extension « m » :
Où P1 et P2 représentent respectivement les puissances moyennes du cœur courant et celui de destination. P1 représente la puissance du cœur possédant l’extension « m » (respectivement dépourvu de l’extension « m ») et P2 est celle du cœur dépourvu de cette extension (respectivement possédant l’extension « m ») et vers lequel on estime le coût de migration dans le cas d’une émulation (respectivement dans le cas d’une accélération). Nb-total^n) est le nombre total d’instructions sur la période précédente « n » et sur la même portion « k ».
Coût de changement de tension/fréquence (DVFS) :
Comparé à la même portion de la période précédente, le surcoût en temps du changement de couple tension fréquence sur la portion « k » à allocation constante, prédit pour la période n+1 et pour un changement d’une fréquence d’exécution F1 vers F2 est donné par l’équation suivante :
[10]
Comparé à la même portion de la période précédente, le surcoût en énergie du changement de couple tension fréquence sur la portion « k » à allocation constante, prédit pour la période n+1 et pour un changement d’une fréquence d’exécution F1 vers F2, est donné par l’équation suivante :
[11]
Où P1 (respectivement P2) représente la puissance moyenne du cœur courant au point de fonctionnement DVFS donné par la fréquence F1 (respectivement F2).
Coût de changement simultané de couple tension/fréquence (DVFS) et d’allocation (émulation/accélération):
Comparé à la même portion de la période précédente, le surcoût en temps du changement de couple tension fréquence sur la portion « k » à allocation constante, prédit pour la période n+1 et pour un changement d’une fréquence d’exécution F1 vers F2 est donné par l’équation suivante avec les deux variantes : KDVFs_emui_tempS surcoût dû à l’émulation et au DVFS ; et KDVFs_accei_temPs surcoût dû à l’accélération sur cœur avec extension « m » et DVFS:
Kdvfs_ emul/accel_temps(m, k, n+1, F1_> F2) — l^emul/accel_temps(m, k, n+1, F2) + K DVFS tempsfm, k, n+1, F1 F2) [12]
Comparé à la même portion de la période précédente, le surcoût en énergie prédit pour la période n+1 du changement de couple tension fréquence sur la portion « k » et pour un changement d’une fréquence d’exécution F1 vers F2 avec migration, est donné par l’équation suivante avec les deux variantes : KDVFs_emui_energie surcoût dû à l’émulation et au DVFS ; et KDVFs_accei_energie surcoût dû à l’accélération sur cœur avec extension « m » et DVFS: P-DVFS_emul/accel_energie(m, k, n+1, F1 F2) = (^emul/accel_temps(m, k, n+1, F2) X P2) +
Kdvfs_ energiefm, k, n+1, F1 F2) [13] Où P1 représente la puissance moyenne du cœur courant au point de fonctionnement DVFS donné par la fréquence F1 et P2 représente la puissance moyenne du cœur destination au point de fonctionnement donné par la fréquence F2.
Prise de décision L’estimation du coût des différentes options de gestion sert à permettre une prise de décision garantissant une QoS minimale tout en minimisant l’énergie consommée.
La figure 6 donne un exemple de prise de décision à la granularité d’une portion pour maintenir une qualité de service au-dessus de la QoS minimale et minimiser l’énergie. Cette figure reprend la figure 4 en y ajoutant : la décomposition des périodes en portions ; l’indication du cœur de processeur utilisé dans chaque portion, et de la consommation énergétique correspondante.
Pour garantir cette condition et éviter des oscillations et des gestions superflues, on définit deux intervalles de prise de décision [QoS_Min, QoS_bas] et [QoS_Haut, QoS_Max] (représentés sur la figure 6) sur lesquels on décide de déclencher des actions de gestion et on garde le système tel quel si la QoS calculée rentre dans l’intervalle intermédiaire [QoS_bas, QoS_Haut].
Dans un mode de réalisation de l’invention, on cherche à déterminer la marge par rapport à la qualité de service QoS_bas (comme illustré par la figure 6) sur la dernière période exécutée et de distribuer cette marge sur les différentes portions de la période suivante de manière à ce que les décisions prises au niveau portion bénéficient de cette portion de marge pour choisir une opportunité de gestion (migration, changement de couple DVFS, une combinaison des deux) qui diminue l’énergie consommée sous contrainte de respect de cette portion de marge.
La marge de QoS est ramenée à une marge de temps « Pqos” positive lorsque la QoSn est supérieure à QoS_bas et négative dans le cas contraire (cas de la marge sur la troisième période de la figure 6) et sa distribution sur les N portions de la période peut se faire de manière égale comme elle peut être plus intelligemment choisie par exemple par rapport au ratio d’utilisation de l’extension « m » dont l’émulation est la plus pénalisante en temps (Tm voir équation [1]) calculé sur chaque portion « k » : T(m,k,n)· Une implémentation privilégierait par exemple la distribution de la marge aux portions de période avec les ratios d’utilisation les moins élevés car ils ont des opportunités d’émulation plus importantes.
Une seconde marge (positive ou négative aussi) peut être introduite par rapport à la prédiction de l’évolution du nombre d’instructions spécialisées dans le temps.
On calcule à la fin de chaque portion k de la période n la prédiction du temps d’exécution, à allocation constante, de la portion k à la période n+1 :
[14]
Cette estimation prend en compte l’émulation des extensions matérielles non supportées (émulées m) par le cœur utilisé à la portion kde la période n en sommant le coût de leur émulation et l’exécution des instructions prédites des extensions supportées (exécutées m’).
La seconde marge utilisable peut être calculée par l’équation suivante :
Ppred(k) = T_Pred (k n+1) ~ f (k, n) [15] où T(k,n) est le temps d’exécution effectif sur la portion k de la période précédente n:
La marge collectée par la portion kest : P (k) = PQoS(k) + Ppred(k) [16]
Avantageusement, cette méthode opère de manière incrémentale en partant de la mise en œuvre choisie à la même portion de la
période précédente et en estimant les surcoûts des opportunités de gestion. Le choix de l’opportunité de gestion la plus adéquate vis-à-vis de la marge « p(k) » allouée à la portion k se fait avantageusement en considérant un paramètre qui intègre conjointement la performance et l’énergie comme l’EDP (produit énergie - latence, de l’anglais « Energy Delay Product »).
Selon un mode de réalisation de l’invention, la différence des surcoûts (ramenée à une grandeur énergétique) est utilisée comme paramètre à maximiser pour guider le choix de l’opportunité de gestion. Pour une opportunité de gestion «opp», pour une portion «k», et une puissance moyenne Pi (puissance du cœur utilisé à la portion k de la période précédente), cette différence est donnée par la formule suivante :
Dopp(k) = (KOpp_temps(k) X Pi ) ~ KOpp_energje(k) [17]
Dans l’équation [17], Kopp_tempS(k) est le coût en temps d’une opportunité de gestion ; en fonction de l’opportunité retenue, il peut valoir par exemple Kemui_ temps; KaCcel_temps OU KDVFS_temps- Do mémo, Kopp_energie(k) SSt Ιθ coût en énergie d’une opportunité de gestion ; en fonction de l’opportunité retenue, il peut valoir par exemple k\emupenergie, ^-accel_energie OU KDVFS_energie-
La condition à satisfaire est donc que :
Kopp_temps(k) < fJ(k) et
Popp(k) = (UaXtoutes les opp(^opp(7ç)) [18]
Par exemple, sur la première portion de la troisième période de la figure 6 on voit que la décision a été prise de changer l’allocation précédente (première portion de la deuxième période) qui était sur un cœur basique avec une extension HW1 vers un cœur basique car la marge allouée à cette portion de période permettait de le faire avec une consommation d’énergie plus faible. Pour la troisième et dernière portion de la période 3, on peut noter que l’opportunité qui maximisait la différence de surcoût D sur cette portion était celle qui migrait vers un cœur basique et qui changeait en même temps la fréquence d’exécution sur ce cœur.
Un autre mode de réalisation possible de la phase de prise de décision se base sur le principe de privilégier l’allocation sur cœur basique sur les premières portions, tant que l’estimation de la QoS en fin de période reste au dessus de la qualité de service minimale, et accélérer ensuite l’exécution en migrant vers un cœur étendu dans les dernières portions. Cette méthode tend à retarder au maximum la migration sur un cœur étendu tout en garantissant une QoS minimale en fin de période privilégiant ainsi l’utilisation de cœurs basique moins performants mais peu gourmands en énergies.
Dans ce mode de réalisation, juste à la fin de la portion k-1 de la période courante, l’estimation de la QoS en fin de période considère une allocation de la portion k sur un cœur basique et une allocation des portions suivantes (k+1 à N) sur un cœur étendu.
Dans cette méthode, l’allocation à la première portion est estimée sur un cœur basique avec toutes les autres portions sur un cœur étendu et on vérifie si la QoS en fin de période reste supérieure à QoSmjn.
La prédiction du temps d’exécution sur cœur étendu de la portion k (T_Etendu_Pred(k)) correspond au calcul de T_Pred(k n+i) de l’équation [14] en considérant que toutes les extensions sont présentes. De manière similaire, la prédiction du temps d’exécution sur cœur basique de la portion k (T_Basic_Pred(k)) correspond au calcul de T_Pred(k, n+i) de l’équation [14] en considérant que toutes les extensions sont émulées.
La QoS prédite en fin de période en estimant que la portion k est allouée sur un cœur basique et que le reste des portions sont allouées sur un cœur étendu est calculée par l’équation suivante :
QoS_Predn+i = Σι<j <k n) + T_Base_Pred(k) + Zj<N-k T_Etendu_Pred(k+j) [19]
Si la condition QoS_Predn+i > QoSmin est satisfaite, on exécute l’allocation prédite. Sinon, on change de manière incrémentale la fréquence de l’allocation de la portion k, ensuite on considère un changement d’allocation à une basse fréquence et on augmente progressivement la fréquence et ainsi de suite.
La mise en œuvre duale, qui privilégie l’allocation de la portion ksur un cœur étendu en considérant que les autres portions suivantes (k+1 à N) vont être alloués sur un cœur basique est aussi une réalisation possible. Tant que la condition QoS_Predn+i > QoSmin n’est pas vérifiée, on décide de continuer à allouer sur le cœur étendu la portion suivante. Dès que cette condition est vérifiée, on prédit de manière incrémentale la QoS en fin de période en estimant, dans le même ordre que dans la méthode précédente, les opportunités de gestion possibles.
Un procédé selon l’invention est mis en œuvre grâce à un produit programme d’ordinateur comprenant des instructions exécutables par un processeur multi-cœurs fonctionnellement asymétrique (processeur PR de la figure 1), stockées sur un support non-volatil lisible par ledit processeur (par exemple une mémoire morte MM, illustrée sur la figure 1). Avantageusement, comme cela a été décrit en particulier en relation à la figure 3, le processeur multi-cœurs fonctionnellement asymétrique peut présenter des moyens matériels spécifiques : circuits de filtrage d’instructions et compteurs. Un tel processeur et une mémoire non volatile stockant le produit programme d’ordinateur peut avantageusement former, avec d’autres composants (mémoires vives, périphériques...), un système informatique, typiquement embarqué. L’invention a été décrite en relation à un mode de réalisation particulier, mais des variantes sont possibles. Par exemple, à titre non limitatif, d’autres formules de calcul des coûts peuvent être utilisées ; les prédictions peuvent ne pas être obtenues par moyenne glissante mais, par exemple, par filtrage de Kalman ; la répartition entre fonctionnalités mises en œuvre de manière logicielle ou matérielle peut varier.

Claims (15)

  1. REVENDICATIONS
    1. Procédé mis en œuvre par ordinateur pour la gestion d’une tâche de calcul sur un processeur multi-cœurs fonctionnellement asymétrique (PR), l’exécution de ladite tâche comprenant une succession de périodes applicatives, ledit processeur comprenant une pluralité de cœurs (PC1 - PC4) partageant des instructions dites basiques, au moins un dit cœur comprenant au moins une extension matérielle (HW1, HW2), ladite ou chaque extension matérielle étant adaptée pour permettre l’exécution d’instructions, dites spécialisées, différentes desdites instructions basiques, chaque instruction spécialisée étant ainsi associée à une dite extension matérielle, le procédé comprenant les étapes suivantes : a) démarrer l’exécution de la tâche de calcul sur un cœur dudit processeur ; b) effectuer, au cours de ladite exécution, un suivi d’un paramètre (QoS) indicatif d’une qualité de service de la tâche de calcul, ainsi que d’au moins un nombre d’instructions spécialisées chargées par ledit cœur; c) sur la base dudit suivi, identifier des instants découpant une période applicative de la tâche de calcul en un nombre prédéterminé de portions (PTS) de telle façon que, au cours de chacune desdites portions, un nombre sensiblement égal d’instructions spécialisées associées à une extension matérielle prédéfinie soient chargées par ledit cœur ; d) calculer, auxdits instants et en fonction dudit suivi, des coûts ou gains en qualité de service et en consommation énergétique correspondant à différentes options de gestion de la tâche de calcul ; et e) effectuer un choix de gestion comprenant une décision de poursuivre l’exécution sur le même cœur du processeur ou sur un cœur différent en fonction des coûts ou gains ainsi calculés.
  2. 2. Procédé selon la revendication 1 dans lequel ladite étape c) comprend la prévision du nombre d’instructions spécialisées associées à ladite extension matérielle chargées au cours de chaque portion d’une période applicative courante à partir du nombre de dites instructions spécialisées chargées lors de portions correspondantes d’au moins une période applicative précédente.
  3. 3. Procédé selon l’une des revendications précédentes dans lequel ladite extension matérielle prédéfinie est celle adaptée pour permettre l’exécution des instructions spécialisées dont l’émulation présenterait le coût en qualité de service le plus élevé.
  4. 4. Procédé selon l’une des revendications précédentes dans laquelle le choix de gestion effectué lors de l’étape e) comprend la décision de poursuivre l’exécution de la tâche de calcul sur le même cœur ou sur un cœur différent de manière à minimiser la consommation énergétique du processeur tout en respectant une contrainte de qualité de service.
  5. 5. Procédé selon la revendication 4 dans lequel ladite étape e) comprend : e1) déterminer une marge de qualité de service sur une période applicative précédente ; e2) distribuer cette marge entre les portions de la période courante ; et e3) pour chaque portion de la période courante, effectuer un dit choix de gestion permettant de diminuer la consommation énergétique sous contrainte de respect de la marge de qualité de service distribuée audit portion, lorsque cela est possible.
  6. 6. Procédé selon la revendication 4 dans lequel : lors de l’étape a), l’exécution de la tâche de calcul est démarrée sur un cœur ne comprenant pas d’extensions matérielle ; lors de ladite étape e), une décision de poursuive l’exécution de la tâche de calcul sur un autre processeur, comprenant au moins une exécution matérielle, est prise lorsque cela est nécessaire pour assurer le respect d’une contrainte de qualité de service.
  7. 7. Procédé selon l’une des revendications précédentes dans lequel ledit choix de gestion comprend également une décision de maintenir ou de changer un couple fréquence d’horloge - tension d’alimentation du cœur.
  8. 8. Procédé selon l’une des revendications précédentes dans lequel les instructions spécialisées associées à chaque extension matérielle sont regroupées en un nombre prédéfini de familles, ce nombre étant supérieur à 1 pour au moins une dite extension matérielle et au moins une dite famille comprenant plusieurs instructions ; et dans lequel, lors de l’étape d), les instructions d’une même famille sont considérées comme une seule et même instruction aux fins du calcul desdits coûts ou gains en qualité de service et en consommation énergétique.
  9. 9. Procédé selon la revendication 8 dans lequel le nombre de familles dans lequel les instructions spécialisées associées à chaque extension matérielle sont regroupées est choisi de manière à minimiser des erreurs affectant le calcul des coûts ou gains en qualité de service et en consommation énergétique effectué lors de l’étape d).
  10. 10. Procédé selon l’une des revendications 8 et 9 dans lequel l’étape b) comprend le suivi : du nombre d’instructions basiques; du nombre d’instructions spécialisées associées à chaque extension matérielle que ledit cœur ne comprend pas ; du nombre d’instructions spécialisées appartenant à chaque famille d’instructions spécialisées associées à chaque extension matérielle que ledit cœur comprend ; et du nombre d’instructions basiques utilisées pour l’émulation des instructions spécialisées associées à chaque extension matérielle que ledit cœur ne comprend pas ; chargées par ledit cœur.
  11. 11. Procédé selon l’une des revendications précédentes comportant une étape préalable de chargement en mémoire d’un ensemble de paramètres de caractérisation représentatifs d’une distribution statistique des coûts d’émulation en temps et énergie des instructions spécialisées, dans lequel l’étape d) est mise en œuvre utilisant lesdits paramètres de caractérisation.
  12. 12. Procédé selon la revendication 11 comportant également une étape préalable d’étalonnage pour déterminer lesdits paramètres d’étalonnage.
  13. 13. Produit programme d’ordinateur stocké sur un support (MM) non-volatil lisible par ordinateur comprenant des instructions exécutables par ordinateur pour la mise en œuvre d’un procédé selon l’une des revendications précédentes.
  14. 14. Processeur multi-cœurs (PR) fonctionnellement asymétrique comprenant une pluralité de cœurs (PC1 - PC4) partageant des instructions dites basiques, au moins un dit cœur comprenant au moins une extension matérielle (HW1, HW2), ladite ou chaque extension matérielle étant adaptée pour permettre l’exécution d’instructions, dites spécialisées, différentes desdites instructions basiques, chaque instruction spécialisée étant ainsi associée à une dite extension matérielle, caractérisé en ce qu’il comprend également : des circuits de filtrage, configurés pour trier les instructions basiques et les instructions spécialisées associées aux différentes extensions matérielles, et pour attribuer chaque instruction spécialisée à une famille ; et pour chaque cœur : un compteur (Nb_basic) d’instructions basiques chargées par le cœur ; pour chaque extension matérielle non comprise par ledit cœur, un compteur (Nb(HW1), Nb(HW2)) d’instructions spécialisées associées à ladite extension matérielle chargées par le cœur, ainsi qu’un compteur du nombre d’instructions basiques utilisées pour l’émulation des instructions spécialisées associées ; et pour chaque extension matérielle comprise par ledit cœur, et pour chaque famille d’instructions spécialisées associées à ladite extension matérielle, un compteur (Nb(HW1,i), Nb(HW2,i)) d’instructions spécialisées associées à ladite extension matérielle et appartenant à ladite famille chargées par le cœur.
  15. 15. Système informatique comprenant un processeur (PR) multi-cœurs fonctionnellement asymétrique selon la revendication 14 et une mémoire non-volatile (MM) stockant des instructions exécutables par ledit processeur pour la mise en œuvre d’un procédé selon l’une des revendications 1 à 11.
FR1659367A 2016-09-29 2016-09-29 Procede de gestion des taches de calcul sur un processeur multi-cœurs fonctionnellement asymetrique Active FR3056786B1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
FR1659367A FR3056786B1 (fr) 2016-09-29 2016-09-29 Procede de gestion des taches de calcul sur un processeur multi-cœurs fonctionnellement asymetrique
US16/333,974 US10846086B2 (en) 2016-09-29 2017-09-06 Method for managing computation tasks on a functionally asymmetric multi-core processor
EP17761281.9A EP3519954A1 (fr) 2016-09-29 2017-09-06 Procede de gestion des taches de calcul sur un processeur multi-coeurs fonctionnellement asymetrique
PCT/EP2017/072376 WO2018059897A1 (fr) 2016-09-29 2017-09-06 Procede de gestion des taches de calcul sur un processeur multi-cœurs fonctionnellement asymetrique

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1659367A FR3056786B1 (fr) 2016-09-29 2016-09-29 Procede de gestion des taches de calcul sur un processeur multi-cœurs fonctionnellement asymetrique
FR1659367 2016-09-29

Publications (2)

Publication Number Publication Date
FR3056786A1 FR3056786A1 (fr) 2018-03-30
FR3056786B1 true FR3056786B1 (fr) 2019-11-22

Family

ID=57906737

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1659367A Active FR3056786B1 (fr) 2016-09-29 2016-09-29 Procede de gestion des taches de calcul sur un processeur multi-cœurs fonctionnellement asymetrique

Country Status (4)

Country Link
US (1) US10846086B2 (fr)
EP (1) EP3519954A1 (fr)
FR (1) FR3056786B1 (fr)
WO (1) WO2018059897A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11544499B2 (en) 2018-09-18 2023-01-03 Microsoft Technology Licensing, Llc Classification of synthetic data tasks and orchestration of resource allocation
CN113452788B (zh) * 2021-06-29 2022-04-26 中国地质大学（北京） 一种动态网络中基于服务迁移的适配优化方法
US20230205592A1 (en) * 2021-12-23 2023-06-29 Intel Corporation Asymmetric tuning

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7246219B2 (en) * 2003-12-23 2007-07-17 Intel Corporation Methods and apparatus to control functional blocks within a processor
US8615647B2 (en) * 2008-02-29 2013-12-24 Intel Corporation Migrating execution of thread between cores of different instruction set architecture in multi-core processor and transitioning each core to respective on / off power state
US8892916B2 (en) * 2008-08-06 2014-11-18 International Business Machines Corporation Dynamic core pool management
US9268611B2 (en) * 2010-09-25 2016-02-23 Intel Corporation Application scheduling in heterogeneous multiprocessor computing platform based on a ratio of predicted performance of processor cores
KR102082859B1 (ko) * 2013-01-07 2020-02-28 삼성전자주식회사 복수의 이종 코어들을 포함하는 시스템 온 칩 및 그 동작 방법
US10423216B2 (en) * 2013-03-26 2019-09-24 Via Technologies, Inc. Asymmetric multi-core processor with native switching mechanism

Also Published As

Publication number Publication date
US20190250919A1 (en) 2019-08-15
WO2018059897A1 (fr) 2018-04-05
FR3056786A1 (fr) 2018-03-30
US10846086B2 (en) 2020-11-24
EP3519954A1 (fr) 2019-08-07

Similar Documents

Publication Publication Date Title
US10542079B2 (en) Automated profiling of resource usage
Al-Dhuraibi et al. Elasticity in cloud computing: state of the art and research challenges
US11150931B2 (en) Virtual workload migrations
RU2605473C2 (ru) Автоматизированное профилирование использования ресурса
US9135048B2 (en) Automated profiling of resource usage
Beloglazov et al. Managing overloaded hosts for dynamic consolidation of virtual machines in cloud data centers under quality of service constraints
FR3035243A1 (fr) Placement d&#39;une tache de calcul sur un processeur fonctionnellement asymetrique
US10257275B1 (en) Tuning software execution environments using Bayesian models
US8347307B2 (en) Method and system for cost avoidance in virtualized computing environments
EP2987081B1 (fr) Procédé d&#39;allocation temporelle de tâches permettant une récupération d&#39;erreur deterministe en temps réel
US9612751B2 (en) Provisioning advisor
FR3056786B1 (fr) Procede de gestion des taches de calcul sur un processeur multi-cœurs fonctionnellement asymetrique
Li et al. Amoeba: Qos-awareness and reduced resource usage of microservices with serverless computing
EP2447840B1 (fr) Gestion de calcul partiel dynamique et intelligent pour parallélisation efficace d&#39;analyse logicielle dans un environnement informatique distribué
Breitgand et al. An adaptive utilization accelerator for virtualized environments
Feliu et al. Symbiotic job scheduling on the IBM POWER8
EP3502895A1 (fr) Commande de la consommation énergétique d&#39;une grappe de serveurs
Rosinosky et al. An efficient approach for multi-tenant elastic business processes management in cloud computing environment
CA2874115A1 (fr) Procede de gestion d&#39;une execution de taches dans un systeme informatique
FR3012896A1 (fr) Procede de validation du temps de reponse d&#39;une application, procede de deploiement d&#39;une application comportant un tel procede de validation, programme d&#39;ordinateur et dispositifs correspondants
FR3027419A1 (fr) Procede de determination d&#39;une frequence optimale pour l&#39;execution d&#39;une application logicielle
US20220398189A1 (en) Resource allocation in microservice architectures
Grounds Feedback and Requirement Biasing for Enhancing Robustness of Scheduling Algorithms for Distributed System Processing

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20180330

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7