Simulator thread management method and device, computer equipment, readable storage medium and program product
By creating an emulator thread pool in the cloud server and unbinding and rebinding the emulator threads to idle physical CPU cores, the problem of emulator threads preempting resources is solved, thereby improving the business performance and resource utilization of the cloud server.
Patent Information
- Application Number
- CN202511805096.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-03
- Publication Date
- 2026-02-24
AI Technical Summary
In traditional cloud servers, simulator threads preempt physical CPU resources, leading to increased virtual CPU task waiting times and impacting business performance.
By acquiring abnormal preemption time, a simulator thread pool that communicates with the scheduling platform is created, and simulator threads are unbound and rebound to idle physical CPU cores to reduce resource contention.
This effectively reduced the time required for cloud server access, improved the performance of cloud servers, and increased resource utilization.
Smart Images
Figure CN121560458A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of cloud computing virtualization technology, and in particular to an emulator thread management method, apparatus, computer device, computer-readable storage medium, and computer program product. Background Technology
[0002] Cloud servers are the core product of cloud service providers, and virtualization technology is the cornerstone of cloud server products. Virtualization technology abstracts and isolates physical resources, enabling multiple virtual environments to run in parallel on the same physical server, thereby achieving resource optimization and flexible management.
[0003] In traditional technology, each cloud host is a set of Quick Emulator (QEMU) threads on the physical computing node (host machine) operating system. QEMU threads can be mainly divided into two parts: Virtual Central Processing Unit (vCPU) thread group and emulator thread group. The vCPU threads provide computing power to the cloud host; the emulator thread group is mainly responsible for device emulation, interrupt handling, storage input / output (I / O) interfaces, hot migration, and other operations, binding the vCPU and emulator threads to the same CPU core set, cpuset.
[0004] However, traditional methods employ Linux's Completely Fair Scheduler (CFS) scheduling policy on physical computing nodes, where multiple threads share CPU time slices. This can lead to emulator threads potentially preempting CPU resources, causing tasks on the vCPU to wait, resulting in steal time and impacting the performance of services within the cloud host (virtual machine). Summary of the Invention
[0005] Therefore, it is necessary to provide a simulator thread management method, apparatus, computer device, computer-readable storage medium, and computer program product that can reduce preemption time and improve the performance of cloud server services, in order to address the above-mentioned technical problems.
[0006] Firstly, this application provides a simulator thread management method applied to a host server, the method comprising:
[0007] In the event that the simulator thread and virtual CPU thread of the first target virtual machine preempt the first physical CPU core on the host server, the abnormal preemption time of the first target virtual machine is obtained and the abnormal preemption time is sent to the scheduling platform; wherein, the scheduling platform is used to determine the creation instruction of the first simulator thread pool based on the abnormal preemption time; the simulator thread and virtual CPU thread of the first target virtual machine are both bound to the first physical CPU core.
[0008] The system receives the creation instruction sent by the scheduling platform; wherein the creation instruction carries a second physical central processing unit core.
[0009] In response to the creation command, a first simulator thread pool is created and bound to the second physical central processing unit core in the host server;
[0010] The simulator thread of the first target virtual machine in the host server is unbound from the first physical CPU core and bound to the second physical CPU core to which the first simulator thread pool is bound.
[0011] In one embodiment, the method further includes:
[0012] Receive the operation instructions for the second target virtual machine sent by the scheduling platform;
[0013] A new asynchronous thread is created, and the third and fourth physical CPU cores of the second target virtual machine are used to detect whether they overlap with the second physical CPU core; wherein, the third physical CPU core is bound to the virtual CPU thread of the second target virtual machine; and the fourth physical CPU core is bound to the emulator thread of the second target virtual machine.
[0014] When at least one of the third physical central processing unit cores and the fourth physical central processing unit cores overlaps with the second physical central processing unit core, the first simulator thread pool is destroyed.
[0015] The operation instructions are responded to by overlapping physical central processing unit cores.
[0016] In one embodiment, the method further includes:
[0017] Receive a first add instruction sent by the scheduling platform, wherein the first add instruction carries a first virtual machine list and a first emulator thread pool identifier to be added;
[0018] In response to the first add instruction, the first virtual machine list is traversed, and the emulator threads of the virtual machines in the first virtual machine list are added to the second emulator thread pool; wherein the second emulator thread pool corresponds to the identifier of the first emulator thread pool to be added.
[0019] In one embodiment, the second simulator thread pool is bound to a fifth physical central processing unit core, and the method further includes:
[0020] Receive a second add instruction sent by the scheduling platform, wherein the second add instruction carries a second virtual machine list and a second emulator thread pool identifier to be added;
[0021] The emulator threads of the virtual machines in the second virtual machine list are added to the third emulator thread pool; wherein, the third emulator thread pool corresponds to the identifier of the second emulator thread pool to be added; the third emulator thread pool is bound to the sixth physical CPU core; the fifth physical CPU core is different from the sixth physical CPU core;
[0022] If the second virtual machine list is the same as the first virtual machine list, and the identifier of the second emulator thread pool to be added is different from the identifier of the first emulator thread pool to be added, the fifth physical CPU core and the sixth physical CPU core are merged, and the merged physical CPU core is bound to the second emulator thread pool and the third emulator thread pool.
[0023] In one embodiment, the method further includes:
[0024] Receive a removal instruction sent by the scheduling platform; wherein the removal instruction carries a third virtual machine list and an identifier of the emulator thread pool to be removed;
[0025] In response to the removal instruction, the eighth physical CPU core bound to the fourth simulator thread is removed from the seventh physical CPU core corresponding to the simulator thread of the virtual machine in the third virtual machine list; wherein, the simulator thread pool identifier to be removed corresponds to the fourth simulator thread.
[0026] In one embodiment, the method further includes:
[0027] Receive update instructions sent by the scheduling platform; wherein, the update instructions carry the identifier of the created simulator thread pool and the ninth physical central processing unit core to be updated;
[0028] The tenth physical central processing unit core is determined based on the already created simulator thread pool identifier;
[0029] In response to the update instruction, the tenth physical central processing unit core is replaced with the ninth physical central processing unit core.
[0030] Secondly, this application also provides an emulator thread management device, the device comprising:
[0031] The acquisition and sending module is used to acquire the abnormal preemption time of the first target virtual machine when the simulator thread and virtual CPU thread of the first target virtual machine preempt the first physical CPU core on the host server, and send the abnormal preemption time to the scheduling platform; wherein, the scheduling platform is used to determine the creation instruction of the first simulator thread pool based on the abnormal preemption time; the simulator thread and virtual CPU thread of the first target virtual machine are both bound to the first physical CPU core.
[0032] A receiving module is used to receive the creation instruction sent by the scheduling platform; wherein the creation instruction carries a second physical central processing unit core;
[0033] A creation module is configured to, in response to the creation instruction, create a first simulator thread pool bound to the second physical central processing unit core in the host server;
[0034] The unbinding module is used to unbind the simulator thread of the first target virtual machine in the host server from the first physical central processing unit core and bind it to the second physical central processing unit core to which the first simulator thread pool is bound.
[0035] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described method.
[0036] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.
[0037] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method.
[0038] The aforementioned simulator thread management method, apparatus, computer device, computer-readable storage medium, and computer program product, firstly, when the simulator thread and virtual CPU thread of the first target virtual machine preempt the first physical CPU core on the host server, acquire the abnormal preemption time of the first target virtual machine and send the abnormal preemption time to the scheduling platform; wherein, the scheduling platform is used to determine the creation instruction of the first simulator thread pool based on the abnormal preemption time; wherein, both the simulator thread and the virtual CPU thread of the first target virtual machine are bound to the first physical CPU core; and the scheduling platform creates the thread pool based on the algorithm logic output according to the abnormal preemption time. The system first receives a creation instruction from the scheduling platform, which carries a second physical central processing unit (CPU) core. In response to the creation instruction, it creates a first simulator thread pool bound to the second CPU core in the host server. Finally, it unbinds the simulator thread of the first target virtual machine in the host server from the first CPU core and binds it to the second CPU core bound to the first simulator thread pool. By separating the emulator thread from the cores bound to the vCPU threads (all bound to the first CPU core), resource contention is avoided, allowing the emulator thread to run in isolation from the vCPU thread, reducing steal time, and thus improving the performance of the cloud host. Attached Figure Description
[0039] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0040] Figure 1 This is a diagram illustrating the application environment of a simulator thread management method in one embodiment.
[0041] Figure 2 This is a flowchart illustrating a simulator thread management method in one embodiment;
[0042] Figure 3 This is a schematic diagram of the runtime architecture of the simulator thread management method in one embodiment;
[0043] Figure 4 This is a schematic diagram illustrating the creation of a simulator thread pool in one embodiment;
[0044] Figure 5 This is a schematic diagram of the operation instruction processing flow for a virtual machine in one embodiment;
[0045] Figure 6 This is a schematic diagram of the cloud host creation process in one embodiment;
[0046] Figure 7 This is a schematic diagram illustrating the addition of a simulator thread pool in one embodiment;
[0047] Figure 8 This is a schematic diagram illustrating the removal of the emulator thread pool in one embodiment;
[0048] Figure 9 This is a schematic diagram illustrating the updating of the simulator thread pool in one embodiment;
[0049] Figure 10 This is a schematic diagram illustrating the destruction of the simulator thread pool in one embodiment;
[0050] Figure 11 This is a structural block diagram of a simulator thread management device in one embodiment;
[0051] Figure 12 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation
[0052] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0053] The simulator thread management method provided in this application embodiment can be applied to, for example, Figure 1 In the application environment shown, the host server 102 communicates with the scheduling platform 104 via a network. When the emulator thread and virtual CPU thread of the first target virtual machine preempt the first physical CPU core on the host server, the host server 102 obtains the abnormal preemption time of the first target virtual machine and sends it to the scheduling platform. The scheduling platform determines the creation instruction for the first emulator thread pool based on the abnormal preemption time. Both the emulator thread and virtual CPU thread of the first target virtual machine are bound to the first physical CPU core. The host server 102 receives the creation instruction sent by the scheduling platform, which carries a second physical CPU core. In response to the creation instruction, the host server creates a first emulator thread pool bound to the second physical CPU core on the host server. The host server unbinds the emulator thread of the first target virtual machine from the first physical CPU core and binds it to the second physical CPU core bound to the first emulator thread pool.
[0054] In one exemplary embodiment, such as Figure 2 As shown, a method for managing emulator threads is provided, which can be applied to... Figure 1 Taking the host server as an example, the explanation includes the following steps S202 to S208. Wherein:
[0055] Step S202: If the simulator thread and virtual CPU thread of the first target virtual machine preempt the first physical CPU core on the host server, obtain the abnormal preemption time of the first target virtual machine and send the abnormal preemption time to the scheduling platform.
[0056] The scheduling platform is used to determine the creation instruction for the first emulator thread pool based on the abnormal preemption time. Both the emulator thread and the virtual CPU thread of the first target virtual machine are bound to the first physical CPU core.
[0057] The hardware modeler QEMU runs virtual machines by simulating hardware in software. QEMU translates the instructions of the virtual machine into instructions that can be executed by the host machine, thus realizing the hardware simulation function.
[0058] Optionally, such as Figure 3 As shown, the compute node, also known as the host server, includes a monitoring and acquisition module, a scheduling platform agent (nova-compute agent), a virtual machine management component (Libvirt), and a hardware emulator (QEMU) process. The scheduling platform agent includes emulator thread pool operation sets and cloud host operation sets. The scheduling platform includes databases such as Prometheus, a first sub-scheduling platform, and a second sub-scheduling platform. The virtual machine management component (Libvirt) provides a unified management interface for different virtualization technologies. Its functions include virtual machine creation, startup, shutdown, migration, and the configuration and management of storage and network resources. Preemption time, or CPU stealtime, is an important performance indicator in a virtualization environment, reflecting the time a virtual machine spends waiting for physical CPU resources. By monitoring and optimizing stealtime, virtual machine performance and resource utilization can be improved.
[0059] Furthermore, for example, the first target virtual machine, such as virtual machine vm1, runs on the host server, with its vCPU and emulator cores both bound to 10-11. vm1 internally runs compute-intensive and I / O-intensive tasks, causing preemption between the emulator and vCPU, resulting in vCPU steal time > 0. The host server, through its monitoring and acquisition module, reports the CPU utilization of vm1 and the preemption time (vCPU) steal time to the Prometheus database at regular intervals; the steal time includes abnormal preemption times. The first sub-scheduling platform integrates an adaptive virtualization thread dynamic scheduling algorithm, while the compute node resource inventory is uniformly managed by the second sub-scheduling platform, such as the nova-compute scheduling platform. The adaptive virtualization thread dynamic scheduling algorithm of the first sub-scheduling platform periodically obtains monitoring data such as CPU utilization and virtual CPU steal time from the Prometheus database. If the algorithm determines that the emulator pool needs to be operated, the adaptive algorithm module of the first sub-scheduling platform periodically reads the virtual machine steal time from the Prometheus database as input to the algorithm model. If the algorithm detects that the steal time of vm1 is greater than 0, it needs to be eliminated. The system obtains CPU inventory information from the second sub-scheduling platform and, based on certain algorithmic logic, uses temporarily idle physical CPU cores such as 0-4 and 7 to create an emulator pool. It then outputs the emulator pool operation strategy, such as instructions to create the emulator pool using idle physical CPU cores like 0-4 and 7, and sends these instructions to the second sub-scheduling platform for execution. The second sub-scheduling platform then sends the creation instructions through the nova-compute agent in the host server's scheduling platform. The nova-compute agent then sends the creation instructions to Libvirt. The host server executes the emulator pool creation interface through Libvirt to execute the creation instructions.
[0060] Several new interfaces have been added to Libvirt for the scheduling layer to manage the emulator pool, thereby implementing a mechanism to introduce a CPU pool in Libvirt for batch management of the thread affinity of QEMU virtual machines.
[0061] Step S204: Receive the creation instruction sent by the scheduling platform.
[0062] The creation instruction carries a second physical CPU core. The second physical CPU core is an available, idle CPU core other than the first physical CPU core. For example, if the first CPU core is identified as 10-11, then the second CPU core can be identified as 0-4 or 7.
[0063] Optionally, the host server receives the creation instructions sent by the scheduling platform through the scheduling platform agent nova-compute agent.
[0064] Step S206: In response to the creation instruction, a first simulator thread pool is created that is bound to the second physical central processing unit core in the host server.
[0065] Optionally, the host server translates the emulator pool creation command into a Libvirt interface call, namely virNodeSetEmulatorPool(), through a scheduling platform proxy, such as... Figure 4 As shown, the `cpumap` represents the CPU cores used by the emulator pool. In the `cpumap=(1, 1, 1, 1, 1, 0, 0, 1)` diagram, the elements corresponding to indices 0-4 and 7 are 1, indicating that the current emulator pool will use CPUs 0-4 and 7. `index=0` represents the emulator pool ID; Libvirt supports creating multiple emulator pools. `create=True` indicates a new emulator pool. After a successful API call, Libvirt maintains a new emulator pool data structure with a status of "running," signifying successful emulator pool creation.
[0066] Step S208: Unbind the simulator thread of the first target virtual machine in the host server from the first physical central processing unit core and bind it to the second physical central processing unit core to which the first simulator thread pool is bound.
[0067] Among them, there is at least one second physical central processing unit core.
[0068] Optionally, the host server unbinds the emulator thread of the first target virtual machine in the host server from the first physical CPU core identifier, such as 10-11, and binds it to the second physical CPU core, such as 0-4 or 7, which is bound to the first emulator thread pool with Index=0.
[0069] In the aforementioned simulator thread management method, firstly, when the simulator thread and virtual CPU thread of the first target virtual machine preempt the first physical CPU core on the host server, the abnormal preemption time of the first target virtual machine is obtained and sent to the scheduling platform. The scheduling platform determines the creation instruction for the first simulator thread pool based on the abnormal preemption time. Both the simulator thread and the virtual CPU thread of the first target virtual machine are bound to the first physical CPU core. The scheduling platform outputs the creation instruction based on the algorithm logic according to the abnormal preemption time. Secondly, the creation instruction sent by the scheduling platform is received. This creation instruction carries the second physical CPU core. In response to the creation instruction, a first simulator thread pool bound to the second physical CPU core on the host server is created. Finally, the simulator thread of the first target virtual machine on the host server is unbound from the first physical CPU core and bound to the second physical CPU core bound to the first simulator thread pool. By separating the simulator thread from the core bound to the vCPU thread (both bound to the first physical CPU core), resource contention is avoided, allowing the simulator thread and vCPU thread to run in isolation, reducing preemption time, and thus improving the performance of the cloud host.
[0070] In an exemplary embodiment, the virtual machine operation instruction processing flow is as follows: Figure 5 As shown, steps S502 to S506 are included. Wherein:
[0071] Step S502: Receive the operation instructions for the second target virtual machine sent by the scheduling platform.
[0072] Among them, the operation instructions for the target virtual machine refer to cloud host lifecycle management (specifically, creation, destruction, etc.), hot migration, snapshots, hot reconfiguration, CPU hot plugging and unplugging, etc., which involve the reallocation of computing node CPU resources.
[0073] Optionally, the host server receives operation instructions for the second target virtual machine sent by the scheduling platform, such as operation instructions for the virtual machine identified as vm2.
[0074] It should be noted that virtual machines and cloud hosts refer to the same object in this application; host machines, host servers, and compute nodes refer to the same object in this application.
[0075] Step S504: Create an asynchronous thread and use the asynchronous thread to detect whether the third and fourth physical CPU cores of the second target virtual machine overlap with the second physical CPU core.
[0076] Among them, the third physical CPU core is bound to the virtual CPU thread of the second target virtual machine; the fourth physical CPU core is bound to the simulator thread of the second target virtual machine.
[0077] Because the emulator pool operation set in this application is designed to be independent of the operation instructions of the target virtual machine and is not controlled by the operation instructions of the target virtual machine, a scenario of core binding conflict between the operation instructions of the target virtual machine and the emulator pool may occur.
[0078] In order not to affect the functionality of the existing target virtual machine's operation instructions, this application designs a core binding conflict detection and resolution mechanism, that is, to detect the core binding status in the operation instruction flow of the target virtual machine in real time. If the core binding overlaps with the emulator pool, an asynchronous conflict resolution process is initiated, that is, the conflicting emulator pool is destroyed and the CPU core is released for one scheduling use.
[0079] Furthermore, taking the cloud server creation process as an example, such as... Figure 6 As shown, a core binding detection interface is embedded in the Libvirt virtual machine creation interface. The host server creates an asynchronous thread through the core binding detection interface and executes the specific detection and conflict resolution logic through the asynchronous thread, without blocking the creation process of the second target virtual machine vm1.
[0080] The second target virtual machine is configured with vCPU, emulator, and IOThread. IOThread is a dedicated thread in QEMU designed to improve disk I / O performance. The vCPU is bound to the third physical CPU core, the emulator is bound to the fourth physical CPU core, and the IOThread is bound to the I / O physical CPU core.
[0081] The host server uses the core binding detection interface to determine whether the third physical CPU core of the vCPU bound core in the second target virtual machine configuration overlaps with the second physical CPU core bound to the existing emulator pool; whether the fourth physical CPU core of the emulator bound core in the second target virtual machine configuration overlaps with the second physical CPU core bound to the existing emulator pool; and whether the IO physical CPU core of the iothread bound core in the second target virtual machine configuration overlaps with the second physical CPU core bound to the existing emulator pool.
[0082] Step S506: When at least one of the third physical CPU core and the fourth physical CPU core overlaps with the second physical CPU core, destroy the first simulator thread pool; respond to operation instructions through the overlapping physical CPU cores.
[0083] Optionally, if at least one of the following occurs: the third physical CPU core of the vCPU-bound core in the second target virtual machine configuration overlaps with the second physical CPU core bound to the existing emulator pool; the fourth physical CPU core of the emulator-bound core in the second target virtual machine configuration overlaps with the second physical CPU core bound to the existing emulator pool; or the IO physical CPU core of the iothread-bound core in the second target virtual machine configuration overlaps with the second physical CPU core bound to the existing emulator pool, then the first emulator thread pool is destroyed, and operation instructions are responded to through the overlapping physical CPU cores.
[0084] Optionally, if none of them overlap with the second physical central processing unit core bound to the existing emulator pool, it indicates that there is no thread conflict in the operation instructions of the second target virtual machine, and the operation instructions of the second target virtual machine can be responded to normally.
[0085] In this embodiment, an automatic conflict detection and resolution mechanism is introduced to ensure the compatibility of CPU pool and virtual machine operation instructions CPU core binding, and to ensure the robustness of the existing functions of the cloud host.
[0086] In one exemplary embodiment, the simulator thread management method further includes: receiving a change instruction sent by a scheduling platform, and in response to the change instruction, modifying the relationship between simulator threads and physical central processing unit cores. The change instruction may include one or more of an add instruction, a delete instruction, or an update instruction.
[0087] In an exemplary embodiment, the simulator thread management method further includes: receiving a first add instruction sent by a scheduling platform; responding to the first add instruction, traversing a first virtual machine list, and adding the simulator threads of the virtual machines in the first virtual machine list to a second simulator thread pool; wherein the first add instruction carries a first virtual machine list and a first simulator thread pool identifier to be added; and the second simulator thread pool corresponds to the first simulator thread pool identifier to be added.
[0088] The first add instruction refers to the instruction to add a virtual machine.
[0089] Optionally, such as Figure 7As shown, the host server adds the Libvirt interface `virNodeAddDomainToPool()`, which iterates through the first add instruction carrying a list of virtual machines. For example, the first add instruction might include two virtual machines, `uuid1` and `uuid2`. The first add instruction might add these two virtual machines to the first emulator thread pool identifier, such as the emulator pool with index 0, which is the second emulator thread pool with Index=0. The CPU set `cpulist` bound to this pool is 0-4 and 7. The `virNodeAddDomainToPool()` interface modifies the emulator affinity of the two virtual machines from the default configuration to 0-4 and 7, consistent with pool 0. `state: running` indicates normal operation.
[0090] In an exemplary embodiment, the second simulator thread pool is bound to the fifth physical central processing unit (CPU) core. The simulator thread management method further includes: receiving a second add instruction sent by the scheduling platform, adding the simulator threads of the virtual machines in the second virtual machine list to the third simulator thread pool; if the second virtual machine list is the same as the first virtual machine list, and the identifier of the second simulator thread pool to be added is different from the identifier of the first simulator thread pool to be added, merging the fifth physical CPU core and the sixth physical CPU core, and binding the merged physical CPU core to the second simulator thread pool and the third simulator thread pool.
[0091] The second add instruction carries a second list of virtual machines and an identifier for the second emulator thread pool to be added. The second add instruction also refers to adding a virtual machine. The third emulator thread pool corresponds to the identifier of the second emulator thread pool to be added; the third emulator thread pool is bound to the sixth physical CPU core; the fifth physical CPU core is different from the sixth physical CPU core.
[0092] It should be noted that the fifth physical CPU core can be the same as or different from the first, second, third, and fourth physical CPU cores. Similarly, the sixth physical CPU core can be the same as or different from the first, second, third, and fourth physical CPU cores. However, the fifth physical CPU core and the sixth physical CPU core are different. The second emulator thread pool can be the same as or different from the first emulator thread pool; similarly, the third emulator thread pool can be the same as or different from the first emulator thread pool, and the second emulator thread pool and the third emulator thread pool are different.
[0093] Continue as Figure 7As shown, the third emulator thread pool is the emulator thread pool with Index=1. The host server adds the interface virNodeAddDomainToPool() through Libvirt. This interface iterates through the first add instruction, which carries the first list of virtual machines, such as uuid1 and uuid2. The second add instruction, for example, adds the two virtual machines uuid1 and uuid2 to the second emulator thread pool identifier, such as the emulator pool with index 1, which is the third emulator thread pool with Index=1. The cpulist of this pool is 6. virNodeAddDomainToPool() allows virtual machines to be managed by multiple emulator pools. It uses an append strategy to modify the emulator affinity of the two virtual machines from 0-4, 7 to 0-4, 6-7, which is the union of the fifth physical CPU core corresponding to the second emulator thread pool with cpulist Index=0 and the sixth physical CPU core corresponding to the third emulator thread pool with Index=1. The result is that the two virtual machines, uuid1 and uuid2, in the same first and second virtual machine lists are both bound to the second and third emulator thread pools.
[0094] In this embodiment, by adding instructions, the CPU affinity of simulator threads can be managed in batches. CPU affinity refers to the ability to "bind" a program or thread to one or more specific CPU cores to run.
[0095] In an exemplary embodiment, the simulator thread management method further includes: receiving a removal instruction sent by a scheduling platform; and in response to the removal instruction, removing the eighth physical CPU core bound to the fourth simulator thread from the seventh physical CPU core corresponding to the simulator thread of the virtual machine in the third virtual machine list.
[0096] The removal command carries a third list of virtual machines and an identifier for the emulator thread pool to be removed; the removal command is the command to remove a virtual machine. The identifier for the emulator thread pool to be removed corresponds to the fourth emulator thread.
[0097] The third virtual machine list can be the same as or different from the first and second virtual machine lists. The identifier of the emulator thread pool to be removed can be the same as or different from any of the first or second emulator thread pool identifiers. Similarly, the seventh physical CPU core can be the same as or different from any of the first through sixth physical CPU cores. The eighth physical CPU core can be the same as or different from any of the first through sixth physical CPU cores; however, the seventh physical CPU core must include the eighth physical CPU core.
[0098] Optionally, such as Figure 8 As shown, the third virtual machine list includes two virtual machines, uuid1 and uuid2; they are bound to the emulator thread pool with Index=0 and the emulator thread pool with Index=1. The emulator thread pool with Index=0 is bound to physical CPU cores 0-3 and 5; the emulator thread pool with Index=1 is bound to physical CPU core 6. For example, to remove the two virtual machines uuid1 and uuid2 from pool 0, the host server uses the virNodeRemoveDomainFromPool() interface to remove the two virtual machines uuid1 and uuid2 from pool 0. After the interface call is successful, the emulator affinity of the two virtual machines is updated from 0-3 and 5-6 to 6, meaning that the two virtual machines are currently only associated with the emulator thread pool with Index=1, i.e., pool 1.
[0099] In this embodiment, by removing instructions, the CPU affinity of simulator threads can be managed in batches.
[0100] In one exemplary embodiment, the simulator thread management method further includes: receiving an update instruction sent by a scheduling platform; determining the tenth physical CPU core based on the identifier of the created simulator thread pool; and replacing the tenth physical CPU core with the ninth physical CPU core in response to the update instruction.
[0101] The update instruction carries the identifier of the created simulator thread pool and the ninth physical CPU core to be updated. The update instruction refers to updating the simulator thread pool. The identifier of the created simulator thread pool can be the same as, or different from, any of the aforementioned identifiers for the first simulator thread pool to be added, the second simulator thread pool to be added, or the removed simulator thread pool. Similarly, the ninth physical CPU core is different from the tenth physical CPU core. The ninth physical CPU core can be the same as, or different from, any of the aforementioned physical CPU cores. The tenth physical CPU core is similar and will not be elaborated further here.
[0102] Optionally, the host server receives update commands sent by the scheduling platform through a scheduling platform proxy; it responds to the update commands via the virNodeSetEmulatorPool() interface created by Libvirt. `create=False` indicates updating the emulator pool; after a successful interface call, the emulator affinity of the virtual machines in the pool is updated accordingly, such as... Figure 9 As shown, if the cpulist of pool 0 is updated from 0-4, 7 to 0-3, 5, then the virtual machine emulator affinity is updated from 0-4, 6-7 to 0-3, 5-6.
[0103] It should be noted that update commands and creation commands share the same interface.
[0104] In this embodiment, by updating instructions, the CPU affinity of simulator threads can be managed in batches.
[0105] In one exemplary embodiment, the host server receives a destruction command sent by the scheduling platform, the destruction command carrying an emulator thread pool identifier. For example... Figure 10 As shown, this is the interface call for destroying an emulator pool. Libvirt has added an interface virNodeDestroyEmulatorPool(), which destroys the specified emulator pool according to the pool index specified in the destruction command. After the interface call is successful, the state of the specified emulator pool will be set to destroyed. Simultaneously, the emulator cores of the virtual machines in the pool will have the cpulist part of the pool removed. If the currently destroyed pool is the only pool associated with the virtual machine, the virtual machine emulator cores will be restored to the initial configuration. As shown in the figure above, virtual machine UUID1 is restored to the initial default cores 10-11, and virtual machine UUID2 is restored to the initial default cores 62-63.
[0106] In this embodiment, the CPU affinity of simulator threads can be managed in batches through the destroy instruction.
[0107] It should be noted that the create, add, update, remove, and destroy commands can be combined in any way.
[0108] In an exemplary embodiment, for example, a first target virtual machine, such as virtual machine vm1, runs on a host server, with its vCPU and emulator cores both bound to 10-11. vm1 internally runs compute-intensive and I / O-intensive tasks, causing preemption between the emulator and vCPU, resulting in a steal time > 0 for the vCPU. The host server, through a monitoring and acquisition module, reports the CPU utilization of vm1 and the preemption time (vCPU) to the Prometheus database at regular intervals; the steal time includes abnormal preemption times. The first sub-scheduling platform integrates an adaptive virtualization thread dynamic scheduling algorithm, while the compute node resource inventory is uniformly managed by the second sub-scheduling platform, such as the nova-compute scheduling platform. The adaptive virtualization thread dynamic scheduling algorithm of the first sub-scheduling platform periodically obtains monitoring data such as CPU utilization and virtual CPU stealtime from the Prometheus database. If the algorithm determines that the emulator pool needs to be operated, the adaptive algorithm module of the first sub-scheduling platform periodically reads the virtual machine stealtime from the Prometheus database as input to the algorithm model. If the algorithm detects that the stealtime of vm1 is greater than 0, it needs to be eliminated. The system obtains CPU inventory information from the second sub-scheduling platform and, based on certain algorithmic logic, such as using temporarily idle physical CPU cores (e.g., 0-4, 7) to create an emulator pool. It then outputs the emulator pool operation strategy, such as instructions to create the emulator pool using idle physical CPU cores (e.g., 0-4, 7), and sends it to the second sub-scheduling platform for execution. The second sub-scheduling platform forwards the creation instructions through the scheduling platform agent nova-computeagent in the host server. The scheduling platform agent nova-computeagent forwards the creation instructions to Libvirt. The host server executes the emulator pool creation interface through Libvirt to execute the creation instructions. The host server translates the emulator pool creation instructions into a Libvirt interface call, i.e., virNodeSetEmulatorPool(), through the scheduling platform agent. Figure 4As shown, `cpumap` represents the CPU cores used by the emulator pool. In the above diagram, `cpumap=(1, 1, 1, 1, 1, 0, 0, 1)`, the elements corresponding to indices 0-4 and 7 are 1, indicating that the current emulator pool will use CPUs 0-4 and 7. `index=0` represents the emulator pool ID; Libvirt supports creating multiple emulator pools. `create=True` indicates a new emulator pool. After a successful API call, Libvirt maintains a new emulator pool data structure with a running status, indicating successful emulator pool creation. The host server unbinds the emulator thread of the first target virtual machine from the first physical CPU core identifier (e.g., 10-11) and binds it to the second physical CPU core (e.g., 0-4, 7) bound to the first emulator thread pool with `Index=0`.
[0109] The host server receives operation instructions from the scheduling platform for the second target virtual machine, such as operation instructions for the virtual machine identified as vm2. The host server uses the core binding detection interface to determine whether the third physical CPU core of the vCPU-bound core in the second target virtual machine configuration overlaps with the second physical CPU core bound to the existing emulator pool; whether the fourth physical CPU core of the emulator-bound core in the second target virtual machine configuration overlaps with the second physical CPU core bound to the existing emulator pool; and whether the IO physical CPU core of the iothread-bound core in the second target virtual machine configuration overlaps with the second physical CPU core bound to the existing emulator pool. If at least one of the following conditions is met: the third physical CPU core of the vCPU-bound core in the second target virtual machine configuration overlaps with the second physical CPU core bound to the existing emulator pool; the fourth physical CPU core of the emulator-bound core in the second target virtual machine configuration overlaps with the second physical CPU core bound to the existing emulator pool; or the IO physical CPU core of the iothread-bound core in the second target virtual machine configuration overlaps with the second physical CPU core bound to the existing emulator pool, the first emulator thread pool is destroyed, and the operation instructions are responded to using the overlapping physical CPU core. If none of them overlap with the second physical central processing unit core bound to the existing emulator pool, it indicates that there is no thread conflict in the operation instructions of the second target virtual machine, and the operation instructions of the second target virtual machine can be responded to normally.
[0110] Under the aforementioned circumstances, the host server receives and executes creation, addition, update, removal, and destruction commands, respectively. The order in which these commands are executed is not specified.
[0111] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.
[0112] Based on the same inventive concept, this application also provides an emulator thread management device for implementing the emulator thread management method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more emulator thread management device embodiments provided below can be found in the limitations of the emulator thread management method described above, and will not be repeated here.
[0113] In one exemplary embodiment, such as Figure 11 As shown, a simulator thread management device is provided, including: an acquisition and sending module 1101, a receiving module 1102, a creation module 1103, and an unbinding module 1104, wherein:
[0114] The acquisition and sending module 1101 is used to acquire the abnormal preemption time of the first target virtual machine when the simulator thread and virtual CPU thread of the first target virtual machine preempt the first physical CPU core on the host server, and send the abnormal preemption time to the scheduling platform; wherein, the scheduling platform is used to determine the creation instruction of the first simulator thread pool based on the abnormal preemption time; the simulator thread and virtual CPU thread of the first target virtual machine are both bound to the first physical CPU core.
[0115] The receiving module 1102 is used to receive the creation instruction sent by the scheduling platform; wherein the creation instruction carries the second physical central processing unit core.
[0116] Create module 1103 to create a first simulator thread pool bound to a second physical central processing unit core in the host server in response to a creation command.
[0117] The unbinding module 1104 is used to unbind the simulator thread of the first target virtual machine in the host server from the first physical central processing unit core and bind it to the second physical central processing unit core bound to the first simulator thread pool.
[0118] In an exemplary embodiment, the simulator thread management device further includes a virtual machine instruction operation module, configured to receive operation instructions for a second target virtual machine sent by a scheduling platform; create an asynchronous thread, and detect whether the third and fourth physical CPU cores of the second target virtual machine overlap with the second physical CPU core through the asynchronous thread; wherein the third physical CPU core is bound to the virtual CPU thread of the second target virtual machine; the fourth physical CPU core is bound to the simulator thread of the second target virtual machine; when at least one of the third and fourth physical CPU cores overlaps with the second physical CPU core, the first simulator thread pool is destroyed; and the operation instructions are responded to through the overlapping physical CPU cores.
[0119] In an exemplary embodiment, the simulator thread management device further includes an adding module, configured to receive a first adding instruction sent by a scheduling platform, wherein the first adding instruction carries a first virtual machine list and a first simulator thread pool identifier to be added; in response to the first adding instruction, the first virtual machine list is traversed, and the simulator threads of the virtual machines in the first virtual machine list are added to a second simulator thread pool; wherein the second simulator thread pool corresponds to the first simulator thread pool identifier to be added.
[0120] In an exemplary embodiment, the second simulator thread pool is bound to the fifth physical CPU core. The addition module is further configured to receive a second addition instruction sent by the scheduling platform, wherein the second addition instruction carries a second virtual machine list and a second simulator thread pool identifier to be added; add the simulator threads of the virtual machines in the second virtual machine list to the third simulator thread pool; wherein the third simulator thread pool corresponds to the second simulator thread pool identifier to be added; the third simulator thread pool is bound to the sixth physical CPU core; the fifth physical CPU core and the sixth physical CPU core are different; if the second virtual machine list is the same as the first virtual machine list, and the second simulator thread pool identifier to be added is different from the first simulator thread pool identifier to be added, merge the fifth physical CPU core and the sixth physical CPU core, and bind the merged physical CPU core to the second simulator thread pool and the third simulator thread pool.
[0121] In an exemplary embodiment, the simulator thread management device further includes a removal module for receiving a removal instruction sent by a scheduling platform; wherein the removal instruction carries a third virtual machine list and an identifier of the simulator thread pool to be removed; in response to the removal instruction, the eighth physical central processing unit core bound to the fourth simulator thread is removed from the seventh physical central processing unit core corresponding to the simulator thread of the virtual machine in the third virtual machine list; wherein the identifier of the simulator thread pool to be removed corresponds to the fourth simulator thread.
[0122] In one exemplary embodiment, the simulator thread management device further includes an update module for receiving an update instruction sent by a scheduling platform; wherein the update instruction carries an identifier of a created simulator thread pool and a ninth physical CPU core to be updated; the tenth physical CPU core is determined based on the identifier of the created simulator thread pool; and in response to the update instruction, the tenth physical CPU core is replaced with the ninth physical CPU core.
[0123] Each module in the aforementioned simulator thread management device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.
[0124] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 12 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores simulator thread management data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When executed by the processor, the computer program implements a simulator thread management method.
[0125] Those skilled in the art will understand that Figure 12The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0126] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.
[0127] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.
[0128] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.
[0129] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.
[0130] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.
[0131] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.
Claims
1. A method for managing threads in an emulator, characterized in that, Applied to a host server, the method includes: In the event that the simulator thread and virtual CPU thread of the first target virtual machine preempt the first physical CPU core on the host server, the abnormal preemption time of the first target virtual machine is obtained and the abnormal preemption time is sent to the scheduling platform; wherein, the scheduling platform is used to determine the creation instruction of the first simulator thread pool based on the abnormal preemption time; the simulator thread and virtual CPU thread of the first target virtual machine are both bound to the first physical CPU core. The system receives the creation instruction sent by the scheduling platform; wherein the creation instruction carries a second physical central processing unit core. In response to the creation command, a first simulator thread pool is created that is bound to the second physical central processing unit core in the host server; The simulator thread of the first target virtual machine in the host server is unbound from the first physical CPU core and bound to the second physical CPU core to which the first simulator thread pool is bound.
2. The method according to claim 1, characterized in that, The method further includes: Receive the operation instructions for the second target virtual machine sent by the scheduling platform; A new asynchronous thread is created, and the third and fourth physical CPU cores of the second target virtual machine are used to detect whether they overlap with the second physical CPU core; wherein, the third physical CPU core is bound to the virtual CPU thread of the second target virtual machine; and the fourth physical CPU core is bound to the emulator thread of the second target virtual machine. When at least one of the third physical CPU core and the fourth physical CPU core overlaps with the second physical CPU core, the first simulator thread pool is destroyed. The operation instructions are responded to by overlapping physical central processing unit cores.
3. The method according to claim 1, characterized in that, The method further includes: Receive a first add instruction sent by the scheduling platform, wherein the first add instruction carries a first virtual machine list and a first emulator thread pool identifier to be added; In response to the first add instruction, the first virtual machine list is traversed, and the emulator threads of the virtual machines in the first virtual machine list are added to the second emulator thread pool; wherein the second emulator thread pool corresponds to the identifier of the first emulator thread pool to be added.
4. The method according to claim 3, characterized in that, The second simulator thread pool is bound to the fifth physical central processing unit core, and the method further includes: Receive a second add instruction sent by the scheduling platform, wherein the second add instruction carries a second virtual machine list and a second emulator thread pool identifier to be added; The emulator threads of the virtual machines in the second virtual machine list are added to the third emulator thread pool; wherein, the third emulator thread pool corresponds to the identifier of the second emulator thread pool to be added; the third emulator thread pool is bound to the sixth physical CPU core; the fifth physical CPU core is different from the sixth physical CPU core; If the second virtual machine list is the same as the first virtual machine list, and the identifier of the second emulator thread pool to be added is different from the identifier of the first emulator thread pool to be added, the fifth physical CPU core and the sixth physical CPU core are merged, and the merged physical CPU core is bound to the second emulator thread pool and the third emulator thread pool.
5. The method according to claim 1, characterized in that, The method further includes: Receive a removal instruction sent by the scheduling platform; wherein the removal instruction carries a third virtual machine list and an identifier of the emulator thread pool to be removed; In response to the removal instruction, the eighth physical CPU core bound to the fourth simulator thread is removed from the seventh physical CPU core corresponding to the simulator thread of the virtual machine in the third virtual machine list; wherein, the simulator thread pool identifier to be removed corresponds to the fourth simulator thread.
6. The method according to claim 1, characterized in that, The method further includes: Receive update instructions sent by the scheduling platform; wherein, the update instructions carry the identifier of the created simulator thread pool and the ninth physical central processing unit core to be updated; The tenth physical central processing unit core is determined based on the already created simulator thread pool identifier; In response to the update instruction, the tenth physical central processing unit core is replaced with the ninth physical central processing unit core.
7. A simulator thread management device, characterized in that, Applied to a host server, the apparatus includes: The acquisition and sending module is used to acquire the abnormal preemption time of the first target virtual machine when the simulator thread and virtual CPU thread of the first target virtual machine preempt the first physical CPU core on the host server, and send the abnormal preemption time to the scheduling platform; wherein, the scheduling platform is used to determine the creation instruction of the first simulator thread pool based on the abnormal preemption time; the simulator thread and virtual CPU thread of the first target virtual machine are both bound to the first physical CPU core. A receiving module is used to receive the creation instruction sent by the scheduling platform; wherein the creation instruction carries a second physical central processing unit core; A creation module is configured to, in response to the creation instruction, create a first simulator thread pool bound to the second physical central processing unit core in the host server; The unbinding module is used to unbind the simulator thread of the first target virtual machine in the host server from the first physical central processing unit core and bind it to the second physical central processing unit core to which the first simulator thread pool is bound.
8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.
10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.