WO2014072628A1 - Procédé, dispositif et programme d'ordinateur de placement de tâches dans un système multi-coeurs - Google Patents

Procédé, dispositif et programme d'ordinateur de placement de tâches dans un système multi-coeurs Download PDF

Info

Publication number
WO2014072628A1
WO2014072628A1 PCT/FR2013/052633 FR2013052633W WO2014072628A1 WO 2014072628 A1 WO2014072628 A1 WO 2014072628A1 FR 2013052633 W FR2013052633 W FR 2013052633W WO 2014072628 A1 WO2014072628 A1 WO 2014072628A1
Authority
WO
WIPO (PCT)
Prior art keywords
task
tasks
heart
time
cores
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.)
Ceased
Application number
PCT/FR2013/052633
Other languages
English (en)
Inventor
Patrice Martinez
Landry Stéphane ZENG EYINDANGA
Jacques Cayuela
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.)
Bull SAS
Original Assignee
Bull SAS
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 Bull SAS filed Critical Bull SAS
Publication of WO2014072628A1 publication Critical patent/WO2014072628A1/fr
Anticipated expiration legal-status Critical
Ceased 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/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
    • G06F9/4887—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues involving deadlines, e.g. rate based, periodic
    • 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/5061—Partitioning or combining of resources
    • G06F9/5066—Algorithms for mapping a plurality of inter-dependent sub-tasks onto a plurality of physical CPUs

Definitions

  • the present invention relates to the management of processes in information systems and more particularly to a method, a device and a computer program for placing tasks in a multi-core system, in particular for certifying the behavior of a multitasking application. and real-time by calculating the placement of his tasks on a multi-core machine according to real-time constraints of each task.
  • a major problem encountered in the development of multitasking and real-time software applications is related to the guarantee that all the tasks of this application can be executed within time constraints. In particular, interrupts affecting a task must not prevent the latter from executing within an allotted time.
  • a system is said to be real-time when it is able to react reliably and repeatedly according to predetermined execution times. For these purposes, a task executed by this system must execute according to other tasks performed by it under predetermined time constraints.
  • the general principle of real time is to control which part of the program intervenes at each moment, without leaving room for randomness.
  • the task placement on each core is particularly important for the real-time behavior of the processor. considered application.
  • a solution commonly used today to optimize the behavior of a multitasking application and real time vis-à-vis the latter feature is to assign to each task, empirically, an investment priority all the higher than the response time associated with the task in question is small in order to influence the (automatic) placement of the task.
  • scheduler in English terminology, orders and places the tasks of an application on the assumption that at a given moment, the n cores of a processing system must execute the n highest priority tasks.
  • a guarantee related to the actual real-time behavior of the application can be obtained by performing a simulation of this behavior from the execution scenario of the application.
  • the invention thus relates to a method for placing a computer of a plurality of tasks in a system comprising a plurality of cores, before the execution of each of said tasks, time constraints being associated with each task of said plurality of tasks. tasks, this method comprising the following steps:
  • the method according to the invention thus makes it possible to assign tasks to cores according to time constraints, especially multitasking and real-time application tasks.
  • said steps of selecting a task, identifying a core and assigning a selected task to an identified core are repeated to assign a set of tasks of said plurality of tasks to at least one heart of said plurality of hearts.
  • the method according to the invention can thus automatically assign a set of tasks to a set of cores according to time constraints.
  • the method further comprises a step of assigning a priority to each task assigned to a heart, said priority being determined according to the assignment order tasks to said heart.
  • the method according to the invention can thus control the respect of time constraints.
  • Said time constraints include, for example, at least one worst execution time of the associated task, a response time allotted to the associated task and a period of execution of the associated task.
  • the method further comprises a prior step of scheduling the tasks of said plurality of tasks according to at least one time constraint.
  • the method according to the invention can thus control the respect of time constraints.
  • said scheduling is performed according to a period of execution of the associated task.
  • said step of identifying a heart comprises the following steps:
  • the method according to the invention thus makes it possible to select cores to which tasks must be assigned, according to time constraints.
  • Said plurality of cores for example form an ordered list of cores, a heart being incrementally selected in said ordered list of cores.
  • the invention also relates to a computer program comprising instructions adapted to the implementation of each of the steps of the method described above when said program is executed on a computer and a device comprising means adapted to the implementation of each of the steps of the method described above.
  • a computer program comprising instructions adapted to the implementation of each of the steps of the method described above when said program is executed on a computer
  • a device comprising means adapted to the implementation of each of the steps of the method described above.
  • FIG. 1 illustrates a representation of the execution time of a task, its worst execution time, the response time given to this task and its period;
  • FIG. 2 illustrates an exemplary task placement algorithm of a multitasking and real-time application executed in a multi-core system, according to an embodiment of the invention
  • FIG. 3 illustrates an example of placement of three tasks on a heart, according to the algorithm described with reference to FIG. 2;
  • FIG. 4 illustrates an exemplary hardware architecture adapted to implement certain steps of the method according to one embodiment of the invention.
  • the subject of the invention is the placement of tasks in a multi-user system, in particular for certifying the behavior of a multitasking and real-time application by calculating the placement of its tasks on a multi-user machine in function time constraints of each task.
  • Such an investment is here performed before the execution of the tasks, in a predetermined manner.
  • the placement of tasks on cores is static.
  • Such time constraints may notably be expressed by the following parameters, for each task of the targeted application:
  • the period is a value inherited from the functional area, it corresponds to an application need, for example a sampling frequency on a sensor.
  • the pseudo-period also expresses a functional need. However, it corresponds to a minimum time interval between two consecutive executions of the task.
  • a pseudo-period is here assimilated to a period, these two notions being managed identically in a particular embodiment of the invention.
  • Non-recurring tasks have a period set here to zero.
  • the worst execution time of a task corresponds to the execution time, at worst, of the task, whatever the processing it must perform and considering that it is not interrupted. This time depends in particular on the computing power of the heart performing this task as well as the nature and the amount of data processed by the task.
  • the worst execution time of a task can be obtained, empirically, by executing the task with the dataset producing the longest processing time and measuring the processing time. This measurement can be done by direct measurement or with the help of a simulator or an emulator. The value of this parameter is preferably provided by the designer or developer of the application or task. It can also be obtained, for a particular data processing system, by extrapolation, for example by linear extrapolation, from a known reference value linked to another particular data processing system.
  • the response time given to a task (deadline), to perform a processing also corresponds to an application need. This is typically a strong constraint that, if not met, may compromise the proper operation of the intended real-time application. It is typically defined by the time at which another task needs a result produced by the task in question.
  • FIG. 1 illustrates an exemplary representation of the execution time of a task T 1t of its worst execution time, denoted WCET ⁇ ), of the response time given to this task, denoted DL (Ti), and of its period, noted ⁇ T-,).
  • the task Ti is here executed periodically at time t 0 , then at the time following the time to, after a duration ⁇ ( ⁇ ).
  • indices / ' and j represent indices on cycles of execution.
  • additional non-temporal and optional parameters may be used for task placement in a multi-core system.
  • the task execution order notably makes it possible to simplify the placement calculation if, from the application point of view, the tasks of the same period are linked together.
  • the execution of the / V th task to be executed is initiated following a duration equal to the sum of the response times given to each of the (n - 1) preceding tasks.
  • the sum of the response times given to the tasks which follow each other must be less than the common period of these tasks.
  • a task call is for a given task to call another task, explicitly, and to wait for a result.
  • Such a call can be blocking or not.
  • a non-blocking call only an explicit resynchronization of tasks is performed. Whether blocking or not, it should be checked that the following conditions are true:
  • the called task is not treated as periodic because it is explicitly triggered by the calling task.
  • tasks whose temporal parameters are compatible with each other are placed on the same core.
  • all the tasks placed on the same The heart can execute entirely in the respect of their response time, whatever the tasks that come to interrupt them.
  • one particular object of the invention is, according to a particular embodiment, to formally calculate, according to their real-time characteristics, which tasks of an application can coexist within one and the same core. a given multi-core system.
  • the tasks are sorted according to their characteristics, in particular according to their period or pseudoperiod of execution, their worst execution time (WCET) and / or the response time allotted to them ( deadline). Their sorting can also be optionally based on the order of execution of tasks and calls between tasks.
  • Figure 2 illustrates an example of a task placement algorithm
  • Tk of a multitasking and real-time application to be executed in a multi-core system here comprising n cores, according to an embodiment of the invention. According to this example, it is appropriate to place m tasks on n cores.
  • a first step (step 200) is to sort the m tasks T k
  • an index p representing an index on the cores of the system (varying from 1 to n)
  • that of the index k is then set to one and that of the index k to the value n + 1.
  • a test is then performed (step 210) to determine if there is at least one task in the list of ordered tasks that has not been placed on a heart, that is, if there is a task T k . If not, the algorithm terminates, each of the tasks of the considered application having been placed successfully on a core.
  • the first non-placed task of the ordered task list is selected (step 215).
  • Another test is then performed to determine if there is at least one heart that has not yet been selected to attempt to place there the task T k selected (step 220), that is to say to determine if the heart C p has already been selected to attempt to place the task T k there . If not, if it has been attempted to place the task T on each of the cores of the multi-core system, the algorithm ends. The task placement is then a failure.
  • a solution consists, for example, in adding at least one core to the multi-core system and in re-executing the algorithm described here.
  • a test is carried out to determine whether the selected task T k can be placed on the heart C p selected (step 225). If the task T k selected can not be placed on the heart C p selected, the value of the index p is incremented by one, modulo n, that is to say modulo the number of cores of the multi-core system that can used to place tasks of the application under consideration (step 230). The algorithm then loops back to step 220 to determine whether the task T k can be placed on the next heart (heart C p ).
  • the selected task T k can be placed on the heart C p selected, it is (step 235).
  • the value of the index k is then incremented by one and that of the index p is also incremented by one, modulo n (step 240).
  • the algorithm then loops back to step 210 to determine whether there remains at least one task T k to be placed on a heart.
  • a task T r can not be placed on a heart C p on which have been previously placed a set of tasks T s (s ranging from 1 to (r - 1)) if , and only if, for every k belonging to the interval [1, r],
  • CEIL (x) is a function that returns the integer immediately greater than the value of the variable x.
  • an execution priority is here associated with the task. This priority corresponds, for example, to his rank of assignment on the heart. Thus, the first task placed on a heart has a priority equal to 1, the second task placed on this heart has a priority equal to 2 and so on.
  • a task when a task is placed on a heart, it can not be moved later to place other tasks.
  • a task list is obtained for each core of the system.
  • the resulting list tasks are sorted, by list, from the task with the largest period to the task with the smallest period, that is, from the lowest priority task to the highest task.
  • priority In other words, the priority of a task is here determined by its position in the list of tasks assigned to the considered heart.
  • FIG. 3 illustrates an example of placement of three tasks on a heart, according to the algorithm described with reference to FIG. 2.
  • a white rectangle represents here a response time allotted to a task while a black rectangle represents the time actually allocated by the node to the task.
  • the algorithm described with reference to Figure 2 can be used for different purposes. As previously described, it can be used for formal certification. The algorithm then determines an investment that guarantees the behavior of a multitasking application on a given computer platform.
  • the algorithm is started successively by reducing or increasing, at each execution, the number of cores that can be used, until obtaining the optimal number of cores.
  • the algorithm also allows to validate a placement performed manually. For these purposes, the list of tasks and their assignment to different cores is provided to the algorithm that does not perform, in this case, the sorting step (step 200). If the validation succeeds without modifying the order of the tasks, the manual placement was, in the sense of the algorithm, optimal. If validation changes the order of the tasks, a more suitable solution is found. On the contrary, if the validation fails, the manual placement was incorrect.
  • the algorithm can also be used for certification of a distributed application.
  • This algorithm can be used to calculate the placement of tasks on a cluster of machines connected to each other by a broadband network and in which the clocks are synchronized. This allows in particular to implement distributed real time applications of large size. For these purposes, it is appropriate to dedicate to the application a certain number of hearts, isolated from any disturbance, by physical machine. It is also appropriate to take into account, in the switching time, the network communication aspects between machines.
  • FIG. 4 illustrates an example of hardware architecture of a device
  • the device 400 is, for example, a computer or a workstation.
  • a communication bus 405 to which are connected: one or more central processing units or microprocessors 410 (CPU, acronym for Central Processing Unit in English terminology);
  • a read only memory 415 (ROM, acronym for Read Only Memory in English terminology) which may include programs (prog, progl and prog2) necessary for the implementation of the invention;
  • RAM Random Access Memory
  • cache memory 420 comprising registers adapted to record variables and parameters created and modified during the execution of the aforementioned programs
  • a communication interface 450 adapted to transmit and receive data.
  • the device 400 also preferably has a hard disk
  • a memory card reader 440 adapted to receive a memory card 445 and to read or write to it data processed or to be processed according to the invention. 'invention.
  • the communication bus allows communication and interoperability between the various elements included in the device 400 or connected to it.
  • the representation of the bus is not limiting and, in particular, the central unit is able to communicate instructions to any element of the device 400 directly or through another element of the device 400.
  • the executable code of each program enabling the programmable device to implement the processes according to the invention can be stored, for example, in the hard disk 435 or in the read-only memory 415.
  • the memory card 445 may contain information, in particular information to be processed according to the invention, as well as the executable code of the aforementioned programs which, once read by the device 400, is stored in the hard disk 435.
  • the executable code of the programs and the information to be processed according to the invention may be received, at least partially, via the interface 450, to be stored in a manner identical to that described above.
  • the program (s) and the information to be processed according to the invention may be loaded into one of the storage means of the device 400 before being executed.
  • the central unit 410 will control and direct the execution of the instructions or portions of software code of the program or programs according to the invention, instructions which are stored in the hard disk 435 or in the 415 read-only memory or in the other storage elements mentioned above.
  • the program or programs that are stored in a non-volatile memory for example the hard disk 435 or the read only memory 415, are transferred into the random access memory 420 which then contains the executable code of the program or programs according to the invention, as well as registers for storing the variables and parameters necessary for the implementation of the invention.

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)

Abstract

L'invention a notamment pour objet le placement de tâches dans un système multi-cœurs, des contraintes de temps étant associées à chaque tâche. Après avoir affecté (205) au moins une tâche distincte à chaque cœur, une tâche non affectée est sélectionnée (220). Un cœur susceptible d'exécuter la tâche sélectionnée selon des contraintes de temps associées à cette tâche et des contraintes de temps associées à des tâches préalablement affectées à ce cœur est alors identifié (225). La tâche sélectionnée est ensuite affectée (235) au cœur identifié.

Description

Procédé, dispositif et programme d'ordinateur de placement de tâches dans un système multi-cœurs
La présente invention concerne la gestion de processus dans les systèmes d'information et plus particulièrement un procédé, un dispositif et un programme d'ordinateur de placement de tâches dans un système multi-cœurs, permettant notamment de certifier le comportement d'une application multitâche et temps réel en calculant le placement de ses tâches sur une machine multi- cœurs en fonction de contraintes de temps réel de chacune des tâches.
Un problème important rencontré lors du développement d'applications logicielles multitâches et temps réel est relatif à la garantie du fait que toutes les tâches de cette application puissent s'exécuter en respectant des contraintes de temps. En particulier, des interruptions affectant une tâche ne doivent pas empêcher cette dernière de s'exécuter dans un délai imparti.
Il est rappelé ici qu'un système est dit temps réel lorsqu'il est capable de réagir de façon fiable et répétée selon des délais d'exécution prédéterminés. A ces fins, une tâche exécutée par ce système doit s'exécuter en fonction d'autres tâches exécutées par celui-ci selon des contraintes de temps prédéterminées. Le principe général du temps réel consiste à contrôler quelle partie du programme intervient à chaque instant, sans laisser de place à l'aléatoire.
Lorsque le système de traitement de l'information utilisé est un système multi-cœurs, c'est-à-dire un système comprenant plusieurs unités de traitement, le placement des tâches sur chaque cœur est particulièrement important pour le comportement temps réel de l'application considérée.
Une solution couramment utilisée aujourd'hui pour optimiser le comportement d'une application multitâche et temps réel vis-à-vis de cette dernière caractéristique consiste à affecter, à chaque tâche, de façon empirique, une priorité de placement d'autant plus élevée que le temps de réponse associé à la tâche considérée est petit afin d'influencer le placement (automatique) de la tâche. En effet, un séquenceur temps réel de tâches, appelé scheduler en terminologie anglo-saxonne, ordonne et place les tâches d'une application en partant du principe qu'à un instant donné, les n cœurs d'un système de traitement doivent exécuter les n tâches les plus prioritaires.
Dans ce contexte, une garantie liée au comportement temps réel effectif de l'application peut être obtenue en effectuant une simulation de ce comportement à partir de scénarii d'exécution de l'application.
Cependant, une telle approche a ses limites car les scénarii utilisés doivent décrire de façon fidèle le comportement de l'application, ce qui peut être difficile à démontrer. Ainsi, à titre d'illustration, plusieurs tâches ayant chacune une forte priorité peuvent empêcher une tâche de moindre priorité de respecter sa propre contrainte de temps d'exécution et, par conséquent, empêcher un fonctionnement normal de l'application.
Pour contenir un tel risque, une solution couramment utilisée consiste à sur-dimensionner le système, notamment au niveau de sa puissance de calcul et/ou du nombre de cœurs mis en œuvre. Cependant, l'inconvénient majeur d'une telle approche est lié à son coût, sans que le surcoût ne garantisse le comportement temps réel de l'application.
Il existe donc un besoin pour améliorer le placement de tâches d'une application multitâche et temps réel dans un système multi-cceurs.
L'invention a ainsi pour objet un procédé pour ordinateur de placement d'une pluralité de tâches dans un système comprenant une pluralité de cœurs, avant l'exécution de chacune desdites tâches, des contraintes de temps étant associées à chaque tâche de ladite pluralité de tâches, ce procédé comprenant les étapes suivantes :
- affectation d'au moins une tâche distincte de ladite pluralité de tâches à chaque cœur de ladite pluralité de cœurs ;
- sélection d'une tâche non affectée de ladite pluralité de tâches ;
- identification d'un cœur de ladite pluralité de cœurs susceptible d'exécuter ladite tâche sélectionnée selon des contraintes de temps associées à ladite tâche sélectionnée et des contraintes de temps associées à des tâches préalablement affectées audit cœur identifié ; et
- affectation de ladite tâche sélectionnée audit cœur identifié. Le procédé selon l'invention permet ainsi d'affecter des tâches à des cœurs selon des contraintes de temps, notamment des tâches d'applications multitâches et temps réel.
Selon un mode de réalisation particulier, lesdites étapes de sélection d'une tâche, d'identification d'un cœur et d'affectation d'une tâche sélectionnée à un cœur identifié sont répétées pour affecter un ensemble de tâches de ladite pluralité de tâches à au moins un cœur de ladite pluralité de cœurs. Le procédé selon l'invention peut ainsi affecter automatiquement un ensemble de tâches à un ensemble de cœurs selon des contraintes de temps.
Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape d'assignation d'une priorité à chaque tâche affectée à un cœur, ladite priorité étant déterminée en fonction de l'ordre d'assignation des tâches audit cœur. Le procédé selon l'invention peut ainsi contrôler le respect de contraintes de temps.
Lesdites contraintes de temps comprennent, par exemple, au moins un pire temps d'exécution de la tâche associée, un temps de réponse imparti à la tâche associée et une période d'exécution de la tâche associée.
Selon un mode de réalisation particulier, le procédé comprend en outre une étape préalable d'ordonnancement des tâches de ladite pluralité de tâches selon au moins une contrainte de temps. Le procédé selon l'invention peut ainsi contrôler le respect de contraintes de temps.
Toujours selon un mode de réalisation particulier, ledit ordonnancement est effectué selon une période d'exécution de la tâche associée.
Toujours selon un mode de réalisation particulier, ladite étape d'identification d'un cœur comprend les étapes suivantes :
- sélection d'un cœur de ladite pluralité de cœurs ;
- évaluation de la capacité dudit cœur sélectionné à exécuter ladite tâche sélectionnée selon des contraintes de temps associées à ladite tâche sélectionnée et les contraintes de temps associées aux tâches préalablement affectées audit cœur sélectionné ; et - si ledit cœur sélectionné n'est pas capable d'exécuter ladite tâche sélectionnée selon des contraintes de temps associées à ladite tâche sélectionnée et des contraintes de temps associées aux tâches préalablement affectées audit cœur sélectionné, répétition des étapes de sélection d'un cœur et d'évaluation.
Le procédé selon l'invention permet ainsi de sélectionner des cœurs auxquels doivent être affectées des tâches, selon des contraintes de temps.
Ladite pluralité de cœurs forme par exemple une liste ordonnée de cœurs, un cœur étant sélectionné de façon incrémentale dans ladite liste ordonnée de cœurs.
L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en œuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur ainsi qu'un dispositif comprenant des moyens adaptés à la mise en œuvre de chacune des étapes du procédé décrit précédemment. Les avantages procurés par ce programme d'ordinateur et ce dispositif sont similaires à ceux évoqués précédemment.
D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels :
- la figure 1 illustre une représentation du temps d'exécution d'une tâche, de son pire temps d'exécution, du temps de réponse imparti à cette tâche et de sa période ;
- la figure 2 illustre un exemple d'algorithme de placement de tâches d'une application multitâche et temps réel exécutée dans un système multi-cœurs, conformément à un mode de réalisation de l'invention ;
- la figure 3 illustre un exemple de placement de trois tâches sur un cœur, conformément à l'algorithme décrit en référence à la figure 2 ; et
- la figure 4 illustre un exemple d'architecture matérielle adaptée à mettre en œuvre certaines étapes du procédé selon un mode de réalisation de l'invention. De façon générale, l'invention a pour objet le placement de tâches dans un système multi-cceurs, permettant notamment de certifier le comportement d'une application multitâche et temps réel en calculant le placement de ses tâches sur une machine multi-cceurs en fonction de contraintes de temps de chacune des tâches.
Un tel placement est ici effectué avant l'exécution des tâches, de façon prédéterminée. En d'autres termes, le placement des tâches sur des cœurs est statique.
De telles contraintes de temps peuvent notamment être exprimées par les paramètres suivants, pour chaque tâche de l'application visée :
- le pire temps d'exécution de la tâche, aussi appelé WCET (sigle de Worst Case Execution Time en terminologie anglo-saxonne) ;
- le temps de réponse imparti à la tâche, aussi appelé deadline et noté DL, qui doit être respecté chaque fois que la tâche est exécutée ; et
- la période d'exécution de la tâche, ou intervalle de temps minimum entre deux exécutions consécutives de la tâche, aussi nommée période pour une tâche réellement périodique ou pseudo-période si seul l'intervalle de temps minimum entre deux exécutions consécutives de la tâche est considéré.
La période est une valeur héritée du domaine fonctionnel, elle correspond à un besoin applicatif, par exemple une fréquence d'échantillonnage sur un capteur. La pseudo-période exprime, elle aussi, un besoin fonctionnel. Cependant, elle correspond à un intervalle de temps minimum entre deux exécutions consécutives de la tâche. Une pseudo-période est ici assimilée à une période, ces deux notions étant gérées de façon identique dans un mode de réalisation particulier de l'invention. Les tâches non périodiques ont une période fixée ici à zéro.
Le pire temps d'exécution d'une tâche (WCET) correspond au temps d'exécution, au pire, de la tâche, quel que soit le traitement qu'elle doit effectuer et en considérant qu'elle n'est pas interrompue. Ce temps dépend notamment de la puissance de calcul du cœur exécutant cette tâche ainsi que de la nature et la quantité de données traitées par la tâche. Le pire temps d'exécution d'une tâche peut-être obtenue, de façon empirique, en exécutant la tâche avec le jeu de données produisant la plus longue durée de traitement et en mesurant le temps de traitement. Cette mesure peut être effectuée par mesure directe ou à l'aide d'un simulateur ou d'un émulateur. La valeur de ce paramètre est, de préférence, fournie par le concepteur ou le développeur de l'application ou de la tâche. Elle peut également être obtenue, pour un système de traitement de données particulier, par extrapolation, par exemple par extrapolation linéaire, à partir d'une valeur de référence connue liée à un autre système de traitement de données particulier.
Le temps de réponse imparti à une tâche (deadline), pour effectuer un traitement, correspond également à un besoin applicatif. Il s'agit typiquement d'une contrainte forte qui, si elle n'est pas respectée, peut compromettre le bon fonctionnement de l'application temps réel visée. Il est typiquement défini par l'instant auquel une autre tâche a besoin d'un résultat produit par la tâche considérée.
La figure 1 illustre un exemple de représentation du temps d'exécution d'une tâche T1t de son pire temps d'exécution, noté WCET^), du temps de réponse imparti à cette tâche, noté DL(T-i), et de sa période, notée Ô T-,).
La tâche Ti, mise en oeuvre par un cœur donné, est ici exécutée de façon périodique au temps t0, puis au temps suivant le temps to, après une durée δ(Τι). δ(Τι) définit ainsi la période d'exécution de la tâche 7"? (f? = 10 + ÔÇT-i)). La nieme exécution de la tâche Ti se produit au temps tn-i {tn-i = to + (n -
Comme représenté, si le pire temps d'exécution de la tâche T-i (WCETiT^), ainsi que le temps de réponse imparti de cette tâche (DL(Ti)) sont constants, le temps d'exécution réel de la tâche, noté EXEC(T-i), ne l'est pas car il dépend de plusieurs facteurs, notamment, par exemple, des données à traiter. Ainsi, en d'autres termes, si les variables t , t" et t" sont définies de la façon suivante :
t = ti + EXEC(Tj)
Figure imgf000009_0001
n= t, + DL(T
alors (t ", - 1!) = (f - tj) et (f" ',· - f,) = (t") - tj)
mais (t - ί,) = (t) - tj) ou (f ',· - f,)≠ (t) - tj)
où les indices /' et j représentent des indices sur des cycles d'exécution.
Selon un mode de réalisation particulier de l'invention, d'autres paramètres supplémentaires, non temporels et optionnels, peuvent être utilisés pour le placement de tâches dans un système multi-cœurs. Ainsi, par exemple il est possible de prendre en compte l'ordre exécution de tâches et l'appel d'une tâche par une autre.
Il est observé ici que l'ordre d'exécution de tâches permet notamment de simplifier le calcul de placement si, du point de vue applicatif, des tâches de même période s'enchaînent. Dans ce cas, l'exécution de la /Veme tâche à exécuter est lancée suite à une durée égale à la somme des temps de réponse impartis à chacune des (n - 1) tâches précédentes. La somme des temps de réponse impartis aux tâches qui s'enchaînent doit être inférieure à la période commune de ces tâches.
Un appel de tâches consiste, pour une tâche donnée, à appeler une autre tâche, de façon explicite, et à en attendre un résultat. Un tel appel peut être bloquant ou non. Dans le cas d'un appel non bloquant, seule une resynchronisation explicite de tâches est effectuée. Qu'ils soient bloquants ou non, il convient de vérifier que les conditions suivantes sont vérifiées :
WCET l "appelante) + DL(Tappeiée) < DL( 7 'appelante)
où, à nouveau, WCET(Tappeiante) représente le pire temps d'exécution de la tâche appelante et DL(J 'appelée) et DL(J 'appelante) représentent les temps de réponse impartis aux tâches appelées et appelantes, respectivement.
Il est observé que, dans ce cas, la tâche appelée n'est pas traitée comme périodique car elle est explicitement déclenchée par la tâche appelante.
Conformément à un mode de réalisation particulier de l'invention, des tâches dont les paramètres temporels sont compatibles entre eux sont placés sur un même cœur. En d'autres termes, toutes les tâches placées sur un même cœur peuvent s'exécuter entièrement dans le respect de leur temps de réponse, quelles que soient les tâches qui viennent les interrompre.
Ainsi, de façon générale, l'invention a notamment pour objet, selon un mode de réalisation particulier, de calculer formellement, en fonction de leurs caractéristiques temps réel, quelles tâches d'une application peuvent cohabiter au sein d'un même cœur d'un système multi-cœurs donné.
A ces fins, il est admis que les cœurs dédiés à l'exécution de tâches de l'application considérée sont exempts de perturbations. Ainsi, tous les processus non applicatifs tels que des processus du système d'exploitation utilisé ainsi que des processus de traitement des interruptions sont avantageusement migrés sur d'autres cœurs dédiés, notamment, à l'exécution du système d'exploitation du système multi-cœurs.
Par ailleurs, il convient de prendre en compte le temps nécessaire au système d'exploitation utilisé pour commuter de l'exécution d'une tâche à celle d'une autre. À ces fins, un temps de commutation prenant en compte un surcoût de temps ajouté par la plate-forme matérielle utilisée est ajouté au temps d'exécution de chaque tâche. Un tel temps de commutation peut être mesuré ou estimé. Dans ce dernier cas, il convient d'effectuer une majoration raisonnable.
Pour permettre le placement, les tâches sont ici triées en fonction de leurs caractéristiques, notamment en fonction de leur période ou pseudopériode d'exécution, de leur pire temps d'exécution (WCET) et/ou du temps de réponse qui leur est imparti (deadline). Leur tri peut également être basé, de façon optionnelle, sur l'ordre d'exécution des tâches et des appels entre tâches.
La figure 2 illustre un exemple d'algorithme de placement de tâches
Tk d'une application multitâche et temps réel devant être exécutée dans un système multi-cœurs, comprenant ici n cœurs, conformément à un mode de réalisation de l'invention. Selon cet exemple, il convient de placer m tâches sur n cœurs.
Une première étape (étape 200) a pour objet de trier les m tâches Tk
(k variant de 1 à m). Ce tri est ici effectué par période décroissante (selon la période associée à chaque tâche), puis pour des tâches ayant des périodes identiques, par pire temps de réponse décroissant et, pour des tâches ayant des périodes et des pires temps de réponse identiques, par temps de réponse imparti décroissant.
Ainsi, par exemple, une tâche T, est placée avant une tâche 7} si δ(Τ;) > S(Tj) ou, si Ô(Tj) = S(Tj), si DL(Ti) > DL(Tj).
Au cours d'une étape suivante (étape 205), les n premières tâches Tk (k = 1 à n) sont placées sur les n cœurs du système multi-cœurs mettant en œuvre l'application considérée. Chacune de ces n premières tâches est placée sur un cœur distinct. Ainsi, en considérant que les cœurs sont notés Cp (p = 1 à n), la tâche Tk est placée sur le cœur Cp, k et p variant simultanément de 1 à n.
La valeur d'un index p, représentant un index sur les cœurs du système (variant de 1 à n), est alors mise à un et celle de l'index k à la valeur n + 1 .
Un test est ensuite effectué (étape 210) pour déterminer s'il existe au moins une tâche de la liste des tâches ordonnées qui n'a pas été placée sur un cœur, c'est-à-dire s'il existe une tâche Tk. Dans la négative, l'algorithme prend fin, chacune des tâches de l'application considérée ayant été placée avec succès sur un cœur.
Au contraire, s'il existe au moins une tâche Tk de la liste des tâches ordonnées qui n'a pas été placée sur un cœur, la première tâche non placée de la liste des tâches ordonnées est sélectionnée (étape 215).
Un autre test est alors effectué pour déterminer s'il existe au moins un cœur qui n'a pas encore été sélectionné pour tenter d'y placer la tâche Tk sélectionnée (étape 220), c'est-à-dire pour déterminer si le cœur Cp a déjà été sélectionné pour tenter d'y placer la tâche Tk. Dans la négative, s'il a été tenté de placer la tâche T sur chacun des cœurs du système multi-cœurs, l'algorithme prend fin. Le placement des tâches est alors un échec.
Dans ce cas, une solution consiste par exemple à ajouter au moins un cœur au système multi-cœurs et à ré-exécuter l'algorithme décrit ici.
Au contraire, si le cœur Cp n'a pas encore été sélectionné pour tenter d'y placer la tâche Tk sélectionnée, un test est effectué pour déterminer si la tâche Tk sélectionnée peut être placée sur le cœur Cp sélectionné (étape 225). Si la tâche Tk sélectionnée ne peut être placée sur le cœur Cp sélectionné, la valeur de l'index p est incrémentée de un, modulo n, c'est-à-dire modulo le nombre de cœurs du système multi-cœurs pouvant être utilisés pour placer des tâches de l'application considérée (étape 230). L'algorithme reboucle alors à l'étape 220 pour déterminer si la tâche Tk peut être placée sur le cœur suivant (cœur Cp).
Si, au contraire, la tâche Tk sélectionnée peut être placée sur le cœur Cp sélectionné, elle l'est (étape 235). La valeur de l'index k est alors incrémentée de un et celle de l'index p est également incrémentée de un, modulo n (étape 240). L'algorithme reboucle ensuite à l'étape 210 pour déterminer s'il reste au moins une tâche Tk à placer sur un cœur.
Pour déterminer si une tâche périodique ou pseudo-périodique Tk peut être placée sur un cœur Cp, il convient, de préférence, de prendre en compte la fréquence de cette tâche à placer par rapport à celles des tâches déjà placées sur le même cœur, ainsi que leurs pires temps d'exécution et leurs temps de réponse impartis. À ces fins, des règles peuvent être utilisées.
Ainsi, par exemple, il peut être décidé qu'une tâche Tr ne peut être placée sur un cœur Cp sur lequel ont été préalablement placées un ensemble de tâches Ts (s variant de 1 à (r - 1)) que si, et seulement si, pour tout k appartenant à l'intervalle [1 , r],
r
^ WCETREELÇTi) < DL(Tk) avec
WCETREELÇTt) = · WCET T ))
Figure imgf000012_0001
où la fonction CEIL(x) est une fonction qui retourne l'entier immédiatement supérieur à la valeur de la variable x.
De telles règles permettent de prendre en compte l'exécution d'une tâche de plus faible période et de calculer son impact réel sur des tâches déjà placées sur le même cœur.
Naturellement il est possible d'utiliser d'autres règles. Lorsqu'une tâche est placée sur un cœur, une priorité d'exécution est ici associée à la tâche. Cette priorité correspond, par exemple, à son rang d'assignation sur le cœur. Ainsi, la première tâche placée sur un cœur a une priorité égale à 1 , la seconde tâche placée sur ce cœur a une priorité égale à 2 et ainsi de suite.
Selon un mode de réalisation particulier, lorsqu'une tâche est placée sur un cœur, elle ne peut être déplacée ultérieurement pour y placer d'autres tâches.
Lorsqu'un ensemble de tâches a été placé avec succès sur un ensemble de cœurs d'un système multi-cœurs, une liste de tâches est obtenue pour chaque cœur du système. Les tâches des listes obtenues sont classées, par liste, de la tâche ayant la plus grande période à la tâche ayant la plus petite période, c'est-à-dire de la tâche ayant la plus faible priorité à la tâche ayant la plus haute priorité. En d'autres termes, la priorité d'une tâche est ici déterminée par sa position dans la liste de tâches affectées au cœur considéré.
Lorsque toutes les tâches d'une application ont été placées sur un ensemble de cœurs d'un système multi-cœurs, le comportement temps réel de l'application correspondante est vérifié car chaque tâche a le temps de s'exécuter avant d'atteindre la fin de son temps de réponse imparti malgré des interruptions de tâches plus prioritaires situées sur le même cœur.
La figure 3 illustre un exemple de placement de trois tâches sur un cœur, conformément à l'algorithme décrit en référence à la figure 2. Un rectangle blanc représente ici un temps de réponse imparti à une tâche tandis qu'un rectangle noir représente le temps de traitement effectivement alloué par le nœud à la tâche.
L'algorithme décrit en référence à la figure 2 peut être utilisé à différentes fins. Comme décrit précédemment, il peut être utilisé pour une certification formelle. L'algorithme détermine alors un placement qui garantit le comportement d'une application multitâche sur une plate-forme informatique donnée.
Il peut également être utilisé pour déterminer le dimensionnement minimum d'une plate-forme devant être mise en œuvre. A ces fins, l'algorithme est lancé de façon successive en réduisant ou en augmentant, à chaque exécution, le nombre de cœurs pouvant être utilisés, jusqu'à obtenir le nombre de cœurs optimal.
L'algorithme permet également de valider un placement effectué de façon manuelle. À ces fins, la liste des tâches et de leur affectation aux différents cœurs est fournie à l'algorithme qui n'effectue pas, dans ce cas, l'étape de tri (étape 200). Si la validation réussit sans modifier l'ordre des tâches, le placement manuel était, au sens de l'algorithme, optimal. Si la validation modifie l'ordre des tâches, une solution plus adaptée est trouvée. Au contraire, si la validation échoue, le placement manuel était incorrect.
L'algorithme peut aussi être utilisé pour la certification d'une application répartie. Cet algorithme est utilisable pour calculer le placement des tâches sur un cluster de machines reliées entre elles par un réseau haut débit et dans lequel les horloges sont synchronisées. Cela permet notamment de mettre en œuvre des applications temps réel réparties de grande taille. A ces fins, il convient de dédier à l'application un certain nombre de cœurs, isolés de toute perturbation, par machine physique. Il convient également de prendre en compte, dans le temps de commutation, les aspects communication réseau entre machines.
La figure 4 illustre un exemple d'architecture matérielle d'un dispositif
400 adapté à mettre en œuvre certaines étapes de l'invention, en particulier les étapes décrites en référence à la figure 2. Le dispositif 400 est, par exemple, un ordinateur ou une station de travail.
Il comporte ici un bus de communication 405 auquel sont reliés : - une ou plusieurs unités centrales de traitement ou microprocesseurs 410 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ;
- une mémoire morte 415 (ROM, acronyme de Read Only Memory en terminologie anglo-saxonne) pouvant comporter des programmes (prog, progl et prog2) nécessaires à la mise en œuvre de l'invention ;
- une mémoire vive ou mémoire cache 420 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités ; et
- une interface de communication 450 adaptée à transmettre et à recevoir des données.
Le dispositif 400 dispose également, de préférence, d'un disque dur
435 pouvant comporter les programmes précités ainsi que des informations traitées ou à traiter selon l'invention et d'un lecteur de cartes mémoires 440 adapté à recevoir une carte mémoire 445 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention.
Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 400 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du dispositif 400 directement ou par l'intermédiaire d'un autre élément du dispositif 400.
Le code exécutable de chaque programme permettant au dispositif programmable de mettre en œuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 435 ou en mémoire morte 415.
Selon une variante, la carte mémoire 445 peut contenir des informations, notamment des informations à traiter selon l'invention, ainsi que le code exécutable des programmes précités qui, une fois lu par le dispositif 400, est stocké dans le disque dur 435.
Selon une autre variante, le code exécutable des programmes et les informations à traiter selon l'invention pourront être reçus, au moins partiellement, par l'intermédiaire de l'interface 450, pour être stocké de façon identique à celle décrite précédemment.
De manière plus générale, le ou les programmes ainsi que les informations à traiter selon l'invention pourront être chargés dans un des moyens de stockage du dispositif 400 avant d'être exécutés.
L'unité centrale 410 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 435 ou dans la mémoire morte 415 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 435 ou la mémoire morte 415, sont transférés dans la mémoire vive 420 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en œuvre de l'invention.
Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente.

Claims

REVENDICATIONS
1. Procédé pour ordinateur de placement d'une pluralité de tâches dans un système comprenant une pluralité de cœurs, avant l'exécution de chacune desdites tâches, des contraintes de temps étant associées à chaque tâche de ladite pluralité de tâches, lesdites contraintes de temps comprenant au moins un pire temps d'exécution de la tâche associée, un temps de réponse imparti à la tâche associée et une période d'exécution de la tâche associée, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes :
- affectation (205) d'au moins une tâche distincte de ladite pluralité de tâches à chaque cœur de ladite pluralité de cœurs ;
- sélection (220) d'une tâche non affectée de ladite pluralité de tâches ;
- identification (225) d'un cœur de ladite pluralité de cœurs susceptible d'exécuter ladite tâche sélectionnée selon des contraintes de temps associées à ladite tâche sélectionnée et des contraintes de temps associées à des tâches préalablement affectées audit cœur identifié ; et
- affectation (235) de ladite tâche sélectionnée audit cœur identifié, le procédé comprenant une étape préalable d'ordonnancement (200) des tâches de ladite pluralité de tâches selon lesdites contraintes de temps.
2. Procédé selon la revendication 1 selon lequel lesdites étapes de sélection d'une tâche, d'identification d'un cœur et d'affectation d'une tâche sélectionnée à un cœur identifié sont répétées pour affecter un ensemble de tâches de ladite pluralité de tâches à au moins un cœur de ladite pluralité de cœurs.
3. Procédé selon la revendication 1 ou !a revendication 2 comprenant en outre une étape d'assignation d'une priorité à chaque tâche affectée à un cœur, ladite priorité étant déterminée en fonction de l'ordre d'assignation des tâches audit cœur.
4. Procédé selon l'une quelconque des revendications 1 à 3 selon lequel ladite étape d'identification d'un cœur comprend les étapes suivantes : - sélection d'un cœur de ladite pluralité de cœurs ;
- évaluation de la capacité dudit cœur sélectionné à exécuter ladite tâche sélectionnée selon des contraintes de temps associées à ladite tâche sélectionnée et les contraintes de temps associées aux tâches préalablement affectées audit cœur sélectionné ; et
- si ledit cœur sélectionné n'est pas capable d'exécuter ladite tâche sélectionnée selon des contraintes de temps associées à ladite tâche sélectionnée et des contraintes de temps associées aux tâches préalablement affectées audit cœur sélectionné, répétition des étapes de sélection d'un cœur et d'évaluation.
5. Procédé selon la revendication 4 selon lequel ladite pluralité de cœurs forme une liste ordonnée de cœurs, un cœur étant sélectionné de façon incrémentale dans ladite liste ordonnée de cœurs.
6. Procédé selon l'une quelconque des revendications précédentes selon lequel ladite étape d'identification d'un cœur comprend une étape de décision pour décider qu'une tâche 7f ne peut être placée sur un cœur Cp sur lequel ont été préalablement placées un ensemble de tâches 7~ s, s variant de 1 à (r- 1), que si, et seulement si, pour tout k appartenant à l'intervalle [1 , r],
∑ DL(Tk)
CEIL(-^■ WCET(T{)) < DL(Tk)
i=k
où CEILQ est une fonction retournant l'entier immédiatement supérieur à la valeur de l'argument, WCET(Tj) représente le pire temps d'exécution de la tâche 7/, DL(Tk) représente le temps de réponse imparti à la tâche Tk et δ(Τί) la période d'exécution de la tâche 7,·.
7. Programme d'ordinateur comprenant des instructions adaptées à la mise en œuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 6 lorsque ledit programme est exécuté sur un ordinateur.
8. Dispositif comprenant des moyens adaptés à la mise en œuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 6.
PCT/FR2013/052633 2012-11-08 2013-11-05 Procédé, dispositif et programme d'ordinateur de placement de tâches dans un système multi-coeurs Ceased WO2014072628A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1260587 2012-11-08
FR1260587A FR2997774B1 (fr) 2012-11-08 2012-11-08 Procede, dispositif et programme d'ordinateur de placement de taches dans un systeme multi-cœurs

Publications (1)

Publication Number Publication Date
WO2014072628A1 true WO2014072628A1 (fr) 2014-05-15

Family

ID=48170547

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2013/052633 Ceased WO2014072628A1 (fr) 2012-11-08 2013-11-05 Procédé, dispositif et programme d'ordinateur de placement de tâches dans un système multi-coeurs

Country Status (2)

Country Link
FR (1) FR2997774B1 (fr)
WO (1) WO2014072628A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150082314A1 (en) * 2012-04-18 2015-03-19 Nec Corporation Task placement device, task placement method and computer program
WO2018024581A1 (fr) * 2016-08-04 2018-02-08 Thales Procede et dispositif de distribution de partitions sur un processeur multi-coeurs
CN111381945A (zh) * 2018-12-29 2020-07-07 华为技术有限公司 任务迁移方法及电子设备
CN111480144A (zh) * 2017-12-19 2020-07-31 法国大陆汽车公司 多核机动车计算机管理多个任务的方法
CN113377542A (zh) * 2021-06-24 2021-09-10 东南大学 一种多核嵌入式系统的网络节点任务映射方法

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017080613A1 (fr) * 2015-11-13 2017-05-18 Telefonaktiebolaget Lm Ericsson (Publ) Formateur de système à nombreux cœurs pour une commande adaptative des ressources
EP3394747A1 (fr) 2015-12-21 2018-10-31 Telefonaktiebolaget LM Ericsson (publ) Dispositif d'entraînement de priorité pour système de traitement à coeurs multiples

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
AJIT RAMACHANDRAN ET AL: "Real-Time Scheduling methods for High Performance Signal Processing Applications on Multicore platform", MASTER REPORT, IDE 1260, 1 August 2012 (2012-08-01), School of Information Science, Computer and Electrical Engineering Halmstad University, Sweden, pages 1 - 62, XP055078097, Retrieved from the Internet <URL:http://hh.diva-portal.org/smash/get/diva2:549983/FULLTEXT01.pdf> [retrieved on 20130906] *
ALAN BURNS ET AL: "Delivering Real-Time Behaviour", 17 September 2007, DOMAIN MODELING AND THE DURATION CALCULUS; [LECTURE NOTES IN COMPUTER SCIENCE], SPRINGER BERLIN HEIDELBERG, BERLIN, HEIDELBERG, PAGE(S) 1 - 50, ISBN: 978-3-540-74963-9, XP019100284 *
B. BERNA: "Joint tasks and cache partitioning for real-time systems", MASTER THESIS, 5 June 2012 (2012-06-05), Université de Rennes I ENS Cachan, pages 1 - 34, XP055078069, Retrieved from the Internet <URL:http://dumas.ccsd.cnrs.fr/docs/00/72/51/72/PDF/Berna.pdf> [retrieved on 20130906] *
BARUAH S ET AL: "The Partitioned Scheduling of Sporadic Real-Time Tasks on Multiprocessor Platforms", PARALLEL PROCESSING, 2005. ICPP 2005 WORKSHOPS. INTERNATIONAL CONFEREN CE WORKSHOPS ON OSLO, NORWAY 14-17 JUNE 2005, PISCATAWAY, NJ, USA,IEEE, 14 June 2005 (2005-06-14), pages 346 - 353, XP010820985, ISBN: 978-0-7695-2381-1, DOI: 10.1109/ICPPW.2005.83 *
XU CHAO ET AL: "An Improved Static-Priority Scheduling Algorithm for Multi-Processor Real-Time Systems", MASTER OF SCIENCE THESIS IN SECURE AND DEPENDABLE COMPUTER SYSTEM, 1 June 2010 (2010-06-01), Chalmers University of Technology University of Gothenburg, pages 1 - 99, XP055078096, Retrieved from the Internet <URL:http://publications.lib.chalmers.se/records/fulltext/129034.pdf> [retrieved on 20130906] *

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150082314A1 (en) * 2012-04-18 2015-03-19 Nec Corporation Task placement device, task placement method and computer program
WO2018024581A1 (fr) * 2016-08-04 2018-02-08 Thales Procede et dispositif de distribution de partitions sur un processeur multi-coeurs
FR3054902A1 (fr) * 2016-08-04 2018-02-09 Thales Sa Procede et dispositif de distribution de partitions sur un processeur multi-coeurs
US11175963B2 (en) 2016-08-04 2021-11-16 Thales Method and device for distributing partitions on a multicore processor
CN111480144A (zh) * 2017-12-19 2020-07-31 法国大陆汽车公司 多核机动车计算机管理多个任务的方法
CN111480144B (zh) * 2017-12-19 2023-10-17 纬湃科技有限责任公司 多核机动车计算机管理多个任务的方法
US12073245B2 (en) 2017-12-19 2024-08-27 Vitesco Technologies GmbH Method for managing a plurality of tasks by a multicore motor vehicle processor
CN111381945A (zh) * 2018-12-29 2020-07-07 华为技术有限公司 任务迁移方法及电子设备
CN111381945B (zh) * 2018-12-29 2024-02-09 华为技术有限公司 任务迁移方法及电子设备
CN113377542A (zh) * 2021-06-24 2021-09-10 东南大学 一种多核嵌入式系统的网络节点任务映射方法
CN113377542B (zh) * 2021-06-24 2024-03-26 东南大学 一种多核嵌入式系统的网络节点任务映射方法

Also Published As

Publication number Publication date
FR2997774A1 (fr) 2014-05-09
FR2997774B1 (fr) 2021-10-29

Similar Documents

Publication Publication Date Title
WO2014072628A1 (fr) Procédé, dispositif et programme d&#39;ordinateur de placement de tâches dans un système multi-coeurs
US10839311B2 (en) Cognitive computing for servers and mobile devices
Farley et al. More for your money: exploiting performance heterogeneity in public clouds
FR3000578A1 (fr) Systeme et procede de calcul partage utilisant une fourniture automatisee de ressources informatiques heterogenes
FR3072798A1 (fr) Ordonnancement de taches dans un processeur a fils d&#39;execution multiples
EP3019957B1 (fr) Procede d&#39;optimisation de traitement parallele de donnees sur une plateforme materielle
FR2927438A1 (fr) Methode de prechargement dans une hierarchie de memoires des configurations d&#39;un systeme heterogene reconfigurable de traitement de l&#39;information
WO2013107819A1 (fr) Procédé d&#39;optimisation de traitement parallèle de données sur une plateforme matérielle.
US10341164B2 (en) Modifying computer configuration to improve performance
WO2011117528A1 (fr) Procede, programme d&#39;ordinateur et dispositif de validation d&#39;execution de taches dans des systemes informatiques evolutifs
WO2015091511A1 (fr) Authentification de code binaire
US20230068120A1 (en) Vector processing of decision trees to form inferences
US11640552B2 (en) Two stage training to obtain a best deep learning model with efficient use of computing resources
EP2850520B1 (fr) Procede de gestion d&#39;une execution de taches dans un systeme informatique
WO2016198762A1 (fr) Procédé et système de détermination d&#39;une configuration de serveurs cible pour un déploiement d&#39;une application logicielle
EP2667302B1 (fr) Procédé de gestion du démarrage d&#39;instances d&#39;applications sur des machines virtuelles d&#39;un réseau distribué
EP4055506B1 (fr) Detection d&#39;attaques a l&#39;aide de compteurs de performances materiels
FR3032289A1 (fr) Procede de commande de deploiement d&#39;un programme a executer dans un parc de machines
WO2018059897A1 (fr) Procede de gestion des taches de calcul sur un processeur multi-cœurs fonctionnellement asymetrique
FR2995424A1 (fr) Procede et dispositif de decompte du temps deporte pour unite de traitement dans un systeme de traitement de l&#39;information
EP3998555B1 (fr) Procédé de traitement de données par un réseau de neurones artificiels avec exécutions groupées d&#39;opérations individuelles pour éviter les attaques par canal auxiliaire, et système correspondant
EP2756398B1 (fr) Procede, dispositif et programme d&#39;ordinateur pour allouer dynamiquement des ressources d&#39;un cluster a l&#39;execution de processus d&#39;une application
EP2996036B1 (fr) Procédé de surveillance d&#39;une architecture applicative comportant une pluralité de services
FR3074939A1 (fr) Procede de gestion du systeme de fichiers d&#39;un terminal 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

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13805452

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13805452

Country of ref document: EP

Kind code of ref document: A1