Dynamic thread scheduling and cache optimization method for multi-core processor

Abstract

The invention relates to the technical field of computers, and particularly discloses a multi-core processor-oriented dynamic thread scheduling and cache optimization method, which comprises the following steps of: monitoring and collecting performance monitoring counting data of active hardware threads in real time, calculating cache conflict factors among the threads, and identifying thread pairs with serious conflicts. And generating a thread migration decision to migrate one thread in the conflict thread pair to a target processor core, and pre-distributing a protected cache partition in a final-stage cache of the target core for the thread to be migrated before a thread migration action is executed, and pre-loading historical access hot data. According to the method and the device, the effects of effectively reducing the cache conflict between the threads, improving the cache utilization rate and the performance of the multi-core processor, and further optimizing the system performance by reasonably scheduling the threads and preferentially processing the threads with high branch prediction misjudgment rate are achieved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a dynamic thread scheduling and cache optimization method for multi-core processors. Background Technology

[0002] The emergence of multi-core processors is a milestone in the development of computer technology. Multi-core processors significantly improve system computing power and processing efficiency, and have been widely used in many fields such as data centers and high-performance computing. They enable computers to handle multiple tasks simultaneously, greatly shortening data processing time and driving rapid development in many industries, including scientific research and industrial production. With the increasing complexity of software applications, the performance requirements for multi-core processors are also increasing, making the full utilization of their potential a hot research topic.

[0003] In thread scheduling and cache management for multi-core processors, traditional methods typically employ static scheduling strategies. A common approach is to allocate threads to specific processor cores based on their initial characteristics; this method is simple, direct, and easy to implement. Another approach is time-slice round-robin scheduling, which allocates processor time to each thread sequentially at fixed time intervals. For cache management, a uniform cache allocation strategy is generally used, regardless of the specific thread characteristics; all threads share cache resources. These methods can guarantee the normal operation of the system to a certain extent, but they lack adaptability to dynamic thread behavior.

[0004] Because it's impossible to perceive thread performance changes in real time, adjustments cannot be made promptly when cache access conflicts occur between threads. Cache conflicts between threads lead to increased last-level cache miss rates and increased inter-core cache coherency communication traffic, thereby reducing instruction throughput and severely impacting the overall performance of multi-core processors. Summary of the Invention

[0005] To address the problem of the inability to perceive thread performance changes in real time, which severely impacts the overall performance of multi-core processors, this application provides a dynamic thread scheduling and cache optimization method for multi-core processors.

[0006] This application provides a dynamic thread scheduling and cache optimization method for multi-core processors, which adopts the following technical solution:

[0007] A dynamic thread scheduling and cache optimization method for multi-core processors includes the following steps:

[0008] S1: Real-time monitoring and collection of performance monitoring count data of all active hardware threads in the system. The performance monitoring count data includes at least the last-level cache miss rate, inter-core cache coherency communication traffic and instruction throughput of each thread.

[0009] S2: Based on the real-time data collected in step S1, dynamically calculate the cache conflict factor between any two threads. The cache conflict factor is a weighted function of the final-level cache miss rate of the two threads and the cache consistency communication traffic between the two threads.

[0010] S3: Based on the cache conflict factor, identify thread pairs with severe cache access conflicts;

[0011] S4: Generate thread migration decision, migrate one thread from the conflicting thread pair identified in step S3 to a target processor core that can effectively reduce the cache conflict factor. The selection criteria for the target processor core include the current cache space freeness, physical distance from the source core, and the non-consistent memory access domain to which it belongs.

[0012] S5: Before the thread migration operation is executed, a protected cache partition is pre-allocated in the final cache of the target processor core for the thread to be migrated in, and the historical hot access data of the thread is preloaded into the partition.

[0013] By adopting the above technical solution, real-time monitoring and collection of performance monitoring count data of active hardware threads within the system can accurately grasp the status of each thread. Based on this data, the cache conflict factor can be dynamically calculated to quantify the degree of cache conflict between threads. Severely conflicting thread pairs are identified based on the cache conflict factor, providing a basis for subsequent thread migration. A thread migration decision is generated, migrating one thread from the conflicting thread pair to the target processor core. The target core is selected based on its cache space availability, physical distance from the source core, and its non-consistent memory access domain, effectively reducing the cache conflict factor. Before the thread migration is executed, a protected cache partition is pre-allocated in the target core's last-level cache for the thread to be migrated in, and historical access hot data is pre-loaded. This allows the thread to recover its working state more quickly after migration, reducing waiting time, improving the overall performance and operating efficiency of the multi-core processor, and making the operation of each thread smoother. This achieves a smooth process of dynamic thread scheduling and cache optimization.

[0014] Optionally, in step S2, the formula for calculating the cache conflict factor is:

[0015] CF(i,j) =α* (L3_miss_i + L3_miss_j) +β* CI_coherence_i j ,

[0016] Where CF(i,j) is the cache conflict factor, L3_miss_i and L3_miss_j are the last-level cache miss rates of thread i and thread j, respectively, CI_coherence_ij is the cache consistency communication traffic between thread i and thread j, and α and β are configurable weight coefficients.

[0017] By adopting the above technical solution, after real-time monitoring and collection of the performance monitoring count data of active hardware threads in the system, the cache conflict factor between any two threads can be dynamically calculated according to the formula. The configurable weight coefficient can flexibly adjust the calculation method, making the calculation results more in line with the actual situation, and providing an accurate basis for subsequent identification of thread pairs with serious cache access behavior conflicts.

[0018] Optionally, the specific method for identifying thread pairs with severe cache access conflicts in step S3 is as follows: set a dynamic threshold, and when the cache conflict factor of any thread pair continuously exceeds the dynamic threshold for a predetermined time window, then determine that the thread pair is a thread pair with severe conflict.

[0019] By adopting the above technical solution, and identifying thread pairs with severe conflicts based on the set dynamic threshold and predetermined time window, it is possible to more accurately identify thread pairs with severe cache access conflicts, so as to generate thread migration decisions in the future.

[0020] Optionally, the dynamic threshold is dynamically adjusted based on the system's current overall average last-level cache miss rate and average consistency communication traffic.

[0021] By adopting the above technical solution, the dynamic threshold is dynamically adjusted according to the system's current overall average last-level cache miss rate and average consistency communication traffic. This can more accurately identify thread pairs with severe cache conflicts, adapt to cache conflict situations under different system states, improve the sensitivity and accuracy of thread scheduling to cache conflicts, and thus optimize the cache utilization efficiency of multi-core processors.

[0022] Optionally, the physical distance in step S4 is determined by the routing hop count of the on-chip network within the processor or the number of nodes required to access the shared memory controller.

[0023] By adopting the above technical solution, the physical distance to the target core is determined by the number of routing hops of the on-chip network inside the processor or the number of nodes required to access the shared memory controller. This can effectively reduce the cache conflict factor. Furthermore, by combining factors such as the current cache space availability of the target core and the non-consistent memory access domain to which it belongs, the target core can be selected more accurately, thereby optimizing thread scheduling and cache usage.

[0024] Optionally, the preloading of historical access hot data in step S5 specifically involves: retrieving and reading the set of memory addresses recorded when the thread was most recently swapped out from a distributed historical record database based on the unique thread identifier of the thread to be migrated in. The set is arranged in descending order of access frequency.

[0025] By adopting the above technical solution, the set of memory addresses recorded at the time of the most recent swap-out, which are sorted in descending order of access frequency, can be retrieved from the distributed historical record library based on the unique thread identifier of the thread to be swapped in. This can be preloaded to effectively reduce the cache conflict factor and improve cache access efficiency. Furthermore, preloading the set of memory addresses sorted in descending order of access frequency can prioritize loading high-frequency access data, further improving performance.

[0026] Optionally, the process of preloading historical access hot data adopts a greedy algorithm until the cache partition pre-allocated for the thread to be migrated is filled or all historical hot data has been loaded.

[0027] By adopting the above technical solution, a protected cache partition is pre-allocated for the thread to be migrated into the target core's last-level cache, and historical access hot data is preloaded. The preloading process uses a greedy algorithm, which can make full use of the cache space, effectively reduce cache conflicts between threads, and improve the cache utilization and overall performance of multi-core processors.

[0028] Optionally, the protected cache partition in step S5 is implemented using the Way partitioning technology provided by the cache hardware. This partition will be preferentially allocated to the thread to be migrated in during subsequent operations until the next migration decision occurs.

[0029] By adopting the above technical solution, the Way partitioning technology of cache hardware is used to pre-allocate a protected cache partition in the last-level cache of the target core for the thread to be migrated in. This partition is then preferentially allocated to the migrated thread until the next migration decision occurs, which can effectively reduce the cache conflict factor, reduce the conflict of cache access behavior between threads, and improve the performance and efficiency of multi-core processors.

[0030] Optionally, the method is executed by a dedicated management thread running at the underlying level of the operating system kernel, and the dedicated management thread has a higher running priority than all user-mode threads.

[0031] By adopting the above technical solution, the method is executed using a dedicated management thread that runs at the bottom layer of the operating system kernel and has a higher priority than all user-mode threads. This ensures that the scheduling and optimization process is not interfered with by user-mode threads, guaranteeing stable and efficient execution of the method.

[0032] Optionally, the performance monitoring count data also includes the branch prediction misjudgment rate; when generating thread migration decisions in step S4, threads with high branch prediction misjudgment rates are preferentially scheduled to processor cores with larger branch predictor hardware resources.

[0033] By adopting the above technical solution, the data collected in real time increases the branch prediction misjudgment rate. When generating thread migration decisions, threads with high branch prediction misjudgment rates can be prioritized and scheduled to processor cores with larger branch predictor hardware resources. This can improve the accuracy of branch prediction, reduce the impact of branch prediction misjudgment on system performance, and optimize the overall system performance.

[0034] In summary, this application includes at least one of the following beneficial technical effects:

[0035] Real-time monitoring and collection of performance monitoring count data of active hardware threads in the system can dynamically identify thread pairs with serious cache access conflicts, promptly detect changes in thread performance, and solve the problem that traditional methods cannot detect changes in thread performance in real time.

[0036] The cache conflict factor between threads can be dynamically calculated based on the collected real-time data, which can more accurately measure the degree of cache conflict between threads and provide a scientific basis for subsequent identification of conflicting thread pairs.

[0037] A dynamic threshold is set to identify thread pairs with severe conflicts. This threshold is dynamically adjusted based on the system's current overall average last-level cache miss rate and average consistency communication traffic, which can adapt to the dynamic changes of the system and identify conflicting threads more accurately.

[0038] Before the thread migration operation is executed, a protected cache partition is pre-allocated in the last-level cache of the target core for the thread to be migrated in, and the historical hot data of the thread is preloaded into the partition. This can reduce cache conflicts, improve instruction throughput, and improve the overall performance of multi-core processors. Attached Figure Description

[0039] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0040] Figure 1 This is a schematic diagram of the dynamic thread scheduling and cache optimization method in Embodiment 1 of this application;

[0041] Figure 2 This is a schematic diagram of the process for identifying conflicting thread pairs in Embodiment 1 of this application;

[0042] Figure 3 This is a schematic diagram of the thread migration decision-making process in Embodiment 1 of this application.

[0043] The attached labels are: 1. Real-time monitoring and data collection; 2. Calculation of cache conflict factor; 3. Identification of conflicting thread pairs; 4. Generation of thread migration decisions; 5. Pre-allocation of cache partitions and pre-loading of hot data. Detailed Implementation

[0044] The following is in conjunction with the appendix Figure 1-3 This application will be described in further detail.

[0045] Example 1

[0046] This application discloses a dynamic thread scheduling and cache optimization method for multi-core processors. (Refer to...) Figure 1 The dynamic thread scheduling and cache optimization method for multi-core processors includes the following steps: 1. Real-time monitoring and data acquisition; 2. Calculation of cache conflict factor; 3. Identification of conflicting thread pairs; 4. Generation of thread migration decisions; 5. Pre-allocation of cache partitions and pre-loading of hot data.

[0047] Real-time monitoring and data acquisition 1 includes performance monitoring count data of all active hardware threads in the system. This performance monitoring count data includes at least the last-level cache miss rate, inter-core cache consistency communication traffic, and instruction throughput for each thread. By monitoring the acquired thread performance data in real time, the cache conflict factor between any two threads is dynamically calculated to identify thread pairs with severe conflicts. Based on the identified thread pairs with severe conflicts, a thread migration decision 4 is generated, followed by thread migration and cache pre-allocation and preloading. This application adopts a dynamic conflict awareness strategy and proposes a cache conflict factor as a quantitative indicator to dynamically evaluate the intensity of resource contention between any two threads, surpassing traditional static or semi-static scheduling strategies. It also tightly couples the thread migration decision with the pre-allocation of cache partitions and preloading of hot data 5, preparing hot data for the thread on the target core before physical migration occurs. This provides a low-overhead, high-efficiency collaborative optimization mechanism, significantly improving the overall performance and operating efficiency of multi-core processors, making the operation of each thread smoother, and achieving a smooth dynamic thread scheduling and cache optimization process.

[0048] Specifically, the step of real-time monitoring and collecting performance monitoring count data for all active hardware threads within the system employs performance monitoring equipment and data acquisition tools. The performance monitoring equipment can be a performance monitoring unit integrated into the processor, capable of acquiring various performance data of the threads in real time. The data acquisition tool can be a software program that collects and organizes the data acquired by the performance monitoring equipment. The performance monitoring unit is typically integrated within the processor and connects to each thread via hardware circuitry to acquire data in real time. The data acquisition software program runs in the operating system, communicating with the performance monitoring unit through the system interface to obtain the required data. Alternatively, the performance monitoring equipment can be a third-party professional monitoring chip, and the data acquisition tool can utilize an open-source data acquisition framework.

[0049] Based on the collected real-time data, the cache conflict factor between any two threads is dynamically calculated. This process requires a computing module, which can be a processing core within the processor. It calculates the cache conflict factor according to the formula, based on collected data such as the thread's final-level cache miss rate and cache coherency communication traffic. The processing core typically consists of multiple arithmetic logic units and registers, enabling rapid data processing. The formula for calculating the cache conflict factor is:

[0050] CF(i,j) = α * (L3_miss_i + L3_miss_j) + β * CI_coherence_i j ,

[0051] Here, CF(i,j) is the cache conflict factor, L3_miss_i and L3_miss_j are the last-level cache miss rates of thread i and thread j, respectively, CI_coherence_ij is the cache consistency communication traffic between thread i and thread j, and α and β are configurable weight coefficients. After real-time monitoring and collection of the performance monitoring count data of active hardware threads in the system, the cache conflict factor between any two threads can be dynamically calculated according to the formula. The configurable weight coefficients can flexibly adjust the calculation method, making the calculation results more consistent with the actual situation, and providing an accurate basis for subsequent identification of thread pairs with severe cache access conflicts. The calculation module here can also use a dedicated coprocessor to improve the calculation speed.

[0052] Reference Figure 2Based on the cache conflict factor, thread pairs with severe cache access conflicts are identified. A conflict identification module, which can be a software algorithm, compares the calculated cache conflict factor with a dynamic threshold. The dynamic threshold is dynamically adjusted based on the system's overall average last-level cache miss rate and average consistency communication traffic. The conflict identification module runs in the operating system and determines the dynamic threshold by reading the cache conflict factor obtained from the calculation module and system performance data, and then compares the results. The specific adjustment formula is as follows:

[0053] Threshold = γ * Avg_L3_miss + δ * Avg_CI_coherence,

[0054] Here, Threshold is a dynamic threshold, Avg_L3_miss is the system's current overall average last-level cache miss rate, Avg_CI_coherence is the system's current overall average consistency communication traffic, and γ and δ are configurable weighting coefficients. When the cache conflict factor of any thread pair continuously exceeds this dynamic threshold for a predetermined time window, the thread pair is determined to be a thread pair with severe cache conflicts. The dynamic threshold is dynamically adjusted based on the system's current overall average last-level cache miss rate and average consistency communication traffic, enabling more accurate identification of thread pairs with severe cache conflicts. It adapts to cache conflict situations under different system states, improves the sensitivity and accuracy of thread scheduling to cache conflicts, and thus optimizes the cache utilization efficiency of multi-core processors. This conflict identification module can also be implemented using hardware circuitry to accelerate the identification speed.

[0055] Reference Figure 3 The thread migration decision generation step 4 is used to migrate one thread from a conflicting thread pair to a target processor core that can effectively reduce the cache conflict factor. This step includes a decision generation module and a migration execution module. The decision generation module selects a suitable target processor core based on selection criteria such as the current cache space availability, physical distance from the source core, and the non-consistent memory access domain it belongs to.

[0056] Specifically, the decision generation module calculates a comprehensive score Score(k) for each candidate target core, using the following formula: Score(k) = ɦ * FreeSpace(k) - ɱ * PhysicalDistance(k) + ε * NUMAFactor(k), where FreeSpace(k) represents the current free space of the target core k's cache, expressed as a percentage, ranging from 0 to 100%; PhysicalDistance(k) represents the physical distance between the target core k and the source core, determined by the routing hops of the on-chip network within the processor or the number of nodes required to access the shared memory controller; NUMAFactor(k) is a factor related to the non-uniform memory access domain. If the target core k and the source core belong to the same non-uniform memory access domain, NUMAFactor(k) = 1, otherwise NUMAFactor(k) = 0; ɦ, ɱ, and ε are configurable weight coefficients used to adjust the importance of each factor in the comprehensive score. The decision generation module selects the target core with the highest comprehensive score as the migration target. This approach can effectively reduce cache conflict factors and can also combine factors such as the current cache space availability of the target core and its non-consistent memory access domain to select the target core more accurately, thereby optimizing thread scheduling and cache usage.

[0057] The current free space level of the cache is calculated using the following formula:

[0058] Idle cache level = (Total cache space - Used cache space) / Total cache space

[0059] The total cache space refers to the total capacity of the final cache of the target processor core, while the used cache space refers to the cache space currently being occupied by other threads.

[0060] The decision generation module can be an intelligent algorithm program that comprehensively considers various factors and makes decisions through analysis and calculation. The migration execution module is responsible for migrating the selected threads to the target processor core. The migration execution module can be the operating system scheduler, which achieves thread migration by modifying the thread scheduling information. The decision generation module can also employ machine learning algorithms to improve the accuracy of the decisions.

[0061] Before the thread migration operation is executed, a protected cache partition is pre-allocated in the last-level cache of the target processor core for the thread to be migrated in, and the thread's historical hot access data is preloaded into this partition. This process includes a cache allocation module and a data preloading module. The cache allocation module can be cache management hardware, which allocates a protected cache partition in the last-level cache of the target processor core according to the thread's needs. Specifically, the cache management hardware allocates the protected cache partition by controlling the cache's read and write permissions and allocation rules. The cache management hardware sets corresponding access permission flags for each storage unit of the cache. For the protected cache partition, its read and write permissions are marked so that only the thread to be migrated in is allowed to access it, and access requests from other threads are denied, thereby ensuring the independence and security of the data in this partition. In terms of allocation rules, the cache management hardware dynamically determines the size and location of the partition based on the historical access data of the thread to be migrated in and the current cache usage. For example, if the historical access data volume of the thread to be migrated is large, the cache management hardware will allocate a relatively large contiguous cache space as a protected cache partition; if the current cache space is relatively scattered, the cache management hardware will use an algorithm to select several suitable non-contiguous spaces to combine into a protected cache partition. The protected cache partition is implemented through the Way partitioning technology provided by the cache hardware. This partition will be preferentially allocated to the thread to be migrated in during subsequent operations until the next migration decision occurs.

[0062] The data preloading module retrieves and reads the set of memory addresses recorded when the thread was most recently swapped out from the distributed history database, based on the thread identifier unique to the thread to be migrated. This set is sorted in descending order of access frequency. Specifically, after the data preloading module starts, it first performs a precise search in the distributed history database based on the thread identifier of the thread to be migrated, locating the corresponding historical record. Then, it selects the data corresponding to the memory addresses in descending order of access frequency. During the preloading process, the data preloading module uses a greedy algorithm to attempt to load data into the cache partition pre-allocated for the thread to be migrated. After loading a portion of the data, it checks whether there is any remaining space in the cache partition. If the cache partition is full, loading stops; if all historical hot data has been loaded, loading also stops. The data preloading module can be a data transfer program that reads historical hot data from the distributed history database and loads it into the cache partition. The data preloading module can use a multi-threaded parallel loading method to improve loading speed.

[0063] Furthermore, the dynamic thread scheduling and cache optimization method for multi-core processors in this application is executed by a dedicated management thread running at the operating system kernel level. This dedicated management thread has a higher execution priority than all user-mode threads. Using a dedicated management thread running at the operating system kernel level with a higher priority than all user-mode threads ensures that the scheduling and optimization process is not interfered with by user-mode threads, guaranteeing stable and efficient execution of the method.

[0064] Furthermore, the data collected in step 1 of real-time monitoring and data acquisition also includes the branch prediction misjudgment rate. When generating thread migration decision 4, threads with high branch prediction misjudgment rates are prioritized for scheduling to processor cores with larger branch predictor hardware resources. Increasing the branch prediction misjudgment rate through real-time monitoring and data acquisition, and prioritizing the scheduling of threads with high branch prediction misjudgment rates to processor cores with larger branch predictor hardware resources when generating thread migration decision 4, can improve branch prediction accuracy, reduce the impact of branch prediction misjudgments on system performance, and optimize overall system performance.

[0065] The implementation principle of this embodiment is as follows: By monitoring thread performance data in real time, this embodiment can promptly understand the dynamic changes of threads. Calculating the cache conflict factor 2 can accurately quantify the degree of conflict between threads, thereby identifying thread pairs with severe conflicts. Thread migration decisions and execution can separate conflicting threads, reducing cache conflicts. Cache pre-allocation and preloading can prepare the necessary cache resources and hot data for threads in advance, improving thread running efficiency. Compared with traditional static scheduling and cache management methods, this embodiment can make real-time adjustments based on the dynamic behavior of threads, effectively reducing cache conflicts, improving the overall performance of multi-core processors, and making significant improvements and contributions to existing technologies. Example 2

[0066] This application discloses a dynamic thread scheduling and cache optimization method for multi-core processors. The difference between embodiment 2 and embodiment 1 is that in step S2, the cache conflict factor is calculated using a fuzzy computation method. This fuzzy computation method can employ a fuzzy inference system, which consists of four parts: fuzzification, a fuzzy rule base, a fuzzy inference engine, and defuzzification.

[0067] Fuzzification converts precise input quantities, such as thread last-level cache miss rate and cache consistency communication traffic, into fuzzy quantities. This can be achieved by defining different membership functions. For example, for the last-level cache miss rate, three fuzzy sets, "low," "medium," and "high," can be defined, each corresponding to a membership function that maps the actual last-level cache miss rate value to the membership degree of the corresponding fuzzy set.

[0068] The fuzzy rule base contains a series of fuzzy rules, which are derived from expert experience or past data. For example, a rule could be "If the last-level cache miss rate of thread i is high and the last-level cache miss rate of thread j is high, and the cache consistency communication traffic between thread i and thread j is high, then the cache conflict factor between thread i and thread j is high."

[0069] The fuzzy inference engine performs inference based on the input fuzzy quantities and the fuzzy rule base to produce fuzzy output results.

[0070] Defuzzification converts the fuzzy output into a precise cache conflict factor value. Common defuzzification methods include the centroid method and the maximum membership method. The fuzzy calculation module here can be an algorithm program based on fuzzy logic. It processes the input data according to preset fuzzy rules and membership functions to obtain the cache conflict factor.

[0071] The implementation principle of this embodiment is as follows: Fuzzy computation is used to calculate the cache conflict factor, which can more flexibly handle dynamic changes in threads. The fuzzy rules can be adjusted according to different application scenarios and system requirements, thereby more accurately reflecting the degree of conflict between threads. This approach avoids the limitations of fixed calculation formulas, improves the accuracy of cache conflict factor calculation, and thus enhances the effectiveness of thread scheduling and cache optimization, representing a significant improvement and contribution to existing technologies.

[0072] The above are all optional embodiments of this application and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the structure, shape and principle of this application should be covered within the scope of protection of this application.

Claims

1. A method for dynamic thread scheduling and cache optimization for a multi-core processor, comprising: The method comprises the following steps: S1: Real-time monitoring and collecting performance monitoring count data of all active hardware threads in the system, the performance monitoring count data at least including last-level cache miss rate, inter-core cache coherence communication traffic and instruction throughput of each thread; S2: Based on the real-time data collected in step S1, dynamically calculating a cache conflict factor between any two threads, the cache conflict factor being a weighted function of the last-level cache miss rate of the two threads and the cache coherence communication traffic between the two threads; S3: According to the cache conflict factor, identifying a thread pair with serious cache access behavior conflict; S4: Generating a thread migration decision, and migrating one thread in the thread pair identified in step S3 to a target processor core that can effectively reduce the cache conflict factor, the selection criteria of the target processor core including the idle degree of its current cache space, the physical distance from the source core and the non-coherent memory access domain to which it belongs; S5: Before the thread migration action is performed, pre-allocating a protected cache partition in the last-level cache of the target processor core for the thread to be migrated in, and pre-loading the historical access hot data of the thread into the partition.

2. The dynamic thread scheduling and cache optimization method for multi-core processors according to claim 1, wherein, In the step S2, the calculation formula of the cache conflict factor is: CF(i,j) =α* (L3_miss_i + L3_miss_j) +β* CI_coherence_i j, Wherein, CF(i,j) is the cache conflict factor, L3_miss_i and L3_miss_j are the last-level cache miss rates of thread i and thread j respectively, CI_coherence_i j is the cache coherence communication traffic between thread i and thread j, and α and β are configurable weight coefficients.

3. The method of claim 1, wherein, The specific way of identifying the thread pair with serious cache access behavior conflict in step S3 is: setting a dynamic threshold, and when the cache conflict factor of any thread pair continuously exceeds the dynamic threshold for a predetermined time window, the thread pair is determined to be a thread pair with serious conflict.

4. The dynamic thread scheduling and cache optimization method for multi-core processors according to claim 3, wherein, The dynamic threshold is dynamically adjusted according to the current overall average last-level cache miss rate and average coherence communication traffic of the system.

5. The method of claim 1, wherein, The physical distance in step S4 is determined by the routing hop count of the on-chip network in the processor or the number of nodes required to access the shared memory controller.

6. The method of claim 1, wherein, In step S5, the preloaded historical access hot data is specifically: according to the unique thread identifier of the thread to be migrated in, retrieving and reading the memory address set recorded when the thread was last swapped out from a distributed historical record library, and the set is arranged in descending order of access frequency.

7. The dynamic thread scheduling and cache optimization method for multi-core processors according to claim 6, wherein, The preloaded historical access hot data process adopts a greedy algorithm until the cache partition pre-allocated for the thread to be migrated in is filled or all historical hot data is loaded.

8. The method of claim 1, wherein, The protected cache partition in step S5 is realized by the Way partition technology provided by the cache hardware, and the partition will be preferentially allocated to the thread to be migrated in for use in subsequent operations until the next migration decision occurs.

9. The method of claim 1, wherein, The method is executed by a special management thread running at the bottom layer of an operating system kernel, and the special management thread has a higher running priority than all user state threads.

10. The method of claim 1, wherein, The performance monitoring count data further comprises a branch prediction misjudgment rate; when the thread migration decision is generated in step S4, threads with a high branch prediction misjudgment rate are preferentially scheduled to processor cores with greater branch predictor hardware resources.

Images