最近看邮件，有注意到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越来越多的时候，情况就越来越糟，最后看上去就大家都很忙，但实际什么事情也没做。
目前来看，已经有一种较为成熟的软件方法来解决类似问题，期待后续是否会有硬件的一些特性来支持，或许已经有了。