Method, device, and medium for improving efficiency of computationally intensive task execution

Abstract

The application discloses a method, device and medium for improving the execution efficiency of a computing-intensive task, relates to the technical field of intensive task processing, and comprises the following steps: in response to an interrupt request received by a multi-core CPU system, determining whether a source CPU for processing the interrupt request is bound to a task; if it is determined that the source CPU is bound to the task, determining a target topology level adapted to the interrupt request according to an interrupt source device of the interrupt request, then determining a target topology node with the lowest interrupt load from the target topology level of the multi-core CPU system, and setting an interrupt affinity mask of the interrupt request to a mask of the target topology node; if it is determined that the source CPU is not bound to the task, then determining that the interrupt request is processed by the source CPU. The application realizes the purpose of considering the influence of interrupt processing on the execution efficiency of a computing-intensive task from the perspective of an external factor, does not need to deploy expensive hardware, does not need to modify the task at the code level, and improves the execution efficiency of the computing-intensive task.

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to the technical field of intensive task processing, and in particular, to a method, device and medium for improving the execution efficiency of a computationally intensive task. BACKGROUND

[0002] For computationally intensive tasks, common strategies for improving the execution efficiency of computationally intensive tasks can be optimizing algorithms, such as optimizing data structures and selecting algorithms with lower time complexity, decomposing computationally intensive tasks into multiple subtasks, using multi-threading technology for parallel computing, binding multi-threads to the same Non-Uniform Memory Access (NUMA) node to avoid the overhead of cross-node memory access, or binding multi-threads to different processors to reduce context switching overhead and improve cache hit rate, etc.; or, it can also be effective use of hardware features, such as using special hardware acceleration co-computing, and using a distributed computing framework to distribute intensive tasks to different computing nodes to implement large-scale data computing.

[0003] However, both strategies of optimizing algorithms and effective use of hardware features only start from the intensive task itself, and the optimization algorithm strategy cannot infinitely improve the execution efficiency of the task due to algorithm bottleneck problems, and the effective use of hardware features strategy usually requires the deployment of expensive hardware, thus resulting in that the existing methods for improving the execution efficiency of intensive tasks still have great limitations. SUMMARY

[0004] In view of the above-mentioned defects or deficiencies in the prior art, it is desirable to provide a method, device and medium for improving the execution efficiency of a computationally intensive task, which realizes the purpose of considering the influence of interrupt processing on the execution efficiency of intensive tasks from the perspective of external factors by migrating the interrupt request on the CPU of the bound task to other CPUs with the lowest interrupt load, without the need to deploy expensive hardware or modify the intensive task at the code level to improve the execution efficiency of the intensive task, thereby reducing the influence of task execution on the CPU of the bound task, ensuring that the task execution on the source CPU is not preempted by interrupt processing, and as much as possible not affecting the interrupt load on the target topology node, while ensuring the efficiency of subsequent interrupt processing through the setting of interrupt affinity, thereby greatly improving the execution efficiency of computationally intensive tasks.

[0005] In a first aspect, the present application provides a method for improving the execution efficiency of a computationally intensive task. The method comprises:

[0006] in response to an interrupt request received by a multi-core CPU system, determining whether a source CPU that processes the interrupt request by default is bound to a task;

[0007] If it is determined that the source CPU is bound to a task, a target topology level adapted to the interrupt request is determined according to an interrupt source device of the interrupt request, a target topology node with the lowest interrupt load is determined from the target topology level of the multi-core CPU system, and an interrupt affinity mask of the interrupt request is set to a mask of the target topology node.

[0008] If it is determined that the source CPU is not bound to a task, it is determined that the interrupt request is processed by the source CPU.

[0009] With reference to the first aspect, in a possible implementation manner, the determining whether the source CPU bound to a task includes:

[0010] obtaining a first CPU mask and a second CPU mask, the first CPU mask being used to represent whether all CPUs in the multi-core CPU system are bound to a task, and the second CPU mask being used to represent a CPU that processes the interrupt request by default;

[0011] determining whether the source CPU is bound to a task based on a result of AND operation of the first CPU mask and the second CPU mask.

[0012] With reference to the first aspect, in a possible implementation manner, the determining the target topology node with the lowest interrupt load from the target topology level of the multi-core CPU system includes:

[0013] in a case where the interrupt source device is a preset other type device and the target topology level is a NUMA level CPU,

[0014] if at least one first NUMA node without a CPU bound to a task is determined from the multi-core CPU system, a target first NUMA node with the lowest sum of interrupt loads is determined from each of the first NUMA nodes, and the target first NUMA node is determined as the target topology node; each of the first NUMA nodes is different from a source NUMA node corresponding to the source CPU;

[0015] if the multi-core CPU system does not include the first NUMA node and only includes one source NUMA node, or the multi-core CPU system includes a CPU bound to a task in each of the NUMA nodes except the source NUMA node, the target topology node is determined according to other CPUs in the source NUMA node except the CPU bound to a task.

[0016] With reference to the first aspect, in a possible implementation manner, the determining the target topology node with the lowest interrupt load from the target topology level of the multi-core CPU system further includes:

[0017] In a case where the interrupt source device is a storage controller and the target topology level is a cache level of a CPU,

[0018] If it is determined that there is no at least one first cache sub-node of a bound task CPU in a source NUMA node of the multi-core CPU system, a target first cache sub-node with the lowest sum of interrupt loads is determined from each of the first cache sub-nodes, and the target first cache sub-node is determined as the target topology node; the source NUMA node is a NUMA node corresponding to a source cache sub-node where the source CPU is located, and each of the first cache sub-nodes is different from the source cache sub-node;

[0019] If the source NUMA node only includes one source cache sub-node, or there is a CPU of a bound task in each cache sub-node other than the source cache sub-node under the source NUMA node, a target second cache sub-node with the lowest sum of interrupt loads and without a bound task CPU is determined from other NUMA nodes of the multi-core CPU system except the source NUMA node, and the target second cache sub-node is determined as the target topology node;

[0020] If the multi-core CPU system only includes one source NUMA node or all cache sub-nodes of other NUMA nodes except the source NUMA node have CPUs of bound tasks, the target topology node is determined according to other CPUs of the source cache sub-node except the CPUs of bound tasks.

[0021] In combination with the first aspect, in a possible implementation manner, the determining, from the target topology level of the multi-core CPU system, the target topology node with the lowest interrupt load, further includes:

[0022] In a case where the interrupt source device is a network card device and the target topology level is a single CPU,

[0023] If at least one other CPU sharing the same source cache sub-node as the source CPU is determined from the multi-core CPU system, a CPU without a bound task and with the lowest interrupt load is determined from each of the other CPUs as the target topology node;

[0024] If the source CPU exclusively uses the source cache sub-node or all CPUs sharing the source cache sub-node are bound to tasks, a CPU with the lowest interrupt load and not bound to tasks is determined from a source NUMA node corresponding to the source cache sub-node as the target topology node;

[0025] If the CPU with the lowest interrupt load and not bound to tasks is not determined from the source NUMA node, a CPU with the lowest interrupt load and not bound to tasks is determined from a NUMA node other than the source NUMA node in the multi-core CPU system as the target topology node.

[0026] With reference to the first aspect, in a possible implementation manner, the method further includes:

[0027] The interrupt load generated by the interrupt request is subtracted from the source topology node, and the subtraction result is added to the target topology node, representing the migration of the interrupt load.

[0028] With reference to the first aspect, in a possible implementation manner, the determination process of the interrupt load generated by the interrupt request includes:

[0029] The interrupt load generated by the interrupt request is calculated according to the number of interrupt requests initiated by the first CPU according to the interrupt request, the total number of interrupt requests received on the first CPU, and the interrupt load on the first CPU; the first CPU is any CPU in the multi-core CPU system.

[0030] With reference to the first aspect, in a possible implementation manner, the determination process of the interrupt load on the first CPU includes:

[0031] The interrupt load on the first CPU is calculated according to the target time for the first CPU to process the interrupt request in a preset time period and the preset time period; the target time includes the difference between the total time for the first CPU to process a hard interrupt and a soft interrupt twice in the preset time period.

[0032] Secondly, the present application provides a computer device. The computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the method according to the first aspect when executing the computer program.

[0033] Thirdly, the present application provides a computer readable storage medium. The computer readable storage medium stores a computer program, and the computer program is executed by a processor to implement the method according to the first aspect.

[0034] The embodiment of the present application provides a method, device and medium for improving the execution efficiency of a computing-intensive task, wherein in the method for improving the execution efficiency of the computing-intensive task, when responding to an interrupt request received by a multi-core CPU system, firstly, it is judged whether a source CPU for processing the interrupt request is bound to a task, and then, in the case that the source CPU is bound to the task, a target topology level adapted to the interrupt request is determined according to an interrupt source device of the interrupt request, a target topology node with the lowest interrupt load is determined from the target topology level of the multi-core CPU system, and an interrupt affinity mask of the interrupt request is set to a mask of the target topology node; or, in the case that the source CPU is not bound to the task, the interrupt request is processed by the source CPU. In this way, by migrating the interrupt request on the CPU bound to the task to another target topology node with the lowest interrupt load, the influence of the interrupt processing on the execution efficiency of the intensive task is considered from the perspective of the external factor, the execution efficiency of the intensive task is improved without deploying expensive hardware or modifying the task at the code level, the influence of the task execution on the CPU bound to the task is reduced, the task execution on the source CPU is ensured not to be preempted by the interrupt processing, the interrupt load on the target topology node is affected as little as possible, and the efficiency of the interrupt processing is ensured by setting the interrupt affinity, so that the execution efficiency of the intensive task is greatly improved. BRIEF DESCRIPTION OF DRAWINGS

[0035] Other features, objects, and advantages of the present application will become more apparent from the following detailed description of non-limiting embodiments thereof as read in conjunction with the accompanying drawings:

[0036] Figure 1 One of the method flowcharts for improving the execution efficiency of a computing-intensive task in an embodiment;

[0037] Figure 2 The second method flowchart for improving the execution efficiency of a computing-intensive task in an embodiment;

[0038] Figure 3 The third method flowchart for improving the execution efficiency of a computing-intensive task in an embodiment;

[0039] Figure 4 The CPU topology structure diagram in an embodiment;

[0040] Figure 5 The fourth method flowchart for improving the execution efficiency of a computing-intensive task in an embodiment;

[0041] Figure 6 The fifth method flowchart for improving the execution efficiency of a computing-intensive task in an embodiment;

[0042] Figure 7 This is a sixth schematic diagram of a method for improving the execution efficiency of computationally intensive tasks in one embodiment;

[0043] Figure 8 This is a structural block diagram of a device for improving the execution efficiency of computationally intensive tasks in one embodiment;

[0044] Figure 9 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0045] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0046] It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of this invention can be combined with each other. The invention will now be described in detail with reference to the accompanying drawings and embodiments. Furthermore, the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The terms "first" and "second," etc., in the specification and claims of the embodiments of this invention are used to distinguish different objects, not to describe a specific order of objects.

[0047] For computationally intensive tasks, common strategies to improve their execution efficiency include optimizing algorithms, such as optimizing data structures and choosing algorithms with lower time complexity; decomposing computationally intensive tasks into multiple subtasks; using multithreading for parallel computation; binding multiple threads to the same NUMA node to avoid the overhead of cross-node memory access; or binding multiple threads to different processors to reduce context switching overhead and improve cache hit rate. Alternatively, it can involve effectively utilizing hardware features, such as using dedicated hardware to accelerate collaborative computation between Field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), or multiple hardware resources like Central Processing Units (CPUs) and Graphics Processing Units (GPUs); and using distributed computing frameworks (Hadoop, a distributed system infrastructure, Spark, a distributed computing engine) to distribute computationally intensive tasks to different computing nodes to achieve large-scale data processing.

[0048] However, both strategies of optimization algorithm and effective use of hardware characteristics only start from the dense task itself, and the optimization algorithm strategy cannot infinitely improve the task execution efficiency due to the algorithm bottleneck problem, and the effective use of hardware characteristics strategy also needs to deploy expensive hardware due to the need for code-level support of certain hardware characteristics.

[0049] That is, in combination with the existing methods for improving the execution efficiency of dense tasks, it can be understood that the existing technologies all start from the dense task itself, and the costs are relatively high, such as improving the execution efficiency of the dense task itself by modifying the code to improve the algorithm or deploying expensive hardware. The existing technologies do not focus on the influence of factors other than the dense task itself on the computing-intensive task. The computing-intensive task usually has a high demand for CPU resources. If there are factors that preempt CPU resources, the execution efficiency of the computing-intensive task will be affected, such as an interrupt context with a higher priority than the process context, which can interrupt the normal execution of the task at any time and compete for CPU resources. Therefore, the existing methods for improving the execution efficiency of dense tasks still have great limitations.

[0050] In order to solve the above technical problems, the present application provides a method, device and medium for improving the execution efficiency of computing-intensive tasks. By migrating the interrupt request on the bound task CPU to other target topology nodes with the lowest interrupt load, the influence of the interrupt processing on the execution efficiency of the dense task is considered from the perspective of external factors, without the need to deploy expensive hardware or modify the task at the code level to improve the execution efficiency of the dense task. The execution of the task on the source CPU is not preempted by the interrupt processing, and the interrupt load on the target topology node is not affected as much as possible. At the same time, the efficiency of the interrupt processing is guaranteed by setting the interrupt affinity, thereby greatly improving the execution efficiency of the dense task.

[0051] The following will be described in combination with Figures 1 to 9The application discloses a method, device and medium for improving execution efficiency of a computing-intensive task. The method for improving execution efficiency of the computing-intensive task can be applied to a multi-core CPU system. The multi-core CPU system comprises a CPU topology structure in which a plurality of CPUs are connected in a topology form and an interrupt controller. The interrupt controller has at least an interrupt monitoring function, a data processing function, a data storage function and an interrupt migration function. The execution subject of the method for improving execution efficiency of the computing-intensive task can be the interrupt controller. Alternatively, the method for improving execution efficiency of the computing-intensive task can also be applied to a device for improving execution efficiency of the computing-intensive task in the interrupt controller. The device for improving execution efficiency of the computing-intensive task can be realized by software, hardware or a combination of both. The method for improving execution efficiency of the computing-intensive task is described below by taking the interrupt controller as the execution subject.

[0052] In order to facilitate understanding of the method for improving execution efficiency of the computing-intensive task provided by the application, the method for improving execution efficiency of the computing-intensive task provided by the application is described in detail below by taking several example embodiments. It can be understood that the following several example embodiments can be combined with each other, and the same or similar concepts or processes can not be described again in some embodiments.

[0053] In one embodiment, a method for improving execution efficiency of a computing-intensive task is provided. As shown in the figure, the method for improving execution efficiency of the computing-intensive task comprises the following steps 101 to 103. Figure 1

[0054] Step 101, in response to an interrupt request received by a multi-core CPU system, determining whether a source CPU which processes the interrupt request by default is bound to a task.

[0055] Step 102, if it is determined that the source CPU is bound to the task, determining a target topology level which is adapted to the interrupt request according to an interrupt source device of the interrupt request, then determining a target topology node with the lowest interrupt load from target topology levels of the multi-core CPU system, and setting an interrupt affinity mask of the interrupt request to a mask of the target topology node.

[0056] Step 103, if it is determined that the source CPU is not bound to the task, determining that the interrupt request is processed by the source CPU.

[0057] The multi-core CPU system can be a Linux operating system.

[0058] ​For a multi-core CPU system, it can receive multiple interrupt requests of different types, or multiple interrupt requests of the same type, and each of the received interrupt requests is an external event, and all the received interrupt requests are recorded in a / proc / irq / directory, which is a virtual directory for managing interrupt requests by a Linux kernel through a virtual file system (procfs), and each subdirectory is named by an interrupt number.

[0059] When the types of the interrupt requests are different, the source CPU for default processing of the corresponding interrupt request changes, and each source CPU belongs to a CPU topology structure included in the multi-core CPU system.

[0060] Each interrupt request can be an interrupt context that exists in a pre-emptive CPU resource and has a higher priority than a process context, and can interrupt the normal execution of an intensive task at any time to compete for the CPU resource. For example, each interrupt request can be automatically generated when a character key on a keyboard is struck, or can be automatically generated when a mouse is clicked; the specific type is not limited here.

[0061] For each source CPU, the bound task can be an intensive task, which refers to a task that mainly relies on a specific resource (CPU or Input / Output (I / O)) during execution; the intensive task mentioned in the embodiments of the present application can be a CPU-intensive task.

[0062] It can be understood that, considering that the interrupt affinity of different types of interrupt requests is suitable for different levels of topology nodes, therefore, as a target of interrupt migration, the target topology node can be a CPU-level topology node, a CACHE-level topology node, or a NUMA-level topology node.

[0063] Specifically, for each interrupt request from the outside that is monitored by the interrupt controller, it can first determine whether the source CPU for default processing of the interrupt request is bound to an intensive task, and if it is determined that the source CPU for default processing of the interrupt request is bound to a task, it determines a target topology node with the lowest interrupt load from the target topology level of the multi-core CPU system, and sets the interrupt affinity mask of the interrupt request to the mask of the target topology node, so as to ensure that the CPU resources for execution of the CPU-intensive task are not pre-empted by interrupt processing, and to improve the execution efficiency of the intensive task; at the same time, in order not to affect the target topology node for processing or migration of these interrupt requests, the target topology node with the lowest interrupt load can also be reasonably determined for interrupt migration according to the interrupt load on these CPUs.

[0064] If it is determined that the source CPU that handles the interrupt request by default is not bound with the intensive task, there is no case that the CPU resource of task execution is preempted by interrupt processing, that is, the interrupt request does not need to be migrated and can be directly processed on the source CPU.

[0065] It should be noted that for all interrupt requests recorded in the / proc / irq / directory, steps 101 to 103 need to be performed for each interrupt request; until all interrupt requests are traversed, if all the traversal is completed, the process is ended; if the traversal is not completed, the next interrupt request is selected and the process continues to step 101.

[0066] The method for improving the execution efficiency of intensive tasks provided by the embodiment of the application, when responding to the interrupt request received by the multi-core CPU system, first determines whether the source CPU that handles the interrupt request by default is bound with a task, and further determines the target topology level adapted to the interrupt request according to the interrupt source device of the interrupt request in the case that the source CPU is bound with a task, then determines the target topology node with the lowest interrupt load from the target topology level of the multi-core CPU system, and sets the interrupt affinity mask of the interrupt request to the mask of the target topology node; or, in the case that the source CPU is not bound with a task, determines that the interrupt request is processed by the source CPU. In this way, by migrating the interrupt request on the CPU bound with a task to the target topology node with the lowest interrupt load, the influence of the interrupt processing on the execution efficiency of intensive tasks is considered from the perspective of external factors, without deploying expensive hardware or modifying the intensive task at the code level to improve the execution efficiency of the intensive task, the influence of the task execution on the CPU bound with a task is reduced, the task execution on the source CPU is ensured not to be preempted by the interrupt processing, the interrupt load on the target topology node is as little affected as possible, and the efficiency of the interrupt processing is ensured by setting the interrupt affinity, thereby greatly improving the execution efficiency of the intensive task.

[0067] Based on the above Figure 1 In an example embodiment, in step 101, whether the source CPU that handles the interrupt request by default is bound with a task is determined, and the specific process in this embodiment can be implemented by steps 201 and 202 shown in the following. Figure 2

[0068] Step 201, a first CPU mask and a second CPU mask are obtained, the first CPU mask is used to represent whether all CPUs in the multi-core CPU system are bound with a task, and the second CPU mask is used to represent the CPU that handles the interrupt request by default.

[0069] Step 202, based on the AND operation result of the first CPU mask and the second CPU mask, whether the source CPU is bound with a task is determined.​

[0070] It should be noted that the obtained first CPU mask can be a CPU mask of all CPUs to which the tasks are bound in the Linux operating system, and can be marked as task_bound.

[0071] For the obtaining process of task_bound, first, all tasks are traversed in the / proc / * / task / directory to obtain the Process ID (PID) of each task; here, / proc / * / task / is a virtual directory used by the Linux kernel to manage tasks through a virtual file system (procfs), and each subdirectory in the virtual directory is named after the PID of the corresponding task; in this way, the PID of each task can be obtained by traversing the virtual directory.

[0072] Further, for each task in all tasks, the CPU affinity mask of each task is obtained through a system call; here, the system call can be implemented through a CPU affinity query interface (or function) provided by the Linux operating system to the user layer, for example, the CPU affinity mask of each task can be obtained through the sched_getaffinity() interface (or function).

[0073] For the CPU affinity mask of each task, if the CPU affinity mask of a task is only a single CPU, it is considered that the task is bound to the CPU, and the CPU mask of the CPU is recorded; otherwise, if the CPU affinity mask of a task is multiple CPUs, it is considered that the task is not bound to any CPU, and the CPU mask does not need to be recorded; after all the CPU affinity masks of all tasks are traversed in the above manner, all the recorded CPU masks bound to the tasks are obtained, and all the recorded CPU masks are marked as task_bound, that is, the first CPU mask is obtained.

[0074] For the obtaining process of the second CPU mask, the interrupt request in all interrupt requests under the / proc / irq / directory can be taken as the interrupt request in the / proc / irq / directory <irq>To illustrate, also, i.e.

[0075] Read / proc / irq / <irq>The CPU mask in the / effective_affinity file is read, and the read CPU mask is determined as the second CPU mask, and is marked as effective_mask. Here, / proc / irq / <irq>The / effective_affinity file is a virtual directory in the management of interrupt requests for recording the interrupt number as <irq>a virtual file of the actual CPU affinity mask; in this way, by reading this virtual file, it is possible to obtain the CPU affinity mask to be used in the default handling of the interrupt <irq>The CPU mask of the source CPU, i.e. the second CPU mask, is obtained to determine the CPU mask of the source CPU which handles the corresponding interrupt request by default.

[0076] At this time, the first CPU mask and the second CPU mask are obtained, and the AND operation result of the OR operation result can be used to determine whether the source CPU is bound to the task.

[0077] For example, the AND operation result is obtained by formula (1).

[0078] (1)

[0079] In formula (1), represents the AND operation, represents the AND operation result; when = 0, it indicates that the interrupt <irq>the processing of the interrupt request is not completed task_bound on any CPU covered, i.e. the source CPU does not bind the task, then no adjustment is needed and the next interrupt request is processed; otherwise, if > 0, then it means that the interrupt <irq>the processing in task_bound The source CPU is bound to the task.

[0080] Based on the above Figure 1 As shown in the method, in an example embodiment, the target topology node with the lowest interrupt load is determined from the target topology level of the multi-core CPU system in step 102, and the specific process in this embodiment can be as follows: when the interrupt source device is a preset other type device and the target topology level is the NUMA level CPU, the target topology node with the lowest interrupt load is determined from the first NUMA node of the multi-core CPU system, and the target topology node is determined as the target first NUMA node. Figure 3 The steps 301 and 302 are implemented.

[0081] Step 301: If at least one first NUMA node without a bound task CPU is determined from the multi-core CPU system, the target first NUMA node with the lowest interrupt load is determined from each first NUMA node, and the target first NUMA node is determined as the target topology node; each first NUMA node is different from the source NUMA node corresponding to the source CPU.

[0082] Step 302: If there is no first NUMA node in the multi-core CPU system and only one source NUMA node is included, or there is a bound task CPU in the other NUMA node except the source NUMA node in the multi-core CPU system, the target topology node is determined according to the other CPU in the source NUMA node except the bound task CPU.

[0083] It should be noted that for different types of interrupt source devices, the corresponding interrupt affinity setting can be determined and stored in advance, and the interrupt type of each interrupt request can be queried through an interrupt type query script to obtain the interrupt source device of each interrupt request.

[0084] For example, the interrupt type query script can be as follows:

[0085] pci_path=`find / sys / bus / pci / devices / * / msi_irqs -name " <irq>`

[0086] test -n "$pci_path" && cat $(dirname $pci_path) / .. / class

[0087] For the CPU topology structure in which multiple CPUs are connected in a topology form in a multi-core CPU system, the CPU topology structure is sequentially from top to bottom as a NUMA node, a cache sub-node, and a CPU at the bottom layer, which can be specifically referred to a CPU topology structure diagram as shown in FIG. 1. Figure 4

[0088] If the interrupt type query script does not output content after querying the interrupt type of the interrupt request through the interrupt type query script, it can be determined that the interrupt source device of the interrupt request is a preset other type device, and the preset other type device can be specifically a USB, multimedia, or other type of device.

[0089] For the USB, multimedia, or other type of device, the interrupt affinity is generally suitable to be set on the CPU list at the NUMA level, at this time, the target first NUMA node with the lowest sum of interrupt loads can be found from other NUMA nodes except the source NUMA node where the interrupt request is processed, that is, at least one first NUMA node without binding tasks is first found from other NUMA nodes, and then the target first NUMA node with the lowest sum of interrupt loads is found from all the first NUMA nodes, and then the target first NUMA node is directly determined as the target topology node.

[0090] Conversely, if there is only one source NUMA node or there are binding task CPUs in other NUMA nodes, the target topology node is determined according to the CPUs in the source NUMA node except the binding task CPUs, such as directly determining the CPUs in the source NUMA node except the binding task CPUs as the target topology node, and taking the mask of the CPUs in the source NUMA node except the binding task CPUs as the interrupt affinity mask of the interrupt request.

[0091] For example, the finding process of the first NUMA node without binding task CPUs in other NUMA nodes except the source NUMA node can be realized by judging whether the result of the AND operation of numa_mask and task_bound is equal to 0, when the result is equal to 0, it means that there is no first NUMA node, and when the result is not equal to 0, it means that there is at least one first NUMA node; wherein, & represents the AND operation, numa_mask represents the NUMA mask in the multi-core CPU system, and the number of NUMA masks is the same as and corresponds to the number of NUMA nodes. ​

[0092] by Figure 4 For example, the NUMA mask includes the NUMA0 mask and the NUMA1 mask, and the NUMA0 mask is 11110000, and the NUMA1 mask is 00001111.

[0093] Then, the sum of the node interrupt loads for each first NUMA node is calculated, which is done by first calculating the interrupt loads on all CPUs under each first NUMA node and then summing them. Next, the target node interrupt load sum with the smallest value is selected from the sums of all node interrupt loads, and the target NUMA node mask corresponding to the target node interrupt load sum is written to / proc / irq / . <irq>In the ` / smp_affinity` file, this is used to update the affinity interruption. Here, ` / proc / irq / ` <irq>The / smp_affinity file is in the virtual directory for managing interrupt requests, and is used to set the interrupt number as <irq>file of the CPU affinity mask of the source NUMA node.

[0094] It should be noted that for the case where there is only one source NUMA node or the CPUs of the other NUMA nodes all have bound tasks, the result of removing the CPUs of the source NUMA node that are not bound to tasks from the source NUMA node's mask (numa_mask & ~task_bound) can be written to / proc / irq / <irq>In the / smp_affinity file, the purpose of updating the interrupt affinity can also be achieved.

[0095] Based on the above Figure 1 As shown in the method, in an example embodiment, the target topology node with the lowest interrupt load is determined from the target topology level of the multi-core CPU system in step 102. In this embodiment, when the interrupt source device is a storage controller and the target topology level is a cache level CPU, the target topology node can be determined by Figure 5 Steps 401 to 403 are implemented.

[0096] Step 401, if at least one first cache sub-node bound to the task CPU is determined to be absent from the source NUMA node of the multi-core CPU system, the target first cache sub-node with the lowest sum of interrupt loads is determined from each first cache sub-node, and the target first cache sub-node is determined as the target topology node; the source NUMA node is the NUMA node corresponding to the source cache sub-node where the source CPU is located, and each first cache sub-node is different from the source cache sub-node.

[0097] Step 402, if the source NUMA node only includes one source cache sub-node, or there is a CPU bound to the task in each cache sub-node except the source cache sub-node under the source NUMA node, the target second cache sub-node with the lowest sum of interrupt loads and without the CPU bound to the task is determined from the other NUMA nodes of the multi-core CPU system except the source NUMA node, and the target second cache sub-node is determined as the target topology node.

[0098] Step 403, if the multi-core CPU system only includes one source NUMA node or all cache sub-nodes of the other NUMA nodes except the source NUMA node have CPUs bound to the task, the target topology node is determined according to the other CPUs in the source cache sub-node except the CPU bound to the task.

[0099] Specifically, when the high 8 bits of the 16-bit string output by the interrupt type query script are 0x01 or 0x0E after the interrupt type of the interrupt request is queried by the interrupt type query script, it can be determined that the interrupt source device of the interrupt request is a storage controller device.

[0100] For the storage controller device, the interrupt affinity is generally suitable to be set on the CPU list at the cache level, at this time, the target first cache sub-node with the lowest sum of interrupt loads and without bound tasks can be found from the other cache sub-nodes of the source NUMA node except the source canhe sub-node where the interrupt request is currently processed, that is, at least one first cache sub-node without bound tasks is first found from the source NUMA node, and then the target first cache sub-node with the lowest sum of interrupt loads is found from all the first cache sub-nodes, and then the target first cache sub-node is directly determined as the target topology node.

[0101] If no first cache sub-node is found from the source NUMA node, that is, there is only one source cache sub-node at the L2 level in the source NUMA node or all the cache sub-nodes at the L2 level in the source NUMA node have CPUs with bound tasks, then the target second cache sub-node with the lowest sum of interrupt loads and without bound tasks is found from the other NUMA nodes except the source NUMA node, at this time, the target second cache sub-node can be directly determined as the target topology node.

[0102] If there is only one source NUMA node or all the cache sub-nodes at the L2 level in the other NUMA nodes have CPUs with bound tasks, then the target topology node is determined according to the other CPUs in the source cache sub-node except the source CPU, for example, the other CPUs in the source cache sub-node except the source CPU are directly determined as the target topology node, and the mask of the other CPUs in the source cache sub-node except the source CPU is taken as the interrupt affinity mask of the interrupt request.

[0103] For example, the finding process of at least one first cache sub-node without bound tasks from the other cache sub-nodes of the source NUMA node except the source canhe sub-node can be realized by judging whether the result of the logical AND operation of cache_mask & task_bound is equal to 0, when the result is equal to 0, it indicates that there is no first cache sub-node, and when the result is not equal to 0, it indicates that there is at least one first cache sub-node; wherein cache_mask represents the cache sub-node mask of the source NUMA node, the number of cache sub-node masks is the same as and corresponds to the number of cache sub-nodes under the source NUMA node.

[0104] For example, the finding process of at least one first cache sub-node without bound tasks from the other cache sub-nodes of the source NUMA node except the source canhe sub-node can be realized by judging whether the result of the logical AND operation of cache_mask & task_bound is equal to 0, when the result is equal to 0, it indicates that there is no first cache sub-node, and when the result is not equal to 0, it indicates that there is at least one first cache sub-node; wherein cache_mask represents the cache sub-node mask of the source NUMA node, the number of cache sub-node masks is the same as and corresponds to the number of cache sub-nodes under the source NUMA node. Figure 4 For example, the NUMA0 node in the above table is the source NUMA node, the cache sub-node mask includes the cache0 mask and the cache1 mask, and the cache0 mask is 11000000 and the cache1 mask is 00110000.

[0105] Then, the sum of the sub-node interrupt loads of each first cache sub-node is calculated, that is, the sum of the respective interrupt loads of all CPUs under each first cache sub-node is calculated first, and then summed; then, the target sub-node interrupt load with the minimum value is selected from the sum of all sub-node interrupt loads, and the mask cache_mask of the target cache sub-node corresponding to the target sub-node interrupt load is written to / proc / irq / <irq>In the / smp_affinity file, the purpose of updating interrupt affinity is achieved.

[0106] It should be noted that for the case that there is only one L2 level source cache sub-node under the source NUMA node or the CPUs in other L2 level cache sub-nodes all have bound tasks, the target second cache sub-node without bound task CPU and with the lowest sum of interrupt load can be found in the same way under other NUMA nodes, and then the mask cache_mask of the target second cache sub-node is written into / proc / irq / <irq>The same search method can be used here, specifically, a method of judging whether the result of the AND operation of the numa_mask and the task_bound is equal to 0.

[0107] In addition, for the case that there is only one source NUMA node or all L2 level cache sub-nodes under other NUMA nodes have CPU bound tasks, the mask of the source cache sub-node can be removed from the result (cache_mask & task_bound) of the bound task CPU and written to / proc / irq / <irq>In the / smp_affinity file, the purpose of updating the interrupt affinity can also be achieved.

[0108] Based on the above Figure 1 As shown in the method, in an example embodiment, the target topology node with the lowest interrupt load is determined from the target topology level of the multi-core CPU system in step 102. In this embodiment, when the interrupt source device is a network card device and the target topology level is a single CPU, the target topology node can be determined by Figure 6 Steps 501 to 503 are implemented as shown.

[0109] Step 501: If at least one other CPU sharing the same source cache sub-node with the source CPU is determined from the multi-core CPU system, then the CPU with the lowest interrupt load and no bound task is determined from each other CPU as the target topology node.

[0110] Step 502: If the source CPU exclusively shares the source cache sub-node or all CPUs sharing the source cache sub-node with the source CPU are bound tasks, then the CPU with the lowest interrupt load and no bound task is determined from the source NUMA node corresponding to the source cache sub-node as the target topology node.

[0111] Step 503: If the CPU with the lowest interrupt load and no bound task is not determined from the source NUMA node, then the CPU with the lowest interrupt load and no bound task is determined from the other NUMA nodes of the multi-core CPU system except the source NUMA node as the target topology node.

[0112] Specifically, if the interrupt type query script outputs a 16-bit string with the high 8 bits as 0x02 or 0x0D after querying the interrupt type of the interrupt request through the aforementioned interrupt type query script, it can be determined that the interrupt device source of the interrupt request is a network card device.

[0113] For network card devices, the interrupt affinity is generally suitable for being set on a single CPU, at which time the CPU with the lowest interrupt load and no bound task can be preferentially found from the source cache sub-node currently processing the interrupt request. The CPU found here is the target topology node.

[0114] If the source CPU exclusively shares the L2-level source cache sub-node or there is a bound task in the CPU currently contributing to the same L2-level source cache sub-node, then the CPU with the lowest interrupt load and no bound task is found in the same L1-level source NUMA node in the same way. The CPU found here is the target topology node.

[0115] If no CPU with the lowest interrupt load and no task binding is found under the source NUM node, then the CPU with the lowest interrupt load and no task binding is determined among the other NUMA nodes besides the source NUMA node; the CPU determined here is the target topology node.

[0116] If there is only one source NUMA node or all CPUs under other NUMA nodes have CPUs with bound tasks, then the source CPU will handle the interrupt request and no interrupt migration operation will be performed.

[0117] For example, the process of finding the CPU with the lowest interrupt load and no bound tasks in the source cache child nodes can be achieved by checking whether the result of the AND operation of cpu_mask & task_bound is equal to 0. When the result of the AND operation is equal to 0, it means that there is no CPU with the lowest interrupt load and no bound tasks. When the result of the AND operation is not equal to 0, it means that there is a CPU with the lowest interrupt load and no bound tasks. Here, cpu_mask represents the CPU mask in the source cache child nodes and its number is the same as the number of CPUs contained in the source cache child nodes and corresponds one-to-one.

[0118] by Figure 4 Taking the cache0 child node as the source cache child node as an example, the CPU mask in the source cache child node includes the mask of CPU0 and the mask of CPU1. The mask of CPU0 is 10000000, and the mask of CPU1 is 01000000.

[0119] It should be noted that for the CPU with the lowest interrupt load and no task binding found under the same L2-level source cache child node, or the CPU with the lowest interrupt load and no task binding found under the same L1-level source NUMA node, or the CPU with the lowest interrupt load and no task binding found under other NUMA nodes, its cpu_mask can be written to / proc / irq / . <irq>In the / smp_affinity file, the interrupt affinity is updated.

[0120] In addition, it should be noted that if there is only one source NUMA node or all CPUs of other NUMA nodes except the source NUMA node have bound tasks, the interrupt affinity does not need to be updated.

[0121] Based on the above Figure 1 As shown in the method, in an example embodiment, after the interrupt request migration is performed or in the process of performing the interrupt request migration, interrupt load migration can also be performed. Based on this, the embodiment of the application can also implement interrupt load migration through the following steps.

[0122] The interrupt load that can be generated by the interrupt request is subtracted from the source topology node, and the subtraction result is added to the target topology node, indicating the migration of the interrupt load.

[0123] Specifically, the / proc / irq / irqnum / smp_affinity file can be read again. <irq>The newly set target topology node is obtained in the manner of the / effective_affinity file, at which time the interrupt load that can be generated by the interrupt request can be added to the target interrupt load on the newly set target topology node, and after the addition is successful, the migration of the interrupt load is completed.

[0124] It should be noted that for the source CPU that handles the interrupt request by default, the original interrupt load on the source CPU can be subtracted by the interrupt load that can be generated by the interrupt request, and after the subtraction is successful, it can be indicated that the interrupt load on the source CPU has completed migration and is updated. In this way, the accuracy of the target topology node found can be improved when traversing the next interrupt request.

[0125] By way of example, the interrupt request is denoted as interrupt <irq>, interrupt <irq>The original interrupt load on the source CPU is noted as , interrupts <irq>The interrupt load that can be generated is denoted , the target interrupt load on the target topology node is denoted , the original interrupt load is subtracted from the interrupt <irq>Loadable in a manner that the updated interrupt load on the source CPU is obtained , and by interrupt <irq>Loadable The target topology node on the target interrupt load is updated in the manner added to the target interrupt load; its process can be shown by the following formula (2) and formula (3).

[0126] = - (2)

[0127] = + (3)

[0128] In formula (2) and formula (3), the original interrupt load And the target interrupt is recorded as Both can be calculated by formula (5), the interrupt <irq>interrupt load generated by interrupt requests The interrupt load generated by interrupt requests can be calculated by formula (4).

[0129] In an example embodiment, the determination of the interrupt load generated by interrupt requests can be achieved by the following steps.

[0130] According to the number of interrupt requests initiated by interrupt requests to the first CPU, the total number of interrupt requests received on the first CPU, and the interrupt load on the first CPU, the interrupt load generated by interrupt requests is calculated; the first CPU is any CPU in a multi-core CPU system.

[0131] Specifically, first traverse the / proc / irq / directory, and each subdirectory named with a number under the / proc / irq / directory represents an interrupt request and saves the information of all interrupt requests, that is, each interrupt request is respectively marked with a number, for example, if there are 5 interrupt requests, there are 1, 2, 3, 4, and 5 numbers corresponding to the 5 interrupt requests, and each number represents an interrupt request.

[0132] For example, in / proc / irq / <irq>The / effective_affinity file holds the default handling of interrupts <irq>In the case of the source CPU of this interrupt event, for the interrupt <irq>, read / proc / irq / <irq>the contents of the / effective_affinity file, the contents read being specifically the default handling of interrupts <irq>mask of the source CPU, for example, if the mask of the source CPU is 2, the CPU corresponding to 2 is the default processor for handling the interrupt <irq>the source CPU; and recording the read content as <cpu> ， <cpu>Indicates actual processing interruption <irq>CPU mask of the source CPU.

[0133] Then, the statistics table of the interrupt requests handled on the CPUs is read in the / proc / interrupts file. In this case, each line in the / proc / interrupts file represents an interrupt request, each column represents a CPU, and the data in the statistics table indicates the count value of the interrupt request represented by the line handled on the CPU represented by the column. Thus, the count value of the interrupt request handled on the CPU can be inquired by looking up the interrupt request in the / proc / interrupts file. <irq>the row in which the cell is located, <cpu>The count value of the column in which the is recorded is added to <cpu>The total number of interrupts on the column where the object is located is noted after .

[0134] The number of interrupts is finally calculated by equation (4) <irq>interruptable load .

[0135] (4)

[0136] in formula (4), indicates an interruption <irq>the number of interrupt requests initiated to the first CPU, the total number of interrupt requests received on the first CPU, the interrupt load on the first CPU.

[0137] It should be noted that the / proc / interrupts file is a file in the Linux kernel virtual file system (procfs) that records real-time statistics of the number of interrupt requests triggered on each CPU, and the statistics are stored in table form.

[0138] In an example embodiment, the determination process of the interrupt load on the first CPU can be implemented by the following steps.

[0139] According to the target time of the first CPU for processing interrupt requests within a preset time period and the preset time period, the interrupt load on the first CPU is calculated; the target time includes the difference between the total time of the first CPU for processing hard interrupts and soft interrupts twice within the preset time period.

[0140] Specifically, first, the preset time period is acquire the statistics of all CPUs in the Linux operating system twice, and the source of the two statistics is the / proc / stat file, which is a dynamic file in the Linux kernel virtual file system (procfs) that records CPU statistics, and the content of the 2nd to (n+1)th lines in the / proc / stat file is the activity statistics of n CPUs since the start of the Linux operating system; wherein the 6th and 7th columns of each line of statistics are the total time consumed by the CPU represented by the line on hard interrupts and soft interrupts, respectively, and n is the total number of CPUs in the Linux operating system.

[0141] Then, for the two read statistics, the total time read the second time is subtracted from the total time read the first time, and the difference is the target time of the first CPU for processing interrupt requests within the preset time period .

[0142] Finally, the interrupt load on the first CPU is calculated by formula (5) .

[0143] (5)

[0144] In formula (5), the difference between the total time of the first CPU for processing hard interrupts and soft interrupts twice within the preset time period, i.e., the target time of the first CPU for processing interrupt requests within the preset time period; ​represents a preset time period.

[0145] As shown in the figure, the method for improving the execution efficiency of the compute-intensive task is as follows: Figure 7 As shown in the figure, the method for improving the execution efficiency of the compute-intensive task is as follows: Figure 7 As shown in the figure, in the case that the interrupt load of each CPU and the interrupt load generated by each interrupt request are calculated in advance, the CPU on which the bound task is executed is obtained, and is marked as task_bound That is, the first CPU mask is obtained, and then all interrupt requests in the / proc / irq / directory are traversed, and it is judged whether the processing of each interrupt request is on the source CPU covered in the task_bound If yes, the interrupt type of the interrupt request is judged, and the target CPU (that is, the CPU on which the bound task is not executed and the interrupt load of which is the lowest) is determined according to the interrupt affinity setting of the interrupt source device of the interrupt request, and then the interrupt load generated by the interrupt request is subtracted from the interrupt load of the source CPU and added to the interrupt load of the newly set target CPU; otherwise, the next interrupt request in the / proc / irq / directory is traversed; until all interrupt requests in the / proc / irq / directory are traversed. The specific process involved can refer to the foregoing embodiments and Figure 7 Here, no longer be described.

[0146] The method for improving the execution efficiency of the compute-intensive task provided by the embodiment of the application can, according to different interrupt types, as far as possible, migrate the interrupt request on the source CPU on which the bound task is recognized to other CPUs in the same NUMA node or the same shared L2-level cache with lower interrupt load, and if it cannot be satisfied, cross-cache migration or cross-NUMA node migration is considered; based on the interrupt load analysis of the CPU topology structure in the system, the interrupt request on the CPU on which the bound task is executed is migrated to the CPU with the lowest interrupt load, which not only ensures that the task execution on the source CPU is not preempted by the interrupt processing, but also as far as possible, does not affect the interrupt load on the target topology node, and further, the interrupt request is migrated to the determined target topology node by setting the interrupt affinity, which ensures the subsequent efficiency of the interrupt processing, so that the influence of the compute-intensive task from the external factor (the interrupt processing) is considered, and the execution efficiency of the task is improved without deploying expensive hardware or modifying the task at the code level.

[0147] It should be noted that, although the operations of the inventive method are described in a particular order in the drawings, this is not required or implied in any way as to the order of the operations being required or implied by the drawings. Rather, the steps depicted in the flowcharts can be changed in order of execution. Additionally or alternatively, certain steps can be omitted, multiple steps can be combined into one step, and / or one step can be broken into multiple steps.

[0148] In one embodiment, the present embodiment also provides an apparatus for improving the execution efficiency of a compute-intensive task, as shown in the figure, the apparatus for improving the execution efficiency of a compute-intensive task comprises a task binding judgment unit 801, an interrupt request migration unit 802 and an interrupt request processing unit 803. Figure 8

[0149] The task binding judgment unit 801 is configured to judge whether the source CPU that is to process the interrupt request by default is bound to a task in response to the interrupt request received by the multi-core CPU system.

[0150] The interrupt request migration unit 802 is configured to, if it is determined that the source CPU is bound to a task, determine the target topology level that is adapted to the interrupt request according to the interrupt source device of the interrupt request, then determine the target topology node with the lowest interrupt load from the target topology level of the multi-core CPU system, and set the interrupt affinity mask of the interrupt request to the mask of the target topology node.

[0151] The interrupt request processing unit 803 is configured to, if it is determined that the source CPU is not bound to a task, determine that the interrupt request is processed by the source CPU.

[0152] In one embodiment, the task binding judgment unit 801 is specifically configured to obtain a first CPU mask and a second CPU mask, the first CPU mask is used to represent whether all CPUs in the multi-core CPU system are bound to a task, and the second CPU mask is used to represent the CPU that is to process the interrupt request by default; and determine whether the source CPU is bound to a task based on the result of the AND operation of the first CPU mask and the second CPU mask.

[0153] ​In one embodiment, the interrupt request migration unit 802 is specifically configured to, in the case that the interrupt source device is a preset other type of device and the target topology level is a NUMA level CPU, if it is determined from the multi-core CPU system that there is no at least one first NUMA node that binds the task CPU, determine a target first NUMA node with the lowest sum of interrupt loads from each first NUMA node, and determine the target first NUMA node as the target topology node; each first NUMA node is different from a source NUMA node corresponding to the source CPU; if there is no first NUMA node in the multi-core CPU system and only one source NUMA node, or there is a CPU that binds a task in each NUMA node other than the source NUMA node in the multi-core CPU system, determine the target topology node according to the other CPUs in the source NUMA node other than the CPU that binds the task.

[0154] In one embodiment, the interrupt request migration unit 802 is specifically configured to, in the case that the interrupt source device is a storage controller and the target topology level is a cache level CPU, if it is determined from the source NUMA node of the multi-core CPU system that there is no at least one first cache sub-node that binds the task CPU, determine a target first cache sub-node with the lowest sum of interrupt loads from each first cache sub-node, and determine the target first cache sub-node as the target topology node; the source NUMA node is a NUMA node corresponding to a source cache sub-node where the source CPU is located, and each first cache sub-node is different from the source cache sub-node; if there is only one source cache sub-node in the source NUMA node, or there is a CPU that binds a task in each cache sub-node other than the source cache sub-node under the source NUMA node, determine a target second cache sub-node with the lowest sum of interrupt loads from each NUMA node other than the source NUMA node in the multi-core CPU system and that does not bind the task CPU, and determine the target second cache sub-node as the target topology node; if there is only one source NUMA node in the multi-core CPU system or there is a CPU that binds a task in each cache sub-node of each NUMA node other than the source NUMA node, determine the target topology node according to the other CPUs in the source cache sub-node other than the CPU that binds the task.

[0155] In one embodiment, the interrupt request migration unit 802 is further configured to, when the interrupt source device is a network interface card (NIC) device and the target topology level is a single CPU, if at least one other CPU sharing the same source cache sub-node with the source CPU is determined from the multi-core CPU system, then the CPU with the lowest interrupt load that is not bound to a task is determined from among the other CPUs as the target topology node; if the source CPU exclusively owns the source cache sub-node or all CPUs sharing the source cache sub-node with the source CPU are bound to a task, then the CPU with the lowest interrupt load that is not bound to a task is determined from the source NUMA node corresponding to the source cache sub-node as the target topology node; if no CPU with the lowest interrupt load that is not bound to a task is determined from the source NUMA node, then the CPU with the lowest interrupt load that is not bound to a task is determined from the other NUMA nodes in the multi-core CPU system other than the source NUMA node as the target topology node.

[0156] In one embodiment, the interrupt request migration unit 802 is further configured to subtract the interrupt load that the interrupt request can generate from the source topology node and add the subtraction result to the target topology node, representing the migration of the interrupt load.

[0157] In one embodiment, the interrupt request migration unit 802 is further configured to calculate the interrupt load that the interrupt request can generate based on the number of interrupt requests initiated by the interrupt request to the first CPU, the total number of interrupt requests received on the first CPU, and the interrupt load on the first CPU; the first CPU is any CPU in a multi-core CPU system.

[0158] In one embodiment, the interrupt request migration unit 802 is further configured to calculate the interrupt load on the first CPU based on the target time for the first CPU to process interrupt requests within a preset time period and the preset time period; the target time includes the difference between the total time for the first CPU to process two hard interrupts and soft interrupts within the preset time period.

[0159] It should be understood that the units and references described in the device for improving the efficiency of computationally intensive tasks Figure 1 The steps in the described method correspond accordingly. Therefore, the operations and features described above for the method are also applicable to the apparatus for improving the execution efficiency of computationally intensive tasks and the units contained therein, and will not be repeated here. The apparatus for improving the execution efficiency of computationally intensive tasks can be pre-implemented in the browser or other security applications of a computer device, or it can be loaded into the browser or its security applications of a computer device through download or other means. The corresponding units in the apparatus for improving the execution efficiency of computationally intensive tasks can cooperate with the units in the computer device to implement the solution of the embodiments of the present invention.

[0160] The following is for reference. Figure 9 which shows a structural diagram of a computer system 900 suitable for use as a terminal device or server for implementing embodiments of the present application.

[0161] As shown in Figure 9 , the computer system 900 includes a central processing unit (CPU) 901 which can perform various appropriate actions and processes in accordance with a program stored in a read only memory (ROM) 902 or a program loaded into a random access memory (RAM) 903 from a storage section 908. In the RAM 903, various programs and data required for the operation of the system 900 are also stored. The CPU 901, the ROM 902, and the RAM 903 are connected to each other through a bus 904. An input / output (I / O) interface 905 is also connected to the bus 904.

[0162] The following components are connected to the I / O interface 905: an input section 906 including a keyboard, a mouse, etc.; an output section 907 including a display such as a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card such as a LAN card, a modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to the I / O interface 905 as necessary. A removable recording medium 911 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. is attached to the drive 910 as necessary, so that a computer program read therefrom is installed into the storage section 908 as necessary.

[0163] In particular, the processes described above with reference to Figure 1 may be implemented as a computer software program. For example, embodiments of the present disclosure include a computer program product comprising a computer program tangibly embodied on a machine readable medium, the computer program comprising program code for executing Figure 1 the methods described above. In such embodiments, the computer program can be downloaded and installed from a network via the communication section 909 and / or installed from the removable recording medium 911.

[0164] It should be noted that the computer-readable medium shown in the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may, for example, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or component, or any combination of the above. More specific examples of computer-readable storage media can include, but are not limited to, an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device or component. In the present application, the computer-readable signal medium can include a data signal carried in a baseband or as a part of a carrier wave, which carries computer-readable program code. Such a propagated data signal can take many forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. The computer-readable signal medium can also be any computer-readable medium that can send, propagate or transmit a program for use by or in conjunction with an instruction execution system, device or component. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0165] The flow diagrams and block diagrams in the drawings are schematic illustrations of possible architectures, functions and operations of systems, methods and computer program products in accordance with various embodiments of the present application. In this regard, each block in the flow diagrams or block diagrams can represent a module, a segment, or a portion of code, which comprises one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or the blocks may be executed in the reverse order, depending on the functionality involved. It will also be noted that each block of the block diagrams and / or flow diagrams, and combinations of blocks in the block diagrams and / or flow diagrams, can be implemented by special purpose hardware-based systems that perform the specified functions or operations, or combinations of special purpose hardware and computer instructions.

[0166] The units or modules described in the embodiments of the present application can be implemented by software or by hardware. The units or modules described can also be implemented in a processor. In some cases, the names of the units or modules do not constitute a limitation on the units or modules themselves.

[0167] As another aspect, the present application also provides a computer readable storage medium, which can be included in the computer device described in the above embodiments, or can exist separately and not be assembled into the computer device. The computer readable storage medium stores one or more programs, which, when executed by one or more processors, perform the methods described in the present application. For example, the computer readable storage medium can store the following programs. Figure 1 Each step of the method shown.

[0168] The embodiments of the present application provide a computer program product, which includes instructions that, when executed, cause the method described in the embodiments of the present application to be performed. For example, the computer program product can store the following programs. Figure 1 Each step of the method shown.

[0169] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer readable storage medium, and when executed, can include the processes of the above-mentioned embodiment methods. In the embodiments of the present application, any reference to memory, database or other medium can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical storage, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration but not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The database involved in the embodiments of the present application can include at least one of a relational database and a non-relational database. The non-relational database can include a distributed database based on a block chain, etc., without being limited thereto. The processor involved in the embodiments of the present application can be a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., without being limited thereto.

[0170] The above description is only the preferred embodiment of the present application and the explanation of the applied technical principles. Those skilled in the art should understand that the scope of the present application is not limited to the technical solutions formed by the specific combination of the above technical features, and also covers other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the inventive concept. For example, the above features can be replaced with the technical features disclosed in the present application (but not limited to) having similar functions to form technical solutions.< / irq> < / irq> < / cpu> < / cpu> < / irq> < / irq> < / cpu> < / cpu> < / irq> < / irq> < / irq> < / irq> < / irq> < / irq> < / irq> ​< / irq> < / irq> < / irq> < / irq> < / irq> < / irq> < / irq> < / irq> < / irq> < / irq> < / irq> < / irq> < / irq> < / irq> < / irq> < / irq> < / irq> < / irq> < / irq> < / irq> < / irq> < / irq>

Claims

1. A method for improving the execution efficiency of computationally intensive tasks, characterized in that, The method includes: In response to an interrupt request received by a multi-core CPU system, determine whether the source CPU that is to handle the interrupt request by default is bound to a task; If the source CPU is determined to be bound to a task, then the target topology level that is compatible with the interrupt request is determined according to the interrupt source device of the interrupt request, and then the target topology node with the lowest interrupt load is determined from the target topology levels of the multi-core CPU system, and the interrupt affinity mask of the interrupt request is set as the mask of the target topology node. If it is determined that the source CPU is not bound to a task, then the interrupt request is determined to be handled by the source CPU. The step of determining whether the source CPU that defaults to handling the interrupt request is bound to a task includes: Obtain a first CPU mask and a second CPU mask. The first CPU mask is used to characterize whether all CPUs in the multi-core CPU system are bound to a task. The second CPU mask is used to characterize the CPU that handles the interrupt request by default. Based on the result of the AND operation between the first CPU mask and the second CPU mask, it is determined whether the source CPU is bound to a task.

2. The method according to claim 1, characterized in that, The step of determining the target topology node with the lowest interrupt load from the target topology level of the multi-core CPU system includes: In the case where the interrupt source device is a preset other type of device and the target topology level is a NUMA-level CPU. If at least one first NUMA node with no bound task CPU is determined from the multi-core CPU system, then the target first NUMA node with the lowest sum of interrupt loads is determined from each of the first NUMA nodes, and the target first NUMA node is determined as the target topology node; each first NUMA node is different from the source NUMA node corresponding to the source CPU. If the first NUMA node does not exist in the multi-core CPU system and only one source NUMA node is included, or if all other NUMA nodes in the multi-core CPU system other than the source NUMA node contain CPUs bound to tasks, then the target topology node is determined based on the other CPUs in the source NUMA node other than the CPUs bound to tasks.

3. The method according to claim 1, characterized in that, The step of determining the target topology node with the lowest interrupt load from the target topology level of the multi-core CPU system further includes: In the case where the interrupt source device is a storage controller and the target topology level is a cache-level CPU. If at least one first cache child node with no bound task CPU is determined from the source NUMA nodes of the multi-core CPU system, then the target first cache child node with the lowest sum of interrupt loads is determined from each of the first cache child nodes, and the target first cache child node is determined as the target topology node; the source NUMA node is the NUMA node corresponding to the source cache child node where the source CPU is located, and each first cache child node is different from the source cache child node; If the source NUMA node includes only one source cache child node, or if all other cache child nodes under the source NUMA node have CPUs with bound tasks, then the target second cache child node with the lowest sum of interrupt load and no bound task CPUs is determined from the other NUMA nodes in the multi-core CPU system, and the target second cache child node is determined as the target topology node. If the multi-core CPU system includes only one source NUMA node, or if all cache child nodes in other NUMA nodes besides the source NUMA node have CPUs with bound tasks, then the target topology node is determined based on the other CPUs in the source cache child nodes besides the CPUs with bound tasks.

4. The method according to claim 1, characterized in that, The step of determining the target topology node with the lowest interrupt load from the target topology level of the multi-core CPU system further includes: In the case where the interrupt source device is a network interface card (NIC) and the target topology level is a single CPU. If at least one other CPU that shares the same source cache sub-node with the source CPU is determined from the multi-core CPU system, then the CPU that is not bound to a task and has the lowest interrupt load is determined from among the other CPUs and is used as the target topology node. If the source CPU exclusively owns the source cache sub-node, or if all CPUs sharing the source cache sub-node with the source CPU are bound to tasks, then the CPU that is not bound to a task and has the lowest interrupt load is determined from the source NUMA nodes corresponding to the source cache sub-node and is used as the target topology node. If the CPU with the lowest interrupt load and no unbound task is identified from the source NUMA node, then the CPU with the lowest interrupt load and no unbound task is identified from the other NUMA nodes in the multi-core CPU system besides the source NUMA node, and is selected as the target topology node.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: The interrupt load that can be generated by the interrupt request is subtracted from the source topology node, and the result of the subtraction is added to the target topology node, which represents the migration of the interrupt load.

6. The method according to claim 5, characterized in that, The process of determining the interrupt load that the interrupt request may generate includes: The interrupt load that the interrupt request can generate is calculated based on the number of interrupt requests initiated by the interrupt request to the first CPU, the total number of interrupt requests received on the first CPU, and the interrupt load on the first CPU; the first CPU is any CPU in the multi-core CPU system.

7. The method according to claim 6, characterized in that, The process of determining the interrupt load on the first CPU includes: The interrupt load on the first CPU is calculated based on the target time for the first CPU to process the interrupt request within a preset time period and the preset time period itself; the target time includes the difference between the total time for the first CPU to process two hard interrupts and two soft interrupts within the preset time period.

8. A computer device, comprising a processor, a memory, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method for improving the execution efficiency of computationally intensive tasks as described in any one of claims 1 to 7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method for improving the execution efficiency of computationally intensive tasks as described in any one of claims 1 to 7.

Images