Task management method, and computing cluster and computer program product

Abstract

Provided in the present application are a task management method, and a computing cluster and a computer program product. The method comprises: a management node in a computing cluster acquiring a first demand amount, for a shared cache in a first computing node, of a plurality of tasks running in the first computing node in the computing cluster, wherein the shared cache in the first computing node is a shared cache corresponding to a plurality of processing units of the first computing node; when the capacity of the shared cache in the first computing node cannot meet the first demand amount, the management node determining a task to be migrated from among the plurality of tasks, and determining a second computing node capable of meeting a shared cache demand of the task to be migrated; the management node sending information of the task to be migrated and information of the second computing node to the first computing node; and the first computing node migrating the task to be migrated to the second computing node on the basis of the information of the task to be migrated and the information of the second computing node. The method can meet the demand of a task for a shared cache to the greatest extent, and make full use of shared cache resources of the entire computing cluster.

Description

Task management methods, computing clusters, and computer program products

[0001] This application claims priority to Chinese Patent Application No. 202510009401.1, filed on January 2, 2025, entitled "Task Management Method, Computing Cluster and Computer Program Product", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of cache management technology, and more particularly to a task management method, computing cluster, and computer program product. Background Technology

[0003] In a supernode cluster, each node runs multiple tasks, and each task requires resources during runtime. For example, multiple tasks running on a multi-core processor within a node share a cache called the Last Level Cache (LLC). Since the LLC has limited capacity, conflicts may occur between multiple tasks. To address the performance degradation caused by multiple tasks competing for the LLC on the same processor, traditional technologies have proposed hardware-based resource isolation. This approach ensures task execution efficiency by allowing specific tasks to exclusively utilize specific hardware resources. A typical implementation is Cache Allocation Technology (CAT).

[0004] CAT (Compute-Oriented) technology allows a portion of the LLC (Limited Cache) to be allocated to a core in a multi-core processor. This restricts tasks running on that core to using only the allocated cache space, thus achieving LLC resource isolation. However, when the tasks running on a core change—for example, from non-computationally intensive to computationally intensive—the LLC cache space corresponding to that core may not be sufficient to meet the task's needs, resulting in low execution efficiency. Summary of the Invention

[0005] This application provides a task management method, a computing cluster, and a computer program product that can meet the task's need for a shared cache.

[0006] In a first aspect, this application provides a task management method, which includes: a management node in a computing cluster obtaining a first demand for a shared cache in a first computing node from multiple tasks running in the computing cluster, wherein the shared cache in the first computing node is a shared cache corresponding to multiple processing units of the first computing node; when the capacity of the shared cache in the first computing node cannot meet the first demand, the management node determines a migration task from the multiple tasks and determines a second computing node that can meet the shared cache demand of the migration task; the management node sends information about the migration task and information about the second computing node to the first computing node; and the first computing node migrates the migration task to the second computing node according to the information about the migration task and the information about the second computing node.

[0007] In the above scheme, the management node determines whether the initial demand for the shared cache on the first compute node exceeds its capacity by obtaining the initial demand from multiple tasks running on the first compute node. If the initial demand exceeds the shared cache capacity, it indicates a conflict in the demands of these tasks on the shared cache. Each task frequently encroaches on the space used by other tasks in the shared cache, leading to data eviction and frequent data loading from the first compute node's memory. This increases memory access latency and reduces task processing speed. Therefore, it is necessary to migrate some tasks from the first compute node to other compute nodes to alleviate the contention for the shared cache on the first compute node.

[0008] Then, the management node identifies the migration task from among the multiple tasks running on the first compute node and determines a second compute node in the compute cluster that can meet the shared cache requirements of the migration task. The management node then sends the migration task information and the second compute node information to the first compute node, instructing the first compute node to migrate the task to the second compute node. When the migration task is migrated to the second compute node, fewer tasks remain on the first compute node, reducing the contention for the shared cache by the remaining tasks and helping to improve the performance of the remaining tasks. Furthermore, because the second compute node can meet the shared cache requirements of the migration task, the migration task achieves better performance on the second compute node.

[0009] Based on the first aspect, in a possible implementation, the management node can periodically obtain the amount of data in the memory of the first computing node for multiple tasks running on the first computing node. Then, the management node determines the task with the least amount of data in the memory of the first computing node as the migration task. In other words, in order to reduce the cost of task migration between computing nodes, the task with the least amount of data in the memory of the first computing node can be selected as the migration task, and then the migration task can be migrated from the first computing node to the second computing node.

[0010] Based on the first aspect, in a possible implementation, the management node can periodically obtain the remaining amount of shared cache in the computing nodes of the computing cluster. Then, the management node determines the computing node whose shared cache remaining amount is greater than the shared cache requirement of the migration task as the second computing node. In other words, the management node can select the computing node with sufficient shared cache remaining amount to meet the shared cache requirement of the migration task from the computing cluster as the second computing node based on the shared cache remaining amount of each computing node, and then migrate the migration task from the first computing node to the second computing node.

[0011] Based on the first aspect, in a possible implementation, the management node periodically obtains the remaining shared cache and memory of the compute nodes in the computing cluster. The management node determines the compute node whose shared cache remaining space is greater than the shared cache requirement of the migration task and whose memory remaining space is greater than the amount of data occupied by the migration task as the second compute node. In other words, the management node comprehensively considers the shared cache remaining space and the memory remaining space of each compute node, and then determines the compute node whose shared cache remaining space is greater than the shared cache requirement of the migration task and whose memory remaining space is greater than the amount of data occupied by the migration task as the second compute node.

[0012] Based on the first aspect, in a possible implementation, the first compute node determines whether the usage of its shared cache has reached a waterline threshold. If it does, it sends an alarm to the management node, which then determines, based on the alarm, that the capacity of the shared cache in the first compute node cannot meet the first demand. In this scheme, the first compute node can monitor whether the usage of its shared cache has reached the waterline threshold. When the waterline threshold is reached, it sends an alarm to the management node, triggering the management node to determine whether the capacity of the shared cache in the first compute node meets the first demand. The alarm may carry the first demand of multiple tasks running on the first compute node for the shared cache. If the management node determines, based on the alarm, that the capacity of the shared cache in the first compute node cannot meet the first demand, the management node determines a migration task from these multiple tasks and identifies a second compute node capable of meeting the shared cache requirements of the migration task.

[0013] Based on the first aspect, in a possible implementation, the first computing node obtains the second demand of multiple subtasks running by multiple cores in the first processing unit of the first computing node for the first shared cache, wherein the multiple subtasks belong to at least one of multiple tasks, and the first shared cache is the shared cache corresponding to the first processing unit; when the capacity of the first shared cache cannot meet the second demand, the first computing node determines the subtask to be moved out from the multiple subtasks and the second processing unit in the first computing node that can meet the shared cache demand of the subtask to be moved out; the first computing node migrates the subtask to the second processing unit.

[0014] In the above scheme, the first processing unit is a processing unit within the first computing node. The first computing node determines whether the second demand exceeds the capacity of the first shared cache by monitoring the second demand of multiple subtasks running on multiple cores within the first processing unit. If the capacity of the first shared cache exceeds the second demand, it indicates a conflict (severe contention) in the demand of the multiple subtasks running on the first processing unit for the first shared cache. Each subtask frequently encroaches on the space used by other subtasks in the first shared cache, causing data stored in the first shared cache to be evicted. This necessitates frequent loading of corresponding data from the memory of the first computing node, thereby increasing memory access latency and reducing the execution speed of the subtasks. In this case, it is necessary to migrate some subtasks from the first processing unit to other processing units to alleviate the contention pressure on the first shared cache from the subtasks running in the first processing unit.

[0015] Then, the first compute node determines a subtask to be migrated from multiple subtasks running on multiple cores in the first processing unit, and identifies a second processing unit within the first compute node that can meet the shared cache requirements of the migrated subtask. The migrated subtask is then moved from the first processing unit to the second processing unit. When the migrated subtask is moved to the second processing unit, the number of tasks on the first processing unit decreases, reducing the contention for the first shared cache by the remaining tasks on the first processing unit and helping to improve the performance of the remaining tasks. Furthermore, since the second processing unit can meet the shared cache requirements of the migrated subtask, the migrated subtask achieves better performance on the second processing unit.

[0016] Based on the first aspect, in a possible implementation, the shared cache requirement of the migrated subtask is less than or equal to the remaining capacity of the shared cache corresponding to the second processing unit, and the shared cache requirement of the migrated subtask is greater than or equal to the difference between the second requirement and the capacity of the first shared cache. When the shared cache requirement of the migrated subtask meets the above conditions, it indicates that after the migrated subtask is moved to the second processing unit, the second processing unit can meet the shared cache requirement of the migrated subtask, thereby ensuring the performance of the migrated subtask when running in the second processing unit. Furthermore, the capacity of the first shared cache of the first processing unit can meet the shared cache requirement of the remaining tasks in the first processing unit, reducing the contention pressure of the remaining tasks on the first shared cache in the first processing unit.

[0017] Based on the first aspect, in a possible implementation, the first computing node determines a processing unit that includes the migrated-in subtask from other processing units of the first computing node, wherein the difference between the shared cache requirement of the migrated-out subtask and the shared cache requirement of the migrated-in subtask is greater than or equal to the difference between the second requirement and the capacity of the first shared cache; the first computing node migrates the migrated-out subtask to the second processing unit and migrates the migrated-in subtask to the first processing unit.

[0018] In the above scheme, the first computing node not only determines the outgoing subtasks that need to be migrated to the second computing node from the first processing unit, but also determines the incoming subtasks that need to be migrated to the first processing unit from other processing units of the first computing node. To reduce the contention pressure on the first shared cache from tasks in the first processing unit, the difference between the shared cache requirements of the outgoing subtasks and the shared cache requirements of the incoming subtasks is required to be greater than or equal to the difference between the second requirement and the capacity of the first shared cache.

[0019] Based on the first aspect, in a possible implementation, the first computing node obtains the performance indicators of multiple subtasks, and then determines the second demand based on the performance indicators of the multiple subtasks.

[0020] In a second aspect, this application also provides a computing cluster, including a management node and multiple computing nodes, which is used to perform the method of any possible implementation of the first aspect.

[0021] Thirdly, this application also provides a computer-readable storage medium including instructions that, when executed on a computing system, cause the computing system to perform a method as described in any possible embodiment of the first aspect, wherein the computing node includes a management node and a plurality of computing nodes.

[0022] Fourthly, this application also provides a computer program product containing instructions. When the aforementioned instructions are executed by a computing system, the computing system performs the method as described in any possible embodiment of the first aspect. The computing node includes a management node and multiple computing nodes. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments are briefly introduced below.

[0024] Figure 1 is an architecture diagram of a computing cluster provided in an embodiment of this application;

[0025] Figure 2 is a schematic diagram illustrating the relationship between the CPU physical topology and applications within a computing node, as provided in an embodiment of this application.

[0026] Figure 3 is a schematic diagram of the relationship between a CPU cluster and an LLC memory bank provided in an embodiment of this application;

[0027] Figure 4 is a flowchart illustrating a task management method provided in an embodiment of this application;

[0028] Figure 5 is a graph showing the relationship between the performance indicators of a certain task and the amount of shared cache allocation provided in an embodiment of this application.

[0029] Figure 6 is an interaction flowchart between a management node and a computing node provided in an embodiment of this application;

[0030] Figure 7 is a schematic diagram of a task migration between a first computing node and a second computing node provided in an embodiment of this application;

[0031] Figure 8 is a flowchart illustrating another task management method provided in an embodiment of this application;

[0032] Figure 9 is a schematic diagram of thread migration between different CPUs within the same computing node provided by an embodiment of this application;

[0033] Figure 10 is a schematic diagram of another thread migration between different CPUs within the same computing node provided by an embodiment of this application;

[0034] Figure 11 is a schematic diagram of the structure of a computing node provided in an embodiment of this application. Detailed Implementation

[0035] To facilitate understanding of the technical solution of this application, a computing cluster involved in this application will be introduced first.

[0036] Please refer to Figure 1, which is an architecture diagram of a computing cluster provided in an embodiment of this application. This computing cluster can also be called a supernode cluster, including a management node and multiple computing nodes. The computing nodes can be connected to each other via a bus, and the management node is connected to each computing node. This application does not specifically limit this connection.

[0037] The aforementioned management node can be a device other than the aforementioned multiple computing nodes, or it can be one of the aforementioned multiple computing nodes, or it can be jointly served by some of the aforementioned multiple computing nodes. This application does not make any specific limitations.

[0038] The aforementioned bus can provide direct links or indirect connections (such as forwarding via a switch) between computing nodes, and this application does not specifically limit its use. Optionally, the aforementioned bus can be a high-speed interconnect bus, which features high bandwidth and low latency, enabling efficient data transmission between computing nodes. The high-speed interconnect bus can be a Compute Express Link (CXL), NVIDIA Link (NVLink), high-speed Ethernet, or other buses, and this application does not specifically limit its use either.

[0039] The aforementioned computing nodes can be physical computing devices such as servers or desktop computers, and this application does not specifically limit them. A computing node includes one or more processing units, which can be central processing units (CPUs), and one or more applications can be deployed on the computing node.

[0040] Please refer to Figure 2, which is a schematic diagram illustrating the relationship between the CPU physical topology and applications within a computing node according to an embodiment of this application. Figure 2 includes multiple sockets, each socket being a package of a physical CPU. The number of physical CPUs is also referred to as the number of sockets. Each socket includes one or more CPU dies, and each CPU die may include one or more cores. A CPU core, also known as a physical core, is an independent processing unit within the CPU. Each physical core can execute instructions independently, and multiple physical cores can achieve parallel processing. A processor containing multiple cores is a multi-core processor.

[0041] Each socket has a corresponding Last Level Cache (LLC) space. LLC, also known as off-core cache or last-level cache, is a cache layer in computer architecture located between the physical core and memory (not shown in the diagram). The main function of the LLC is to store recently used data to reduce the latency of physical core accessing memory, thereby improving data access speed and system performance. LLCs are typically shared; different physical cores within the same socket logically share (access / use) the corresponding LLC space for that socket. This effectively reduces data redundancy and improves cache hit rate.

[0042] There are several possible implementations for the LLC space corresponding to the socket, depending on the chip design.

[0043] Figure 2 illustrates a possible implementation where each CPU die has a physically independent LLC memory (a cache memory), and all physical cores on that CPU die can share the cache space of this LLC memory. The LLC memories on different CPU dies within the same socket can be connected via an inter-chip bus, allowing physical cores on a CPU die to access both the LLC memory cache space of that CPU die and the LLC memory cache spaces of other CPU dies within the same socket. In this case, the LLC space corresponding to a socket includes the LLC memory cache spaces of all CPU dies within that socket, and different physical cores within that socket share the LLC space corresponding to that socket.

[0044] Figure 3 illustrates another possible implementation: a socket includes multiple LLC memory banks connected via an inter-chip bus. These banks correspond one-to-one with multiple CPU clusters within the socket. A CPU cluster is a concept found in processor architectures such as ARM. Multiple adjacent physical cores within a CPU die form a CPU cluster, and a socket can contain multiple CPU clusters. In this case, the LLC space corresponding to a socket includes the cache space of the aforementioned multiple banks. All physical cores within the socket share this cache space, but each physical core in a CPU cluster preferentially uses the cache space of its corresponding bank. Physical cores in different CPU clusters can simultaneously access the cache spaces of different banks, thereby improving resource utilization, reducing access conflicts, and increasing data access speed.

[0045] A compute node can deploy one or more applications. The compute node runs instances of the corresponding applications (also called application processes). An application can have one or more application instances, and each application instance can create one or more threads to execute corresponding tasks. Optionally, an application instance can be a Virtual Machine (VM), a container, or a regular process other than a VM or container. A VM refers to a complete computer system simulated by software, possessing full hardware system functionality and running in a completely isolated environment. A VM is a single-process application. A VM can include one or more virtual cores, also called Virtual Central Processing Units (vCPUs). Each virtual core is a processing unit within the VM, and each virtual core can be understood as a thread of an application instance. A container is a portable software unit that can combine an application and all its dependencies into a single software package. This package is not limited by the underlying host operating system, thus eliminating the need to build complex environments and simplifying the application development and deployment process. A container's corresponding process can create one or more threads (a thread of the application instance), and each thread is used to execute corresponding tasks. Each physical core can run one or more threads; that is, there is a one-to-one or one-to-many relationship between physical cores and threads.

[0046] For example, assuming a one-to-one relationship between physical cores and threads, as shown in Figure 1, a VM has four vCPUs, and each vCPU corresponds to one physical core in the corresponding compute node (one-to-one correspondence). Alternatively, a container may have four threads, and each thread corresponds to one physical core in the corresponding compute node (one-to-one correspondence). It should be understood that the four vCPUs / threads in Figure 1 correspond to four different physical cores in a CPU cluster, but this is merely an example and does not constitute a limitation. In reality, different vCPUs / threads can correspond to physical cores in different CPU clusters, different CPU dies, or different sockets. This application does not impose any specific limitations on this.

[0047] As described above, multiple applications can be deployed on N compute nodes in a supernode cluster. Any compute node can deploy one or more applications, or it can remain idle (i.e., have no applications deployed). Each of these applications comprises one or more application instances, and each application instance comprises one or more threads. Assume there are a total of M threads across these applications, each thread corresponding to (bound to / using) one physical core across the N compute nodes. One physical core can correspond to one or more threads. Different threads of the same application can use physical cores located on the same compute node / socket / CPU die / CPU cluster. All threads of the same application can collectively use one or more physical cores. For ease of description, the physical cores used by all threads of the same application are referred to as the physical cores used by that application. Different threads of the same application can use the same or different physical cores, and the physical cores used by different applications generally do not overlap.

[0048] It should be noted that the quantity and positional relationships of Sockets, CPU Dies, CPU Cores, CPU Clusters, LLCs, etc., in Figure 1 are merely examples and do not constitute a limitation. In practical application scenarios, a computing node may include more Sockets, each Socket may include more or fewer CPU Dies, each CPU Die may include more or fewer CPU Cores, each CPU Core may include more or fewer CPU Clusters, and each CPU Cluster may include more or fewer physical cores. Figure 1 may also include more or fewer application instances (virtual machines, containers, or ordinary processes), and each application instance may have one or more threads. This application does not specifically limit the correspondence between these threads and physical cores.

[0049] Based on the computing cluster described above, the following section introduces a task management method provided in this application.

[0050] Please refer to Figure 4, which is a flowchart of a task management method provided in an embodiment of this application, including the following steps S401 to S404.

[0051] S401, The management node in the computing cluster obtains the first demand of multiple tasks running on the first computing node in the computing cluster for the shared cache in the first computing node. The shared cache in the first computing node is the shared cache corresponding to multiple processing units of the first computing node.

[0052] The first computing node mentioned above can be any or a specific computing node in a computing cluster. The first computing node includes multiple processing units, each with a corresponding shared cache. Different cores within each processing unit can share the shared cache corresponding to that processing unit. The shared caches corresponding to different processing units do not overlap (cache spaces do not overlap), and the size (i.e., capacity / total amount) of the shared caches corresponding to different processing units may be the same or different; this application does not impose specific limitations. The shared cache in the first computing node is the shared cache corresponding to these multiple processing units.

[0053] For example, the processing unit can be the CPU in Figure 2. In this case, the shared cache corresponding to each CPU is the LLC cache space corresponding to each CPU. Each CPU includes multiple cores, which is a multi-core CPU. The LLC cache space corresponding to the multi-core CPU can be shared by all cores of the multi-core CPU. For details, please refer to the previous introduction, which will not be repeated here.

[0054] The aforementioned multiple tasks run on the first computing node. This application does not specifically limit the distribution of these multiple tasks on the first computing node. Each task may also include one or more subtasks, and this application also does not specifically limit the distribution of the subtasks on the first computing node. For example, suppose these multiple tasks are multiple different applications. These applications may run on different processing units on the first computing node, or they may run on the same processing unit, or some applications may run on the same processing unit while others run on different processing units. As another example, suppose these multiple tasks are multiple virtual machines, each virtual machine including multiple threads (i.e., subtasks). Threads from different virtual machines may run on different processing units on the first computing node, or they may run on the same processing unit.

[0055] The aforementioned first demand is the sum of the individual demands of these tasks on the shared cache of the first compute node. The management node obtains this first demand from the shared cache of the first compute node to determine whether it exceeds the capacity of the shared cache on the first compute node, and thus decides whether some tasks need to be migrated from the first compute node to other compute nodes. Optionally, the aforementioned multiple tasks can be actively specified by the user, or the first compute node can automatically use virtual machines and containers running on the first compute node as the aforementioned multiple tasks.

[0056] Each of the aforementioned tasks requires a certain amount of shared cache. The shared cache requirement for each task is related to the task's data locality and data access frequency. Data locality refers to the fact that within a certain period of time, the data accessed by the task tends to be concentrated in a certain region of memory, rather than being scattered throughout the entire memory. This application does not specify the method for determining the shared cache requirement of a task; the following explanation uses methods one, two, and three as examples.

[0057] Method 1: By adjusting the shared cache allocation of the task, observe the trend of the task's performance indicators as the shared cache allocation changes, and then calculate the performance change rate (change gradient) corresponding to different shared cache allocations. The minimum value of the shared cache allocation when the performance change rate is less than or equal to the change rate threshold is taken as the shared cache requirement of the task.

[0058] This application does not specify the method for adjusting the shared cache allocation of a task. For example, the shared cache allocation of a task can be adjusted using Memory System Resource Partitioning and Monitoring (MPAM) technology, and then the performance indicators of the task can be observed to change with the shared cache allocation.

[0059] The aforementioned performance indicators can be throughput, execution time, or other indicators. This application does not impose any restrictions and the appropriate indicators can be selected based on the actual task.

[0060] The aforementioned rate of change threshold can be set as needed, and this application does not impose any specific limitations.

[0061] The performance change rate of a task under a certain shared cache allocation is calculated as follows: (Performance index of the task under the target allocation - Performance index of the task under the current shared cache allocation) ÷ First increment, where the target allocation is the sum of the shared cache allocation and the first increment (i.e., allocating more shared cache). The size of the first increment is not specifically limited in this application and can be set according to actual needs. Besides the calculation method listed here, other methods can be used to calculate the performance change rate of the same task under different shared cache allocations, and this application does not limit these methods.

[0062] For example, Figure 5 is a graph showing the relationship between the performance index of a certain task and the amount of shared cache allocation provided in an embodiment of this application. As the amount of shared cache allocation increases (the further to the right, the larger), the value of the performance index of the task gradually increases. When the amount of shared cache allocation increases to the area indicated by the arrow and the area to its right, the rate of performance change is less than or equal to the rate of change threshold. Therefore, the amount of shared cache allocation indicated by the arrow can be taken as the shared cache requirement of the task.

[0063] Method 2: Estimate the shared cache requirements of a task based on its performance metrics.

[0064] Optionally, the relationship between the task's performance metrics and shared cache requirements can be mathematically modeled in advance. This application does not limit the modeling method or model type. Then, the current performance metrics of the task are input into the model, and the model outputs the shared cache requirements of the task.

[0065] Optionally, performance metrics may include the utilization of the physical core where the task resides, instructions per clock cycle (IPC), shared cache hits, shared cache misses, shared cache miss rate, number of memory channel read / write requests, etc. The shared cache miss rate is calculated as: shared cache miss rate = number of shared cache misses ÷ (number of shared cache hits + number of shared cache misses). These performance metrics can be obtained through the physical core's Performance Monitor Unit (PMU) or other counters; this application does not specifically limit their acquisition. The PMU is a hardware event counter in a compute node used to track and measure various hardware-related events, such as CPU cycles, instructions per clock cycle (IPC), cache hits, cache misses, memory accesses, and interrupts.

[0066] Method 3: Determine the shared cache requirements of tasks based on task priority.

[0067] Optionally, the user can set corresponding priorities for each task on the first compute node, with different priorities corresponding to different shared cache requirements. Then, based on the user-configured priorities, the first compute node can determine the shared cache requirements of each of the multiple tasks running on the first compute node, and thus determine the initial demand of these multiple tasks on the shared cache in the first compute node.

[0068] S402. When the capacity of the shared cache in the first computing node cannot meet the first demand, the management node determines the migration task from multiple tasks and determines the second computing node that can meet the shared cache demand of the migration task.

[0069] Optionally, the management node stores resource and task information reported by each compute node in the compute cluster. The management node can then determine the migration task from among these multiple tasks based on the resource and task information, and identify a second compute node capable of meeting the shared cache requirements of the migration task. In other words, each compute node in the compute cluster can report its resource and task information to the management node. The management node stores this information to determine if there are any compute nodes in the compute cluster that cannot meet the shared cache requirements of all tasks on that compute node, and thus determines which tasks / tasks to migrate from that compute node to other compute nodes to alleviate the competition pressure on the shared cache for tasks on that compute node.

[0070] For example, Figure 6 is an interaction flowchart between a management node and a computing node provided in an embodiment of this application, including steps 1 to 5. It should be noted that, for simplicity, Figure 6 only shows one computing node. In fact, each computing node in the computing system can interact with the management node in the manner shown in Figure 6, that is, each computing node establishes a connection with the management node and sends its own information to the management node.

[0071] Step 1: Initialize the management node.

[0072] Step 2: The compute node sends initial resource information to the management node.

[0073] Specifically, a management node is first designated in the computing cluster. This can be a specific computing node in the computing system, and the management node's functions are configured on that node, thus completing its initialization. Alternatively, multiple computing nodes or other devices besides computing nodes can be configured as management nodes; this application does not impose specific limitations on this. Then, each computing node reports its initial resource information to the management node. This initial resource information may include the specifications of the processing units within the computing node (such as the number of CPU cores, frequency, shared cache capacity, etc.) and the total amount of memory.

[0074] Step 3: The management node stores the initial resource information of the compute nodes.

[0075] Step 4: The compute nodes send resource information and application information to the management node.

[0076] This application does not specify the timing for compute nodes to report resource and task information to the management node. For example, each compute node can periodically report its own resource and task information to the management node. The resource and task information can be reported together or separately, and the reporting period can be set according to usage requirements. This application does not specify the timing.

[0077] Step 5: The management node stores the resource information and application information of the computing nodes.

[0078] The management node stores resource and application information for each compute node to determine whether task migration is needed between nodes and how to perform the migration. Resource information may include the capacity and remaining space of shared cache in the compute node, etc., while task information may include the shared cache requirements of the task, memory usage (i.e., the amount of data stored in memory by the task), etc., which are not specifically limited in this application.

[0079] Optionally, the first compute node can determine whether the usage of its shared cache has reached a waterline threshold. If it does, the first compute node sends an alarm to the management node. The waterline threshold can be set according to usage needs, and this application does not impose specific limitations. Then, the management node determines, based on the alarm information, that the capacity of the shared cache in the first compute node cannot meet the first demand. The alarm information may carry the first demand of multiple tasks in the first compute node, and the management node determines that the capacity of the shared cache in the first compute node cannot meet the first demand based on the first demand in the alarm information and the capacity of the shared cache in the first compute node.

[0080] In practice, for any compute node in the computing cluster, the management node can determine whether the capacity of the shared cache on that compute node meets (is greater than or equal to) the total shared cache requirement of the tasks on that compute node based on the shared cache requirements reported by that compute node. If the total requirement is met, it is determined that there is no conflict in the shared cache requirements of the tasks on that compute node (the contention is not severe), and there is no need to migrate the tasks off that compute node. The management node can also determine the remaining capacity of the shared cache on that compute node as the difference between the capacity of the shared cache on that compute node and the total requirement.

[0081] If the shared cache capacity of a compute node is insufficient to meet the total demand, it indicates a conflict (severe contention) in the shared cache requirements of tasks on that compute node. Each task frequently encroaches on the shared cache space already used by other tasks, leading to data eviction from the shared cache and frequent data loading from memory. This increases memory access latency and reduces task processing speed. In this case, it is necessary to migrate some tasks from that compute node to other compute nodes to alleviate the contention for shared cache on that current compute node.

[0082] Since the capacity of the shared cache in the first computing node does not meet the total demand of the multiple tasks on the first computing node (i.e., the first demand described above), the management node determines that the competition pressure of the tasks on the first computing node on the shared cache is too great, and it is necessary to migrate some tasks out of the first computing node. There are several possible ways to achieve this.

[0083] In the first possible implementation, the management node can first determine which tasks / tasks from the first compute node need to be migrated out. These tasks are denoted as migration tasks, and there may be one or more migration tasks. Each migration task has corresponding shared cache requirements. Then, the management node determines which compute nodes / tasks each task needs to be migrated to. The total requirement of the migration tasks can be greater than or equal to the difference between the initial requirement (i.e., the total shared cache requirement of multiple tasks on the first compute node) and the capacity of the shared cache in the first compute node. In other words, after all migration tasks have been migrated out of the first compute node, the capacity of the shared cache in the first compute node can meet the total shared cache requirement of the remaining tasks on the first compute node.

[0084] This application does not provide specific information regarding the method for determining migration tasks. For example, one could first calculate the difference between the initial demand and the capacity of the shared cache in the first compute node. Then, one or more tasks from the first compute node whose total shared cache demand is greater than or equal to this difference would be selected as migration tasks. There may be one or more options that satisfy the above requirements. Optionally, one of these options could be randomly selected as a migration task, or the option with the smallest total shared cache demand could be selected as a migration task. Alternatively, the task's memory usage could be considered, and the option with the smallest memory usage could be selected as a migration task. This minimizes the amount of data that needs to be migrated between compute nodes, thereby reducing the cost of task migration between compute nodes.

[0085] Optionally, the above-mentioned scheme for combining task memory usage can be that the management node periodically obtains the amount of data in the memory of multiple tasks running on the first computing node, and then the management node determines the application with the least amount of data in that memory as the migration task.

[0086] After the migration tasks are determined, the management node then selects a compute node from the compute cluster that can meet the shared cache requirements of the migration tasks. This node is designated as the second compute node (different from the first compute node). There may be one or more second compute nodes. When there is only one second compute node, the shared cache space in the second compute node must be greater than or equal to the sum of the shared cache requirements of all migration tasks. In other words, the shared cache of the second compute node must not only meet the shared cache requirements of the existing tasks on the second compute node but also meet the shared cache requirements of all migration tasks. Therefore, all migration tasks can be migrated to this second compute node. When there are multiple second compute nodes, the first compute node acts as the migration-out node, and each second compute node (acting as the migration-in node) must have at least one migration task migrated in. Each second compute node can meet the shared cache requirements of its corresponding migration task.

[0087] Optionally, the management node can periodically obtain the remaining amount of shared cache in the compute nodes of the compute cluster, and then determine the node whose remaining amount of shared cache is greater than the shared cache requirement of the migration task as the second compute node.

[0088] Optionally, the management node periodically obtains the remaining amount of shared cache and memory in the computing nodes of the computing cluster. Then, the management node determines the computing node whose remaining amount of shared cache is greater than the shared cache requirement of the migration task and whose remaining amount of memory is greater than the amount of data occupied by the migration task as the second computing node.

[0089] In the second possible implementation, the management node determines only one migration task and a second computing node capable of meeting the shared cache requirements of that migration task from among the multiple tasks on the first computing node at a time. The migration task can be selected randomly, based on the minimum memory usage, or according to other principles (this application does not impose specific limitations). The management node then instructs the first computing node to migrate the task to the corresponding second computing node. This process is repeated until the shared cache capacity of the first computing node is sufficient to meet the total shared cache requirements of the remaining tasks on the first computing node, or until there are no computing nodes in the computing cluster capable of meeting the shared cache requirements of any task on the first computing node. In other words, the shared cache capacity of each computing node is insufficient, and no computing node can support the first computing node in migrating any task.

[0090] In the third possible implementation, the first compute node not only migrates some tasks from its own node to the second compute node, but also receives tasks from other compute nodes (denoted as the third compute node). That is, the first compute node not only migrates out some tasks but also migrates in others. For ease of description, tasks migrated from the first compute node to the second compute node are called migration-out tasks, and tasks migrated from the third compute node to the first compute node are called migration-in tasks. There may be one or more migration-out tasks, and one or more migration-in tasks. There may be one or more second compute nodes, and one or more third compute nodes. Migration-in tasks may come from one or more third compute nodes. To ensure that the capacity of the shared cache in the first compute node can meet the total shared cache requirements of all tasks on the first compute node after the migration, the following condition must be met: (Sum of shared cache requirements of all migration-out tasks - Sum of shared cache requirements of all migration-in tasks) ≥ (First requirement - Capacity of shared cache in the first compute node). This application does not specifically limit the determination of migration-out and migration-in tasks, as long as the above condition is met.

[0091] Optionally, the third computing node and the second computing node mentioned above may be the same computing node or different computing nodes.

[0092] It should be noted that the three possible implementations described above are merely examples and do not constitute a limitation. In practical applications, other methods can be used to determine the migration task and the corresponding second compute node, as long as they can alleviate the contention for the shared cache by tasks on the first compute node.

[0093] S403, The management node sends the migration task information and the information of the second computing node to the first computing node.

[0094] This application does not specifically limit the information regarding the migration task; for example, it may be a process identifier (PID). Similarly, this application does not specifically limit the information regarding the second computing node; for example, it may be the access address of the second computing node (such as an Internet Protocol (IP) address) or the name of the second computing node.

[0095] S404. The first computing node migrates the migration task to the second computing node based on the migration task information and the second computing node information.

[0096] Optionally, the first and second compute nodes can be connected via a high-speed interconnect bus. When the first compute node receives migration task information and information about the second compute node from the management node, it can initiate communication with the second compute node based on the second compute node's IP address, thus establishing a connection. The first compute node then saves the current working state of the migration task and transmits the migration task's working state information and its data in memory to the second compute node via the bus. The second compute node selects an appropriate physical core to run the migration task, stores the migration task data in its memory, and then restores the migration task to its previously saved working state based on the working state information.

[0097] For example, Figure 7 is a schematic diagram of task migration between a first computing node and a second computing node according to an embodiment of this application. The first computing node includes a first CPU (corresponding to the processing unit described above) and a second CPU. Each CPU has 8 physical cores and a corresponding LLC space (corresponding to the shared cache described above). The LLC space of each CPU has a capacity of 512MB, so the LLC space capacity in the first computing node is 512×2=1024MB. Before the migration between nodes, four tasks, application A, application B, application C, and application D, are running on the first computing node. These applications all run on 4 physical cores (applications and physical cores within the same dashed box have a corresponding relationship). The first computing node can determine the LLC space requirements of each application (corresponding to the shared cache requirements described above) according to the method described above, and then report the LLC space requirements of these applications to the management node.

[0098] Based on the information reported by the first compute node, the management node determines that the sum of the LLC space requirements of the four applications on the first compute node is 1200MB. Since 1200MB is greater than the LLC space capacity of 1024MB on the first compute node, the management node determines that there is a conflict in the LLC space requirements of the applications on the first compute node, and it is necessary to migrate some applications away from the first compute node to alleviate the contention pressure on the shared cache. Assuming the management node identifies application B as the migration task and determines that the second compute node can meet the LLC space requirements of application B, the management node sends information about application B and the second compute node to the first compute node, instructing the first compute node to migrate application B to the second compute node.

[0099] The first compute node initiates communication and establishes a connection with the second compute node based on information from application B and the second compute node. Then, the first compute node migrates the data of application B stored in the memory of the first compute node to the second compute node via the bus between the two nodes, and sends the working status information of all threads of application B to the second compute node. The second compute node places the data of application B into its own memory, selects some physical cores to rerun the threads of application B, and restores the threads of application B to their previous working state based on the aforementioned working status information, thus completing the migration of application B. This application does not specify how the second compute node selects the physical cores to run application B; for example, it can select idle physical cores, distribute the threads of application B across different physical cores, or distribute the threads of application B within the same CPU. After the migration is complete, only application A, application C, and application D remain on the first compute node, with a total shared cache requirement of 900MB. At this point, the LLC capacity of 1024MB in the first compute node can meet the needs of these three applications.

[0100] Please refer to Figure 8, which is a flowchart of another task management method provided in the embodiment of this application, including the following steps S801 to S803.

[0101] S801, the first computing node obtains the second demand of multiple subtasks running by multiple cores in the first processing unit of the first computing node for the first shared cache. These multiple subtasks belong to at least one of the multiple tasks, and the first shared cache is the shared cache corresponding to the first processing unit.

[0102] For details on the first computing node and multiple tasks, please refer to Figure 4. They will not be elaborated here.

[0103] The aforementioned first processing unit can be any or a specific processing unit within the first computing node. The shared cache corresponding to the first processing unit in the first computing node is the first shared cache (which is a part of all shared caches in the first computing node). Multiple cores within the first processing unit can share this first shared cache. These multiple cores run multiple subtasks, and these multiple subtasks belong to at least one subtask among multiple tasks running in the first computing node.

[0104] The aforementioned second demand is the total demand of multiple subtasks on the first shared cache. The first compute node obtains the second demand to determine whether it exceeds the capacity of the first shared cache. This application does not specifically limit the method for determining the shared cache demand of subtasks; reference can be made to methods one, two, and three in step S401 for determining the shared cache demand of tasks. For example, the first compute node obtains the performance metrics of these multiple subtasks, and then determines the aforementioned second demand based on these performance metrics.

[0105] Optionally, the first computing node can periodically acquire the shared cache requirements of the subtasks running in each processing unit within the first computing node, in order to determine whether there are processing units in the first computing node that cannot meet the shared cache requirements of the corresponding subtasks. This application does not specifically limit the acquisition period; it can be set according to usage needs.

[0106] S802. When the capacity of the first shared cache cannot meet the second demand, the first computing node determines the subtask to be moved out from multiple subtasks and the second processing unit in the first computing node that can meet the shared cache demand of the subtask to be moved out.

[0107] When the capacity of the first shared cache cannot meet the second demand, it indicates that the multiple subtasks running on the first processing unit have conflicting demands on the first shared cache (severe contention). Each subtask frequently encroaches on the cache space used by other subtasks in the first shared cache, causing data stored in the first shared cache to be evicted. This necessitates frequent loading of corresponding data from memory, thereby increasing memory access latency and reducing the execution speed of the subtasks. In this case, it is necessary to migrate some subtasks from the first processing unit to other processing units to alleviate the contention pressure on the first shared cache from the subtasks running in the first processing unit.

[0108] In the first possible implementation, the first computing node can first determine which / which subtasks in the first processing unit need to be migrated out. These subtasks are denoted as migrated-out subtasks. There may be one or more migrated-out subtasks, each with corresponding shared cache requirements. Then, it determines which / which processing units the migrated-out subtasks should be migrated to. The total requirement of the migrated-out subtasks can be greater than or equal to the difference between the second requirement (i.e., the total shared cache requirement of multiple subtasks in the first processing unit) and the capacity of the shared cache in the first processing unit. In other words, after all migrated-out subtasks have been migrated out of the first processing unit, the capacity of the shared cache in the first processing unit can meet the total shared cache requirement of the remaining subtasks in the first processing unit.

[0109] This application does not provide specific information regarding the method for determining the move-out subtasks. For example, one could first calculate the difference between the second demand and the capacity of the shared cache in the first processing unit, and then select one or more subtasks from the first processing unit whose total shared cache demand is greater than or equal to this difference. These selected subtasks are all move-out subtasks. There may be one or more selection schemes that satisfy the above requirements. Optionally, one could randomly select a subtask corresponding to one of these one or more selection schemes as the move-out subtask, or select a subtask corresponding to the scheme with the smallest total shared cache demand as the move-out subtask, or select a suitable move-out subtask according to the principle of placing subtasks of the same task in the same processing unit as much as possible, or select a subtask that requires switching physical cores as little as possible, and so on.

[0110] After determining the outgoing subtasks, the first computing node then identifies a processing unit (different from the first processing unit) that can satisfy the shared cache requirements of the outgoing subtasks. This second processing unit may have one or more second processing units. When there is only one second processing unit, the remaining space in its shared cache must be greater than or equal to the sum of the shared cache requirements of all outgoing subtasks. In other words, the shared cache of the second processing unit must not only satisfy the shared cache requirements of the existing subtasks on that unit but also the shared cache requirements of all outgoing subtasks. Therefore, all outgoing subtasks can be migrated to this second processing unit. When there are multiple second processing units, the first processing unit acts as the outgoing unit, and each second processing unit (acting as the incoming unit) migrates in at least one outgoing subtask. The remaining space in each second processing unit is sufficient to satisfy the shared cache requirements of the corresponding outgoing subtask.

[0111] In the second possible implementation, the first computing node determines only one outgoing subtask and a second processing unit capable of meeting the shared cache requirements of that outgoing subtask from among the multiple subtasks of the first processing unit at a time. The outgoing subtask can be selected randomly, by ensuring all subtasks of the same task are on the same processing unit, or by other principles (this application does not specifically limit this selection). Then, the first computing node migrates the outgoing subtask from the first processing unit to the corresponding second processing unit. This process is repeated until the shared cache capacity of the first processing unit can meet the total shared cache requirements of the remaining subtasks on the first processing unit, or until there are no other processing units on the first computing node capable of meeting the shared cache requirements of any subtask on the first processing unit. In other words, the shared cache capacity of other processing units is insufficient, and no processing unit can support the first processing unit in migrating any subtask over.

[0112] For example, Figure 9 is a schematic diagram of thread migration between different CPUs within the same computing node provided by an embodiment of this application. The hardware of the first computing node in the figure includes a first CPU (corresponding to the processing unit described above), a second CPU, and a corresponding LLC (corresponding to the shared cache described above) for each CPU. Each CPU includes 8 physical cores, and the LLC capacity of each CPU is 320MB. Therefore, the total LLC space in the first computing node is 320×2=640MB.

[0113] Before the intra-node migration, the first compute node ran three tasks: Application A, Application B, and Application C. Each application included four threads (i.e., subtasks). The four threads of Application A corresponded one-to-one with the four physical cores of the first CPU (applications within the same dashed box corresponded to physical cores). The four threads of Application B corresponded one-to-one with the other four physical cores of the first CPU, and the four threads of Application C corresponded one-to-one with the four physical cores of the second CPU. The first compute node could determine the LLC requirement (i.e., shared cache requirement) of each thread according to the method described above, and then use the sum of the LLC requirements of all threads of the same application as the LLC requirement of that application.

[0114] Assume that application C running on the second CPU has an LLC requirement of only 100MB, and the LLC capacity of the second CPU is 320MB. Therefore, the LLC capacity of the second CPU can meet the LLC requirement of application C, and the LLC margin of the second CPU = 320 - 100 = 220MB. Assume that applications A and B running on the first CPU each have an LLC requirement of 200MB, and the LLC capacity of the first CPU is 320MB. Therefore, the LLC capacity of the first CPU cannot meet the LLC requirements of all threads of applications A and B (200 + 200 = 400MB). There is an LLC requirement conflict between the threads of applications A and B on the first CPU. Frequent competition between threads within the first CPU for the LLC space corresponding to the first CPU leads to poor overall performance of applications A and B. It is necessary to migrate some threads from the first CPU to alleviate LLC contention within the first CPU.

[0115] Because the second CPU has ample LLC capacity, the first compute node determines that some threads from the first CPU can be transferred to the second CPU to alleviate LLC demand conflicts on the first CPU. This application does not specify how to determine which threads need to be transferred; please refer to the previous section. The principle here is to place threads of the same application on the same CPU as much as possible. First, it is determined whether the LLC capacity of the second CPU meets the needs of application A or application B: if so, all threads of application A or application B can be migrated to the second CPU as outgoing subtasks; if not, some threads from application A and / or some threads from application B are selected as migration subtasks to migrate to the second CPU. Here, the LLC capacity of the second CPU (220MB) can meet the LLC requirements of application A or application B (200MB), so application A or application B can be migrated to the second CPU. Assuming application B is selected, the first compute node will transfer all threads of application B as outgoing subtasks from the physical cores of the first CPU to the physical cores of the second CPU.

[0116] As shown in Figure 9, after the migration within the node is completed, only application A is running on the first CPU. At this time, the LLC capacity of the first CPU can meet the LLC requirements of all threads of application A, thereby improving the data hit rate of application A in the LLC and helping to improve the performance of application A. The second CPU not only runs the original application C, but also the migrated application B. The four threads of application C correspond one-to-one with the four physical cores of the second CPU, and the four threads of application B correspond one-to-one with the other four physical cores of the second CPU. At this time, the LLC capacity of the second CPU can meet the sum of the LLC requirements of all threads of application B and application C. Compared with before the migration, the performance of application B is improved.

[0117] After migrating application B from the first CPU to the second CPU, affinity adjustments can be made to resources such as memory and input / output (I / O) within the compute node. For example, the operating system of the second compute node can prioritize allocating memory space closer to the physical core currently running application B, which helps improve application B's memory access speed and reduce memory access latency. Furthermore, application B's I / O requests can be routed to the I / O device closest to the physical core currently running application B, thereby reducing application B's I / O operation latency and improving data transfer efficiency.

[0118] It should be noted that the number of applications, CPUs, physical cores, and LLC capacity in Figure 9 are merely examples and do not constitute limitations. In practical applications, the first CPU may include more CPUs, each CPU may include more or fewer physical cores, and the LLC capacity of each CPU may have other values. To resolve LLC demand conflicts in the first CPU, besides migrating all threads of application B to the second CPU, one can also choose to migrate all threads of application A to the second CPU (without migrating application B to the second CPU), or migrate only some threads of application B to the second CPU, as long as the LLC demand of the threads on both the first and second CPUs can be satisfied after the migration, and there are no LLC demand conflicts on either the first or second CPU.

[0119] In the third possible implementation, the first processing unit not only migrates some subtasks from its own processing unit to the second processing unit as outgoing subtasks, but also receives subtasks from other processing units (denoted as the third processing unit). That is, the first processing unit not only migrates some subtasks out, but also migrates in some subtasks. For ease of description, the subtasks migrated from the first processing unit to the second processing unit are called outgoing subtasks, and the subtasks migrated from the third processing unit to the first processing unit are called incoming subtasks. There may be one or more outgoing subtasks, one or more incoming subtasks, one or more second processing units, and one or more third processing units. Optionally, the second and third processing units can be the same or different.

[0120] To ensure that the shared cache capacity in the first processing unit is sufficient to meet the total shared cache requirements of the remaining subtasks on the first processing unit after the migration is completed, the following condition must be met: (Sum of shared cache requirements of all migrated-out subtasks - Sum of shared cache requirements of all migrated-in subtasks) ≥ (Second requirement - Capacity of shared cache in the first processing unit). This application does not specify the exact method for determining the migrated-out and migrated-in subtasks.

[0121] For example, the first computing node determines from its other processing units a processing unit that includes the migrated-in subtask (which may or may not be the second processing unit), wherein the difference between the shared cache requirement of the migrated-out subtask and the shared cache requirement of the migrated-in subtask is greater than or equal to the difference between the second requirement and the capacity of the first shared cache. Then, the first computing node migrates the migrated-out subtask to the second processing unit and migrates the migrated-in subtask to the first processing unit.

[0122] It should be noted that the three possible implementations mentioned above are merely examples and do not constitute specific limitations. In practical applications, other methods can be used to determine the outgoing subtasks and the second processing unit, as long as they can alleviate the contention for the shared cache by the subtasks on the first processing unit and meet the shared cache requirements of the corresponding subtasks.

[0123] For example, Figure 10 is a schematic diagram of another thread migration between different CPUs within the same computing node provided by an embodiment of this application. The hardware of the first computing node in the figure includes a first CPU (corresponding to the processing unit described above), a second CPU, and a corresponding LLC (corresponding to the shared cache described above) for each CPU. Each CPU includes 8 physical cores, and the LLC capacity of each CPU is 512MB. Therefore, the LLC capacity in the first computing node is 512×2=1024MB.

[0124] Before the intra-node migration, the first compute node ran four tasks: Application A, Application B, Application C, and Application D. Each application included four threads (i.e., subtasks). The four threads of Application A corresponded one-to-one with the four physical cores of the first CPU (applications within the same dashed box corresponded to physical cores). The four threads of Application B corresponded one-to-one with the other four physical cores of the first CPU. The four threads of Application C corresponded one-to-one with the four physical cores of the second CPU. The four threads of Application D corresponded one-to-one with the other four physical cores of the second CPU. The first compute node could determine the LLC requirement (i.e., shared cache requirement) of each thread according to the method described above, and use the sum of the LLC requirements of all threads of the same application as the LLC requirement of that application.

[0125] Assume that application C running on the second CPU has an LLC requirement of 200MB, and application D also has an LLC requirement of 200MB. The LLC capacity of the second CPU is 512MB. Therefore, the LLC capacity of the second CPU can meet the LLC requirements of all threads of applications C and D, leaving an LLC margin of 112MB. Assume that applications A and B running on the first CPU each have an LLC requirement of 300MB. The LLC capacity of the first CPU is 512MB. Therefore, the LLC capacity of the first CPU cannot meet the sum of the LLC requirements (600MB) of all threads of applications A and B. Consequently, there is an LLC requirement conflict between the threads of applications A and B on the first CPU. Frequent competition for the LLC space corresponding to the first CPU among the threads leads to poor overall performance of applications A and B. It is necessary to migrate some threads from the first CPU to alleviate LLC contention within the first CPU.

[0126] Since the second CPU has ample LLC space, the first compute node determines that some threads from the first CPU can be migrated to the second CPU to alleviate LLC demand conflicts on the first CPU. This application does not specify how to determine which threads need to be migrated; please refer to the preceding description. The principle here is to place threads of the same application on the same CPU as much as possible. First, it is determined whether migrating the application between the first and second CPUs can alleviate LLC conflicts. If not, then migrating some threads from the application can be chosen.

[0127] Since the LLC capacity of the second CPU is insufficient for either application A or application B, migrating only application A or application B to the second CPU would result in an LLC demand conflict on the second CPU. Because the LLC capacity of the first CPU is sufficient to meet the shared cache requirements of application A and application C on the second CPU, and the LLC capacity of the second CPU is sufficient to meet the LLC requirements of applications D and B, all threads of application B (as outgoing subtasks) can be migrated to the second CPU, and all threads of application C (as incoming subtasks) can be migrated to the first CPU. This ensures that there are no LLC demand conflicts between the first and second CPUs. After the migration within the node is completed, affinity adjustments can be made to resources such as memory and I / O, as described above; these will not be elaborated upon here.

[0128] S803, the first computing node migrates the outgoing subtask to the second processing unit.

[0129] Specifically, once the first computing node identifies a checkout subtask from among multiple subtasks in the first CPU and determines a second processing unit capable of meeting the shared cache requirements of the checkout subtask, the first computing node migrates the checkout subtask to the second processing unit. This application does not specifically limit the physical core corresponding to the checkout subtask in the second processing unit.

[0130] It should be noted that the task management methods in Figures 4 and 8 can be used individually or together, and this application does not impose any limitations on this. The method in Figure 8 can be implemented by the operating system or software module in the first computing node, and this application does not impose any specific limitations on this.

[0131] In summary, in the task management method provided in this application, the management node obtains resource and task information of each computing node in the computing cluster, enabling the management node to have a global understanding of the shared cache usage and task status of the entire computing cluster. Based on this, the management node can identify computing nodes in the computing cluster with shared cache demand conflicts, and then decide how to reasonably migrate tasks between computing nodes to reduce the shared cache contention pressure on computing nodes and try to meet the shared cache needs of each task, thereby improving task execution efficiency and achieving global optimal resource utilization (fully utilizing the shared cache resources in the entire computing cluster).

[0132] In addition to performing task migration between compute nodes according to the instructions of the management node, compute nodes can also analyze the shared cache requirements of subtasks running on each processing unit in the compute node, thereby identifying processing units in the compute node with shared cache requirement conflicts, and then migrating some subtasks in the processing unit to other processing units in the compute node to resolve the shared cache requirement conflicts of the subtasks in the processing unit, and make full use of the shared cache resources in the compute node.

[0133] This application also provides a computing cluster, including a management node and multiple computing nodes, as detailed in Figure 1. This computing cluster is used to execute the operation steps of the task management method shown in Figure 4 or Figure 8.

[0134] Specifically, the management node is used to: obtain the initial demand for shared cache in the first compute node of the computing cluster from multiple tasks running on the first compute node, where the shared cache in the first compute node corresponds to multiple processing units of the first compute node. The management node is also used to: when the capacity of the shared cache in the first compute node cannot meet the initial demand, determine a migration task from among the multiple tasks, and determine a second compute node that can meet the shared cache requirements of the migration task. The management node is also used to: send information about the migration task and the second compute node to the first compute node.

[0135] The first computing node is used to migrate the migration task to the second computing node based on the migration task information and the information of the second computing node.

[0136] Optionally, the management node is also used to: periodically obtain the amount of data in the memory of the first computing node for multiple tasks running in the first computing node; specifically, the management node is used to: determine the task with the least amount of data in the memory of the first computing node as the migration task.

[0137] Optionally, the management node is also used to: periodically obtain the remaining amount of shared cache in the computing nodes of the computing cluster; specifically, the management node is used to: determine the computing node whose remaining amount of shared cache is greater than the shared cache requirement of the migration task as the second computing node.

[0138] Optionally, the management node is also used to: periodically obtain the remaining amount of shared cache and memory in the computing nodes of the computing cluster; specifically, the management node is used to: determine the computing node whose remaining amount of shared cache is greater than the shared cache requirement of the migration task and whose remaining amount of memory is greater than the amount of data occupied by the migration task as the second computing node.

[0139] Optionally, the first computing node is also used to: determine whether the usage of the shared cache in the first computing node has reached the waterline threshold; if it has reached the waterline threshold, send an alarm message to the management node; the management node is also used to: determine, based on the alarm message, that the capacity of the shared cache in the first computing node cannot meet the first demand.

[0140] Optionally, the first computing node is further configured to: obtain the second demand of multiple subtasks running by multiple cores in the first processing unit of the first computing node for the first shared cache, wherein the multiple subtasks belong to at least one of multiple tasks, and the first shared cache is the shared cache corresponding to the first processing unit; when the capacity of the first shared cache cannot meet the second demand, determine the subtask to be moved out from the multiple subtasks and the second processing unit in the first computing node that can meet the shared cache demand of the subtask to be moved out; and migrate the subtask to the second processing unit.

[0141] Optionally, the shared cache requirement of the outgoing subtask is less than or equal to the remaining amount of the shared cache corresponding to the second processing unit, and the shared cache requirement of the outgoing subtask is greater than or equal to the difference between the second requirement and the capacity of the first shared cache.

[0142] Optionally, the first computing node is specifically used to: determine a processing unit including the migrated-in subtask from other processing units of the first computing node, wherein the difference between the shared cache requirement of the migrated-out subtask and the shared cache requirement of the migrated-in subtask is greater than or equal to the difference between the second requirement and the capacity of the first shared cache; migrate the migrated-out subtask to the second processing unit, and migrate the migrated-in subtask to the first processing unit.

[0143] Optionally, the first computing node is specifically used to: obtain the performance indicators of multiple subtasks; and determine the second demand based on the performance indicators of the multiple subtasks.

[0144] The structure of the computing nodes in the computing cluster is illustrated below using Figure 11 as an example.

[0145] Please refer to Figure 11, which is a schematic diagram of a computing node structure provided in an embodiment of this application, including a bus 1102, a processor 1104, a memory 1106, and a communication interface 1108. The processor 1104, the memory 1106, and the communication interface 1108 communicate with each other via the bus 1102. The computing node 1100 can be a server, laptop, tablet, desktop computer, edge device, smartphone, smart screen, etc., and this application does not specifically limit it. This application also does not limit the number and type of processors and memory in the computing node 1100.

[0146] Bus 1102 can be a Peripheral Component Interconnect Express (PCIe) bus, or an Extended Industry Standard Architecture (EISA) bus, a Unified Bus (Ubus or UB), a Compute Express Link (CXL), a Cache Coherent Interconnect for Accelerators (CCIX), etc. Bus 1102 can be divided into address bus, data bus, control bus, etc. In addition to the data bus, bus 1102 can also include a power bus, control bus, and status signal bus. However, for clarity, all buses are labeled as bus 1102 in the diagram.

[0147] The processor 1104 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0148] The memory 1106 may include volatile memory, such as random access memory (RAM). The memory 1106 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0149] The memory 1106 stores executable program code. The processor 1104 executes the executable program code to implement the operation steps involved in the first computing node or the second computing node in the task management method of Figure 4 or Figure 8, respectively.

[0150] The communication interface 1108 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the computing node 1100 and other devices or communication networks.

[0151] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that, when executed on a computing cluster, cause the computing cluster to perform the operation steps in the task management method of Figure 4 or Figure 8. The computing system is described above and will not be repeated here.

[0152] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any available medium. When the computer program product runs on a computing cluster, it causes the computing cluster to perform the operational steps in the task management method of Figure 4 or Figure 8. The computing system is described above and will not be repeated here.

[0153] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of this application.

Claims

1. A task management method, characterized in that, The method includes: The management node in the computing cluster obtains the first demand of multiple tasks running on the first computing node in the computing cluster for the shared cache in the first computing node, wherein the shared cache in the first computing node is the shared cache corresponding to multiple processing units of the first computing node. When the capacity of the shared cache in the first computing node cannot meet the first demand, the management node determines a migration task from the plurality of tasks and determines a second computing node that can meet the shared cache requirements of the migration task. The management node sends the migration task information and the information of the second computing node to the first computing node; The first computing node migrates the migration task to the second computing node based on the information of the migration task and the information of the second computing node.

2. The method according to claim 1, characterized in that, The method further includes: The management node periodically obtains the amount of data in the memory of the first computing node for multiple tasks running in the first computing node; The management node determines the migration task from the plurality of tasks, including: The management node determines the task with the least amount of data in the memory of the first computing node as the migration task.

3. The method according to claim 1 or 2, characterized in that, The method further includes: The management node periodically obtains the remaining amount of the shared cache in the computing nodes of the computing cluster; The management node determines that the second computing node capable of meeting the shared cache requirements of the migration task includes: The management node determines the computing node whose shared cache reserve is greater than the shared cache requirement of the migration task as the second computing node.

4. The method according to claim 1 or 2, characterized in that, The method further includes: The management node periodically obtains the remaining amount of shared cache and memory in the computing nodes of the computing cluster. The management node determines that the second computing node capable of meeting the shared cache requirements of the migration task includes: The management node determines that the computing node whose shared cache reserve is greater than the shared cache requirement of the migration task and whose memory reserve is greater than the amount of data in memory occupied by the migration task is the second computing node.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: The first computing node determines whether the usage of the shared cache in the first computing node has reached the waterline threshold. If it has reached the waterline threshold, it sends an alarm message to the management node. The management node determines, based on the alarm information, that the capacity of the shared cache in the first computing node cannot meet the first requirement.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: The first computing node obtains the second demand of multiple subtasks running by multiple cores in the first processing unit of the first computing node for the first shared cache. The multiple subtasks belong to at least one of the multiple tasks, and the first shared cache is the shared cache corresponding to the first processing unit. When the capacity of the first shared cache cannot meet the second demand, the first computing node determines the subtask to be moved out from the plurality of subtasks and the second processing unit in the first computing node that can meet the shared cache demand of the subtask to be moved out. The first computing node migrates the migrated subtask to the second processing unit.

7. The method according to claim 6, characterized in that, The shared cache requirement of the outgoing subtask is less than or equal to the remaining amount of the shared cache corresponding to the second processing unit, and the shared cache requirement of the outgoing subtask is greater than or equal to the difference between the second requirement and the capacity of the first shared cache.

8. The method according to claim 6, characterized in that, The first computing node determines a second processing unit within the first computing node that can meet the shared cache requirements of the migrated subtask, including: The first computing node determines a processing unit that includes a migrated subtask from its other processing units, wherein the difference between the shared cache requirement of the migrated subtask and the shared cache requirement of the migrated subtask is greater than or equal to the difference between the second requirement and the capacity of the first shared cache. The first computing node migrates the outgoing subtask to the second processing unit, including: The first computing node migrates the outgoing subtask to the second processing unit and the incoming subtask to the first processing unit.

9. The method according to any one of claims 6 to 8, characterized in that, The first computing node obtains the second demand of multiple subtasks running by multiple cores in the first processing unit of the first computing node for the first shared cache, including: The first computing node obtains the performance metrics of the multiple subtasks; The first computing node determines the second requirement based on the performance metrics of the multiple subtasks.

10. A computing cluster, characterized in that, Includes a management node and multiple computing nodes. The management node is used to: obtain the first demand of multiple tasks running on the first computing node in the computing cluster for the shared cache in the first computing node, wherein the shared cache in the first computing node is the shared cache corresponding to multiple processing units of the first computing node; The management node is further configured to: when the capacity of the shared cache in the first computing node cannot meet the first demand, determine a migration task from the plurality of tasks, and determine a second computing node that can meet the shared cache requirements of the migration task; The management node is also configured to: send information about the migration task and information about the second computing node to the first computing node; The first computing node is used to migrate the migration task to the second computing node based on the information of the migration task and the information of the second computing node.

11. The computing cluster according to claim 10, characterized in that, The management node is also used to: periodically obtain the amount of data in the memory of the first computing node for multiple tasks running in the first computing node; The management node is specifically used to: determine the task with the least amount of data in the memory of the first computing node as the migration task.

12. The computing cluster according to claim 10 or 11, characterized in that, The management node is also used to: periodically obtain the remaining amount of shared cache in the computing nodes of the computing cluster; The management node is specifically used to: determine the computing node whose remaining shared cache is greater than the shared cache requirement of the migration task as the second computing node.

13. The computing cluster according to claim 10 or 11, characterized in that, The management node is also used to: periodically obtain the remaining amount of shared cache and memory in the computing nodes of the computing cluster; The management node is specifically used to: determine the computing node whose remaining shared cache is greater than the shared cache requirement of the migration task and whose remaining memory is greater than the amount of data in the memory occupied by the migration task as the second computing node.

14. The computing cluster according to any one of claims 10 to 13, characterized in that, The first computing node is further configured to: determine whether the usage of the shared cache in the first computing node has reached the waterline threshold; if it has reached the waterline threshold, send an alarm message to the management node. The management node is also used to: determine, based on the alarm information, that the capacity of the shared cache in the first computing node cannot meet the first demand.

15. The computing cluster according to any one of claims 10 to 14, characterized in that, The first computing node is also used for: The second demand of multiple subtasks running by multiple cores in the first processing unit of the first computing node on the first shared cache is obtained, wherein the multiple subtasks belong to at least one of the multiple tasks, and the first shared cache is the shared cache corresponding to the first processing unit. When the capacity of the first shared cache cannot meet the second demand, a checkout subtask and a second processing unit in the first computing node that can meet the shared cache demand of the checkout subtask are determined from the plurality of subtasks. The migration subtask is then moved to the second processing unit.

16. The computing cluster according to claim 15, characterized in that, The shared cache requirement of the outgoing subtask is less than or equal to the remaining amount of the shared cache corresponding to the second processing unit, and the shared cache requirement of the outgoing subtask is greater than or equal to the difference between the second requirement and the capacity of the first shared cache.

17. The computing cluster according to claim 15, characterized in that, The first computing node is specifically used for: A processing unit including a migrated-in subtask is determined from the other processing units of the first computing node, wherein the difference between the shared cache requirement of the migrated-out subtask and the shared cache requirement of the migrated-in subtask is greater than or equal to the difference between the second requirement and the capacity of the first shared cache. The outgoing subtask is moved to the second processing unit, and the incoming subtask is moved to the first processing unit.

18. The computing cluster according to any one of claims 15 to 17, characterized in that, The first computing node is specifically used for: Obtain the performance metrics of the multiple subtasks; The second requirement is determined based on the performance metrics of the multiple subtasks.

19. A computer-readable storage medium, characterized in that, The system includes instructions that, when executed on a computing cluster, cause the computing cluster to perform the method as described in any one of claims 1-9, wherein the computing system includes a management node and a plurality of computing nodes.

20. A computer program product containing instructions, characterized in that, When the instructions are executed on the computing cluster, the computing cluster performs the method as described in any one of claims 1-9, wherein the computing system includes a management node and a plurality of computing nodes.

Images