EP4473396A1

EP4473396A1 - Software optimization method and device for numa architecture

Info

Publication number: EP4473396A1
Application number: EP22732026.4A
Authority: EP
Inventors: Enrico BINI; Alessandro DRUETTO; Andrea Grosso; Silvio BACCI; Marco DINATALE
Original assignee: Shenzhen Yinwang Intelligent Technology Co Ltd
Current assignee: Shenzhen Yinwang Intelligent Technology Co Ltd
Priority date: 2022-05-23
Filing date: 2022-05-23
Publication date: 2024-12-11
Also published as: WO2023227187A1; CN117441161A

Abstract

The present disclosure relates to a device and a method for software deployment on a multicore hardware platform. The platform comprises a plurality of cores and memories. The software comprises a plurality of functions sharing a plurality of variables. The device is configured to map the variables to the memories, and map the functions to the cores. The device may obtain the mapping of the variables and the function based on a BILP problem. Optionally, the device may be configured to bind the variables to the functions and allocate bound variables to a local memory of a corresponding core. In this way, the resources of the platform may be utilized more efficiently based on the joint mappings of the variables and functions.

Description

SOFTWARE OPTIMIZATION METHOD AND DEVICE FOR NUMA ARCHITECTURE

TECHNICAL FIELD

The present disclosure relates to the field of computer technology. For example, the present disclosure relates to a software optimization device and method for multi-core systems.

BACKGROUND

Multi-core (or multicore, multiprocessor) systems are widely used in various application scenarios for controlling real-time applications. Non-Uniform Memory Access (NUMA) is a computer memory architecture for a multicore system. FIG. 6 depicts an abstract model of the NUMA architecture, where each processor (also referred to as a core or as a central processing unit (CPU) in this disclosure) is directly coupled to a local random access memory (LRAM) of its own. Moreover, a plurality of processors may commonly share at least one global random access memory (GRAM). Unlike a uniform memory access architecture, wherein each processor has equal memory access time, a processor of the NUMA architecture can access its own LRAM faster than non-local memory. It is noted that the LRAM in this disclosure is different from a CPU cache, which is located inside a CPU and is not considered to be a memory accessible to other CPUs. In contrast, the LRAM in this disclosure is accessible to all CPUs that have a bus connecting to it. The non-local memory may comprise a memory local to another processor, or a global memory shared between multiple processors, e.g., the GRAM. The NUMA architecture provides for separate memory allocations for each processor (or a group of processors) in a multiprocessor system, thereby avoiding the performance degradation when several processors attempt to address the same memory.

For example, in the field of automotive, an electronic control unit (ECU) of a motor vehicle may typically comprise a plurality of cores. Modem vehicles are now capable of supporting many sophisticated functions, such as infotainment, navigation, security, advanced engine emission control, image detection-based services, and autonomous driving. Accordingly, the number of ECUs embedded in a vehicle is steadily increasing and can reach more than 100 ECUs. A standardized architecture named AUTomotive Open System Architecture (AUTOSAR) is widely adopted to standardize hardware and software architectures used in modern vehicles, with the aim of simplifying the development and integration of vehicle-related software functions. Since AUTOSAR 4.0, multicore support was introduced. For example, an Inter OS-Application Communicator (IOC) was proposed as a connection with the runtime environment (RTE) of the software architecture to map communication across cores and memories. By running the sophisticated functions on a multicore system, e.g., with the NUMA architecture, system performance can be improved. It is noted that functions of a plurality of ECUs can be implemented in a single ECU. For example, infotainment and navigation can be separately implemented on different ECUs, or jointly implemented on a same ECU.

SUMMARY

Currently, at the software level, variables (or labels) and functions (or runnables) may be mapped to a particular core for execution, e.g., based on a prediction algorithm. The NUMA architecture, however, is challenging in terms of predictability. Therefore, it is complex and time-consuming to map software functions and shared variables into cores.

For example, embedded system applications for multiprocessors may typically comprise thousands of functionalities communicating with each other in a well-connected pattern, using shared variables. It is far from trivial to map the functions and the variables to cores while assuring an optimal system performance.

For example, during software to hardware deployment phases, two correlated problems may be solved: the allocation of task functions to cores, and the placement of shared variables into memory. This may have a greater impact on NUMA platforms, since each core may have different fastest memory access times. An improper deployment may negatively affect the performance and the correctness of the hardware system. These two problems are also highly correlated, especially on the NUMA platforms. Depending on the variable placements in the memories and correlated function allocation to the cores, memory operations may incur additional stall cycles. Therefore, the time required to execute a given task function using a correlated variable can be quite different based on different solutions.

Typical software applications may comprise about thousands of functions and ten thousand shared variables. A target platform may comprise multiple cores, and multiple local and global RAMs. This makes it impossible to derive a solution for software deployment by hand or manually with guaranteed quality. A typical software deployment may comprise an allocation of functions to cores. One of the fundamental challenges in designing software for a multicore system is to ensure the effective use of available computing, communication, and memory resources. For example, in the AUTOSAR, as the IOC operates using a sender-receiver protocol, for example by implementing data memory buffers, finding a proper scheduling and corresponding execution of time-critical data transmissions may be a challenging task, for example, when attempting to implement a high degree of parallelism running on a plurality of cores. Moreover, the handling of communication between functions running in parallel on different cores becomes more difficult and can require a complicated software deployment process in order to ensure a safe and reliable operation of the overall system. For example, a vehicle controlling system may need to ensure that security functions are not to be blocked by other less urgent functions, such as navigation, etc.

In view of the above, this disclosure aims to increase the efficiency of automated software deployment. An objective is to ensure effective and/or optimal usage of available resources. Another objective of this disclosure is to provide a solution for automatically deriving the mapping of embedded applications onto a multicore system. Another objective of this disclosure is to propose a faster, more robust, and predictable software deployment/configuration solution for real-time applications.

These and other objectives are achieved by the solution of this disclosure as described in the independent claims. Advantageous implementations are further defined in the dependent claims.

A first aspect of this disclosure provides a device for mapping a plurality of functions sharing a plurality of variables to a multi-core computing system. The multi-core computing system comprises a plurality of cores and a plurality of memories. Each core is coupled to a memory of the plurality of memories. The device is configured to allocate each of the variables to one of the plurality of memories based on one or more characteristics of the plurality of memories, to obtain an allocation of the variables to the memories. The device is further configured to map the plurality of functions to the plurality of cores based on the allocation of the variables to the memories.

The software deployment in this disclosure may be understood as inferring a mapping (or allocation) of the functions to the cores and a mapping of the variables to the memories. By allocating shared variables to the memories, and mapping the functions to the cores in accordance with the allocation of the variables to the memories, the impact of the one or more characteristics of the plurality of memories on the shared variables is considered. This has the advantage that the overall performance of the multicore system can be improved due to the increased efficiency introduced by the allocation of the variables to the memories.

In an implementation form of the first aspect, the one or more characteristics of the plurality of memories may comprise an access time of each memory.

By considering the access time of each memory, variables that are more frequently used or that have a great impact on system performance can be allocated to a faster memory. The overall resource usage of the multi-core system can be optimized.

In an implementation form of the first aspect, the device may be further configured to partition the variables with respect to the plurality of functions, to obtain a binding relationship between the variables and the functions. The device may be further configured to map the plurality of functions to the plurality of cores based further on the binding relationship between the variables and the functions.

Optionally, the binding relationship between the variables and the functions may comprise a one-to-one relationship, or a many-to-one relationship. Optionally, each variable is bound to at most one function. A plurality of variables may be bound to a same function.

Optionally, for mapping the functions to the cores based further on the binding relationship between the variables and the functions, the device may be configured to determine a mapped core on which a function is executed, so as to save the most execution time of the function. When a function is mapped to a particular core, the device may be further configured to map one or more variables bound to the function in the binding relationship to a memory that is the closest or have the fastest access time with respect to the particular core.

By binding the variables to the functions, the allocation of the variables to the memory can be done together with the allocation of the functions to the cores. This has the advantage that available computing resources of the multiple cores and memory resources may be utilized more efficiently. In an implementation form of the first aspect, for partitioning the variables, the device may be configured to, for each function: obtain a frequency with which the function is to be executed; and associate one or more variables of the plurality of variables with the function based on the frequency of the function.

Optionally, the frequency with which the function is to be executed may be understood as a maximum execution frequency of the function. The maximum execution frequency of each function may be pre-defined or pre-configured. The maximum execution frequency may be provided as an input to the device, e.g., by the provider of each function.

Optionally, the device may be configured to calculate the number of execution cycles that can be saved in one invocation of each function in the assumption that each variable is mapped to a local memory, which is the closest memory to a core where each function is executed. The device may be configured to compare different assumptions and associate one or more variables with each function in a way that a maximum total execution time can be saved. This has the advantage that more resources can be allocated to functions that are more frequently executed. In this way, hardware resources can be efficiently utilized, and the overall system performance may be improved.

In an implementation form of the first aspect, the one or more characteristics of the plurality of memories may comprise a size of each memory, and the device is configured to associate each variable based further on a size of the variable and on the size of each memory.

By considering the size of each memory, the variables can be allocated based on the sizes of the variables and the size of each memory in a way that the total capacity of the memories is efficiently used. Moreover, it can be assured that no memory is overloaded.

In an implementation form of the first aspect, the device may be configured to map the functions to the plurality of cores based further on a quantity of cycles of each function required for executing the function on each core. In an implementation form of the first aspect, the device may be configured to map the functions to the plurality of cores in a way that each core is not overloaded.

Optionally, the plurality of cores may have different performance capabilities and power consumptions. For example, the plurality of cores may comprise at least one high-performance core and at least one low power consumption core. The device may be configured to map a function that has more execution cycles to the high-performance core, and map a function that has fewer execution cycles to the low power consumption core.

In an implementation form of the first aspect, the device may be further configured to combine two or more functions of a same core into a task based on release patterns of the two or more functions of the same core.

Optionally, the combined two or more functions shall not self-suspend. That is, one function does not need to wait for another function to complete.

In an implementation form of the first aspect, the device may be further configured to assign a priority to each task, so as to minimize resource utilization of each core.

This can ensure that limited and/or better resources (e.g., faster CPU and faster memory) can be allocated to a task of high priority. Thus, the system performance can be further improved by ensuring the stability of tasks of high priorities.

In an implementation form of the first aspect, the device may be configured to determine the priority of each task based on a deadline of the task.

Optionally, the deadline can be understood as a specific period of time within which the task needs to be completed.

An advantage of using the deadline is that ensure that each task's specific timing constraints can be met.

In an implementation form of the first aspect, the device may be configured to determine the priority of each task based further on interferences caused by one or more further tasks. Optionally, the device may assign a task that can cause greater interferences with a lower priority. Thus, the task causing greater interferences can be executed after other tasks are completed, so as to ensure a smooth system performance. In this way, the interferences between tasks can be reduced.

Optionally, the device may use the interferences as a constraint when determining the allocations of the variables and the functions.

In an implementation form of the first aspect, the device may be configured to determine the priority of each task based further on a blocking time during which the task is in a wait state.

Optionally, the device may use the blocking time as a constraint when determining the allocations of the variables and the functions.

In an implementation form of the first aspect, for mapping the plurality of functions to the plurality of cores, the device may be configured to group two or more functions into a single cluster function, wherein the two or more functions share one or more common partitioned variables, and map the single cluster function to a core of the plurality of cores.

Optionally, the device may be further configured to group two or more of the runnables and their bound labels into the single cluster function. The single cluster function may be of customizable sizes. In this disclosure, this scheme may be referred to as hierarchical clustering.

By using the single cluster function (or simply, cluster) as a basic unit for mapping the functions to the cores, the number of parameters involved in the optimization of the mapping can be reduced. The advantage of clustering is that the tractability of the optimization of the software deployment can be ensured.

In an implementation form of the first aspect, the plurality of memories may comprise a global memory (or GRAM) and a plurality of local memories (or LRAMs). The global memory is shared by the plurality of cores, and each local memory is directly coupled to a core of the plurality of cores. Optionally, after binding one or more variables to a function, the device may be configured to map the function to a core. The device may be further configured to map the one or more bound variables to an LRAM of the core. The mapping of the one or more bound variables may be done implicitly, which is a result of the binding relationship.

Optionally, the device may be further configured to allocate the one or more common partitioned variables associated with the cluster function to a local memory directly coupled to the mapped core.

In an implementation form of the first aspect, the plurality of functions may be a plurality of runnables of a software component for a run time environment, and the plurality of shared variables may be inputs to the software component.

A second aspect of this disclosure provides a method for mapping a plurality of functions sharing a plurality of variables to a multi-core computing system. The multi-core computing system comprises a plurality of cores and a plurality of memories. Each core is coupled to a memory of the plurality of memories. The method is executed by a device and comprises the following steps: allocating, by the device, each of the variables to one of the plurality of memories based on one or more characteristics of the plurality of memories, to obtain an allocation of the variables to the memories; and mapping, by the device, the plurality of functions to the plurality of cores based on the allocation of the variables to the memories

In an implementation form of the second aspect, the one or more characteristics of the plurality of memories may comprise an access time of each memory.

In an implementation form of the second aspect, the method may further comprise: partitioning, by the device, the variables with respect to the plurality of functions, to obtain a binding relationship between the variables and the functions; and mapping, by the device, the plurality of functions to the plurality of cores based further on the binding relationship between the variables and the functions. In an implementation form of the second aspect, the step of partitioning the variables may comprise: for each function: obtaining, by the device, a frequency with which the function is to be executed; and associating, by the device, one or more variables of the plurality of variables with the function based on the frequency of the function.

In an implementation form of the second aspect, the one or more characteristics of the plurality of memories may comprise a size of each memory, and the method may comprise associating, by the device, each variable based further on a size of the variable and on the size of each memory.

In an implementation form of the second aspect, the method may comprise mapping the functions to the plurality of cores based further on a quantity of cycles of each function required for executing the function on each core.

In an implementation form of the second aspect, the method may comprise mapping the functions to the plurality of cores in a way that each core is not overloaded.

In an implementation form of the second aspect, the method may comprise combining, by the device, two or more functions of a same core into a task based on release patterns of the two or more functions of the same core.

In an implementation form of the second aspect, the method may further comprise assigning, by the device, a priority to each task, so as to minimize resource utilization of each core.

In an implementation form of the second aspect, the method may further comprise determining, by the device, the priority of each task based on a deadline of the task.

In an implementation form of the second aspect the method may further comprise determining, by the device, the priority of each task based further on interferences caused by one or more further tasks. In an implementation form of the second aspect, the method may comprise determining, by the device, the priority of each task based further on a blocking time during which the task is in a wait state.

In an implementation form of the second aspect, the step of mapping the plurality of functions to the plurality of cores may comprise grouping, by the device, two or more functions into a single cluster function, and mapping the single cluster function to a core of the plurality of cores. The two or more functions may share one or more common partitioned variables.

In an implementation form of the second aspect, the plurality of memories may comprise a global memory and a plurality of local memories. The global memory is shared by the plurality of cores, and each local memory is directly coupled to a core of the plurality of cores. The method may further comprise allocating the one or more common partitioned variables associated with the cluster function to a local memory directly coupled to the mapped core.

In an implementation form of the second aspect, the plurality of functions may be a plurality of runnables of a software component for a run time environment, and the plurality of shared variables may be inputs to the software component.

The method of the second aspect and its implementation forms may achieve the same advantages and effects as described above for the device of the first aspect and its implementation forms.

A third aspect of this disclosure provides a computer program comprising instructions which, when the program is executed by a computer, cause the computer to perform the method according to the second aspect or any of its implementation forms.

A fourth aspect of this disclosure provides a non-transitory storage medium storing executable program code which, when executed by a processor, causes the method according to the second aspect or any of its implementation forms to be performed.

It has to be noted that all devices, elements, units, and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.

BRIEF DESCRIPTION OF DRAWINGS

The above-described aspects and implementation forms will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which

FIG. 1 shows an example of a device according to this disclosure;

FIG. 2 shows an example of variable partitioning according to this disclosure;

FIG. 3 shows an example of hierarchical clustering according to this disclosure;

FIG. 4 shows a diagram of a method according to this disclosure;

FIG. 5 shows a diagram of a further method according to this disclosure; and

FIG. 6 shows an example of a NUMA architecture.

DETAILED DESCRIPTION OF EMBODIMENTS

The present disclosure generally relates to a software deployment optimization for multicore computing systems (or simply, multicore systems). The present disclosure may be applied to various multicore systems, such as the NUMA architecture exemplarily depicted in FIG. 6.

FIG. 1 shows an example of a device 100 according to the present disclosure.

The device 100 may be a software deployment tool, which is adapted to map a plurality of functions sharing a plurality of variables to a multi-core computing system. The multi-core computing system comprises multiple cores and multiple memories. Each core is directly coupled to a memory, which may be referred to as an LRAM. Optionally, there may be at least one shared memory that is connected to a global system bus and is shared by a part or all of the cores. The shared memory may be referred to as a GRAM. For example, as depicted on the right-hand side of FIG. 1, the multi-core computing system may comprise two cores (core 1, core 2) and three memories (LRAM 1, LRAM 2, GRAM). LRAM 1 and LRAM 2 are directly coupled to core 1 and core 2, respectively, while GRAM is globally shared among core 1 and core 2. The memories may be of different characteristics, such as but not limited to access times and sizes. For example, access times to memory are about one order of magnitude shorter from cores which are directly connected to them.

FIG. 1 on its left-hand side depicts an abstract example of functions to be executed on the multicore computing system and variables shared among the functions. In this disclosure, the functions may be referred to as runnables. The variables may be understood as read and written data associated with each function. In this disclosure, the variables may be referred to as labels.

Optionally, the runnables may be part of one or more software components. The software components may be architectural elements that provide and/or require interfaces and are connected to each other in order to fulfill architectural responsibilities. Optionally, the software components may be for a run time environment, such as an AUTOSAR.

From FIG. 1, it can be seen that one variable may be dedicated to only one function (e.g., variable c and function 2), or may be used by two or more functions. Correspondingly, one function may have only one variable (e.g., function 1 and variable a), or may have two or more variables.

The device 100 is configured to allocate each of the variables to one of the plurality of memories based on one or more characteristics of the plurality of memories, to obtain an allocation of the variables to the memories. The device 100 is further configured to map the plurality of functions to the plurality of cores based on the allocation of the variables to the memories.

It is noted that the step of “mapping the plurality of functions to the plurality of cores based on the allocation of the variables to the memories” in the present disclosure may alternatively be understood as “mapping the plurality of functions to the plurality of cores in combination with the allocation of the variables to the memories”. That is, the device takes the one or more characteristics of the plurality of memories into consideration for mapping the variables. Since the functions share the variables, the mapping of the variables and the mapping of the functions may mutually affect each other. That is to say, the device 100 may be further configured to map the variables to the memories based on the mapping of the functions to the cores. The whole process may be understood as an optimization procedure until a cost function is fulfilled, when the device 100 may obtain an optimal mapping of the variables and an optimal mapping of the functions.

This has the advantage that the resource usage of the multicore system can be optimized, or a slack can be maximized.

Optionally, the device 100 may be configured to use binary integer linear programming (BILP) to determine an optimal mapping of the functions to the cores and an optimal mapping of the variables to the memories. In this way, the resource usage of the multicore system can be further optimized through the BILP.

Optionally, the device 100 may be configured to obtain application definitions of the functions (or software components) as one input for determining software deployment. For example, the device 100 may be configured to obtain information about a set of functions, and information on read and written data (e.g., variables, labels) of each function, such as data size, latency requirement, dependency, etc.

Optionally, the device 100 may be configured to obtain a specification of the multicore system as one input for determining software deployment. The specification of the multicore system may comprise, for example, the number of cores and memories, the hierarchy of the memories, and information on costs for local (e.g., LRAM) and remote memory (e.g., GRAM) accesses.

Optionally, the device 100 may be configured to obtain real-time properties of the functions (or software components) with respect to the multicore system as one input for determining software deployment. For example, the real-time properties may comprise execution time for each function on an assumption that its variables are in GRAM, or in a memory with the largest access time; and a gain of execution cycles by one invocation of the function if its variables are in its LRAM. The real-time properties may be estimated or calculated by using existing runtime performance analysis tools commonly known in the field.

FIG. 2 shows an example of variable partitioning according to the present disclosure. The variable partitioning may be referred to as label binding. Optionally, the device 100 of FIG. 1 may be configured to partition the variables with respect to the plurality of functions, to obtain a binding relationship between the variables and the functions. The device 100 may be further configured to map the plurality of functions to the plurality of cores based further on the binding relationship between the variables and the functions.

The variables (or labels) may represent portions of memories (possibly as small as a single bit) used by the runnables to communicate with each other. It is preferable to allocate the labels to available memory areas, which may be any one of the LRAMs or the GRAM, in an appropriate manner to increase communication efficiency. The impact of variable partitioning (or label binding) is on the execution time of the runnables. In fact, access times to the memories are about one order of magnitude shorter from cores that are directly connected to them.

In FIG. 2, seven runnables 1-7 and eleven labels a-k are exemplarily shown. One runnable may share one or more labels with one or more other runnables. In a typical embedded applications scenario, for instance, in the field of automotive, there may be a thousand runnables and ten thousand labels. Hence, a unique formulation of the joint mapping of the labels and runnables is not easily tractable. Therefore, before mapping the functions to the cores, the device 100 may be configured to bind the labels to the runnables as an initial step. A general principle of label binding is that, when runnable i is mapped to core k, then all the labels bound to runnable i may be mapped to a memory local to core k, optionally on the condition that the local memory is not overloaded.

An example of a determination of the disjoint subsets L_i of L is graphically represented on the right-hand side of FIG. 2. It can be seen that each label is bounded to only one runnable, which is represented by a solid usage line. Optionally, the bounded label may still be accessible by other runnables but not bound to other runnables, which is represented by a dashed usage line. That is, the binding relationship between the variables and the functions may be disjoint, which means that each label may be bound to at most one runnable.

The label binding problem may be formulated as follows. The device 100 may be configured to obtain information about a set of N runnables and a set of L labels as an input. For each pair (i, 1) ∈ N x L, the device 100 may be configured to: if label I is used by runnable i, determine a value of g_i,l, wherein g_i,l represents a gain of execution time on one invocation of runnable i when label I is allocated to a memory which is local to a core where runnable i executes, if the label I is not used by runnable i, set g_i,l = 0.

N, L, i, j, and I are positive integers. The gain g_i,l may depend on the size of label I and on the number of accesses to label I by one invocation of runnable i.

For each runnable i ∈ N, f_i represents the maximum frequency of execution of the runnable. The device 100 may be configured to obtain the maximum frequency of execution of each runnable as one input, e.g., from the software provider.

For the purpose of label binding, the following notions are introduced:

An aim of binding labels to runnables is to minimize resource usage. Assuming each runnable may be executed with a frequency f_i, a metric to be maximized may be formulated as follows:

The rationale of the cost function in Equation 2 is to assign label I to runnable i to obtain a binding relationship between the labels and the runnables, so that the multicore system may benefit the most in terms of saving processing time. Equations 1 and 2 may ensure the largest utilization gain represented by execution time saving multiplied by the frequency of execution ft-

Denoting S_L as the size (or amount) of local memory (e.g., LRAM) assigned to the runnable i, and Si as the size of label /, then the device 100 may be further configured to apply the following constraint: This may ensure that the total memory local to the runnable i is not overloaded. Moreover, the device 100 may be further configured to apply the following constraint: ) which is to ensure that the total size of local memory is not overloaded, wherein S_k ^ore denotes the total size of the local memory of core k.

The device may be further configured to ensure that a label is bound to at most one runnable by applying: After an optimal solution is found, a disjoint subset Li is defined by comprising all labels assigned to the runnable i.

Optionally, the labels I may be bound to the runnables following the next rules:

, , , , , , .

1. labels are sorted by decreasing

2. labels are selected to be bound to runnables following the ordering defined above, until the constraint (4) is reached

3. each selected label /, is bound to the runnable j such that f_jg_i,l = max_if_jg_i,l

The device 100 is further configured to map the functions (or runnables) to the cores (or CPUs). Optionally, the device 100 may be configured to obtain an optimal solution for mapping the runnables to the CPUs based on a BILP problem. For mapping N runnables over M CPUs, variables y_{i k} may be modelled with the following notion:

Each runnable shall be mapped over one CPU only. This may be guaranteed by the following constraint:

Optionally, the device 100 may be further configured to determine whether or not any pair or runnables is mapped onto the same CPU. If two runnables share the same CPU, then the communication between them may be more efficient through the LRAM of the same CPU, which is faster than through the GRAM. To implement this condition into the BILP problem, variables may be modeled with the following notion:

Moreover, if two runnables i and j are bound to the same CPU k, then must be equal to

1, which is enforced by:

Before further describing the constraints of the mapping of the runnables to the CPUs, the following notations are introduced.

Firstly, denotes the execution cycles of runnable i, assuming that: all labels in L_i bound to runnable i as described previously are stored in LRAM and then have a faster access; and all other labels are stored in GRAM.

Secondly, ΔC_i,j denotes the execution cycles saved by one invocation of runnable i if runnable j executes over the same CPU (such a condition is fulfilled by ). This happens, if runnable i uses any label in L_i . ΔC_i,j is written as a function of the gains g_i,l previously introduced, which may be as follows

Thirdly, C_i,k ≥ 0 represents the number of execution cycles required by runnable i over CPU k, which is defined as follows:

It is noted that, if runnable i is not mapped to CPU k, C_i,k is equal to zero.

Optionally, when the device 100 may be configured partition the labels with respect to the runnables, the partitioned one or more labels bounded to runnable i may be allocated to the LRAM of runnable i. A memory size S_i may be needed in the LRAM for storing the partitioned one or more labels. If the available size of the LRAM of runnable I is denoted by , then the constraint of limited size of the LRAM may be formulated as:

Optionally, the device 100 may be configured not to overload any core; this corresponds to the maximum utilization constraint as follows:

By mapping the runnables to the cores based on the BILP problem, an advantage may be that core utilization may be minimized based on a general or per-core metric. That is, a mapping may be driven by the maximization of the slack on all cores.

Optionally, the device 100 may be further configured to combine two or more functions of a same core into a task based on release patterns of the two or more functions of the same core. For example, if two runnables have the same release pattern and do not self-suspend, the two runnables are mapped to the same CPU, then they may be aggregated into the same task.

The aggregation of runnables may be formulated as follows.

A set of tasks is denoted by τ . A set of runnables of runnables to form task I is denoted by The subsets in form a partition of in a way that every runnable belongs to one and only one subset

The equivalence relation ~ over pairs of runnables encodes the aggregation of runnables. That is, i~j denotes that “the two runnables i and j have the same release pattern and none of them self-suspends”. The runnables in belonging to the same task I may be defined as follows:

, with being the variables representing the optimal mapping.

Based on Equation 11, execution cycles of task I ∈ are as follows:

A minimum interarrival time (or a period) of task I ∈ τ is:

It is noted that all runnables in the same task may have the same period.

A deadline of task I ∈ τ is: A partition of tasks over M CPUs may be defined as follows:

It is noted that if y_i,k = 1 for some runnable , then y_{i k} = 1 for all

Optionally, the device 100 may be further configured to assign a priority to each task, so as to minimize resource utilization of each core.

For assigning priorities to the tasks, priorities are comparable only within the same CPUs, since scheduling decisions within CPUs are independent. Hence, the assignment of priorities to tasks in must be performed For brevity, is omitted in all equations related to priority assignment.

Priorities among tasks yield an ordering. To be more formal, the ordering of tasks by priority is a total order among disjoint subsets of tasks, with the subsets of tasks representing the tasks with the same priority. If the cardinality of all subsets is 1, then all tasks have a distinct priority and the ordering is total.

The priority assignment may be modeled by the following variables

The relationship among the tasks modelled by the variables is a partial order among tasks. The order is partial, because tasks may possibly have the same priority. Constraints on variables x^J enforce the property of an ordering. The constraints comprise: reflexivity, which is enforced implicitly by omitting the variable as it would always be

- transitivity, which is enforced by the following constraint antisymmetry, which is enforced explicitly by

It is noted that if tasks are required to all have a distinct priority, so the priority ordering is total, then it is sufficient to replace the aforementioned constraint of antisymmetry with Instead, if tasks are allowed to have the same priority, it may need to enforce explicitly an equivalence among the tasks having the same priority. In fact, not all partial orders correspond valid priority assignments.

To enforce the equivalence among tasks with non-comparable priority, the following variable encoding the two tasks i and j having the same priority is defined:

It is noted that the parameters in the above functions of x^ are not independent, as they are defined by previous functions. Still, it is convenient to introduce them to have more compact notations for the constraints to be defined in the following.

The equivalence among pairs of tasks i and j with is enforced as follows: reflexivity is enforced implicitly by omitting the variables symmetry is enforced implicitly by defining only when i < j; and

- transitivity is enforced explicitly by:

Optionally, the device 100 may be configured to assign a limited number of priorities to the tasks. For example, if the number of priorities is limited by a number P, then this constraint can be enforced by limiting the sum of variables. For example, if P = 2, then: which means that if runnable i has a higher priority than any runnable j, the runnable j cannot have priority higher than any other runnable I. Otherwise, three priority levels would be needed.

Optionally, every runnable may be a deadline D_i. If it is not set explicitly, an implicit deadline of the runnable i is equal to its period T_i defined in Equation 18. The deadline constraint of all tasks on a given CPU is written as:

C_i + Ii + B_i ≤ D_i (26) wherein:

C_i denotes the worst-case execution time of the runnable itself,

I_i denotes the interference caused by higher or same priority runnables, and

B_i denotes the blocking time, which is the time spent by runnable i waiting for some resources (e.g., one or more labels used by other runnables) to become available.

The execution time C_i of the runnable i is given by Equation 17. The interference I_i experienced by runnable is written as the following linear combination of decision variables:

The variables are equal to 1, if and only if task i has the same priority as task j. Similarly, the variables are equal to 1, if and only if task i has a higher priority than task j . In Equation 29, two contributions to the interference are introduced.

The first one is the execution of tasks with the same priority. Tasks with the same priority are scheduled in first-in-first-out (FIFO) order, this contribution is equal to the sum of the execution cycles of all tasks with the same priority, except task i itself. The second one is the execution of tasks with higher priority. An over-approximation of the interference is used here, which fully accounts for the execution cycles of all releases of higher priority tasks in the interval [0, D_i) . The exact expression of the interference It requires the evaluation of the minimum among several linear expressions. Such a minimum, however, breaks the convexity of the feasible region, which makes the optimization intractable. Hence, the over-approximation for I_i of Equation 29 is used for the purpose of assigning priorities only.

The blocking time B_i is the time spent by task i in a “waiting” state, which may be caused by an attempt to access a shared resource locked by any lower priority task within the same CPU or any task executing on other CPUs. The waiting state may also be caused by an invocation of a blocking system call such as a remote procedure call. The blocking time B_L is a linear function of the decision variables, hence it is well suited for the purpose of the priority assignment problem.

Optionally, the device 100 may determine an optimization goal. The optimization goal is to maximize the extensibility of the application deployment, which may be understood as having as much “space” as possible to accommodate future new functionalities. Based on the constraints previously introduced, for each constraint the following normalized form is proposed: linear combination of the binary variables ≤ 1. (28)

Then, an additional variable z representing “space” reserved for future extensions is defined, and then by modifying all constraints as follows linear combination of the binary variables + a · z < 1 (29) wherein a G [0,1] represents the constraint-dependent amount of slack desired in the constraint. A larger value of a represents the goal of having more slack in the constraint.

The goal of the optimization problem then is:

“maximize z” (30) The found optimal z* represents the amount of slack in the constraints.

The aforementioned optimization problem may need to consider a large amount of parameters and the computational cost required for the evaluation of an optimum can be huge. Therefore, the device 100 may be configured to perform hierarchical clustering on the runnables and the labels.

The device 100 may be configured to implement a greedy procedure in order to group runnables that are very likely to be on the same core in an optimal assignment. The device 100 may be configured to evaluate this likelihood when determining the groups maximization based on Equation 2.

Grouping the runnables can be easily achieved, for example, by means of hierarchical clustering, especially with an agglomerative approach that can build increasingly larger groups of runnables from the bottom up. Optionally, the distance concept is substituted by a similarity measure, with a value equal to the gain two runnables would have if ran on the same core and their assigned labels were located in the local memory of the same core. This similarity concept can be automatically extended to a case when runnables to be joined are already groups of runnables, since all labels assigned to the runnables of the group participant to the evaluation of the joint similarity value.

An advantage of using hierarchical clustering is that one builds the entire hierarchical tree during the procedure, and this tree can be cut into any level of choice, hence having an algorithm that groups runnables and partitions them in any number of clusters. This can be further added with a parallel evaluation of cycles and memory required by every cluster to run, hence providing a stopping (or “branching”) condition for the clustering procedure when, for example, the memory required for one cluster exceeds a predefined amount.

Since hierarchical clustering is a greedy, non-exact approach, it can help reduce the number of runnables before feeding them to the optimization problem. Therefore, the complexity of the optimization problem can be reduced. FIG. 3 shows an example of hierarchical clustering according to this disclosure. The device 100 may be configured to group runnables 1-7 into a plurality of clusters 310, 311, 320, 321, 322. Cluster 311 is a branch (or child) of cluster 310, and clusters 321 and 322 are branches of cluster 320. The device 100 may be configured to adjust the number of clusters according to the complexity of the optimization problem. For example, if after evaluation, a maximum of three clusters are allowed, then the device 100 may use clusters 310, 321, and 320 as basic units for the optimization.

FIG. 4 shows a diagram of a method 400 according to this disclosure. The method 400 is performed by a device for mapping a plurality of functions sharing a plurality of variables to a multi-core computing system. The multi-core computing system comprises a plurality of cores and a plurality of memories, wherein each core is coupled to a memory of the plurality of memories. The method 400 comprises the following steps:

Step 401: allocating, by the device, each of the variables to one of a plurality of memories based on one or more characteristics of the plurality of memories, to obtain an allocation of the variables to the memories; and

Step 402: mapping the plurality of functions to the plurality of cores based on the allocation of the variables to the memories.

The steps of the method 400 may share the same functions and details from the perspective of FIG. 1-3 described with respect to the device 100 above. Therefore, the corresponding method implementations are not described again at this point.

FIG. 5 shows a diagram of a method 500 according to this disclosure. The method 500 is based on the method 400 of FIG. 4 and comprises the following steps:

Step 501 : binding, by the device of FIG. 4, the labels to the runnables;

Step 502: mapping, by the device, the runnables to the cores;

Step 503 : mapping, by the device, the labels to the memories;

Step 504: mapping, by the device, the runnables to tasks;

Step 505: assigning, by the device, priorities to the tasks;

Step 506: generating, by the device, constraints of a software deployment optimization problem; and

Step 507: solving, by the device, the optimization problem based on an objective function. Step 501 is optional and may share the same functions and details from the perspective of the label binding problem addressed in FIG. 1-3 and Equations 1-5.

Step 502 corresponds to Step 402 of FIG. 4 and may share the same features and details from the perspective of FIG. 1-3 described with respect to Equations 6-13.

Step 503 corresponds to Step 401 of FIG. 4 and may share the same features and functions likewise. It is noted that there may be no strict order for performing steps 502 and 503.

Step 504 is optional and may share the same features and details from the perspective of FIG. 1-3 described with respect to Equations 14-18.

Step 505 is optional and may share the same features and details from the perspective of FIG. 1-3 described with respect to Equations 19-25.

Step 506 may share the same features and details from the perspective of FIG. 1-3 described with respect to Equations 26-27.

Step 507 may share the same features and details from the perspective of FIG. 1-3 described with respect to Equations 28-30.

In the present disclosure, a mapping of labels to memories is proposed in addition to mapping functions to cores. It has the advantage that the resource usage of the computing system can be optimized. This disclosure can be applied to embedded application deployment on a system of multi-core architecture. The embedded application may comprise software components, which comprise runnables executed in a run time environment. The runnables are resource-sensitive. By mapping shared labels properly into memories, either an LRAM or a GRAM, based on the BILP problem, the overall system performance can be improved.

Optionally, by binding the labels to the runnables and using hierarchical clustering, the number of parameters used in solving the BILP problem can be reduced about one order of magnitude. This can make the BILP problem tractable. Optionally, by assigning priorities to tasks formed by a group of runnables mapped to the same core, the slack of all cores can be maximized.

A further advantage of this disclosure is that the proposed equations in this disclosure are all expressed as linear constraints among the parameters. Therefore, it reduced the complexity of the BILP problem.

It is noted that the method for performing the software deployment disclosed in this disclosure may be implemented in any programming language and may be adapted to be executed on any hardware platform.

This disclosure can be applied to any multicore or heterogeneous hardware platforms, where real-time guarantees shall be respected. This disclosure may have the following advantages.

By using optimization techniques, more guarantees can be ensured about the properties derived by the software application deployment. Moreover, available resources, e.g., CPU resources and memory resources, are more efficiently used. The slack of the resources may be maximized. The real-time (or dependability) guarantees can be ensured, e.g., in case of failures. Further, resources can be reserved for future new functionalities and the same configuration can be reused.

This disclosure can be applied to any software deployment tool, such as an AUTOSAR system configuration tool. This disclosure may help to improve the quality of products and enable automation of the software deployment process.

In the present disclosure, the device may comprise a processor or processing circuitry (not shown) configured to perform, conduct or initiate the various operations of the device described herein. The processing circuitry may comprise hardware and/or the processing circuitry may be controlled by software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as applicationspecific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multi-purpose processors. The device may further comprise memory circuitry, which stores one or more instruction(s) that can be executed by the processor or by the processing circuitry, for example, under the control of the software. For instance, the memory circuitry may comprise a non-transitory storage medium storing executable software code which, when executed by the processor or the processing circuitry, causes the various operations of the device to be performed. In one embodiment, the processing circuitry comprises one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the device to perform, conduct or initiate the operations or methods described herein.

The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed matter, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

1. A device (100) for mapping a plurality of functions sharing a plurality of variables to a multi-core computing system, wherein the multi-core computing system comprises a plurality of cores and a plurality of memories, wherein each core is coupled to a memory of the plurality of memories, and wherein the device is configured to: allocate each of the variables to one of the plurality of memories based on one or more characteristics of the plurality of memories, to obtain an allocation of the variables to the memories; and map the plurality of functions to the plurality of cores based on the allocation of the variables to the memories.

2. The device (100) according to claim 1, wherein the one or more characteristics of the plurality of memories comprise an access time of each memory.

3. The device (100) according to claim 1 or 2, further configured to: partition the variables with respect to the plurality of functions, to obtain a binding relationship between the variables and the functions; and map the plurality of functions to the plurality of cores based further on the binding relationship between the variables and the functions.

4. The device (100) according to claim 3, wherein for partitioning the variables, the device is configured to, for each function: obtain a frequency with which the function is to be executed; and associate one or more variables of the plurality of variables with the function based on the frequency of the function.

5. The device (100) according to claim 4, wherein the one or more characteristics of the plurality of memories comprise a size of each memory, and the device is configured to associate each variable based further on a size of the variable and on the size of each memory.

6. The device (100) according to any one of claims 1 to 5, wherein the device is configured to map the functions to the plurality of cores based further on a quantity of cycles of each function required for executing the function on each core.

7. The device (100) according to any one of claims 1 to 6, wherein the device is configured to map the functions to the plurality of cores in a way that each core is not overloaded.

8. The device (100) according to any one of claims 1 to 7, further configured to combine two or more functions of a same core into a task based on release patterns of the two or more functions of the same core.

9. The device (100) according to claim 8, further configured to assign a priority to each task, so as to minimize resource utilization of each core.

10. The device (100) according to claim 9, configured to determine the priority of each task based on a deadline of the task.

11. The device (100) according to claim 10, configured to determine the priority of each task based further on interferences caused by one or more further tasks.

12. The device (100) according to claim 11, configured to determine the priority of each task based further on a blocking time during which the task is in a wait state.

13. The device (100) according to any one of claims 3 to 12, wherein for mapping the plurality of functions to the plurality of cores, the device is configured to: group two or more functions into a single cluster function, wherein the two or more functions share one or more common partitioned variables; and map the single cluster function to a core of the plurality of cores.

14. The device (100) according to claim 13, wherein the plurality of memories comprises a global memory and a plurality of local memories, wherein the global memory is shared by the plurality of cores, and each local memory is directly coupled to a core of the plurality of cores, and wherein the device is further configured to allocate the one or more common partitioned variables associated with the cluster function to a local memory directly coupled to the mapped core.

15. The device (100) according to claim any one of claims 1 to 14, wherein the plurality of functions are a plurality of runnables of a software component for a run time environment, and the plurality of shared variables are inputs to the software component.

16. A method (400) for mapping a plurality of functions sharing a plurality of variables to a multi-core computing system, wherein the multi-core computing system comprises a plurality of cores and a plurality of memories, wherein each core is coupled to a memory of the plurality of memories, and wherein the method comprises: allocating (401), by a device, each of the variables to one of the plurality of memories based on one or more characteristics of the plurality of memories, to obtain an allocation of the variables to the memories; and mapping (402), by the device, the plurality of functions to the plurality of cores based on the allocation of the variables to the memories.

17. A computer program product comprising instructions which, when the program is executed by a second computer, cause the second computer to perform the method according to claim 16.