Load balancing based multi-core CPU task scheduling optimization method
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- YANLING INTELLIGENT MANUFACTURING TECHNOLOGY (DONGGUAN) CO LTD
- Filing Date
- 2025-11-12
- Publication Date
- 2026-06-23
Smart Images
Figure CN121433899B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of multi-core CPU task scheduling technology, specifically a multi-core CPU task scheduling optimization method based on load balancing. Background Technology
[0002] With the rapid development of information technology, multi-core CPUs, with their strong parallel processing capabilities and high computing efficiency, have been widely used in various scenarios such as servers, embedded devices, and high-performance computing, becoming the core hardware foundation supporting the operation of complex applications. Task scheduling, as a key aspect of maximizing the performance of multi-core CPUs, aims to rationally distribute massive amounts of tasks across various processing cores, avoiding situations where some cores are overloaded while others are idle, thereby maximizing the overall system efficiency.
[0003] Currently, most multi-core CPU task scheduling methods rely on preset fixed thresholds or simple load statistics models to adjust task allocation. These methods generally suffer from a lack of single monitoring dimensions, only capturing static data on core load and failing to track dynamic changes in load during task execution, leading to a lag in assessing system load status. In the load assessment phase, existing technologies often use average load values as the basis for judgment, ignoring the instantaneous fluctuations and distribution differences in load across cores. This makes it difficult to accurately identify load skew and specific skewed cores, resulting in a lack of targeted load balancing adjustments.
[0004] Existing task scheduling methods often employ a uniform task migration strategy upon detecting load imbalance, failing to develop differentiated adjustment plans based on the degree of load deviation. This can easily lead to over-migration or incomplete adjustment, increasing system overhead. Furthermore, most scheduling schemes lack a mechanism linking task execution data with scheduling optimization, focusing only on real-time load adjustments while neglecting the analysis and accumulation of task execution characteristics. This results in a lack of long-term optimization basis for scheduling strategies. When faced with a mix of tasks of different types and priorities, existing scheduling methods struggle to adapt to the differentiated operational needs of tasks. This can lead to problems such as high-priority tasks being delayed and similar tasks concentrating on a single core resource, resulting in decreased overall stability of multi-core CPUs, underutilization of resources, and an inability to meet the real-time, accurate, and efficient scheduling requirements of complex application scenarios. Summary of the Invention
[0005] The purpose of this invention is to provide a multi-core CPU task scheduling optimization method based on load balancing to solve the problems mentioned in the background art.
[0006] To achieve the above objectives, this invention provides a multi-core CPU task scheduling optimization method based on load balancing, the method comprising:
[0007] Continuously monitor the output value of the load balancing indicator in the task scheduler of the multi-core CPU. When the output value indicates that the system is in a balanced state, set the current task allocation mode of the multi-core CPU to the baseline task distribution.
[0008] Collect real-time load measurements for each processing core in a multi-core CPU;
[0009] A load distribution sequence is constructed based on real-time load measurements, and the load deviation parameter between the load distribution sequence and the baseline task distribution is calculated.
[0010] The load imbalance status of a multi-core CPU is determined based on the load deviation parameters, including the degree of imbalance and the identification of skewed cores.
[0011] The output value of the load balancing indicator is updated based on the load imbalance status, and a task reallocation instruction is generated through the task scheduler to control the task scheduler to adjust the task allocation direction in the task queue.
[0012] During task execution, the task monitoring unit collects task operation data in real time and associates it with the unique task identifier. Based on the correspondence between the unique task identifier and the task category, the task operation data is segmented, and the segmented task operation data is evaluated for performance and the results are stored.
[0013] Preferably, the acquisition of real-time load measurements for each processing core in the multi-core CPU is achieved by querying the hardware performance counter of each processing core, wherein the hardware performance counter is configured to sample CPU utilization data of the core at fixed time intervals.
[0014] Preferably, constructing the load distribution sequence based on real-time load measurements includes: comparing the real-time load measurement of each processing core with the reference load value of the corresponding core in the baseline task distribution to obtain the load difference value of each core; determining the logical distance between cores based on the core arrangement topology of the multi-core CPU; and constructing the load distribution sequence using the load difference value and the logical distance between cores.
[0015] Preferably, the calculation of the load deviation parameter between the load distribution sequence and the reference task distribution includes: projecting the load distribution sequence onto the reference task distribution plane to obtain a first projection length, the first projection length representing the component of the load distribution sequence in the direction of the reference task distribution; calculating a second projection length of the load distribution sequence in the vertical direction, the second projection length representing the cumulative magnitude of the load difference value; combining the first projection length and the second projection length into a right-angled triangle model, and calculating the load deviation angle between the load distribution sequence and the reference task distribution through trigonometric function relationships.
[0016] Preferably, determining the load imbalance state of the multi-core CPU based on the load deviation parameter includes: deriving the slope normal vector of the load distribution sequence based on the load deviation angle; calculating the angle between the slope normal vector and the reference task distribution plane as the degree of imbalance; and extracting the projection direction of the slope normal vector on the reference task distribution plane as the skewed core identifier.
[0017] Preferably, updating the output value of the load balancing indicator based on the load imbalance status includes: encoding the imbalance degree and skew core identifier into the input signal of the load balancing indicator, adjusting the internal threshold of the load balancing indicator; and the task scheduler generating a task migration command based on the updated output value of the load balancing indicator.
[0018] Preferably, the task scheduler adjusts the task allocation direction in the task queue by: the task scheduler parses the task migration command and identifies the high-load core pointed to by the skew core identifier; and reallocates the tasks to be processed on the high-load core to the low-load core, so that the task allocation direction is consistent with the opposite direction of the skew core identifier.
[0019] Preferably, the step of collecting task execution data in real time and associating it with a unique task identifier through the task monitoring unit includes: the task monitoring unit recording the task start time, task end time, and number of CPU cycles occupied by the task during task execution; and binding the task execution data with the unique task identifier assigned by the task scheduler to form a task record set.
[0020] Preferably, the segmentation of task execution data based on the correspondence between task unique identifiers and task categories includes: predefining a task category mapping table to map task unique identifiers to compute-intensive, I / O-intensive, or hybrid task categories; and dividing the task record set into multiple task segment datasets according to the task category.
[0021] Preferably, the step of evaluating and storing the performance of the segmented task execution data includes: calculating the average task execution time and load variance index for each task segment dataset; and storing the performance evaluation results in the database in association with the task category for the task scheduler to query and use in subsequent scheduling decisions.
[0022] Compared with the prior art, the beneficial effects of the present invention are:
[0023] By continuously monitoring the output value of the load balancing indicator and establishing a baseline task distribution, a scientific reference standard is provided for subsequent load status judgment. This enables the system to quickly perceive changes in its load balance status, avoiding the misjudgment problems caused by static monitoring in traditional methods. This design allows load status perception to move beyond static data at a single point in time, forming a dynamic tracking closed loop that ensures a more timely and accurate response to system load changes.
[0024] By collecting real-time load measurements from each processing core and constructing a load distribution sequence, the instantaneous load state and distribution characteristics of each core can be comprehensively captured. Compared to traditional average load statistics, this method better reflects the true load situation of multi-core CPUs. The load deviation parameters calculated based on this clearly define the specific degree of load imbalance and the skewed core identifiers. This ensures that load balancing adjustments are no longer blind operations but can accurately locate problematic cores, providing a clear direction for subsequent task allocation adjustments and effectively avoiding the waste of system resources caused by indiscriminate adjustments.
[0025] The load balancing indicator output is updated based on the load imbalance status, and targeted task reallocation instructions are generated, achieving dynamic adaptation of load balancing adjustments. This adjustment method can flexibly adjust the task allocation direction according to the actual load deviation, avoiding the continuous accumulation of pressure on overloaded cores and making full use of the idle resources of underloaded cores. This ensures that task allocation is always dynamically optimized around the load balancing goal, guaranteeing the efficient utilization of the resources of each core of a multi-core CPU.
[0026] During task execution, the task monitoring unit collects task execution data with unique identifiers in real time, processes it in segments according to task category, and then performs performance evaluation and storage, achieving a deep correlation between task execution characteristics and scheduling strategies. This design breaks the traditional separation between task execution and scheduling optimization. By accumulating and analyzing execution data from different types of tasks, it is possible to gradually grasp the operational patterns and resource requirements of various tasks, providing rich practical evidence for the continuous optimization of subsequent scheduling strategies.
[0027] This method, encompassing load status monitoring, load assessment, execution adjustments, and data accumulation, forms a complete closed-loop scheduling optimization system. By accurately sensing load changes, scientifically assessing imbalances, dynamically adjusting task allocation, and accumulating task execution data, it comprehensively optimizes the task scheduling logic of multi-core CPUs, making task allocation more rational and targeted. Whether facing intensive computing tasks or mixed-type tasks, it effectively avoids core load imbalance, reduces task execution latency, improves the overall stability and smoothness of the system, fully leverages the parallel processing advantages of multi-core CPUs, and adapts to the operational needs of various complex application scenarios. Attached Figure Description
[0028] Figure 1 This is a schematic diagram illustrating the working principle of the multi-core CPU task scheduling optimization method based on load balancing described in this invention.
[0029] Figure 2 A flowchart for constructing the load distribution sequence;
[0030] Figure 3 A flowchart for updating the output value of the load balancing indicator. Detailed Implementation
[0031] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0032] Please see Figure 1 This invention provides a multi-core CPU task scheduling optimization method based on load balancing. The method includes: a load balancing indicator continuously outputting system status values; when the output value indicates that the system is in a balanced state, the task scheduler records the current task allocation pattern as a baseline task distribution. The baseline task distribution represents the ideal load state and serves as a reference for subsequent comparisons. The system periodically collects real-time load measurements for each processing core, which are obtained through a hardware interface and reflect the real-time workload of the core. Based on the real-time load measurements, the system constructs a load distribution sequence that captures the overall load pattern of the multi-core CPU. The load distribution sequence is compared with the baseline task distribution to calculate a load deviation parameter, which quantifies the difference between the current load and the baseline. The load deviation parameter is used to determine the load imbalance state, including the degree of imbalance and a skewed core identifier. The degree of imbalance indicates the severity of system imbalance, and the skewed core identifier points to a core with abnormal load. According to the imbalance state, the output value of the load balancing indicator is updated, and the task scheduler generates a task reallocation instruction to adjust the task flow in the task queue, migrating tasks from high-load cores to low-load cores. During the task execution phase, the task monitoring unit collects task runtime data in real time, such as execution time and resource usage, and associates this data with a unique task identifier. The unique task identifier maps to task categories, such as compute-intensive or I / O-intensive, thus segmenting the task runtime data. The segmented data undergoes performance evaluation, and metrics such as average execution time are calculated. The results are stored in a database for the scheduler to query in subsequent decisions. The entire process is executed cyclically, achieving dynamic load balancing.
[0033] Example 1: Real-time load measurements for each processing core in a multi-core CPU are obtained by querying the hardware performance counters of each core. These hardware performance counters are configured to sample CPU utilization data at fixed time intervals. In practice, the hardware performance counters are dedicated register sets integrated within each physical processor core. These registers are designed to record various low-level hardware events related to core execution activities. During system initialization, the operating system kernel or underlying firmware code uniformly configures the hardware performance counters for all cores. Configuration operations include setting specific event types to monitor, setting the fixed sampling time interval, and allocating a memory buffer to store the sampled data. The fixed time interval is a programmable parameter, its value determined based on the balance between real-time requirements and performance overhead, typically ranging from 1 millisecond to 10 milliseconds. When the fixed time interval expires, the hardware performance counter triggers a high-priority interrupt signal, which invokes a pre-defined interrupt service routine. Interrupt service routines are responsible for performing critical operations, including safely reading the current count value from the hardware performance counter register, writing the read raw count value to the corresponding memory buffer location, and resetting or reinitializing the hardware performance counter register according to the configuration to begin the next sampling cycle. The read raw count value typically reflects the number of active cycles in which the processor core was not idle over a fixed time interval in the past, or indicators that directly characterize the computational load, such as the number of instruction retirements.
[0034] In some embodiments, the event types monitored by the hardware performance counters are explicitly limited to specific events directly related to CPU utilization, such as the number of unstopped clock cycles or the number of instructions executed. In practice, the selection of monitored events is accomplished by writing to the control register of the hardware performance counters during system startup or module loading. To ensure the consistency and comparability of the acquired real-time load measurements, the system performs a normalization process. Normalization converts the raw counts acquired from different cores into a uniform scale, such as a core utilization percentage. The conversion is based on a known baseline, typically the maximum number of clock cycles a core can complete within the same fixed time interval when running at its maximum theoretical frequency. By dividing the actual number of cycles acquired by this maximum number of cycles and multiplying by 100, the CPU utilization percentage of each core in the most recent sampling interval is obtained; this percentage is the real-time load measurement used for subsequent processing. It can be understood that normalization allows load data from cores of different architectures and frequencies to be compared on the same scale, which is particularly important for load balancing in heterogeneous multi-core CPU systems.
[0035] In practical implementation, the process of querying hardware performance counters must consider concurrent access and data consistency issues in a multi-core environment. Since the hardware performance counters of all cores trigger interrupts at almost the same time, the design of interrupt service routines (ISRs) needs to avoid race conditions on shared data structures. One implementation approach is to use a per-core data structure, allocating an independent memory buffer for each processor core to store its own sampled data. When an ISR executes, it determines which core's interrupt it is currently servicing by reading the processor identifier register, thus operating only on the private data structures belonging to that core. The query operation itself, i.e., reading the value of the hardware performance counter register, is a privileged instruction that needs to be executed in operating system kernel mode. Before executing the read instruction, the ISR may temporarily mask other interrupts to prevent interruption by higher-priority interrupts during the read process, thus ensuring that the read count value is a consistent snapshot at a given point in time. After the read operation is completed, the interrupt mask is removed to maintain the system's low-latency response characteristics.
[0036] Optionally, the system can provide a mechanism for dynamically adjusting the sampling frequency, although the core mechanism is still based on a fixed time interval. In practice, this dynamic adjustment does not respond in real time to instantaneous load changes, but rather adapts slowly based on the overall load level trend of the system. The system maintains a background monitoring thread that periodically analyzes the fluctuations in historical load data. If the system load is detected to be consistently stable over a long period, the monitoring thread may dynamically adjust the fixed sampling time interval of the hardware performance counter to a larger value, such as from 1 millisecond to 5 milliseconds, through a system call interface, thereby reducing the system overhead of performance analysis. Conversely, when increased load fluctuations are detected, the fixed time interval will be adjusted back to a smaller value to obtain more accurate load data. The adjustment operation is implemented by reprogramming the timer comparison register of the hardware performance counter. It can be understood that this dynamic adjustment strategy needs to make a trade-off between reducing overhead and ensuring the scheduler's response speed. Its decision-making logic is relatively conservative to avoid instability introduced by excessively frequent changes in the sampling frequency.
[0037] Before the raw data collected by the hardware performance counter is used to construct the load distribution sequence, it needs to undergo a data verification and filtering process. In practice, data verification primarily targets potential anomalies, such as missing sampling points due to interrupt delays or data loss, or count values that wrap around due to counter overflow. For missing sampling points, the system can use interpolation algorithms, such as using the previous valid sample value to fill the missing value, or simply ignoring the sample and waiting for the next period's data. Handling counter overflow requires the hardware performance counter to support overflow interruption, or at the software level, it can determine if an overflow has occurred by comparing the difference between two consecutive sample values for an unreasonable large negative increase and performing appropriate numerical correction. Data filtering aims to eliminate instantaneous load spikes caused by micro-events such as extremely short-term thread switching and interrupt handling, as these spikes do not represent the core's continuous load state. The filtering algorithm typically uses a simple moving average window to smooth the instantaneous load measurements obtained over several consecutive sampling periods. The window size can be configured as needed, for example, using a window with 3 or 5 sampling points. After verification and filtering, the stability and reliability of the real-time load measurements are improved, and they are then passed to the load analysis module for subsequent load distribution sequence construction operations.
[0038] Example 2: See Figure 2 The process of constructing a load distribution sequence based on real-time load measurements involves comparing the real-time load measurement of each processing core with the reference load value of the corresponding core in the baseline task distribution to obtain the load difference value for each core. The load difference value is a scalar measure characterizing the deviation of a single core from its baseline load state. In specific implementations, the baseline task distribution is a pre-stored data structure in which a reference load value is recorded for each processing core. The reference load value is a representative value of the real-time load measurement collected and saved when the system is determined to be in a balanced state by the load balancing indicator; it could be an average or steady-state value. Logically, the comparison operation is an element-wise subtraction process. The system iterates through the identifier of each core, reads the corresponding core's value from the currently collected real-time load measurement array, and simultaneously reads the reference load value of the same core from the baseline task distribution data structure. Then, it calculates the arithmetic difference between the real-time load measurement and the reference load value; the result is the load difference value for that core. The load difference value is a signed number: a positive number indicates that the current load is higher than the baseline load, a negative number indicates that the current load is lower than the baseline load, and a zero value indicates that the load state is consistent with the baseline. The load variance values of all cores are collected to form an initial load variance vector, the dimension of which is equal to the total number of processing cores in the system.
[0039] In practice, determining the logical distance between cores based on the core arrangement topology of a multi-core CPU is a calculation step based on system hardware topology information. The core arrangement topology describes the physical connections and relative positions of the various computing cores on the processor chip. This topology information is typically obtained by the system firmware or operating system during startup by querying the ACPI table or using the CPUID instruction. Common topologies include mesh networks, ring networks, or more hierarchical NUMA architectures. The logical distance is quantified as a cost metric for the communication path between cores, such as the minimum expected latency cycles or the number of intermediate hops required to transmit a cache line of data between two cores. The system constructs a distance matrix where the row and column indices correspond to core identifiers, and each element stores the logical distance value between two corresponding cores. For homogeneous and symmetric multi-core processors, the logical distance may be simplified to the shortest path length between cores on the topology graph. The calculation of the logical distance provides a spatial basis for subsequently measuring the propagation impact of load differences between cores.
[0040] Constructing a load distribution sequence using load variance values and inter-core logical distances is the final stage of the process. In practice, the load distribution sequence is a weighted load variance vector. The weighting operation aims to reflect the potential impact of a core's load variance on its neighboring cores; the degree of influence is inversely proportional to the inter-core logical distance. Specifically, for each core in the system, the component values in its final load distribution sequence do not directly use its original load variance value, but rather calculate a weighted sum influenced by the load variances of its neighboring cores. The weighting coefficients of the sum are determined by the inter-core logical distance, typically using a distance decay function, such as an inverse proportional function or a Gaussian kernel function, such that cores with closer logical distances have larger weights, and cores with farther logical distances have smaller weights. Through this weighting process, the load distribution sequence not only includes the load deviation information of each core itself but also incorporates the load correlation caused by inter-core proximity, thus providing a more comprehensive characterization of the load distribution across the entire chip. The constructed load distribution sequence is a multi-dimensional vector, with its dimensions consistent with the number of processing cores. Calculating the load deviation parameter between the load distribution sequence and the baseline task distribution involves vector projection and trigonometric operations. In practice, the baseline task distribution is considered a directional reference in this computational scenario, typically represented mathematically by a vector with equal components. The direction of this reference vector represents an ideal, perfectly uniform load distribution. Projecting the load distribution sequence onto the baseline task distribution plane is achieved by calculating the dot product of the two vectors. Dividing the dot product value by the magnitude of the baseline task distribution vector yields the first projection length of the load distribution sequence projected onto the direction of the baseline task distribution vector. This first projection length is a scalar whose magnitude reflects the component in the current load distribution sequence that is related to the overall load level change, i.e., the overall trend of all core loads increasing or decreasing synchronously.
[0041] In practical implementation, calculating the second projection length of the load distribution sequence in the direction perpendicular to the baseline task distribution requires the application of vector decomposition principles. The second projection length represents the component in the load distribution sequence related to load imbalance, i.e., the degree of uneven load distribution among different cores. Mathematically, by subtracting the projection vector in the direction of the baseline task distribution vector from the original load distribution sequence vector, a residual vector can be obtained, which is completely orthogonal to the baseline task distribution direction. Calculating the magnitude of this residual vector yields the second projection length. The second projection length quantifies the dispersion of load differences among cores; a larger value indicates a more severe deviation from a uniform load distribution. Combining the first and second projection lengths into a right-angled triangle model is a geometric abstraction method. The first and second projection lengths form the two legs of the right triangle, while the original load distribution sequence vector corresponds to the hypotenuse. The load deviation angle between the load distribution sequence and the baseline task distribution is calculated using trigonometric functions. Specifically, the ratio of the second projection length to the first projection length is calculated, and then the arctangent of this ratio is performed to obtain the load deviation angle in radians or degrees. The load deviation angle is a key parameter, directly reflecting the angle by which the current load distribution deviates from the ideal uniform distribution. A zero angle indicates perfect balance, while an increasing angle indicates a greater degree of imbalance. Determining the load imbalance state of a multi-core CPU based on the load deviation parameter involves deriving the slope normal vector of the load distribution sequence. In practice, within the vector space spanned by the load distribution sequence vector and the baseline task distribution vector, the load distribution sequence vector itself defines the load distribution slope. The slope normal vector of the load distribution sequence is a vector perpendicular to this slope, pointing in the direction of the fastest increase in the load gradient. The slope normal vector of the load distribution sequence can be calculated through mathematical operations on the load distribution sequence vector, such as determining the component directions of the load distribution sequence vector in an orthogonal complement space containing the baseline task distribution vector as a one-dimensional subspace.
[0042] In practice, the angle between the ramp normal vector and the baseline task distribution plane is used to determine the degree of imbalance. The baseline task distribution plane is a subspace composed of all uniformly distributed load states. The angle between the ramp normal vector and the baseline task distribution plane can be obtained by calculating the angle between the ramp normal vector and its projection vector on the baseline task distribution plane. The magnitude of this angle directly measures the severity of the current load distribution state deviating from the uniform distribution state, and is therefore defined as the degree of imbalance. The degree of imbalance is a scalar value; the larger the value, the more prominent the load imbalance problem of the system. The projection direction of the ramp normal vector on the baseline task distribution plane is extracted as the skew core identifier. The projection of the ramp normal vector on the baseline task distribution plane is a vector, and each component of this vector has a sign and magnitude. By analyzing the components of this projection vector, it is possible to identify which cores contribute the most to the current imbalance state. Specifically, cores with significant positive components in the projection vector are identified as cores with high load, i.e., skew cores.
[0043] Example 3: See Figure 3Updating the output value of the load balancing indicator based on the load imbalance status involves encoding the degree of imbalance and the skewed core identifier into the load balancing indicator's input signal. In practice, the load balancing indicator is a logical judgment module with internal states and adjustable thresholds, and its input signal is a structured data packet. The encoding process involves data format conversion and normalization. The degree of imbalance, as a floating-point or fixed-point value, is directly mapped to a specific field of the input signal, and its numerical range is scaled to a predefined interval, such as from 0.0 to 1.0, where 0.0 represents perfect balance and 1.0 represents severe imbalance. The skewed core identifier is encoded as a compact bitmap, the length of which equals the total number of processing cores in the system. Each bit in the bitmap corresponds to a core identifier; if a bit is set to logic '1', it indicates that the core is identified as a skewed core. This composite data structure containing the degree of imbalance and the skewed core bitmap together constitutes the input signal of the load balancing indicator. After the input signal is sent to the load balancing indicator, it triggers its internal threshold adjustment logic. An internal threshold is a dynamically changing reference value used to determine whether the current system state is sufficient to trigger load balancing. One strategy for adjusting the internal threshold is based on a sliding window average of historical input signals. The load balancing indicator maintains a fixed-size historical buffer, recording the imbalance levels of the most recent few times. Each time a new input signal arrives, the load balancing indicator calculates the average of all imbalance levels in the buffer and sets the internal threshold to this average multiplied by a configurable scaling factor. The scaling factor is typically greater than 1, used to set a reasonable threshold for triggering action and avoid frequent adjustments for minor fluctuations. In this way, the internal threshold can adaptively follow the long-term trend of system load, thereby improving the accuracy of the judgment.
[0044] In some embodiments, the internal state machine of the load balancing indicator is designed to be more complex, containing multiple discrete states, such as "balanced," "slightly unbalanced," "moderately unbalanced," and "severely unbalanced." The degree of imbalance in the input signal is compared with a set of corresponding threshold ranges to determine the state transition. Skewed core identifiers are used to record the spatial distribution characteristics of the imbalance during state transitions. The task scheduler generates task transition commands based on the updated load balancing indicator output value, which can be directly an enumeration of its internal states or a specific operation instruction calculated based on the state and input signals. The task transition command generation logic parses the output value; if the output value indicates that load balancing needs to be performed, the command generator creates a task transition command data structure. This data structure explicitly contains a list of source cores (high-load cores) parsed from the skewed core identifier and a target core suggestion calculated based on the load distribution. Controlling the task scheduler to adjust the task allocation direction in the task queue includes the task scheduler parsing the task transition commands and identifying high-load cores. In specific implementations, the task scheduler periodically checks for new task transition commands arriving in its main scheduling loop. The parsing process involves reading various fields of the task migration command data structure, particularly the source core list field. The source core list is directly derived from the skew core identifier bitmap encoded in the input signal. By traversing the bitmap, the core identifiers corresponding to all set bits are extracted, forming a clear list of high-load cores. After identifying high-load cores, the task scheduler needs to further determine low-load cores. The determination of low-load cores can be derived by looking in the opposite direction of the skew core identifiers. If the projection direction of the skew normal vector of the load distribution sequence onto the baseline task distribution plane points to high-load cores, then the direction opposite to this projection direction roughly indicates the low-load region. The task scheduler calculates the current real-time load of all cores and selects one or more cores with the lowest load from the non-high-load cores as the target for task migration.
[0045] In some embodiments, the parsing and execution of task migration commands are atomic, or occur within a critical region, to prevent inconsistencies in decision-making caused by changes in system state during migration. After identifying high-load and low-load cores, the task scheduler begins scanning the task queue, which stores all task descriptors in a ready state awaiting execution. The task scheduler needs to select tasks to migrate from the run queue or ready queue corresponding to the high-load core. The task selection strategy needs to consider several factors to optimize migration performance and reduce overhead, such as task priority, estimated task execution time, task affinity, and task resource consumption. High-priority tasks may be prioritized for migration to quickly respond to system demands, while tasks with very short estimated execution times may not be suitable for migration because the overhead of migration itself may outweigh the benefits. Task affinity information is used to avoid migrating tasks to cores with which they share less data, thereby increasing cache invalidation overhead. The selected pending task descriptors are unlinked from their current high-load core queue. Reassigning pending tasks from high-load cores to low-load cores is the core step in the adjustment operation. In practice, the reallocation operation involves updating the core affinity field in the task control block and inserting the task descriptor into the tail of the ready queue of the target low-load core. To align the task allocation direction with the opposite direction of the skewed core identifier, the task scheduler consciously selects tasks and target cores that, after migration, will make the overall system load distribution closer to the balanced state indicated by the opposite direction of the skewed core identifier. For example, if the skewed core identifier indicates that cores 3 and 4 are overloaded, while the opposite direction indicates that cores 0 and 1 are underloaded, the task scheduler will prioritize migrating tasks from cores 3 and 4 to cores 0 and 1, rather than to other moderately loaded cores. This directed migration strategy can more effectively correct load skew. Task migration may notify the target core of a new task joining its ready queue by sending an inter-processor interrupt, thereby triggering the scheduler on the target core to re-evaluate the scheduling decision.
[0046] Optionally, after migrating tasks, the task scheduler can set a short stabilization period, during which new load balancing decisions are paused to allow the system state to stabilize and the migration effect to be observed. It's understandable that task migration itself introduces certain performance overhead, including cache pollution and task switching costs; therefore, a trade-off between the benefits and costs of migration is necessary. The process by which the task scheduler generates task reallocation instructions and controls the direction of task allocation is a key component of a closed-loop feedback control system. Its goal is to drive the system load distribution to converge to a balanced state defined by the baseline task distribution through continuous fine-tuning. The update of the load balancing indicator output value and the actions of the task scheduler together form a complete negative feedback loop, ensuring that the multi-core CPU system can adaptively respond to dynamically changing workloads.
[0047] In some embodiments, to more accurately quantify migration decisions, the generation of task migration commands may reference a quantification model based on load skew. This model aims to estimate how much load needs to be migrated to effectively reduce the imbalance. A formula for estimating the amount of load migration used to aid decision-making can be expressed as:
[0048]
[0049] Where: symbol The symbol represents the estimated load for the recommended migration. It is a configurable system constant, symbol The magnitude of the load distribution sequence vector, sign... This represents the previously calculated load deviation angle. (Sine function) This highlights the influence of the vertical component of the load deviation angle. This auxiliary estimate... Instead of directly specifying the number of tasks to migrate, it provides the task scheduler with a reference target for load adjustment.
[0050] Example 4: The task monitoring unit collects task execution data in real time and associates it with unique task identifiers. The task monitoring unit is a resident memory component within the operating system kernel. In practice, the task monitoring unit captures the lifecycle of task execution by hooking into the core event points of the task scheduler. These event points mainly include the moment a task is selected by the scheduler and begins execution on a processing core, and the moment a task completes execution or is forced to relinquish a processing core. At the start of task execution, the task monitoring unit records a high-precision timestamp as the task start time. This high-precision timestamp is obtained by reading the timestamp counter register of the processing core, which provides the number of clock cycles elapsed since processor startup, thus achieving nanosecond-level time recording accuracy. Similarly, at the end of the task, the task monitoring unit records a high-precision timestamp as the task end time. In addition to time information, the task monitoring unit also records the number of CPU cycles consumed by the task. This number is collected by querying a hardware performance counter. The task monitoring unit reads the initial value of the performance counter once at the start of the task and reads the final value again at the end of the task. The difference between the final value and the initial value is the actual number of processor clock cycles consumed by the task during execution. All data task start times, task end times, and number of CPU cycles used by the task are temporarily cached in a per-core buffer associated with each processing core to reduce concurrent access conflicts to shared memory.
[0051] In practice, binding task execution data with the unique task identifier assigned by the task scheduler is a crucial data association step. When creating a new task instance, the task scheduler assigns it a globally unique task identifier, typically a monotonically increasing integer value or a composite identifier containing a timestamp and a kernel identifier. When the task monitoring unit captures the aforementioned task start event, it retrieves the task identifier assigned by the task scheduler from the currently executing task control block. Subsequently, the task monitoring unit binds the task execution data—task start time, task end time, and number of CPU cycles used—to this task identifier. This binding operation is accomplished by creating a new task record data structure in kernel memory. This data structure contains at least two fields: a task identifier field and a task execution data field. The task execution data field itself is a substructure used to store the task start time, task end time, and number of CPU cycles used. As tasks are continuously executed and completed, a large number of such task record data structures gradually accumulate in the system kernel, and the collection of these data structures collectively constitutes the task record set. The task record set is usually organized in a global chain structure or hash table, using the task's unique identifier as the primary key, to facilitate subsequent fast query and retrieval operations.
[0052] Segmenting task execution data based on the mapping between unique task identifiers and task categories presupposes the existence of a predefined task category mapping table. In practice, the task category mapping table is a static or loadable configuration data structure during system initialization. It defines the mapping rules from the pattern or range of unique task identifiers to predefined task categories. Predefined task categories typically include compute-intensive, I / O-intensive, or hybrid categories. Compute-intensive task categories refer to tasks that spend most of their time executing computational instructions and rarely access external I / O devices; I / O-intensive task categories refer to tasks that frequently initiate I / O requests and spend a significant amount of time waiting for I / O operations to complete; hybrid task categories fall somewhere in between. The mapping rules can be direct, such as encoding the expected category using specific bits of the unique task identifier; or indirect, such as determining it by querying a configuration file associated with the task startup command or program image. Referring to Table 1, the task category mapping table can be stored in the read-only memory area of the system kernel as an array or a dictionary.
[0053] Table 1: Task Category Mapping Table
[0054] Task unique identifier prefix or pattern Mapped task categories 0x1000-0x1FFF Computation-intensive 0x2000-0x2FFF IO intensive 0x3000-0x3FFF Hybrid
[0055] In practice, dividing the task record set into multiple task segment datasets according to task categories is a classification and aggregation operation. The system initiates the segmentation process periodically or when the task record set reaches a certain size. The process first traverses the entire task record set. For each task record in the set, the system extracts its unique task identifier and then uses this unique identifier as the key to query a predefined task category mapping table. The query operation returns the task category corresponding to the unique task identifier, such as compute-intensive, I / O-intensive, or hybrid. The system then adds the current task record to a segment dataset specifically used to store task data for that category, based on this task category. Essentially, the system maintains an independent segment dataset for each predefined task category, such as a compute-intensive task segment dataset, an I / O-intensive task segment dataset, and a hybrid task segment dataset. Each task segment dataset is essentially a linked list or dynamic array that stores all task records categorized into that task category. This segmentation process allows subsequent performance evaluations to be performed separately for different types of tasks, resulting in more targeted analysis results.
[0056] Optionally, a delayed binding mechanism can be introduced into the segmentation process. In some embodiments, the category of a task may not be fully determined when it is created, or its behavior pattern may change during execution. In this case, the task category mapping table can be designed to support dynamic updates. When recording task execution data, the task monitoring unit can temporarily refrain from category mapping and instead store the task records in a temporary unclassified set. Once the task ends and sufficient runtime features are collected, its task category is dynamically determined based on these actual runtime features, and the entry corresponding to the unique identifier of that task in the task category mapping table is updated. Finally, the task record is moved to the corresponding task segment dataset. This approach can improve the accuracy of task classification. To manage memory resources, the segmentation process can also include an aging mechanism. When the size of a task segment dataset exceeds a preset threshold, the system can archive the oldest portion of the task record data to an external storage device or directly remove it from memory, retaining only the task execution data from the most recent period for performance evaluation. This ensures that the task monitoring unit can run stably for a long time without exhausting system memory. It is understood that the ultimate goal of the entire monitoring process is to evaluate the performance of the segmented task execution data and store the results. The specific implementation method will be described in detail in a later section. The task monitoring unit collects task execution data in real time and associates it with unique task identifiers. Then, based on the correspondence between the unique task identifiers and task categories, the task execution data is segmented.
[0057] Example 5: In specific implementation, the system maintains a background performance evaluation thread, which is periodically activated or triggered when the number of task records in any task segment dataset accumulates to a certain threshold. The performance evaluation thread processes computationally intensive task segment datasets, I / O-intensive task segment datasets, and mixed task segment datasets sequentially. For each task segment dataset, the performance evaluation thread traverses all task records contained in the dataset. Each task record includes key runtime data such as task start time, task end time, and the number of CPU cycles used. The core of performance evaluation is calculating a set of performance metrics that characterize the execution characteristics of this type of task, among which average task execution time and load variance are two fundamental and important evaluation dimensions.
[0058] In practice, the average task execution time for each task segment dataset is calculated using statistical methods. The average task execution time reflects the central tendency of tasks belonging to the same task category in terms of execution time. The calculation process is as follows: The performance evaluation thread reads each task record in the task segment dataset, extracts the task end time and task start time from the task record, and subtracts these two timestamps to obtain the execution time of a single task. The execution times of the single tasks corresponding to all task records are summed to obtain a total execution time. Then, this total execution time is divided by the total number of task records contained in the task segment dataset, i.e., the number of tasks. The quotient is the average task execution time for that type of task. For example, assuming the computationally intensive task segment dataset contains 100 task records, and the total execution time of these 100 tasks is 5000 milliseconds, then the average task execution time for computationally intensive tasks is 5000 milliseconds / 100 = 50 milliseconds. This average task execution time metric helps the task scheduler understand the typical execution duration of different types of tasks, providing a reference for estimating task completion time and making scheduling decisions.
[0059] In practice, calculating the load variance metric for each task segment dataset is a crucial step in assessing task load volatility. The load variance metric quantifies the dispersion in resource consumption among tasks within a task segment dataset. The calculation of load variance is based on the number of CPU cycles occupied by tasks in the task execution data. The performance evaluation thread first calculates the average number of CPU cycles occupied by all tasks in the task segment dataset. Then, for each task in the dataset, it calculates the difference between its CPU cycle count and the average, and squares this difference. Next, it sums the squared differences for all tasks, and finally divides this sum by the number of tasks to obtain the load variance metric. A larger load variance metric indicates greater differences in CPU resource consumption among different instances of that type of task, and a more unstable load; a smaller metric indicates a more stable load. For example, for I / O-intensive tasks, the load variance may be larger because the uncertainty of I / O wait time can cause significant fluctuations in the actual number of CPU cycles consumed; while for compute-intensive tasks, the load variance may be relatively smaller because the computational load is relatively stable. The load variance metric provides data support for the task scheduler to identify task categories with large load fluctuations, allowing for a more conservative load balancing strategy when scheduling such tasks.
[0060] Performance evaluation may include other metrics, but this embodiment focuses on two fundamental metrics: average task execution time and load variance. In practice, storing the performance evaluation results in a database in association with task categories is a structured data persistence process. The database typically uses a relational database management system, which pre-creates a performance results table. This table contains several core fields: task category, average task execution time, load variance, and timestamp. The task category field stores the task category corresponding to the record, such as "compute-intensive," "IO-intensive," or "hybrid." The average task execution time field stores the calculated average task execution time value. The load variance field stores the calculated load variance value. The timestamp field records the time when the performance evaluation was completed. When the performance evaluation thread completes the metric calculation for a task segment dataset, it constructs a new database record, filling in the task category, calculated average task execution time, calculated load variance, and current timestamp into the corresponding fields. Then, it inserts this record into the performance results table through a database operation interface (such as an SQL INSERT statement).
[0061] In some embodiments, performance evaluation results are stored in an append-only manner rather than an overwrite manner. New evaluation results are inserted as new records into the database, while older records are retained. This creates a time-series arrangement of historical performance data, allowing the task scheduler not only to query the latest performance characteristics but also to analyze trends in performance metrics over time. For example, the scheduler can observe whether the average task execution time for a certain task category increases as system load increases.
[0062] Optionally, data validity verification can be incorporated into the performance evaluation process. Before calculating the average task execution time and load variance metrics, the performance evaluation thread scans the task segment dataset, identifying and excluding outlier task records. The criteria for identifying outlier task records can be based on statistical principles. For example, task records whose execution time or CPU cycles exceed the average by more than three standard deviations are considered outliers and removed from the metric calculation. This prevents individual extreme values from excessively interfering with the overall performance evaluation results, ensuring that the evaluation results better represent the general performance of this type of task.
[0063] Optionally, the frequency of performance evaluation can be dynamically adjusted based on the system activity level. The system can monitor the rate at which new task records are generated. When the system is busy, new tasks complete quickly, and the task segment dataset grows rapidly, the trigger threshold for the performance evaluation thread can be set lower, or the evaluation cycle can be shortened, to update the performance evaluation results more promptly and allow the scheduler to obtain the latest load characteristics. Conversely, when the system is idle, the evaluation frequency can be reduced to save computing resources.
[0064] Optionally, the database storing performance evaluation results can be optimized to support efficient queries. For example, a composite index can be created on the task category field and the timestamp field. This way, when the task scheduler needs to query "the average execution time of computationally intensive tasks in a recent period", the database can quickly locate the relevant record using the index without performing a full table scan, thereby reducing query latency and ensuring the real-time nature of scheduling decisions.
[0065] It's understandable that once performance evaluation results are stored in the database, they become a historical knowledge base that the task scheduler can query and use in subsequent scheduling decisions. When the task scheduler needs to make load balancing decisions, task allocation, or priority adjustments, it can send query requests to the database. For example, when the scheduler is about to assign a new task to a processing core, it can first assume its task category based on task attributes (if inferred) or default rules, and then query the database to obtain the recent average task execution time and load variance metric for that type of task. If the average task execution time is long, the scheduler may assign it to a relatively idle core with good caching; if the load variance metric is large, indicating high uncertainty in the execution time of that type of task, the scheduler may reserve more resource margin on the target core or avoid placing it together with other tasks that are also highly volatile.
[0066] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.
[0067] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.
Claims
1. A multi-core CPU task scheduling optimization method based on load balancing, characterized in that, The method includes: Continuously monitor the output value of the load balancing indicator in the task scheduler of the multi-core CPU. When the output value indicates that the system is in a balanced state, set the current task allocation mode of the multi-core CPU to the baseline task distribution. Collect real-time load measurements for each processing core in a multi-core CPU; A load distribution sequence is constructed based on real-time load measurements, and the load deviation parameter between the load distribution sequence and the baseline task distribution is calculated. The load imbalance status of a multi-core CPU is determined based on the load deviation parameters, including the degree of imbalance and the skewed core identifier. The output value of the load balancing indicator is updated based on the load imbalance status, and a task reallocation instruction is generated through the task scheduler to control the task scheduler to adjust the task allocation direction in the task queue. During task execution, the task monitoring unit collects task operation data in real time and associates it with the unique task identifier. Based on the correspondence between the unique task identifier and the task category, the task operation data is segmented, and the segmented task operation data is evaluated for performance and the results are stored.
2. The multi-core CPU task scheduling optimization method based on load balancing according to claim 1, characterized in that, The instantaneous load measurement of each processing core in the multi-core CPU is obtained by querying the hardware performance counter of each processing core, which is configured to sample the CPU utilization data of the core at fixed time intervals.
3. The multi-core CPU task scheduling optimization method based on load balancing according to claim 2, characterized in that, The step of constructing a load distribution sequence based on real-time load measurements includes: comparing the real-time load measurement of each processing core with the reference load value of the corresponding core in the baseline task distribution to obtain the load difference value of each core; determining the logical distance between cores based on the core arrangement topology of the multi-core CPU; and constructing a load distribution sequence using the load difference value and the logical distance between cores.
4. The multi-core CPU task scheduling optimization method based on load balancing according to claim 3, characterized in that, The calculation of the load deviation parameter between the load distribution sequence and the reference task distribution includes: projecting the load distribution sequence onto the reference task distribution plane to obtain a first projection length, where the first projection length represents the component of the load distribution sequence in the direction of the reference task distribution; calculating a second projection length of the load distribution sequence in the vertical direction, where the second projection length represents the cumulative magnitude of the load difference value; combining the first projection length and the second projection length into a right-angled triangle model, and calculating the load deviation angle between the load distribution sequence and the reference task distribution through trigonometric function relationships.
5. The multi-core CPU task scheduling optimization method based on load balancing according to claim 4, characterized in that, The method of determining the load imbalance state of a multi-core CPU based on the load deviation parameter includes: deriving the slope normal vector of the load distribution sequence based on the load deviation angle; calculating the angle between the slope normal vector and the reference task distribution plane as the degree of imbalance; and extracting the projection direction of the slope normal vector on the reference task distribution plane as the skewed core identifier.
6. The multi-core CPU task scheduling optimization method based on load balancing according to claim 5, characterized in that, The process of updating the output value of the load balancing indicator based on the load imbalance status includes: encoding the degree of imbalance and skew core identifier into the input signal of the load balancing indicator, adjusting the internal threshold of the load balancing indicator; and the task scheduler generating a task migration command based on the updated output value of the load balancing indicator.
7. The multi-core CPU task scheduling optimization method based on load balancing according to claim 6, characterized in that, The task scheduler adjusts the task allocation direction in the task queue by: parsing the task migration command and identifying the high-load core pointed to by the skew core identifier; and reallocating the tasks to be processed on the high-load core to the low-load core, so that the task allocation direction is consistent with the opposite direction of the skew core identifier.
8. The multi-core CPU task scheduling optimization method based on load balancing according to claim 7, characterized in that, The step of collecting task execution data in real time and associating it with a unique task identifier through the task monitoring unit includes: the task monitoring unit recording the task start time, task end time and number of CPU cycles occupied during task execution; and binding the task execution data with the unique task identifier assigned by the task scheduler to form a task record set.
9. A multi-core CPU task scheduling optimization method based on load balancing according to claim 8, characterized in that, The segmentation of task execution data based on the correspondence between task unique identifiers and task categories includes: predefining a task category mapping table to map task unique identifiers to compute-intensive, I / O-intensive, or hybrid task categories; and dividing the task record set into multiple task segment datasets according to task categories.
10. A multi-core CPU task scheduling optimization method based on load balancing according to claim 9, characterized in that, The process of evaluating and storing the performance results of the segmented task execution data includes: calculating the average task execution time and load variance for each task segment dataset; and storing the performance evaluation results in the database in association with the task category for the task scheduler to query and use in subsequent scheduling decisions.