pv ticketlock解决虚拟环境下的spinlock问题
2013-09-16 19:33
253 查看
最近看邮件,有注意到pv ticketlock相关的消息,貌似jeremy 几年前的东东,终于将要被收录到linux 3.12里面。
先说下pv ticketlock这东西,http://blog.xen.org/index.php/2012/05/11/benchmarking-the-new-pv-ticketlock-implementation/ 这里面介绍的非常详细,不想看英文的话,我可以大概解释下。
spinlock在非虚拟化的环境下,它是可以认为cpu不会被抢占的,所以A拿锁干活,B死等A,A干完自己的活,就释放了,中间不会被调度。但是在虚拟化下,cpu对应到vcpu, 每个vcpu跟之前裸机上的进程调度一样,所以A拿锁干活,并不一定不会被抢占,很有可能被调度走了,因为cpu这时候还不知道vcpu在干嘛。B死等A,但是A被调度了,运行了C,C也要死等A, 在一些设计不够好的系统里面,这样就会变得很糟糕。
为了保证spinlock unlock的公平性,有一种队列的spinlock,ticketlock, http://www.ibm.com/developerworks/cn/linux/l-cn-spinlock/这篇文章介绍的非常详细,总之根据next, own,来判断是否到自己了。这样一种机制在裸机上是可以解决公平的问题,但是放到虚拟化环境里,它会使问题变得更糟。C必须等到B完成才可以,如果中间B被调度了,又开始循环了,当然更糟的定义也是相对的,如果vcpu的调度机制能够vcpu正在拿锁的话,会怎样?
jeremy很早就写了一个pv ticketlock,原理大概就是vcpu在拿锁了一段时间,会放弃cpu,并blocked,unlocked的时候会被唤醒,这个针对PV制定的优化,在vcpu拿不到锁的场景下,并没有任何的性能损耗,并且能够解决之前的问题,但是当运行native linux的时候,就会有性能损耗,所以当时在config里面添加了一个编译选项CONFIG_PARAVIRT_SPINLOCK,话说我们的系统里面,这个是没打开的啊,后面要再好好评估下
之后,这个patch进行了改良,在原有native linux的ticketlock的基础,增加了一种模式,通过检测cpu是否spinned一段时间,判断是否要进入slow path,之前的fast path的逻辑和原来保持不变,进入slowpath后,会在ticketlock里面置位,并block vcpu,等unlock的时候,这个位会被clear,因为占用了一个位,所以能用的ticket少了一半。
这个方案在一些硬件(XEON x3450)上进行各种benchmark测试后,结论是不再有任何的性能损耗。
好吧,说了这么多理论性的东西,再来说下,我们实际遇到的问题。 很早以前经常有windows用户的工单投诉,说自己的vm里面cpu没有怎么使用,为什么cpu显示百分之百。
由于是windows系统,加上我是小白,很难给出一些技术细节上的分析,只能通过简单滴一些测试实验进行调查。
最后的结果,就是windows很多核的情况下,比如12、16, 在一个稍微有点load的物理机上面,跑一些cpu压力,就很容易出现cpu百分百的问题,后面降core之后,情况有所缓解。后面大致的分析结果是,windows里面很多操作是用到spinlock的,当一个core拿到锁,事情没有做完,被调度了,这时其他的core也需要拿锁,当core越来越多的时候,情况就越来越糟,最后看上去就大家都很忙,但实际什么事情也没做。
目前来看,已经有一种较为成熟的软件方法来解决类似问题,期待后续是否会有硬件的一些特性来支持,或许已经有了。
先说下pv ticketlock这东西,http://blog.xen.org/index.php/2012/05/11/benchmarking-the-new-pv-ticketlock-implementation/ 这里面介绍的非常详细,不想看英文的话,我可以大概解释下。
spinlock在非虚拟化的环境下,它是可以认为cpu不会被抢占的,所以A拿锁干活,B死等A,A干完自己的活,就释放了,中间不会被调度。但是在虚拟化下,cpu对应到vcpu, 每个vcpu跟之前裸机上的进程调度一样,所以A拿锁干活,并不一定不会被抢占,很有可能被调度走了,因为cpu这时候还不知道vcpu在干嘛。B死等A,但是A被调度了,运行了C,C也要死等A, 在一些设计不够好的系统里面,这样就会变得很糟糕。
为了保证spinlock unlock的公平性,有一种队列的spinlock,ticketlock, http://www.ibm.com/developerworks/cn/linux/l-cn-spinlock/这篇文章介绍的非常详细,总之根据next, own,来判断是否到自己了。这样一种机制在裸机上是可以解决公平的问题,但是放到虚拟化环境里,它会使问题变得更糟。C必须等到B完成才可以,如果中间B被调度了,又开始循环了,当然更糟的定义也是相对的,如果vcpu的调度机制能够vcpu正在拿锁的话,会怎样?
jeremy很早就写了一个pv ticketlock,原理大概就是vcpu在拿锁了一段时间,会放弃cpu,并blocked,unlocked的时候会被唤醒,这个针对PV制定的优化,在vcpu拿不到锁的场景下,并没有任何的性能损耗,并且能够解决之前的问题,但是当运行native linux的时候,就会有性能损耗,所以当时在config里面添加了一个编译选项CONFIG_PARAVIRT_SPINLOCK,话说我们的系统里面,这个是没打开的啊,后面要再好好评估下
之后,这个patch进行了改良,在原有native linux的ticketlock的基础,增加了一种模式,通过检测cpu是否spinned一段时间,判断是否要进入slow path,之前的fast path的逻辑和原来保持不变,进入slowpath后,会在ticketlock里面置位,并block vcpu,等unlock的时候,这个位会被clear,因为占用了一个位,所以能用的ticket少了一半。
这个方案在一些硬件(XEON x3450)上进行各种benchmark测试后,结论是不再有任何的性能损耗。
好吧,说了这么多理论性的东西,再来说下,我们实际遇到的问题。 很早以前经常有windows用户的工单投诉,说自己的vm里面cpu没有怎么使用,为什么cpu显示百分之百。
由于是windows系统,加上我是小白,很难给出一些技术细节上的分析,只能通过简单滴一些测试实验进行调查。
最后的结果,就是windows很多核的情况下,比如12、16, 在一个稍微有点load的物理机上面,跑一些cpu压力,就很容易出现cpu百分百的问题,后面降core之后,情况有所缓解。后面大致的分析结果是,windows里面很多操作是用到spinlock的,当一个core拿到锁,事情没有做完,被调度了,这时其他的core也需要拿锁,当core越来越多的时候,情况就越来越糟,最后看上去就大家都很忙,但实际什么事情也没做。
目前来看,已经有一种较为成熟的软件方法来解决类似问题,期待后续是否会有硬件的一些特性来支持,或许已经有了。
相关文章推荐
- pv ticketlock解决虚拟环境下的spinlock问题
- 解决Anaconda在指定虚拟环境下无法包的问题
- 【转】解决VMWare中“二进制转换与此平台上的长模式不兼容,此虚拟环境中的长模式将被禁用”问题
- VM 安装Linux虚拟服务器:环境搭建遇到:《Linux “ifconfig”看不到inet address》问题--解决土方法
- (转)解决VMWare中“二进制转换与此平台上的长模式不兼容,此虚拟环境中的长模式将被禁用”问题
- 解决cocoapods diff: /../Podfile.lock: No such file or directory以及iOS开发同一应用多环境配置的问题
- Windows7 中在VMware Workstation虚拟环境下的Ubuntu安装遇到的问题及解决办法记录
- 解决VMWare中“二进制转换与此平台上的长模式不兼容,此虚拟环境中的长模式将被禁用”问题
- win8下使用vagrant安装部署Linux虚拟环境出错的问题解决
- 64位WIN7下Android 开发环境搭建(SDK Manager闪退,无法更新sdk,建立新项目时无法正常自动生成Activity的问题解决)
- 在win10环境下解决sublime text 3 build 3143的package controller 问题
- openCV2.4.13+VS2015+Cmake开发环境配置,解决nonfree问题
- 如何解决SVN目录的cleanup问题和lock问题
- Unix NetWork Programming——环境搭建(解决unp.h等源码编译问题)
- tiny6410配置linux开发环境问题解决办法
- 解决unix环境高级编程的第一个程序运行问题
- 解决XCODE配置LLVM环境出现的问题
- 修改CentOS7,修改默认语言环境,解决中文乱码问题。
- 安卓模拟器Genymotion虚拟设备启动失败问题的解决方法
- EBS 开发 如何解决内部开发环境上Subinventory Form上的问题