Method for operating a computing unit

Abstract

The invention relates to a method for operating a computing unit (100) in which a plurality of processes are executed which jointly access a resource (130) in accordance with a predetermined resource allocation, the method comprising: determining (220, 230) a current actual processing time of at least one of the plurality of processes during the execution of the at least one of the plurality of processes, the at least one of the plurality of processes being processed for the actual processing time; comparing (230) the actual processing time with a nominal processing time assigned to the at least one of the plurality of processes and / or with a sum of the assigned nominal processing time and a processing time extension assigned to the at least one of the plurality of processes; and adjusting (240, 250) the predetermined resource allocation in accordance with a result of the comparison.

Description

Technical Field

[0001] The present invention relates to a method for operating a computing unit, as well as a computing unit and a computer program for performing the method. Background Technology

[0002] Applications or processes, such as those involving autonomous or self-driving vehicles, can be extremely computationally and data-intensive. Accordingly, there is a tendency to use high-performance computing platforms in cyber-physical systems (e.g., through exchanges with computing systems outside the vehicle (the so-called "cloud"). Such platforms can be used to execute different processes with varying quality requirements in terms of Quality of Service (QoS), such as personalized requirements regarding latency, bandwidth, or so-called "Best Effort." QoS is a measure of how well a service meets the required quality standards.

[0003] On such a platform, there are typically different units such as CPU clusters, GPUs, or other user-defined hardware accelerators (also known as memory masters or masters), all of which can access shared resources, such as shared memory (slaves). Here, an application running on a specific core (specifically, a CPU or one of multiple processor cores in a CPU cluster) first competes for memory with applications running on other cores. Furthermore, other hosts, such as GPUs, can compete with the CPU for shared memory via shared connections.

[0004] It has been shown that when a process executes alongside other processes on a shared multi-core platform, its execution time can be significantly prolonged due to access to shared resources, such as main memory. This competition with other hosts further exacerbates the problem. Therefore, it is crucial to achieve interference-free and time-decoupled execution of different processes on a multi-core platform, especially for processes with real-time requirements. Summary of the Invention

[0005] According to the present invention, a method for operating a computing unit, as well as the computing unit and a computer program for performing the method, are proposed, featuring the characteristics of the independent claims. Advantageous designs are the subject of the dependent claims and the following description.

[0006] Multiple processes or applications execute within a computing unit, sharing resources according to a predetermined resource allocation. This invention utilizes the aforementioned measures to assign tolerances, such as required runtime or processing time and allowable runtime extensions, to each process. If these tolerances cannot be met, for example, due to conflicts accessing shared resources, then the resource allocation is adjusted for each process.

[0007] The computing unit particularly has a processor unit with multiple processor cores, each processor core executing multiple processes and connected to corresponding resources, such as via data connections like buses. Such a processor unit can be configured, for example, as a CPU (“Central Processing Unit”), a GPU (“Graphics Processing Unit”), or, for example, as a DMA or DMA controller (“Direct Memory Access”), or as a dedicated accelerator.

[0008] Particularly suitable are these shared resources, which can be memory cells, such as shared working memory, that is, particularly volatile memory such as DRAM (Dynamic Random Access Memory). Such memory cells have bandwidth, or memory bandwidth, which is the rate at which data can be read and / or written per unit time. This bandwidth is not necessarily constant. DRAM, for example, has its own internal optimization mechanisms (see, for example, caching), and thus this bandwidth can be higher or lower depending on the order of access to memory addresses and the location of the data. In contrast, the processor core, and therefore the processes executed by it, must share the available bandwidth.

[0009] Furthermore, shared resources can also be, for example, the computing capacity of a computing unit or processor unit, such as when processes are not fixedly assigned to specific processor cores but can be executed by multiple cores. Shared resources can also be, for example, modules or other units within a computing unit, such as peripheral devices.

[0010] According to a predetermined resource allocation, the individual processor cores and thus the access of each processor to shared resources are appropriately adjusted. Particularly suitable is this resource allocation to allocate available memory bandwidth within shared memory units to each processor core and process. The present method provides a possibility to dynamically adjust resource allocation to shared resources during the operation of the computing unit to meet the requirements of individual processes.

[0011] For this purpose, within the scope of the method of the present invention, a rated processing time or rated execution time and an allowed processing time extension are assigned or predetermined for each individual or, in particular, all processes. Here, the corresponding process should be fully processed or executed, in particular, within the corresponding assigned rated processing time. The actual processing time of the corresponding process should deviate from the corresponding assigned rated processing time by at most the assigned processing time extension. This deviation from the rated processing time occurs particularly when multiple processes access common resources in parallel. When the actual processing time exceeds the rated processing time by more than the corresponding (allowed) processing time extension, it may impair the functionality of the corresponding process or even the entire computing unit.

[0012] Suitablely, the rated processing time is a standard or reference value for the runtime of the corresponding process, and can correspond to the expected runtime, for example, when the corresponding process executes in isolation or independently from other processes competing for the resource and thus has exclusive access to the corresponding resource. The sum of the rated processing time and the processing time extension can be particularly suitably predetermined as an allowable threshold or allowable limit for the actual processing time. The processing time extension can in particular correspond to an allowable percentage or absolute time, when a corresponding delay effect occurs due to shared access to the resource, the rated processing time should at most be extended by said allowable percentage or absolute time.

[0013] The rated execution time or processing time can be observed and described holistically for the entire process or at the interval level. The rated processing time and processing time extension can be described, for example, as absolute time values ​​or suitably as relative values ​​from which absolute time values ​​can be derived. The rated processing time and processing time extension can be, for example, predetermined as counter values ​​of a performance counter, a hardware performance counter, or a hardware counter ("performance monitoring counter", PMC, or "performance monitoring unit", PMU) that measures or counts a specific process or activity within the computing unit. Changes in operating time can also be, for example, predetermined as a percentage deviation from these counter values. Based on these counter values, the corresponding runtime or corresponding rated processing time and processing time extension are suitably derived automatically by the target hardware platform.

[0014] When each process is executed in the computing unit, the current actual processing time of each process is determined or calculated, and each process is actually processing within that actual processing time. These actual processing times of each process are compared with their respective assigned rated processing times and / or with the sum of their respective assigned rated processing times and their respective assigned processing time extensions. Resource allocation is adjusted based on the result of this comparison. Therefore, it is particularly important to monitor whether the actual processing time of each process deviates from the predetermined rated processing time during normal operation of the computing unit, and if so, to what extent. If the actual times deviate from the respective rated processing times, this specifically indicates that conflicts have occurred among the processes when accessing shared resources, thereby delaying the processing time of the processes. If the actual processing times deviate from the assigned rated processing times, or even more than the corresponding permissible processing time extension, then the system is operating outside the permissible range and may adversely affect the respective processes, for example, due to access conflicts regarding shared resources, and system instability may occur.

[0015] Ideally, resource allocation should be adjusted based on whether and to what extent the actual processing time and the rated processing time deviate from each other, so as to reduce these deviations and bring the processing time of the corresponding processes closer to their respective rated values. In particular, resource allocation should be adjusted in such a way that critical processes exceeding their respective rated processing times have more access to resources, thus preventing these processes from being negatively hindered during execution. Non-critical processes whose actual processing times are the same as or at least substantially the same as their rated processing times can be guaranteed to access the resources less during execution. For example, runtime priority values ​​can be assigned to each process to indicate the importance of the process's runtime requirements.

[0016] This invention thus enables the dynamic and personalized adjustment of which process should access shared resources to what extent during the execution of the computing unit, thereby preventing access conflicts, delays, and even errors or instability during process execution. The allocation of resources to each process is therefore adjusted independently and automatically by the computing unit, personalized to the currently executing application and process.

[0017] Suitablely, the monitoring of processing time and the adjustment of resource allocation are implemented in the software through corresponding software units, software modules, or software mechanisms. Such software mechanisms can be configured as execution managers or resource managers, for example. These mechanisms or execution managers can be executed, in particular, by the processor unit of the computing unit. Alternatively, it is conceivable to implement the hardware unit itself that executes such software mechanisms within the computing unit.

[0018] The method further enables the separation of determining the best possible resource allocation between the hardware and software sides. Specifically, programmers or software developers can predetermine the rated processing time and processing time extension for the respective processes, for example, during the process creation or programming phase. Specifically, the rated processing time and processing time extension can be predetermined for the respective processes independently of specific computing units or hardware configurations, after which the processes are executed. Therefore, developers of individual software processes can be given a high degree of freedom and flexibility during development. These stipulations regarding how well software developers can execute their respective processes are automatically taken into account by the computing unit during its operation. The rated processing time for this purpose can be described, for example, as a relative value in the form of a counter, and the processing time extension can be described, for example, as an increase in these counter values.

[0019] Individual processes or applications executing within a computing unit can have varying quality requirements in terms of Quality of Service (QoS). QoS is a measure of how well a service meets the required quality. Depending on the type and priority of the application, each process can react differently to latency in its processing. Each process, when executing concurrently with other applications, can tolerate performance degradation, particularly in the form of increased execution time due to contention for shared hardware resources, depending on its time-criticality. Latency can therefore have a more or less critical impact on individual processes and the entire system. For time-insensitive, less important processes, such as those creating records or log files, latency has little or no negative impact. Time-critical or real-time processes, such as those controlling motors, internal combustion engines, inverters, etc., have particularly little leeway in their processing time and can only tolerate limited latency in their processing. Based on the criticality and sensitivity of each process, and particularly based on the maximum increase in execution time (which the corresponding process can tolerate in order to operate correctly), a nominal processing time and an allowable processing time extension are appropriately and individually scheduled for each process. Based on these stipulations, resource allocation in the online monitoring and dynamic control system is controlled, thereby limiting the impact of access conflicts, particularly in the form of extended execution time, on each process to the corresponding predetermined allowable values. Therefore, the current approach can particularly appropriately ensure the Quality of Service (QoS) for different processes and applications.

[0020] Shared resources are often statically provided or allocated in a traditional manner and configured, at least considering so-called worst-case contention scenarios. This static resource allocation can lead to inefficient use of system resources. For example, a mechanism or method is known from Marco Caccamo, Rodolfo Pellizzoni, Lui Sha, Gang Yao, and Heechul Yun's 2013 paper, "MemGuard: A Memory Bandwidth Reservation System for Efficient Performance Isolation in Multi-Core Platforms" (IEEE 19th Real-Time and Embedded Technologies and Applications Workshop (RTAS'13); IEEE Computer Society, Washington, D.C., 55-64), in which a minimum memory bandwidth is guaranteed for different CPU cores within a CPU cluster. This operates by assigning a budget, i.e., a specific value or a share of the entire available memory bandwidth, to the cores and monitoring cache errors at the last level within a set interval, and stopping the cores when the budget for the set interval is exceeded. Furthermore, this approach provides the possibility of dynamically assigning memory bandwidth based on previous usage patterns. However, forecasting always looks at previous intervals and is not event-driven. It assumes that the budget is statically assigned to each core, and then unused budget is reallocated.

[0021] Another traditional possibility for memory-aware planning is, for example, that tasks that should be executed concurrently on different cores at specific points in time are determined in advance, for example, by the planner, thus not pushing memory limits. Applications can also be scheduled in storage and computation phases, and different storage phases of applications can be planned on different cores. However, it is desirable to have a scheme that is independent of the planning logic and does not alter the characteristics of the application.

[0022] Embedded high-performance platforms increasingly provide QoS modules on the hardware side for connections between the host (e.g., CPU, GPU, DMA) and main memory. These QoS modules are useful for adjusting data traffic based on different parameters such as open transactions, rate adjustment, or latency regulation. For example, registers on the connection can be configured to determine limits for open traffic, such as for the GPU, so that the connection is not overwhelmed by memory traffic. Once these limits are exceeded, the connection throttles incoming data traffic from the GPU, allowing other hosts to access memory. These modules are typically programmable via registers and control the host components connected to the connection.

[0023] However, these QoS modules typically treat the entire core cluster as a single host, since the entire cluster is connected to the connection at a single port or interface. Therefore, QoS modules only provide tuning at the cluster level when necessary and may not be able to distinguish between different cores, which does not solve the problem of cross-core contention. Furthermore, static configuration of tuning parameters may be insufficient for efficient use of shared memory.

[0024] Furthermore, QoS tuning for different cores within a CPU cluster is typically not supported by the underlying hardware. This means that hardware-based QoS support at the interconnect level can only protect a core from other interference sources, but not from other cores within the same cluster. Therefore, top-level software mechanisms usually combine QoS support at the interconnect level to provide the necessary interference tuning.

[0025] However, in such software-based tuning mechanisms, a static resource budget is often assigned to each core. This budget is frequently set to the maximum number of resource accesses within a specific tuning interval, which can cause non-real-time cores to slow down significantly. Furthermore, configuring such a mechanism can prove difficult. This requires expertise in the underlying hardware and specific workloads. For example, in large software stacks consisting of a hypervisor, operating system, middleware, and additional virtual units, such as Docker containers, this can prove extremely expensive. Misconfigured systems can lead to significant performance penalties or an inability to mitigate disruptive effects.

[0026] In contrast to these approaches, the current method proposes a software mechanism that automatically takes into account the changing resource usage patterns of processes, such as varying memory usage patterns, and allows these tuning parameters to be reconfigured within the QoS module. The method also proposes the possibility of dynamically tuning resources such as memory bandwidth for different hosts (which could involve either individual processor units or groups of processor units (or cores)) at the connection layer and additionally tuning resources between cores within the processor unit group, i.e., within the host.

[0027] Advantageously, the following steps are implemented: determining the current actual processing time; comparing the determined actual processing time with the corresponding assigned rated processing time, or with the sum of the corresponding assigned rated processing time and the corresponding assigned processing time extension; and periodically adjusting resource allocation within predetermined monitoring intervals. Therefore, the deviation between the current actual processing time and the corresponding rated value can be determined under the current monitoring event, and resource allocation can be adjusted based on said deviation. The impact of this adjustment on the processing time can be observed in subsequent monitoring events.

[0028] Preferably, resource allocation is adjusted based on whether the actual processing time of at least one process deviates from the corresponding assigned rated processing time by more than the corresponding assigned processing time extension. It is preferable to adjust resource allocation dynamically in this way so as to minimize the allowable processing time extension and thus prevent system instability.

[0029] Alternatively or additionally, resource allocation can be adjusted based on the extent to which the actual processing time of each process deviates from its corresponding rated processing time. In this case, dynamic adjustment of resource allocation is particularly beneficial, as it allows for finding the optimal allocation of resources and achieving the best possible processing time for each process, as close as possible to its predetermined rated value.

[0030] The current actual processing time of each process is advantageously determined using at least one performance counter. A performance counter, or hardware performance counter (PMC, or performance monitoring unit, PMU), is a component of a processor unit or microprocessor, for example, in the form of a special register, that measures or counts a specific process or activity within the computing unit. Therefore, it is suitable to collect data from the corresponding performance counters to monitor increases in the execution time of a process (the process experiencing said increase in execution time during its execution). Data from combinations of multiple performance counters is particularly considered here. Monitoring via performance counters is performed periodically, especially at predetermined monitoring intervals. It is suitable that a software mechanism or execution manager can read information from these performance counters and compare it with stored predetermined rated processing time and processing time extensions.

[0031] In a preferred embodiment, during resource allocation, different allocation parameters are used to regulate, organize, or arrange access to shared resources by multiple processes. Specifically, different allocation mechanisms or control or organization mechanisms can be set up, which assign portions of resources to individual processor cores or processes in different ways according to these allocation parameters. Particularly suitable for this purpose is to set up multiple QoS modules or QoS mechanisms, which use corresponding allocation parameters to regulate the corresponding allocation mechanisms.

[0032] Preferably, one or more allocation parameters are adjusted based on a comparison between the actual processing time and the rated processing time, or the sum of the corresponding rated processing time and processing time extension. Different allocation parameters provide flexibility in adjusting resource allocation. In particular, the rated values ​​of the allocation parameters can be determined based on pre-defined values ​​for each process, i.e., based on the rated processing time and processing time extension. Therefore, it is suitable to convert the rated processing time and processing time extension into QoS-specific rated values ​​or tuning parameters for different hardware and software QoS mechanisms 240. The software mechanism or execution manager can, in particular, instruct each QoS module or QoS mechanism to adjust the corresponding allocation parameters based on the current comparison results to determine and compare the actual processing time. Suitablely, the software mechanism communicates the QoS-specific rated values ​​to each QoS module or QoS mechanism, which are coordinated accordingly with the corresponding allocation parameters.

[0033] According to a preferred embodiment, relationships or correlations are determined or learned between adjustments to various allocation parameters and the resulting changes in the actual processing time of each process. These determined and learned relationships are used to adjust one or more of the allocation parameters based on a comparison of the actual processing time with the rated processing time or the sum of the rated processing time and its extension. Software mechanisms can learn the corresponding correlations between allocation parameters and processing time, particularly during machine learning or with the aid of algorithms for machine learning. These relationships can be determined, for example, at a first point in time, during the learning phase, and used at a subsequent second point in time, especially during normal operation of the computing unit.

[0034] Resource allocation can be advantageously adjusted by partially or entirely assigning the portion of resources allocated to the first process to the second process. Thus, resources may be partially reallocated, for example, from a first process whose actual processing time and rated processing time are close to each other, or from a process that is not time-critical, to a second process whose processing should not be delayed.

[0035] Alternatively or additionally, resource allocation can be adjusted by reducing the number of pending services or operations within predetermined time intervals, particularly within the next monitoring interval. For example, non-time-critical services can be postponed to ensure access to resources for time-critical processes.

[0036] In addition, resource allocation can be adjusted alternatively or additionally by preferentially increasing the execution priority of specific processes, particularly those whose actual processing time deviates from the corresponding assigned rated processing time by more than the corresponding assigned processing time extension. Suitablely, it is guaranteed that processes with such higher priority can access resources faster than processes with lower execution priority.

[0037] Alternatively or additionally, resource allocation can be preferably adjusted in such a way that resources, or at least a portion thereof, are exclusively assigned to specific processes. This, for example, ensures that time-critical processes delayed due to access conflicts can exclusively access resources, or a portion thereof.

[0038] Alternatively or additionally, resource allocation can be advantageously adjusted by partitioning resources and exclusively assigning one of these partitions to a specific process. For example, shared memory can be divided into multiple separate memory regions during a process, which can be flexibly assigned to various processes.

[0039] When the actual processing times of multiple processes deviate from their respective assigned rated processing times by more than the corresponding assigned processing time extension, there is a risk that problems or instability may occur in all these processes due to access conflicts. In this case, it is particularly important to prioritize these processes when adjusting resource allocation. Preferably, the assigned processing time extensions for these processes are adjusted based on their runtime priority. It is particularly suitable to increase the assigned processing time extensions for lower priority processes by a predetermined value. Thus, it is particularly advantageous to prioritize higher-priority, time-critical processes during resource allocation. Alternatively or additionally, it is preferable to adjust resource allocation for each of these processes iteratively, continuously, or sequentially according to their runtime priority, especially starting with the highest-priority process. Therefore, it is suitable to adjust resource allocation for the highest-priority process first, and then iteratively process the remaining processes accordingly.

[0040] This invention is applicable to many different fields of study, and is particularly advantageously applicable to the field of (motor) vehicles, wherein the computing unit is advantageously configured as a control device for (motor) vehicles, and wherein various processes are designed to control vehicle functions. The processes executed by the computing unit may, for example, include safety-critical functions designed to safely operate and control the vehicle, for example, during motor control or driver assistance functions. The method can particularly suitably enable such safety-critical and especially time-critical processes, which require real-time execution, to meet their respective real-time conditions without being delayed due to access conflicts to shared resources of the control device, particularly to shared memory. The safety, fault tolerance, and integrity of the control device can be improved by the present method. In particular, the method can meet safety requirements in the field of (motor) vehicles, such as those detailed in ISO 26262 as defined in ISO standard 26262 or, in particular, by the so-called "Automotive Safety Integrity Level" (ASIL), for safety-critical systems in motor vehicles.

[0041] The computing unit according to the invention, such as a control device for a motor vehicle, is particularly configured in terms of programming technology to implement the method according to the invention.

[0042] It is also advantageous to implement the method according to the invention in the form of a computer program for carrying out all the method steps or a computer program product with program code, because this results in particularly low costs, especially when the control device being executed can also be used for other tasks and is therefore always available. Suitable data carriers for providing the computer program are, in particular, magnetic, optical, and electrical memories, such as hard disks, flash memory, EEPROM, DVDs, etc. The program can also be downloaded via computer networks (Internet, local area network, etc.).

[0043] Further advantages and design solutions of the present invention are provided in the specification and drawings.

[0044] The present invention is schematically illustrated in the accompanying drawings by means of embodiments and is described below with reference to the drawings. Attached Figure Description

[0045] Figure 1 The illustration shows a preferred design of a computing unit according to the invention, the computing unit being configured to implement a preferred embodiment of the method according to the invention; Figure 2 A preferred embodiment of the method according to the invention is illustrated schematically as a block diagram. Detailed Implementation

[0046] exist Figure 1The diagram schematically illustrates a computing unit, such as a control device, in this example, a vehicle, and is labeled with reference numeral 100.

[0047] The control device 100 has a processor unit with two processor cores 110 and 120. Each of these processor cores 110 and 120 executes multiple processes 111, 112, 113, 114 and 121, 122, 123, 124. Of course, the processor unit can also have more processor cores and can also execute more processes on each processor core.

[0048] The control device 100 may be, for example, a motor control device for controlling the motor of a vehicle. The various processes 111, 112, 113, 114, 121, 122, 123, and 124 may include safety-critical functions for the safe operation of the vehicle and for controlling the machinery.

[0049] Processes 111, 112, 113, 114, 121, 122, 123, and 124 can collectively access resource 130 according to a predetermined resource allocation, such as accessing shared memory units, for example, working memory configured as DRAM. For this purpose, processor cores 110 and 120 are collectively connected to memory 130 via data connections, such as a data bus.

[0050] Shared memory access can cause delays in the execution of individual processes. To combat this delay, resource allocation can be dynamically adjusted during the operation of the control device. For this purpose, the control device is specifically configured in terms of programming techniques to implement, for example, in... Figure 2 The diagram is shown schematically as a block diagram, and a preferred embodiment of the method according to the invention will be explained below.

[0051] In the (preparatory) step 210, the scheduled processing time and processing time extension are assigned to processes 111, 112, 113, 114, 121, 122, 123, and 124, respectively. Each process 111, 112, 113, 114, 121, 122, 123, and 124 should be processed within its assigned scheduled processing time. The actual processing time of each process 111, 112, 113, 114, 121, 122, 123, and 124 should deviate from its assigned scheduled processing time by at most its assigned processing time extension.

[0052] These rated processing times and processing time extensions can be determined, for example, by programmers or software developers during the creation or programming phases of the respective processes 111, 112, 113, 114, 121, 122, 123, 124. When the respective processes are executed in isolation within the computing unit accompanied by exclusive access to memory, the rated processing time can, for example, correspond to the expected runtime. The sum of the rated processing time and processing time extensions can be predetermined as an allowable threshold or limit, and the processing time should extend at most beyond this allowable threshold or limit to avoid instability due to shared access to memory. The rated processing time and processing time extensions are predetermined, particularly based on criticality or priority, and also, particularly, based on the real-time requirements of the respective processes.

[0053] The rated processing time and processing time extension can be described, for example, as absolute time values ​​or relative values. The rated processing time can be predetermined, for example, as a counter value of a performance counter, a hardware performance counter, or a hardware counter, and the processing time extension can be predetermined as a percentage deviation of these counter values. From these counter values, the corresponding runtime or specific time values ​​for the rated processing time and processing time extension are derived using the target hardware platform.

[0054] The rated processing time and processing time extension are stored in the control device 100, specifically in the execution manager 220, which is designed as a software mechanism, software unit, or software module within the control device 100, or, for example, can be configured as a separate hardware module. During the execution of each process 111, 112, 113, 114, 121, 122, 123, 124 in the control device 100, the execution manager 220 determines the current actual processing time, and processes each process 111, 112, 113, 114, 121, 122, 123, 124 within the current actual processing time.

[0055] These current actual processing times are determined, for example, using at least one performance counter. Control device 100 particularly has a monitoring unit 230 with multiple performance counters, hardware performance counters, or hardware counters (performance monitoring counters, PMCs, or PMUs) 231, 232, 233, which, for example, in the form of special registers, measure or count specific processes or activities within control device 100. Execution manager 220 reads information from performance counters 231, 232, 233 and determines, based on this, the current actual processing time of each process 111, 112, 113, 114, 121, 122, 123, 124.

[0056] For example, performance counter 231 can be used to monitor the execution cycle of a process. For example, in an ARM processor architecture, performance counter 232 can measure events 0xE7 / 0xE8 to calculate memory pauses based on write or read operations. Furthermore, performance counter 233 can be used to monitor, for example, Level-2 cache misses and L2 cache write-backs to determine latency due to memory access.

[0057] The execution manager 220 compares the specific actual processing time of each process 111, 112, 113, 114, 121, 122, 123, 124 with the corresponding assigned rated processing time, and further compares it with the sum of the corresponding rated processing time and the corresponding processing time extension. Resource allocation is adjusted based on the result of this comparison. Deviations between the actual time and the assigned rated time particularly imply conflicts during memory access and the resulting processing time delays. Resource allocation is dynamically adjusted based on these deviations.

[0058] During the resource allocation process, the access of each process 111, 112, 113, 114, 121, 122, 123, and 124 to the common memory 130 is regulated in particular by means of different allocation parameters. For this purpose, multiple allocation, control, or organization mechanisms 240 are specifically provided, which assign portions of the resource 130 to each process in different ways according to these allocation parameters. Particularly suitable for this purpose is the provision of multiple QoS modules, QoS mechanisms, or QoS controllers 241, 242, 243, and 244, which regulate the corresponding allocation mechanisms using appropriate allocation parameters.

[0059] Based on the comparison results, one or more allocation parameters are adjusted. Specifically for this purpose, the execution manager 220 converts the rated processing time and processing time extension into QoS-specific rated values ​​or tuning parameters for different hardware and software QoS mechanisms 240. If any actual processing time deviates from the corresponding rated processing time, the execution manager 220 instructs the corresponding QoS controller 240 to adjust the corresponding allocation parameters.

[0060] In step 250, resource allocation is adjusted accordingly, and the processes access common memory 130 based on this adjusted resource allocation. Reference numeral 260 indicates that the current actual processing time is re-determined by performance counter 230 and compared by execution manager 220 with a rated time or permissible extension. Therefore, a control loop can be implemented, and resource allocation can be appropriately and dynamically adjusted or controlled. Execution manager 220 can periodically determine the actual processing time within predetermined monitoring intervals, compare it with predetermined values, and adjust resource allocation accordingly. Furthermore, execution manager 220 can learn, for example, during machine learning, the relationship, interrelationship, or correlation between adjusting various allocation parameters and the resulting changes in the actual processing time of individual processes. This learned relationship can be used to adjust resource allocation in subsequent monitoring intervals. Therefore, resource allocation adjustments can always be improved.

[0061] Each QoS controller manages a specific QoS mechanism and coordinates QoS parameters accordingly. QoS controller 241 may, for example, be configured to adjust memory bandwidth. When, for example, execution manager 220 confirms that the actual processing time of time-critical process 111 deviates from its assigned rated processing time by more than a predetermined processing time extension, execution manager 220 instructs QoS controller 241 to reduce the memory bandwidth assigned to other processes 112, 113, 114, 121, 122, 123, 124 for the duration of the next monitoring interval and instead assign it to the time-critical process 111.

[0062] Furthermore, the QoS manager 242 can be configured, for example, to control interconnection. When the execution manager 220, for example, confirms that a process on a core, such as core 110, exceeds the allowed processing time extension, the execution manager 220 can, for example, instruct the QoS controller 242 to reduce the number of pending services on other cores 120 or increase the priority of services on core 110 for the duration of the next monitoring interval, thereby processing these services more quickly.

[0063] The QoS controller 243 may, for example, manage the cache hierarchy. When the execution manager 220 determines, for example, that the processing time of a time-critical process 111 exceeds the allowed processing time extension, the execution manager 220 may instruct the QoS controller 243 to partition the cache, for example, using a software mechanism such as cache coloring or a hardware mechanism provided by the ARM DynamiQ-CPU architecture. Thus, some parts of the cache are exclusively reserved for process 111, which reduces interference effects.

[0064] Because it may be impossible to simultaneously meet the requirements of all applications in all situations (e.g., due to a sudden increase in contention), the execution manager 220 determines which process takes priority when necessary. This can occur, for example, by specifying a predefined descending order based on criticality and security requirements to ensure the performance of higher-priority processes. When the execution manager 220 determines that the actual processing time of multiple processes deviates from their assigned rated processing time by more than an assigned processing time extension, the execution manager 220 may appropriately increase the assigned processing time extension of lower-priority processes and then execute a rebalancing loop to meet these changed values. Alternatively or additionally, the execution manager 220 may appropriately iteratively adjust resource allocation for each of these processes during the rebalancing loop process, starting with the highest-priority process.

[0065] Therefore, within the scope of the current approach, different QoS parameters can be dynamically adjusted in software / hardware, controlled by information obtained from one or more performance counters (PMCs), to meet the user-defined QoS requirements of the application. For example, information about L2 cache misses and write-backs, or about latching cycles due to resource access, can be used to dynamically configure the budget of shared resources for different processes or processor cores on the interconnect using appropriate software or other QoS mechanisms. Furthermore, measurements of performance counters, such as DDR performance counters or interconnect performance counters, can also be used to dynamically configure different software / hardware QoS mechanisms. Operating system kernel (OS) events can be additionally used, for example, to control the configuration of QoS mechanisms. Thus, the current approach can, in particular, improve average system performance and ensure application performance guarantees.

[0066] The current method can be used to control main memory interference (e.g., measured by cache misses in the last monitoring cycle) and also to control cache interference, for example, when using additional information from performance counters.

[0067] The execution manager is particularly well-suited to self-regulation using current methods, especially based on specified information such as criticality, deadlines, and security boundaries. Users, in particular, only specify QoS requirements without knowing the details of the hardware / software stack. This mechanism is therefore transparent to the user and makes configuration and use less complex from the user's perspective.

Claims

1. A method for running a computing unit (100), in which multiple processes (111, 112, 113, 114, 121, 122, 123, 124) are executed, the processes collectively accessing resources (130) according to a predetermined resource allocation, the method comprising: During the execution of at least one of multiple processes (111, 112, 113, 114, 121, 122, 123, 124), the current actual processing time of at least one of the multiple processes (111, 112, 113, 114, 121, 122, 123, 124) is determined (220, 230), and at least one of the multiple processes (111, 112, 113, 114, 121, 122, 123, 124) is processed within the actual processing time. The actual processing time is compared with the rated processing time assigned to at least one of the multiple processes (111, 112, 113, 114, 121, 122, 123, 124) (230), and / or The actual processing time is compared with the sum of the assigned rated processing time and the processing time extensions assigned to at least one of the multiple processes (111, 112, 113, 114, 121, 122, 123, 124) (230), and... Adjust the predetermined resource allocation (240, 250) based on the comparison results. During resource allocation, different allocation parameters are used to adjust the access of multiple processes (111, 112, 113, 114, 121, 122, 123, 124) to the resource (130). Based on the comparison between the actual processing time and the rated processing time, and / or Based on the comparison between the actual processing time and the sum of the rated processing time and the processing time extension, Adjusting the resource allocation (240, 250) includes (241, 242, 243, 244) adjusting one or more of the allocation parameters.

2. The method according to claim 1, wherein, Implementation (260): Determine the current actual processing time, compare the determined actual processing time with the corresponding assigned rated processing time, and / or compare the determined actual processing time with the sum of the corresponding assigned rated processing time and the corresponding assigned processing time extension, and periodically adjust resource allocation within a predetermined monitoring interval.

3. The method according to claim 1 or 2, in, Adjustments to the resource allocation are made based on whether the actual processing time of at least one of the plurality of processes (111, 112, 113, 114, 121, 122, 123, 124) deviates significantly from the corresponding assigned processing time, and / or adjustments are made to the resource allocation based on whether the actual processing time of at least one of the plurality of processes exceeds the corresponding assigned processing time by an extended period. The resource allocation is adjusted based on the extent to which the actual processing time of at least one of the plurality of processes (111, 112, 113, 114, 121, 122, 123, 124) deviates from the corresponding rated processing time.

4. The method according to claim 1 or 2, wherein, The current actual processing time of at least one of the plurality of processes (111, 112, 113, 114, 121, 122, 123, 124) is determined by using at least one performance counter (231, 232, 233).

5. The method according to claim 1 or 2, further comprising: Determine the relationship between adjusting various allocation parameters and the resulting changes in the actual processing time of at least one of a plurality of processes, and further include: using the determined relationship to adjust the one or more allocation parameters based on the result of a comparison of the actual processing time with the rated processing time and / or based on the result of a comparison of the actual processing time with the sum of the rated processing time and the processing time extension.

6. The method according to claim 1 or 2, wherein, Adjust resource allocation as follows: The portion of the resource assigned to the first process of the plurality of processes is partially or completely assigned (241) to the second process of the plurality of processes. Reduce (242) the number of services to be performed within the predetermined time interval, and / or Increase or decrease (242) the execution priority of a specific process among the plurality of processes, and / or The resource, or at least a portion thereof, is exclusively assigned (243) to a specific process among the plurality of processes, and / or The resources are partitioned and one of the partitions is exclusively assigned (244) to a specific process among the plurality of processes.

7. The method according to claim 1 or 2, wherein, When the actual processing time of many of the plurality of processes (111, 112, 113, 114, 121, 122, 123, 124) deviates significantly from the corresponding assigned processing time, the method includes: Based on the runtime priority of the processes (111, 112, 113, 114, 121, 122, 123, 124), the corresponding assigned processing time of the processes (111, 112, 113, 114, 121, 122, 123, 124) is extended, and / or Resource allocation is iteratively adjusted for each of the processes (111, 112, 113, 114, 121, 122, 123, 124) based on their runtime priority.

8. The method according to claim 1 or 2, wherein, The computing unit is configured as a vehicle control device (100), and the various processes (111, 112, 113, 114, 121, 122, 123, 124) are designed to control vehicle functions.

9. The method according to claim 7, wherein the method comprises: Based on the runtime priority of the processes (111, 112, 113, 114, 121, 122, 123, 124), the corresponding assigned processing time of the processes (111, 112, 113, 114, 121, 122, 123, 124) is extended, wherein the corresponding assigned processing time extension for the lower priority processes is increased by a predetermined value.

10. The method according to claim 7, wherein the method comprises: Resource allocation is iteratively adjusted for each of the processes (111, 112, 113, 114, 121, 122, 123, 124) according to their runtime priority, starting with the process with the highest priority.

11. A computing unit (100) configured to perform all the method steps of the method according to any one of claims 1 to 10.

12. The computing unit (100) according to claim 11, wherein, The computing unit (100) is a vehicle control device.

13. A computer program, when executed on a computing unit (100), causes the computing unit (100) to perform all the method steps of the method according to any one of claims 1 to 10.

14. A machine-readable storage medium having a computer program stored thereon as described in claim 13.

Images