vSimilar: A high-adaptive VM scheduler based on the CPU pool mechanism

Abstract

In a virtualized system, the virtual machine (VM) scheduler plays a key role to the performance promotion of the virtual machine monitor (VMM), a.k.a. hypervisor. The scheduler is responsible for assigning adequate system resources to each VM according to the demands of the VM tenants, which is quite challenging as VM tenants’ demands are quite dynamic and unpredictable. To this end, CPU pool mechanism has been widely adopted as an adaptive solution. However, the CPU pool mechanism still has defficiency in terms of VM classification model and time-slice allocation strategy, as the two strategies have to be effectively utilized for realizing a high-adaptive VM scheduler. In this paper, we thus explore opportunities to improve the CPU pool mechanism and develop a new VM scheduling solution, called vSimilar, which uses VM multi-classification model to more effectively adaptive to the VMs of running different types of tasks at different time. Moreover, by a dynamic time-slice function, vSimilar manages to provide a more efficient resource allocation. The experimental evaluation shows that vSimilar can significantly improve the performance of a VMM, such as Xen. The improvements include 1) a VM server hosted by Xen with vSimilar can reduce nearly 95% of a client’s Ping round-trip time (Ping RTT), 2) vSimilar can help increase about 40% the TCP throughput, and about 20% the UDP throughput, between a Xen-hosted VM server and a client, and 3) vSimilar also increases the page operation rate by nearly 50% for a Xen-hosted VM Web server.

Introduction

In virtualized cloud datacenters [1], VM scheduling plays a key role to improve the performance of a cloud system in various domains, such as real-time applications supporting [2], security [3], network latency reducing [4], energy efficiency [5], load balancing [6], to name just a few. The VM scheduler is responsible for allocating CPU time to VMs in VM scheduling, which is a vital component of the hypervisor [7]. The design of a VM scheduler thus has a significant impact on the overall performance of the virtualized system. In the scheduling policies of the VM scheduler, the setting of timeslice length is particularly important. For I/O-intensive VMs, achieving low I/O latency is their top priority demand, in which case, the timeslice should be set to be short. Setting a short timeslice ensures that the I/O requests of VMs are handled timely because it guarantees VMs higher scheduling frequency. In contrast to I/O-intensive VMs, fewer context switches is preferred for none-I/O-intensive VMs. Thus, setting a longer timeslice is preferred by none-I/O-intensive VMs due to the fact that long-timeslice setting does not cause too many expensive VM context switches and provides a better CPU utilization environment. Setting a unified timeslice is not able to meet both the requirements of I/O-intensive VMs and none-I/O-intensive VMs. The credit scheduler is the default and the most commonly used VM scheduler in Xen. It adopts unified timeslice setting for VMs of different I/O-intensity, and thus impede the adaptivity of the virtualized system.

Another deficiency of the credit scheduler is that it yields high I/O latency. The credit scheduler employs the Boost mechanism to accelerate the handling of I/O events. When an I/O event arrives for a none-Boost-priority VM with remaining credit, the VM will be set with a higher scheduling priority, the Boost priority, and will be scheduled before the VMs with a lower scheduling priority. In this manner, I/O event handling is made quicker. However, the Boost mechanism may not be effective in some cases. One case is that the Boost mechanism only boosts VMs with remaining credits. For VMs without remaining credits, their I/O events will not be handled before all VMs run out of their credits and all VMs are then supplied with newly allocated credits. The waiting time causes high I/O latency. Another case is that there are so many I/O-intensive VMs in the scheduling queue that almost all VMs are in the Boost priority. In this situation, the VMs have to wait in a long Boost-priority-VM queue for their scheduling turn, which is time-consuming. In these two cases, the credit scheduler fails to mitigate I/O latency.

Besides, the scheduling policies of the credit scheduler are not friendly to none-I/O-intensive VMs. The credit scheduler allows other VMs to preempt the pCPU from the VM occupying the pCPU. This policy can reduce the latency for handling I/O events. But for none-I/O-intensive VMs, this policy may cause unnecessary overhead. The main types of none-I/O-intensive VMs are CPU-bound and memory-bound and require less context switching. Frequent VM context switching causes more overhead for executing context switching codes and cache swapping, which are expensive and degrading the performance of none-I/O-intensive VMs.

To improve the credit scheduler, the Xen organization adopts cpupool scheme, which has been introduced to Xen since Xen 4.2 [8]. The idea behind the cpupool scheme is to group the physical cores (pCPU) of the machine into several pools. At any time, a given pCPU can be assigned to no more than one of these pools. A VM is assigned to a pool at a time. Each of these pools has an individual VM scheduler, and can be set with different scheduling parameters, so as to enable Xen to classify VMs to different types and allocate CPU resources according to VMs’ demands.

However, though the cpupool approach provides users tools to implement VM classification, the rulers of what VMs should be grouped into the same pool and how the parameters of the cpupool-specific VM scheduler should be set are not addressed. These issues have to be addressed in order to build a VM scheduler with high adaptability, low I/O latency, and fair friendliness to none-I/O-intensive VMs.

In this paper, we thus propose approaches to build a high-adaptive VM scheduler, called vSimilar, on extending our previous work [9]. In comparison, we improve the dynamic time slice function and VM scheduling scheme in vSimilar. vSimilar classifies VMs according to their average I/O-event count per second, and classifies VMs into as many types as possible to obtain fine-grained VM classification to ensure superior compatibility between the scheduling strategy and the characteristics of various VMs. Here, vSimilar uses the number of pCPUs as the number of types of VMs, because larger number of types will cause more than one types of VMs to be scheduled to one single pCPU such that different parameters for the cpupool-specific VM scheduler are not allowed to be set. On each physical core, vSimilar dynamically calculates a time-slice for all VMs in the core. vSimilar takes the performance of both I/O and CPU activities into considerations, which is more balanced and fairer treatment of I/O and CPU activities.

The contributions of this paper can be summarized as follows:

• We analyze the main causes leading to high latency, low CPU usage and low network throughput;

• We propose a new VM scheduling model, vSimilar, to achieve higher performance on CPU and I/O;

• Our proto system, vSimilar, implemented on hypervisor Xen 4.4. achieve nearly 95% latency mitigation, and about 40% and 20% throughput enhancement on TPC and UDP performance gain, respectively, which is substantially higher than previously proposed approaches. It is worth noticing that vSimilar is implemented on application level, and requires no modification of Xen source code.

The rest of this paper is organized as follows. Section 2 introduces the background, the previous work, and the unresolved issues. Section 3 describes in detail how vSimilar addresses the main causes that contribute to low performance of VMM. Section 4 briefly discusses implementation issues of vSimilar. Section 5 presents the evaluation results of vSimilar, using vSimilar in hypervisor Xen. Finally, Section 6 discusses the future work and concludes the paper.