Server network process adaptive scheduling method, system and medium of numa architecture

Abstract

The application discloses a NUMA architecture server network process adaptive scheduling method and system and a medium, and the method comprises the steps of monitoring the data packets passed in the kernel network protocol stack of the server; obtaining the NUMA node number of the network card and the network process pid corresponding to the data packet according to the data packet and saving them, obtaining the mask of the local cpu according to the NUMA node number of the network card, and updating the cpu affinity mask of the network process pid according to the mask of the local cpu, so that the network process pid transmits data through the network card on the local cpu. The application realizes the cpu affinity adaptive function of the network process in various network application scenarios, effectively avoids the occurrence of cross-road memory access, and does not need to do additional core binding operation for the application outside the core. All data packets passing through the network card are supervised, and the application range is very wide.

Description

Technical Field

[0001] This invention relates to the field of network communication technology for servers, and specifically to a method, system, and medium for adaptive scheduling of server network processes based on a NUMA architecture. Background Technology

[0002] The main characteristic of SMP servers is sharing; all resources in the system (CPU, memory, I / O, etc.) are shared. This very characteristic leads to a major problem with SMP servers: their scalability is very limited. Due to this limitation, researchers began exploring technologies for effectively scaling to build large-scale systems, and NUMA is one such result.

[0003] Using NUMA technology, dozens (or even hundreds) of CPUs can be combined into a single server. Based on this, multi-socket servers have emerged. Multi-socket servers can be categorized by the number of physical CPUs, such as dual-socket, quad-socket, and eight-socket servers. A dual-socket server refers to the number of physical CPUs in the server; note that this is the number of physical CPUs, and the corresponding server motherboard will have two CPU slots. Dual-socket does not mean dual-core. Dual-core refers to installing two CPU cores on a single CPU, so a dual-core or multi-core CPU still appears as a single CPU. A multi-socket CPU, however, has as many visible CPUs as there are sockets. Taking the domestic Phytium platform Tengyun S2500 dual-socket server (hereinafter referred to as S2500) as an example, the S2500 server is an arm64 architecture dual-socket server using a dual-socket interconnect logic. The S2500 server also uses a NUMA architecture. In a NUMA structure, although memory is directly attached to the CPU, because the memory is evenly distributed across the nodes, there is a shorter response time (Local Access) only when the CPU accesses the physical address corresponding to the memory it directly attaches to. However, if data needs to be accessed in memory attached to other CPUs, it needs to be accessed through the inter-connect channel, which slows down the response time compared to before (Remote Access).

[0004] In multi-socket servers, besides the possibility of accessing memory across NUMA nodes, there is also the possibility of accessing memory across sockets. Cross-socket memory access incurs greater overhead and lower performance than cross-NUMA node memory access. Taking the Tengyun S2500 dual-socket server as an example, the S2500 has a master-slave dual-socket configuration, each with 64 processor cores and 8 NUMA nodes. Therefore, the S2500 dual-socket server has a total of 128 processor cores (cpu0~cpu127) and 16 NUMA nodes (node0~node15), including: master socket (cpu0~cpu63, node0~node7); slave socket (cpu0~cpu63, node0~node7). On an S2500 dual-socket server, there are three memory access methods: Memory Access 1: Local node memory access, e.g., the CPU of node0 accesses the memory of node0; Memory Access 2: Cross-node memory access, e.g., the CPU of node0 accesses the memory of node1; Memory Access 3: Cross-socket memory access, e.g., the CPU of node0 accesses the memory of node8. The memory access overhead is: Memory Access 3 > Memory Access 2 > Memory Access 1, with cross-socket memory access being significantly more expensive than the other two methods. During network data exchange, there is a memory copying process between user space and kernel space. Sending involves copying data from user space to kernel space, while receiving involves copying data from kernel space to user space. Kernel space memory is typically allocated based on NUMA node determination during driver design, prioritizing the nearest node. However, without binding, processes outside the kernel might run to a remote node or even cross-socket scheduling. In such cases, cross-socket memory access may occur during data copying, which is detrimental to the performance of high-performance network cards.

[0005] Therefore, a method for adaptive scheduling of multi-process network communication on servers is urgently needed to specifically address the performance issues of high-performance network interface cards (NICs) in NUMA-based servers. Linux developers have already considered NUMA architecture, and there are related commands outside the kernel that can bind relevant processes to corresponding CPUs or NUMA nodes, such as `taskset` or `numactl`. The following are examples of these two commands. For instance, when performing an iperf test, if the NIC is located on NUMA node0, the kernel binding command can be as follows:

[0006] Using taskset to bind cores:

[0007] Server-side: taskset -c 0-7iperf -s

[0008] Client: taskset -c 8-15iperf -c server_ip -i 1 -t 1000

[0009] Using numactl to bind cores:

[0010] Server-side: numactl --cpubind=0 --membind=0 iperf -s

[0011] Client: numactl --cpubind=1 --membind=1 iperf -c server_ip -i 1 -t 1000

[0012] However, this approach is not user-friendly, especially in high-concurrency network application scenarios where thousands of network processes need to be bound one by one, which is unacceptable to users. Therefore, how to achieve adaptive scheduling of server network processes in a NUMA architecture has become a critical technical problem that urgently needs to be solved. Summary of the Invention

[0013] The technical problem this invention aims to solve is to provide a NUMA-based server network process adaptive scheduling method, system, and medium that addresses the aforementioned issues in existing technologies. This method enables CPU affinity adaptation for network processes in various network application scenarios, effectively preventing cross-network memory access and eliminating the need for additional core binding operations outside the core. All data packets passing through the network card are monitored, making it widely applicable. This process is imperceptible to the user, representing an effective solution.

[0014] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0015] An adaptive scheduling method for network processes in a NUMA-based server includes:

[0016] S101 monitors the data packets passing through the server's kernel network protocol stack;

[0017] S102: Obtain the NUMA node number of the network card and the network process PID corresponding to the data packet according to the data packet and save it. Obtain the mask of the local CPU according to the saved NUMA node number of the network card, and update the CPU affinity mask of the network process PID according to the mask of the local CPU, so that the network process PID can transmit data through the network card on the local CPU.

[0018] Furthermore, in step S101, monitoring the data packets passing through the server's kernel network protocol stack means monitoring the data packets passing through the server's kernel network protocol stack at a specified frequency.

[0019] Furthermore, monitoring the data packets that pass through at the specified frequency means counting the data packets that pass through. If the count value is equal to the set value, an operation is triggered to obtain the NUMA node number of the network card and the network process PID corresponding to the data packet and save it, and then the count value is set to zero to start counting again.

[0020] Furthermore, before step S101, the scheduling frequency freq is initialized to 0. Step S101 includes:

[0021] S201, determine whether there are data packets being transmitted in the server's kernel network protocol stack. If there are data packets being transmitted, proceed to step S202; otherwise, end and exit.

[0022] S202: Monitor whether there are any data packets in the kernel network protocol stack of the monitoring server. If there are data packets, increment the scheduling frequency freq by 1, and then determine whether the scheduling frequency freq is greater than or equal to the set value. If not, jump to step S202; otherwise, jump to step S102.

[0023] Furthermore, the setting value in step S202 can be adjusted appropriately; in this example, the value is 15.

[0024] Further, step S102 includes saving the network process PID corresponding to the data packet into the device structure `dev` of the network card, and delaying the execution of the callback function `irq_work` of the work queue. Step S102 includes initializing the device structure `dev` in the server's kernel network protocol stack to save the current network process PID and the callback function `irq_work` of the work queue, and allocating memory for and initializing the callback function `irq_work` of the work queue; the execution of the callback function `irq_work` of the work queue includes:

[0025] S301, obtain the NUMA node number of the network card based on the data packet;

[0026] S302, determine whether the interrupt context is valid. If valid, end and jump to step S101; otherwise, jump to step S303.

[0027] S303, determine the type of the device structure dev of the network card. If it is a bound virtual network card device, obtain the NUMA node number node of the currently active slave device of the bound virtual network card device; jump to step S304.

[0028] S304, determine whether the NUMA node number of the network card is equal to -1. If it is true, end and jump to step S101; otherwise, jump to step S305.

[0029] S305 determines the CPU group to which the local CPU belongs based on the NUMA node number of the network card; and initializes and generates the mask of the local CPU based on the CPU group to which the local CPU belongs.

[0030] S306, determine whether the generated local CPU mask and the CPU affinity mask cpumask_src of the network process PID are consistent. If they are consistent, end and jump to step S101; otherwise, assign the generated local CPU mask to the CPU affinity mask cpumask_src of the network process PID and jump to step S101.

[0031] Furthermore, before jumping to step S305 in step S304, it also includes determining whether the current network process pid is less than or equal to 1. If it is true, the process ends and jumps to step S101; otherwise, it jumps to step S305.

[0032] Furthermore, at least one of steps S101 and S102 includes the step of identifying the server platform: obtaining server platform information; if the server platform information matches the preset server platform information, the process continues; otherwise, the process ends and exits.

[0033] The present invention also proposes a server network process adaptive scheduling system for NUMA architecture, comprising interconnected microprocessors and memory, wherein the microprocessors are programmed or configured to execute any of the server network process adaptive scheduling methods for NUMA architecture.

[0034] The present invention also proposes a computer-readable storage medium storing a computer program for being programmed or configured by a microprocessor to execute any of the server network process adaptive scheduling methods of the NUMA architecture described above. Attached Figure Description

[0035] Figure 1 This is a simplified flowchart of Embodiment 1 of the present invention.

[0036] Figure 2 This is a detailed flowchart of Embodiment 1 of the present invention.

[0037] Figure 3 This is a multi-path server network process adaptive data flow route diagram according to Embodiment 2 of the present invention. Detailed Implementation

[0038] Before introducing specific embodiments of the present invention, the definitions of relevant abbreviations and key terms are now explained:

[0039] NUMA Architecture: NUMA, or Non-Uniform Memory Access, focuses on addressing the limitations of server scalability. Its fundamental characteristic is that a server has multiple CPU modules (also called NUMA nodes), and each node consists of multiple CPUs. Each NUMA node has independent local memory, I / O, and other resources, and nodes exchange information through an interconnect module. Each CPU can quickly access the memory and other resources of its own NUMA node (local access) and access the memory and other resources of other nodes through the interconnect module (remote access). Obviously, the access speed of local memory is much higher than that of remote memory. For this reason, in development, to better utilize system performance, it is necessary to minimize the information exchange between different NUMA nodes.

[0040] Network Interface Card (NIC) Interrupts: In Linux systems, NIC I / O requests are handled through an interrupt system. When a network I / O request is needed, the NIC sends an interrupt signal to the CPU. Upon receiving the interrupt, the CPU immediately notifies the operating system of its arrival, and the operating system then executes the interrupt handler to process the NIC's network I / O request.

[0041] Multi-queue network interface cards (NICs): Multi-queue NIC technology was initially developed to address network I / O quality of service (QoS) issues. However, with the continuous improvement of network bandwidth and NIC performance, a single-core CPU can no longer fully meet the demands of NICs. Through the support of multi-queue NIC drivers, NIC I / O can be divided into multiple queues, and each queue can be bound to a different CPU core via interrupts, thereby satisfying the NIC's requirements.

[0042] SMP (Symmetric Multiprocessing): A symmetric multiprocessing system contains many tightly coupled processors. In such a system, all CPUs share all resources, such as the bus, memory, and I / O system. There is only one copy of the operating system or management database. The biggest characteristic of this system is that all resources are shared. There is no distinction between the multiple CPUs; they all access memory, peripherals, and a single operating system equally.

[0043] Example 1

[0044] The essence of software performance optimization is to maximize hardware performance. Therefore, our focus now is on minimizing cross-channel memory access. In terms of network card optimization, this requires enabling network processes to automatically affinity with the local CPU channel and prioritize the use of local memory; that is, implementing adaptive affinity scheduling for network processes. To avoid cross-channel memory access and achieve adaptive scheduling of network processes in a NUMA-based server, this embodiment proposes the following concept:

[0045] The server's kernel network protocol stack monitors all passing data packets (skb) at a certain frequency. It doesn't monitor every single data packet to prevent excessive resource overhead from setting too frequently. The NUMA node (node ​​number) of the network interface card (NIC) is obtained through the skb, and the current process ID (PID) is also obtained and saved. These are then scheduled in a delayed manner using a work queue. Based on the previously saved NIC NUMA node, the mask of the local CPU is obtained to set the CPU affinity of the PID. Real-time setting is not possible because the NIC transmits and receives data packets in an interrupt context, which does not allow sleeping or scheduling (see attached table). Therefore, it can only be set in a delayed manner using a work queue.

[0046] Based on the above concepts, this embodiment proposes an adaptive scheduling method for server network processes in a NUMA architecture, such as... Figure 1 As shown, it includes the following steps:

[0047] S101 monitors the data packets passing through the server's kernel network protocol stack;

[0048] S102: Obtain the NUMA node number of the network card and the network process PID corresponding to the data packet according to the data packet and save it. Obtain the mask of the local CPU according to the saved NUMA node number of the network card, and update the CPU affinity mask of the network process PID according to the mask of the local CPU, so that the network process PID can transmit data through the network card on the local CPU.

[0049] Through the above steps, this embodiment realizes the CPU affinity adaptive function of network processes in various network application scenarios, effectively avoiding cross-path memory access, and eliminating the need for additional core binding operations outside the core for the application. All data packets passing through the network card will be monitored, making it widely applicable.

[0050] In step S101 of this embodiment, monitoring the data packets that pass through the server's kernel network protocol stack means monitoring the data packets that pass through the server's kernel network protocol stack at a specified frequency to prevent resource overhead caused by excessively high frequency settings.

[0051] In this embodiment, monitoring the traversed data packets at a specified frequency refers to counting the traversed data packets. If the count value equals a set value, an operation is triggered to obtain and save the NUMA node number of the network card and the network process PID corresponding to the data packet, and then the count value is reset to zero to start counting again. Since the cross-path overhead of multi-path servers mainly bottlenecks the performance of high-performance network cards (such as 25G, 40G, 100G, etc.) and the data flow is large, keeping the count value greater than or equal to the set value before continuing to the next step is to avoid resource waste caused by each data packet going through the scheduling process, resulting in relatively low resource consumption.

[0052] like Figure 2 As shown, in this embodiment, before step S101, the scheduling frequency freq is initialized to 0. Step S101 includes:

[0053] S201, determine whether there is a transmission data packet skb in the server's kernel network protocol stack. If there is a transmission data packet skb, proceed to step S202; otherwise, end and exit.

[0054] S202: Monitor whether the kernel network protocol stack of the monitoring server has passed through the data packet skb. If the data packet skb has passed through, increment the scheduling frequency freq by 1, and then determine whether the scheduling frequency freq is greater than or equal to the set value. If not, jump to step S202; otherwise, jump to step S102.

[0055] The setting value in step S202 of this embodiment can be adjusted appropriately. In this example, the value is 15. Scheduling once according to 16 data packets can meet the needs of most scenarios, and the resource consumption is relatively small.

[0056] like Figure 2 As shown, step S102 in this embodiment includes saving the network process PID corresponding to the data packet to the device structure `dev` of the network card, and delaying the execution of the callback function `irq_work` of the work queue. A delayed work queue is used because data packet transmission and reception occur within the network card interrupt context, during which scheduling or sleeping is not allowed. Therefore, a real-time work queue cannot be used; a delayed work queue allows scheduling to occur only after the interrupt context is complete. Furthermore, step S102 includes initializing the device structure `dev` in the server's kernel network protocol stack to save the current network process PID and the callback function `irq_work` of the work queue, and allocating and initializing memory for the callback function `irq_work`. In this embodiment, the network process PID and the callback function `irq_work` are two newly added members to the device structure `dev`. Simultaneously, any memory allocation operation in the registration function must be accompanied by a memory release operation; otherwise, there is a risk of memory leaks.

[0057] like Figure 2 As shown, the execution of the callback function irq_work in this embodiment includes:

[0058] S301, obtain the NUMA node number of the network card based on the data packet;

[0059] S302, determine whether the interrupt context is valid. If valid, end and jump to step S101; otherwise, jump to step S303.

[0060] S303, determine the type of the network card's device structure dev. If it is a bound virtual network card device, obtain the NUMA node number of the currently active slave device of the bound virtual network card device; jump to step S304.

[0061] S304, determine whether the NUMA node number of the network card is equal to -1. If it is true, end and jump to step S101; otherwise, jump to step S305.

[0062] S305 determines the CPU group of this CPU based on the NUMA node number of the network card; initializes and generates the cpumask of this CPU based on the CPU group of this CPU.

[0063] S306, determine whether the generated local CPU mask cpumask and the network process PID CPU affinity mask cpumask_src are consistent. If they are consistent, end and jump to step S101; otherwise, assign the generated local CPU mask cpumask to the network process PID CPU affinity mask cpumask_src and jump to step S101.

[0064] like Figure 2 As shown, in this embodiment, before jumping to step S305 in step S304, it is further included to determine whether the current network process PID is less than or equal to 1. If it is true, the process ends and jumps to step S101; otherwise, it jumps to step S305. Determining whether the network process PID is greater than 1 is based on the fact that process 0 and process 1 are the idle process and the init process, respectively. In case the transmission of the network process PID is incorrect, it will not cause interference to these two processes.

[0065] In step S303 of this embodiment, it is determined whether the device structure dev of the network card is a bonding device. This is because the bonding master device is a virtual device and does not have a hardware NUMA node number attribute. If the NUMA node number node is read directly from the bonding master device, the result will only be NUMA_NO_NODE (with a value of -1). Therefore, the NUMA node number node can only be read from the slave device.

[0066] In step S306 of this embodiment, it is compared whether the cpumask mask of the local CPU has changed. If it has changed, the CPU affinity mask cpumask_src of the network process PID is set. This is done to reduce resource consumption, because the first part of the process is code logic, and the real resource consumption is concentrated in the later part of setting cpumask, because this interface has the schedule() function.

[0067] In this embodiment, at least one of steps S101 and S102 includes the step of identifying the server platform: obtaining server platform information; if the server platform information matches the preset server platform information, the process continues; otherwise, the process ends and exits.

[0068] This embodiment also proposes a server network process adaptive scheduling system based on NUMA architecture, including interconnected microprocessors and memory, wherein the microprocessors are programmed or configured to execute the server network process adaptive scheduling method based on NUMA architecture described in this embodiment.

[0069] This embodiment also proposes a computer-readable storage medium storing a computer program that is programmed or configured by a microprocessor to execute the server network process adaptive scheduling method of the NUMA architecture described in this embodiment.

[0070] In summary, this embodiment is applied to the kernel network protocol stack, remaining unnoticed by the user layer. However, it achieves CPU affinity settings for all off-kernel network processes, eliminating the need for users to perform kernel binding operations and significantly improving the user experience. Furthermore, this invention monitors all data packets passing through the network card, setting CPU affinity for relevant off-kernel network processes in real time. Combined with the NUMA attribute settings of high-performance network card drivers, it effectively achieves near-NUMA node transmission for memory copying between the kernel and user layers, avoiding cross-path memory access and maximizing hardware performance.

[0071] Example 2

[0072] This embodiment applies the method of Embodiment 1 to the Phytium S2500 multi-way server, thereby realizing a method for adaptive scheduling of network processes on the Phytium S2500 server platform. This method is applicable to dual-way servers, 4-way servers, and 8-way servers.

[0073] The method in this embodiment includes the following steps:

[0074] S1: After confirming that NUMA is enabled in the BIOS, perform initialization preparation work, which is called during the netdev registration phase, including:

[0075] (1) Determine if it is an S2500 platform. If yes, continue with the following steps (2);

[0076] (2) Store the current process pid and the callback function irq_work of the work queue in the reserved field of the dev structure;

[0077] (3) Allocate memory and initialize the callback function irq_work for the work queue;

[0078] (4) Clear the scheduling frequency counter freq;

[0079] S2: Based on step S101 of Embodiment 1, monitor the data packet skb, including:

[0080] (1) Determine if it is an S2500 platform. If yes, continue with the following steps (2);

[0081] (2) Determine if there is an incoming data packet skb; if not, terminate the process directly.

[0082] (3) If a data packet is received, increment the counter freq by 1;

[0083] (4) Determine the size of the counter freq. If it is less than 15, jump to step (2).

[0084] (5) If freq is greater than or equal to 15, save the current process pid, clear freq to zero, and schedule the delayed work queue irq_work;

[0085] S3: Based on step S102 of Embodiment 2, the callback function irq_work for the delayed scheduling execution work queue includes:

[0086] (1) Obtain the NUMA node number (node) of the network card based on the data packet skb;

[0087] (2) Determine whether it is in an interrupt context. If yes, jump to step (2) of S2. Otherwise, continue.

[0088] (3) Determine if pid is less than or equal to 1. If yes, jump to step (2) of S2. Otherwise, continue.

[0089] (4) Determine if dev is a bonding device. If it is, reacquire the numanode based on the currently active slave device. Otherwise, continue.

[0090] (5) Determine if node is equal to -1. If yes, jump to step (2) of S2. Otherwise, continue.

[0091] (6) Get which channel the current network card is on, that is, get the channel where the CPU is located based on the numa node number of the current network card, and assign it to cpu_group;

[0092] (7) Initialize the cpumask of the CPU in this path according to cpu_group;

[0093] (8) Compare whether the CPU affinity mask cpumask of this process is different from the original CPU affinity mask cpumask_src of the current process pid. If they are different, set the value of the CPU affinity mask cpumask_src of the current process pid to the value of the CPU affinity mask cpumask of this process. If they are the same, jump to step (2) of S2.

[0094] After applying the method of this embodiment to the S2500 dual-socket server, its network process status is as follows: Figure 3 As shown, the following is a detailed explanation:

[0095] We'll tentatively designate the first path on the left as the main path, corresponding to processor cpu0 (its actual numbering should be 0-63) and memory mem0.

[0096] The second path on the right is tentatively designated as the slave path, corresponding to processor cpu1 (the actual number should be 64-127) and memory mem1.

[0097] Process A transmits data through the network card on the main path (cpu0, mem0). The data flow path is line "A". It is processed by cpu0 and accesses mem0.

[0098] Process B transmits data through the network card on the path (cpu1, mem1). The data flow path is line "B". It is processed by cpu1 and accesses mem1.

[0099] In this way, all data streams passing through the main network interface card use the main memory mem0, and the corresponding processes are all compatible with the main CPU0, following the "..." A"Data flow path; all data flows through the slave network card use slave memory mem1, and the corresponding processes are all compatible with slave cpu1, taking the "B" data flow path; cross-path memory access is avoided, and the adaptive behavior of the off-core network process is realized, without the need for user space to use commands such as taskset or numactl to bind each process to the core."

[0100] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0101] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A method for adaptive scheduling of network processes in a NUMA-based server, characterized in that, include: S101 monitors the data packets passing through the server's kernel network protocol stack; S102: Obtain the NUMA node number of the network card and the network process PID corresponding to the data packet according to the data packet and save it. Obtain the mask of the local CPU according to the saved NUMA node number of the network card, and update the CPU affinity mask of the network process PID according to the mask of the local CPU, so that the network process PID can transmit data through the network card on the local CPU. Save the network process PID corresponding to the data packet to the device structure dev of the network card, and schedule the execution of the callback function irq_work of the work queue with a delay; In the server's kernel network protocol stack, the device structure `dev` is initialized to store the current network process PID and the work queue callback function `irq_work`. Memory is then allocated and initialized for the work queue callback function `irq_work`. The execution of the work queue callback function `irq_work` includes: S301, obtain the NUMA node number of the network card based on the data packet; S302, determine whether the interrupt context is valid. If valid, end and jump to step S101; otherwise, jump to step S303. S303, determine the type of the device structure dev of the network card. If it is a bound virtual network card device, obtain the NUMA node number node of the currently active slave device of the bound virtual network card device; jump to step S304. S304, determine whether the NUMA node number of the network card is equal to -1. If it is true, end and jump to step S101; otherwise, jump to step S305. S305 determines the CPU group of this CPU based on the NUMA node number of the network card; and initializes and generates the mask of this CPU based on the CPU group of this CPU. S306, determine whether the generated local CPU mask and the CPU affinity mask cpumask_src of the network process PID are consistent. If they are consistent, end and jump to step S101; otherwise, assign the generated local CPU mask to the CPU affinity mask cpumask_src of the network process PID and jump to step S101.

2. The server network process adaptive scheduling method for NUMA architecture according to claim 1, characterized in that, In step S101, monitoring the data packets passing through the server's kernel network protocol stack means monitoring the data packets passing through the server's kernel network protocol stack at a specified frequency.

3. The server network process adaptive scheduling method for NUMA architecture according to claim 2, characterized in that, The monitoring of the data packets that pass through according to the specified frequency refers to counting the data packets that pass through. If the count value is equal to the set value, an operation is triggered to obtain the NUMA node number of the network card and the network process PID corresponding to the data packet and save it, and then the count value is set to zero to start counting again.

4. The server network process adaptive scheduling method for NUMA architecture according to claim 3, characterized in that, Before step S101, the scheduling frequency freq is initialized to 0. Step S101 includes: S201, determine whether there are data packets being transmitted in the server's kernel network protocol stack. If there are data packets being transmitted, proceed to step S202; otherwise, end and exit. S202: Monitor whether there are any data packets in the kernel network protocol stack of the monitoring server. If there are data packets, increment the scheduling frequency freq by 1, and then determine whether the scheduling frequency freq is greater than or equal to the set value. If not, jump to step S202; otherwise, jump to step S102.

5. The server network process adaptive scheduling method for NUMA architecture according to claim 4, characterized in that, The setting value in step S202 is 15.

6. The server network process adaptive scheduling method for NUMA architecture according to claim 1, characterized in that, Before jumping to step S305 in step S304, it also includes determining whether the current network process pid is less than or equal to 1. If it is true, the process ends and jumps to step S101. Otherwise, proceed to step S305.

7. The server network process adaptive scheduling method for NUMA architecture according to claim 1, characterized in that, At least one of steps S101 and S102 includes the step of identifying the server platform: obtaining server platform information; if the server platform information matches the preset server platform information, the process continues; otherwise, the process ends and exits.

8. A NUMA-based server network process adaptive scheduling system, comprising interconnected microprocessors and memory, characterized in that, The microprocessor is programmed or configured to execute the server network process adaptive scheduling method of the NUMA architecture according to any one of claims 1 to 7.

9. A computer-readable storage medium storing a computer program, characterized in that, The computer program is used to be programmed or configured by a microprocessor to execute the server network process adaptive scheduling method of the NUMA architecture according to any one of claims 1 to 7.

Images