VCPU scheduling method based on microkernel Hypervisor

Abstract

The invention discloses a VCPU (Virtual Central Processing Unit) scheduling method based on a microkernel Hypervisor, which comprises the following steps of: calling a clock processing function to schedule a VCPU every time a new scheduling time slice is entered, and judging whether the VCPU has a potential synchronization problem by the clock processing function through whether the scheduled VCPU is started to monitor, whether a current thread is in a kernel mode and whether thread switching exists in sequence; the method comprises the following steps of: judging whether a VCPU (Virtual Central Processing Unit) has a potential synchronization problem, if the VCPU does not have the potential synchronization problem, performing normal scheduling, if the potential synchronization problem exists, acquiring a value and a change condition of a preemptcount to judge whether the VCPU is the synchronization problem VCPU, and if the VCPU is the synchronization problem VCPU, adding an additional time slice to enable the currently scheduled VCPU to continue to run so as to solve the synchronization problem. According to the method, the VCPU scheduling is carried out by using the microkernel Hypervisor based on the lock detection and collaborative fair scheduling strategy, so that the performance overhead caused by lock competition in the Hypervisor can be reduced, the synchronization performance is improved, the source code of a client operating system does not need to be modified, and the stability and portability of the system are ensured.

Description

Technical Field

[0001] The present invention belongs to the field of microkernel technology, and more specifically, relates to a VCPU scheduling method based on a microkernel Hypervisor. Background Art

[0002] Hypervisor (virtual machine monitor) is a virtualization technology that allows the creation and management of multiple virtualized computing environments on a physical computer, each of which can run independent operating systems and applications. The role of Hypervisor is similar to that of a virtualized operating system. It allocates computing resources and isolates different virtual machines so that they can run simultaneously on the same physical computer without interfering with each other. Type 1 Hypervisor has no host operating system. It runs directly on physical hardware, directly manages various physical resources, and manages and runs client operating systems. Type 2 Hypervisor, its parasitic host operating system has full control over the hardware platform and resources (including CPU and physical memory, etc.).

[0003] In a virtualized environment, due to the semantic gap between the hypervisor and the client operating system, the optimization mechanism of the client operating system for the kernel spin lock fails, resulting in synchronization performance problems such as LHP (Lock Holder Preemption) and LWP (Lock Waiter Preemption), which leads to serious synchronization overhead and reduces system performance. In order to solve the synchronization performance problem, some technical solutions have been proposed in the industry. Among them, the full virtualization solution has received great attention because it does not require modifying the client operating system source code. Among the full virtualization solutions, representative solutions include VCPU synchronization scheduling solution, driver detection LHP solution and IPI-driven scheduling solution.

[0004] The VCPU synchronous scheduling scheme is to allocate the VCPU (virtual central processing unit) of the client operating system to different physical CPUs for synchronous scheduling, so as to achieve their simultaneous operation or stop, fundamentally eliminating the LHP and LWP problems. Although the synchronous scheduling scheme has significant advantages in eliminating synchronization problems such as LHP and LWP, the implementation of this strategy is also accompanied by some challenges and potential negative effects. Although this scheme can fundamentally eliminate the LHP and LWP problems, it has the following shortcomings: First, it requires that the number of physical CPUs is not less than the number of VCPUs of the virtual machine, which may cause certain pressure on the system hardware resources. In addition, the introduction of synchronous scheduling may lead to CPU fragmentation, making it impossible to fully utilize the physical CPU resources, thereby affecting the overall efficiency of the system. In addition, problems such as priority inversion and scheduling delays may also occur, affecting the stability and performance of the system.

[0005] The driver-detected LHP solution introduces a special driver into the client operating system, so that the system can identify "safe points" where spin locks are not held and prohibit preemption at non-"safe points", thereby avoiding the LHP problem. This method also introduces the concept of preemption windows to ensure fairness in scheduling. Although this solution can effectively identify the holder of the lock, the configuration is cumbersome and requires the installation of special lock-free device drivers, which increases the complexity of implementation.

[0006] The IPI-driven scheduling scheme is based on the fact that the IPI signal is usually triggered before some spin locks are released. By using the IPI signal, the lock holder can be dynamically identified at the Hypervisor layer and the time for it to be preempted can be delayed to avoid LHP. Although this scheme can dynamically identify the lock holder at the Hypervisor layer and make certain scheduling processing, it can only identify user-level synchronization based on IPI interrupts and is invalid for other types of kernel spin locks. Summary of the invention

[0007] The purpose of the present invention is to overcome the shortcomings of the prior art and provide a VCPU scheduling method based on a microkernel Hypervisor. The microkernel Hypervisor performs VCPU scheduling based on lock detection and collaborative fair scheduling strategy, which can reduce the performance overhead caused by lock contention in the Hypervisor, thereby improving synchronization performance. At the same time, there is no need to modify the client operating system source code, thereby ensuring the stability and portability of the system.

[0008] In order to achieve the above-mentioned object of the invention, the present invention is based on a VCPU scheduling method of a microkernel Hypervisor. Whenever a new scheduling time slice is entered, the microkernel Hypervisor calls a clock processing function to schedule the VCPU, which specifically includes the following steps:

[0009] S1: The microkernel Hypervisor obtains the currently scheduled VCPU;

[0010] S2: Let the number of time slices of the scheduled VCPU be N=N-1;

[0011] S3: Determine whether the scheduled VCPU has started monitoring. If not, proceed to step S4; otherwise, proceed to step S19;

[0012] S4: Determine whether the current thread of the scheduled VCPU is in kernel state. If not, proceed to step S5; otherwise, proceed to step S6;

[0013] S5: Mark the scheduled VCPU as a normal VCPU, and then go to step S18;

[0014] S6: Determine whether there is a thread switch in the scheduled VCPU. If a thread switch occurs, go to step S7; otherwise, go to step S9;

[0015] S7: Mark the scheduled VCPU as a normal VCPU, and then proceed to step S8;

[0016] S8: Turn off the monitoring of the VCPU that is enabled for monitoring, and proceed to step S19;

[0017] S9: Read the value of the preemption counter preempt_count from the thread information structure thread_info of the scheduled VCPU;

[0018] S10: Determine whether preempt_count=0, if yes, go to step S18, otherwise go to step S11;

[0019] S11: determining whether the value of preempt_count changes in the current time slice according to the historical record of the preemption counter preempt_count, if it changes, no operation is performed, if it does not change, determining the number of time slices in which preempt_count continuously maintains the current value;

[0020] S12: Determine whether the monitoring time of the scheduled VCPU reaches the preset upper limit, if yes, proceed to step S13, otherwise proceed to step S19;

[0021] S13: Determine whether the scheduled VCPU is a lock-related VCPU. If yes, proceed to step S14, otherwise proceed to step S17; the method for determining the lock-related VCPU is: if the number of time slices during which the preempt_count value of the scheduled VCPU continuously remains at the current value is greater than a preset threshold, then it is not a lock-related VCPU, otherwise it is a lock-related VCPU;

[0022] S14: Mark the scheduled VCPU as a synchronization problem VCPU;

[0023] S15: adding extra time slices to the scheduled VCPU. The number of extra time slices is determined according to the actual situation. The number of times the time slice of the scheduled VCPU is increased is increased by 1.

[0024] S16: Turn off the monitoring of the VCPU that is enabled for monitoring, and proceed to step S21;

[0025] S17: Mark the scheduled VCPU as an exception VCPU, and then proceed to step S18;

[0026] S18: Save the remaining time slice of the scheduled VCPU, then call the VCPU calling function to re-determine the scheduled VCPU; the VCPU calling function includes the following steps:

[0027] 1) Determine whether the scheduled VCPU is a synchronization problem VCPU. If so, proceed to step 2), otherwise proceed to step 3);

[0028] 2) Determine whether the number of times the time slice of the scheduled VCPU increases reaches the preset upper limit, if yes, proceed to step 8), otherwise proceed to step 4);

[0029] 3) Determine whether the scheduled VCPU is an exception VCPU, if yes, go to step 8), otherwise go to step 4);

[0030] 4) Determine whether the current thread of the scheduled VCPU is in kernel state, if yes, proceed to step 5), otherwise proceed to step 8);

[0031] 5) Read the value of the preemption counter preempt_count from the thread information structure thread_info of the scheduled VCPU;

[0032] 6) Determine whether preempt_count=0, if yes, proceed to step 8), otherwise proceed to step 7);

[0033] 7) Start monitoring the current thread of the scheduled VCPU, record the value of preempt_count and monitoring duration in each time slice; this scheduling is completed;

[0034] 8) Mark the scheduled VCPU as a normal VCPU;

[0035] 9) Clear the number of times the time slice of the scheduled VCPU is increased to 0;

[0036] 10) The currently scheduled VCPU is scheduled out of the VCPU scheduling queue, and then the first VCPU is read from the VCPU scheduling queue as the new scheduled VCPU; this scheduling is completed;

[0037] S19: Determine whether the number of time slices of the scheduled VCPU is 0, if yes, proceed to step S20, otherwise proceed to step S21;

[0038] S20: calling the VCPU calling function to redetermine the scheduled VCPU, and proceeding to step S21;

[0039] S21: Resume the operation of the currently scheduled VCPU and wait for the next time slice.

[0040] The present invention is based on a VCPU scheduling method of a microkernel Hypervisor. Whenever a new scheduling time slice is entered, a clock processing function is called to schedule the VCPU. The clock processing function determines whether the VCPU has potential synchronization problems by checking whether monitoring of the scheduled VCPU has been started, whether the current thread is in the kernel state, and whether there is a thread switch. If not, normal scheduling is performed. If there is a potential synchronization problem, the value of the preemption counter preempt_count and its change are obtained to determine whether it is a VCPU with synchronization problems. If so, an additional time slice is added to allow the currently scheduled VCPU to continue running to solve the synchronization problem.

[0041] The present invention has the following beneficial effects:

[0042] 1) The present invention utilizes the characteristics and hardware support provided by the ARMv8 architecture to provide an LHP / LWP detection strategy in a fully virtualized manner, which can improve the synchronization performance of the system, reduce the lock waiting time, and reduce lock contention by avoiding algorithm execution related VCPUs and maintaining fair CPU resource allocation, thereby improving the stability and performance of the virtual machine;

[0043] 2) The present invention maintains different running times of VCPUs, thereby more effectively allocating and utilizing physical CPU resources, avoiding resource waste and fragmentation, enabling the virtualization system to run more tasks under the same hardware configuration, and improving the overall performance of the system;

[0044] 3) The present invention does not require additional drivers or configurations, and is simpler and more direct to implement; and is lightweight: since the detection and scheduling algorithms themselves are simple in design, they are relatively easy to deploy and integrate into existing virtualization systems, reducing the complexity of deployment and maintenance. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1It is a schematic diagram of LHP and LWP problems that may be encountered in non-virtualized and virtualized environments;

[0046] Figure 2 It is a schematic diagram of two-stage address translation in a virtualized environment;

[0047] Figure 3 It is a schematic diagram of the lock state counter change of the VCPU in the present invention;

[0048] Figure 4 It is a flowchart of a specific implementation of the clock processing function in the present invention;

[0049] Figure 5 It is a flow chart of a specific implementation method of the VCPU calling function in the present invention. DETAILED DESCRIPTION

[0050] The specific implementation of the present invention is described below in conjunction with the accompanying drawings so that those skilled in the art can better understand the present invention. It should be noted that in the following description, when the detailed description of known functions and designs may dilute the main content of the present invention, these descriptions will be omitted here.

[0051] In order to better illustrate the technical solution of the present invention, the technical principles involved in the present invention are first briefly described.

[0052] First, the time required for VCPU scheduling is analyzed. In VCPU scheduling, if a VCPU holding a lock or waiting for a lock is preempted, other VCPUs trying to perform operations on the same lock will be in a busy waiting state. When the preempted VCPU is scheduled for execution again, the waiting time depends on its position in the scheduling queue. Assume that all preempted VCPUs holding or waiting for locks will not be preempted again before the next time they are scheduled for execution. Assume that there are n VCPUs in the scheduling queue (including the currently executing VCPU), and the average execution time of each VCPU scheduling is T execution =T slice ×N slice , T slice Indicates the size of a time slice, N slice Indicates the number of time slices. The time required for the lock holder or the lock waiting VCPU to release the lock is T release for:

[0053]

[0054] In the above formula, p j represents the probability that the VCPU holding or waiting for the lock is in the jth position in the scheduling queue. When j = 0, it means that it is not preempted and is running, and p 0 represents the probability of not being preempted. Tcritical Represents the time required to execute the key area protected by the lock, usually around 5us, which is much shorter than the average scheduling execution time T execution . You can use T release Understood as the total time a lock holder or lock waiter VCPU releases the lock.

[0055] The time required to synchronize the waiting thread running in the lock waiter VCPU depends on the position of the thread in the lock wait queue. The time required for the waiting thread to complete synchronization is T sync , which is defined as follows:

[0056]

[0057] In the above formula, q i represents the probability of the waiting thread being in the i-th position in the lock waiting queue. i=0 means that the thread does not need to wait and can acquire the lock immediately once the lock is released. sync It is understood as the total time a lock waiter VCPU waits for the lock to be released.

[0058] In a virtualized environment, CPU resource sharing is done in a time slice rotation mode. Therefore, when the critical area protected by the lock is available, the waiting thread in the lock waiter VCPU may be waiting in the scheduling queue for the next scheduling. The waiting scheduling time can be defined as T wait , the total time for waiting threads to execute non-critical area codes can be defined as T non-critical , so the total time required to wait for the thread to complete the task is T, which is defined as follows:

[0059] T=T non-critical +T critical +T wait +T sync

[0060]

[0061] T non-critical and T critical Determined by the load characteristics of the client operating system, T wait Affected by the client operating system scheduling policy, T sync Affected by the host operating system's scheduling policy for VCPU. execution Much larger than T critical , so the synchronization overhead T sync It accounts for a large proportion of the waiting thread completion time T, which directly affects the performance of the system. sync Among the components of execution and p j Affected by the host operating system scheduling policy. executionThe larger the value, the greater the synchronization overhead, so lower T execution The performance degradation can be alleviated to some extent, but the smaller T execution This will seriously damage cache efficiency. Therefore, by improving p 0 To optimize synchronization performance, p 0 It indicates the probability of not being preempted, so the VCPU scheduling strategy in the present invention selects the LHP / LWP avoidance scheduling strategy, that is, minimizes the probability of lock holders and lock waiters being preempted.

[0062] In the present invention, the LHP / LWP detection method adopts some mechanisms in the client operating system. In the kernel of the Linux operating system, each thread is managed by a data structure called a thread information structure thread_info. In this data structure, there is a field called a preemption counter preempt_count, which is used to determine whether the thread can be forcibly preempted. When the value of the preemption counter is 0, it means that other tasks are allowed to preempt the current thread; and when the value is not 0, it is usually because the thread is occupying system resources (such as spin locks) and cannot be preempted. In the operating system kernel, if an external interrupt (such as a clock interrupt) triggers thread scheduling, the scheduler will first check the preemption counter value of the currently running thread. Only when the counter is 0 will the scheduler immediately switch threads; otherwise, the current thread will continue to execute. The value of the preemption counter will be dynamically modified by spin lock related operations: before the thread attempts to acquire the spin lock, the counter will increase by 1; after releasing the spin lock, the counter will be subtracted by 1. This mechanism ensures that the preemption counter is always greater than 0 for threads holding or waiting for spin locks, thereby avoiding performance problems when holding or waiting for locks for a long time (that is, avoiding LHP and LWP problems).

[0063] Figure 1 The following is a diagram of LHP and LWP problems that may be encountered in non-virtualized and virtualized environments. Figure 1 The optimization mechanism for synchronization performance in Linux of thread or VCPU lock behavior in non-virtualized and virtualized environments and the LHP and LWP problems that may be encountered in virtualized environments are shown. In a non-virtualized environment, when thread 1 acquires the lock, it will not be preempted by other threads until the lock is released. If there are other threads waiting for this lock, they will not be preempted until the lock is released. Therefore, once the lock is released, thread 2 (the first lock waiter) can immediately acquire the lock without a long waiting time (i.e., idling time).

[0064] In a virtualized environment, the LHP problem refers to when a thread in VCPU1 holds a lock while a thread in VCPU2 is waiting for the lock. Although the thread in VCPU1 will not be preempted, the VCPU may be switched for some reason, resulting in a longer lock holding time, which in turn causes VCPU2 waiting for the lock to idle and wait. This waiting time will be affected by the scheduling of VCPU1 holding the lock.

[0065] In a virtualized environment, the LWP problem refers to when the thread in VCPU1 holds the lock, the thread in VCPU2 is the first thread waiting for the lock, and the thread in VCPU3 is the second thread waiting for the lock. When VCPU1 releases the lock, according to the order of the waiting queue, VCPU2, which is the first to wait for the lock, should acquire the lock and release it before VCPU3, which is the second to wait for the lock, can acquire the lock. If VCPU2 is switched before acquiring the lock, then even though the lock is available, VCPU3 cannot acquire the lock and can only wait in vain. This causes the time VCPU3 waits for the lock to depend not only on its position in the waiting queue, but also on the scheduling of the VCPU waiting in front.

[0066] In the ARMv8 architecture, the kernel stack size for each thread is also fixed, usually 8KB. In this architecture, the preempt_count is defined in the thread_info data structure, and the thread_info of each thread is stored in its corresponding kernel stack. In order for the kernel to quickly find the thread_info of the current thread, this information is usually stored in this special way. The thread_info is usually stored at the bottom of the kernel stack. The address allocation of the kernel stack is aligned according to the stack size, so the address of the thread_info can be calculated by the current kernel stack pointer (such as the SP_EL1 register). The usual practice is to calculate the address of the thread_info in the following way: SP_EL1&~(8K-1), where 8K represents the size of the kernel stack. This calculation method ensures that the location of the thread_info in the kernel stack can be accurately found. This method of the Linux kernel can efficiently manage and access key information of each thread, such as preempt_count, without excessive addressing overhead.

[0067] After the Hypervisor obtains the address of thread_info, it can obtain the address of preempt_count through a simple offset calculation. preempt_count is a field in the thread_info structure, which is used to identify whether the thread can be preempted. Since the address of preempt_count only requires the pointer value of the kernel stack, after obtaining the address of preempt_count in the Hypervisor, since the address is a GVA (guest operating system virtual address), it is necessary to convert the address to an HVA (host operating system virtual address) that the Hypervisor can access. The Hypervisor can then read the value of preempt_count to understand whether the virtual CPU (VCPU) is holding a lock or waiting for a lock, thereby adjusting the scheduling strategy to optimize the system's performance and responsiveness.

[0068] Since the Hypervisor obtains the GVA (Guest Virtual Address) address of preempt_count, it needs the HVA (Host Virtual Address) address to access it correctly. Converting a GVA to an HVA requires the following steps: GVA->GPA (Guest Physical Address)->HPA (Host Physical Address)->HVA. Figure 2 This is a schematic diagram of two-stage address translation in a virtualized environment. Figure 2 As shown in the figure, the specific process of two-stage address translation in a virtualized environment is as follows:

[0069] GVA->GPA: The conversion from GVA to GPA is the address translation of Stage 1 and is maintained by the client operating system. The Hypervisor first obtains the page table base address (GPA) of the client operating system stored in the TTBRx_EL1 register, converts the page table base address to HVA, and then converts the GVA of preempt_count to GPA by accessing this page table. This process is similar to emulating the address translation of the memory management unit (MMU).

[0070] GPA->HPA: The conversion from GPA to HPA is the address conversion of Stage 2, which is maintained by the host operating system for the guest operating system. Before the virtual machine is started, the host operating system allocates a virtual address space for the guest operating system, and then converts the HVA of this space to HPA, and then establishes the mapping relationship between GPA and HPA. Therefore, the guest operating system can directly convert GPA to HPA through information such as the space base address and offset address, without simulating the address conversion process of the MMU.

[0071] HVA->HPA / HPA->HVA: The address translation from HVA to HPA and from HPA to HVA is maintained and controlled by the host operating system, without the need to simulate the address translation process of the MMU. The host operating system directly converts HVA to HPA or HPA to HVA based on the address area and offset address information divided by the system.

[0072] During the LHP / LWP detection process, since the Hypervisor needs to frequently access the preemption counter preempt_count, in order to improve efficiency, a cache area can be allocated to record the mapping information of preempt_count's GVA to HVA. When address conversion is required, it can be directly searched from the cache area to avoid repeated GVA to GPA and GPA to HPA conversion processes, thereby reducing system overhead and latency while ensuring the performance and stability of the virtualization environment. A GVA can be bound to a unique HVA address through the virtual machine id, VCPUid, and TTBRx_EL1 page table base address GPA.

[0073] Next, the relationship between the preempt_count value and the spin lock state (locked, waiting, unlocked) of the VCPU is tested and analyzed. In the present invention, the client operating system kernel code is modified to set a lock state counter lock_count for each VCPU to record the instantaneous spin lock state of the current running thread of the VCPU. Figure 3This is a schematic diagram of the lock state counter change of the VCPU in the present invention. When the system starts, all lock state counters are initialized to 0, indicating that the current thread on all VCPUs is in the "unlocked" state. Before the thread attempts to acquire the lock, the lock state counter lock_count will increase by 1, indicating that the thread is in the "waiting" state. After successfully acquiring the lock, the lock state counter lock_count increases by 1 again, indicating that the thread currently holds the lock. Since the lock state counter lock_count increases by 2 each time the lock is acquired, it decreases by 2 when the lock is released. This counting method makes it simple and clear to determine the lock state of the thread: the lock state counter value of 0 indicates "unlocked", an odd number indicates "waiting", and an even number indicates "holding the lock". In addition, the number of locks held by the thread can be known by shifting the lock state counter lock_count right by one position. The value of the lock state counter lock_count can be passed to the Hypervisor through shared memory or a notification mechanism.

[0074] The test results show that most virtual CPUs (VCPUs) with non-zero preempt_count values ​​are in a "locked" or "waiting" state. The value of preempt_count can approximately reflect the number of spin locks held by the VCPU. Specifically, if a VCPU is a lock holder, the value of preempt_count indicates the number of spin locks held; if it is a lock waiter, preempt_count-1 indicates the number of spin locks held. Therefore, the present invention defines this type of VCPU as a "potential lock holder or lock waiter".

[0075] However, there is an exception, that is, the preempt_count value is non-0, but the corresponding VCPU may be in the "unlocked" state, because preempt_count is not only used for spin lock counting. In other non-preemptible situations, such as interrupt processing, temporary kernel mapping, page fault interrupts, etc., preempt_count will also be set to non-0 to prevent preemption. Through testing and analysis, it is found that in the case of non-spin locks, preempt_count usually remains at a fixed value for a long time and changes slowly; while in the case of spin locks, preempt_count changes more frequently. This is because the busy waiting feature of the spin lock requires the process holding the lock to release the lock as soon as possible, so the holding time of the spin lock is usually very short, about the microsecond level, resulting in more frequent changes in the value of preempt_count. In contrast, other scenarios using preempt_count do not have such urgency requirements, so the non-preemptible time is relatively longer, and the value of preempt_count will remain unchanged for a long time. Using these features, the present invention can distinguish such exceptions, so as to adopt different scheduling strategies to more effectively manage system resources.

[0076] Since it is impossible to determine whether a VCPU is an exception VCPU or a lock-related VCPU only through a single preempt_count value, both types of VCPUs will get additional scheduling opportunities. The preempt_count value of the exception VCPU usually remains unchanged for a long time, so the present invention uses this feature to distinguish: when a VCPU is monitored to be scheduled multiple times, if the number of scheduling times for which its preempt_count value remains unchanged continuously exceeds a set threshold, the VCPU will be marked as an exception VCPU and scheduled out. In order to identify the exception VCPU as quickly as possible, a smaller value is usually selected for the threshold. However, this may result in the "non-preemptible VCPU" being mistakenly identified as an exception VCPU, thereby affecting system performance. Therefore, when setting the threshold, the threshold can be obtained through experiments, and a smaller value can be selected as much as possible while ensuring that the system performance is not affected.

[0077] According to the above analysis, the present invention proposes a VCPU scheduling method based on a microkernel Hypervisor. Whenever a new scheduling time slice is entered, the microkernel Hypervisor calls a clock processing function to perform VCPU scheduling. Figure 4 This is a flow chart of a specific implementation of the clock processing function in the present invention. Figure 4 As shown, the specific steps of the clock processing function of the present invention include:

[0078] S401: Get the scheduled VCPU:

[0079] The microkernel Hypervisor obtains the currently scheduled VCPU.

[0080] S402: Consumption time slice:

[0081] Let the number of time slices of the scheduled VCPU be N=N-1.

[0082] S403: Determine whether the scheduled VCPU has enabled monitoring. If not, proceed to step S404; otherwise, proceed to step S419.

[0083] S404: Determine whether the current thread of the scheduled VCPU is in kernel state. If not, proceed to step S405; otherwise, proceed to step S406.

[0084] S405: Mark the scheduled VCPU as a normal VCPU:

[0085] If the current thread is in user mode, it means that there is no synchronization problem with the threads in the current VCPU, and the scheduled VCPU will be marked as a normal VCPU, and then enter step S418.

[0086] S406: Determine whether the scheduled VCPU has thread switching, if thread switching occurs, proceed to step S407, otherwise proceed to step S409. Since the time slice of the scheduled VCPU is consumed at each clock, thread switching may occur at this time, so it is necessary to determine this state.

[0087] S407: Mark the scheduled VCPU as a normal VCPU:

[0088] Mark the scheduled VCPU as a normal VCPU.

[0089] S408: Disable VCPU monitoring:

[0090] The monitoring of the VCPU that is enabled for monitoring is turned off, and the process goes to step S419.

[0091] S409: Get preempt_count:

[0092] The value of the preemption counter preempt_count is read from the thread information structure thread_info of the scheduled VCPU. According to the previous technical principle description, in this embodiment, the specific method for obtaining preempt_count is:

[0093] The microkernel Hypervisor obtains the address of the thread_info data structure of the scheduled VCPU, obtains the GVA address of preempt_count through offset calculation, then obtains the HVA address of preempt_count through two-stage address translation, reads the data in the HVA address, and thus obtains the value of the preemption counter preempt_count.

[0094] S410: Determine whether preempt_count=0. If so, it means that there is no synchronization problem with the current VCPU thread, and go to step S418; otherwise, go to step S411.

[0095] S411: Collecting preempt_count change information:

[0096] preempt_count≠0 indicates that there may be a synchronization problem in the current VCPU thread. Therefore, based on the historical record of the preemption counter preempt_count, determine whether the preempt_count value has changed in this time slice. If it has changed, do not do anything. If it has not changed, determine the number of time slices in which the preempt_count value has remained at the current value continuously.

[0097] S412: Determine whether the monitoring time of the scheduled VCPU reaches a preset upper limit, if yes, proceed to step S413, otherwise proceed to step S419.

[0098] S413: Determine whether the scheduled VCPU is a lock-related VCPU, if yes, proceed to step S414, otherwise proceed to step S417. The method for determining a lock-related VCPU is: if the number of time slices during which the preempt_count value of the scheduled VCPU continuously remains at the current value is greater than a preset threshold, then it is not a lock-related VCPU, otherwise it is a lock-related VCPU.

[0099] S414: Mark the scheduled VCPU as a synchronization problem VCPU:

[0100] Mark the scheduled VCPU as a synchronization problem VCPU.

[0101] S415: Add time slice:

[0102] Add extra time slices to the scheduled VCPU. The number of extra time slices is determined according to the actual situation, and the number of time slices of the scheduled VCPU is increased by 1. By increasing the time slice, the VCPU thread can release all the locks it holds as much as possible, thereby solving the synchronization problem.

[0103] S416: Disable VCPU monitoring:

[0104] The monitoring of the VCPU that is enabled for monitoring is turned off, and the process goes to step S421.

[0105] S417: Mark the scheduled VCPU as an exception VCPU:

[0106] The scheduled VCPU is marked as an exceptional VCPU, and then the process goes to step S418.

[0107] S418: Save the remaining time slice and schedule VCPU:

[0108] The remaining time slice of the scheduled VCPU is saved, and then the VCPU calling function is called to re-determine the scheduled VCPU. Figure 5 This is a flow chart of a specific implementation method of the VCPU calling function in the present invention. Figure 5 As shown, the VCPU calling function in the present invention includes the following steps:

[0109] S501: Determine whether the scheduled VCPU is a VCPU with synchronization problems. If yes, proceed to step S502; otherwise, proceed to step S503.

[0110] S502: Determine whether the number of times the time slice of the scheduled VCPU is increased reaches a preset upper limit. If yes, proceed to step S508; otherwise, proceed to step S504.

[0111] S503: Determine whether the scheduled VCPU is an exceptional VCPU, if so, proceed to step S508, otherwise proceed to step S504.

[0112] S504: Determine whether the current thread of the scheduled VCPU is in kernel state. If so, proceed to step S505; otherwise, proceed to step S508.

[0113] S505: Get preempt_count:

[0114] The value of the preemption counter preempt_count is read from the thread information structure thread_info of the scheduled VCPU.

[0115] S506: Determine whether preempt_count=0, if yes, proceed to step S508, otherwise proceed to step S507.

[0116] S507: Start monitoring:

[0117] Enable monitoring for the current thread of the scheduled VCPU, and record the value of preempt_count and monitoring duration in each time slice. This scheduling is completed.

[0118] S508: Mark the scheduled VCPU as a normal VCPU:

[0119] Mark the scheduled VCPU as a normal VCPU.

[0120] S509: The number of times the time slice is increased is cleared to 0:

[0121] The timeslice increase times of the scheduled VCPU are cleared to 0.

[0122] S510: Select a new scheduled VCPU:

[0123] The currently scheduled VCPU is scheduled out of the VCPU scheduling queue, and then the first VCPU is read from the VCPU scheduling queue as the new scheduled VCPU. This scheduling is completed.

[0124] Like the regular scheduling queue in the microkernel, the VCPU scheduling queue includes several optimization levels, and is scheduled from high to low priority. The same priority level is scheduled in a round-robin manner.

[0125] According to the above process, when a VCPU frequently executes spin lock related operations, if the VCPU is in a "locked" or "waiting" state and cannot be forcibly preempted at the end of each scheduling, the VCPU will continue to run according to the above scheduling strategy, which obviously deviates from the fair scheduling principle. To this end, the present invention sets an upper limit on the number of times the time slice is increased (that is, the number of consecutive additional scheduling times of the VCPU) to ensure fairness without compromising system performance.

[0126] S419: Determine whether the number of time slices of the scheduled VCPU = 0, if so, proceed to step S420, otherwise proceed to step S421.

[0127] S420: VCPU scheduling:

[0128] The VCPU calling function is called to re-determine the scheduled VCPU, and the process goes to step S412. As can be seen, when the VCPU time slice is exhausted, the microkernel Hypervisor will trigger the VCPU scheduling.

[0129] S421: Restore VCPU operation:

[0130] Resume the operation of the currently scheduled VCPU and wait for the next time slice.

[0131] It can be seen from the above process that the main task of the clock processing function in the present invention is to monitor whether the current VCPU thread may have synchronization problems. If the current VCPU has enabled the monitoring function, it will first check whether the VCPU thread still has potential synchronization problems. If not, the monitoring will be turned off, the VCPU will retain its current remaining time slice, and directly perform VCPU scheduling. On the contrary, if there is still a potential synchronization problem, the system will obtain the preempt_count value, and judge whether the current VCPU thread does have a synchronization problem through the previously saved numerical value. If not, the monitoring will also be turned off, the VCPU will retain the current remaining time slice and perform normal VCPU scheduling. However, if there is a synchronization problem, the system will turn off the monitoring and add an additional time slice to the VCPU so that the VCPU thread can release all the locks it holds as much as possible.

[0132] Since the VCPU with synchronization problems has the opportunity of additional scheduling and additional time slices, it consumes more CPU resources than the VCPU without synchronization problems. Therefore, in practical applications, the microkernel Hypervisor can also record the number of normal scheduling time slices and the number of additional scheduling time slices of the VCPU. Each time the VCPU is supplemented with time slices normally, the balance coefficient λ∈(0,1) is calculated according to the number of additional scheduling time slices. The higher the ratio of the number of additional scheduling time slices to the number of scheduling time slices, the larger the value of the balance coefficient λ, and the number of supplementary time slices of the VCPU is. Indicates the number of standard supplementary time slices. According to this strategy, it can effectively ensure that the average number of time slices consumed by each VCPU each time it is scheduled is fair.

[0133] Although the above describes the illustrative specific embodiments of the present invention to facilitate those skilled in the art to understand the present invention, it should be clear that the present invention is not limited to the scope of the specific embodiments. For those of ordinary skill in the art, as long as various changes are within the spirit and scope of the present invention as defined and determined by the attached claims, these changes are obvious, and all inventions and creations using the concept of the present invention are protected.

Claims

1. A VCPU scheduling method based on a microkernel Hypervisor, characterized in that: Whenever a new scheduling time slice is entered, the microkernel Hypervisor calls the clock processing function to schedule the VCPU, which includes the following steps: S1: The microkernel Hypervisor obtains the currently scheduled VCPU; S2: Let the number of time slices of the scheduled VCPU be N=N-1; S3: Determine whether the scheduled VCPU has started monitoring. If not, proceed to step S4; otherwise, proceed to step S19; S4: Determine whether the current thread of the scheduled VCPU is in kernel state. If not, proceed to step S5; otherwise, proceed to step S6; S5: Mark the scheduled VCPU as a normal VCPU, and then go to step S18; S6: Determine whether there is a thread switch in the scheduled VCPU. If a thread switch occurs, go to step S7; otherwise, go to step S9; S7: Mark the scheduled VCPU as a normal VCPU, and then proceed to step S8; S8: Turn off the monitoring of the VCPU that is enabled for monitoring, and proceed to step S19; S9: Read the value of the preemption counter preempt_count from the thread information structure thread_info of the scheduled VCPU; S10: Determine whether preempt_count=0, if yes, go to step S18, otherwise go to step S11; S11: determining whether the value of preempt_count changes in the current time slice according to the historical record of the preemption counter preempt_count, if it changes, no operation is performed, if it does not change, determining the number of time slices in which preempt_count continuously maintains the current value; S12: Determine whether the monitoring time of the scheduled VCPU reaches the preset upper limit, if yes, proceed to step S13, otherwise proceed to step S19; S13: Determine whether the scheduled VCPU is a lock-related VCPU. If yes, proceed to step S14, otherwise proceed to step S17; the method for determining the lock-related VCPU is: if the number of time slices during which the preempt_count value of the scheduled VCPU continuously remains at the current value is greater than a preset threshold, then it is not a lock-related VCPU, otherwise it is a lock-related VCPU; S14: Mark the scheduled VCPU as a synchronization problem VCPU; S15: adding extra time slices to the scheduled VCPU. The number of extra time slices is determined according to the actual situation. The number of times the time slice of the scheduled VCPU is increased is increased by 1. S16: Turn off the monitoring of the VCPU that is enabled for monitoring, and proceed to step S21; S17: Mark the scheduled VCPU as an exception VCPU, and then proceed to step S18; S18: Save the remaining time slice of the scheduled VCPU, then call the VCPU calling function to re-determine the scheduled VCPU; the VCPU calling function includes the following steps: 1) Determine whether the scheduled VCPU is a synchronization problem VCPU. If so, proceed to step 2), otherwise proceed to step 3); 2) Determine whether the number of times the time slice of the scheduled VCPU increases reaches a preset upper limit, if yes, proceed to step 8), otherwise proceed to step 4); 3) Determine whether the scheduled VCPU is an exception VCPU, if yes, go to step 8), otherwise go to step 4); 4) Determine whether the current thread of the scheduled VCPU is in kernel state, if yes, proceed to step 5), otherwise proceed to step 8); 5) Read the value of the preemption counter preempt_count from the thread information structure thread_info of the scheduled VCPU; 6) Determine whether preempt_count=0, if yes, proceed to step 8), otherwise proceed to step 7); 7) Start monitoring the current thread of the scheduled VCPU, record the value of preempt_count and monitoring duration in each time slice; this scheduling is completed; 8) Mark the scheduled VCPU as a normal VCPU; 9) Clear the number of times the time slice of the scheduled VCPU is increased to 0; 10) Schedule the currently scheduled VCPU out of the VCPU scheduling queue, and then read the first VCPU from the VCPU scheduling queue as the new scheduled VCPU; this scheduling is completed; S19: Determine whether the number of time slices of the scheduled VCPU is 0, if yes, proceed to step S20, otherwise proceed to step S21; S20: calling the VCPU calling function to redetermine the scheduled VCPU, and proceeding to step S21; S21: Resume the operation of the currently scheduled VCPU and wait for the next time slice.

2. The VCPU scheduling method according to claim 1, characterized in that: The specific method for obtaining preempt_count in step S9 is: The microkernel Hypervisor obtains the address of the thread_info data structure of the scheduled VCPU, obtains the GVA address of preempt_count through offset calculation, then obtains the HVA address of preempt_count through two-stage address translation, reads the data in the HVA address, and thus obtains the value of the preemption counter preempt_count.

3. The VCPU scheduling method according to claim 1, characterized in that: The microkernel Hypervisor records the number of normal scheduled time slices and the number of additional scheduled time slices of the VCPU. Each time the VCPU is supplemented with time slices normally, the balance coefficient λ∈(0,1) is calculated according to the number of additional scheduled time slices. The higher the ratio of the number of additional scheduled time slices to the number of scheduled time slices, the larger the value of the balance coefficient λ, and the larger the number of supplementary time slices of the VCPU. Indicates the number of standard supplementary time slices.

Images