Scheduling method for improving real-time performance of Xvisor scheduler
By adopting PRM scheduling policy and red and black tree to manage VCPU priority in the Xvisor scheduler, and using spin locks when incoming and dequeuing operations, the problem of Normal VCPU response delay in the Xvisor scheduler is solved, and the scheduler is improved real-time.
Patent Information
- Application Number
- CN202411549273.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-01
- Publication Date
- 2025-02-14
AI Technical Summary
The ready queue of the existing Xvisor scheduler is implemented using per cpu variable, resulting in the Normal VCPU not responding in time and real-time performance cannot be guaranteed.
Using the PRM scheduling strategy, a scheduled entity ready queue is created for all physical CPUs through the vmm_scheduler_init function, and a red-black tree is used to manage runnable VCPUs on different priorities. Obtain spin locks during incoming and dequeuing operations to ensure data synchronization.
By changing the ready queue into a global variable shared by all hcpus and adding spin locks at critical operating points, the real-time performance of the Xvisor scheduler is improved, ensuring that the Normal VCPU can respond in a timely manner.
Smart Images
Figure SMS_1 
Figure SMS_2 
Figure SMS_3
Abstract
Description
Technical Field
[0001] The invention relates to the field of Xvisor schedulers, and specifically provides a scheduling method for improving the real-time performance of the Xvisor scheduler. Background Art
[0002] Xvisor is a hardware-assisted virtualization software that runs directly on the host (i.e., physical machine or hardware device). In short, Xvisor is a native or type-1 hypervisor.
[0003] In Xvisor, we call virtual machines Guest and virtual CPUs VCPUs. The VCPUs belonging to the Guest are called Normal VCPUs, and the VCPUs that do not belong to any Guest are called Orphan VCPUs. Xvisor creates Orphan VCPUs for background processes and running management daemons. Xvisor's Normal VCPU runs in user mode, and Orphan VCPU runs in supervisor mode.
[0004] Xvisor's scheduler is universal and has interfaces for implementing scheduling policies. Once the scheduler senses a change in the VCPU state in the hypervisor manager module, it updates the per-CPU ready queue (rq). The hypervisor scheduler uses per-CPU hypervisor timer events to allocate time slices to VCPUs. When a VCPU's scheduler timer event expires, the hypervisor scheduler finds the next VCPU to be scheduled based on the scheduling policy and sets a scheduler timer event for the next VCPU.
[0005] For Xvisor, the normal VCPU is a black box (that is, any code can run on this VCPU). Exceptions or interrupts are the only way for Xvisor to regain control of the VCPU. Xvisor code must run in one of the following contexts:
[0006] 1. IRQ context: handles interrupts generated by host machine peripherals
[0007] 2. Normal context: Xvisor proxies the Normal VCPU to process functions, instructions, or IO.
[0008] 3. Orphan context: runs the Orphan VCPU or hypervisor thread.
[0009] Normal context is a special context of Xvisor. It is in Normal context only when Xvisor is acting on behalf of NormalVCPU, such as exception handling, IO simulation, etc. Normal context cannot sleep, that is, Normal VCPU cannot be scheduled-out in Normal context. Normal VCPU can be scheduled-out in only two cases: 1. Xvisor leaves IRQ context; 2. Xvisor leaves Normal context. This allows Xvisor to ensure deterministic latency when handling exceptions and IO simulation.
[0010] Currently, Xvisor has two scheduling strategies:
[0011] 1. PRR: Priority Round-Robin priority round-robin scheduling algorithm
[0012] 2. PRM: Priority rate monotonic priority frequency monotonic scheduling algorithm
[0013] When the Xvisor scheduler creates a ready queue (rq), the scheduling strategies of PRR and PRM are the same, and both include the following execution steps:
[0014] Call the vmm_init function from the cpu_init function, then call the init_bootcpu function from the vmm_init function, and then call the vmm_scheduler_init function from the init_bootcpu function;
[0015] The vmm_scheduler_init function is called as the kernel initialization function, and the scheduler_startup function is called in it to start the event. The event is to enable the scheduler to create a ready queue (rq) for each host cpu (physical CPU), where schedp is a percpu variable, namely schedp->rq; define schedp->rq = vmm_schedalgo_rq_create function, the ready queue created by this function represents the ready queue of the scheduling entity, and then maintain the ready queue.
[0016] The maintenance process differs between PRR and PRM:
[0017] PRR supports eight priorities from 0 to 7 and maintains a linked list for each priority. The larger the priority value, the higher the priority.
[0018] PRM supports eight priorities from 0 to 7, and maintains a rb tree for each priority, that is, 8 rbtrees are created. When entering or exiting a queue, the corresponding rb tree is found according to the priority, and then the rb tree is inserted or deleted.
[0019] The reason for this difference is the difference between the two scheduling strategies. Analyzing the scheduling strategy is actually analyzing the two strategies for ready queue dequeuing and enqueuing.
[0020] When the Xvisor scheduler performs the enqueue operation, the scheduling strategy of PRR is to first assign the obtained vcpu scheduling entity vcpu->sched_priv to rq_entry, then find the corresponding readyqueue according to the priority vcpu->priority, and insert the scheduling entity rq_entry into the tail of the ready queue. The scheduling strategy of PRM is to first find the target rb tree according to vcpu->priority, which is established during the creation of the ready queue; then traverse the rb tree nodes found above according to the scheduling frequency periodicity, and find the parent node to be inserted according to the basic principle that the smaller the vcpu->periodicity is, the lower the node should be placed when adding nodes to the rb_tree, so as to find the parent node to be inserted.
[0021] When the Xvisor scheduler performs a dequeue operation, the scheduling strategy of PRR is to first find the highest priority and non-empty linked list, find the first node of the non-empty linked list, remove this node, and assign this node as the next scheduling entity found to next. Next represents the next scheduling entity to be scheduled. The scheduling strategy of PRM is to first find the highest priority and non-empty ready queue, traverse from the root of the non-empty ready queue found above to find the bottom left node, remove this node, and assign this node as the next scheduling entity found to next. Next represents the scheduling entity that the hypervisor scheduler is going to schedule.
[0022] In summary, the existing scheduling algorithms have the following disadvantages:
[0023] PRR scheduling strategy: Orphan VCPU in Xvisor is the hypervisor management thread, and its priority is higher than the Normal VCPU created in the Guest. In addition, many Orphan VCPUs are percpu, which means that the ready queue of each hcpu (physical CPU) must have an Orphan VCPU with a higher priority than the Normal VCPU. In this way, the real-time performance of the Normal VCPU cannot be guaranteed.
[0024] PRM scheduling strategy: There is a limit on the VCPU scheduling frequency, that is, the smaller the periodicity of the VCPU in a ready queue is set, the higher the priority it will be scheduled. Similar to PRR, the Orphan VCPU in Xvisor is a hypervisor management thread with a higher priority than the Normal VCPU created in the Guest. If the Orphan VCPU is running on a hcpu, the Normal VCPU cannot be scheduled and can only run when the Orphan VCPU finishes running and releases the hcpu. Therefore, the real-time performance of the Normal VCPU cannot be guaranteed either. Summary of the invention
[0025] In order to overcome the above defects, the present invention is proposed to provide a solution to the technical problem that the ready queue of the Xvisor scheduler is implemented using per cpu variables, resulting in the Normal VCPU not being able to respond in time and the real-time performance not being guaranteed.
[0026] The present invention provides a scheduling method for improving the real-time performance of an Xvisor scheduler, comprising the following steps:
[0027] Call the vmm_scheduler_init function as the kernel initialization function, so that the scheduler can create a scheduling entity ready queue ready queue for all physical CPUs;
[0028] Call the vmm_schedalgo_rq_create function to create a scheduling entity ready queue and use the red-black tree rb tree to manage the executable VCPUs at different priorities;
[0029] Use the PRM scheduling strategy to perform the enqueue operation;
[0030] Use the PRM scheduling strategy to perform dequeue operations;
[0031] Acquire spin locks during enqueue and dequeue operations respectively.
[0032] Furthermore, the scheduling entity ready queue supports eight priorities from 0 to 7, and maintains a red-black tree rb tree for each priority.
[0033] Further, the enqueue operation is performed using the PRM scheduling strategy, including the following steps:
[0034] Call the vmm_schedalgo_rq_enqueue function and find the target red-black tree rbtree according to vcpu->priority;
[0035] The found red-black tree rb tree is traversed according to the scheduling frequency, and the node to be inserted is found according to the basic principle followed by adding nodes in rb_tree.
[0036] Further, the dequeue operation is performed using the PRM scheduling strategy, including the following steps:
[0037] Call the vmm_schedalgo_rq_dequeue function to find the highest priority and non-empty scheduling entity ready queue ready queue;
[0038] Starting from the root of the found scheduling entity ready queue ready queue, traverse to find the node corresponding to the minimum scheduling frequency, and assign the node as the next scheduling entity to next.
[0039] Further, acquiring the spin lock during the enqueue operation includes the following steps:
[0040] Call the static int rq_enqueue function, register two variables int ret and irq_flags_tflags in it, define the int ret variable to store the return value of the function vmm_schedalgo_rq_enqueue, and the irq_flags_tflags variable to save the status of the interrupt flag;
[0041] Call the vmm_spin_lock_irqsave_lite function to acquire the spin lock and modify the flags variable to disable interrupts;
[0042] Call the vmm_schedalgo_rq_enqueue function, add the vcpu to the ready queue of the scheduling entity corresponding to the spin lock, and store the return value of the vmm_schedalgo_rq_enqueue function in the ret variable;
[0043] Call the vmm_spin_unlock_irqrestore_lite function to release the previously acquired spin lock and modify the flags variable to restore the interrupt status;
[0044] Call the vmm_schedalgo_rq_enqueue function to return the value of the ret variable to determine whether the operation of VCPU joining the scheduling entity ready queue is successful.
[0045] Further, acquiring the spin lock during the dequeue operation includes the following steps:
[0046] Call the static int rq_dequeue function, register two variables int ret and irq_flags_tflags in it, define the int ret variable to store the return value of the function vmm_schedalgo_rq_dequeue, and the irq_flags_tflags variable to save the status of the interrupt flag;
[0047] Call the vmm_spin_lock_irqsave_lite function to acquire the spin lock and modify the flags variable to disable interrupts;
[0048] Call the vmm_schedalgo_rq_dequeue function, add the vcpu to the ready queue of the scheduling entity corresponding to the spin lock, and store the return value of the vmm_schedalgo_rq_dequeue function in the ret variable;
[0049] Call the vmm_spin_unlock_irqrestore_lite function to release the previously acquired spin lock and modify the flags variable to restore the interrupt status;
[0050] Call the vmm_schedalgo_rq_dequeue function to return the value of the ret variable to determine whether the operation of releasing the VCPU from the scheduling entity ready queue is successful.
[0051] Working principle and beneficial effects of the present invention:
[0052] In the technical solution of the present invention, based on the implementation of the ready queue in the PRM scheduling strategy, the creation of a ready queue for each hCPU is changed to creating a shared global variable ready queue for all hCPUs. In order to ensure data synchronization, spin locks are added to the queue entry and queue exit operations, thereby improving the real-time performance of the Xvisor scheduler. DETAILED DESCRIPTION
[0053] Some embodiments of the present invention are described below. It should be understood by those skilled in the art that these embodiments are only used to explain the technical principles of the present invention and are not intended to limit the protection scope of the present invention.
[0054] Example 1
[0055] This embodiment proposes a scheduling method for improving the real-time performance of the Xvisor scheduler, which mainly includes the following four parts.
[0056] 1. Creation of ready queue
[0057] Remove the process of creating a ready queue for each hcpu in the scheduler_startup function and refactor it. Add the creation of a common variable ready queue for all hcpus in the vmm_scheduler_init function. Use the vmm_schedalgo_rq_create function to create a ready queue for a specific scheduling algorithm. Specifically for PRM, the vmm_schedalgo_rq_create function remains unchanged, using the existing implementation to support eight priorities from 0 to 7, and maintaining an rbtree for each priority.
[0058] Specifically, this process includes the following steps:
[0059] Call the vmm_scheduler_init function as the kernel initialization function, so that the scheduler can create a ready queue (rq) for all host cpus (physical CPUs).
[0060] Call vmm_schedalgo_rq_create function to create a new ready queue structure ready queue (rq), which uses red-black tree rb tree to manage the executable VCPUs at different priorities. Specifically, it supports eight priorities from 0 to 7, and maintains an rb tree for each priority.
[0061] The specific implementation code is as follows:
[0062]
[0063] 2 Enqueue Operation
[0064] The enqueue operation is implemented by calling the existing vmm_schedalgo_rq_enqueue function.
[0065] Specifically, this process includes the following steps:
[0066] Find the target rb tree according to vcpu->priority. This rb tree is created during the creation of the ready queue.
[0067] Then, according to the scheduling frequency periodicity, the rb tree found above is traversed. According to the basic principle that when adding nodes to rb_tree, the smaller the vcpu->periodicity, the lower the left node should be placed, the parent node to be inserted is found.
[0068] 3. Dequeue Operation
[0069] The dequeue operation is implemented by calling the existing vmm_schedalgo_rq_dequeue function.
[0070] Specifically, this process includes the following steps:
[0071] Find the highest priority and non-empty ready queue;
[0072] Starting from the root of the ready queue found above, traverse to find the lower left parent node, remove this node, and assign this node to next as the next scheduling entity found.
[0073] 4. Ready queue synchronization
[0074] Since the ready queue is a data structure shared by all hCPUs, a spin lock is required to ensure synchronization. In other words, only one hCPU is allowed to operate the ready queue at any time.
[0075] 4.1 Obtain a spin lock when enqueuing:
[0076] Call the static int rq_enqueue function, in which two variables int ret and irq_flags_tflags are registered. The int ret variable is defined to store the return value of the function vmm_schedalgo_rq_enqueue, indicating the result of the enqueue operation. The irq_flags_tflags variable is used to save the status of the interrupt flag so that interrupts can be disabled when the spin lock is acquired and restored when the spin lock is released.
[0077] Call the vmm_spin_lock_irqsave_lite function, acquire the spin lock, and modify the flags variable to disable interrupts. The flags variable is used to save the current interrupt status so that it can be restored later. This is to prevent concurrent access when modifying the ready queue of the scheduling entity.
[0078] Call the vmm_schedalgo_rq_enqueue function to add the vcpu to the ready queue of the scheduling entity corresponding to the spin lock. The return value of this function is stored in the ret variable to indicate whether the operation is successful.
[0079] Call the vmm_spin_unlock_irqrestore_lite function to release the previously acquired spin lock and modify the flags variable to restore the interrupt status. Ensure that the system can respond to interrupts normally after modifying the scheduling entity ready queue.
[0080] Calling the vmm_schedalgo_rq_enqueue function returns the value of the ret variable, indicating whether the operation of adding the VCPU to the ready queue of the scheduling entity is successful.
[0081] The specific implementation code is as follows:
[0082]
[0083]
[0084] 4.2 Obtain a spin lock when dequeuing:
[0085] Call the static int rq_dequeue function, in which two variables int ret and irq_flags_tflags are registered. The int ret variable is defined to store the return value of the function vmm_schedalgo_rq_dequeue, indicating the result of the dequeue operation. The irq_flags_tflags variable is used to save the status of the interrupt flag so that interrupts can be disabled when the spin lock is acquired and restored when the spin lock is released.
[0086] Call the vmm_spin_lock_irqsave_lite function, acquire the spin lock, and modify the flags variable to disable interrupts. The flags variable is used to save the current interrupt status so that it can be restored later. This is to prevent concurrent access when modifying the ready queue of the scheduling entity.
[0087] Call the vmm_schedalgo_rq_dequeue function to add the vcpu to the ready queue of the scheduling entity corresponding to the spin lock. The return value of this function is stored in the ret variable to indicate whether the operation is successful.
[0088] Call the vmm_spin_unlock_irqrestore_lite function to release the previously acquired spin lock and modify the flags variable to restore the interrupt status. Ensure that the system can respond to interrupts normally after modifying the scheduling entity ready queue.
[0089] Calling the vmm_schedalgo_rq_dequeue function returns the value of the ret variable, indicating whether the operation of placing the VCPU into the ready queue of the scheduling entity is successful.
[0090] The specific implementation code is as follows:
[0091]
[0092] Based on the above steps, this solution is based on the implementation of ready queue in PRM scheduling strategy. It changes the creation of ready queue for each hCPU into creating a shared global variable ready queue for all hCPUs. In order to ensure data synchronization, spin locks are added in the queue entry and queue exit operations, which improves the real-time performance of Xvisor scheduler.
[0093] It should be pointed out that although the various steps in the above embodiments are described in a specific order, those skilled in the art can understand that in order to achieve the effects of the present invention, different steps do not have to be performed in such an order. They can be performed simultaneously (in parallel) or in other orders. These changes are within the scope of protection of the present invention.
[0094] Example 2
[0095] Based on the technical solution of the above-mentioned embodiment 1, this embodiment proposes a specific implementation method.
[0096] The Raspberry Pi 4B hardware is used for testing, where the guest vCPU is set to 3 with the following parameters
[0097]
[0098] in:
[0099] priority: VCPU priority. The larger the value, the higher the priority.
[0100] time_slice: The minimum time slice in nano-seconds that a VCPU can obtain once it is scheduled.
[0101] deadline: The maximum time limit in nano-seconds that the VCPU must be scheduled to run.
[0102] periodicity: The frequency at which the VCPU status changes to ready or starts working, in nano-seconds.
[0103] The operating system version running in the guest is Linux with the PREEMPT_RT patch installed, version number is 5.10.0-rc7-rt16 SMP PREEMPT_RT.
[0104] Tested with cyclisttest, version V 0.92, test command cyclictest-t1-p 99-n 1000-D1d
[0105] The test results are as follows, showing that real-time performance has been significantly improved.
[0106] Before scheduler optimization
[0107] T:0(550)P:99I:1000C:21367300Min:16Act:37Avg:43Max:1500
[0108] After scheduler optimization
[0109] T:0(550)P:99I:1000C:21367300Min:16Act:37Avg:43Max:78
[0110] Example 3
[0111] For ease of understanding, the relevant codes involved in the background technology are attached here as follows.
[0112]
[0113] In scheduler_startup, schedp is a percpu variable, and each host cpu (physical CPU) creates an rq, namely schedp->rq.
[0114]
[0115]
[0116] PRR: supports eight priorities from 0 to 7, and maintains a linked list for each priority. The larger the value of PRIORITY (i.e. the variable p in the code below, priority), the higher the priority.
[0117]
[0118] PRM: supports eight priorities from 0 to 7 and maintains a rb tree for each priority.
[0119]
[0120]
[0121] 2. Entry operation PRR:
[0122]
[0123]
[0124]
[0125] 3. Departure operation PRR:
[0126]
[0127]
[0128]
[0129] So far, the technical solutions of the present invention have been described in conjunction with the preferred embodiments, but it is easy for those skilled in the art to understand that the protection scope of the present invention is obviously not limited to these specific embodiments. Without departing from the principle of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will fall within the protection scope of the present invention.
Claims
1. A scheduling method for improving the real-time performance of an Xvisor scheduler, characterized in that: The following steps are involved: Call the vmm_scheduler_init function as the kernel initialization function, so that the scheduler can create a scheduling entity ready queue ready queue for all physical CPUs; Call the vmm_schedalgo_rq_create function to create a scheduling entity ready queue and use the red-black tree rb tree to manage the executable VCPUs at different priorities; Use the PRM scheduling strategy to perform the enqueue operation; Use the PRM scheduling strategy to perform dequeue operations; Acquire spin locks during enqueue and dequeue operations respectively.
2. A scheduling method for improving the real-time performance of the Xvisor scheduler according to claim 1, characterized in that: The scheduling entity ready queue supports eight priorities from 0 to 7, and maintains a red-black tree rb tree for each priority.
3. A scheduling method for improving the real-time performance of the Xvisor scheduler according to claim 1, characterized in that: Use the PRM scheduling strategy to perform the enqueue operation, including the following steps: Call the vmm_schedalgo_rq_enqueue function and find the target red-black tree rb tree according to vcpu->priority; The found red-black tree rb tree is traversed according to the scheduling frequency, and the node to be inserted is found according to the basic principle followed by adding nodes in rb_tree.
4. A scheduling method for improving the real-time performance of the Xvisor scheduler according to claim 3, characterized in that: Use the PRM scheduling strategy to perform the dequeue operation, including the following steps: Call the vmm_schedalgo_rq_dequeue function to find the highest priority and non-empty scheduling entity ready queue ready queue; Starting from the root of the found scheduling entity ready queue ready queue, traverse to find the node corresponding to the minimum scheduling frequency, and assign the node as the next scheduling entity to next.
5. A scheduling method for improving the real-time performance of the Xvisor scheduler according to claim 1, characterized in that: Acquire the spin lock during the enqueue operation, including the following steps: Call the static int rq_enqueue function, register two variables int ret and irq_flags_tflags in it, define the int ret variable to store the return value of the function vmm_schedalgo_rq_enqueue, and the irq_flags_tflags variable to save the status of the interrupt flag; Call the vmm_spin_lock_irqsave_lite function to acquire the spin lock and modify the flags variable to disable interrupts; Call the vmm_schedalgo_rq_enqueue function, add the vcpu to the ready queue of the scheduling entity corresponding to the spin lock, and store the return value of the vmm_schedalgo_rq_enqueue function in the ret variable; Call the vmm_spin_unlock_irqrestore_lite function to release the previously acquired spin lock and modify the flags variable to restore the interrupt status; Call the vmm_schedalgo_rq_enqueue function to return the value of the ret variable to determine whether the operation of VCPU joining the scheduling entity ready queue is successful.
6. A scheduling method for improving the real-time performance of the Xvisor scheduler according to claim 1, characterized in that: Acquire the spin lock during the dequeue operation, including the following steps: Call the static int rq_dequeue function, register two variables int ret and irq_flags_tflags in it, define the int ret variable to store the return value of the function vmm_schedalgo_rq_dequeue, and the irq_flags_tflags variable to save the status of the interrupt flag; Call the vmm_spin_lock_irqsave_lite function to acquire the spin lock and modify the flags variable to disable interrupts; Call the vmm_schedalgo_rq_dequeue function, add the vcpu to the ready queue of the scheduling entity corresponding to the spin lock, and store the return value of the vmm_schedalgo_rq_dequeue function in the ret variable; Call the vmm_spin_unlock_irqrestore_lite function to release the previously acquired spin lock and modify the flags variable to restore the interrupt status; Call the vmm_schedalgo_rq_dequeue function to return the value of the ret variable to determine whether the operation of releasing the VCPU from the scheduling entity ready queue is successful.