Multi-core processing with software-based scheduler and planner

Abstract

A multi-core processing system includes a processing unit having a plurality of different processing cores; and a memory coupled to the processing unit, the memory including instructions defining modules executable by the processing unit. The module includes an application configured to execute one or more processes at runtime, wherein each process is defined by one or more user-level threads. The module also includes a software scheduler configured to schedule execution of the user-level threads on the processing core. The software scheduler accesses hardware limit metrics and / or real-time performance metrics associated with individual processing cores monitored during runtime. The software scheduler dynamically allocates the processing cores to the user-level threads based on monitored hardware limit metrics and / or real-time performance metrics associated with the individual processing cores. Based on the allocation, the user-level threads are dispatched for execution on the respective processing cores.

Description

Technical Field

[0001] The present disclosure generally relates to scheduling software tasks on a multi-core processing system. Background Art

[0002] Real-time systems such as industrial control systems typically include a real-time operating system, which may include a scheduler for organizing tasks (e.g., including one or more threads) to execute on multiple hardware computing nodes (e.g., CPU cores) to meet the real-time requirements of tasks based on time and resource constraints. Existing scheduling methods (e.g., round-robin scheduling, priority scheduling, etc.) are mainly based on software and functional requirements and do not consider hardware physical constraints. When using a traditional real-time scheduler to achieve real-time performance, user-level software may not be aware of hardware constraints (e.g., thermal limits of CPU cores), which may directly lead to lower-level CPU hardware / firmware shutdowns, potentially resulting in a complete failure of the software. This can be particularly catastrophic if the software is used for critical control or safety applications. Summary of the Invention

[0003] Briefly, aspects of the present disclosure are directed to multi-core processing systems and methods that include software-based dynamic schedulers and planners based on processor hardware constraints and / or real-time performance requirements.

[0004] According to a first aspect of the present disclosure, a multi-core processing system is provided. The multi-core processing system includes a processing unit and a memory. The processing unit includes a plurality of different processing cores. The memory is coupled to the processing unit and includes instructions defining modules executable by the processing unit. The modules include an application program and a software scheduler. The application program is configured to execute one or more processes at runtime, each process being defined by one or more user-level threads. The software scheduler is configured to schedule the execution of user-level threads on the processing cores. The software scheduler is configured to access hardware limit metrics and / or real-time performance metrics associated with individual processing cores monitored during runtime. The software scheduler is configured to dynamically allocate processing cores to user-level threads based on the monitored hardware limit metrics and / or real-time performance metrics associated with individual processing cores. The software scheduler is configured to dispatch user-level threads for execution on the corresponding processing cores based on the allocation.

[0005] Other aspects of the present disclosure are directed to corresponding methods for allocating resources to applications running on a multi-core processing system, and to computer program products that include instructions executable by a multi-core processing system to implement such methods.

[0006] According to another aspect of the present disclosure, a method for allocating resources in a multi-core processing system by constructing a software task planner during a debugging phase is provided. The method includes, in multiple iterations: (a) testing and running one or more applications on the multi-core processing system using a scheduling policy defined by a set of scheduling parameters to allocate the resources of the multi-core processing system to user-level threads of the one or more applications, where the scheduling parameters define hyperparameters for the testing and running, (b) evaluating an optimization objective based on monitoring of hardware limit metrics and / or real-time performance metrics associated with individual processing cores, and (c) executing a hyperparameter tuning algorithm based on the evaluated optimization objective to adjust a set of hyperparameters. The iterations result in a set of optimized scheduling parameters that define an optimal scheduling policy. The optimal scheduling policy is configured as a task planner to pre-allocate resources for running one or more applications on the multi-core processing system.

[0007] Another aspect of the present disclosure relates to a computer program product that includes instructions executable by a multi-core processing system to implement the above method and its optional implementations.

[0008] Additional technical features and benefits can be achieved through the techniques of the present disclosure. The embodiments and aspects of the present disclosure are described in detail herein and are considered part of the claimed subject matter. For a better understanding, reference is made to the detailed description and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The foregoing and other aspects of the present disclosure can be best understood from the following detailed description when read in conjunction with the drawings. To easily identify the discussion of any element or activity, the most significant digit or digits in the reference numerals refer to the drawing number in which the element or activity was first introduced.

[0010] Figure 1 A multi-core processing system according to one embodiment is shown.

[0011] Figure 2 is a schematic block diagram showing a dynamic software scheduler considering hardware constraints of processing cores according to an example embodiment.

[0012] Figure 3 An example of a user interface showing the monitored per-core temperature in a prior art processor is shown.

[0013] Figure 4 is a schematic block diagram showing a dynamic software scheduler considering real-time performance of processing cores according to an example embodiment.

[0014] Figure 5 Schematically shows the measurement of deadline misses and jitter for real-time tasks.

[0015] Figure 6Schematic block diagram of a method for a software task planner for building a multi-core processing system according to an exemplary embodiment. Detailed implementation

[0016] Before proceeding with the detailed description, it may be beneficial to define certain terms for clarity.

[0017] A "process" refers to an instance of an application program executed by a processing unit. An application program (or "app") may include one or more processes.

[0018] A "task" refers to a part of a process that runs on one processing core. A task may include one or more threads.

[0019] A "thread" refers to a basic sequence of instructions to which a scheduler can allocate processor time. The scheduler may be part of an operating system (OS). A thread can execute any part of the process code and may include multiple parts of the process code currently being executed by another thread. In the context of this specification, unless otherwise stated, the term "thread" refers to a user-level thread (also known as an "application thread"). User-level threads are implemented in a user-space library and can be managed and scheduled in the user space of the OS.

[0020] In a multi-core processing system, recent advancements in the OS have made it possible to control which processes run on different processing cores (CPU cores), thus allowing the workload on the available CPU hardware to be freely scheduled. For example, in a real-time operating system, tasks can have different states, such as ready, running, paused, etc. In such a case, the OS kernel is typically responsible for scheduling multiple tasks: for example, when to run, when to pause, and on which CPU cores to run the tasks, in order to meet the functional requirements of the processing system, such as meeting real-time deadlines, allowing multitasking, and sharing hardware resources among multiple tasks.

[0021] CPU hardware may have physical limitations, such as heat limitations. For example, when the hardware is operating under extreme conditions, or if the task is too intense and runs continuously on one core for too long, then the core may reach its heat limit. Another example of CPU overheating may involve the case where an old firmware is running on new CPU hardware. For example, if the old firmware was developed for a 2-core architecture and the new hardware has 4 cores, then overheating problems may occur when the firmware runs on the new hardware and all 4 cores are running. In the case of overheating (e.g., a heat hotspot on a specific core), the CPU or the OS kernel can implement a low-level protection mechanism that can migrate a task from one core to another or sometimes completely shut down the CPU.

[0022] Hardware schedulers are known that can schedule CPU cores at the hardware level to allow for efficient execution of machine code. The OS kernel can also have a scheduler for sharing computing resources among applications. There are also various known schedulers designed for real-time computing, such as Linux's PREEMPT-RT kernel, VxWorks® (developed by Wind River Systems), QNX® (developed by BlackBerry Limited), etc. However, those schedulers do not take into account hardware limitations at the user software level. This can lead to situations such as triggering some low-level actions that can have a catastrophic impact on the software (e.g., shutting down the CPU).

[0023] Embodiments disclosed herein are directed to software-based dynamic schedulers and planners that take into account hardware physical constraints and / or real-time performance requirements. According to the disclosed embodiments, hardware limitation monitoring information and / or real-time performance monitoring information can be accessed at the user or application layer to facilitate scheduling and planning of tasks for real-time systems such as those in industrial control systems. A software scheduler can be made available to applications such that applications (including processes and threads) can be intelligently and dynamically scheduled during runtime based on the monitored information. User-level software, knowing the monitored hardware limitation metrics for individual CPU cores, can act earlier before the low-level protection mechanisms of the CPU or OS kernel take effect to migrate threads, thus avoiding some of the above situations. Additionally, user-level software knowing the monitored real-time performance metrics for individual CPU cores can intelligently schedule tasks to meet real-time requirements, thus allowing real-time systems to run on a general-purpose OS.

[0024] Particularly in the context of industrial control systems, it is a trend for control applications to become more flexible and dynamic, enabling more software-defined control systems. In a software-defined control system, software modules are not bound to specific hardware, i.e., the same control application can be deployed on different hardware (different computing nodes, different cores, different CPUs). The disclosed embodiments can ensure that when a control application is deployed to a software-defined control system, hardware constraints and real-time performance during runtime are considered at the application level, making the software-defined control system suitable for safety and critical control applications while still being open and flexible.

[0025] Turning now to the drawings, Figure 1FIG. 0 shows a multi-core processing system 100 that can incorporate aspects of the present disclosure. In one embodiment, the multi-core processing system 100 can include an industrial control system. As shown, the processing system 100 can include at least one processing unit 102 having a plurality of processing cores and a system memory 104. The processing system 100 can also include a plurality of processing units that cooperate when executing programs. Depending on the exact configuration and type of the processing system 100, the system memory 104 can be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.), or some combination of both. The system memory 104 generally includes an operating system 106, which according to the disclosed embodiments can include a general-purpose PC-based OS such as Linux, etc. In other embodiments, the system memory 104 can include a real-time OS such as VxWorks® developed by Wind River Systems, etc. The system memory 104 can also include one or more software modules, such as an application 108, program modules 110, and a software scheduler 112 that run on the operating system 106.

[0026] The basic configuration of the processing system 100 is shown in Figure 1 by those components within the dashed line 114. The processing system 100 can have additional features or functionality. For example, the processing system 100 can also include additional data storage devices (removable and / or non-removable), such as a hard disk, optical disk, magnetic disk, or tape, flash memory, or other memory technologies. Such additional memory is shown in Figure 1 by removable storage 116 and non-removable storage 118. The processing system 100 can include a user interface adapter 120, which can support input and output devices such as a keyboard, mouse, pen, voice input device, touch input device, display monitor, audio speaker, etc. The processing system 100 can also include an I / O adapter 122, which can be coupled to device controllers in, for example, a factory automation system. The processing system 100 can additionally include a communication connection 124, which allows the processing system 100 to communicate with other devices, such as via a wireless network in a distributed computing environment, such as an intranet or the Internet, etc.

[0027] As disclosed in the present invention, the software scheduler 112 can allocate resources to the application 108 by accessing hardware limit metrics and / or real-time performance metrics associated with individual processing cores of the processing unit 102 that are monitored during runtime. The software scheduler 112 can dynamically allocate processing cores to user-level threads of the application 108 while taking into account the monitored hardware limit metrics and / or real-time performance metrics associated with the individual processing cores. The software scheduler 112 can dispatch user-level threads to execute on the corresponding processing cores based on this allocation.

[0028] Figure 2FIG. 0 illustrates a first embodiment of a software scheduler 202 configured to schedule the execution of one or more applications (e.g., control applications) on multiple processing cores 204 of a multi-core processing system, taking into account the hardware constraints of the multiple processing cores 204 of the multi-core processing system. Each application may execute one or more processes at runtime, and each process is defined by one or more user-level threads. In one embodiment, the software scheduler 202 may be part of a system service that allows a user to define application threads and set parameters such as core affinity, task priority, task loop time, etc. Thus, the software scheduler 202 may access user-defined thread data 206 via a user input device. In the disclosed embodiment, the software scheduler 202 runs in the user space of the processing system OS.

[0029] As shown, the software scheduler 202 may also access hardware limit metrics associated with individual processing cores 204. According to the disclosed embodiment, the hardware limit metric indicates the temperature of each processing core 204 ("core temperature"). In the example shown, the individual core temperatures are measured via respective temperature sensors associated with each processing core 204. Alternatively or additionally, the hardware limit metric may be monitored, for example, via a system environmental processor based on core voltage and / or core current measurements. The voltage and current measurements may capture the more dynamic physical behavior of the hardware and may further be correlated with the core temperature. Measurements related to the hardware limit metrics (e.g., core temperature, voltage, current, etc.) may be monitored in real time by a hardware limit monitoring module 208. The hardware limit monitoring module 208 may include, for example, a sensor fusion module configured to combine online measurement data from multiple sensors to derive the hardware limit metric for each processing core 204.

[0030] Hardware limit monitoring is to some extent available in many prior art multi-core processors. Figure 3 FIG. 8 shows an example of a user interface 300 that displays the per-core temperature monitored in an x86 CPU manufactured by Intel Corporation. However, such prior art measurements are passive and not fed back to the scheduler to adjust software behavior to adapt to different hardware during runtime.

[0031] Continuing to refer to Figure 2 , the software scheduler 202 may dynamically assign the processing cores 204 to the user-level threads of one or more applications, considering the hardware limit metrics of the processing cores 204 monitored during runtime. For example, based on the monitored core temperature, the software scheduler 202 may dynamically decide which core 204 executes the next task to avoid heat hotspots. The basic idea is based on the understanding that the amount of heat generated by a core is associated with its workload, but the temperature is the hard limit for CPU throttling or shutdown.

[0032] According to the disclosed embodiments, as shown in the figure, the software scheduler 202 may include a first layer including an optimizer 210 and a second layer including a thread migrator 212. The optimizer 210 may dynamically determine optimal scheduling parameters using monitored hardware limit metrics of individual processing cores 204. The scheduling parameters may include one or more of the following parameters for each thread, namely, the processing core for execution, the sleep time, the loop time, and so on. The optimization problem solved by the optimizer 210 may include determining scheduling parameters that minimize the hardware limit metrics (e.g., core temperature) such that real-time performance requirements (e.g., task deadlines) are met. For example, such an optimization problem may be formulated as:

[0033]

[0034] such that: real-time performance constraints are satisfied, and

[0035] CPU utilization < limit; CPU temperature < shutdown temperature.

[0036] In one embodiment, the optimizer 210 may include a rule-based optimizer, which may be computationally inexpensive and thus suitable for a runtime scheduler. The rule-based optimizer 210 may be designed based on the above optimization problem. As an illustrative example, consider Figure 2 the scenario shown, where Core 1 is assigned three threads, and Cores 2, 3, and 4 are each assigned one thread. The hardware limit monitoring module 208 may observe that the temperature of Core 1 increases over time and provide such feedback to the rule-based optimizer 210. Based on this feedback, the rule-based optimizer 210 may determine scheduling parameters to move some threads from Core 1 to Core 3 before a hot spot forms at Core 1 while meeting real-time requirements. The hardware limit monitoring module 208 may continuously monitor the impact of each action and provide feedback to the optimizer 210.

[0037] The thread migrator 212 may include, for example, a prior art thread scheduling algorithm to dynamically migrate or switch user-level threads 216 to the allocated processing cores 204 based on the optimal scheduling parameters determined by the optimizer 210. Based on the output of the thread migrator 212, the user-level threads 216 may be dispatched via a suitable OS API 214 for execution on the corresponding processing cores 204, which may be used to set or change the processing core for executing a thread or task. For example, in a Linux-based system, the APIs that may be used by a software scheduler running in the OS user space may include cgroup, sched_setaffinity, and taskset. In a real-time OS such as VxWorks®, a suitable API that may be used by such a software scheduler is taskCpuAffinitySet(taskID, core number). In some embodiments where the scheduler may run in the kernel space of the OS, the scheduler may utilize other suitable APIs to dispatch threads to processing cores.

[0038] Figure 4 A second embodiment of a software scheduler 402 is shown that is configured to schedule the execution of one or more applications (e.g., control applications) on multiple processing cores 404 of a multi-core processing system considering the real-time performance of the multiple processing cores 404 of the multi-core processing system. Each application may execute one or more processes at runtime, and each process is defined by one or more user-level threads. The software scheduler 402 may be part of a system service that allows a user to define application threads and set parameters such as core affinity, task priority, task loop time, etc. Thus, the software scheduler 402 may access user-defined thread data 406 via a user input device. The software scheduler 402 may run in the user space of the processing system OS.

[0039] The software scheduler 402 may also access real-time performance metrics associated with individual processing cores 404. In a closed-loop control system, tasks are typically periodic and require execution at constant time intervals. For control applications implemented with periodic tasks, the monitored real-time performance metrics may include parameters that affect periodicity and may cause performance degradation. Thus, in some embodiments, for each processing core, the monitored real-time performance metrics may include measurements of one or more of the following, namely deadline misses, jitter, and memory utilization, as well as other measurements such as CPU load.

[0040] As Figure 5As shown, tasks in a control application can iterate in a loop with a desired cycle time (e.g., every 1 millisecond). The cycle time can be defined by the user, for example, based on domain knowledge. As shown in the figure, if the run time of a loop iteration exceeds the desired cycle time, a deadline miss is considered to have occurred. The deadline miss can be expressed as, for example, the number of misses per core per minute (or any other defined interval). On the other hand, jitter is measured as the amount of error in the task timing in subsequent iterations of a program or loop, as Figure 5 shown. Jitter can thus be defined as a measure of the variability of task waiting times. Higher jitter can indicate a lower degree of determinism in task execution, for example, due to interrupts or random processes executed on the hardware.

[0041] To the extent of the prior art, real-time performance monitoring can be used to measure timing, jitter, and memory utilization, CPU load, etc. per core. However, such prior art measurements are passive and not fed back to the scheduler to adjust the software's behavior to adapt to different hardware during runtime.

[0042] Return reference Figure 4 , measurements related to real-time performance metrics (e.g., deadline misses, jitter, memory utilization, CPU load, etc.) can be continuously monitored during runtime by a real-time performance monitoring module 408 that can be coupled to the system clock. The software scheduler 402 can dynamically allocate the processing core 404 to user-level threads of one or more applications considering the real-time performance of the processing core 404 monitored during runtime. Similar to the previous embodiments, the software scheduler 402 can include a first layer that includes an optimizer 410 and a second layer that includes a thread migrator 412.

[0043] The optimizer 410 can use the monitored real-time performance metrics of individual processing cores 404 to dynamically determine the best scheduling parameters for each thread (e.g., the processing core for execution, sleep time, cycle time, etc.). In one example, the optimizer 410 can be configured to determine the best scheduling parameters that can minimize jitter such that real-time constraints (e.g., real-time task deadlines, CPU load limits, etc.) are met.

[0044] According to the disclosed embodiments, a software-defined control system can run on a general-purpose OS, which, unlike a real-time OS, can have multiple normal (non-critical) processes that can compete with the control application for CPU time and memory access. By implementing a software scheduler to intelligently schedule tasks based on measurements of jitter, deadline misses, or other real-time performance metrics, the software-defined control system can provide improved performance for real-time applications.

[0045] In one embodiment, the optimizer 410 may include a rule-based optimizer, which may have low computational complexity and is thus suitable for a runtime scheduler. The rule-based optimizer 410 may be designed based on the optimization problem described above. As an illustrative example, consider Figure 4 the scenario shown in, where the user has scheduled more threads / tasks on core 1 than there are remaining cores. The real-time performance monitoring module 408 may observe that there are more deadline misses and / or jitter on core 1 and provide this feedback to the rule-based optimizer 410. Based on this feedback, the rule-based optimizer 410 may determine scheduling parameters to move some threads from core 1 to core 2, while the real-time performance monitoring module 408 continues to monitor the impact of each action.

[0046] The thread migrator 412 may include, for example, a prior art thread scheduling algorithm to dynamically migrate or switch the user-level threads 416 to the assigned processing cores 404 based on the optimal scheduling parameters determined by the optimizer 410. Based on the output of the thread migrator 412, the user-level threads 416 may be dispatched via a suitable OS API 414 (e.g., as described above) for execution on the corresponding processing cores 404.

[0047] According to a third embodiment, a software-level scheduler may be configured to schedule the execution of user-level threads on processing cores based on hardware limit metrics and real-time performance metrics associated with individual processing cores monitored during runtime. In this case, the combination of a hardware limit monitoring module (as Figure 2 shown) and a real-time performance measurement module (as Figure 4 shown) may be used to provide feedback to the software scheduler, based on which the software scheduler may dynamically allocate processing cores to the user-level threads of a running application.

[0048] As in the first and second embodiments, the software scheduler according to the third embodiment may include a first layer containing an optimizer and a second layer containing a thread migrator. The optimizer may use the monitored metrics to dynamically determine optimal scheduling parameters. In this case, the optimizer may be based on an optimization problem defined by the combination of hardware limit metrics and real-time performance metrics associated with individual processing cores. For example, the optimization problem may be formulated as:

[0049]

[0050] such that: the real-time performance constraints are satisfied, and

[0051] CPU utilization < limit; CPU temperature < shutdown temperature.

[0052] The optimizer may include a rule - based optimizer that can be designed based on an optimization problem where real - time performance is intertwined with the thermal limits of the hardware. As an illustrative example, the rule - based optimizer can be designed to determine scheduling parameters such that hard real - time threads that should not be interrupted can be scheduled on the core with the most stable thermal conditions, while some other threads with high computational requirements and fewer real - time requirements can be scheduled on other cores, and the execution of those threads also takes into account the thermal inertia of the cores.

[0053] Again, similar to the previous embodiments, the thread migrator can dynamically migrate user - level threads to the allocated processing cores based on the determined optimal scheduling parameters. Based on the output of the thread migrator, the user - level threads can be dispatched for execution on separate processing cores via appropriate OS APIs.

[0054] Other aspects of the present disclosure are directed to a software task planner for a multi - core processing system. Recognizing that in a closed - loop control system, even with software - defined controllers, most control applications may still involve cyclic tasks. Based on this understanding, in many cases, the heat and computational footprint of a control application can be predetermined during the debugging phase. Thus, a software task planner can be constructed that can pre - allocate processing cores and resources to one or more applications during the debugging phase.

[0055] Figure 6 A method 600 for constructing a software task planner according to an example embodiment is shown. The various activities of method 600 as described in the present invention, including its components, can be implemented in various ways by a multi - core processing system, e.g., as hardware and programming. The programming for the activities can take the form of processable executable instructions stored on a non - transitory machine - readable storage medium, and the hardware for the engine can include a processor that executes these instructions.

[0056] Activity 604 includes test - running one or more applications 602 on the multi - core processing system using a scheduling policy defined by a set of scheduling parameters (e.g., as described above) to allocate the resources of the multi - core processing system to the user - level threads of the applications 602. In this case, the scheduling parameters define the hyperparameters of the test - run (i.e., remain constant).

[0057] Activity 606 includes monitoring the hardware limit metrics and / or real - time performance metrics associated with individual processing cores (e.g., as described above). The measured metrics can be used to evaluate an optimization objective (e.g., a cost function). In one embodiment, the optimization objective / cost function can be defined by a combination of the measured hardware limit metrics and the measured real - time performance metrics associated with individual processing cores, as described above in connection with the third embodiment.

[0058] Activity 608 includes performing a hyperparameter tuning algorithm to adjust the set of hyperparameters based on an evaluated optimization objective. The hyperparameter tuning algorithm can include, for example, a grid search algorithm, a Latin hypercube sampling algorithm, a Monte Carlo search algorithm, etc. The above algorithms are particularly suitable for cases where a mathematical model describing the system behavior is not available, as in the current case.

[0059] Activities 604, 606, 608 can be iteratively performed until a convergence criterion is met. The convergence criterion can include, for example, a specified number of iteration steps, a minimum increment (difference) in the evaluation of the optimization objective between consecutive iterations, etc. At convergence, a set of optimized scheduling parameters defining an optimal scheduling strategy can be obtained. The optimal scheduling strategy can be configured as a task planner to pre-allocate resources for running one or more applications on a multi-core processing system.

[0060] A software task planner developed offline can enable the control system to run predictably without online monitoring of hardware limitations or real-time performance. However, in the case of unpredictable operating conditions (such as extreme ambient temperature changes), the dynamic software scheduler described above can provide better real-time performance. In such a case, the scheduling parameters of the software task planner can still provide a near-optimal starting point.

[0061] Thus, according to one embodiment, during the deployment phase, the scheduling parameters of the software task planner can be used for the initial allocation of resources for running an application on a multi-core processing system. The software scheduler (e.g., as described above) can access hardware limitation metrics and / or real-time performance metrics associated with individual processing cores monitored during the runtime of the application. The software scheduler can include an optimizer for further dynamically adjusting the scheduling parameters based on the monitored metrics; and a thread migrator for dynamically migrating user-level threads to the allocated processing cores based on the determined optimal scheduling parameters, as described above. It is desirable that the optimizer has a small computational load, for example, including a rule-based optimizer or an optimization algorithm based on a linearized model around the settings (scheduling parameters) defined by the software task planner.

[0062] Embodiments of the present disclosure can be implemented in any combination of hardware and software. In addition, embodiments of the present disclosure can include an article of manufacture (e.g., one or more computer program products) having, for example, a non-transitory computer-readable storage medium. The computer-readable storage medium has implemented therein computer-readable program instructions for providing and facilitating the mechanisms of embodiments of the present disclosure. The article of manufacture can be included as part of a computer system or sold separately.

[0063] A computer-readable storage medium may include a tangible device that can hold and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network.

[0064] The systems and processes of the figures are not exclusive. Other systems, processes, and menus may be derived in accordance with the principles of the present disclosure to achieve the same objectives. Although the present disclosure has been described with reference to specific embodiments, it should be understood that the embodiments and variations shown and described herein are for illustrative purposes only. Modifications to the current designs may be implemented by those skilled in the art without departing from the scope of the appended claims.

Claims

1. A multi-core processing system, comprising: a processing unit including a plurality of different processing cores, and a memory coupled to the processing unit, the memory including instructions defining modules executable by the processing unit, the modules including: an application configured to execute one or more processes at runtime, each process defined by one or more user-level threads, and a software scheduler configured to schedule execution of the user-level threads on the processing cores by: accessing hardware limit metrics and / or real-time performance metrics associated with individual processing cores monitored during runtime, dynamically allocating processing cores to the user-level threads based on the monitored hardware limit metrics and / or the real-time performance metrics associated with the individual processing cores, and dispatching the user-level threads to execute on the corresponding processing cores based on the allocation.

2. The multi-core processing system according to claim 1, wherein the monitored hardware limit metric indicates the temperature of each processing core.

3. The multi-core processing system according to any one of claims 1 and 2, wherein the hardware limit parameter is monitored via a measurement signal related to one or more of: core temperature, core voltage, and core current.

4. The multi-core processing system according to any one of claims 1 to 3, wherein for each processing core, the monitored actual performance metric includes measurements of one or more of: deadline misses, jitter, and memory utilization.

5. The multi-core processing system according to any one of claims 1 to 4, wherein both the hardware limit metrics and the real-time performance metrics associated with the individual processing cores are monitored during runtime, and wherein the processing cores are dynamically allocated to the user-level threads based on the monitored hardware limit metrics and the real-time performance metrics associated with the individual processing cores.

6. The multi-core processing system according to claim 5, wherein the software scheduler includes: an optimizer configured to dynamically determine optimal scheduling parameters based on an optimization objective using the monitored metrics, the optimization objective defined by a combination of the hardware limit metrics and the real-time performance metrics associated with the individual processing cores, and a thread migrator configured to dynamically migrate user-level threads to the allocated processing cores based on the determined optimal scheduling parameters.

7. The multi-core processing system according to claim 6, wherein for each user-level thread, the scheduling parameters include one or more of: the processing core for execution, the sleep time, and the cycle time.

8. The multi-core processing system according to any one of claims 6 and 7, wherein the optimizer includes a rule-based optimizer.

9. The multi-core processing system according to any one of claims 1 to 8, wherein the software scheduler runs in the user space of the operating system of the multi-core processing system.

10. The multi-core processing system according to claim 9, wherein the operating system is a general-purpose operating system.

11. The multi-core processing system according to any one of claims 1 to 10, wherein The multi-core processing system is an industrial control system.

12. A method for allocating resources to an application running on a multi-core processing system, the method comprises: accessing hardware limit metrics and / or real-time performance metrics associated with individual processing cores of the multi-core processing system monitored during runtime; dynamically allocating processing cores to user-level threads of the application considering the monitored hardware limit metrics and / or the real-time performance metrics associated with the individual processing cores; and dispatching the user-level threads to execute on corresponding processing cores based on the allocation.

13. A non-transitory computer-readable storage medium comprising instructions that, when processed by a multi-core processing system, configure the multi-core processing system to execute the method according to claim 12.

14. A method for allocating resources in a multi-core processing system, comprises: constructing a software task planner during a debugging phase by performing the following steps in multiple iterations: testing and running one or more applications on the multi-core processing system using a scheduling policy defined by a set of scheduling parameters to allocate resources of the multi-core processing system to user-level threads of the one or more applications, wherein the scheduling parameters define hyperparameters for the test run, evaluating an optimization objective based on monitoring of hardware limit metrics and / or real-time performance metrics associated with individual processing cores, and executing a hyperparameter tuning algorithm based on the evaluated optimization objective to adjust a set of hyperparameters, wherein the iteration generates a set of optimized scheduling parameters defining an optimal scheduling policy configured as a task planner to pre-allocate resources for running the one or more applications on the multi-core processing system.

15. The method according to claim 14, wherein, for each user-level thread, the hyperparameters include one or more of the following: the processing core for execution, the sleep time, and the cycle time.

16. The method according to any one of claims 14 and 15, wherein, the hyperparameter tuning algorithm is selected from the group consisting of: a grid search algorithm, a Latin hypercube sampling algorithm, and a Monte Carlo search algorithm.

17. The method according to any one of claims 14 to 16, wherein, the optimization objective is defined by a combination of the measured hardware limit metrics and the measured real-time performance metrics associated with the individual processing cores.

18. The method according to any one of claims 14 to 17, further comprises: using the scheduling parameters of the task planner for an initial allocation of resources for running the one or more applications on the multi-core processing system, accessing the hardware limit metrics and / or the real-time performance metrics associated with the individual processing cores monitored during the runtime of the one or more applications, using an optimizer to further dynamically adjust the scheduling parameters based on the monitored metrics, and using a thread migrator to dynamically migrate user-level threads to allocated processing cores based on the determined optimal scheduling parameters.

19. The method according to claim 18, Among them, the optimizer includes a rule-based optimizer.

20. A non-transitory computer-readable storage medium, including instructions that, when processed by a multi-core processing system, configure the multi-core processing system to execute the method according to any one of claims 14 to 19.

Images