EP3803589A1 - Procédé de contrôle d'un système à plusieurs coeurs et dispositifs associés - Google Patents

Procédé de contrôle d'un système à plusieurs coeurs et dispositifs associés

Info

Publication number
EP3803589A1
EP3803589A1 EP19726450.0A EP19726450A EP3803589A1 EP 3803589 A1 EP3803589 A1 EP 3803589A1 EP 19726450 A EP19726450 A EP 19726450A EP 3803589 A1 EP3803589 A1 EP 3803589A1
Authority
EP
European Patent Office
Prior art keywords
execution
critical
common resource
resource
physical quantity
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.)
Pending
Application number
EP19726450.0A
Other languages
German (de)
English (en)
Inventor
Sylvain GIRBAL
Jimmy LE RHUN
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.)
Thales SA
Original Assignee
Thales SA
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 Thales SA filed Critical Thales SA
Publication of EP3803589A1 publication Critical patent/EP3803589A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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

Definitions

  • the present invention relates to a method of controlling a system comprising a computer having a plurality of cores.
  • the present invention also relates to a computer program product and a readable medium of associated information.
  • Real-time systems including civil avionics calculators, are subject to very stringent safety requirements. Indeed, in the case of an aircraft, a failure could have catastrophic consequences on the flight of the airliner and its many passengers. Specific norms and regulations thus impose particular techniques to ensure the temporal determinism of the execution of applications.
  • a fundamental characteristic of a real-time system is its response time, which must imperatively be less than a predetermined value.
  • the execution time of a sequence of software tasks should be deterministic and repeatable. For safety reasons, this execution time is considered in the worst case, that is to say when various undesirable events (internal and external to the system) occur.
  • isolation techniques are well controlled on single-core processors, including deactivating certain unfavorable features to determinism and / or taking time margins. These isolation techniques are also essential to the integrated modular avionics concept, which allows the development of mixed criticality systems where highly critical applications (such as avionics autopilot) will mix with less critical applications (such as embedded multimedia systems). in avionics).
  • the present description relates to a method for controlling a system comprising a computer comprising a plurality of cores and resources common to at least two cores, each core being capable of performing tasks, each task involving a plurality of treatments. and one or more accesses to at least one common resource during a predefined execution time period, each access inducing a variation of a physical quantity relative to the common resource, each task being critical or non-critical, the method comprising least one step of, for each common resource, determining the variation of the execution slowing rate in the execution of each critical task as a function of the value of the physical quantity relative to the common resource during the period of time of predefined execution, of, for each common resource, setting a maximum value during the period of e predefined time according to a predetermined execution slowdown rate and the determined variation, execution of all the tasks by the computer, the execution step comprising the measurement of the physical quantity for each resource and stopping the execution of non-critical tasks as soon as, for a resource, the measured value is greater than the maximum value set
  • control method comprises one or more of the following characteristics, taken in isolation or in any technically possible combination:
  • the method further comprises, for each common resource, a step of obtaining the total value of the physical quantity for each critical task executed during the predefined period of time.
  • the method includes, for each common resource, during the predefined period of time, a step of providing a maximum value corresponding to the value of the physical quantity possible for the common resource considered to guarantee a predefined maximum execution time for access to the common resource.
  • the execution step also comprises measuring the physical quantity for each critical task and stopping the execution of the non-critical tasks as soon as, for a resource, at least one of the two following conditions is fulfilled a first condition according to which the measured physical quantity is greater than the maximum value supplied, and a second condition according to which the sum of the measured physical quantity for each critical task executed is equal to the total value obtained.
  • the system is a real-time system.
  • the system is an embedded system, for example in an airplane, a satellite or a railway vehicle.
  • Common resources belong to the group consisting of memories, link buses, cache memories, input / output devices, access ports and on-chip networks.
  • the physical quantity is chosen from the group consisting of a number of accesses to the common resource, a power consumption, a temperature and a quantity of memory used.
  • the present description also relates to a computer program product comprising a readable information medium, on which is stored a computer program comprising program instructions, the computer program being loadable on a data processing unit. and adapted to carry out the implementation of a method according to any one of the preceding claims when the computer program is implemented on the data processing unit.
  • the present description also relates to a readable information medium on which is stored a computer program product.
  • FIG. 1 a schematic view of a computer enabling the implementation of a control method of a system:
  • FIG. 2 a schematic view of a multi-core computer forming part of a system
  • FIG. 3 is a flowchart of an exemplary implementation of an exemplary control method of a system
  • FIG. 4 a diagrammatic representation of one way of implementing a step of the control method of FIG. 3; - Figure 5, a schematic representation of one way to implement another step of the control method of Figure 3;
  • FIG. 6 a graph representing the evolution of the execution time of a task as a function of the solicitation of a resource
  • FIG. 7 a diagrammatic representation of one way of implementing another step of the control method of FIG. 3, and
  • FIG. 8 a schematic representation of a way of implementing the step shown diagrammatically in FIG. 7.
  • FIG. 1 A computer 10 and a computer program product 12 are shown in FIG. 1.
  • the interaction of the computer program product 12 with the computer 10 makes it possible to implement a control method of a system.
  • the computer 10 is an electronic calculator able to manipulate and / or transform data represented as electronic or physical quantities in computer registers and / or memories in other similar data corresponding to physical data in databases. memories, registers or other types of display, transmission or storage devices.
  • the computer 10 comprises a processor 14 comprising a data processing unit 16, memories 18 and an information carrier reader 20.
  • the computer 10 also includes input and output peripherals 22 and 24.
  • the computer program product 12 comprises a readable information medium.
  • a readable information medium is a support readable by the computer 10, usually by the reader 20.
  • the readable information medium is a medium adapted to store electronic instructions and capable of being coupled to a bus of a system computer.
  • the readable information medium is a diskette or floppy disk ("floppy disk"), an optical disk, a CD-ROM, a magneto-optical disk, a ROM memory, a RAM memory, an EPROM memory, an EEPROM memory, a magnetic card or an optical card.
  • On the readable information medium is stored a computer program including program instructions.
  • the computer program is loadable on the data processing unit 16 and is adapted to drive the implementation of the optimization process.
  • the system 30 is a real-time system, i.e. a system having tasks to be performed in a predetermined time interval to provide security.
  • the system 30 is an embedded system, in particular intended to be part of an airplane, a satellite or a railway vehicle.
  • the system 30 comprises a calculator 32 comprising a plurality of cores 34, resources 36 of a core 34 and common resources 38, 40, 42, 44 and 46 with at least two cores 34.
  • Each heart 34 is capable of performing tasks.
  • a task is a set of at least one operation.
  • Each task is critical or non-critical.
  • a task is critical as soon as the execution of this task impacts the security of the system 30. All other tasks are non-critical.
  • Each task involves a plurality of processing and one or more accesses to at least one common resource 38, 40, 42, 44 and 46 for a period of execution time.
  • the number of cores 34 is small, typically between 2 and 12.
  • the system 30 comprises four cores 34 and the resources 36 of a core 34 are a cache memory.
  • a cache or cache is, in computing, a memory that temporarily stores copies of data from a source, to reduce the time of a subsequent access (read) of a computer hardware (usually a processor) to these data.
  • the common resources 38, 40, 42, 44 and 46 belong to the group consisting of memories, link buses, cache memories, input / output devices, access ports and networks-on-a-chip.
  • the common resources 38, 40, 42, 44 and 46 are two cache memories 38 and 40, a link bus 42, a memory 44 and an input-output module 46.
  • the first cache memory 38 cooperates with the cache memory 36 specific to the first core 34 and with the cache memory 36 specific to the second core 34.
  • the first cache memory 38 is thus shared by the first core 34 and the second core 34.
  • the second cache memory 40 cooperates with the cache memory 36 specific to the third core 34 and with the cache memory 36 specific to the fourth heart 34.
  • the second cache memory 40 is thus shared by the third core 34 and the fourth core 34.
  • the link bus 42 connects the two cache memories 38 and 40 with the memory 44 and the input-output module 46 so that these common resources can communicate with each other.
  • the control method of the system 30 is to manage such interference.
  • control method is a method of regulating the aforementioned interferences.
  • the control method comprises a supply step S50, a calculation step S52 and an execution step S54.
  • the supply S50 and S52 calculation steps are implemented offline (that is to say without operating the computer) while the execution step S54 is implemented online (c '). that is, in operation of the calculator).
  • the separation between steps with and without operating the computer is shown in Figure 3 by a dashed line 56.
  • the provisioning step S50 is implemented for each common resource.
  • the maximum possible number of accesses for the common resource considered is provided to guarantee a predefined maximum execution time for access to the common resource.
  • the provisioning step S50 takes into account the structure of the calculator (indicated by the rectangle 60), a mechanism for measuring the execution time and the number of accesses. to the common resource (indicated by the rectangle 62) and a requestor of said common resource (indicated by the rectangle 64) to obtain at the output the maximum possible number of accesses for the common resource (indicated by the rectangle 66).
  • the solicitor of the common resource also called the "stressing benchmark" allows to multiply the access to the common resource.
  • the petitioner allows a gradual increase in access to the common resource.
  • the increase of the execution time of an operation by the common resource is followed so that the maximum possible number of accesses for the common resource considered is obtained to guarantee a time of predefined maximum execution for access to the common resource.
  • the set of maximum possible access numbers are known for each common resource.
  • the calculation step S52 is implemented for each common resource.
  • the calculation step S52 takes into account four inputs to obtain two outputs.
  • the four inputs are the calculator structure (indicated by the rectangle 60), a mechanism for measuring the execution time and the number of accesses to the common resource (indicated by the rectangle 62), a solicitor of the said common resource ( indicated by rectangle 64) and critical tasks (indicated by rectangle 68).
  • the two outputs are the maximum number of possible accesses to the common resource for critical tasks (see rectangle 70 in Figure 5) and the maximum number of possible accesses to the common resource for non-critical tasks (see rectangle 72 in Figure 5).
  • the calculation step S52 comprises a determination step, a fixing step and a obtaining step.
  • the variation of the execution slowdown rate in the execution of each critical task is determined according to the number of accesses to the common resource during the predefined execution time period.
  • a maximum access number is set during the predefined period of time as a function of a predetermined execution slowdown rate and the variation of the number of accesses to the determined common resource.
  • the total number of accesses to the common resource for each critical task executed during the predefined period of time is obtained.
  • the total number of accesses to the common resource for each non-critical task is subtracted by subtracting the maximum possible access number for the common resource from the total number of accesses to the common resource for each critical task.
  • the operation of the determination, fixing and obtaining steps appears more precisely by studying the graph of FIG. 6.
  • the ordinate axis represents in the current time window, the worst execution time of the critical task which is followed. while the x-axis represents the solicitation (that is, the access in this context) to the material resource considered. Solicitation is induced by the solicitor.
  • the ordinate at the origin corresponds to the worst execution time of the critical task considered, assuming that the critical task is the only one to be executed. As expected, the more access to the material resource considered increases and the worse the execution time of the critical task increases to become so great that it corresponds to an impossibility for the critical task to be realized.
  • the variation of the execution slowdown rate in the execution of each critical task as a function of the number of accesses to the common resource during the predefined execution time period is therefore the value derived from the curve represented in FIG. .
  • the point 78 corresponding to the maximum slope comprises an abscissa 80 and an ordinate 82.
  • Said ordinate 82 corresponds to the level acceptable slowing down of tasks while said abscissa 80 corresponds to the budget in terms of available access for non-critical tasks while ensuring an acceptable slowdown rate.
  • the execution step S54 comprises measuring the number of accesses to the common resource for each resource and for each non-critical task.
  • the execution step S54 includes stopping the execution of the non-critical tasks as soon as, for a resource, the number of accesses measured is greater than the maximum number of accesses fixed for all non-critical tasks. criticism.
  • the calculator 32 ensures in real time that the non-critical tasks do not consume beyond the budgets allocated to them, temporarily suspending as needed the least critical applications.
  • the control method relaxes the principle of temporal partitioning between tasks of different criticalities, allowing less critical tasks to be interrupted in case of endangering critical tasks. This allows a better exploitation of parallelism by allowing non-critical tasks to run at the same time as critical tasks.
  • the control method makes it possible to better control the system 30 while avoiding the occurrence of temporal interference.
  • the control process relies on budget-based regulation that will monitor the use of shared resources by non-critical tasks according to the needs of the critical task, and temporarily interrupt non-critical tasks to ensure the quality level. service required for critical tasks.
  • the control method is thus a hardware-based budgeting solution for real-time systems with mixed criticality, that is to say involving the execution of critical and non-critical tasks.
  • control method therefore allows a better exploitation of the resources of the multi-core computer, and therefore a better performance for the critical hybrid critical integrated systems.
  • control method is simple, just counting accesses, which is important from the point of view of the certification of the process. This makes it possible to execute tasks in parallel without having to rewrite or modify them and therefore without having to recertify them.
  • the development process established for single-core processors can therefore be reused directly, avoiding the significant additional cost associated with the certification process.
  • the execution step S54 takes into account the critical tasks (see indicated rectangle 68) and the maximum possible number of accesses for the common resource (indicated by the rectangle 66) instead of the non-essential tasks. -critical (see rectangle 84) as in Figure 8.
  • the execution step S54 takes into account the maximum number of possible access to the common resource for critical tasks (see rectangle 70) instead of the maximum number of possible accesses to the common resource for non-critical tasks (see rectangle 72).
  • the execution step S54 also comprises measuring the number of accesses to the resource for each critical task and stopping the execution of the non-critical tasks as soon as, for a resource a first condition or a second condition is fulfilled.
  • the first condition is met if the number of accesses to the measured resource is greater than the maximum number of accesses to the resource provided.
  • the second condition is fulfilled if the number of accesses to the measured resource for each critical task executed is equal to the total access number obtained.
  • Such an embodiment makes it possible to carry out a self-diagnosis aimed at monitoring in real time the load of critical tasks in terms of access to each resource, and thus to ensure that the load of the system remains below the levels imposed by the authorities of regulation or customers.
  • the method described here which determines budgets in terms of number of accesses to resources, can also be extended to other types of budgets.
  • the control method is applied for the energy consumption of the common resource.
  • the control method is applied for the temperature of the common resource.
  • control method is applied for a quantity of memory used.
  • control method is applied for a physical quantity relative to the common resource.

Landscapes

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

Abstract

La présente invention concerne un procédé de contrôle d'un système comprenant un calculateur comportant une pluralité de cœurs et des ressources communes, chaque cœur exécutant des tâches critiques ou non-critiques impliquant une pluralité de traitements et d'accès à une ressource commune pendant une période de temps, chaque accès induisant une variation d'une grandeur physique relative à la ressource commune, le procédé comportant une étape de : - détermination de la variation du taux de ralentissement dans l'exécution de chaque tâche critique en fonction de la valeur de la grandeur physique pendant la période de temps, - fixation d'une valeur maximale en fonction d'un taux de ralentissement et de la variation déterminée, - arrêt de l'exécution des tâches non-critiques dès que, pour une ressource, la valeur mesurée est supérieure à la valeur maximale fixée.

Description

Procédé de contrôle d’un système à plusieurs cœurs et dispositifs associés
La présente invention concerne un procédé de contrôle d’un système comprenant un calculateur comportant une pluralité de cœurs. La présente invention se rapporte également à un produit programme d’ordinateur et un support lisible d’informations associés.
Les systèmes temps réel, notamment les calculateurs avioniques civils, sont soumis à des exigences de sûreté très contraignantes. En effet, dans le cas d’un avion, une défaillance pourrait avoir des conséquences catastrophiques sur le vol de l’avion de ligne et ses nombreux passagers. Des normes et régulations spécifiques imposent ainsi des techniques particulières pour assurer le déterminisme temporel de l’exécution des applications.
Une caractéristique fondamentale d’un système temps réel est son temps de réponse, qui doit impérativement être inférieur à une valeur prédéterminée. Il convient que le temps d’exécution d’une séquence de tâches logicielles soit déterministe et répétable. Pour des raisons de sûreté, il est considéré ce temps d’exécution dans le pire cas, c’est- à-dire quand divers événements indésirables (internes et externes au système) surviennent.
Pour cela, il est connu que minimiser ces effets indésirables consiste à garantir une isolation stricte, dans le temps et dans l’espace mémoire, entre les sous-ensembles fonctionnels du calculateur (typiquement entre applications). Il est alors utilisé des techniques de partitionnement, dans l’espace mémoire à l’aide de virtualisation d’adresses et dans le temps grâce à un ordonnancement statique des partitions.
De telles techniques d’isolation sont bien maîtrisées sur les processeurs mono cœur, y compris en désactivant certaines fonctionnalités défavorables au déterminisme et/ou en prenant des marges temporelles. Ces techniques d’isolation sont également indispensables au concept d’avionique modulaire intégrée qui permet de développer des systèmes à criticité mixtes où des applications fortement critiques (tel que le pilotage automatique en avionique) vont côtoyer des applications moins critiques (comme les systèmes multimédia embarqués en avionique).
Pour que ces systèmes (comportant des applications avec différents niveaux de criticité) exploitent avec un niveau de performance acceptable les systèmes multi-cœurs, il convient d’exploiter tous les niveaux de parallélisme disponibles dans le calculateur sous-jacent.
Or, le partitionnement robuste introduit par la technique d’isolation précitée limite cet aspect parallèle en séquençant les applications pour linéariser les accès aux ressources logicielles et matérielles partagées. Ce faisant, il est utilisé des fenêtres temporelles découpant le temps d’exécution en intervalles où une seule fonction peut s’exécuter. Si une telle pratique s’adapte parfaitement aux calculateurs mono-cœurs, elle dégrade fortement les performances des calculateurs multi-cœurs.
Il existe donc un besoin pour un procédé de contrôle d’un système compatible avec les exigences d’un emploi en temps réel pour la mise en œuvre d’applications critiques et non critiques qui puisse exploiter les performances des calculateurs multi- cœurs.
Pour cela, la présente description porte sur un procédé de contrôle d’un système comprenant un calculateur comportant une pluralité de cœurs et des ressources communes à au moins deux cœurs, chaque cœur étant propre à exécuter des tâches, chaque tâche impliquant une pluralité de traitements et un ou plusieurs accès à au moins une ressource commune pendant une période de temps d’exécution prédéfinie, chaque accès induisant une variation d’une grandeur physique relative à la ressource commune, chaque tâche étant critique ou non-critique, le procédé comportant au moins une étape de, pour chaque ressource commune, détermination de la variation du taux de ralentissement d’exécution dans l’exécution de chaque tâche critique en fonction de la valeur de la grandeur physique relative à la ressource commune pendant la période de temps d’exécution prédéfinie, de, pour chaque ressource commune, fixation d’une valeur maximale pendant la période de temps prédéfinie en fonction d’un taux de ralentissement d’exécution prédéterminé et de la variation déterminée, d’exécution de l’ensemble des tâches par le calculateur, l’étape d’exécution comportant la mesure de la grandeur physique pour chaque ressource et l’arrêt de l’exécution des tâches non-critiques dès que, pour une ressource, la valeur mesurée est supérieure à la valeur maximale fixée.
Suivant des modes de réalisation particuliers, le procédé de contrôle comprend une ou plusieurs des caractéristiques suivantes, prise(s) isolément ou suivant toutes les combinaisons techniquement possibles :
- le procédé comporte, en outre, pour chaque ressource commune, une étape d’obtention de la valeur totale de la grandeur physique pour chaque tâche critique exécutée pendant la période de temps prédéfinie.
- le procédé comporte, pour chaque ressource commune, pendant la période de temps prédéfinie, une étape de fourniture d’un valeur maximale correspondant à la valeur de la grandeur physique possible pour la ressource commune considérée pour garantir un temps d’exécution maximal prédéfini pour un accès à la ressource commune. - l’étape d’exécution comporte aussi la mesure de la grandeur physique pour chaque tâche critique et l’arrêt de l’exécution des tâches non-critiques dès que, pour une ressource, l’une au moins des deux conditions suivantes est remplie : une première condition selon laquelle la grandeur physique mesurée est supérieure à la valeur maximale fournie, et une deuxième condition selon laquelle la somme de la grandeur physique mesurée pour chaque tâche critique exécutée est égale à la valeur totale obtenue.
- le système est un système temps réel.
- le système est un système embarqué, par exemple dans un avion, un satellite ou un véhicule ferroviaire.
- les ressources communes appartiennent au groupe constitué des mémoires, des bus de liaison, des antémémoires, des périphériques entrée/sortie, des ports d’accès et des réseaux sur puce.
- la grandeur physique est choisie dans le groupe constitué d’un nombre d’accès à la ressource commune, d’une consommation d’énergie, d’une température et d’une quantité de mémoire utilisée.
La présente description se rapporte également à un produit programme d’ordinateur comportant un support lisible d’informations, sur lequel est mémorisé un programme d’ordinateur comprenant des instructions de programme, le programme d’ordinateur étant chargeable sur une unité de traitement de données et adapté pour entraîner la mise en oeuvre d’un procédé selon l’une quelconque des revendications précédentes lorsque le programme d’ordinateur est mis en oeuvre sur l’unité de traitement des données.
La présente description concerne aussi un support lisible d’informations sur lequel est mémorisé un produit programme d’ordinateur.
D’autres caractéristiques et avantages de l’invention apparaîtront à la lecture de la description qui suit de modes de réalisation de l’invention, donnés à titre d’exemple uniquement et en référence aux dessins qui sont :
- figure 1 , une vue schématique d’un ordinateur permettant la mise en oeuvre d’un procédé de contrôle d’un système :
- figure 2, une vue schématique d’un calculateur multi-cœur faisant partie d’un système ;
- figure 3, un ordinogramme d’un exemple de mise en oeuvre d’un exemple de procédé de contrôle d’un système ;
- figure 4, une représentation schématique d’une manière de mettre en oeuvre une étape du procédé de contrôle de la figure 3 ; - figure 5, une représentation schématique d’une manière de mettre en œuvre une autre étape du procédé de contrôle de la figure 3 ;
- figure 6, un graphe représentant l’évolution du temps d’exécution d’une tâche en fonction de la sollicitation d’une ressource ;
- figure 7, une représentation schématique d’une manière de mettre en œuvre une autre étape du procédé de contrôle de la figure 3, et
- figure 8, une représentation schématique d’une manière de mettre en œuvre l’étape schématisée à la figure 7.
Un ordinateur 10 et un produit programme d’ordinateur 12 sont représentés à la figure 1. L’interaction du produit programme d’ordinateur 12 avec l’ordinateur 10 permet de mettre en œuvre un procédé de contrôle d’un système.
Plus généralement, l’ordinateur 10 est un calculateur électronique propre à manipuler et/ou transformer des données représentées comme des quantités électroniques ou physiques dans des registres du calculateur et/ou des mémoires en d’autres données similaires correspondant à des données physiques dans des mémoires, des registres ou d’autres types de dispositifs d’affichage, de transmission ou de mémorisation.
L’ordinateur 10 comporte un processeur 14 comprenant une unité de traitement de données 16, des mémoires 18 et un lecteur 20 de support d’informations. L’ordinateur 10 comprend également des périphériques d’entrée 22 et de sortie 24.
Le produit programme d’ordinateur 12 comporte un support lisible d’informations. Un support lisible d’informations est un support lisible par l’ordinateur 10, usuellement par le lecteur 20. Le support lisible d’informations est un médium adapté à mémoriser des instructions électroniques et capable d’être couplé à un bus d’un système informatique.
A titre d’exemple, le support lisible d’informations est une disquette ou disque souple (de la dénomination anglaise de « floppy disk »), un disque optique, un CD-ROM, un disque magnéto-optique, une mémoire ROM, une mémoire RAM, une mémoire EPROM, une mémoire EEPROM, une carte magnétique ou une carte optique.
Sur le support lisible d’informations est mémorisé un programme d’ordinateur comprenant des instructions de programme.
Le programme d’ordinateur est chargeable sur l’unité de traitement de données 16 et est adapté pour entraîner la mise en œuvre du procédé d’optimisation.
Le fonctionnement de l’ordinateur 10 en interaction avec le produit programme d’ordinateur 12 est maintenant décrit en référence à un exemple de mise en œuvre d’un procédé de contrôle d’un système 30. Le système 30 est décrit en référence à la figure 2.
Le système 30 est un système temps réel, c’est-à-dire un système ayant des tâches à accomplir dans un intervalle de temps prédéterminé pour assurer la sécurité.
Par exemple, le système 30 est un système embarqué, notamment destiné à faire partie d’un avion, d’un satellite ou d’un véhicule ferroviaire.
Le système 30 comprend un calculateur 32 comportant une pluralité de coeurs 34, des ressources propres 36 à un cœur 34 et des ressources communes 38, 40, 42, 44 et 46 à au moins deux cœurs 34.
Chaque cœur 34 est propre à exécuter des tâches.
Par définition, une tâche est un ensemble d’au moins une opération.
Chaque tâche est critique ou non-critique.
Une tâche est critique dès que l’exécution de cette tâche impacte la sécurité du système 30. Toutes les autres tâches sont non-critiques.
Chaque tâche implique une pluralité de traitements et un ou plusieurs accès à au moins une ressource commune 38, 40, 42, 44 et 46 pendant une période de temps d’exécution.
Le nombre de tâches est très grand.
Par contraste, le nombre de cœurs 34 est restreint, typiquement entre 2 et 12.
Dans l’exemple décrit, le système 30 comporte quatre cœurs 34 et les ressources propres 36 à un cœur 34 sont une mémoire cache.
Une mémoire cache ou antémémoire est, en informatique, une mémoire qui enregistre temporairement des copies de données provenant d'une source, pour diminuer le temps d'un accès ultérieur (en lecture) d'un matériel informatique (en général, un processeur) à ces données.
De manière générale, les ressources communes 38, 40, 42, 44 et 46 appartiennent au groupe constitué des mémoires, des bus de liaison, des antémémoires, des périphériques entrée/sortie, des ports d’accès et des réseaux sur puce.
Dans le cas de la figure 2, les ressources communes 38, 40, 42, 44 et 46 sont deux mémoires caches 38 et 40, un bus de liaison 42, une mémoire 44 et un module d’entrée-sortie 46.
La première mémoire cache 38 coopère avec la mémoire cache 36 spécifique au premier cœur 34 et avec la mémoire cache 36 spécifique au deuxième cœur 34. La première mémoire cache 38 est ainsi partagée par le premier cœur 34 et le deuxième cœur 34.
Similairement, la deuxième mémoire cache 40 coopère avec la mémoire cache 36 spécifique au troisième cœur 34 et avec la mémoire cache 36 spécifique au quatrième cœur 34. La deuxième mémoire cache 40 est ainsi partagée par le troisième cœur 34 et le quatrième cœur 34.
Le bus de liaison 42 permet de connecter les deux mémoires cache 38 et 40 avec la mémoire 44 et le module d’entrée-sortie 46 pour que ces ressources communes puissent communiquer entre elles.
En fonctionnement du calculateur 32, il existe des cas impliquant des requêtes simultanées par plusieurs cœurs 34 sur une même ressource partagée ou commune 38, 40, 42, 44 et 46. Sur la figure 2, de tels phénomènes sont montrés par des collisions 48 entre trajets. Dans de tels cas aussi appelés « interférences temporelles », un arbitrage est réalisé au niveau matériel pour accorder l’accès à une requête et bloquer les autres jusqu’à la fin de la transaction. Cela implique une variabilité du temps d’exécution des tâches.
Le procédé de contrôle du système 30 vise à gérer de telles interférences.
En d’autres termes, le procédé de contrôle est un procédé de régulations des interférences précitées.
Dans l’exemple proposé à la figure 3, le procédé de contrôle comporte une étape de fourniture S50, une étape de calcul S52 et une étape d’exécution S54. Par exemple, les étapes de fourniture S50 et de calcul S52 sont mises en œuvre hors ligne (c’est-à-dire sans faire fonctionner le calculateur) alors que l’étape d’exécution S54 est mise en œuvre en ligne (c’est-à-dire en fonctionnement du calculateur). La séparation entre étapes avec et sans fonctionnement du calculateur est matérialisé sur la figure 3 par un trait 56 en pointillés.
L’étape de fourniture S50 est mise en œuvre pour chaque ressource commune.
Lors de l’étape de fourniture S50, il est fourni le nombre d’accès maximal possible pour la ressource commune considérée pour garantir un temps d’exécution maximal prédéfini pour un accès à la ressource commune.
Comme visible sur la figure 4, pour une ressource commune, l’étape de fourniture S50 prend en compte en entrée la structure du calculateur (indiquée par le rectangle 60), un mécanisme de mesure du temps d’exécution et du nombre d’accès à la ressource commune (indiqué par le rectangle 62) et un solliciteur de ladite ressource commune (indiqué par le rectangle 64) pour obtenir en sortie le nombre d’accès maximal possible pour la ressource commune (indiqué par le rectangle 66).
Le solliciteur de la ressource commune aussi appelé sous le terme anglais de « stressing benchmark » permet de multiplier les accès à la ressource commune. Plus précisément, le solliciteur permet une augmentation progressive des accès à la ressource commune. En parallèle, l’augmentation du temps d’exécution d’une opération par la ressource commune (voir rectangle 52) est suivie de sorte qu’il est obtenu le nombre d’accès maximal possible pour la ressource commune considérée pour garantir un temps d’exécution maximal prédéfini pour un accès à la ressource commune.
A l’issue de l’étape de fourniture S50, l’ensemble des nombres d’accès maximaux possibles sont connus pour chaque ressource commune.
L’étape de calcul S52 est mise en oeuvre pour chaque ressource commune.
Comme visible sur la figure 5, pour une ressource commune, l’étape de calcul S52 prend en compte quatre entrées pour obtenir deux sorties.
Les quatre entrées sont la structure du calculateur (indiquée par le rectangle 60), un mécanisme de mesure du temps d’exécution et du nombre d’accès à la ressource commune (indiqué par le rectangle 62), un solliciteur de ladite ressource commune (indiqué par le rectangle 64) et les tâches critiques (indiquées par le rectangle 68).
Les deux sorties sont le nombre d’accès maximal possible à la ressource commune pour les tâches critiques (voir rectangle 70 sur la figure 5) et le nombre d’accès maximal possible à la ressource commune pour les tâches non-critiques (voir rectangle 72 sur la figure 5).
Un exemple de mise en oeuvre de l’étape de calcul S52 est maintenant décrit.
L’étape de calcul S52 comporte une étape de détermination, une étape de fixation et une étape d’obtention.
Lors de l’étape de détermination S52, il est déterminé la variation du taux de ralentissement d’exécution dans l’exécution de chaque tâche critique en fonction du nombre d’accès à la ressource commune pendant la période de temps d’exécution prédéfinie.
Lors de l’étape de fixation, il est fixé un nombre d’accès maximal pendant la période de temps prédéfinie en fonction d’un taux de ralentissement d’exécution prédéterminé et de la variation du nombre d’accès à la ressource commune déterminée.
Lors de l’étape d’obtention, il est obtenu le nombre total d’accès à la ressource commune pour chaque tâche critique exécutée pendant la période de temps prédéfinie. Le nombre total d’accès à la ressource commune pour chaque tâche non-critique se déduit par soustraction au nombre d’accès maximal possible pour la ressource commune du nombre total d’accès à la ressource commune pour chaque tâche critique.
Le fonctionnement des étapes de détermination, de fixation et d’obtention apparaît plus précisément en étudiant le graphe de la figure 6. L’axe des ordonnées représente dans la fenêtre temporelle courante, le pire temps d’exécution de la tâche critique qui est suivie tandis que l’axe des abscisses représente la sollicitation (c’est-à-dire l’accès dans ce contexte) à la ressource matérielle considérée. La sollicitation est induite par le solliciteur.
L’ordonnée à l’origine (matérialisé par un signe de référence 74) correspond au pire temps d’exécution de la tâche critique considérée en supposant que la tâche critique soit la seule à être exécutée. Comme attendu, plus l’accès à la ressource matérielle considérée augmente et plus le pire temps d’exécution de la tâche critique augmente jusqu’à devenir tellement grand que cela correspond à une impossibilité pour la tâche critique de se réaliser.
La variation du taux de ralentissement d’exécution dans l’exécution de chaque tâche critique en fonction du nombre d’accès à la ressource commune pendant la période de temps d’exécution prédéfinie est donc la valeur dérivée de la courbe représentée sur la figure 6.
En utilisant la courbe représentée sur la figure 6 et compte-tenu de la structure du calculateur et des tâches critiques considérées, les experts savent définir une pente maximale au-delà de laquelle le ralentissement devient trop rapidement asymptotique. Pour le cas de la figure 6, la pente maximale, c’est-à-dire le taux de ralentissement d’exécution maximal, est montrée par le signe de référence 76.
Le point 78 correspondant à la pente maximale (c’est-à-dire le point en lequel la tangente à la courbe représentée sur la figure 6 présente la pente maximale) comporte une abscisse 80 et une ordonnée 82. Ladite ordonnée 82 correspond au niveau de ralentissement acceptable des tâches alors que ladite abscisse 80 correspond au budget en termes d’accès disponible pour les tâches non-critiques tout en garantissant un taux de ralentissement acceptable.
En répétant l’étape de calcul S52 pour chaque ressource commune, il est obtenu pour chacune un nombre maximal d’accès possible pour chaque type de tâches.
Lors de l’étape d’exécution S54, l’ensemble des tâches est mis en œuvre par le calculateur.
L’étape d’exécution S54 comporte la mesure du nombre d’accès à la ressource commune pour chaque ressource et pour chaque tâche non-critique.
L’étape d’exécution S54 comporte l’arrêt de l’exécution des tâches non-critiques dès que, pour une ressource, le nombre d’accès mesuré est supérieur au nombre d’accès maximal fixé pour l’ensemble des tâches non-critiques.
Cette manière de mettre en œuvre l’étape d’exécution S54 est illustrée schématiquement par la figure 7, le signe de référence 84 désignant les tâches non- critiques. Autrement formulé, le calculateur 32 s’assure en temps réel que les tâches non- critiques ne consomment pas au-delà des budgets qui leur sont alloués, suspendant temporairement au besoin les applications les moins critiques.
Le procédé de contrôle relâche le principe de partitionnement temporel entre des tâches de criticités différentes, autorisant les tâches moins critiques à être interrompues en cas de mise en danger des tâches critiques. Cela permet une meilleure exploitation du parallélisme en autorisant les tâches non-critiques à s’exécuter en même temps que les tâches critiques.
Le procédé de contrôle permet de mieux contrôler le système 30 en évitant l’occurrence d’interférences temporelles.
Le procédé de contrôle repose sur une régulation basée sur des budgets qui va surveiller l’utilisation des ressources partagées par les tâches non-critiques en fonction des besoins de la tâche critique, et temporairement interrompre les tâches non-critiques pour assurer le niveau de qualité de service nécessaire aux tâches critiques.
Le procédé de contrôle est ainsi une solution de régulation à base de budgétisation des ressources matérielles pour des systèmes temps réel à criticité mixte, c’est-à-dire impliquant l’exécution de tâches critiques et non-critiques.
Le procédé de contrôle permet donc une meilleure exploitation des ressources du calculateur à multi-coeurs, et donc une meilleure performance pour les systèmes embarqués critiques à criticité mixte.
De plus, il est à noter que la mise en œuvre du procédé de contrôle est simple, se contentant de compter les accès, ce qui est important du point de vue de la certification du procédé. Cela permet de faire exécuter des tâches en parallèle sans avoir à les réécrire ni les modifier et donc sans avoir à les recertifier. Le processus de développement établi pour les processeurs mono-cœurs peut donc directement être réutilisé en évitant le surcoût important lié au processus de certification.
En outre, il convient de mettre en avant que le taux de ralentissement maximum qui est considéré comme acceptable est distinct de la notion de ralentissement du pire- cas. Avec la notion précédente, il est utilisé un stress d’amplitude maximale et pas un stress d’amplitude variable.
Selon un autre mode de réalisation, l’étape d’exécution S54 prend en compte les tâches critiques (voir rectangle indiqué 68) et le nombre d’accès maximal possible pour la ressource commune (indiqué par le rectangle 66) au lieu des tâches non-critiques (voir rectangle 84) comme dans la figure 8. En outre, l’étape d’exécution S54 prend en compte le nombre d’accès maximal possible à la ressource commune pour les tâches critiques (voir rectangle 70) au lieu du nombre d’accès maximal possible à la ressource commune pour les tâches non-critiques (voir rectangle 72).
Dans un tel mode de réalisation, l’étape d’exécution S54 comporte aussi la mesure du nombre d’accès à la ressource pour chaque tâche critique et l’arrêt de l’exécution des tâches non-critiques dès que, pour une ressource une première condition ou une deuxième condition est remplie.
La première condition est remplie si le nombre d’accès à la ressource mesuré est supérieur au nombre d’accès maximal à la ressource fournie.
La deuxième condition est remplie si le nombre d’accès à la ressource mesuré pour chaque tâche critique exécutée est égal au nombre d’accès total obtenu.
Un tel mode de réalisation permet de réaliser un autodiagnostic visant à surveiller en temps réel la charge des tâches critiques en termes d’accès à chaque ressource, et de s’assurer ainsi que la charge du système reste sous les niveaux imposés par les autorités de régulation ou les clients.
Le procédé décrit ici, qui détermine des budgets en termes de nombre d’accès aux ressources, peut également être étendu à d’autres types de budgets.
Par exemple, au lieu du nombre d’accès à la ressource commune, le procédé de contrôle est appliqué pour la consommation d’énergie de la ressource commune.
Selon une autre variante, au lieu du nombre d’accès à la ressource commune, le procédé de contrôle est appliqué pour la température de la ressource commune.
Selon encore une autre variante, au lieu du nombre d’accès à la ressource commune, le procédé de contrôle est appliqué pour une quantité de mémoire utilisée.
Dans tous les cas, le procédé de contrôle est appliqué pour une grandeur physique relative à la ressource commune.

Claims

REVENDICATIONS
1.- Procédé de contrôle d’un système (30) comprenant un calculateur comportant une pluralité de cœurs et des ressources communes à au moins deux cœurs, chaque cœur étant propre à exécuter des tâches, chaque tâche impliquant une pluralité de traitements et un ou plusieurs accès à au moins une ressource commune pendant une période de temps d’exécution prédéfinie, chaque accès induisant une variation d’une grandeur physique relative à la ressource commune, chaque tâche étant critique ou non- critique, le procédé comportant au moins une étape de :
- pour chaque ressource commune, détermination de la variation du taux de ralentissement d’exécution dans l’exécution de chaque tâche critique en fonction de la valeur de la grandeur physique relative à la ressource commune pendant la période de temps d’exécution prédéfinie,
- pour chaque ressource commune, fixation d’une valeur maximale pendant la période de temps prédéfinie en fonction d’un taux de ralentissement d’exécution prédéterminé et de la variation déterminée,
- exécution de l’ensemble des tâches par le calculateur, l’étape d’exécution comportant la mesure de la grandeur physique pour chaque ressource et l’arrêt de l’exécution des tâches non-critiques dès que, pour une ressource, la valeur mesurée est supérieure à la valeur maximale fixée.
2.- Procédé selon la revendication 1 , dans lequel le procédé comporte, en outre, pour chaque ressource commune, une étape d’obtention de la valeur totale de la grandeur physique pour chaque tâche critique exécutée pendant la période de temps prédéfinie.
3.- Procédé selon la revendication 1 ou 2, dans lequel, le procédé comporte, pour chaque ressource commune, pendant la période de temps prédéfinie, une étape de fourniture d’un valeur maximale correspondant à la valeur de la grandeur physique possible pour la ressource commune considérée pour garantir un temps d’exécution maximal prédéfini pour un accès à la ressource commune.
4.- Procédé selon la revendication 3 dans sa dépendance avec la revendication 2, dans laquelle l’étape d’exécution comporte aussi la mesure de la grandeur physique pour chaque tâche critique et l’arrêt de l’exécution des tâches non-critiques dès que, pour une ressource, l’une au moins des deux conditions suivantes est remplie : - une première condition selon laquelle la grandeur physique mesurée est supérieure à la valeur maximale fournie, et
- une deuxième condition selon laquelle la somme de la grandeur physique mesurée pour chaque tâche critique exécutée est égale à la valeur totale obtenue.
5.- Procédé selon l’une quelconque des revendications 1 à 4, dans lequel le système (30) est un système temps réel.
6.- Procédé selon l’une quelconque des revendications 1 à 5, dans lequel le système (30) est un système embarqué, par exemple dans un avion, un satellite ou un véhicule ferroviaire.
7.- Procédé selon l’une quelconque des revendications 1 à 6, dans lequel les ressources communes appartiennent au groupe constitué des mémoires, des bus de liaison, des antémémoires, des périphériques entrée/sortie, des ports d’accès et des réseaux sur puce.
8.- Procédé selon l’une quelconque des revendications 1 à 7, dans lequel la grandeur physique est choisie dans le groupe constitué d’un nombre d’accès à la ressource commune, d’une consommation d’énergie, d’une température et d’une quantité de mémoire utilisée.
9.- Produit programme d’ordinateur comportant un support lisible d’informations, sur lequel est mémorisé un programme d’ordinateur comprenant des instructions de programme, le programme d’ordinateur étant chargeable sur une unité de traitement de données et adapté pour entraîner la mise en œuvre d’un procédé selon l’une quelconque des revendications précédentes lorsque le programme d’ordinateur est mis en œuvre sur l’unité de traitement des données.
10.- Support lisible d’informations sur lequel est mémorisé un produit programme d’ordinateur selon la revendication 9.
EP19726450.0A 2018-06-01 2019-05-29 Procédé de contrôle d'un système à plusieurs coeurs et dispositifs associés Pending EP3803589A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1800543A FR3082020B1 (fr) 2018-06-01 2018-06-01 Procede de controle d'un systeme a plusieurs coeurs et dispositifs associes
PCT/EP2019/064057 WO2019229168A1 (fr) 2018-06-01 2019-05-29 Procédé de contrôle d'un système à plusieurs coeurs et dispositifs associés

Publications (1)

Publication Number Publication Date
EP3803589A1 true EP3803589A1 (fr) 2021-04-14

Family

ID=63722441

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19726450.0A Pending EP3803589A1 (fr) 2018-06-01 2019-05-29 Procédé de contrôle d'un système à plusieurs coeurs et dispositifs associés

Country Status (3)

Country Link
EP (1) EP3803589A1 (fr)
FR (1) FR3082020B1 (fr)
WO (1) WO2019229168A1 (fr)

Also Published As

Publication number Publication date
FR3082020B1 (fr) 2020-08-14
FR3082020A1 (fr) 2019-12-06
WO2019229168A1 (fr) 2019-12-05

Similar Documents

Publication Publication Date Title
US11275561B2 (en) Mixed precision floating-point multiply-add operation
US9830677B2 (en) Graphics processing unit resource sharing
US9514037B1 (en) Test program scheduling based on analysis of test data sets
US10109030B1 (en) Queue-based GPU virtualization and management system
US9256452B1 (en) Providing an instance availability estimate
CN114730276B (zh) 确定多核处理器复合体中每个核心的最佳线程数量
KR102236419B1 (ko) 액세스 요청을 관리하기 위한 방법, 장치, 기기 및 저장 매체
Yang et al. Design adaptive task allocation scheduler to improve MapReduce performance in heterogeneous clouds
US8943287B1 (en) Multi-core processor system configured to constrain access rate from memory
US9253048B2 (en) Releasing computing infrastructure components in a networked computing environment
GB2475897A (en) Resource allocation using estimated time to complete jobs in a grid or cloud computing environment
CN108205469B (zh) 一种基于MapReduce的资源分配方法及服务器
US20120102499A1 (en) OPTIMIZING THE PERFORMANCE OF HYBRID CPU SYSTEMS BASED UPON THE THREAD TYPE OF APPLICATIONS TO BE RUN ON THE CPUs
FR3054902B1 (fr) Procede et dispositif de distribution de partitions sur un processeur multi-coeurs
US20120144039A1 (en) Computing scheduling using resource lend and borrow
US20160004985A1 (en) Prioritizing Proposal Development Under Resource Constraints
US10025624B2 (en) Processing performance analyzer and process manager
CA3149986C (fr) Plateforme distribuee de calcul en peripherie de reseau pour des vehicules
US9384057B2 (en) Programmatic load-based management of processor population
Dierks et al. On the cluster admission problem for cloud computing
EP3803589A1 (fr) Procédé de contrôle d'un système à plusieurs coeurs et dispositifs associés
US10423330B2 (en) Data collection in a multi-threaded processor
CN114004479B (zh) 目标资源需求量确定方法、装置、设备及存储介质
US9244939B2 (en) Managing I/O operations in a shared file system
US11144356B2 (en) Dynamic determination of memory requirements for function as a service multi-invocation flows

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20201201

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20240227