Soft and hardware cooperative task processing and control method based on ARM multi-core architecture

Abstract

The present application belongs to the technical field of computer task processing and resource management, and relates to a software and hardware cooperative task processing and control method based on an ARM multi-core architecture, comprising: obtaining bottom layer running data to generate a state label set; receiving a task allocation instruction and identifying a key code attribute to generate a task constraint event limiting a hardware dependency condition; comparing the hardware constraint and the state label to generate a feasible target core set; calling an operating system scheduling framework to select a target computing core in the feasible set to generate a preliminary scheduling action proposal; intercepting the proposal to issue and project to a hardware event processor for pre-verification; if verification is rejected, updating the feasible set by analyzing hardware feedback parameters; and if verification is allowed, performing joint control of a closed loop by aggregating task migration and bottom layer power adjustment actions. The present application solves the problem that an operating system scheduler makes a suboptimal scheduling decision in a dynamic complex scene due to lack of real-time state perception and prospective influence evaluation at the micro-architecture layer.

Description

Technical Field

[0001] This invention belongs to the technical field of computer task processing and resource management, and relates to a software and hardware collaborative task processing and control method based on ARM multi-core architecture. Background Technology

[0002] Multi-core processors based on the ARM architecture are widely used in current computing devices to meet device performance requirements. The operating system scheduler is responsible for allocating software tasks to the corresponding computing cores for execution. This process must meet task performance requirements while also taking into account the power consumption and heat dissipation of the processing device. Due to the dynamic changes in task behavior characteristics and the real-time fluctuations in the underlying operating states of each processor core, these characteristics involving computing power, storage, and temperature together constitute a complex, multi-variable allocation environment.

[0003] Existing solutions primarily rely on software scheduling frameworks at the operating system kernel level to allocate tasks. These mechanisms mainly formulate scheduling strategies based on observable macroscopic statistical metrics at the software level, including historical task execution time, priority, and average core load. The scheduler tracks the average task load, migrating high-load tasks to more powerful cores and reserving low-load tasks on more energy-efficient cores. Simultaneously, it incorporates dynamic frequency scaling techniques to adjust overall power consumption, thereby providing a conventional resource allocation mechanism.

[0004] The aforementioned scheduling frameworks, which rely on macroscopic statistical indicators at the software layer, exhibit certain response lags and assessment biases when dealing with dynamic and complex loads. Because their decisions are largely based on the average load over a long time window, the scheduler is slow to perceive instantaneous changes in task behavior and real-time fluctuations in the processor's microarchitecture. In specific scenarios, bottlenecks caused by insufficient underlying storage often manifest as high occupancy at the system level, leading conventional strategies to classify them as computationally intensive tasks and allocate them to high-frequency cores. This not only fails to improve execution efficiency but also increases additional power consumption. Furthermore, conventional scheduling often lacks advance assessment of the underlying hardware-related impacts of execution actions, and the information barrier between software decisions and the actual hardware state limits the overall energy efficiency of the system. Summary of the Invention

[0005] To address the aforementioned problems, this invention provides a hardware and software collaborative task processing and control method based on an ARM multi-core architecture.

[0006] A hardware-software collaborative task processing and control method based on ARM multi-core architecture includes the following steps:

[0007] S1. Obtain the underlying operating data of the multi-core processor, execute the state transition logic, and generate a set of real-time state labels describing the current performance state of each computing core.

[0008] S2. Receive the task allocation instruction from the system kernel, identify the key code attributes of the target task, and generate task constraint events that limit the hardware dependencies of the target task during runtime.

[0009] S3. Extract the hardware constraint requirements from the task constraint events, and compare the hardware constraint requirements with the set of immediate status labels to generate a set of feasible target cores belonging to the target task.

[0010] S4. Invoke the operating system's scheduling framework, select the target computing core from the feasible target core set, and generate a preliminary scheduling action proposal containing task migration path attributes.

[0011] S5. Intercept the issuance of the preliminary scheduling action proposal, project the preliminary scheduling action proposal to the hardware event handler for pre-verification, and generate hardware verification results.

[0012] S6. In response to the hardware verification result triggering a rejection scheduling instruction, parse the correction strategy parameters fed back by the underlying hardware, update the feasible target core set, and return to execute step S4.

[0013] S7. In response to the hardware verification result triggering the scheduling instruction, based on the preliminary scheduling action proposal, the task migration operation and the underlying power adjustment action are aggregated to execute the joint control atomic operation closed loop issued by the software and hardware.

[0014] A further aspect of the present invention, step S1, includes the following steps:

[0015] Continuously capture the raw architecture event stream of each computing core. The raw architecture event stream includes the number of instructions per cycle, multi-level cache miss rate, and instruction queue depth parameters.

[0016] By utilizing the embedded hardware event filter and policy mapping unit, the original architecture event stream is filtered and counted according to a preset triggering cycle to obtain the filtered architecture parameter set;

[0017] Based on the preset event state transition rules, the state threshold triggered by the filtered architecture parameter set is determined, and the physical energy efficiency state corresponding to each computing core is marked. The set of real-time state labels corresponding to each computing core is then generated.

[0018] A further aspect of the present invention, step S2, includes the following steps:

[0019] During the creation and execution cycle of the target task, the software task profiler parses the code segment corresponding to the target task, counts the frequency of hardware accesses triggered, and generates a historical behavior profile.

[0020] Identify pre-configured hardware event concern patterns in code segments that are sensitive to core instruction throughput or memory bandwidth.

[0021] In response to the processor's instruction decoding unit executing a key code sequence that conforms to the hardware event concern pattern, a task constraint event declaring the rigid requirements of task performance is sent to the embedded hardware event filter and policy mapping unit.

[0022] A further aspect of the present invention, step S3, includes the following steps:

[0023] Extract hardware state avoidance parameters from task constraint events that describe the real-time performance of instruction execution;

[0024] The hardware state avoidance parameters are input into the hardware decision closed-loop channel and compared with the physical energy efficiency status of each computing core in the real-time state label set.

[0025] From the pre-defined list of globally available processor cores, remove restricted core entities with tags that conflict with hardware state avoidance parameters, obtain the remaining matching entities, and construct a set of feasible target cores based on the matching entities.

[0026] A further aspect of the present invention, step S4, includes the following steps:

[0027] Obtain the current logical load queue status and throughput margin space of each pre-selected computing unit entity within the feasible target core set;

[0028] The underlying operating system uses a task priority-based scheduling algorithm to calculate the execution latency weight of each pre-selected computing unit entity based on the current logical load queue status and throughput margin.

[0029] Within the feasible target core set, select the pre-selected computational unit entity of the target execution delay weight as the target computation core;

[0030] Spatial binding mapping is performed between the task identifier of the target task and the physical addressing identifier of the target computing core to generate a preliminary scheduling action proposal.

[0031] A further aspect of the present invention, step S5, includes the following steps:

[0032] In response to the timing node of the first clock cycle of the task migration interruption, the preliminary scheduling action proposal is submitted to the hardware event filter and policy mapping unit in the form of register pass-through data packet;

[0033] The projection assessment evaluates the target power consumption increment and cache contention probability caused by the target task being scheduled to the target computing core according to the task migration path attributes.

[0034] Determine whether the target power consumption increment and cache contention probability exceed the preset hard real-time security and performance thresholds;

[0035] Based on the judgment result, the output is a hardware verification result indicating whether scheduling is allowed or denied, along with a control frame for alternative repair schemes.

[0036] A further aspect of the present invention, step S6, includes the following steps:

[0037] Receive the security verification feedback credential carrying a veto signal returned by the hardware event filter and policy mapping unit to the scheduling framework;

[0038] The core list of suggested states is fed down along with the rejection signal in the security verification feedback certificate. The core list of suggested states includes the recommended nodes calculated and filtered after removing the nodes that have just been rejected from the original set of feasible target cores by using the current instantaneous wafer thermal capacity margin parameter.

[0039] Call the available node parameters in the suggested state core list to overwrite and replace the original set of feasible target cores;

[0040] Carrying the updated set of feasible target cores, the execution program jumps back to step S4.

[0041] A further aspect of the present invention, step S7, includes the following steps:

[0042] Receive the permission signal returned based on the security verification rules, solidify and lock the data path relationship for the transfer mapping from the target task to the target computing core;

[0043] Retrieve historical behavior profiles of the target task, fit and generate hardware microcontroller instruction packages for the dynamic voltage frequency adjustment module;

[0044] The on-chip system bus controller is invoked to merge and package the inter-core interrupt instruction that triggers the scheduling transfer with the hardware microcontroller instruction package;

[0045] Within the same bus transaction, transmission operations are performed according to strict clock synchronization timing characteristics, completing the joint control atomic operation closed loop.

[0046] A further aspect of this invention involves projecting and evaluating the target power consumption increment and cache contention probability, specifically including:

[0047] Based on the task identifier code of the target task, obtain the historical behavior profile of the target task, and extract the task computing activity factor and the task memory access intensity factor.

[0048] Based on the physical addressing identifier of the target computing core, obtain the current voltage, frequency, and memory controller bus utilization of the target computing core;

[0049] The task activity factor is multiplied by the square of the current voltage and the current frequency, and then multiplied by a preset power consumption coefficient to obtain the target power consumption increment.

[0050] The cache contention probability is obtained by multiplying the task memory access intensity factor by the memory controller bus utilization and then multiplying by a preset weighting coefficient.

[0051] A further aspect of this invention involves calculating and selecting recommended nodes based on the current instantaneous wafer thermal capacity margin parameter, specifically including:

[0052] Real-time readings of digital temperature sensors from all on-chip computing cores are retrieved to obtain the current temperature.

[0053] The difference between the preset maximum allowable chip junction temperature and the current temperature is calculated to obtain the current instantaneous wafer thermal capacity margin parameters for each corresponding computing core.

[0054] After removing the rejected scheduling target node from the original feasible target core set, determine whether the current instantaneous wafer thermal capacity margin parameter corresponding to each remaining computing core in the set is greater than the preset safety margin threshold.

[0055] Calculation cores whose judgment results are greater than the safety margin threshold are retained as recommended nodes, and all recommended nodes are aggregated to generate a list of suggested state cores.

[0056] In summary, the present invention has the following beneficial technical effects:

[0057] 1. This invention constructs a core state awareness mechanism at the hardware level to dynamically capture the microarchitectural event stream of the underlying computing core and convert it into tags corresponding to physical energy efficiency states according to preset rules. This mechanism utilizes objective hardware behavior data such as the number of instruction cycles and cache status at the underlying level to abstract operational characteristics recognizable by the scheduler within a short timescale. This design provides upper-layer software scheduling logic with data input reflecting the real-time operating status of the hardware, overcoming the limitations of traditional scheduling frameworks that rely solely on macroscopic lagging indicators such as historical average load, and improving the timeliness and accuracy of scheduling decisions.

[0058] 2. This invention employs a task attribute identification and hardware constraint pre-processing mechanism to pre-screen hardware execution environments that match the task processing characteristics before executing scheduling decisions. Based on the operational characteristics of the task's critical code sequences, corresponding hardware dependency constraint events are generated, thereby initially eliminating computing cores with conflicting current operating states at the hardware level. This approach provides the operating system scheduler with a set of feasible cores that have undergone hardware-level matching checks, reducing the allocation space for ineffective scheduling, decreasing the occurrence of misallocation of tasks to unsuitable hardware environments, and helping to improve the operational determinism and performance during actual task execution.

[0059] 3. This invention introduces a hardware pre-verification and closed-loop iterative correction process for scheduling proposals. Before the operating system officially issues scheduling instructions, a preliminary scheduling proposal is projected onto the hardware system for verification of the expected impact. By comparing the potential power consumption increment and resource contention risks after scheduling are issued with the set safety thresholds, and if the pre-verification fails, a core list of suggestions is fed back based on underlying real-time physical parameters such as thermal capacity margin, guiding the software scheduling logic to make corrections. This hardware-software collaborative closed-loop adjudication mechanism not only prevents potential thermal overshoot or hardware preemption risks, but also ensures the reliability of resource allocation in the processing system under dynamic and complex load environments. Attached Figure Description

[0060] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. The drawings are used to provide a further understanding of the present invention.

[0061] Figure 1 A flowchart illustrating an embodiment of this application is disclosed.

[0062] Figure 2 Structural schematic diagrams of embodiments of this application are disclosed. Detailed Implementation

[0063] The following is in conjunction with the appendix Figures 1-2 A preferred description of the present invention is provided below.

[0064] See attached document Figure 1 This invention proposes a hardware and software collaborative task processing and control method based on ARM multi-core architecture, including the following steps:

[0065] S1. Obtain the underlying operating data of the multi-core processor, execute the state transition logic, and generate a set of real-time state labels describing the current performance state of each computing core.

[0066] S2. Receive the task allocation instruction from the system kernel, identify the key code attributes of the target task, and generate task constraint events that limit the hardware dependencies of the target task during runtime.

[0067] S3. Extract the hardware constraint requirements from the task constraint events, and compare the hardware constraint requirements with the set of immediate status labels to generate a set of feasible target cores belonging to the target task.

[0068] S4. Invoke the operating system's scheduling framework, select the target computing core from the feasible target core set, and generate a preliminary scheduling action proposal containing task migration path attributes.

[0069] S5. Intercept the issuance of the preliminary scheduling action proposal, project the preliminary scheduling action proposal to the hardware event handler for pre-verification, and generate hardware verification results.

[0070] S6. In response to the hardware verification result triggering a rejection scheduling instruction, parse the correction strategy parameters fed back by the underlying hardware, update the feasible target core set, and return to execute step S4.

[0071] S7. In response to the hardware verification result triggering the scheduling instruction, based on the preliminary scheduling action proposal, the task migration operation and the underlying power adjustment action are aggregated to execute the joint control atomic operation closed loop issued by the software and hardware.

[0072] In one embodiment of the present invention, step S1 includes the following steps:

[0073] Continuously capture the raw architecture event stream of each computing core. The raw architecture event stream includes the number of instructions per cycle, multi-level cache miss rate, and instruction queue depth parameters.

[0074] By utilizing the embedded hardware event filter and policy mapping unit, the original architecture event stream is filtered and counted according to a preset triggering cycle to obtain the filtered architecture parameter set;

[0075] Based on the preset event state transition rules, the state threshold triggered by the filtered architecture parameter set is determined, and the physical energy efficiency state corresponding to each computing core is marked. The set of real-time state labels corresponding to each computing core is then generated.

[0076] Specifically, the method for acquiring the low-level operational data of the multi-core processor, executing state transition logic, and generating a set of real-time state labels describing the current performance state of each computing core is performed by the hardware event filter and policy mapping unit embedded in the multi-core processor. This unit is a dedicated hardware coprocessor, such as the system control processor in the ARM architecture, which runs independently of the main operating system to ensure low-latency characteristics for data acquisition and processing. The hardware event filter and policy mapping unit is a microcontroller or programmable logic array integrated within the system-on-a-chip, possessing independent processing capabilities. It directly accesses the performance monitoring unit registers of each computing core through the hardware bus.

[0077] First, the hardware event filter and policy mapping unit continuously reads and aggregates the raw architectural event stream by accessing the performance monitoring units within each computing core. This event stream is a real-time updated data structure containing raw counts for each computing core within a specific time window, including the cumulative number of instruction retirements, processor clock cycles, total accesses and misses of the L2 and L3 caches, and the average occupancy depth of the instruction issue queue. It should be understood that the raw architectural event stream data structure is a set of multivariate time-series vectors associated with core identifiers, each vector containing raw counts such as the number of instruction retirements and clock cycles.

[0078] Next, the hardware event filter and policy mapping unit, under its internal clock control, processes the collected raw architecture event stream according to a preset trigger cycle. In this embodiment, the trigger cycle is set from 1 microsecond to 100 microseconds. The selection of this cycle is based on the ability to capture at least several microarchitectural-level state fluctuations within the operating system scheduling time slice, thereby providing high-time-resolution state input for subsequent scheduling decisions. Assuming the application scenario is industrial control with high real-time requirements, the trigger cycle is set to 10 microseconds. The processing includes: calculating the number of instructions retired within the time window and the number of clock cycles to obtain the number of instructions per cycle; calculating the multi-level cache miss rate by calculating the number of cache misses and the total number of accesses. Further, the number of instructions per cycle in the filtered architecture parameter set... With multi-level cache miss rate The calculation process can be expressed by the following formula:

[0079]

[0080]

[0081] In the formula, This represents the total number of retired instructions counted by the hardware performance monitoring unit within a trigger cycle, expressed in terms of instructions. This represents the total number of processor clock cycles counted within the same trigger cycle, expressed in units of cycles. This indicates the total number of multi-level cache miss events that occur within the same trigger cycle, expressed in times. This indicates the total number of accesses to the multi-level cache within the same trigger cycle, expressed in times.

[0082] To eliminate noise caused by instantaneous data jitter, this unit performs a time-window smoothing filter algorithm, such as a moving average or exponentially weighted moving average, on a series of calculated parameter values ​​to generate a stable set of filtered architecture parameters that reflects recent core operating characteristics. and Perform a moving average filter to obtain the smoothed parameters. and :

[0083]

[0084]

[0085] in, This represents the sequence number of the current time window, while This is the number of samples in the time window used for moving average filtering. It is a preset integer. The number of samples N in the time window for moving average filtering is usually set to 5, which aims to balance the smoothness of data and the real-time nature of state updates.

[0086] Finally, the hardware event filter and policy mapping unit invokes its internally embedded preset event state transition rules. This rule base is essentially a collection of multi-dimensional conditional judgment logic, comparing each parameter in the filtered architecture parameter set with a set of preset state thresholds. It should be noted that the event state transition rules are based on the mapping relationship between microarchitecture parameters and core operating states, summarized after extensive benchmarking of the target processor architecture. When a combination of parameters satisfies the triggering condition of a rule, the unit labels the corresponding computing core with a predefined physical energy efficiency state tag. For example, physical energy efficiency states can be divided into four types: compute-intensive state, triggered by a smoothed instruction count per cycle greater than 2.5 and a smoothed cache miss rate less than 1%; memory-constrained state, triggered by a smoothed instruction count per cycle less than 1.0 and a smoothed cache miss rate greater than 5%; balanced load state, a state between the first two; and compute-idle state, triggered by a smoothed instruction count per cycle less than 0.2. After traversing all monitored computing cores, this process combines the identifiers of each core with their corresponding physical energy efficiency status tags to ultimately generate and output a structured, global, real-time status tag set for subsequent steps.

[0087] For example, suppose a dual-core processor, consisting of core 0 and core 1, has a trigger cycle of 10 microseconds. Within a certain trigger cycle, the hardware event filter and policy mapping unit reads the instruction retirement count from the performance monitoring unit of core 0. For 30,000, the number of clock cycles The number is 10,000; the instruction retirement number is read from the performance monitoring unit of Core 1. 8000 lines, number of clock cycles The number is 10,000. Simultaneously, the number of multi-level cache misses on core 0 is read. For 50 visits, the total number of visits is [number missing]. The number of times the multi-level cache misses occurred was 6000; 800 visits, total number of visits The number of iterations is 10,000. First, the number of instructions per cycle for core 0 is calculated. The multi-level cache miss rate is 3.0. It is 0.83%. Instructions per cycle for Core 1. The multi-level cache miss rate is 0.8. The value is 8%. Next, assuming the current period is the t-th period, a moving average filter with N = 5 is used. For simplicity, it is assumed that the calculated values ​​of the previous four periods are close to the current value, then the smoothing parameter after filtering is... Approximately 3.0, Approximately 0.83%; smoothing parameter Approximately 0.8, Approximately 8%. Subsequently, the hardware event filter and policy mapping unit apply these smoothed parameters to the event state transition rules. For core 0, its... Greater than 2.5 and Less than 1%, meeting the triggering conditions for a computationally intensive state, and therefore marked as such. For core 1, its Less than 1.0 and If the value is greater than 5%, the trigger condition for a memory-constrained state is met, and therefore it is marked as a memory-constrained state. Finally, step S1 is completed, and the generated and output set of immediate state labels is: {Core 0: Computationally intensive state, Core 1: Memory-constrained state}.

[0088] In one embodiment of the present invention, step S2 includes the following steps:

[0089] During the creation and execution cycle of the target task, the software task profiler parses the code segment corresponding to the target task, counts the frequency of hardware accesses triggered, and generates a historical behavior profile.

[0090] Identify pre-configured hardware event concern patterns in code segments that are sensitive to core instruction throughput or memory bandwidth.

[0091] In response to the processor's instruction decoding unit executing a key code sequence that conforms to the hardware event concern pattern, a task constraint event declaring the rigid requirements of task performance is sent to the embedded hardware event filter and policy mapping unit.

[0092] Specifically, the method for receiving task allocation instructions from the system kernel, identifying key code attributes of the target task, and generating task constraint events that limit the hardware dependencies of the target task at runtime is executed collaboratively by the software task profiler in the operating system kernel and the instruction decoding unit inside the processor core. This process begins with the operating system kernel scheduler responding to a task creation or wake-up request and deciding to put a target task into execution. During the creation and execution cycle of the target task, the software task profiler is activated. It performs static analysis and runtime monitoring of the target task's code segment as it is mapped into memory by hooking the kernel's process loading module. The software task profiler is a kernel module that is invoked during the system call processing flow of task creation.

[0093] During the static analysis phase, the profiler scans the instruction sequence of the code, calculates the ratio of memory access instructions to arithmetic and logic instructions, and identifies a piece of metadata generated by the compiler based on specific annotations or primitives in the source code. This metadata defines the hardware event concern pattern. It should be noted that a hardware event concern pattern is an attribute set by the developer in the high-level language code using specific keywords or compiler directives. This attribute is encoded into a specific section of the executable file after compilation. A critical code sequence refers to the machine code address range corresponding to the code block marked with this attribute.

[0094] During the runtime monitoring phase, within the initial few execution time slices of the target task, the profiler further verifies and quantifies its memory access behavior and computational intensity by sampling hardware performance counters. The analysis results are then integrated into a structured historical behavior profile, which is stored in the process control block maintained by the kernel for this task. In this embodiment, the historical behavior profile is a data structure that includes at least statistical characteristics such as the percentage of memory instructions, the percentage of floating-point instructions, and the branch prediction error rate.

[0095] When the operating system schedules a target task to be executed on a computing core, the task's context switch loads the identifier code of the hardware event concern mode into the core's dedicated control register. Subsequently, the core's instruction decoding unit, while decoding and executing instructions one by one, continuously monitors whether the current program counter has entered the address range of the critical code sequence associated with the hardware event concern mode. Once a match is found, the triggering condition is met, and the instruction decoding unit bypasses the operating system, immediately sending a task constraint event containing the task identifier and performance requirement type to the hardware event filter and policy mapping unit via a dedicated hardware signal path, thereby declaring the task's rigid performance requirements at this critical stage. It should be understood that the task constraint event is a specific formatted data packet transmitted on the on-chip system bus, generated by the instruction decoding unit, with its target address being the hardware event filter and policy mapping unit. The generation latency of this event is within several clock cycles, far lower than the interrupt handling latency at the operating system level.

[0096] For example, continuing with the scenario in S1 above, the immediate state label set is {Core 0: Computation-intensive state, Core 1: Memory-constrained state}. At this time, the system kernel receives a target task identified as Task_FFT, which is responsible for performing the critical Fast Fourier Transform calculation. When the target task is loaded, the software task profiler analyzes its code segment. The analysis results show that the ratio of memory access instructions to computation instructions for this task is 0.7, indicating that it has high memory bandwidth requirements. Simultaneously, the profiler identifies from the metadata of the task's executable file that its core loop code segment has been marked as memory bandwidth sensitive by the developer; this is its hardware event concern pattern. Based on this, the profiler generates a historical behavior profile containing this information. Next, the operating system scheduler initially decides to schedule Task_FFT for execution on Core 1. During task context switching, the identifier code representing memory bandwidth sensitivity is written to the dedicated control register of Core 1. When Task_FFT begins execution, and its program counter enters the marked core loop code segment, the instruction decoding unit of Core 1 detects this situation and immediately triggers and generates a task constraint event. The event is sent directly to the hardware event filter and policy mapping unit via the hardware bus. The data structure of the event content is {Task Identifier: Task_FFT, Performance Rigidity Requirement: Avoid Memory-Constrained States}. This step provides precise constraint input from the task level for subsequent hardware-level scheduling decisions.

[0097] In one embodiment of the present invention, step S3 includes the following steps:

[0098] Extract hardware state avoidance parameters from task constraint events that describe the real-time performance of instruction execution;

[0099] The hardware state avoidance parameters are input into the hardware decision closed-loop channel and compared with the physical energy efficiency status of each computing core in the real-time state label set.

[0100] From the pre-defined list of globally available processor cores, remove restricted core entities with tags that conflict with hardware state avoidance parameters, obtain the remaining matching entities, and construct a set of feasible target cores based on the matching entities.

[0101] Specifically, the method of extracting task-level hardware constraint requirements, comparing them with the full set of core states at the hardware level, and constructing a dynamically reduced feasible target core set specific to the target task is further executed by the hardware event filter and policy mapping unit. Upon receiving the task constraint event from the instruction decoding unit, this unit first parses its data structure and extracts the field used to define the rigid requirements of task performance; this field is the hardware state avoidance parameter. The hardware state avoidance parameter is an enumerated value or bitmask parsed from the data packet of the task constraint event, encoding one or more physical energy efficiency states that the task needs to avoid, such as "avoid memory-constrained states" or "avoid high-heat states."

[0102] Subsequently, within its internal hardware decision-making closed-loop channel, this unit compares the extracted hardware state avoidance parameters with the internally stored set of instantaneous state tags, which is updated in real-time by step S1. It should be understood that the hardware decision-making closed-loop channel is a set of hard-wired logic or microcode programs within the hardware event filter and policy mapping unit, used to implement the aforementioned parsing, comparison, and filtering functions. Its entire execution process is completed at the hardware clock cycle level. This comparison process is performed in a traversal manner, that is, sequentially reading the current physical energy efficiency state tag of each computing core in the instantaneous state tag set and logically matching it with the hardware state avoidance parameters to identify restricted core entities with conflicting states. The hardware event filter and policy mapping unit is based on a pre-stored list of globally available processor cores, which contains all physically available computing cores in the system. It should be noted that the list of globally available processor cores is determined during system initialization and written into the configuration register of the hardware event filter and policy mapping unit, representing all physically existing and not disabled cores.

[0103] During the traversal and comparison process, once a conflict is determined between the current state of a core and the hardware state avoidance parameters, the unit removes the core's identifier from the temporary list of available cores. Conflict determination is an exact match process; for example, if a core's physical energy efficiency state label is "memory-constrained state," while the hardware state avoidance parameter is "avoid memory-constrained state," then a conflict is determined. After the traversal is complete, the core entities remaining in the temporary list constitute a subset that satisfies the task's hardware constraints. The unit ultimately solidifies this subset and outputs it as a set of feasible target cores, serving as the hardware space boundary for subsequent software scheduling decisions.

[0104] In this embodiment, the feasible target core set The construction process can be described using set operations:

[0105]

[0106] in, The core set representing state conflicts is defined as follows:

[0107]

[0108] In the formula, A complete set representing the list of globally available processor cores. It is a set One of the elements represents the specific computational core. It is a mapping function used to obtain the kernel. The physical energy efficiency state corresponding to the instantaneous state label set. It represents the set of states that need to be avoided, as specified by the hardware state avoidance parameters. That is and The difference set contains the core of all current states that do not conflict with task requirements.

[0109] For example, continuing the scenario described above, the hardware event filter and policy mapping unit receives a task constraint event generated for Task_FFT, the content of which is {task identifier: Task_FFT, performance rigidity requirement: avoid memory-constrained states}. First, this unit extracts the hardware state avoidance parameters from this event, namely "avoid memory-constrained states," thus forming a set of avoidance states. The current state is {memory-constrained state}. Next, the unit retrieves its internally stored set of immediate state tags, which is {core 0: compute-intensive state, core 1: memory-constrained state}, and a list of globally available processor cores, which is {core 0, core 1}. Then, the unit initiates a comparison process. For core 0, its current state is "compute-intensive state", which is not in the avoidance state set. Therefore, there is no conflict. For core 1, its current state is a "memory-constrained state," which is consistent with the set of avoidance states. The elements in the list do not match, therefore a conflict is identified. Based on the comparison results, Core 1 is identified as a restricted core entity and removed from the available list. Finally, the hardware event filter and policy mapping unit constructs and outputs a set of feasible target cores specific to Task_FFT in this scheduling cycle, based on the retained core entities, with the content being {Core 0}.

[0110] In one embodiment of the present invention, step S4 includes the following steps:

[0111] Obtain the current logical load queue status and throughput margin space of each pre-selected computing unit entity within the feasible target core set;

[0112] The underlying operating system uses a task priority-based scheduling algorithm to calculate the execution latency weight of each pre-selected computing unit entity based on the current logical load queue status and throughput margin.

[0113] Within the feasible target core set, select the pre-selected computational unit entity of the target execution delay weight as the target computation core;

[0114] Spatial binding mapping is performed between the task identifier of the target task and the physical addressing identifier of the target computing core to generate a preliminary scheduling action proposal.

[0115] Specifically, the method of invoking the operating system's software-layer logic-based scheduling framework to select target nodes within the limited available hardware space and generate preliminary scheduling action proposals is executed by the main scheduler module in the operating system kernel. First, the main scheduler receives the set of feasible target cores passed by the hardware event filter and policy mapping unit, and uses this as the sole candidate core pool for decision-making within the current scheduling cycle. Then, for each core entity in the feasible target core set—that is, the pre-selected computing unit entity—the main scheduler obtains its current logical load queue state and throughput capacity by accessing the dedicated run queue data structure maintained by each core in the kernel. It should be noted that the current logical load queue state refers to the total number of tasks in a run queue of a specific core that are runnable at the time of the scheduling decision. Throughput capacity refers to the proportion of time a core has been idle within a short time window, such as the past 10 milliseconds; this value reflects the core's immediate available computing power.

[0116] The master scheduler runs its built-in task-priority-based scheduling algorithm, which calculates an execution latency weight for each pre-selected computational unit entity. In this embodiment, for each pre-selected computational unit entity... Calculate execution delay weights The process can be represented by the following formula:

[0117]

[0118] Select target computing core The decision-making process is as follows:

[0119]

[0120] In the formula, Represents the core set of feasible objectives The pre-selected computational unit entity in the process. It is the core The execution latency weight is such that the smaller the value, the better the core is. It is the core The current logical load queue status, i.e., the number of tasks in its run queue. It represents the maximum number of tasks that a single core run queue in the system can handle, and is used for normalization. It is the core The throughput margin is expressed as a percentage of idle time, with a value ranging from 0 to 1. It is a preset weighting coefficient, with a value ranging from 0 to 1, used to balance the impact of queue length and real-time load. The choice of operation representation makes The core with the smallest value As the ultimate target computing core .

[0121] The weight calculation combines core load and task priority to quantify the expected waiting and execution time after scheduling the target task to that core. After calculation, the scheduler selects the core with the lowest execution latency weight from the set of feasible target cores. It should be understood that task priority-based scheduling algorithms are standard scheduling logic built into operating systems, such as the Completely Fair Scheduler in the Linux kernel; however, in this invention, their selection is strictly limited by the set of feasible target cores provided by the hardware. The execution latency weight is a dimensionless comprehensive score used to make a suitable software-level selection among multiple cores that meet hardware constraints. Weight coefficient The system administrator preset it to 0.6, indicating that the decision-making process places more emphasis on the long latency impact caused by the number of queued tasks.

[0122] Finally, the master scheduler creates a data structure as a preliminary scheduling action proposal, and fills the target task's task identifier and the physical addressing identifier of the selected target computing core into this structure, completing the space binding mapping. This proposal also includes task migration path attributes, clarifying the source and target cores of the task, providing a basis for subsequent migration operations. The preliminary scheduling action proposal is a temporary data object created in kernel memory, containing the task identifier, source core identifier, and target core identifier.

[0123] For example, to more clearly illustrate the selection process, assume a quad-core system. In the aforementioned steps, the feasible target core set generated for Task_FFT is {core 0, core 2, core 3}. After receiving this set, the operating system's main scheduler begins to acquire the status of each core. The acquired information includes: the current logical load queue status of core 0. For 3 tasks, throughput capacity It is 0.1; Core 2 For 1 task, It is 0.6; Core 3 For 0 tasks, The value is 0.95. Assume the system's run queue has a maximum number of tasks. 10. Weighting coefficient The weight is 0.6. The scheduler then calculates the execution latency weight for each core. For core 0, its weight is... For core 2, its weight For core 3, its weight By comparing the three weight values, the scheduler found that core 3, with a weight of 0.02, had the smallest weight. Therefore, the scheduler selected core 3 as the target computing core from the set of feasible target cores. Finally, the scheduler generated a preliminary scheduling action proposal, the contents of which are {task identifier: Task_FFT, target computing core physical address identifier: Core3_ID, task migration path attribute: {source core: NULL, target core: Core3_ID}}, where NULL for the source core indicates that this is the first scheduling of a newly created task.

[0124] In one embodiment of the present invention, step S5 includes the following steps:

[0125] In response to the timing node of the first clock cycle of the task migration interruption, the preliminary scheduling action proposal is submitted to the hardware event filter and policy mapping unit in the form of register pass-through data packet;

[0126] The projection assessment evaluates the target power consumption increment and cache contention probability caused by the target task being scheduled to the target computing core according to the task migration path attributes.

[0127] Determine whether the target power consumption increment and cache contention probability exceed the preset hard real-time security and performance thresholds;

[0128] Based on the judgment result, the output is a hardware verification result indicating whether scheduling is allowed or denied, along with a control frame for alternative repair schemes.

[0129] Specifically, the method of intercepting software-layer scheduling instructions, projecting scheduling allocation logic to the hardware event handler, and generating hardware verification results for adjudicating scheduling safety and reliability is completed collaboratively by the operating system scheduler and the hardware event filter and policy mapping unit. When the operating system scheduler is ready to execute a preliminary scheduling action proposal, it does not directly issue an inter-core interrupt instruction for task migration. Instead, at the timing node of the first clock cycle in response to the issuance of the task migration interrupt, it encapsulates the content of the preliminary scheduling action proposal into a register pass-through data packet and writes it into a set of configuration registers dedicated to software-hardware interaction. The register pass-through data packet is a technique that directly maps data structures in software memory to the hardware register address space, achieving low-latency data exchange. This write action triggers a hardware signal, activating the hardware event filter and policy mapping unit to enter the pre-verification process. This unit first parses the register pass-through data packet to obtain the task identifier, source core, and target core.

[0130] Based on the task identifier code of the target task, this unit reads the historical behavior profile generated in step S2 from a specific area of ​​system memory, and retrieves the current microarchitectural state of the target computing core from its internal cache based on the physical addressing identifier of the target core. Then, the unit executes a projection evaluation algorithm, which fits the resource consumption characteristics of the task with the carrying capacity of the target core to calculate two key correlation indicators: target power consumption increment and cache contention probability. In this embodiment, the target power consumption increment... probability of contention with cache The projective evaluation model can be expressed by the following formula:

[0131]

[0132]

[0133] The logic for verification and judgment is as follows:

[0134]

[0135] In the above formula, This is a power consumption factor that is related to the processor's process technology and architecture. This represents the task activity factor extracted from historical behavioral profiles. and These are the current voltage and frequency of the target computing core, respectively. These are the weighting coefficients calibrated for the system. This represents the task memory access intensity factor extracted from historical behavior profiles. This represents the utilization rate of the memory controller bus currently connected to the target computing core; this value can be obtained directly from the hardware performance monitoring unit. The function is used to ensure that the calculated probability value converges strictly within the absolute upper limit of 1. and These are the power consumption threshold and cache contention threshold in the hard real-time security and performance thresholds. This represents a logical AND operation. The final verification result Result is true only when both conditions are met simultaneously, thus allowing scheduling.

[0136] After the calculations are complete, the unit compares the results of these two metrics with a set of preset hard real-time security and performance thresholds stored internally. If all metrics are within the thresholds, the calculation is considered successful. Conversely, if any metric exceeds the threshold, the calculation is considered a violation. The target power consumption increment calculation model aims to characterize the absolute contribution of dynamic power consumption introduced by the task itself after it is loaded into the core. It is based on the physical principle that dynamic power consumption is proportional to the sum of the squares and first powers of voltage and frequency, and the task's computational activity factor. Analysis of instruction type distribution in its historical behavior profile reveals a range between 0 and 1. The cache contention probability model quantifies the likelihood of performance conflicts occurring when a memory-intensive task is scheduled onto a core with an already busy memory bus. The hard real-time safety and performance thresholds are set based on the processor's thermal design power limitations and the application scenario's requirements for maximum tolerable latency; for example, in autonomous driving systems... It may be set so that the instantaneous power consumption of a single core does not exceed 80% of its thermal design power (TDP). This requires that the increase in cache miss rate caused by new tasks does not exceed 5%.

[0137] Finally, the hardware event filter and policy mapping unit generates a structured hardware verification result based on the judgment result, and returns the result to the operating system scheduler via hardware interrupt or status register write-back. It should be understood that the hardware verification result is a data structure containing a Boolean decision value (allow or deny) and a control frame for optional alternative repair schemes, used to guide subsequent scheduling behavior.

[0138] For example, continuing with the scenario in S4, the operating system scheduler adopts a preliminary scheduling proposal to schedule Task_FFT to Core 3. The scheduler writes this proposal {Task ID: Task_FFT, Target Computation Core Physical Addressing Identifier: Core3_ID} into the interaction register, triggering a pre-verification by the hardware event filter and policy mapping unit. This unit first retrieves the historical behavior profile of Task_FFT to obtain its computational activity factor. The memory access strength factor is 0.7. The value is 0.8. Simultaneously, the current state of core 3 is obtained as idle, and its voltage is... 0.9 V, frequency 1.0GHz, memory bus utilization The power consumption factor is 0.05. The weighting coefficient is 1.0 W / (V²·GHz). The threshold is set to 0.5. The hard real-time security and performance threshold is set to... W, Next, the unit begins calculating the relevant metric data, including the target power consumption increment. W. Cache contention probability Then, a determination was made: 0.567 W is less than or equal to... 0.6 W, the condition is met; 0.02 is less than or equal to The condition of 0.2 is also met. Since all conditions are met, the final decision is to allow. Finally, the hardware event filter and policy mapping unit generates and returns the hardware verification result to the operating system scheduler as {Decision: Allow scheduling}.

[0139] In one embodiment of the present invention, step S6 includes the following steps:

[0140] Receive the security verification feedback credential carrying a veto signal returned by the hardware event filter and policy mapping unit to the scheduling framework;

[0141] The core list of suggested states is fed down along with the rejection signal in the security verification feedback certificate. The core list of suggested states includes the recommended nodes calculated and filtered after removing the nodes that have just been rejected from the original set of feasible target cores by using the current instantaneous wafer thermal capacity margin parameter.

[0142] Call the available node parameters in the suggested state core list to overwrite and replace the original set of feasible target cores;

[0143] Carrying the updated set of feasible target cores, the execution program jumps back to step S4.

[0144] Specifically, after the hardware pre-verification process in step S5, if the generated hardware verification result triggers a rejection scheduling instruction, the method of parsing the correction policy parameters fed back by the underlying hardware in response to the hardware verification result triggering the rejection scheduling instruction, and driving the iterative flow of the preceding calculation steps until a pass state is achieved, is jointly executed by the operating system scheduler and the hardware event filter and policy mapping unit. First, after submitting the initial scheduling action proposal, the operating system scheduler is in a waiting state. When it receives the security verification feedback credential carrying a rejection signal returned by the hardware event filter and policy mapping unit, this iterative process is activated. The security verification feedback credential is a data structure directly written by the hardware to a predetermined memory address or special register, and the operating system scheduler detects its updates through polling or interrupts. The rejection signal is a specific flag bit in this data structure.

[0145] Next, the scheduler parses the core suggestion status list that accompanies the rejection signal in the credential and sends it back down. In this embodiment, the core suggestion status list... The generation logic can be represented by the following formula:

[0146]

[0147] Among them, the heat capacity margin of each core The calculation method is as follows:

[0148]

[0149] In the formula, This is the core list of suggested states. To eliminate the target computing cores that have been rejected Subsequently, the core set of current feasible objectives One of the elements. That is the core The current instantaneous wafer thermal capacity margin parameter, in degrees Celsius. It is the maximum allowable chip junction temperature defined in the processor datasheet, and it is a fixed value. Through the core The internal digital temperature sensor reads the current temperature in real time. It is a preset safety margin threshold used to ensure that even after a new task is loaded, the core temperature has enough room to rise without reaching the limit.

[0150] This unit retrieves real-time thermal sensor readings from all on-chip cores, calculates the current instantaneous wafer thermal margin parameter for each core, removes recently rejected nodes from the set of feasible target cores, and then performs forward calculations to filter the remaining candidates, retaining only cores with thermal margins higher than a preset safety margin as recommended nodes. It should be understood that the current instantaneous wafer thermal margin parameter is a direct physical indicator of how much temperature rise a core can withstand. The value is usually determined based on the chip's manufacturing process and packaging technology. For example, for an embedded processor, the value might be set to 100 degrees Celsius. The setting is based on the system's reliability requirements, typically between 10 and 20 degrees Celsius, to prevent thermal overshoot caused by instantaneous power consumption spikes.

[0151] Finally, the operating system scheduler calls the available node parameters from the suggested state core list to completely overwrite and replace the original set of feasible target cores generated in step S3. After the replacement is completed, the scheduler does not continue execution but instead uses a program jump instruction to carry this updated core set back and re-enter the computation allocation process in step S4. That is, based on the new and more stringent hardware candidate space, the software-level optimization calculation is performed again to generate a new preliminary scheduling action proposal, thus forming a closed-loop iterative correction process until the scheduling proposal is verified by hardware. The computation allocation process is the process detailed in step S4, which calculates the execution latency weight based on the candidate core set and selects the better core.

[0152] For example, suppose the verification in step S5 fails. In S4, Task_FFT is proposed to be scheduled to core 3. In the pre-verification in S5, although the cache contention probability passes, it is assumed that the system power consumption threshold... The threshold was more strictly set at 0.5 W. Since the calculated target power increment was 0.567 W, exceeding this threshold, the hardware event filter and policy mapping unit generated a hardware verification result containing a rejection signal. The operating system scheduler received this rejection credential. This credential also included a list of recommended core states. This list was generated by the hardware decision unit, assuming the current core temperatures are as follows: Celsius Celsius Celsius Celsius, and the chip's 100 degrees Celsius, safety margin The temperature is 10 degrees Celsius. The hardware calculates the thermal margins of the current candidate cores as follows: core 0 is 15 degrees Celsius, core 1 is 8 degrees Celsius, core 2 is 25 degrees Celsius, and core 3 is 12 degrees Celsius. Core 1 was eliminated in the previous step S3 due to a state conflict, and core 3 was just rejected due to excessive power consumption. Therefore, both core 1 and core 3 are immediately removed from this round of recommendation evaluation. Since the thermal margins of core 0 and core 2 are not lower than 10 degrees Celsius, the generated recommended state core list is {core 0, core 2}. After receiving this list, the scheduler replaces the original set of feasible target cores with it. Subsequently, the scheduler returns to the execution step S4, at which point the candidate core set is {core 0, core 2}. The scheduler will recalculate the execution latency weight of each core based on this new set and select a new target core. Since the weight of core 2 (0.22) is better than the weight of core 0 (0.54), the scheduler selects core 2 and generates a new preliminary scheduling action proposal. This new proposal will be submitted to step S5 for verification again, and this process will continue until a scheduling scheme that can pass both hardware and software verification is found.

[0153] In one embodiment of the present invention, step S7 includes the following steps:

[0154] Receive the permission signal returned based on the security verification rules, solidify and lock the data path relationship for the transfer mapping from the target task to the target computing core;

[0155] Retrieve historical behavior profiles of the target task, fit and generate hardware microcontroller instruction packages for the dynamic voltage frequency adjustment module;

[0156] The on-chip system bus controller is invoked to merge and package the inter-core interrupt instruction that triggers the scheduling transfer with the hardware microcontroller instruction package;

[0157] Within the same bus transaction, transmission operations are performed according to strict clock synchronization timing characteristics, completing the joint control atomic operation closed loop.

[0158] Specifically, after the hardware pre-verification process in step S5, if the generated hardware verification result triggers a scheduling permission instruction, in response to this instruction, the task migration operation and underlying power adjustment action are aggregated to execute a closed-loop method of joint control atomic operation issued by both hardware and software. This method is collaboratively executed by the operating system kernel scheduler, the hardware event filter and policy mapping unit, and the on-chip system bus controller. First, the operating system kernel scheduler receives a permission signal returned by the hardware event filter and policy mapping unit based on the security verification pass rules. This permission signal is the confirmation flag bit in the hardware verification result data structure.

[0159] After receiving this signal, the scheduler no longer hesitates and immediately solidifies and locks the data path relationship for transferring the target task to the target computing core, which means that this scheduling decision becomes the final decision at the software level. Solidifying and locking the data path relationship means that the scheduler updates the corresponding process scheduling data structure in the kernel, assigns the affinity of the task to the target computing core, and prepares for the specific operation of context switching. Immediately afterwards, the hardware event filter and the policy mapping unit execute the second task in parallel within themselves, that is, extract the historical behavior portraits analyzed and cached in the previous step S2, and based on the task computing intensity and memory access characteristics recorded therein, fit out the hardware parameter values corresponding to the dynamic voltage frequency adjustment module that can maintain a better computing energy efficiency ratio parameter through table lookup or real-time calculation. It should be noted that the better computing energy efficiency ratio parameter is a mapping table pre-calibrated based on the processor characteristic curve, which indicates that for different types of computing loads, there are optimal voltage and frequency operating points. These parameter values are packed into a hardware micro-control instruction packet. It should be understood that the hardware micro-control instruction packet is a low-level instruction sequence containing control parameters such as the target voltage value, target frequency value, and adjustment slope. The dynamic voltage frequency adjustment module is usually a hardware unit inside the processor, responsible for dynamically adjusting the working voltage and clock frequency of the core.

[0160] Subsequently, the operating system scheduler readies the inter-core interrupt instruction that triggers the scheduling transfer. At the same time, the hardware event filter and the policy mapping unit also ready the hardware control instruction packet. Finally, both of them use a synchronization signal to call the on-chip system bus controller, which packs, merges, and seals the inter-core interrupt instruction issued by the operating system kernel and the hardware micro-control instruction packet generated by the hardware unit. The on-chip system bus controller is a hardware unit responsible for coordinating data transmission between various modules inside the on-chip system, and it can ensure the atomicity or strict timing transmission of multiple instructions. This controller ensures that these two instruction packets are executed and sent in the same bus transaction according to the strict clock synchronization timing characteristics. The strict clock synchronization timing characteristics mean that the emission time points of the two instructions are controlled within a deterministic delay range of several clock cycles, ensuring that the adjustment of voltage and frequency is tightly coupled with the actual execution of the task code in time. The inter-core interrupt instruction is sent to the interrupt controller of the target core to trigger task context switching; while the hardware micro-control instruction packet is sent to the control register of the power management unit to adjust its voltage and frequency. This process realizes the real-time linkage action flow between the processor computing unit and the hardware power control unit inside the target processing device, forming an inseparable joint control atomic operation.

[0161] For example, continuing the scenario where step S5 verification is successful, the operating system scheduler receives a permission signal to schedule Task_FFT to core 3. The scheduler immediately binds Task_FFT to core 3 in the kernel data structure. Simultaneously, the hardware event filter and policy mapping unit queries its internal energy efficiency parameter table based on the historical behavior profile of Task_FFT (computation activity 0.7, memory access intensity 0.8). The lookup results show that for this type of load, the optimal hardware parameters for running on core 3 are a voltage of 1.05 V and a frequency of 1.5 GHz. Therefore, this unit generates a hardware microcontroller instruction packet containing these target values. Next, the scheduler prepares an inter-core interrupt instruction to be sent to core 3 to initiate the execution of Task_FFT. Through handshake signal synchronization with the hardware event filter and policy mapping unit, both jointly invoke the on-chip system bus controller. This controller merges the inter-core interrupt instruction and the hardware microcontroller instruction packet into a single transaction. In the next clock cycle, the transaction is executed, and the inter-core interrupt instruction is routed to core 3, causing it to begin fetching and executing Task_FFT from the run queue. Almost simultaneously, a hardware microcontroller instruction packet containing {target voltage: 1.05 V, target frequency: 1.5 GHz} is written to the register of the dynamic voltage and frequency adjustment module associated with core 3, ensuring that core 3's operating state is promptly adjusted to an optimal energy efficiency point. In this way, task migration and its required optimal hardware resource configuration are activated synchronously, completing the integrated hardware and software closed-loop control.

[0162] See appendix Figure 2 This invention also proposes a hardware and software collaborative task processing and control system based on an ARM multi-core architecture, including the following modules:

[0163] The core state awareness module is configured to acquire the underlying operating data of the multi-core processor, execute state transition logic, and generate a set of real-time state labels describing the current performance state of each computing core.

[0164] The task attribute recognition module is configured to receive task allocation instructions from the system kernel, identify key code attributes of the target task, and generate task constraint events that limit the hardware dependencies of the target task at runtime.

[0165] The feasible core set generation module is configured to extract hardware constraint requirements from task constraint events, compare the hardware constraint requirements with the set of instantaneous status labels, and generate a feasible target core set belonging to the target task.

[0166] The software scheduling proposal module is configured to invoke the operating system's scheduling framework, select a target computing core from the set of feasible target cores, and generate a preliminary scheduling action proposal containing task migration path attributes.

[0167] The hardware pre-verification and adjudication module is configured to intercept the issuance of the preliminary scheduling action proposal, project the preliminary scheduling action proposal to the hardware event handler for pre-verification, and generate hardware verification results.

[0168] The scheduling iteration correction module is configured to respond to the hardware verification result triggering a rejection scheduling instruction, parse the correction strategy parameters fed back by the underlying hardware, update the feasible target core set, and return to the execution step S4.

[0169] The hardware and software co-execution module is configured to respond to the hardware verification result by triggering a scheduling instruction, and aggregate task migration operations and underlying power adjustment actions based on the initial scheduling action proposal to execute a closed loop of joint control atomic operations issued by the hardware and software.

[0170] Each of the modules can be implemented in whole or in part through software, hardware, or a combination thereof. It supports hardware embedded in or independent of the processor in the computer device, and also supports software stored in the memory of the computer device, so that the processor can call and execute the operations corresponding to each of the above modules.

[0171] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A hardware and software collaborative task processing and control method based on ARM multi-core architecture, characterized in that, Includes the following steps: S1. Obtain the underlying operating data of the multi-core processor, execute the state transition logic, and generate a set of real-time state labels describing the current performance state of each computing core. S2. Receive the task allocation instruction from the system kernel, identify the key code attributes of the target task, and generate task constraint events that limit the hardware dependencies of the target task during runtime. S3. Extract the hardware constraint requirements from the task constraint events, and compare the hardware constraint requirements with the set of immediate status labels to generate a set of feasible target cores belonging to the target task. S4. Invoke the operating system's scheduling framework, select the target computing core from the feasible target core set, and generate a preliminary scheduling action proposal containing task migration path attributes. S5. Intercept the issuance of the preliminary scheduling action proposal, project the preliminary scheduling action proposal to the hardware event handler for pre-verification, and generate hardware verification results. S6. In response to the hardware verification result triggering a rejection scheduling instruction, parse the correction strategy parameters fed back by the underlying hardware, update the feasible target core set, and return to execute step S4. S7. In response to the hardware verification result triggering the scheduling instruction, based on the preliminary scheduling action proposal, the task migration operation and the underlying power adjustment action are aggregated to execute the joint control atomic operation closed loop issued by the software and hardware.

2. The hardware and software collaborative task processing and control method based on ARM multi-core architecture according to claim 1, characterized in that, Step S1 includes the following steps: Continuously capture the raw architecture event stream of each computing core. The raw architecture event stream includes the number of instructions per cycle, multi-level cache miss rate, and instruction queue depth parameters. By utilizing the embedded hardware event filter and policy mapping unit, the original architecture event stream is filtered and counted according to a preset triggering cycle to obtain the filtered architecture parameter set; Based on the preset event state transition rules, the state threshold triggered by the filtered architecture parameter set is determined, and the physical energy efficiency state corresponding to each computing core is marked. The set of real-time state labels corresponding to each computing core is then generated.

3. The hardware and software collaborative task processing and control method based on ARM multi-core architecture according to claim 1, characterized in that, Step S2 includes the following steps: During the creation and execution cycle of the target task, the software task profiler parses the code segment corresponding to the target task, counts the frequency of hardware accesses triggered, and generates a historical behavior profile. Identify pre-configured hardware event concern patterns in code segments that are sensitive to core instruction throughput or memory bandwidth. In response to the processor's instruction decoding unit executing a key code sequence that conforms to the hardware event concern pattern, a task constraint event declaring the rigid requirements of task performance is sent to the embedded hardware event filter and policy mapping unit.

4. The hardware and software collaborative task processing and control method based on ARM multi-core architecture according to claim 1, characterized in that, Step S3 includes the following steps: Extract hardware state avoidance parameters from task constraint events that describe the real-time performance of instruction execution; The hardware state avoidance parameters are input into the hardware decision closed-loop channel and compared with the physical energy efficiency status of each computing core in the real-time state label set. From the pre-defined list of globally available processor cores, remove restricted core entities with tags that conflict with hardware state avoidance parameters, obtain the remaining matching entities, and construct a set of feasible target cores based on the matching entities.

5. The hardware and software collaborative task processing and control method based on ARM multi-core architecture according to claim 1, characterized in that, Step S4 includes the following steps: Obtain the current logical load queue status and throughput margin space of each pre-selected computing unit entity within the feasible target core set; The underlying operating system uses a task priority-based scheduling algorithm to calculate the execution latency weight of each pre-selected computing unit entity based on the current logical load queue status and throughput margin. Within the feasible target core set, select the pre-selected computational unit entity of the target execution delay weight as the target computation core; Spatial binding mapping is performed between the task identifier of the target task and the physical addressing identifier of the target computing core to generate a preliminary scheduling action proposal.

6. The hardware and software collaborative task processing and control method based on ARM multi-core architecture according to claim 1, characterized in that, Step S5 includes the following steps: In response to the timing node of the first clock cycle of the task migration interruption, the preliminary scheduling action proposal is submitted to the hardware event filter and policy mapping unit in the form of register pass-through data packet; The projection assessment evaluates the target power consumption increment and cache contention probability caused by the target task being scheduled to the target computing core according to the task migration path attributes. Determine whether the target power consumption increment and cache contention probability exceed the preset hard real-time security and performance thresholds; Based on the judgment result, the output is a hardware verification result indicating whether scheduling is allowed or denied, along with a control frame for alternative repair schemes.

7. The hardware and software collaborative task processing and control method based on ARM multi-core architecture according to claim 1, characterized in that, Step S6 includes the following steps: Receive the security verification feedback credential carrying a veto signal returned by the hardware event filter and policy mapping unit to the scheduling framework; The core list of suggested states is fed down along with the rejection signal in the security verification feedback certificate. The core list of suggested states includes the recommended nodes calculated and filtered after removing the nodes that have just been rejected from the original set of feasible target cores by using the current instantaneous wafer thermal capacity margin parameter. Call the available node parameters in the suggested state core list to overwrite and replace the original set of feasible target cores; Carrying the updated set of feasible target cores, the execution program jumps back to step S4.

8. The hardware and software collaborative task processing and control method based on ARM multi-core architecture according to claim 1, characterized in that, Step S7 includes the following steps: Receive the permission signal returned based on the security verification rules, solidify and lock the data path relationship for the transfer mapping from the target task to the target computing core; Retrieve historical behavior profiles of the target task, fit and generate hardware microcontroller instruction packages for the dynamic voltage frequency adjustment module; The on-chip system bus controller is invoked to merge and package the inter-core interrupt instruction that triggers the scheduling transfer with the hardware microcontroller instruction package; Within the same bus transaction, transmission operations are performed according to strict clock synchronization timing characteristics, completing the joint control atomic operation closed loop.

9. The hardware and software collaborative task processing and control method based on ARM multi-core architecture according to claim 6, characterized in that, The process of projecting and evaluating the target power consumption increment and cache contention probability specifically includes: Based on the task identifier code of the target task, obtain the historical behavior profile of the target task, and extract the task computing activity factor and the task memory access intensity factor. Based on the physical addressing identifier of the target computing core, obtain the current voltage, frequency, and memory controller bus utilization of the target computing core; The task activity factor is multiplied by the square of the current voltage and the current frequency, and then multiplied by a preset power consumption coefficient to obtain the target power consumption increment. The cache contention probability is obtained by multiplying the task memory access intensity factor by the memory controller bus utilization and then multiplying by a preset weighting coefficient.

10. The hardware and software collaborative task processing and control method based on ARM multi-core architecture according to claim 7, characterized in that, The process of selecting recommended nodes based on the current instantaneous wafer thermal capacity margin parameters specifically includes: Real-time readings of digital temperature sensors from all on-chip computing cores are retrieved to obtain the current temperature. The difference between the preset maximum allowable chip junction temperature and the current temperature is calculated to obtain the current instantaneous wafer thermal capacity margin parameters for each corresponding computing core. After removing the rejected scheduling target node from the original feasible target core set, determine whether the current instantaneous wafer thermal capacity margin parameter corresponding to each remaining computing core in the set is greater than the preset safety margin threshold. Calculation cores whose judgment results are greater than the safety margin threshold are retained as recommended nodes, and all recommended nodes are aggregated to generate a list of suggested state cores.

Images