A method and system for dynamically optimizing CPU scheduling based on thread affinity

Abstract

The application relates to a method and system for dynamically optimizing CPU scheduling based on thread affinity, and belongs to the technical field of computer operating system performance optimization. The system constructs an affinity thread graph of a target thread in real time through eBPF, analyzes the CPU resident distribution of the affinity thread, integrates the affinity information into CPU selection, task queuing and dispatching logic, realizes the same core / NUMA node scheduling of the target thread and the affinity thread, reduces the cross-core overhead, and improves the execution efficiency of the target thread.

Description

Technical Field

[0001] This invention relates to a method and system for dynamically optimizing CPU scheduling based on thread affinity, belonging to the field of computer operating system performance optimization technology. Background Technology

[0002] In a multitasking operating system, the CPU scheduling efficiency of threads directly determines the program execution performance. Existing scheduling technologies have the following key problems:

[0003] Static affinity limitations: Traditional schedulers (such as CFS) rely on static CPU affinity configuration (such as taskset), which cannot respond to dynamic cooperation relationships during thread runtime (such as frequently woken thread pairs, cooperating threads sharing a cache), which can easily lead to cooperating threads being scattered across different CPU cores, causing cross-core cache invalidation, increased data migration overhead, and reduced target thread performance;

[0004] The scheduling strategy is out of sync with the collaboration requirements: Although existing scalable scheduling frameworks (such as the CFS scheduler) support custom scheduling logic, they mainly rely on virtual time (vtime) or FIFO to achieve fairness or simple ordering, without taking into account the actual affinity between threads (such as wake-up frequency and resource sharing) to optimize scheduling decisions.

[0005] The lack of linkage between affinity tracking and scheduling: Existing eBPF tools (such as the waker program) can track thread wake-up relationships, but they are only used for data collection and display. They do not feed back affinity data to the scheduler to drive dynamic adjustment of scheduling strategies, and therefore cannot directly improve the performance of the target thread.

[0006] Therefore, there is an urgent need for a technical solution that can capture the dynamic affinity relationship of threads in real time and deeply link it with CPU scheduling to solve the performance loss problem caused by cross-core scheduling of cooperating threads. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this invention provides a method and system for dynamically optimizing CPU scheduling based on thread affinity. It constructs a real-time "affinity thread graph" of the target thread (based on metrics such as wake-up frequency and cooperation frequency) using eBPF, analyzing the CPU resident distribution of affinity threads. Based on the sched_ext scheduling framework, affinity information is integrated into CPU selection, task enqueueing, and dispatch logic, achieving "target thread and affinity thread scheduling on the same core / NUMA node," reducing cross-core overhead and improving the execution efficiency of the target thread. This invention, built upon eBPF technology and the sched_ext scheduling framework, includes a kernel-mode eBPF module, a scheduling decision module, and a user-mode management module. These modules work together to achieve thread affinity tracking and scheduling optimization.

[0008] Terminology Explanation:

[0009] 1. BPF (Berkeley Packet Filter): BPF (Berkeley Packet Filter) was created in 1992. It was originally designed as a technology for efficiently filtering network packets. It filters useful data by executing simple rules in the kernel space and avoids copying useless data to the user space. It is the underlying foundation of tools such as tcpdump. However, its function is limited to network filtering, relies on a simple instruction set and interpreted execution, and has limited performance and complexity.

[0010] 2. eBPF (extended Berkeley Packet Filter): eBPF (extended Berkeley Packet Filter) is a disruptive extension of the traditional BPF after 2014. It breaks through the single network filtering scenario and becomes a general-purpose kernel-mode execution engine. It extends the instruction set to support complex logic (such as loops and function calls), introduces a verifier to ensure program security, uses JIT compilation to convert code into machine code to improve performance, and realizes kernel-user space data interaction through BPF mapping. It is widely used in performance analysis, security monitoring, network optimization and other fields, and is a flexible and efficient kernel programming framework in modern Linux systems.

[0011] 3. DSQ (Dispatch Queue): DSQ (Dispatch Queue) is a core component of the Linux kernel's sched_ext extensible scheduling framework. Its main function is to store tasks to be scheduled as a temporary buffer before they are finally dispatched to the CPU for execution. It also supports managing task sorting and dispatching logic according to different strategies.

[0012] 4. Sched_ext: sched_ext is an extensible BPF scheduling class introduced in Linux kernel version 6.12. Unlike traditional schedulers, it allows scheduling behavior to be dynamically defined through a set of BPF programs. Custom scheduling policies can be implemented without modifying the kernel source code, greatly improving scheduling flexibility.

[0013] 5. NUMA (Non-Uniform Memory Access): NUMA (Non-Uniform Memory Access) is a memory architecture designed for multi-processor or multi-socket computer systems. Its core is to integrate the CPU core with its corresponding local memory and I / O resources into independent "NUMA nodes". Different nodes are connected through the system interconnect bus. Unlike the traditional UMA (Uniform Memory Access) architecture, where all CPUs access memory at the same speed, in the NUMA architecture, the CPU accesses the memory within its local node much faster than accessing the memory of other nodes across nodes (cross-node access requires going through the interconnect bus, resulting in higher latency and lower bandwidth).

[0014] The technical solution of the present invention is as follows:

[0015] A method for dynamically optimizing CPU scheduling based on thread affinity, comprising the following steps:

[0016] (1) Real-time tracking of the affinity relationship of the target thread and the CPU affinity data of the affinity thread;

[0017] (2) Transform affinity information into scheduling strategies;

[0018] (3) Configure the target thread, monitor its status, and adjust its parameters.

[0019] According to a preferred embodiment of the present invention, in step (1), specifically:

[0020] (11) Reuse eBPF tracepoints (such as tp_btf / sched_wakeup, tp_btf / sched_waking), refer to the wake-up relationship recording logic of the waker program, and construct an affinity thread graph;

[0021] (12) By using cpu_affinity_map (PERCPU_ARRAY type BPF mapping), the CPU resident cores of high affinity threads are counted in real time, that is, the CPU cores where the affinity threads have been executed in the last 10 times. The core with the highest frequency is taken as the resident CPU, and the CPU affinity data is collected.

[0022] Specifically, data statistics are achieved through cpu_affinity_map. When a high-affinity thread is executed, the module records the CPU core in which it is located in real time and uses a sliding window mechanism (counting the 10 most recent execution records) to count the frequency of occurrence of each CPU core. Finally, the CPU core with the highest frequency is taken as the "resident CPU" of the high-affinity thread, thus completing the collection of CPU affinity data.

[0023] (13) Synchronize the affinity thread graph and resident CPU information to the scheduling decision module through the circular buffer (affinity_stats) to ensure low-latency data transmission.

[0024] According to a preferred embodiment of the present invention, the specific process of constructing the affinity thread graph in step (11) is as follows:

[0025] The mapping relationship between target threads and affinity threads is stored in an LRU hash table (affinity_tree). The key is the target thread PID, and the value is a struct affinity_node containing the affinity thread PID, wake-up frequency, and last cooperative timestamp.

[0026] The wake_relation function records the wake-up frequency of the target thread and other threads. When the wake-up frequency exceeds a preset threshold (such as 5 times per second), the thread is marked as a high affinity thread of the target thread.

[0027] This forms the affinity thread graph. The storage logic of affinity_tree is the data carrier of the graph, defining the structure and core fields of the graph. The frequency judgment logic of the wake_relation function is the dynamic update rule of the graph, which determines which threads can be included in the graph as high affinity threads. At the same time, high affinity threads are selected from all threads that interact with the target thread by using a wake-up frequency threshold (such as 5 times per second). These threads are closely cooperating and form the core subset of the target thread affinity relationship.

[0028] According to a preferred embodiment of the present invention, in step (2), specifically, a scheduling decision module is constructed based on the sched_ext scheduling framework and integrated into the kernel scheduling process to convert affinity information into a scheduling policy. The steps are as follows:

[0029] (21) When the target thread is awakened, select the CPU core;

[0030] (22) Enqueue the target thread into the CPU's local DSQ;

[0031] (23) If the eBPF tracing module is abnormal or the affinity thread does not exist, it will automatically fall back to the default scheduling logic of the scheduler CFS (such as global vtime fair scheduling) to ensure system stability.

[0032] CFS is a type of scheduler that is the default process scheduler in the Linux kernel. It implements fair scheduling based on virtual time (vtime) and supports scheduling policies such as FIFO. Therefore, in the scheduling rollback mechanism of this invention, the default scheduling logic of CFS is selected as a fallback solution to ensure compatibility with existing system scheduling mechanisms.

[0033] According to a preferred embodiment of the present invention, in step (21), when the target thread is awakened, the LRU hash table and cpu_affinity_map are queried to obtain the resident CPU core of the high affinity thread. If the resident CPU core is in an idle state and is within the CPU allowable mask of the target thread, the target thread is directly scheduled to the resident CPU core. If the resident CPU core is in an occupied state, an idle CPU core of the same NUMA node as the resident CPU is selected to avoid cross-NUMA node scheduling.

[0034] Specifically, an affinity query process is added to the callback function. It iterates through the LRU hash table and cpu_affinity_map to obtain the resident CPU cores of high affinity threads. Idle state and CPU allow mask verification logic is added. The is_idle parameter of the scx_bpf_select_cpu_dfl function is used to determine whether the resident CPU is idle. The bpf_task_cpu_allowed function is called to verify whether the CPU is within the allow mask of the target thread. Then, the scheduling priority is adjusted. If it is within the allow mask of the target thread, it is directly assigned to the CPU. Otherwise, the same NUMA node selection logic is triggered. That is, if all CPUs are in a high-occupancy state, the idle core of the resident CPU in the same NUMA node is selected to avoid cross-NUMA node scheduling.

[0035] According to a preferred embodiment of the present invention, in step (22), the target thread is preferentially enqueued into the local DSQ (dispatch queue) (such as SCX_DSQ_LOCAL) of the CPU where the affinity thread resides, rather than the global DSQ. If the target thread is associated with multiple high affinity threads, the local DSQ of the CPU with the largest number of high affinity threads is selected. When enqueuing, the virtual time (vtime) weight of the target thread is updated synchronously. When the target thread and the affinity thread are on the same core, the time slice ratio is increased by a preset ratio (such as 10%-20%) to ensure smooth collaboration.

[0036] Specifically, an affinity CPU matching step is added to the callback. The `find_affinity_cpu` function is used to obtain the CPUs where high affinity threads associated with the target thread reside. If multiple high affinity threads exist, the number of high affinity threads associated with each CPU is counted, and the CPU with the most high affinity threads is selected as the target CPU for enqueuing. Secondly, the DSQ selection strategy is adjusted. The `scx_bpf_dispatch` function is used to enqueue the target thread into the local DSQ (SCX_DSQ_LOCAL) of that CPU, instead of the default global DSQ. Dynamic adjustment logic for vtime weight is added. When the target thread and the affinity thread are on the same core, the time slice ratio is increased by a preset ratio (e.g., 10%-20%), and the weight is updated by multiplying `SCX_SLICE_DFL` by a coefficient (e.g., 1.1-1.2).

[0037] According to a preferred embodiment of the present invention, in step (3), specifically:

[0038] Target thread configuration: Users can specify the PID of the target thread to be optimized via the command line (e.g., . / affinity_sched -t 1234), and write the target PID into the eBPF target_pids mapping;

[0039] Status monitoring: By reading the eBPF circular buffer affinity_stats, information such as the list of affinity threads of the target thread, the CPU resident of affinity threads, and the target thread scheduling kernel can be displayed in real time;

[0040] Parameter adjustment: Supports dynamic adjustment of parameters such as affinity thread threshold (e.g., wake-up frequency threshold) and NUMA node priority to adapt to different application scenarios.

[0041] A system for dynamically optimizing CPU scheduling based on thread affinity, comprising:

[0042] The kernel-mode eBPF module is used to track the affinity of the target thread and the CPU affinity data of the affinity thread in real time.

[0043] The scheduling module is used to convert affinity information into scheduling strategies;

[0044] The user management module is used for target thread configuration, status monitoring, and parameter adjustment.

[0045] The beneficial effects of this invention are as follows:

[0046] 1. Significant performance improvement: This invention schedules the target thread and the affinity thread to the same CPU core, reducing cross-core cache misses and data migration overhead. The instruction execution efficiency of the target thread is improved by 15%-30%, which is especially suitable for thread collaboration-intensive scenarios (such as distributed computing and real-time data processing).

[0047] 2. Strong dynamic adaptability: This invention is based on eBPF to track thread affinity in real time, without the need for static configuration, and can respond to changes in the cooperation mode of threads during runtime (such as thread pairs that are temporarily woken up frequently).

[0048] 3. Low invasiveness: This invention is based on the eBPF and sched_ext framework, requires no modification to the kernel source code, can be dynamically enabled / disabled, and does not affect the original scheduling logic of the system;

[0049] 4. Good compatibility: This invention automatically falls back to the CFS default scheduling in abnormal scenarios to ensure system stability and supports NUMA architecture and multi-core CPUs;

[0050] 5. High observability: This invention displays the distribution and scheduling status of affinity threads in real time, which facilitates troubleshooting and parameter optimization. Attached Figure Description

[0051] Figure 1 This is a schematic diagram of the architecture of the present invention;

[0052] Figure 2 This is a schematic diagram of the process of the present invention. Detailed Implementation

[0053] The present invention will be further described below with reference to the embodiments and accompanying drawings, but is not limited thereto.

[0054] Example 1:

[0055] like Figure 1-2 As shown in the figure, this embodiment provides a method for dynamically optimizing CPU scheduling based on thread affinity, and the steps are as follows:

[0056] (1) Real-time tracking of the affinity relationship of the target thread and the CPU affinity data of the affinity thread, specifically:

[0057] (11) Reuse eBPF tracepoints (such as tp_btf / sched_wakeup, tp_btf / sched_waking), refer to the wake-up relationship recording logic of the wakeer program, and construct an affinity thread graph. The specific process is as follows:

[0058] The mapping relationship between target threads and affinity threads is stored in an LRU hash table (affinity_tree). The key is the target thread PID, and the value is a struct affinity_node containing the affinity thread PID, wake-up frequency, and last cooperative timestamp.

[0059] The wake_relation function records the wake-up frequency of the target thread and other threads. When the wake-up frequency exceeds a preset threshold (such as 5 times per second), the thread is marked as a high affinity thread of the target thread.

[0060] This forms the affinity thread graph. The storage logic of affinity_tree is the data carrier of the graph, defining the structure and core fields of the graph. The frequency judgment logic of the wake_relation function is the dynamic update rule of the graph, which determines which threads can be included in the graph as high affinity threads. At the same time, high affinity threads are selected from all threads that interact with the target thread by using a wake-up frequency threshold (such as 5 times per second). These threads are closely cooperating and form the core subset of the target thread affinity relationship.

[0061] (12) By using cpu_affinity_map (PERCPU_ARRAY type BPF mapping), the CPU resident cores of high affinity threads are counted in real time, that is, the CPU cores where the affinity threads have been executed in the last 10 times. The core with the highest frequency is taken as the resident CPU, and the CPU affinity data is collected.

[0062] Specifically, data statistics are achieved through cpu_affinity_map. When a high-affinity thread is executed, the module records the CPU core in which it is located in real time and uses a sliding window mechanism (counting the 10 most recent execution records) to count the frequency of occurrence of each CPU core. Finally, the CPU core with the highest frequency is taken as the "resident CPU" of the high-affinity thread, thus completing the collection of CPU affinity data.

[0063] (13) Synchronize the affinity thread graph and resident CPU information to the scheduling decision module through the circular buffer (affinity_stats) to ensure low-latency data transmission.

[0064] (2) Transform affinity information into scheduling strategies;

[0065] A scheduling decision module is built based on the sched_ext scheduling framework and integrated into the kernel scheduling process. It transforms affinity information into scheduling policies. The steps are as follows:

[0066] (21) When the target thread is awakened, query the LRU hash table and cpu_affinity_map to obtain the resident CPU core of the high affinity thread. If the resident CPU core is in an idle state and is within the CPU allowable mask of the target thread, the target thread is directly scheduled to the resident CPU core. If the resident CPU core is occupied, select an idle CPU core of the same NUMA node as the resident CPU to avoid cross-NUMA node scheduling.

[0067] Specifically, an affinity query process is added to the callback function. It iterates through the LRU hash table and cpu_affinity_map to obtain the resident CPU cores of high affinity threads. Idle state and CPU allow mask verification logic is added. The is_idle parameter of the scx_bpf_select_cpu_dfl function is used to determine whether the resident CPU is idle. The bpf_task_cpu_allowed function is called to verify whether the CPU is within the allow mask of the target thread. Then, the scheduling priority is adjusted. If it is within the allow mask of the target thread, it is directly assigned to the CPU. Otherwise, the same NUMA node selection logic is triggered. That is, if all CPUs are in a high-occupancy state, the idle core of the resident CPU in the same NUMA node is selected to avoid cross-NUMA node scheduling.

[0068] (22) Prioritize enqueuing the target thread into the local DSQ (dispatch queue) of the CPU where the affinity thread resides (such as SCX_DSQ_LOCAL), rather than the global DSQ. If the target thread is associated with multiple high affinity threads, select the local DSQ of the CPU with the most high affinity threads. When enqueuing, synchronously update the virtual time (vtime) weight of the target thread. When the target thread and the affinity thread are on the same core, increase the time slice ratio by a preset ratio (such as increasing it by 10%-20%) to ensure smooth collaboration.

[0069] Specifically, an affinity CPU matching step is added to the callback. The `find_affinity_cpu` function is used to obtain the CPUs where high affinity threads associated with the target thread reside. If multiple high affinity threads exist, the number of high affinity threads associated with each CPU is counted, and the CPU with the most high affinity threads is selected as the target CPU for enqueuing. Secondly, the DSQ selection strategy is adjusted. The `scx_bpf_dispatch` function is used to enqueue the target thread into the local DSQ (SCX_DSQ_LOCAL) of that CPU, instead of the default global DSQ. Dynamic adjustment logic for vtime weight is added. When the target thread and the affinity thread are on the same core, the time slice ratio is increased by a preset ratio (e.g., 10%-20%), and the weight is updated by multiplying `SCX_SLICE_DFL` by a coefficient (e.g., 1.1-1.2).

[0070] (23) If the eBPF tracing module is abnormal or the affinity thread does not exist, it will automatically fall back to the default scheduling logic of the scheduler CFS (such as global vtime fair scheduling) to ensure system stability.

[0071] CFS is a type of scheduler that is the default process scheduler in the Linux kernel. It implements fair scheduling based on virtual time (vtime) and supports scheduling policies such as FIFO. Therefore, in the scheduling rollback mechanism of this invention, the default scheduling logic of CFS is selected as a fallback solution to ensure compatibility with existing system scheduling mechanisms.

[0072] (3) Configure the target thread, monitor its status, and adjust its parameters. Specifically:

[0073] Target thread configuration: Users can specify the PID of the target thread to be optimized via the command line (e.g., . / affinity_sched -t 1234), and write the target PID into the eBPF target_pids mapping;

[0074] Status monitoring: By reading the eBPF circular buffer affinity_stats, information such as the list of affinity threads of the target thread, the CPU resident of affinity threads, and the target thread scheduling kernel can be displayed in real time;

[0075] Parameter adjustment: Supports dynamic adjustment of parameters such as affinity thread threshold (e.g., wake-up frequency threshold) and NUMA node priority to adapt to different application scenarios.

[0076] Example 2:

[0077] This embodiment provides a system for dynamically optimizing CPU scheduling based on thread affinity, applied to the method described in Embodiment 1, including:

[0078] The kernel-mode eBPF module is used to track the affinity of the target thread and the CPU affinity data of the affinity thread in real time.

[0079] The scheduling module is used to convert affinity information into scheduling strategies;

[0080] The user management module is used for target thread configuration, status monitoring, and parameter adjustment.

[0081] The specific steps for system implementation are as follows:

[0082] Step 1: System Initialization and Target Configuration:

[0083] 1.1 Loading kernel-mode eBPF modules: Using libbpf, eBPF programs related to affinity thread tracing and CPU affinity analysis are loaded into the kernel, and tracing points such as tp_btf / sched_wakeup, tp_btf / sched_waking, and tp_btf / sched_process_exit are mounted;

[0084] 1.2 Initialize BPF mappings: Create affinity_tree, cpu_affinity_map, target_pids, and affinity_stats mappings to store affinity relationships, CPU distribution, and interaction data;

[0085] 1.3 Configure the target thread: The user inputs the PID of the target thread to be optimized through the user-mode management module. The program writes the target PID into the target_pids mapping, triggering the eBPF module to start tracking the affinity of the thread.

[0086] Step 2: Affinity Thread Tracing and CPU Affinity Analysis:

[0087] 2.1 Affinity Thread Identification: When the target thread is woken up / wake-up by another thread, the wake_relation function of the eBPF module is triggered, recording the PID and timestamp of both parties and updating the affinity thread list of the target thread in the affinity_tree; if the wake-up frequency exceeds a preset threshold (e.g., 5 times per second), the thread is marked as a "high affinity thread";

[0088] 2.2 CPU affinity statistics: cpu_affinity_map records the CPU cores used by high affinity threads in real time for each execution. The cores with the highest frequency are counted through a sliding window (e.g., the last 10 executions) and are used as the "resident CPUs" of the affinity thread.

[0089] 2.3 Data Synchronization: Every 10ms, the eBPF module synchronizes the list of high-affinity threads and resident CPU information of the target thread to the scheduling decision module through the affinity_stats circular buffer.

[0090] Step 3: Affinity-based CPU scheduling optimization:

[0091] 3.1 CPU Selection Optimization: When the target thread is awakened, the select_cpu callback of the scheduling decision module is triggered:

[0092] • Query cpu_affinity_map to obtain the set of resident CPU cores for high affinity threads;

[0093] • Prioritize selecting cores that are idle in the set and within the CPU allowable mask for the target thread; if no idle cores are available, select idle cores from the same NUMA node;

[0094] 3.2 Task Enqueue Optimization: If the target thread is not directly assigned, the enqueue callback will prioritize enqueuing it into the local DSQ (SCX_DSQ_LOCAL) of the CPU selected in step 3.1 to avoid entering the global DSQ and causing cross-core scheduling; if the target thread and the affinity thread are on the same core, adjust their virtual time weight to increase the time slice ratio by 10%-20%;

[0095] 3.3 Task Assignment and Execution: During CPU scheduling, the target thread in the local DSQ is consumed first to ensure that the target thread and the affinity thread are executed on the same core, thereby reducing cache invalidation and data migration overhead.

[0096] Step 4: System Monitoring and Rollback

[0097] 4.1 Status Monitoring: The user-space management module reads affinity_stats data every second to display metrics such as the target thread's scheduling core, affinity thread distribution, and cache hit rate;

[0098] 4.2 Abnormal rollback: If the eBPF module fails (e.g., affinity_tree read fails) or the high affinity thread does not exist, the scheduling decision module automatically rolls back to the default scheduling logic of CFS (global vtime or FIFO) to avoid system crash;

[0099] 4.3 Resource cleanup: When the target thread exits, the eBPF module deletes the relevant data of that thread in affinity_tree and cpu_affinity_map through the tp_btf / sched_process_exit tracking point, thus releasing resources.

Claims

1. A method for dynamically optimizing CPU scheduling based on thread affinity, characterized in that, The steps are as follows: (1) Real-time tracking of the affinity relationship of the target thread and the CPU affinity data of the affinity thread, specifically: (11) Construct an affinity thread graph and store the mapping relationship between the target thread and the affinity thread through an LRU hash table. The key is the target thread PID and the value is struct affinity_node, which contains the affinity thread PID, wake-up frequency and last cooperation timestamp. The wake_relation function records the wake-up frequency of the target thread and other threads. When the wake-up frequency exceeds a preset threshold, the thread is marked as a high affinity thread of the target thread. (12) By using cpu_affinity_map, the CPU resident cores of high affinity threads are counted in real time, that is, the CPU cores where the affinity threads have been executed in the last 10 times. The core with the highest frequency is taken as the resident CPU, and the CPU affinity data is collected. (13) Synchronize the affinity thread graph and resident CPU information to the scheduling decision module through a circular buffer; (2) Transform affinity information into scheduling strategies. Specifically, construct a scheduling decision module to transform affinity information into scheduling strategies. The steps are as follows: (21) When the target thread is awakened, query the LRU hash table and cpu_affinity_map to obtain the resident CPU core of the high affinity thread. If the resident CPU core is in an idle state and is within the CPU allowable mask of the target thread, the target thread is directly scheduled to the resident CPU core. If the resident CPU core is occupied, select an idle CPU core of the same NUMA node as the resident CPU core to avoid cross-NUMA node scheduling. (22) Enqueue the target thread to the CPU's local DSQ; (23) If the eBPF tracing module is abnormal or the affinity thread does not exist, it will automatically fall back to the scheduler's default scheduling logic to ensure system stability; (3) Configure the target thread, monitor its status, and adjust its parameters.

2. The method for dynamically optimizing CPU scheduling based on thread affinity as described in claim 1, characterized in that, In step (22), the target thread is enqueued first into the local DSQ of the CPU where the affinity thread resides. If the target thread is associated with multiple high affinity threads, the local DSQ of the CPU with the most high affinity threads is selected. When enqueuing, the virtual time weight of the target thread is updated synchronously. When the target thread and the affinity thread are on the same core, the time slice ratio is increased according to a preset ratio.

3. The method for dynamically optimizing CPU scheduling based on thread affinity as described in claim 2, characterized in that, In step (3), specifically: Target thread configuration: Allows users to specify the PID of the target thread to be optimized via the command line and write the target PID into the eBPF target_pids mapping; Status monitoring: By reading the eBPF circular buffer affinity_stats, the system can display the target thread's affinity thread list, affinity threads resident on the CPU, and the target thread's scheduling core information in real time. Parameter adjustment: Supports dynamic adjustment of affinity thread threshold and NUMA node priority parameters to adapt to different application scenarios.

4. A system for dynamically optimizing CPU scheduling based on thread affinity, applied to the method for dynamically optimizing CPU scheduling based on thread affinity as described in claim 1, characterized in that, include: The kernel-mode eBPF module is used to track the affinity of the target thread and the CPU affinity data of the affinity thread in real time. The scheduling module is used to convert affinity information into scheduling strategies; The user management module is used for target thread configuration, status monitoring, and parameter adjustment.

Images