Process control method, computer equipment and computer storage medium
By binding processes to the target CPU in the DPDK application and using custom sleep actions, the problem of actual sleep time prolonged due to process preemption of CPU is solved, and lower packet processing delays and higher CPU utilization is achieved.
Patent Information
- Application Number
- CN202510522480.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-24
- Publication Date
- 2025-08-12
AI Technical Summary
In the field of high real-time and low-latency computing, DPDK applications have extended the actual sleep time caused by the process preemption of CPU during sleep operations, increasing the problem of packet processing delay.
By binding the target process to the target CPU and performing custom sleep actions, the process continues to occupy the CPU and avoid preemption from other processes. The PAUSE instruction is used to replace the traditional sleep function to maintain CPU usage.
It reduces the actual sleep time of the process, reduces the packet processing delay, and improves CPU utilization and processing efficiency.
Smart Images
Figure CN120469775A_ABST
Abstract
Description
Technical Field
[0001] The embodiments of the present application relate to the field of program development, and specifically to a process control method, a computer device, and a computer storage medium. Background Art
[0002] To address performance bottlenecks in traditional Linux network drivers, such as system call overhead, interrupt latency, kernel-mode to user-mode switching, and packet copying, the Data Plane Development Kit (DPDK) has become a popular development direction for network developers, enabling direct packet transmission, reception, and processing in user mode. However, some challenges remain in areas requiring high real-time, low-latency computing.
[0003] For example, during the Pool Mode Driver (PMD)'s packet collection process, a DPDK application typically performs a sleep operation, briefly placing the process in a dormant state. This sleep operation can cause delays in packet processing. Furthermore, after the DPDK application yields the CPU during the sleep operation, other processes on the system may preempt the CPU, causing the actual sleep time to exceed the specified sleep time, further increasing packet processing delays. Summary of the Invention
[0004] An embodiment of the present application provides a process control method, a computer device, and a computer storage medium, in which a process continues to run based on a custom sleep action and does not give up the CPU to which it is bound, so that other processes cannot preempt the CPU, thereby avoiding an increase in the actual sleep time of the process due to other processes preempting the CPU.
[0005] A first aspect of an embodiment of the present application provides a process control method, the method comprising:
[0006] In response to a setting operation on the CPU affinity of a target process, binding the target process to a target CPU indicated by the setting operation;
[0007] The target process is configured to receive data packets in sequence when running on the target CPU, and process the data packets of the current batch upon receiving the data packets of the current batch;
[0008] Each time it is determined that the target process completes processing of the current batch of data packets, a custom sleep action is performed on the target process, so that the target process continues to occupy the target CPU to which the target process is bound.
[0009] A second aspect of an embodiment of the present application provides a computer device, the computer device comprising:
[0010] A setting unit, configured to, in response to a setting operation on the CPU affinity of a target process, bind the target process to a target CPU indicated by the setting operation;
[0011] The target process is configured to receive data packets in sequence when running on the target CPU, and process the data packets of the current batch upon receiving the data packets of the current batch;
[0012] The control unit is configured to execute a custom sleep action on the target process each time it is determined that the target process completes processing of the current batch of data packets, so that the target process continues to occupy the target CPU to which the target process is bound.
[0013] A third aspect of an embodiment of the present application provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor implements the method of the first aspect when executing the computer program.
[0014] A fourth aspect of an embodiment of the present application provides a computer storage medium, in which instructions are stored. When the instructions are executed on a computer, the computer executes the method of the first aspect.
[0015] It can be seen from the above technical solutions that the embodiments of the present application have the following advantages:
[0016] Each time the computer device determines that the target process has completed processing the current batch of data packets, it can execute a custom sleep action on the target process. The target process then continues to run based on the custom sleep action and is not suspended. In this state, the target process does not relinquish its bound target CPU, but instead continues to occupy the target CPU, preventing other processes from preempting it. This prevents the target process's actual sleep time from increasing due to other processes preempting the CPU, thereby reducing the target process's sleep time and the delay in processing data packets. BRIEF DESCRIPTION OF THE DRAWINGS
[0017] Figure 1 This is a flow chart of the process control method in the embodiment of the present application;
[0018] Figure 2 This is an exemplary schematic diagram of the CPU binding strategy of the multi-process model of the DPDK application in the embodiment of the present application;
[0019] Figure 3 This is an exemplary diagram of the CPU distribution of NUMA nodes when hyperthreading is enabled in an embodiment of the present application;
[0020] Figure 4This is an exemplary schematic diagram of the CPU distribution of NUMA nodes when hyperthreading is not enabled in an embodiment of the present application;
[0021] Figure 5 This is a schematic diagram of an exemplary content of statistical information of multiple CPUs for running multiple DPDK slave processes in an embodiment of the present application;
[0022] Figure 6 This is a structural diagram of a computer device in an embodiment of the present application;
[0023] Figure 7 This is another structural diagram of the computer device in the embodiment of the present application. DETAILED DESCRIPTION
[0024] An embodiment of the present application provides a process control method, a computer device, and a computer storage medium, in which a process continues to run based on a custom sleep action and does not give up the CPU to which it is bound, so that other processes cannot preempt the CPU, thereby avoiding an increase in the actual sleep time of the process due to other processes preempting the CPU.
[0025] The DPDK application process processes packets. When a process calls the sleep function, it is marked as suspendable. The CPU bound to the process will then process instructions from other processes instead of the DPDK application process. The latency of the DPDK application process in processing packets is the sleep duration of the DPDK application process.
[0026] In an operating system, the sleep time of a process refers to the time the process enters the sleep state after calling a sleep function (such as the sleep function). However, the actual sleep time may be longer than the specified sleep time for the following reasons:
[0027] Scheduling delay: The operating system uses a scheduling algorithm to manage process execution. When a process calls the sleep function, it is marked as suspendable, and the operating system may delay waking up the process when other processes need CPU resources.
[0028] System load: If the system load is high, the CPU resources are occupied by other processes, causing the awakened process to wait longer to regain control of the CPU.
[0029] Time Slice: The operating system typically allocates a time slice to each process, and the process is suspended after the time slice is used up. If other processes frequently seize the CPU while the process is sleeping, the awakened process may be suspended again during its actual execution.
[0030] Priority: The priority of a process also affects the order in which it is scheduled. If a low-priority process is awakened while a high-priority process is running, it may be suspended again, resulting in a longer actual sleep time.
[0031] In summary, the actual sleep time of a process may be longer than the specified sleep time due to CPU preemption by other processes, which in turn increases the delay in the process processing data packets.
[0032] In order to solve the above technical problems, a process control method according to an embodiment of the present application is proposed. The process control method according to an embodiment of the present application is described below:
[0033] See also Figure 1 In one embodiment of the process control method of the present application, the following steps are included:
[0034] 101. In response to a setting operation for CPU affinity of a target process, bind the target process to the target CPU indicated by the setting operation; wherein the target process is configured to sequentially receive data packets when running on the target CPU and process the data packets of a current batch upon receiving the data packets of the current batch;
[0035] The method of this embodiment can be applied to a computer device, which can manage and control processes running on the system based on the method of this embodiment. In response to an operation to set the CPU affinity of a target process, the computer device can bind the target process to the target CPU indicated by the setting operation, and the target process can then run on the target CPU. The target process can be configured to sequentially receive data packets when running on the target CPU and process the current batch of data packets upon receiving the current batch of data packets. That is, the target process performs polling to receive packets and processes the data packets received each time a packet is received.
[0036] 102. Each time it is determined that the target process has completed processing of the current batch of data packets, a custom sleep action is performed on the target process, so that the target process continues to occupy the target CPU to which the target process is bound;
[0037] Each time the computer device determines that the target process has completed processing the current batch of data packets, it can execute a custom sleep action on the target process. The target process then continues to run based on the custom sleep action and is not suspended. In this state, the target process does not relinquish its bound target CPU, but instead continues to occupy the target CPU, preventing other processes from preempting it. This prevents the target process's actual sleep time from increasing due to other processes preempting the CPU, thereby reducing the target process's sleep time and the delay in processing data packets.
[0038] In an optional implementation, this embodiment can be applied to scenarios where a DPDK application process receives and processes data packets. Specifically, when a DPDK process is running, its process type parameter, proc-type, can be set to primary. This initializes the process as the primary process. The DPDK primary process is used to create huge pages, memory pools, and network card packet queues.
[0039] When the DPDK process is running, if its process type parameter --proc-type is set to second, this process will be initialized as a slave process. The DPDK slave process will not repeatedly create large page memory, memory pool and other information, but will map them through the mmap method to ensure that it operates on the same resources as the DPDK master process.
[0040] In another optional implementation, the CPU bound to a process can be set by configuring its CPU affinity. CPU affinity refers to the tendency of a process or thread to execute on one or more CPU cores at runtime, rather than randomly or frequently switching between different cores. This feature can improve the performance of a process or thread by leveraging the locality of the CPU cache and reducing the overhead of cache invalidation and process migration.
[0041] Specifically, the CPU affinity of the target process may be set to bind the target process to the target CPU so that the target process runs on the target CPU.
[0042] For example, when a DPDK process is running, after the process is started, you can use the taskset command to set the process's CPU affinity. Assuming that the PID of DPDK slave process 1 is 1234, if you want to bind it to CPU 1, execute taskset-pc 11234.
[0043] In addition, during the process startup process, the CPU affinity of the current process can also be set through the standard API sched_setaffinity(pid_tpid,unsigned intcpusetsize,cpu_set_t*mask).
[0044] sched_setaffinity is a system call provided by the Linux kernel that sets the CPU affinity mask for a process or thread, thereby specifying which CPU cores the process or thread can run on. By using this function, a process or thread can be bound to a specific CPU core to improve performance and reduce cache invalidations.
[0045] like Figure 2As shown in the figure, suppose a server deploys a NUMA architecture, where NUMA stands for Non-Uniform Memory Access, which is an architecture between multiple CPUs, memory, and buses. Assuming that the number of NUMA nodes in the deployed NUMA architecture is 2 and each NUMA node has 4 CPUs, the CPU binding strategy of the multi-process model of the DPDK application can be as follows: Figure 2 As shown, the DPDK master process is mapped to multiple DPDK slave processes, and CPU affinity is set for each DPDK slave process, so that each DPDK slave process is bound to the corresponding CPU, and each DPDK slave process can run on the CPU to which it is bound.
[0046] based on Figure 1 In an optional implementation of the embodiment shown, a custom sleep action is performed on the target process, specifically, a PAUSE instruction is executed on the target process, so that the target process continues to run and spin-wait with lower resource consumption to continue to occupy the target CPU.
[0047] For example, during the PMD's polling period, the DPDK slave process receives and processes packets in batches using the rte_eth_rx_burst function. At the end of each loop, a custom do_sleep operation is performed, where each loop receives and processes a packet. In related solutions, if the do_sleep operation is implemented using an API like usleep, the CPU will be released while the process is sleeping, giving other processes on the system the opportunity to preempt the CPU, increasing the latency of the DPDK slave process in processing packets.
[0048] Therefore, in this embodiment, the do_sleep operation is replaced with the cpu_relax() operation. The cpu_relax() operation can be defined as executing the PAUSE instruction, which is specifically designed to optimize busy-wait loops. This operation does not release the CPU, causing the CPU usage of the DPDK slave process to approach 100%, meaning that other processes cannot be scheduled onto these CPUs. The cpu_relax() operation also indicates to the processor that the current process is idle, which can reduce power consumption and processor resource consumption, thereby avoiding waste of processor resources.
[0049] Because the target process will not give up its bound CPU, and the system has other processes that need to be scheduled besides the target process. For example, because the CPU bound to the DPDK slave process will not be given up (the cpu_relax instruction will not give up the CPU), and the system has other processes that need to be scheduled besides the DPDK process, it is necessary to set a policy to determine which CPUs in the system should be used by the DPDK slave process and which CPUs should be reserved for use by other processes.
[0050] Therefore, based on Figure 1 In an optional implementation of the illustrated embodiment, multiple target processes run on CPUs in respective memory architecture nodes of the memory architecture. The computer device may also determine the CPUs that need to be reserved in the memory architecture based on the CPU distribution of the logical cores corresponding to the memory architecture nodes in the memory architecture. The reserved CPUs are reserved for running other processes.
[0051] Specifically, since hyperthreading technology allows multiple threads to run on each logical core (logical core), the CPU distribution of the logical core can be determined based on whether hyperthreading is enabled. When determining the CPUs that need to be reserved in the memory architecture based on the CPU distribution of the logical cores corresponding to the memory architecture nodes in the memory architecture, if hyperthreading is enabled, then for each memory architecture node, the CPU in any one logical core corresponding to the memory architecture node is determined as the CPU that needs to be reserved; if hyperthreading is not enabled, then for each memory architecture node, the CPU in at least one logical core corresponding to the memory architecture node is determined as the CPU that needs to be reserved.
[0052] The memory architecture can be an architecture involving memory, CPU, and bus management, such as a NUMA architecture. A memory architecture node can be a NUMA node deployed in a NUMA architecture. A NUMA node can be configured with multiple logical cores, and each logical core can be configured with one or more threads depending on whether hyperthreading is enabled.
[0053] For example, Figure 3 As shown, Figure 3 The figure shows the CPU distribution of a NUMA node when hyperthreading is enabled. If a server has two NUMA nodes, each with four logical cores and two threads (hyperthreading is enabled on the server), the total number of CPUs (counted by hyperthreading) is 2*4*2=16.
[0054] To balance the packet processing load among DPDK slave processes, each NUMA node is assigned an equal number of reserved CPU cores. In this case, the CPU on the first logical core (other logical cores can also be selected) on each NUMA node is reserved for use by other processes. Specifically, CPU0, CPU8, CPU4, and CPU12 are reserved. Therefore, the number of reserved CPU cores = number of NUMA nodes * 2.
[0055] Figure 4 The figure shows the CPU distribution of NUMA nodes when hyperthreading is disabled. Without hyperthreading, each logical core has only one CPU. The CPUs on the first logical core (other logical cores are also available) of each NUMA node are reserved for use by other processes. Specifically, CPU0 and CPU4 are reserved. (If the number of NUMA nodes is 1, special treatment is performed, reserving CPUs on two logical cores.)
[0056] Then, the number of reserved CPU cores = the number of NUMA nodes * n (when the number of NUMA nodes is 1, n = 2; otherwise n = 1).
[0057] Therefore, by designing a CPU reservation strategy for other processes and reserving a corresponding number of CPUs based on the strategy, it is possible to ensure that other processes have a certain amount of CPU resources, ensure the normal operation of other processes, and ensure the normal processing of data and the normal operation of the system.
[0058] Since the target process is bound to the target CPU and will not give up the CPU during operation, even if the system does not have so much packet load to process, the utilization of these CPUs is almost 100%, which cannot reflect the actual load situation.
[0059] For example, because DPDK slave processes are bound to CPUs and do not relinquish CPUs during operation, the time slices spent by these CPUs in user mode account for almost all of the CPU's working time. Therefore, even if the system does not have a high packet load to process, the CPU utilization of these CPUs will be close to 100% when viewed through tools such as top and mpstat. A time slice is a time period allocated to each process, meaning the time the process is allowed to run, or the time the CPU allocates to the process.
[0060] Therefore, in order to truly reflect the CPU load, based on Figure 1In the illustrated embodiment, in an optional implementation manner, multiple target processes are run on multiple CPUs. After executing a custom sleep action on the target process, the statistical information of multiple CPUs can be read, and the statistical information includes the CPU parameters and parameter values of each CPU running each target process, as well as the statistical values of each CPU parameter of the multiple CPUs. Among them, the CPU parameters include user-mode running time parameters and idle state time parameters. The total packet processing time and total idle time of each target process can also be obtained, and the statistical value of the user-mode running time parameter in the above statistical information can be modified according to the total packet processing time of each target process, and the statistical value of the idle state time parameter in the above statistical information can be modified according to the total idle time of each target process.
[0061] Among them, the statistical value of the user-state running time parameter is modified according to the total packet processing time of each target process, and the statistical value of the idle state time parameter is modified according to the total idle time of each target process. An optional approach may be that, for each CPU running the target process, the parameter value of the user-state running time parameter of the CPU is replaced with the total packet processing time of the target process run by the CPU, and the parameter value of the idle state time parameter of the CPU is replaced with the total idle time of the target process run by the CPU.
[0062] Then, the total packet processing time of multiple CPUs can be accumulated to obtain the true statistical values of the multiple CPUs in the user state running time parameters. In addition, the total idle time of multiple CPUs can be accumulated to obtain the true statistical values of the multiple CPUs in the idle state time parameters.
[0063] For example, you can set up a custom process called custom_fs. When the custom_fs process initializes, it opens the / proc / stat file once and saves the file descriptor fp. Later, it uses fp to read statistics from the system's / proc / stat file. The proc / stat file is a file in the Linux system's dynamic pseudo-file system proc. It provides system-wide statistics, primarily including CPU usage and other important runtime system information.
[0064] Afterwards, the computer device can execute a file mount command, such as the command mount -o bind / iproc / apps / custom_fs / stat / proc / stat, to overwrite the system's / proc / stat file. All subsequent processes that read the / proc / stat file actually read the file / iproc / apps / custom_fs / stat. The mount -o bind / iproc / apps / custom_fs / stat / proc / stat command is a Linux command used to bind a directory or file in the file system to another directory. This is very useful when developing embedded systems or debugging because it allows you to modify system behavior without recompiling or restarting the system.
[0065] In this particular example, the file / iproc / apps / custom_fs / stat is bound to the / proc / stat file, which means that when the process accesses the / proc / stat file, it actually accesses the file / iproc / apps / custom_fs / stat. The file / iproc / apps / custom_fs / stat is a user-mode file system implemented by the custom_fs process using the libfuse library. You can customize the open, read, lseek, release, and other operations on this stat file.
[0066] Among them, the libfuse library is the user space library of the user space file system FUSE (Filesystem in Userspace). Libfuse is an open source library that allows custom file systems to be implemented in user space and mounted into the Linux kernel. FUSE is a software interface for Unix-like computer operating systems that enables unprivileged users to create their own file systems without editing kernel code. Through the FUSE interface, file systems that meet specific needs can be easily created without in-depth understanding of the underlying kernel mechanisms. Therefore, using FUSE technology, it is possible to map to the user space file system to overwrite and mount the / proc / stat file, making it easier to calculate and display the actual load status of the DPDK slave process processing data packets.
[0067] Furthermore, the custom_fs program can control other programs to read the CPU statistics returned by the / proc / stat file, an exemplary content of which is as follows: Figure 5 shown. Figure 5The specific values of multiple CPU parameters for each CPU are displayed, including USER, NICE, SYSTEM, IDLE, and other CPU parameters. The statistics column shows the statistical values of various CPU parameters for multiple CPUs running various DPDK slave processes.
[0068] The computer device may further obtain the total packet processing time of each DPDK slave process, recorded as total_user_time, and the total idle time, recorded as total_idle_time.
[0069] Furthermore, for each DPDK slave process, replace the USER row value in the statistics of the CPU to which the DPDK slave process is bound with the total_user_time of the DPDK slave process, and replace the IDLE row value with the total_idle_time of the DPDK slave process. For example, for CPU0, replace the USER row value "3126670" with the total_user_time of the DPDK slave process running on CPU0, and replace the IDLE row value "59899721" with the total_idle_time of the DPDK slave process running on CPU0.
[0070] After the replacement is complete, you can accumulate multiple values in the USER row to obtain the USER parameter statistics, and accumulate multiple values in the IDLE row to obtain the IDLE parameter statistics. At this time, the accumulated USER parameter statistics and IDLE parameter statistics represent the actual CPU load.
[0071] Furthermore, the accumulated statistical values of USER parameters and IDLE parameters can be displayed to show software engineers the actual CPU load, making it easier for them to optimize application operation or adjust CPU resource allocation strategies based on the actual CPU load.
[0072] To obtain the total packet processing time and total idle time for each target process, one optional approach is to collect the packet processing time and idle time of each target process at each sampling interval during the target process's operation. This allows obtaining multiple packet processing times and idle times for multiple sampling intervals. The packet processing times for multiple sampling intervals can be accumulated to obtain the total packet processing time for the target process. Furthermore, the idle times for multiple sampling intervals can be accumulated to obtain the total idle time for the target process.
[0073] Continuing with the above example, in the DPDK slave process, it is necessary to calculate the ratio of actual packet processing load to idle time. A sampling interval can be set. During the sampling interval, the actual time spent processing packets is recorded as user_time, and the idle time is recorded as idle_time. After each sampling interval, user_time is added to total_user_time, and idle_time is added to total_idle_time. All DPDK slave processes and the custom_fs process can synchronize total_user_time and total_idle_time via shared memory. The custom_fs program can then retrieve the total_user_time and total_idle_time values for all DPDK slave processes from shared memory.
[0074] Therefore, by counting the total time and total idle time of each target process in processing data packets, we can provide accurate and real data basis for truly reflecting the CPU load situation, which is conducive to obtaining accurate and real CPU resource utilization.
[0075] The process control method in the embodiment of the present application is described above. The computer device in the embodiment of the present application is described below. Figure 6 In one embodiment of the present application, a computer device includes:
[0076] A setting unit, configured to, in response to a setting operation on the CPU affinity of a target process, bind the target process to a target CPU indicated by the setting operation;
[0077] The target process is configured to receive data packets in sequence when running on the target CPU, and process the data packets of the current batch upon receiving the data packets of the current batch;
[0078] The control unit is configured to execute a custom sleep action on the target process each time it is determined that the target process completes processing of the current batch of data packets, so that the target process continues to occupy the target CPU to which the target process is bound.
[0079] In a preferred implementation of this embodiment, the control unit is specifically configured to:
[0080] A PAUSE instruction is executed on the target process, so that the target process continues to run and performs spin waiting with lower resource consumption, so as to continue to occupy the target CPU.
[0081] In a preferred implementation of this embodiment, the plurality of target processes are run on CPUs in each memory architecture node of the memory architecture;
[0082] The control unit is also used to:
[0083] According to the CPU distribution of the logical cores corresponding to the memory architecture nodes in the memory architecture, the CPUs that need to be reserved in the memory architecture are determined, and the reserved CPUs are used to be reserved for running other processes.
[0084] In a preferred implementation of this embodiment, the control unit is specifically configured to:
[0085] If hyperthreading is enabled, for each of the memory architecture nodes, a CPU in any logical core corresponding to the memory architecture node is determined as a CPU that needs to be reserved;
[0086] If hyperthreading is not enabled, for each of the memory architecture nodes, a CPU in at least one logical core corresponding to the memory architecture node is determined as a CPU that needs to be reserved.
[0087] In a preferred implementation of this embodiment, the plurality of target processes are run on multiple CPUs;
[0088] Computer equipment also includes:
[0089] Get unit for:
[0090] Reading statistical information of the multiple CPUs, the statistical information including CPU parameters and parameter values of each CPU running the target process, and statistical values of each CPU parameter of the multiple CPUs; the CPU parameters including user state running time parameters and idle state time parameters;
[0091] Obtaining the total packet processing time and total idle time of each target process;
[0092] A modification unit is used to modify the statistical value of the user-mode running time parameter according to the total data packet processing time of each target process, and to modify the statistical value of the idle state time parameter according to the total idle time of each target process.
[0093] In a preferred implementation of this embodiment, the modification unit is specifically configured to:
[0094] For each CPU running the target process, replace the parameter value of the user-mode runtime parameter of the CPU with the total packet processing time of the target process running on the CPU, and replace the parameter value of the idle state time parameter of the CPU with the total idle time of the target process running on the CPU;
[0095] Accumulating the total time taken by the multiple CPUs to process the data packets to obtain a true statistical value of the user-mode runtime parameter;
[0096] The total idle time of the multiple CPUs is accumulated to obtain a true statistical value of the idle state time parameter.
[0097] In a preferred implementation of this embodiment, the acquiring unit is specifically configured to:
[0098] For each target process, collecting the time taken by the target process to process data packets and the idle time during each sampling interval;
[0099] Accumulating the time taken to process the data packets in multiple sampling intervals to obtain the total time taken to process the data packets of the target process;
[0100] The idle time of multiple sampling intervals is accumulated to obtain the total idle time of the target process.
[0101] In this embodiment, the operations performed by each unit in the computer device are the same as those described above. Figure 1 The illustrated embodiment and its various optional implementations are similar to those described above and will not be repeated here.
[0102] The computer device in the embodiment of the present application is described below. Figure 7 In one embodiment of the present application, a computer device includes:
[0103] The computer device 700 may include one or more central processing units (CPUs) 701 and a memory 705 . The memory 705 stores one or more application programs or data.
[0104] Memory 705 may be volatile or persistent storage. The program stored in memory 705 may include one or more modules, each of which may include a series of instruction operations on the computer device. Furthermore, CPU 701 may be configured to communicate with memory 705 and execute the series of instruction operations in memory 705 on computer device 700.
[0105] The computer device 700 may also include one or more power supplies 702, one or more wired or wireless network interfaces 703, one or more input and output interfaces 704, and / or one or more operating systems, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.
[0106] The CPU 701 can execute the aforementioned Figure 1 The operations performed by the computer device in the illustrated embodiment and its various optional implementations are not described in detail here.
[0107] The present application also provides a computer storage medium, wherein one embodiment includes: the computer storage medium stores instructions, and when the instructions are executed on a computer, the computer executes the aforementioned Figure 1 Operations performed by a computer device in the illustrated embodiment and its various alternative implementations.
[0108] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.
[0109] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.
[0110] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.
[0111] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.
[0112] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, read-only memory), random access memory (RAM, random access memory), disk or optical disk, and other media that can store program code.
Claims
1. A process control method, characterized in that: The method comprises: In response to a setting operation on the CPU affinity of a target process, binding the target process to a target CPU indicated by the setting operation; The target process is configured to receive data packets in sequence when running on the target CPU, and process the data packets of the current batch upon receiving the data packets of the current batch; Each time it is determined that the target process completes processing of the current batch of data packets, a custom sleep action is performed on the target process, so that the target process continues to occupy the target CPU to which the target process is bound.
2. The method according to claim 1, characterized in that The performing of a customized sleep action on the target process includes: A PAUSE instruction is executed on the target process, so that the target process continues to run and performs spin waiting with lower resource consumption, so as to continue to occupy the target CPU.
3. The method according to claim 1, characterized in that The plurality of target processes are run on CPUs in respective memory architecture nodes of the memory architecture; The method further comprises: According to the CPU distribution of the logical cores corresponding to the memory architecture nodes in the memory architecture, the CPUs that need to be reserved in the memory architecture are determined, and the reserved CPUs are used to be reserved for running other processes.
4. The method according to claim 3, characterized in that The determining, based on the CPU distribution of the logical cores corresponding to the memory architecture nodes in the memory architecture, the CPUs that need to be reserved in the memory architecture includes: If hyperthreading is enabled, for each of the memory architecture nodes, a CPU in any logical core corresponding to the memory architecture node is determined as a CPU that needs to be reserved; If hyperthreading is not enabled, for each of the memory architecture nodes, a CPU in at least one logical core corresponding to the memory architecture node is determined as a CPU that needs to be reserved.
5. The method according to claim 1, wherein The plurality of target processes are run on a plurality of CPUs; After executing the customized sleep action on the target process, the method further includes: Reading statistical information of the multiple CPUs, the statistical information including CPU parameters and parameter values of each CPU running the target process, and statistical values of each CPU parameter of the multiple CPUs; the CPU parameters including user state running time parameters and idle state time parameters; Obtaining the total packet processing time and total idle time of each target process; The statistical value of the user-mode runtime parameter is modified according to the total packet processing time of each target process, and the statistical value of the idle state time parameter is modified according to the total idle time of each target process.
6. The method according to claim 5, characterized in that The modifying of the statistical value of the user-mode runtime parameter according to the total packet processing time of each target process, and the modifying of the statistical value of the idle state time parameter according to the total idle time of each target process, comprises: For each CPU running the target process, replace the parameter value of the user-mode runtime parameter of the CPU with the total packet processing time of the target process running on the CPU, and replace the parameter value of the idle state time parameter of the CPU with the total idle time of the target process running on the CPU; Accumulating the total time taken by the multiple CPUs to process the data packets to obtain a true statistical value of the user-mode runtime parameter; The total idle time of the multiple CPUs is accumulated to obtain a true statistical value of the idle state time parameter.
7. The method according to claim 5, characterized in that The obtaining of the total data packet processing time and the total idle time of each target process includes: For each target process, collecting the time taken by the target process to process data packets and the idle time during each sampling interval; Accumulating the time taken to process the data packets in multiple sampling intervals to obtain the total time taken to process the data packets of the target process; The idle time of multiple sampling intervals is accumulated to obtain the total idle time of the target process.
8. A computer device, characterized in that: The computer device comprises: A setting unit, configured to, in response to a setting operation on the CPU affinity of a target process, bind the target process to a target CPU indicated by the setting operation; The target process is configured to receive data packets in sequence when running on the target CPU, and process the data packets of the current batch upon receiving the data packets of the current batch; The control unit is configured to execute a custom sleep action on the target process each time it is determined that the target process completes processing of the current batch of data packets, so that the target process continues to occupy the target CPU to which the target process is bound.
9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 7 is implemented.
10. A computer storage medium, characterized in that The computer storage medium stores instructions, which, when executed on a computer, enable the computer to perform the method according to any one of claims 1 to 7.