pv ticketlock解决虚拟环境下的spinlock问题
2013-09-15 20:55
218 查看
最近看邮件,有注意到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问题
- 【转】解决VMWare中“二进制转换与此平台上的长模式不兼容,此虚拟环境中的长模式将被禁用”问题
- (转)解决VMWare中“二进制转换与此平台上的长模式不兼容,此虚拟环境中的长模式将被禁用”问题
- VM 安装Linux虚拟服务器:环境搭建遇到:《Linux “ifconfig”看不到inet address》问题--解决土方法
- 解决cocoapods diff: /../Podfile.lock: No such file or directory以及iOS开发同一应用多环境配置的问题
- Windows7 中在VMware Workstation虚拟环境下的Ubuntu安装遇到的问题及解决办法记录
- 解决VMWare中“二进制转换与此平台上的长模式不兼容,此虚拟环境中的长模式将被禁用”问题
- win8下使用vagrant安装部署Linux虚拟环境出错的问题解决
- 解决Anaconda在指定虚拟环境下无法包的问题
- MySQL解决DOS环境下乱码问题
- Elastic-Job分布式环境中有问题的解决方法
- 关于ReentrantReadWriteLock两个问题及解决心得(转)
- Genymotion 解决虚拟镜像下载速度特别慢的问题
- 部署DTCMS到Jexus遇到的问题及解决思路---Linux环境搭建
- php虚拟主机session失效/无法跨页传递问题解决
- vue-cli开发环境跨域问题解决方案
- 分布式环境下基于redis解决在线客服坐席动态分配的问题
- 虚拟IP实验,遇到场景启用使用虚拟IP就报错,不启用可以正常运行的问题,解决方法
- 使用存储过程中的虚拟表解决同时从几个数据库服务器中读取记录的问题
- 非J2EE 容器环境下Spring +JPA 多持久化单元/多个JAR归档注解实体 的实体扫描问题及解决办法