Paravirtualization for Scalable Kernel-Based Virtual Machine (KVM)

K. Raghavendra, S. Vaddagiri, N. Dadhania, J. Fitzhardinge
{"title":"Paravirtualization for Scalable Kernel-Based Virtual Machine (KVM)","authors":"K. Raghavendra, S. Vaddagiri, N. Dadhania, J. Fitzhardinge","doi":"10.1109/CCEM.2012.6354619","DOIUrl":null,"url":null,"abstract":"In a multi-CPU Virtual Machine(VM), virtual CPUs (VCPUs) are not guaranteed to be scheduled simultaneously. Operating System (OS) constructs, such as busy-wait (mainly spin locks and TLB shoot-down), are written with an assumption of running on bare-metal wastes lot of CPU time, resulting in performance degradation. For e.g., suppose a spin lock holding VCPU is preempted (aka LHP) by the host scheduler, other VCPUs waiting to acquire the same spin lock, waste lot of CPU cycles. Worsening this is the ticket based spin lock implementation, which requires next eligible VCPU to acquire the lock to be running. Similarly, remote TLB flushing API's does a busy wait for other VCPUs to flush the TLB. Above problems result in a higher synchronization latency for the workloads running within a VM. Especially in a massively over-committed environment like cloud, these problems become worse. One of the existing solutions is the hardware supported Pause Loop Exiting (PLE) mechanism which detects such busy-wait constructs inside the VCPU of a VM, and automatically does VCPU exit. Alternate implementation could be gang scheduling which tries to ensure VCPUs of VMs are scheduled simultaneously. But both the implementations suffer from scalability problem and are ill suited for cloud environments. Paravirtualization is the best approach, where the guest OS is made aware that it is running in a virtualized environment, and optimize the busy-wait. Host OS also coordinate with guest to bring further performance benefits. This paper discusses about paravirtualized ticket spin locks where VCPU waiting for spin lock sleeps, and unlocker identifies next eligible lock-holder VCPU and wakes it up. In paravirtualized remote TLB flush, a VCPU does not wait for other VCPUs that are sleeping, but all the sleeping VCPUs flush the TLB when they run next time. Results show that, on a non-PLE machine, these solutions bring huge speed up in over-committed guest scenarios.","PeriodicalId":409273,"journal":{"name":"2012 IEEE International Conference on Cloud Computing in Emerging Markets (CCEM)","volume":"49 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2012-11-20","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"10","resultStr":null,"platform":"Semanticscholar","paperid":null,"PeriodicalName":"2012 IEEE International Conference on Cloud Computing in Emerging Markets (CCEM)","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1109/CCEM.2012.6354619","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
引用次数: 10

Abstract

In a multi-CPU Virtual Machine(VM), virtual CPUs (VCPUs) are not guaranteed to be scheduled simultaneously. Operating System (OS) constructs, such as busy-wait (mainly spin locks and TLB shoot-down), are written with an assumption of running on bare-metal wastes lot of CPU time, resulting in performance degradation. For e.g., suppose a spin lock holding VCPU is preempted (aka LHP) by the host scheduler, other VCPUs waiting to acquire the same spin lock, waste lot of CPU cycles. Worsening this is the ticket based spin lock implementation, which requires next eligible VCPU to acquire the lock to be running. Similarly, remote TLB flushing API's does a busy wait for other VCPUs to flush the TLB. Above problems result in a higher synchronization latency for the workloads running within a VM. Especially in a massively over-committed environment like cloud, these problems become worse. One of the existing solutions is the hardware supported Pause Loop Exiting (PLE) mechanism which detects such busy-wait constructs inside the VCPU of a VM, and automatically does VCPU exit. Alternate implementation could be gang scheduling which tries to ensure VCPUs of VMs are scheduled simultaneously. But both the implementations suffer from scalability problem and are ill suited for cloud environments. Paravirtualization is the best approach, where the guest OS is made aware that it is running in a virtualized environment, and optimize the busy-wait. Host OS also coordinate with guest to bring further performance benefits. This paper discusses about paravirtualized ticket spin locks where VCPU waiting for spin lock sleeps, and unlocker identifies next eligible lock-holder VCPU and wakes it up. In paravirtualized remote TLB flush, a VCPU does not wait for other VCPUs that are sleeping, but all the sleeping VCPUs flush the TLB when they run next time. Results show that, on a non-PLE machine, these solutions bring huge speed up in over-committed guest scenarios.
可扩展的基于内核的虚拟机(KVM)的准虚拟化
在多cpu的虚拟机中,不保证多个虚拟cpu同时被调度。操作系统(OS)结构,例如忙等待(主要是自旋锁和TLB关机),在编写时假定在裸机上运行会浪费大量CPU时间,从而导致性能下降。例如,假设持有自旋锁的VCPU被主机调度程序抢占(又名LHP),其他VCPU等待获得相同的自旋锁,浪费了大量的CPU周期。更糟糕的是基于票证的自旋锁实现,它需要下一个符合条件的VCPU获取要运行的锁。类似地,远程TLB刷新API会忙着等待其他vcpu来刷新TLB。上述问题会导致VM中运行的工作负载的同步延迟变长。特别是在像云这样的大规模过度承诺的环境中,这些问题变得更糟。现有的解决方案之一是硬件支持的Pause Loop exit (PLE)机制,它检测VM的VCPU内部的这种忙等待构造,并自动使VCPU退出。另一种实现可能是组调度,它试图确保vm的vcpu同时被调度。但是这两种实现都存在可伸缩性问题,并且不适合云环境。半虚拟化是最好的方法,在这种方法中,客户机操作系统知道它在虚拟环境中运行,并优化忙碌等待。主机操作系统还可以与来宾操作系统协调,从而带来进一步的性能优势。本文讨论了半虚拟化票据自旋锁,其中等待自旋锁的VCPU休眠,解锁器识别下一个符合条件的锁持有者VCPU并唤醒它。在半虚拟化的远程TLB刷新中,一个VCPU不等待其他正在休眠的VCPU,但是所有正在休眠的VCPU在下次运行时刷新TLB。结果表明,在非ple机器上,这些解决方案在过度使用的客户机场景中带来了巨大的速度提升。
本文章由计算机程序翻译,如有差异,请以英文原文为准。
求助全文
约1分钟内获得全文 求助全文
来源期刊
自引率
0.00%
发文量
0
×
引用
GB/T 7714-2015
复制
MLA
复制
APA
复制
导出至
BibTeX EndNote RefMan NoteFirst NoteExpress
×
提示
您的信息不完整,为了账户安全,请先补充。
现在去补充
×
提示
您因"违规操作"
具体请查看互助需知
我知道了
×
提示
确定
请完成安全验证×
copy
已复制链接
快去分享给好友吧!
我知道了
右上角分享
点击右上角分享
0
联系我们:info@booksci.cn Book学术提供免费学术资源搜索服务,方便国内外学者检索中英文文献。致力于提供最便捷和优质的服务体验。 Copyright © 2023 布克学术 All rights reserved.
京ICP备2023020795号-1
ghs 京公网安备 11010802042870号
Book学术文献互助
Book学术文献互助群
群 号:604180095
Book学术官方微信