Physical machine processor scheduling method, equipment, system, product and storage medium

Abstract

The embodiment of the invention provides a physical machine processor scheduling method, device, system, product and storage medium, the physical machine comprises a physical processor, the physical processor corresponds to a scheduling queue, the method comprises the following steps: switching a running host machine operating system from a root mode to a virtualization mode, and in the virtualization mode, the host machine operating system is switched to a virtual mode; creating at least one virtual processor; generating a scheduling object and adding the scheduling object to a scheduling queue of the physical processor; and in a process of selecting a running task for the physical processor based on the scheduling queue of the physical processor, if the scheduling object is selected, selecting a target virtual processor from the at least one virtual processor, and scheduling the physical processor to run the target virtual processor.

Description

Technical Field

[0001] This specification relates to the field of virtualization technology, and in particular to processor scheduling methods, devices, systems, products and storage media for physical machines. Background Technology

[0002] Traditional operating systems like Linux provide control groups (cgroups), which allow the creation of different functional groups, each containing at least one process. Cgroups can be used to define the processor scope used by different functional groups, thus allocating different processor usage ranges and quotas for each group. While this cgroup configuration can be changed online, in production environments, system stability must be considered. Often, the quotas for different cgroups do not change frequently, and CPU scheduling policies are relatively fixed. This can lead to situations where some cgroups have idle processor resources while others are heavily used. Therefore, processor scheduling schemes using cgroups in related technologies are not flexible enough and cannot provide fine-grained processor management. Summary of the Invention

[0003] To overcome the problems existing in related technologies, this specification provides processor scheduling methods, devices, systems, products, and storage media for physical machines.

[0004] According to a first aspect of the embodiments of this specification, a processor scheduling method for a physical machine is provided, the physical machine including a physical processor, the physical processor corresponding to a scheduling queue, the method comprising:

[0005] Switch the running host operating system from root mode to virtualization mode, and create at least one virtual processor in virtualization mode;

[0006] Generate a scheduling object and add it to the scheduling queue of the physical processor;

[0007] During the process of selecting a running task for the physical processor based on the scheduling queue of the physical processor, if the scheduling object is selected, a target virtual processor is selected from the at least one virtual processor, and the physical processor is scheduled to run the target virtual processor.

[0008] According to a second aspect of the embodiments of this specification, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method embodiments described in the first aspect above.

[0009] According to a third aspect of the embodiments of this specification, a processor scheduling system for a physical machine is provided, the physical machine including a physical processor and a host operating system running on the physical processor, a virtualization layer being implemented between the physical processor and the host operating system, the virtualization layer including the processor scheduling system, the processor scheduling system being used to perform the steps of the method embodiments of the first aspect.

[0010] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the method embodiments described in the first aspect above.

[0011] According to a fifth aspect of the embodiments of this specification, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method embodiments described in the first aspect above.

[0012] The technical solutions provided in the embodiments of this specification may include the following beneficial effects:

[0013] In this embodiment, the physical machine includes a physical processor, and each physical processor corresponds to a scheduling queue. This embodiment can switch the running host operating system from root mode to virtualization mode. In virtualization mode, at least one virtual processor is created; a scheduling object is generated and added to the scheduling queue of the physical processor; during the process of selecting a running task for the physical processor based on the scheduling queue of the physical processor, if the scheduling object is selected, a target virtual processor is selected from the at least one virtual processor, and the physical processor is scheduled to run the target virtual processor. Based on this, this embodiment can directly create new virtual processors in the running host operating system. By adding scheduling objects to the scheduling queue of the physical processor, when a scheduling object is selected, a target virtual processor can be selected to run on the physical processor. Therefore, the resources of the physical processor can be utilized to execute the target virtual processor, improving the utilization rate of the physical processor. Furthermore, the number of virtual processors created can be arbitrary, allowing for flexible provision of computing power from the physical processor to the upper layers.

[0014] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating a processor scheduling method for a physical machine according to an exemplary embodiment of this specification.

[0016] Figure 2AThis is a schematic diagram of a physical machine illustrated in this specification according to an exemplary embodiment.

[0017] Figure 2B This is a schematic diagram illustrating a processor scheduling method for a physical machine according to an exemplary embodiment of this specification.

[0018] Figure 3 This specification is a hardware structure diagram of a computer device containing a processor scheduling device for a physical machine, according to an exemplary embodiment.

[0019] Figure 4 This is a structural diagram of a processor scheduling device for a physical machine according to an exemplary embodiment of this specification. Detailed Implementation

[0020] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this specification as detailed in the appended claims.

[0021] The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of this specification. The singular forms “a,” “the,” and “the” as used in this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0022] It should be understood that although the terms first, second, third, etc., may be used in this specification to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0023] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data shall comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points shall be provided for users to choose to authorize or refuse.

[0024] In operating systems such as Linux, cgroups are a kernel feature used to limit, record, and isolate the use of hardware resources within a control group. These hardware resources include, but are not limited to, CPU, memory, and disk I / O (input / output). Using cgroups, system administrators can control hardware resources, such as limiting the proportion of processor (Central Processing Unit) and / or memory used by specific processes, or tracking their resource usage. For example, regarding CPU resource allocation, cgroups provide functions such as limiting the total CPU usage time of all processes within the control group, and binding processes within the control group to specific CPU cores and / or memory nodes.

[0025] However, cgroup-based processor scheduling strategies are relatively fixed, which can lead to situations where some cgroups have idle processor resources while others are heavily used. Therefore, cgroup-based processor scheduling schemes are not flexible enough and cannot provide fine-grained processor management. In production environments, although cgroups can be dynamically adjusted, their configurations are often empirical values ​​validated through practical experience and large-scale deployments, making frequent changes unlikely.

[0026] Therefore, hardware resource control can also be considered through virtualization technologies. For example, virtualization allows the physical CPU on a physical machine to be abstracted and divided into multiple virtual CPUs (vCPUs). As an example, the Kernel-based Virtual Machine (KVM) virtualization management tool in the Linux kernel can utilize Linux kernel modules and some user-space tools to implement virtualization, allowing multiple virtual machines (VMs) to run on a Linux system. Each VM can independently run different operating systems and applications. KVM can allocate vCPUs to VMs running on the host, mapping and scheduling vCPUs to physical CPUs. In KVM, vCPU scheduling can be based on various strategies, including round-robin, fair scheduling, and real-time scheduling, depending on the implementation of the virtualization management software. The ultimate goal is to ensure VM performance while maximizing the efficiency of the physical hardware. KVM utilizes the Linux kernel scheduler to mount vCPUs to physical CPUs, and KVM also supports advanced features such as CPU-intensive task prioritization and memory page migration.

[0027] vCPUs can be dynamically migrated to different physical cores for more efficient use of physical resources. This is called vCPU migration. For example, if a vCPU on one physical core has a light load while a vCPU on another physical core has a heavy load, some of the load can be migrated to the less loaded core to achieve load balancing. Dynamic scheduling also allows for dynamic modification of the number of vCPUs. For example, when a vCPU is running under high load, the number of vCPUs can be increased to meet the resource needs of the VMs. Administrators can use various monitoring tools to track resource usage and make optimizations based on this data.

[0028] Based on this, the scheduling of physical processors can be achieved through virtualization. This specification provides a processor scheduling scheme that, by switching the running operating system to virtualization mode and creating new virtual processors for it, and then scheduling these new virtual processors to run on physical processors, can more efficiently utilize the resources of physical processors, improve processor utilization, and the number of virtual processors created can be arbitrary, allowing for flexible provision of computing power from physical processors to upper layers.

[0029] like Figure 1 The diagram illustrates a processor scheduling method for a physical machine according to an exemplary embodiment of this specification. The physical machine includes physical processors, each corresponding to a scheduling queue. The method may include the following steps:

[0030] In step 102, the running host operating system is switched from root mode to virtualization mode, in which at least one virtual processor is created.

[0031] In step 104, a scheduling object is generated and added to the scheduling queue of the physical processor.

[0032] In step 106, during the process of selecting a running task for the physical processor based on the scheduling queue of the physical processor, if the scheduling shell is selected, then the target virtual processor is selected and the physical processor is scheduled to run the target virtual processor.

[0033] As an example, the hardware resources of the physical machine include, but are not limited to, combinations of one or more processors such as: CPU, Graphics Processing Unit (GPU), Data Processing Unit (DPU), Tensor Processing Unit (TPU), Cloud Infrastructure Processing Unit (CIPU), and Application Specific Integrated Circuit (ASIC), etc. The hardware resources of the physical machine may also include any type of storage medium, as well as other components such as I / O devices, communication components, displays, power supply components, and audio components, etc., which are not limited in this embodiment.

[0034] The host operating system is system software that runs on a physical machine. It is responsible for managing hardware resources and providing a platform that allows applications to run on the operating system and access and utilize hardware resources to perform specific tasks. As an example, the host operating system could be Linux, etc., but this embodiment does not limit it.

[0035] The processors used in the embodiments of this specification include, but are not limited to, CPUs, GPUs, DPUs, or TPUs; in subsequent embodiments, for ease of description, most will use CPUs as an example.

[0036] To provide elastic computing power, the embodiments in this specification can first directly create a new virtual processor on the running host operating system, and then schedule the new virtual processor to run on the physical processor to achieve elastic computing power.

[0037] As an example, in practical applications, there can be various situations that trigger the execution of the scheme in this embodiment. For example, it may be when cgroup adjustment is required, such as when a cgroup adjustment request is received, or any other situation can trigger the execution of the scheme in this embodiment.

[0038] KVM virtualization requires starting a virtual machine. Unlike KVM, this embodiment switches the running host operating system from root mode to virtualization mode, essentially switching the existing running physical CPUs to virtualization mode. This is more lightweight than KVM virtualization. Based on this, this embodiment creates one or more virtual processors in the virtualization mode.

[0039] In some examples, such as Figure 2AThe diagram shown is an architecture diagram of a physical machine according to an exemplary embodiment of this specification. The physical machine architecture of this embodiment provides two operating modes for the host operating system in a running state: root mode and virtualization mode. A virtualization layer can be inserted between the hardware resources and the host operating system. The virtualization layer can be located between the hardware resources of the physical machine and the host operating system. The virtualization layer switches the running host operating system from root mode to virtualization mode, allowing for flexible implementation of various functions for the running host operating system without reinstalling the operating system.

[0040] As an example, a host operating system has root mode and virtualization mode. Root mode is the operating mode where the host operating system has direct access to hardware resources. Virtualization mode is the operating mode where a virtualization layer virtualizes hardware resources and schedules and accesses these virtualized resources on behalf of the host operating system. In virtualization mode, the virtualization layer's access to hardware resources is restricted. Compared to root mode, virtualization mode can also be called non-root mode; correspondingly, the host operating system in virtualization mode can also be called a guest operating system.

[0041] In this embodiment, a lightweight, powerful, and efficient virtualization layer is inserted between the hardware resources and the host operating system. The virtualization layer can be pre-developed and inserted between the hardware resources and the host operating system. The method of inserting the virtualization layer is not limited. For example, the virtualization layer can be inserted after the host operating system is installed on the physical machine and while the host operating system is running normally.

[0042] As an example, the virtualization layer can be a software module within the host operating system. When the host operating system is in root mode, this software module can switch the host operating system from root mode to virtualization mode. After the switch, the host operating system becomes the guest operating system, and the virtualization layer takes over the management of the physical machine's hardware resources. In other words, the virtualization layer is inserted between the hardware resources and the host operating system, so that the host operating system can use hardware resources through the virtualization layer.

[0043] After the host operating system switches from root mode to virtualization mode, taking the CPU as an example, the existing physical CPU can be switched to the corresponding virtual CPU; however, in this embodiment, new virtual CPUs will be created further in virtualization mode. There can be one or more newly created virtual CPUs, which can be flexibly configured according to actual needs; this embodiment does not impose any limitations on this.

[0044] As an example, suppose the physical machine has four physical CPUs. After the host operating system switches from root mode to virtualization mode, these four physical CPUs can be switched to their corresponding virtual CPUs. In this embodiment, n new virtual CPUs can be created based on these four switched-to virtual CPUs. To distinguish them from the virtual CPUs switched from the physical CPUs, this embodiment refers to the newly created virtual CPUs as newly created virtual CPUs. Thus, the total number of virtual CPUs is four switched-to virtual CPUs plus n newly created virtual CPUs.

[0045] As an example, during the process of the host operating system switching from root mode to virtualization mode, the physical CPU is switched to the corresponding virtual CPU. The virtualization layer can create a corresponding physical description structure (PDS) for each physical CPU and a corresponding virtualization description structure (VDS) for each virtual CPU. The PDS is used to save the context information of the physical CPU running in root mode during mode switching, while the VDS is used to synchronize the context information in the PDS during mode switching. The virtualization layer manages the virtual CPUs switched from the physical CPUs through the VDS.

[0046] As an example, there are multiple ways to create a new virtual processor. For instance, the virtual processor switched from the physical processor mentioned above corresponds to a virtualization description structure. To create a new virtual processor, a new virtualization description structure can be created. Optionally, a series of registers can also be configured, etc., specifically implemented by the virtual processor creation function of the virtualization layer. This embodiment does not limit this. For example, the virtualization description structure of the new virtual processor here is similar to the virtualization description structure corresponding to the physical CPU mentioned above; for example, the fields are the same, but the specific field values ​​are different. Each newly created virtualization description structure represents a new virtual processor, and the corresponding new virtual processor can be managed through the virtualization description structure. The specific management method is not limited in this embodiment.

[0047] As an example, for the virtualization layer at the bottom of the physical machine in this embodiment, a virtual processor is a running task that can be scheduled to run on the physical CPU. On the newly created virtual processor, this virtual processor can be used to run arbitrary tasks, similar to a KVM virtual machine. However, the creation method of the virtual processor in this embodiment differs from KVM, and the virtual processor is managed by the virtualization layer. As an example, various user tasks, such as common user-mode processes, can run on the virtual processor in this embodiment. User processes can also be bound to the newly created virtual processor as needed, etc., and this embodiment does not limit this. Therefore, by scheduling the newly created virtual processor to run on the physical CPU, this embodiment can provide elastic computing power to the upper layer. How the underlying virtualization layer schedules the newly created virtual processor according to the busy / idle status of the physical CPU is transparent to the upper-layer tasks, maintaining transparency to the original running mode.

[0048] As an example, a scheduler can be implemented in the virtualization layer to schedule these virtual CPUs (virtual CPUs switched from physical CPUs + n newly created virtual CPUs). The method in this embodiment can be applied to the scheduler of this virtualization layer. Optionally, the scheduler can run on each physical CPU, that is, the method in this embodiment can be applied to each physical CPU.

[0049] In this embodiment, under virtualization mode, each physical processor in the virtualization layer has a corresponding scheduling queue, which contains one or more tasks to be run for that physical processor. These tasks to be run for the physical processor can be upper-layer processes bound to that physical processor, etc. By setting some scheduling policies, the virtualization layer can retrieve tasks to be run from the scheduling queue of the physical processor and hand them over to the physical processor for execution. The specific scheduling policies and methods can be flexibly configured according to actual needs, and this embodiment does not limit them.

[0050] To enable newly created virtual processors to be scheduled to run on physical processors, this embodiment can generate scheduling objects and add them to the scheduling queue. As an example, scheduling objects can be created in the scheduling queue of each physical processor, or they can be created in some scheduling queues; this embodiment does not limit this approach.

[0051] Thus, since the scheduling object is added to the scheduling queue of the physical processor, it has the opportunity to be selected when a task is selected for execution on the physical processor based on the scheduling queue. In this embodiment, the scheduling object itself is not a task to be executed on the physical processor, but rather the selection of a virtual processor is triggered when the scheduling object is selected. That is, the scheduling object is a data object in the scheduling queue of the physical processor. This scheduling object can be considered as a shell used to enclose each newly created virtual processor. Therefore, if a scheduling object is selected from the scheduling queue of the physical processor, one of the newly created virtual processors can be selected. In this embodiment, the selected virtual CPU is called the target virtual processor. Furthermore, the physical processor can be scheduled to run the target virtual processor.

[0052] As an example, following the aforementioned embodiments, such as Figure 2B As shown, assuming the physical machine includes 4 physical CPUs (physical CPU_1 to physical CPU_4) and currently has the following 6 vCPUs:

[0053] ①vCPU_1, vCPU_2, vCPU_3 and vCPU_4, these four are switched from the physical CPU;

[0054] ②vCPU_5 and vCPU_6 are newly created;

[0055] Scheduling objects can be inserted into the scheduling queues of all four physical CPUs. The virtualization layer can manage each physical CPU and select a running task for each physical CPU based on its corresponding scheduling queue. Since scheduling objects have been inserted into the scheduling queues, if a scheduling object is selected from the scheduling queue of physical CPU_1, then one of the newly created vCPU_5 and vCPU_6 will be selected. If vCPU_5 is selected, then the running task of vCPU_5 can be executed by physical CPU_1.

[0056] The physical CPU's scheduling queue contains the physical CPU's original running tasks. Newly inserted scheduling objects trigger the selection of a newly created virtual CPU for execution. As an example, the priority of the scheduling object in the scheduling queue can be set. For instance, the priority of the physical CPU's original running tasks can be higher than the priority of the newly created virtual CPU. In other examples, the scheduling queue can also include other tasks from the virtualization layer, such as background tasks like memory swapping, whose priority can be lower than the priority of the newly created virtual CPU. Of course, other priority strategies can be used in practical applications, and this embodiment does not limit this. Thus, when the physical CPU is idle, such as when its original running tasks are not needed, it can be promptly scheduled to the vCPU of this embodiment, allowing the vCPU to utilize the computing power of the physical CPU during idle periods. For example, if the physical CPU is bound to run certain control groups, the solution in this embodiment allows the physical CPU to run newly created virtual CPUs when idle, and these newly created virtual CPUs can host any running tasks.

[0057] As an example, multiple new virtual CPUs can be created. When a scheduling object is selected from a scheduling queue, one of the multiple newly created virtual CPUs can be randomly selected for execution by a physical CPU. The selection method can be arbitrary, such as random selection, priority-based selection, and other methods. Considering that in practical applications there may be multiple physical CPUs and multiple newly created virtual CPUs, to better schedule the newly created virtual CPUs, as an example, each virtual CPU corresponds to a scheduling entity, and the method may further include:

[0058] Create a virtual processor scheduling queue, which is used to store the scheduling entities corresponding to the virtual processors;

[0059] Selecting a target virtual processor from the at least one virtual processor includes:

[0060] Select a target scheduling entity from the virtual processor scheduling queue and determine the target virtual processor corresponding to the target scheduling entity.

[0061] As an example, taking a CPU as an example, each virtual CPU can correspond to a scheduling entity. The scheduling entity can contain relevant information about the virtual CPU, including but not limited to the virtual CPU's identifier, execution function, time slice, etc. The scheduling entity can be stored in the virtual CPU scheduling queue. When a scheduling object is selected from the physical CPU's scheduling queue, a scheduling entity can be selected from the virtual CPU scheduling queue. The virtual CPU corresponding to the selected scheduling entity can then run on the physical CPU, and the selected scheduling entity is removed from the virtual CPU scheduling queue. This process can be understood to work similarly for other processors, such as GPUs.

[0062] For example Figure 2B As shown, this includes a virtual CPU scheduling queue. Newly created scheduling entities se5 (vCPU_5) and se6 (vCPU_6) can be added to this queue. If the virtualization layer selects a scheduling object from the scheduling queue of physical CPU_1, it can then select a scheduling entity from the virtual CPU scheduling queue. If scheduling entity se5 is selected, corresponding to vCPU_5, then vCPU_5 can be executed by physical CPU_1.

[0063] In other examples, suppose there are 4 physical CPUs and 5 newly created virtual CPUs. The scheduling entities corresponding to these 5 virtual CPUs are initially stored in the virtual CPU scheduling queue. At some point, scheduler A, corresponding to physical CPU A, selects a scheduling object from physical CPU A's scheduling queue. Scheduler A then selects a scheduling entity from the virtual CPU scheduling queue. This scheduling entity corresponds to the newly created virtual CPU 1, so the newly created virtual CPU 1 runs on physical CPU A. Since the scheduling entity of the newly created virtual CPU 1 has been removed, scheduler B, corresponding to physical CPU B, selects a scheduling object from physical CPU B's scheduling queue. Scheduler B then selects a scheduling entity from the virtual CPU scheduling queue. At this point, the scheduling entity of the newly created virtual CPU 1 is no longer in the virtual CPU scheduling queue. Scheduler B will then select other scheduling entities so that other newly created virtual CPUs can run on physical CPU B.

[0064] As can be seen from the above embodiments, by cooperating with the scheduling entity and the virtual CPU scheduling queue, multiple virtual CPUs can be flexibly scheduled among multiple physical CPUs, and each virtual CPU can be scheduled.

[0065] In practical applications, one or more virtual CPU scheduling queues can be created as needed. This embodiment does not limit the number of virtual CPU scheduling queues, and the priority of different virtual CPU scheduling queues can be set as needed.

[0066] As an example, the virtual processor scheduling queue can be a global scheduling queue, which can create a corresponding scheduling entity se for each newly created virtual processor. The scheduling entities corresponding to each newly created virtual processor can be added to the global scheduling queue. Each time a scheduling object is selected in the scheduling queue of a physical processor, a scheduling entity can be selected from the global scheduling queue, and the newly created virtual processor corresponding to the selected scheduling entity can be scheduled to run on that physical processor.

[0067] As an example, the scheduling entities corresponding to vCPU_5 and vCPU_6 in the aforementioned embodiments can be added to the global queue. Assuming that a scheduling shell is selected from the scheduling queue of physical CPU_1, a scheduling entity is selected from the global scheduling queue. Assuming that the selected scheduling entity corresponds to vCPU_5, the scheduling entity is dequeued from the scheduling queue, and the running task of vCPU_5 can be executed by physical CPU_1.

[0068] As an example, the strategy for selecting the scheduling entity of each newly created virtual CPU can be a first-in-first-out strategy, or the priority of the scheduling entity of different vCPUs can be set according to actual needs. This embodiment does not limit this.

[0069] As an example, the virtual processor scheduling queue includes a global scheduling queue and an emergency scheduling queue, wherein the priority of the virtual processor corresponding to the scheduling entity in the global scheduling queue is lower than the priority of the virtual processor corresponding to the scheduling entity in the emergency scheduling queue.

[0070] The step of selecting a target scheduling entity from the virtual processor scheduling queue includes:

[0071] Determine whether a scheduling entity exists in the emergency dispatch queue;

[0072] If so, select the target scheduling entity from the emergency scheduling queue;

[0073] If not, select the target scheduling entity from the global scheduling queue.

[0074] As an example, two different levels of queues are set up for the virtual processor scheduling queue. The emergency scheduling queue can be used to store the scheduling entities of virtual processors that need to be executed first. In practical applications, some virtual processors can be given higher priority and some virtual processors can be given lower priority based on factors such as some urgent tasks or conditions.

[0075] During the selection of scheduling entities, the emergency scheduling queue can be checked first. If a scheduling entity is in the emergency scheduling queue, it can be selected from that queue. Only if there is no scheduling entity in the emergency scheduling queue will the scheduler select a scheduling entity from the global scheduling queue. This ensures that non-urgent tasks can also be scheduled appropriately. Based on this, this embodiment, by distinguishing between the global and emergency scheduling queues, can more effectively run virtual CPUs of different priorities, ensuring that urgent tasks can be responded to in a timely manner.

[0076] In practical applications, the priority of different virtual processors, i.e., which virtual processor scheduling entities are stored in the emergency scheduling queue and the global scheduling queue, can be configured as needed. This embodiment does not limit this.

[0077] Following the step of creating at least one virtual processor, the method further includes:

[0078] Create the scheduling entity corresponding to the virtual processor and add it to the global scheduling queue;

[0079] Detect whether a preset emergency event occurs in the virtual processor corresponding to each scheduling entity in the global scheduling queue;

[0080] The scheduling entity corresponding to the virtual processor that has a preset emergency event is removed from the global scheduling queue and then added to the emergency scheduling queue.

[0081] That is, the scheduling entities in the global scheduling queue can be added in the following way:

[0082] When creating the virtual processor, a scheduling entity corresponding to the virtual processor is created and added to the global scheduling queue.

[0083] The scheduling entities in the emergency scheduling queue can be added in the following way:

[0084] Detect whether a preset emergency event occurs in the virtual processor corresponding to each scheduling entity in the global scheduling queue;

[0085] The scheduling entity corresponding to the virtual processor that has a preset emergency event is removed from the global scheduling queue and then added to the emergency scheduling queue.

[0086] In this embodiment, a global scheduling queue and an emergency scheduling queue can be created. When a virtual processor is created, a scheduling entity for the virtual processor can be created and stored in the global scheduling queue. The virtual processor can host various tasks, including tasks submitted by the virtualization layer and upper-layer applications. At any given moment, if the virtual processor's scheduling entity is in the global scheduling queue, it indicates that the virtual processor is not scheduled to run on a physical processor at that time. Because the virtual processor can host various tasks, some emergency events may occur that require the virtual processor to run for processing, such as an emergency event occurring in a process bound to the virtual processor, or an interrupt event requiring a response from the virtual processor.

[0087] Based on this, in this embodiment, it is possible to detect whether a preset emergency event has occurred in the virtual processor corresponding to each scheduling entity in the global scheduling queue. If a virtual processor has a preset emergency event, its corresponding scheduling entity can be removed from the global scheduling queue and added to the emergency scheduling queue.

[0088] Since the scheduler prioritizes selecting scheduling entities from the emergency scheduling queue, it can schedule these emergency events to run on virtual processors more quickly.

[0089] When a processor is running, it needs to respond quickly to events such as interrupts. If the processor does not respond to such events in a timely manner, it may cause serious problems to the system or even cause it to freeze. However, conventional virtual processor scheduling is limited by priority and time slice, and may not be able to guarantee this real-time performance. Therefore, it is necessary to respond quickly to such events. Based on this, in some embodiments, an emergency scheduling queue can be created to attach the scheduling entities of virtual processors that need to be processed urgently.

[0090] As an example, there can be one or more emergency dispatch queues. For example, there can be multiple queues, and multiple emergency dispatch queues with different priorities can be set as needed. This embodiment does not limit this.

[0091] As an example, the physical machine includes multiple physical processors, each of which is used to run a scheduler, and the method is applied to the scheduler running in each physical processor;

[0092] The emergency scheduling queue includes: a local emergency scheduling sub-queue corresponding to each of the physical CPUs, and a global emergency scheduling sub-queue; wherein, the priority of the virtual CPU corresponding to the scheduling entity in the local emergency scheduling sub-queue is higher than the priority of the virtual CPU corresponding to the scheduling entity in the global emergency scheduling sub-queue; or, the virtual CPU corresponding to the scheduling entity in the local emergency scheduling sub-queue is bound to the physical CPU corresponding to the local emergency scheduling sub-queue.

[0093] Determining whether a scheduling entity exists in the emergency scheduling queue includes:

[0094] Determine whether a scheduling entity exists in the target local emergency scheduling subqueue corresponding to the physical processor.

[0095] If so, select a scheduling entity from the target local emergency scheduling sub-queue;

[0096] If not, select a scheduling entity from the global emergency scheduling sub-queue.

[0097] In this embodiment, considering different levels of emergency events that may occur in practical applications, and considering that the physical machine may include multiple physical processors, this embodiment designs a corresponding scheduler for each physical processor to be responsible for the scheduling of virtual processors on that physical processor. Furthermore, a local emergency scheduling sub-queue, dedicated to each physical processor, and a global emergency scheduling sub-queue, which can correspond to each physical processor, can be designed. The scheduling entities in the local emergency scheduling sub-queue have higher priority, or are scheduling entities of virtual processors bound to the physical processor, such as virtual processors with local physical processor affinity that run more efficiently on the local physical processor.

[0098] The process of selecting a scheduling entity from the emergency dispatch queue can involve checking if the entity exists in the local emergency dispatch sub-queue. If it does, the entity is selected from the local emergency dispatch sub-queue first to ensure the fastest response time. If the local emergency dispatch sub-queue is empty, the global emergency dispatch sub-queue is checked, and a scheduling entity is selected from it.

[0099] In this embodiment, by introducing local and global emergency scheduling sub-queues, as well as considering priority and binding relationships, the efficiency and response speed of processor scheduling in the virtualization environment are improved, ensuring that virtual processors can be quickly and effectively scheduled to run when an emergency event is detected.

[0100] In some examples, scheduling the physical processor to run the target virtual processor includes:

[0101] Allocate the current runtime of the current scheduling cycle to the target virtual processor, and schedule the physical processor to run the target virtual processor based on the current runtime;

[0102] The method further includes:

[0103] If the target virtual processor completes its operation on the physical processor, the scheduling entity corresponding to the target virtual processor is re-added to the global scheduling queue.

[0104] In practical applications, runtime is the time slice. The time slice allocated to the target virtual processor can be flexibly set as needed. For example, a fixed time slice can be set for each scheduling cycle, or different time slices can be set for different scheduling cycles. The time slice can also be set according to the running status of the physical processor, etc. This embodiment does not limit this.

[0105] Taking CPU as an example, after the scheduling entity corresponding to the selected target virtual CPU (vCPU) is retrieved, the physical CPU can run the vCPU based on the time slice allocated to that vCPU. If the target vCPU can complete its execution normally on the physical CPU according to the allocated time slice, then after completing the execution of that time slice, the scheduling entity of the target vCPU can be added back to the global scheduling queue so that the target vCPU can be scheduled again in the future.

[0106] In some examples, allocating the current runtime of the current scheduling cycle to the target virtual processor includes:

[0107] The difference between the actual runtime of the target virtual processor in a historical scheduling period and the historical runtime allocated in the historical scheduling period is obtained, and the runtime of the target virtual processor in the current scheduling period is determined based on the difference.

[0108] As an example, when a vCPU runs on a physical CPU, it may prematurely encounter a trap due to various circumstances. A trap occurs when a vCPU needs to exit execution on the physical CPU due to a necessary condition, and the virtualization layer takes over the physical CPU. Therefore, a trap may result in the vCPU's actual runtime not reaching its allocated time slice, and there is also the possibility of the vCPU timing out. Based on this, this embodiment adopts a dynamic and fair time slice allocation strategy based on historical execution data.

[0109] As an example, the actual runtime of a virtual processor in each scheduling cycle can be implemented in several ways. For instance, the scheduler can start timing after scheduling the virtual processor to run on the physical processor. Alternatively, it can be implemented using a timer. This timer could be a preemption timer from existing hardware virtualization, or a software timer running within the virtual processor. When the virtual processor is scheduled to run on the physical processor, the software timer also starts. When the virtual processor escapes a trap, the actual runtime of the virtual processor can be obtained by the timer's duration, thus enabling a check for whether the virtual processor has timed out.

[0110] If there is a difference between the actual runtime of a historical scheduling period (which could be the previous scheduling period, or multiple previous scheduling periods, etc.) and the historical time slice allocated in the historical scheduling period, the local time slice can be determined based on this difference. The specific method can be flexibly configured as needed. For example, if the difference is positive, the current time slice can be reduced; if the difference is negative, the current time slice can be increased, and so on.

[0111] Alternatively, time slices can be allocated using other methods such as integration. For example, if the time slices in a historical scheduling cycle are used up, the time slices in the next scheduling cycle can be appropriately reduced; if there are any remaining time slices, they can be used to offset the time overused by setting corresponding integrations, and so on.

[0112] As can be seen from the above embodiments, by dynamically allocating time slices to the target virtual processor in each scheduling cycle based on historical execution data, fair time slice allocation can be achieved.

[0113] In some examples, the method may also include:

[0114] When scheduling the physical processor to run the target virtual processor based on the current runtime, a timer is started, and when the timer's duration is reached, the operation of the target virtual processor is stopped.

[0115] In this embodiment, a timer can be used to ensure that the virtual processor runs within its allocated time slice and automatically stops running when the time slice expires. When the timer reaches its set duration, an event is triggered, which instructs the physical processor to stop executing the current virtual processor. Upon receiving the timer event, the physical processor will stop the target virtual processor and return control to the scheduler, allowing the scheduler to continue scheduling the physical processor's execution.

[0116] There are several ways to implement a timer. As an example, it can be implemented using a preemption timer from existing hardware virtualization. Another example is running a software timer within the virtual processor. When the virtual processor is scheduled to run on the physical processor, the software timer also starts. If the virtual processor continues to run until the timer's duration expires, the target virtual processor can be stopped, effectively trapping it. There are several trapping methods. One example is pre-setting a corresponding interrupt event for the timer. When the timer's duration expires, the pre-set interrupt event is injected into the virtual processor, causing the virtualization layer to detect the interrupt event and stop the virtual processor.

[0117] As an example, the timer's duration can be configured as needed, for instance, based on the scheduler's scheduling cycle. For example, assuming the scheduler's cycle is 5ms, the timer's duration can be shorter than the scheduling cycle to ensure the scheduler's accuracy. Alternatively, the timer's duration can be determined based on the virtual processor's time slice to ensure the virtual processor exits promptly when its time slice expires.

[0118] This embodiment uses a timer to ensure that the target virtual processor runs within the allocated time slice, preventing the target virtual processor from using the physical processor for too long. Furthermore, the timer reduces the computational burden on the scheduler, eliminating the need for the scheduler to check the running time of the target virtual processor.

[0119] In some examples, the method further includes:

[0120] Create a global pause queue;

[0121] During the execution of the target virtual processor by the physical processor, if a pause event corresponding to the target virtual processor is detected, the execution of the target virtual processor is paused, and the scheduling entity of the target virtual processor is added to the global pause queue.

[0122] If the target virtual processor is detected to meet the preset wake-up conditions, the scheduling entity of the target virtual processor is removed from the global pause queue and added to the virtual processor scheduling queue.

[0123] As an example, under normal circumstances, the vCPU will continue to run on the physical CPU until the time slice allocated to the target virtual CPU expires. However, during operation, it may be paused for various reasons, such as the appearance of pause instructions like halt or mwait. These instructions will pause the execution of the target vCPU and return to the scheduler, waiting for some event (such as an interrupt) to reawaken the target virtual CPU. If these instructions need to be executed, it can be run in root mode. The specific method of executing these instructions can be implemented by the existing virtualization layer, which will not be elaborated again in this embodiment. After the target vCPU is paused, its scheduling entity can be added to the global pause queue. Subsequently, if the target virtual CPU is detected to meet the preset wake-up conditions, its scheduling entity can be removed from the global pause queue and added to the global scheduling queue, waiting for the target virtual CPU to be reawakened and run by the physical CPU.

[0124] In practical applications, preset wake-up conditions can be set according to actual needs. For example, it could be an IPI (Inter-Processor Interrupts) event sent to the target vCPU, or the expiration of a software LAPIC (Local Advanced Programmable Interrupt Controller) timer, or the receipt of certain active synchronization instructions sent to the target vCPU. The virtualization layer can detect whether the target virtual CPU meets the preset wake-up conditions.

[0125] In the above embodiments, since the scheduling entity of the target virtual CPU is added to the global pause queue when it is paused, it will not appear in the global scheduling queue, so the target virtual CPU will not be scheduled. By setting the corresponding wake-up conditions, when it needs to be woken up, its scheduling entity will be removed from the global pause queue and added to the virtual CPU scheduling queue, so that the target virtual CPU can participate in subsequent scheduling and execution.

[0126] As an example, in cases where the virtual CPU scheduling queue includes the aforementioned global scheduling queue or emergency scheduling queue, it is also possible to determine whether to add the corresponding scheduling entity to the global scheduling queue or the emergency scheduling queue after the target virtual CPU is reawakened, based on the urgency of the event sent to the target vCPU.

[0127] In some examples, the method further includes:

[0128] If a yield event corresponding to the target virtual processor is detected during the operation of the target virtual processor by the physical processor, the operation of the target virtual processor is stopped, and the scheduling entity of the target virtual processor is added to the global scheduling queue.

[0129] As an example, there can be various types of yield events, such as the `pause` instruction. In a multi-core processor, this is used to indicate that the processor is currently in a waiting state to optimize resource usage. It does not perform any specific function but rather indicates to the processor that this is a yieldable state. Based on this, in this embodiment, when a yield event corresponding to the target virtual processor is detected, such as when the `pause` instruction in the target vCPU is executed, the target vCPU can be directly yielded, that is, the operation of the target virtual CPU is stopped. The scheduling entity of the target virtual CPU can then be re-added to the global scheduling queue, allowing the target virtual CPU to participate in subsequent scheduling and execution.

[0130] The following examples illustrate this further. These examples use a CPU as an example; however, in practical applications, the CPU in this example can be replaced with other types of processors, such as a GPU, etc., and this example does not limit this.

[0131] Example 1: Normal operation scheduling of virtual CPUs in a lightweight virtualization architecture:

[0132] This embodiment can be applied to the virtualization layer, switching the running host operating system from root mode to virtualization mode, and creating at least one virtual CPU in virtualization mode. Since the newly created virtual CPU may not have a fixed physical CPU, a range of physical CPUs that the virtual CPU can run on can be set.

[0133] As an example, a scheduling priority can be set for a newly created virtual CPU. Its priority can be set to be no higher than the priority of other directly switched physical CPUs, but higher than the priority of background tasks.

[0134] As an example, you can set a time slice that a newly created virtual CPU can run on a physical CPU, so that the virtualization layer scheduler can allocate a certain amount of time slices to the virtual CPU in each scheduling cycle.

[0135] As an example, a scheduling function can be created for the scheduling class of the virtual CPU, including functions such as run function, dequeue, and enqueue. The running process of the virtual CPU is no different from that of the physical CPU after actual switching, so the run function can directly reuse the run function of the vCPU switched from the physical CPU.

[0136] Each physical CPU has a corresponding scheduling queue. Scheduling objects for scheduling virtual CPUs can be added to each physical CPU's scheduling queue. These scheduling objects can be added to the scheduling queues of all physical CPUs, or to the scheduling queues of only a subset of physical CPUs.

[0137] Each newly created virtual CPU corresponds to a vCPU structure, which contains a scheduling entity corresponding to the aforementioned scheduling class. This scheduling entity may include functions such as run functions, dequeue functions, and enqueue functions, as well as information such as the set time slice. The scheduling entity of each newly created virtual CPU can be attached to a global scheduling queue, which can be a data structure such as a linked list.

[0138] Each physical CPU can run the scheduler in the virtualization layer; the scheduler in each physical CPU can select tasks to run from the scheduling queue of that physical CPU. Based on the aforementioned priority settings for virtual CPUs, when a scheduling shell is selected from the scheduling queue, it means it's the turn of the newly created virtual CPU to run, and a scheduling entity (se) can be selected from the global scheduling queue; if a scheduling entity for a virtual CPU is selected, it is dequeued from the global scheduling queue. If the global scheduling queue is empty, the scheduler will select other tasks to run from the scheduling queue of the physical CPUs.

[0139] The selected target virtual CPU's scheduling entity `se` can be invoked to execute its specific set of execution functions. For example, this set of execution functions includes functions for dequeuing, executing, and enqueuing tasks for the scheduling entity `se`. Optionally, the execution process can begin by setting a timeout based on the time slice and historical execution information, followed by executing the specific task function. During the execution of the specific task function, it's possible to determine if a timeout has occurred. At the end of the specific task function, the actual execution time can be calculated for subsequent time slice adjustments by the scheduler.

[0140] To prevent the target virtual CPU from running for an extended period, time-slice checks can be implemented. Considering that vCPU execution may encounter traps due to various events, timeout checks can be set at the points of trapping.

[0141] Meanwhile, if the target vCPU does not exit for an extended period during execution, the consistency check cannot be performed, thus hanging other CPUs. Therefore, this embodiment can also set a timer, which can be implemented using an existing hardware virtualization preemption timer, or a software timer running within the vCPU. When the vCPU is scheduled to run on a physical CPU, the software timer also starts. This timer has a set duration, and it starts counting when the vCPU enters virtual CPU operation. The duration setting determines the vCPU's exit time. As an example, the timer can be pre-set with a corresponding interrupt event. When the timer's duration expires, the pre-set interrupt event is injected into the vCPU, causing the virtualization layer to detect the interrupt event and stop the vCPU's operation.

[0142] Therefore, the longest runtime without trapping for the target vCPU will not exceed the duration of this timer. Of course, too frequent trapping may also result in performance loss, so this duration can be set to be longer than the time slice corresponding to the newly created vCPU.

[0143] After a virtual CPU completes its current time slice, its scheduler can be re-enqueued into the global scheduling queue. This allows it to run if another physical CPU has an available time slice.

[0144] During each round of scheduling, the available time slice can be calculated at the beginning and the actual time slice used can be calculated at the end. For example, the time slice can be read at the end. If the time slice is exceeded, the next scheduling cycle will appropriately reduce the time slice used. Of course, if there is a surplus, an appropriate integral can be used to offset the time exceeded, but it cannot be too long, otherwise it will affect the fairness of scheduling.

[0145] Example 2: Emergency Virtual CPU Run Scheduling in a Lightweight Virtualization Architecture

[0146] Example 1 describes the scheduling process for normal operation of the virtual CPU; in other examples, emergency scheduling can also be implemented considering some special circumstances.

[0147] As an example, when the CPU is running, it needs to respond quickly to events such as interrupts or exceptions. If the virtual CPU is not run in time for such events, it may cause serious problems to the system, or even cause it to freeze. However, conventional virtual CPU scheduling is limited by priority and time slices, and may not be able to guarantee this real-time performance. Therefore, it is necessary to respond quickly to such events. Based on this, this embodiment can also create an emergency scheduling queue to attach the scheduling entity se of the virtual CPU that needs to be processed urgently.

[0148] In practical applications, if the vCPU receives an interrupt or exception while running on the physical CPU, such as an external interrupt, it can escape into the root mode of the virtualization layer to handle the interrupt event.

[0149] If some vCPUs are not running on the physical CPU, the virtualization layer can detect events sent to these vCPUs, such as interrupt events between vCPUs. If it is an emergency event, the vCPU's se can be mounted to the emergency scheduling queue so that the vCPU can be scheduled to run on the physical CPU as soon as possible.

[0150] Because emergency scheduling disrupts the original scheduler's time allocation rhythm and can even lead to priority inversion, the duration of emergency scheduling can be limited. For example, emergency scheduling queues with different priorities can be established. Each physical CPU can have a local emergency scheduling sub-queue, which needs to respond immediately. When scheduling, the local CPU will consider whether it has an event that needs to be run, even if its current priority is higher than the virtual CPU's priority. Secondly, a global emergency scheduling sub-queue can be set up for events that need rapid processing but have slightly lower priority. Virtual CPUs in this sub-queue will have priority over those in the aforementioned global scheduling queue, and all physical CPUs will prioritize this queue during scheduling. Furthermore, to ensure that virtual CPUs can run at full capacity during emergency scheduling, some virtual CPUs can be bound to a specific physical CPU for execution.

[0151] As an example, when the scheduler selects a scheduling entity, it first checks whether there is a local CPU emergency scheduling subqueue with a virtual CPU that needs to be executed immediately. If so, the virtual CPU needs to be selected to run first. Of course, since it is an emergency execution, the virtual CPU may have already run before and there is no available time slice. In this case, a minimum running time slice needs to be allocated to it to ensure that it can run normally.

[0152] If the local emergency scheduling subqueue is empty, a scheduling entity is selected from the global emergency scheduling subqueue. If the global emergency scheduling subqueue is not empty, a scheduling entity is selected from it to enable the corresponding virtual CPU to run; otherwise, a scheduling entity is selected from the global scheduling queue. That is, the order in which scheduling entities are selected is: local emergency scheduling queue, global emergency scheduling queue, global scheduling queue.

[0153] Example 3: Virtual CPU pause scheduling in a lightweight virtualization architecture:

[0154] In this embodiment, considering that the virtual CPU may pause operation for various reasons, the following pause operation scheduling embodiment may also be included:

[0155] As an example, when a virtual CPU is running on a physical CPU and a halt or mwait instruction occurs, the virtual CPU can escape into the virtualization's root mode, allowing the virtualization layer to execute functions related to the halt instruction. Simultaneously, the virtual CPU's scheduling entity can be attached to the global halt queue. Optionally, the virtual CPU's scheduling entity can contain a processing function, which can include a halt field. Setting this halt field to 1 indicates that the vCPU corresponding to the scheduling entity is in a halted state. This setting indicates that the vCPU is in a halted state.

[0156] Subsequently, the virtualization layer can check whether the paused vCPU meets the preset wake-up conditions. The wake-up conditions can be set as needed. For example, the virtualization layer may intercept interrupt events sent by other vCPUs to the paused vCPU, such as IPI interrupt events. The vCPU that issued the IPI interrupt event can escape into root mode, and the paused vCPU can be woken up to execute the interrupt event. Optionally, the processing flow can be to clear the halt field of the processing function in the scheduling entity to indicate that the vCPU has cleared the paused state, or the scheduling entity can be removed from the global pause queue and moved into the global scheduling queue.

[0157] In practical applications, the preset wake-up conditions can also be other things, such as the software lapic timer expiring, or the virtual CPU receiving an active synchronization instruction, which will also wake up the pause queue and perform the same operation.

[0158] For vCPUs that are trapped due to the pause instruction during operation, a yield flag can be set in the yield field of the scheduling entity to yield the execution of the current virtual CPU. The virtual CPU scheduling entity will not enter the pause queue, but will be moved to the global scheduling queue. The next time virtual CPU scheduling is performed, this virtual CPU can be selected to run.

[0159] As can be seen from the above embodiments, the CPU scheduling method for a physical machine is applied to the virtualization layer of the physical machine. The physical machine includes physical CPUs, each with a corresponding scheduling queue. The virtualization layer can switch the running host operating system from root mode to virtualization mode. In virtualization mode, at least one virtual CPU is created; a scheduling object is generated and added to the scheduling queue of the physical CPU; during the process of selecting a running task for the physical CPU based on its scheduling queue, if the scheduling object is selected, a target virtual CPU is selected from the at least one virtual CPU, and the physical CPU is scheduled to run the target virtual CPU. Based on this, the embodiments of this specification can directly create new virtual CPUs in the running host operating system. By adding scheduling objects to the scheduling queue of the physical CPU, when a scheduling object is selected, a target virtual CPU can be selected to run on the physical CPU. Therefore, the resources of the physical CPU can be utilized more efficiently, improving CPU utilization. Furthermore, the number of virtual CPUs created can be arbitrary, allowing for flexible provision of computing power from the physical CPU to the upper layer.

[0160] Accordingly, this specification also provides a processor scheduling system for a physical machine, as described in the foregoing embodiments, please see... Figure 2A As shown, the physical machine includes a physical processor and a host operating system running on the physical processor. A virtualization layer is implemented between the physical processor and the host operating system. In this embodiment, a processor scheduling system can be implemented in the virtualization layer, and the processor scheduling system executes the steps of the method described in any of the foregoing embodiments.

[0161] As an example, the virtualization layer can switch the running host operating system from root mode to virtualization mode when needed. For instance, the physical machine may include hardware resources, including at least one physical computing resource object and a physical address space containing host physical addresses. The host operating system runs on the physical computing resource object. Switching the running host operating system from root mode to virtualization mode includes: creating a memory page table to store the mapping between guest physical addresses in virtualization mode and host physical addresses in root mode; creating an information carrier object required for mode switching, which is used to synchronize context information between root mode and virtualization mode; and switching the running host operating system from root mode to virtualization mode based on the information carrier object and the memory page table.

[0162] In root mode, the physical address space contains the host physical address, which can be represented by HPA (Physical Address). The host physical address is the address of physical memory in the physical memory resources. In virtualization mode, the physical address space corresponds to the virtual address space, which contains the guest physical address. The guest physical address can be represented by GPA (Guest Physical Address). The guest physical address is the address of virtual memory in the virtual memory resources.

[0163] In this embodiment, the virtualization layer can create memory page tables, which are used to store the mapping relationship between the physical addresses of the guest machine in virtualization mode and the physical addresses of the host machine in root mode. Memory page tables can be represented by EPT (Extended Page Tables).

[0164] Optionally, creating a memory page table includes: establishing a page table structure corresponding to the memory page table; requesting the root page of the memory page table from the physical address space; generating the entry address of the memory page table based on the host physical address of the root page and adding it to the page table structure; and creating a multi-level memory page table based on the address range of the physical address space and the page granularity used to map the client physical address to the host physical address.

[0165] Optionally, information carrier objects required for mode switching can be created, including: for any physical computing resource object, a physical descriptor structure is created, which is used to save the context information of any physical computing resource in the root mode during mode switching; for any physical computing resource object, a virtualization descriptor structure is created and initialized, which is used to synchronize the context information in the physical descriptor structure during mode switching; for any physical computing resource object, a virtualization control structure is created and initialized to save the runtime information and runtime control information of any physical computing resource object in virtualization mode.

[0166] Optionally, the running host operating system can be switched from root mode to virtualization mode based on the information carrier object and memory page table. This includes: when switching the mode of the target physical computing resource object, saving the context information of the target physical computing resource object in root mode to the physical descriptor structure corresponding to the target physical computing resource object; synchronizing the values ​​of each register and the configuration information of the segment registers in the context information of the physical descriptor structure to the virtualization descriptor structure and virtualization control structure corresponding to the target physical computing resource object, respectively; and controlling the operation of the target physical computing resource object according to the virtualization descriptor structure, virtualization control structure, and memory page table to switch the running host operating system from root mode to virtualization mode.

[0167] Optionally, the context information of the target physical computing resource object in root mode is saved to the physical descriptor structure corresponding to the target physical computing resource object, including: saving the values ​​of each register in the context information and the stack top and stack bottom addresses of the second stack to the physical descriptor structure, wherein the second stack is the stack used by the target physical computing resource object in root mode; and switching the second stack used by the target physical computing resource object in root mode to the first stack corresponding to the target physical computing resource object in virtualization mode.

[0168] Optionally, the operation of the target physical computing resource object is controlled based on the virtualization descriptor structure, the virtualization control structure, and the memory page table, including: loading the values ​​of special-purpose registers in the virtualization control structure and the virtualization descriptor structure; injecting the runtime control information in the virtualization control structure into the target physical computing resource object and loading the values ​​of general-purpose registers in the virtualization descriptor structure; executing a mode switching instruction to control the target physical computing resource object to enter virtualization mode and start running from the first instruction, and performing memory management and access based on the memory page table during the running process.

[0169] Corresponding to the embodiments of the processor scheduling method for physical machines described above, this specification also provides embodiments of a processor scheduling device for physical machines and the computer equipment on which it is applied.

[0170] The embodiments of the processor scheduling device for physical machines described in this specification can be applied to computer devices, such as servers or terminal devices. The device embodiments can be implemented in software, hardware, or a combination of both. Taking software implementation as an example, as a logical device, it is formed by the processor reading the corresponding computer program instructions from non-volatile memory into memory for execution. From a hardware perspective, such as... Figure 3 The diagram shown is a hardware structure diagram of a computer device containing the processor scheduling device of the physical machine described in this specification. (Except for...) Figure 3 In addition to the processor 310, network interface 320, memory 330, and non-volatile memory 340 shown, the computer device where the processor scheduling device of the physical machine in the embodiment is located may also include other hardware depending on the actual function of the computer device, which will not be described in detail here.

[0171] like Figure 4 As shown, Figure 4 This specification is a structural diagram illustrating a processor scheduling device for a physical machine according to an exemplary embodiment. The physical machine includes a physical processor, and the physical processor corresponds to a scheduling queue. The device includes:

[0172] Module 41 is created to: switch the running host operating system from root mode to virtualization mode, and create at least one virtual processor in the virtualization mode;

[0173] Add module 42, used to: generate a scheduling object and add it to the scheduling queue of the physical processor;

[0174] The scheduling module 43 is used to: in the process of selecting running tasks for the physical processor based on the scheduling queue of the physical processor, if the scheduling object is selected, select the target virtual processor and schedule the physical processor to run the running task of the target virtual processor.

[0175] In other examples, the virtual processor corresponds to a scheduling entity, and the creation module is further configured to:

[0176] Create a virtual processor scheduling queue, which is used to store the scheduling entities corresponding to the virtual processors;

[0177] The selection module is used for:

[0178] Select a target scheduling entity from the virtual processor scheduling queue and determine the target virtual processor corresponding to the target scheduling entity.

[0179] In other examples, the virtual processor scheduling queue includes a global scheduling queue and an emergency scheduling queue, wherein the priority of the virtual processor corresponding to the scheduling entity in the global scheduling queue is lower than the priority of the virtual processor corresponding to the scheduling entity in the emergency scheduling queue.

[0180] The selection module is also used for:

[0181] Determine whether a target scheduling entity exists in the emergency scheduling queue;

[0182] If so, select the target scheduling entity from the emergency scheduling queue;

[0183] If not, select the target scheduling entity from the global scheduling queue.

[0184] In other examples, the creation module is also used for:

[0185] Create the scheduling entity corresponding to the virtual processor and add it to the global scheduling queue;

[0186] Detect whether a preset emergency event occurs in the virtual processor corresponding to each scheduling entity in the global scheduling queue;

[0187] The scheduling entity corresponding to the virtual processor that has a preset emergency event is removed from the global scheduling queue and then added to the emergency scheduling queue.

[0188] In other examples, the physical machine includes multiple physical processors, each of which is used to run a scheduler, and the device is applied to the scheduler running in each physical processor;

[0189] The emergency scheduling queue includes: a local emergency scheduling sub-queue corresponding to each of the physical CPUs, and a global emergency scheduling sub-queue; wherein, the priority of the virtual CPU corresponding to the scheduling entity in the local emergency scheduling sub-queue is higher than the priority of the virtual CPU corresponding to the scheduling entity in the global emergency scheduling sub-queue; or, the virtual CPU corresponding to the scheduling entity in the local emergency scheduling sub-queue is bound to the physical CPU corresponding to the local emergency scheduling sub-queue.

[0190] Determining whether a scheduling entity exists in the emergency scheduling queue includes:

[0191] Determine whether a scheduling entity exists in the target local emergency scheduling subqueue corresponding to the physical processor.

[0192] If so, select a scheduling entity from the target local emergency scheduling sub-queue;

[0193] If not, select a scheduling entity from the global emergency scheduling sub-queue.

[0194] In other examples, the scheduling module is also used for;

[0195] Allocate the current runtime of the current scheduling cycle to the target virtual processor, and schedule the physical processor to run the target virtual processor based on the current runtime;

[0196] If the target virtual processor completes its operation on the physical processor, the scheduling entity corresponding to the target virtual processor is re-added to the global scheduling queue.

[0197] In other examples, the scheduling module is also used for;

[0198] The difference between the actual runtime of the target virtual processor in a historical scheduling period and the historical runtime allocated in the historical scheduling period is obtained, and the runtime of the target virtual processor in the current scheduling period is determined based on the difference.

[0199] In other examples, the scheduling module is also used for;

[0200] When scheduling the physical processor to run the target virtual processor based on the current runtime, a timer is started, and when the timer's duration is reached, the operation of the target virtual processor is stopped.

[0201] In other examples, the device also includes a pause module for:

[0202] Create a global pause queue;

[0203] During the process of the physical CPU running the target virtual CPU, if a pause event corresponding to the target virtual CPU is detected, the operation of the target virtual CPU is paused, and the scheduling entity of the target virtual CPU is added to the global pause queue.

[0204] If the target virtual CPU is detected to meet the preset wake-up conditions, the scheduling entity of the target virtual CPU is removed from the global pause queue and added to the virtual CPU scheduling queue.

[0205] In other examples, the device also includes a yield module for:

[0206] If a yield event corresponding to the target virtual CPU is detected during the operation of the target virtual CPU by the physical CPU, the operation of the target virtual CPU is stopped, and the scheduling entity of the target virtual CPU is added to the global scheduling queue.

[0207] The specific implementation process of the functions and roles of each module in the processor scheduling device of the above-mentioned physical machine can be found in the implementation process of the corresponding steps in the processor scheduling method of the above-mentioned physical machine, and will not be repeated here.

[0208] Accordingly, this specification also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the aforementioned physical machine processor scheduling method embodiment.

[0209] Accordingly, embodiments of this specification also provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of an embodiment of a processor scheduling method for a physical machine.

[0210] Accordingly, embodiments of this specification also provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of an embodiment of a processor scheduling method for a physical machine.

[0211] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of the solution in this specification according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0212] The above embodiments can be applied to one or more computer devices. The computer device is a device that can automatically perform numerical calculations and / or information processing according to pre-set or stored instructions. The hardware of the computer device includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0213] The computer device can be any electronic product that can interact with the user, such as a personal computer, tablet computer, smartphone, personal digital assistant (PDA), game console, interactive network television (IPTV), smart wearable device, etc.

[0214] The computer equipment may also include network equipment and / or user equipment. The network equipment includes, but is not limited to, a single network server, a server group consisting of multiple network servers, or a cloud based on cloud computing consisting of a large number of hosts or network servers.

[0215] The network in which the computer device is located includes, but is not limited to, the Internet, wide area network, metropolitan area network, local area network, and virtual private network (VPN).

[0216] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0217] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.

[0218] While this specification contains numerous specific implementation details, these should not be construed as limiting the scope of any invention or the scope of the claims, but rather are primarily intended to describe features of specific embodiments of a particular invention. Certain features described in the various embodiments herein may also be implemented in combination in a single embodiment. Conversely, various features described in a single embodiment may also be implemented separately in various embodiments or in any suitable sub-combination. Furthermore, while features may function in certain combinations as described above and even initially claimed in this way, one or more features from a claimed combination may be removed from that combination in some cases, and a claimed combination may refer to a sub-combination or a variation thereof.

[0219] The terms "specific example" or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with the embodiments or examples, which are included in at least one embodiment or example of this specification. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0220] Other embodiments of this specification will readily occur to those skilled in the art upon consideration of the specification and practice of the invention claimed herein. This specification is intended to cover any variations, uses, or adaptations that follow the general principles of this specification and include common knowledge or customary techniques in the art not claimed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this specification are indicated by the following claims.

[0221] It should be understood that this specification is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this specification is limited only by the appended claims.

[0222] The above description is merely a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of protection of this specification.

Claims

1. A processor scheduling method for a physical machine, the physical machine including physical processors, each physical processor corresponding to a scheduling queue, the method comprising: Switch the running host operating system from root mode to virtualization mode, and create at least one virtual processor in virtualization mode; Generate a scheduling object and add it to the scheduling queue of the physical processor; During the process of selecting a running task for the physical processor based on the scheduling queue of the physical processor, if the scheduling object is selected, a target virtual processor is selected from the at least one virtual processor, and the physical processor is scheduled to run the target virtual processor.

2. The method according to claim 1, wherein the virtual processor corresponds to a scheduling entity, and the method further includes: Create a virtual processor scheduling queue, which is used to store the scheduling entities corresponding to the virtual processors; Selecting a target virtual processor from the at least one virtual processor includes: Select a target scheduling entity from the virtual processor scheduling queue and determine the target virtual processor corresponding to the target scheduling entity.

3. The method according to claim 2, wherein the virtual processor scheduling queue includes a global scheduling queue and an emergency scheduling queue, and the priority of the virtual processor corresponding to the scheduling entity in the global scheduling queue is lower than the priority of the virtual processor corresponding to the scheduling entity in the emergency scheduling queue; The step of selecting a target scheduling entity from the virtual processor scheduling queue includes: Determine whether a scheduling entity exists in the emergency dispatch queue; If so, select the target scheduling entity from the emergency scheduling queue; If not, select the target scheduling entity from the global scheduling queue.

4. The method of claim 3, further comprising, after the step of creating at least one virtual processor: Create the scheduling entity corresponding to the virtual processor and add it to the global scheduling queue; Detect whether a preset emergency event occurs in the virtual processor corresponding to each scheduling entity in the global scheduling queue; The scheduling entity corresponding to the virtual processor that has a preset emergency event is removed from the global scheduling queue and then added to the emergency scheduling queue.

5. The method according to claim 3, wherein the physical machine comprises a plurality of physical processors, each of the physical processors being used to run a scheduler, and the method is applied to the scheduler running in each physical processor; The emergency dispatch queue includes: Each physical processor is associated with a local emergency scheduling subqueue and a global emergency scheduling subqueue; wherein, the priority of the virtual processor corresponding to the scheduling entity in the local emergency scheduling subqueue is higher than the priority of the virtual processor corresponding to the scheduling entity in the global emergency scheduling subqueue; or, the virtual processor corresponding to the scheduling entity in the local emergency scheduling subqueue is bound to the physical processor corresponding to the local emergency scheduling subqueue. Determining whether a scheduling entity exists in the emergency scheduling queue includes: Determine whether a scheduling entity exists in the target local emergency scheduling subqueue corresponding to the physical processor. If so, select a scheduling entity from the target local emergency scheduling sub-queue; If not, select a scheduling entity from the global emergency scheduling sub-queue.

6. The method according to claim 3, wherein scheduling the physical processor to run the target virtual processor includes; Allocate the current runtime of the current scheduling cycle to the target virtual processor, and schedule the physical processor to run the target virtual processor based on the current runtime; The method further includes: If the target virtual processor completes its operation on the physical processor, the scheduling entity corresponding to the target virtual processor is re-added to the global scheduling queue.

7. The method according to claim 6, wherein allocating the current runtime of the current scheduling cycle to the target virtual processor comprises: The difference between the actual runtime of the target virtual processor in a historical scheduling period and the historical runtime allocated in the historical scheduling period is obtained, and the runtime of the target virtual processor in the current scheduling period is determined based on the difference.

8. The method according to claim 7, further comprising: When scheduling the physical processor to run the target virtual processor based on the current runtime, a timer is started, and when the timer's duration is reached, the operation of the target virtual processor is stopped.

9. The method according to claim 2, further comprising: Create a global pause queue; During the execution of the target virtual processor by the physical processor, if a pause event corresponding to the target virtual processor is detected, the execution of the target virtual processor is paused, and the scheduling entity of the target virtual processor is added to the global pause queue. If the target virtual processor is detected to meet the preset wake-up conditions, the scheduling entity of the target virtual processor is removed from the global pause queue and added to the virtual processor scheduling queue.

10. The method according to claim 3, further comprising: If a yield event corresponding to the target virtual processor is detected during the operation of the target virtual processor by the physical processor, the operation of the target virtual processor is stopped, and the scheduling entity of the target virtual processor is added to the global scheduling queue.

11. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 10.

12. A processor scheduling system for a physical machine, the physical machine including a physical processor and a host operating system running on the physical processor, a virtualization layer implemented between the physical processor and the host operating system, the virtualization layer including the processor scheduling system, the processor scheduling system being used to perform the steps of the method of any one of claims 1 to 10.

13. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method of any one of claims 1 to 10.

14. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method of any one of claims 1 to 10.

Images