VCPU Scheduling Method Based on Microkernel Hypervisor

Abstract

The present invention discloses a VCPU scheduling method based on a microkernel Hypervisor. Whenever a new scheduling time slice is entered, the clock processing function is called for VCPU scheduling. The clock processing function sequentially determines whether there are potential synchronization problems with the VCPU by monitoring whether the scheduled VCPU has been enabled, whether the current thread is in the kernel state, and whether there is a thread switch. If not, normal scheduling is performed. If there are potential synchronization problems, the value and change of the preempt_count of the preemptive counter are obtained to determine whether it is a synchronization problem VCPU. If so, an additional time slice is added to enable the currently scheduled VCPU to continue running to solve the synchronization problem. The present invention uses the microkernel Hypervisor to perform VCPU scheduling based on lock detection and cooperative fairness scheduling strategies, which can reduce the performance overhead caused by lock contention in the Hypervisor, thereby improving the synchronization performance. At the same time, there is no need to modify the source code of the guest operating system, ensuring the stability and portability of the system.

Description

Technical Field

[0001] The present invention belongs to the technical field of microkernel, 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 single physical computer, and each environment can run an independent operating system and applications. The role of Hypervisor is similar to that of a virtualized operating system. By allocating computing resources and isolating different virtual machines, they can run simultaneously on the same physical computer without interfering with each other. The Type1 Hypervisor has no host operating system. It runs directly on the physical hardware, directly manages various physical resources, and at the same time manages and runs the guest operating systems. The Type2 Hypervisor, whose host operating system it parasitizes, 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 guest operating system, the optimization mechanism of the guest operating system for the kernel spin lock fails, bringing synchronization performance problems such as LHP (Lock Holder Preemption) and LWP (Lock Waiter Preemption), resulting in serious synchronization overhead and reducing system performance. To solve the synchronization performance problem, some technical solutions have been proposed in the industry, and among them, the full virtualization solution has received great attention because it does not require modifying the source code of the guest operating system. In the full virtualization solution, representative solutions include the VCPU synchronous scheduling solution, the driver detection LHP solution, and the scheduling solution based on IPI driving.

[0004] The VCPU synchronous scheduling scheme distributes the VCPUs (virtual central processing units) of the guest operating system to different physical CPUs for synchronous scheduling, so as to achieve their simultaneous operation or stop, and fundamentally eliminate the LHP and LWP problems. Although the synchronous scheduling scheme has significant advantages in eliminating synchronous problems such as LHP and LWP, implementing this strategy also comes with some challenges and potential negative impacts. Although this scheme can fundamentally eliminate the LHP and LWP problems, it has the following deficiencies: 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, introducing synchronous scheduling may lead to CPU fragmentation, making the physical CPU resources unable to be fully utilized, thus affecting the overall efficiency of the system. In addition, problems such as priority inversion and scheduling delay may also occur, affecting the stability and performance of the system.

[0005] The driver detection LHP scheme can avoid the LHP problem by introducing a special driver in the guest operating system. The system can identify the "safe points" that do not hold spin locks and prohibit preemption at non-"safe points". This method also introduces the concept of a preemption window to ensure the fairness of scheduling. Although this scheme can effectively identify the lock holders, the configuration is cumbersome and a special lockless device driver needs to be installed, increasing the complexity of implementation.

[0006] The IPI-driven scheduling scheme is based on the situation that IPI signals are usually triggered before certain spin locks are released as found in the research. By using IPI signals, the lock holders can be dynamically identified at the Hypervisor layer and the time of their preemption can be delayed to achieve the purpose of avoiding LHP. Although this scheme can dynamically identify the lock holders at the Hypervisor layer and make certain scheduling processing, based on IPI interrupts, only user-level synchronization can be identified, and it is ineffective for other types of kernel spin locks. Summary of the Invention

[0007] The purpose of the present invention is to overcome the deficiencies of the prior art and provide a VCPU scheduling method based on a microkernel Hypervisor. The microkernel Hypervisor performs VCPU scheduling based on a lock detection and cooperative fairness scheduling strategy, which can reduce the performance overhead caused by lock competition in the Hypervisor, thereby improving the synchronization performance. At the same time, it is not necessary to modify the source code of the guest operating system to ensure the stability and portability of the system.

[0008] To achieve the above invention purpose, for the VCPU scheduling method based on the microkernel Hypervisor of the present invention, whenever a new scheduling time slice is entered, the microkernel Hypervisor calls the clock processing function to perform VCPU scheduling, which specifically includes the following steps:

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

[0010] S2: Set the time slice number N of the scheduled VCPU to N - 1;

[0011] S3: Determine whether monitoring has been enabled for the scheduled VCPU. If not, go to step S4; otherwise, go to step S19;

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

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

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

[0015] S7: Mark the scheduled VCPU as an ordinary VCPU, and then go to step S8;

[0016] S8: Turn off the monitoring of the VCPU with monitoring enabled, and go to step S19;

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

[0018] S10: Determine whether preempt_count = 0. If so, go to step S18; otherwise, go to step S11;

[0019] S11: According to the historical record of the preempt counter preempt_count, determine whether the value of preempt_count has changed in this time slice. If it has changed, do nothing; if it has not changed, determine the number of time slices that preempt_count has continuously remained at the current value;

[0020] S12: Determine whether the monitoring time of the scheduled VCPU has reached the preset upper limit. If so, go to step S13; otherwise, go to step S19;

[0021] S13: Determine whether the scheduled VCPU is a lock-related VCPU. If so, go to step S14; otherwise, go to step S17; The method for judging a lock-related VCPU is: if the number of time slices that the preempt_count value of the scheduled VCPU has continuously remained at the current value is greater than the preset threshold, it is not a lock-related VCPU; otherwise, it is a lock-related VCPU;

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

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

[0024] S16: Turn off the monitoring of the VCPU with monitoring enabled and enter step S21;

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

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

[0027] 1) Determine whether the scheduled VCPU is a synchronous problem VCPU. If it is, enter step 2); otherwise, enter step 3);

[0028] 2) Determine whether the number of times the time slice of the scheduled VCPU is increased reaches the preset upper limit. If it is, enter step 8); otherwise, enter step 4);

[0029] 3) Determine whether the scheduled VCPU is an exception VCPU. If it is, enter step 8); otherwise, enter step 4);

[0030] 4) Determine whether the current thread of the scheduled VCPU is in the kernel state. If it is, enter step 5); otherwise, enter step 8);

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

[0032] 6) Determine whether preempt_count = 0. If it is, enter step 8); otherwise, enter step 7);

[0033] 7) Turn on the monitoring of the current thread of the scheduled VCPU, and record the value of preempt_count and the monitoring duration in each time slice; This scheduling ends;

[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) 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 ends.

[0037] S19: Determine whether the number of time slices of the scheduled VCPU = 0. If so, go to step S20; otherwise, go to step S21.

[0038] S20: Call the VCPU call function to re-determine the scheduled VCPU, and go to step S21.

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

[0040] The VCPU scheduling method based on the microkernel Hypervisor of the present invention calls the clock processing function for VCPU scheduling whenever a new scheduling time slice is entered. The clock processing function sequentially determines whether there are potential synchronization problems of the VCPU by monitoring whether the scheduled VCPU has been enabled, whether the current thread is in the kernel state, and whether there is a thread switch. If not, normal scheduling is performed. If there are potential synchronization problems, the value and change situation of the preempt counter preempt_count are obtained to determine whether it is a synchronization problem VCPU. If so, an additional time slice is added to make the currently scheduled VCPU continue to run to solve the synchronization problem.

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

[0042] 1) The present invention utilizes the features and hardware support provided by the ARMv8 architecture to provide an LHP / LWP detection strategy in a full virtualization manner. By avoiding algorithms from executing lock-related VCPUs and maintaining fair CPU resource allocation, the synchronization performance of the system can be improved, the lock waiting time can be reduced, and lock contention can be lowered, thereby improving the stability and performance of the virtual machine.

[0043] 2) The present invention more effectively allocates and utilizes physical CPU resources by maintaining different running times of VCPUs, 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 more simple and direct to implement; and lightweight implementation: Due to the simple design of the detection and scheduling algorithms themselves, it is also relatively easy to deploy and integrate into existing virtualization systems, reducing the complexity of deployment and maintenance. Description of the Drawings

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

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

[0047] Figure 3 Schematic diagram of the change principle of the lock status counter of the VCPU in the present invention;

[0048] Figure 4 Flowchart of the specific implementation of the clock processing function in the present invention;

[0049] Figure 5 Flowchart of the specific implementation of the VCPU call function in the present invention. Specific implementation

[0050] The following describes the specific implementation of the present invention in conjunction with the accompanying drawings, so that those skilled in the art can better understand the present invention. It should be particularly 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] To better illustrate the technical solution of the present invention, the technical principles involved in the present invention will be briefly described first.

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

[0053]

[0054] In the above formula, p j represents the probability that a lock-holding or lock-waiting VCPU is in the j-th position in the scheduling queue. When j = 0, it means not being preempted and running, and p0 represents the probability of not being preempted. T criticalRepresents the time required to execute the critical section protected by the lock, usually around 5 us, which is much less than the average execution time T of the scheduler. execution . T can be release understood as the total time for a lock holder or lock waiter VCPU to release the lock.

[0055] The time required to synchronize the waiting threads running in the lock waiter VCPU depends on the position of the thread in the lock waiting 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 that the waiting thread is in the i-th position in the lock waiting queue. When i = 0, it means the thread does not need to wait and can immediately acquire the lock once the lock is released. T can be sync understood as the total time for a lock waiter VCPU to wait for the lock to be released.

[0058] In a virtualized environment, the CPU resource sharing method is time slice rotation. So when the critical section protected by the lock is available, the waiting threads 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 , and the total time for the waiting thread to execute the non-critical section code can be defined as T non-critical . Therefore, the total time required for the waiting 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 are determined by the load characteristics of the guest operating system. T wait is affected by the scheduling policy of the guest operating system, while T sync is affected by the scheduling policy of the host operating system for the VCPU. Since T execution is much larger than T critical , the synchronization overhead T sync accounts for a relatively large proportion of the waiting thread's completion time T and directly affects the system performance. Among the components of T sync , T execution and p j are affected by the scheduling policy of the host operating system. The larger T execution , the greater the synchronization overhead. So reducing Texecution It can alleviate the performance degradation to a certain extent, but a smaller T execution will seriously damage the cache efficiency. Therefore, the synchronization performance can be optimized by increasing p0. p0 represents the probability of not being preempted. So in the present invention, the VCPU scheduling policy selects the LHP / LWP avoidance scheduling policy, that is, to minimize the probability that the lock holder and the lock waiter are preempted.

[0062] In the present invention, the LHP / LWP detection method adopts some mechanisms in the guest operating system. In the kernel of the Linux operating system, each thread is managed by a data structure called the thread information structure thread_info. Inside this data structure, there is a field called the preempt count preempt_count, which is used to determine whether a thread can be forcibly preempted. When the value of the preempt count is 0, it means that other tasks are allowed to preempt the current thread; when the value is not 0, usually because the thread is occupying system resources (such as a spin lock), it 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 value of the preempt count of the currently running thread. Only when the counter is 0 will the scheduler immediately perform a thread switch; otherwise, it will continue to let the current thread execute. The value of the preempt count will be dynamically modified by operations related to the spin lock: before a thread attempts to acquire a spin lock, the counter will be incremented by 1; after releasing the spin lock, the counter will be decremented by 1. This mechanism ensures that for a thread holding a spin lock or waiting for a spin lock, the preempt count is always greater than 0, thus avoiding performance problems during long-term lock holding or waiting (i.e., avoiding LHP and LWP problems).

[0063] Figure 1 Schematic diagrams of LHP and LWP problems that may be encountered in non-virtualized and virtualized environments. Figure 1 It shows the lock behavior of threads or VCPUs in non-virtualized and virtualized environments, the optimization mechanism for synchronization performance in Linux, and the LHP and LWP problems that may be encountered in the virtualized environment. In the non-virtualized environment, when thread 1 acquires a 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 either 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., idle time).

[0064] In a virtualized environment, the LHP problem refers to the situation where a thread in VCPU1 holds a lock while a thread in VCPU2 is waiting for this lock. Although the thread in VCPU1 will not be preempted, for some reason, this VCPU may be switched, resulting in an extended lock-holding time, which in turn causes the waiting VCPU2 to spin idly. This waiting time will be affected by the scheduling of the lock-holding VCPU1.

[0065] In a virtualized environment, the LWP problem refers to the situation where a thread in VCPU1 holds a lock, the thread in VCPU2 is the first to wait for this lock, and the thread in VCPU3 is the second to wait for this lock. When VCPU1 releases the lock, according to the order of the waiting queue, the first waiting VCPU2 should acquire and release the lock before the second waiting VCPU3 can acquire the lock. If VCPU2 is switched before acquiring the lock, then although the lock is available, VCPU3 cannot acquire the lock and can only spin idly. This results in the waiting time of VCPU3 for the lock depending not only on its position in the waiting queue but also on the scheduling of the preceding waiting VCPU.

[0066] In the ARMv8 architecture, the kernel stack size of each thread is also fixed, usually 8KB. In this architecture, preempt_count is defined in the thread_info data structure, and the thread_info of each thread is stored in its corresponding kernel stack. To enable the kernel to quickly find the thread_info of the current thread, this information is usually stored in this special way. 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 thread_info can be calculated through the current kernel stack pointer (such as the SP_EL1 register). The common practice is to calculate the address of 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 position of thread_info in the kernel stack can be accurately found. This way of the Linux kernel can efficiently manage and access the key information of each thread, such as preempt_count, without excessive addressing overhead.

[0067] After obtaining the address of thread_info, the hypervisor can calculate the address of preempt_count through simple offset calculation. preempt_count is a field in the thread_info structure and is used to identify whether a thread can be preempted. Since calculating 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 this address is a GVA (guest operating system virtual address), it needs to be converted into an HVA (host operating system virtual address) that the hypervisor can access. Then the hypervisor can read the value of preempt_count to find out whether the virtual CPU (VCPU) is holding a lock or waiting for a lock, so as to adjust the scheduling policy to optimize the performance and responsiveness of the system.

[0068] Since the address obtained by the hypervisor is the GVA (Guest Virtual Address) address of preempt_count and an HVA (Host Virtual Address) is required to access it correctly, converting a GVA to an HVA requires the following conversion 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. As Figure 2 shown, 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 in Stage 1 and is maintained by the guest operating system. The hypervisor first obtains the page table base address (GPA) of the guest operating system stored in the TTBRx_EL1 register. After converting the page table base address into an HVA, by accessing this page table, the GVA of preempt_count is converted into a GPA. This process is similar to simulating the address translation by the memory management unit (MMU).

[0070] GPA -> HPA: The conversion from GPA to HPA is the address conversion in Stage 2, which is maintained by the host operating system for the guest operating system. Before the virtual machine starts, the host operating system allocates a virtual address space for the guest operating system, 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 conversion from HVA to HPA and from HPA to HVA are both maintained and controlled by the host operating system, without the need to simulate the address conversion process of the MMU. The host operating system directly converts HVA to HPA or HPA to HVA through information such as the address area divided by the system and the offset address.

[0072] During the LHP / LWP detection process, since the Hypervisor needs to frequently access the preempt_count of the preemptive counter, to improve efficiency, a buffer area can be allocated to record the mapping information from GVA to HVA of the preempt_count. When address conversion is required, it can be directly searched in the buffer area, avoiding the repeated conversion process from GVA to GPA and from GPA to HPA, thereby reducing system overhead and latency, and at the same time 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 the GPA of the TTBRx_EL1 page table base address.

[0073] Next, test and analyze the relationship between the preempt_count value and the spin lock state (holding the lock, waiting, no lock) of the VCPU. In the present invention, the kernel code of the guest operating system is modified to set a lock state counter lock_count for each VCPU to record the instantaneous spin lock state of the currently running thread of this VCPU. Figure 3This is the schematic diagram of the change of the lock status counter of the VCPU in the present invention. When the system starts, all lock status counters are initialized to 0, indicating that the current threads on all VCPUs are in the "lock-free" state. Before a thread attempts to acquire a lock, the lock status counter lock_count is incremented by 1, indicating that the thread is in the "waiting" state. After successfully acquiring the lock, the lock status counter lock_count is incremented by 1 again, indicating that the thread currently holds the lock. Since the lock status counter lock_count is incremented by 2 each time a lock is acquired and decremented by 2 when the lock is released. This counting method makes it simple and clear to judge the thread lock status: a lock status counter value of 0 indicates "lock-free", an odd number indicates "waiting", and an even number indicates "holding the lock". In addition, by shifting the lock status counter lock_count one bit to the right, the number of locks held by the thread can be known. The value of the lock status 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 the "holding the lock" or "waiting" state. The value of preempt_count can approximately reflect the number of spin locks held by the VCPU. Specifically, if a certain VCPU is the holder of the lock, the value of preempt_count represents the number of spin locks held; if it is a lock waiter, preempt_count - 1 represents the number of spin locks held. Therefore, the present invention defines such VCPUs as "potential lock holders or lock waiters".

[0075] However, there is an exception. That is, when the preempt_count value is non-zero, the corresponding VCPU may be in a "lock-free" state because preempt_count is not only used for spin-lock counting. In other non-preemptible situations, such as interrupt handling, temporary kernel mapping, page fault interrupts, etc., preempt_count is also set to non-zero to prevent preemption. Through test 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 relatively slowly; while in the case of spin locks, the change of preempt_count is more frequent. This is because the busy-waiting characteristic of spin locks requires the process holding the lock to release the lock as soon as possible. Therefore, the holding time of spin locks is usually very short, about at 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 an urgent requirement, so the non-preemptible time is relatively longer and the value of preempt_count remains unchanged for a longer time. Utilizing these characteristics, the present invention can distinguish this exception situation, and thus adopt different scheduling strategies to more effectively manage system resources.

[0076] Since it is impossible to determine whether a VCPU is an exceptional VCPU or a lock-related VCPU only through a single preempt_count value, both types of VCPUs will be given additional scheduling opportunities. The preempt_count value of exceptional VCPUs usually remains unchanged for a long time. Therefore, the present invention uses this characteristic for discrimination: when it is monitored that a certain VCPU has been scheduled multiple times, if the number of consecutive unchanged scheduling times of its preempt_count value exceeds a set threshold, this VCPU will be marked as an exceptional VCPU and scheduled out. In order to identify exceptional VCPUs as soon as possible, the threshold usually selects a smaller value. However, this may cause misidentifying "non-preemptible VCPUs" as exceptional VCPUs, thus affecting system performance. Therefore, when setting the threshold, the threshold can be obtained through experiments, and a smaller value should be selected as much as possible on the premise of ensuring that the system performance is not affected.

[0077] Based on 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 the clock processing function for VCPU scheduling. Figure 4 It is the flowchart of the specific implementation manner of the clock processing function in the present invention. As Figure 4 shown, the specific steps of the clock processing function of the present invention include:

[0078] S401: Obtain the VCPU to be scheduled:

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

[0080] S402: Consume the time slice:

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

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

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

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

[0085] If the current thread is in the user mode, it means that there is no synchronization problem in the thread of the current VCPU. Mark the scheduled VCPU as a normal VCPU, and then go to step S418.

[0086] S406: Determine whether there is a thread switch for the scheduled VCPU. If a thread switch occurs, go to step S407; otherwise, go to step S409. Since the time slice of the scheduled VCPU is consumed at each clock, a thread switch may occur at this time, so this state needs to be judged.

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

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

[0089] S408: Turn off VCPU monitoring:

[0090] Turn off the monitoring of the VCPU with monitoring enabled, and go to step S419.

[0091] S409: Obtain preempt_count:

[0092] Read the value of the preempt counter preempt_count 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, calculates the GVA address of preempt_count through offset calculation, and then obtains the HVA address of preempt_count through two-stage address translation, and reads the data in the HVA address to obtain the value of the preempt counter preempt_count.

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

[0095] S411: Collect the change information of preempt_count:

[0096] preempt_count ≠ 0 indicates that there may be a synchronization problem in the current VCPU thread. Therefore, according to the historical record of the preempt counter preempt_count, determine whether the value of preempt_count changes in this time slice. If it changes, do nothing; if it does not change, determine the number of time slices during which the value of preempt_count continuously remains the current value.

[0097] S412: Determine whether the monitoring time of the scheduled VCPU reaches the preset upper limit. If so, go to step S413; otherwise, go to step S419.

[0098] S413: Determine whether the scheduled VCPU is a lock-related VCPU. If so, go to step S414; otherwise, go to step S417. The method for judging a lock-related VCPU is: if the number of time slices during which the preempt_count value of the scheduled VCPU continuously remains the current value is greater than the preset threshold, 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: Increase the time slice:

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

[0103] S416: Turn off VCPU monitoring:

[0104] Turn off the monitoring of the VCPU for which monitoring is enabled, and proceed to step S421.

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

[0106] Mark the scheduled VCPU as an exception VCPU, and then proceed to step S418.

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

[0108] Save the remaining time slice of the scheduled VCPU, and then call the VCPU call function to re-determine the scheduled VCPU. Figure 5 It is a flowchart of the specific implementation manner of the VCPU call function in the present invention. As Figure 5 shown, the VCPU call function in the present invention includes the following steps:

[0109] S501: Determine whether the scheduled VCPU is a synchronous problem VCPU. If so, proceed to step S502; otherwise, proceed to step S503.

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

[0111] S503: Determine whether the scheduled VCPU is an exception 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 the kernel state. If so, proceed to step S505; otherwise, proceed to step S508.

[0113] S505: Obtain preempt_count:

[0114] Read the value of the preempt counter preempt_count from the thread information structure thread_info of the scheduled VCPU.

[0115] S506: Determine whether preempt_count = 0. If so, proceed to step S508; otherwise, proceed to step S507.

[0116] S507: Enable monitoring:

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

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

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

[0120] S509: Clear the number of times the time slice is incremented to 0:

[0121] Clear the number of times the time slice of the VCPU to be scheduled is incremented to 0.

[0122] S510: Select a new VCPU to be scheduled:

[0123] Schedule the current VCPU to be scheduled out of the VCPU scheduling queue, and then read the first VCPU from the VCPU scheduling queue as the new VCPU to be scheduled. This scheduling ends.

[0124] Similar to the regular scheduling queue in the microkernel, the VCPU scheduling queue includes several optimization levels and is scheduled in descending order of priority. Inside the same priority, the round-robin method is used for scheduling.

[0125] According to the above process, when a certain VCPU frequently performs spin-lock related operations, if the VCPU is in the "holding lock" or "waiting" state and cannot be forcibly preempted at the end of each scheduling, according to the aforementioned scheduling policy, the VCPU will continue to run, which significantly deviates from the fair scheduling criterion. Therefore, the present invention sets an upper limit on the number of times the time slice is incremented (that is, the number of consecutive additional schedules of the VCPU) to ensure fairness without compromising system performance.

[0126] S419: Determine whether the time slice quantity of the VCPU to be scheduled = 0. If so, enter step S420; otherwise, enter step S421.

[0127] S420: VCPU scheduling:

[0128] Call the VCPU call function to re-determine the VCPU to be scheduled and enter step S412. It can be seen that when the VCPU time slice is exhausted, the microkernel Hypervisor will trigger VCPU scheduling.

[0129] S421: Resume the VCPU operation:

[0130] Resume the operation of the current VCPU to be scheduled and wait to enter the next time slice.

[0131] As can be seen from the above process, the main task of the clock processing function in the present invention is to monitor whether there may be synchronization problems in the current VCPU thread. If the monitoring function is enabled for the current VCPU, it will first check whether there are still potential synchronization problems in the VCPU thread. If not, the monitoring will be turned off, and the VCPU will retain its current remaining time slice and directly perform VCPU scheduling. On the contrary, if there are still potential synchronization problems, the system will obtain the preempt_count value and determine whether there are indeed synchronization problems in the current VCPU thread based on the previously saved value. If not, the monitoring will also be turned off, and the VCPU will retain the current remaining time slice and perform normal VCPU scheduling. However, if there are synchronization problems, 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 for additional scheduling and additional time slices, consuming more CPU resources than the VCPU without synchronization problems, 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. When replenishing the normal time slice of the VCPU each time, the balance coefficient λ∈(0, 1) is calculated according to the number of additional scheduling time slices. The higher the proportion 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 replenished time slices of the VCPU represents the standard number of replenished time slices. According to this strategy, it can effectively ensure the fairness of the number of time slices consumed by each VCPU on average each time it is scheduled.

[0133] Although the above describes the illustrative specific embodiments of the present invention for the convenience of 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 defined and determined by the appended claims, these changes are obvious, and all inventions made using the concept of the present invention are within the scope of protection.

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 for VCPU scheduling, which specifically includes the following steps: S1: The microkernel Hypervisor obtains the currently scheduled VCPU; S2: Set the number of time slices N of the scheduled VCPU to N - 1; S3: Determine whether monitoring has been enabled for the scheduled VCPU. If not, proceed to step S4; otherwise, proceed to step S19; S4: Determine whether the current thread of the scheduled VCPU is in kernel mode. If not, proceed to step S5; otherwise, proceed to step S6; S5: Mark the scheduled VCPU as a normal VCPU, and then proceed to step S18; S6: Determine whether there is a thread switch for the scheduled VCPU. If a thread switch occurs, proceed to step S7; otherwise, proceed 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 with monitoring enabled, and proceed to step S19; S9: Read the value of the preempt counter preempt_count from the thread information structure thread_info of the scheduled VCPU; S10: Determine whether preempt_count = 0. If so, proceed to step S18; otherwise, proceed to step S11; S11: According to the historical record of the preempt counter preempt_count, determine whether the value of preempt_count has changed in this time slice. If it has changed, do nothing; if it has not changed, determine the number of time slices that preempt_count has continuously remained at the current value; S12: Determine whether the monitoring time of the scheduled VCPU has reached the preset upper limit. If so, proceed to step S13; otherwise, proceed to step S19; S13: Determine whether the scheduled VCPU is a lock-related VCPU. If so, proceed to step S14; otherwise, proceed to step S17. The method for judging a lock-related VCPU is: If the number of time slices that the preempt_count value of the scheduled VCPU has continuously remained at the current value is greater than the preset threshold, 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: Add extra time slices to the scheduled VCPU. The number of extra time slices is determined according to the actual situation, and increment the number of times the time slices of the scheduled VCPU are increased by 1; S16: Turn off the monitoring of the VCPU with monitoring enabled, 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 slices of the scheduled VCPU, and then call the VCPU call function to re-determine the scheduled VCPU. The VCPU call 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 has increased reaches a preset upper limit. If so, go to step 8); otherwise, go to step 4). 3) Determine whether the scheduled VCPU is an exception VCPU. If so, go to step 8); otherwise, go to step 4). 4) Determine whether the current thread of the scheduled VCPU is in the kernel state. If so, go to step 5); otherwise, go to step 8). 5) Read the value of the preempt_count from the thread information structure thread_info of the scheduled VCPU. 6) Determine whether preempt_count = 0. If so, go to step 8); otherwise, go to step 7). 7) Monitor the current thread of the scheduled VCPU, record the value of preempt_count and the monitoring duration in each time slice; this scheduling ends. 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 current 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 ends. S19: Determine whether the number of time slices of the scheduled VCPU = 0. If so, go to step S20; otherwise, go to step S21. S20: Call the VCPU call function to re-determine the scheduled VCPU, and go to step S21. S21: Resume the operation of the current scheduled VCPU and wait to enter the next time slice.

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

3. The VCPU scheduling method according to claim 1, wherein The microkernel Hypervisor records the number of normal scheduling time slices and the number of additional scheduling time slices for the VCPU. Each time when normal time slices are replenished for the VCPU, a balance coefficient λ ∈ (0, 1) is calculated according to the number of additional scheduling time slices. The higher the proportion of the number of additional scheduling time slices in the number of scheduling time slices, the larger the value of the balance coefficient λ, and then the number of replenished time slices of this VCPU represents the standard number of replenished time slices.

Images