OSv—Optimizing the Operating System for Virtual Machines 2

OSv的核心是用c++ 11写的，包括OSv loader，dynamic linker，memory management， thread scheduler， synchronization机制，虚拟硬件驱动。
OSv的小部分传统的驱动是有hypervisor是实现的（VGA， SATA...),自己又编写的部分驱动提高性能（clock, NIC,block)
OSv支持虚拟化文件系统，但采用ZFS作为其主要的文件系统
OSv重写的内核网络协议栈。
接下来部分主要讲的是： 
1：OSv的内存管理
2：OSv是如何且为什么要完全避免spinlock
3：OSv网络协议栈的设计
4：OSv线程调度， lock-free algorithms， floating-point based fair accounting of run-time




1：memory management
 传统的OS使用扁平化的物理内存映射， 但是OSv使用的是虚拟内存， OSv要求内存的与页的映射有mmap API提供，
 为了提供足够大的内存映射， OSv映射的大页(2M),这个尺寸会提高应用程序的性能，减少TLB miss，
 当如果部分page需要变的更小，已经映射的内存，部分可以取消映射，OSv的页不支持换出（swap），而是提供另外的内存管理机制见section 3.


2.2： No Spinlocks
在SMP体系结构中通过spin-lock来控制多个cpu访问data并发现，目前所有的虚拟机也支持SMP体系，所以也使用spin-lock
SMP体系中当一个cpu请求原子操作的时候其他cpu就忙等待，知道该cpu释放资源， SMP OS中使用spin-lock来实现更高层次的锁机制比如sleeping mutexs，
也直接使用spin-lock在sleeping禁止的情况，比如kernel的调度中断处理上下文。
当然spin-locks在SMP的物理体系中很合适，但是我们考虑下虚拟环境下，spin-lock会有一个非常重要的缺点“lock-holder preemption”
在host os情况下物理cpu一直运行的如果OS需要cpu的话， 但是虚拟cpu会造成“pause”在未知的时间及未知的情况， 比如当hypervisor退出，或者hypervisor运行其他guest或者hypervisor就运行在这个cpu上
如果虚拟环境下cpu paused当持有一个spin-lock，如果其他cpu如果想用相同cpu也必须等待，这个浪费cpu时间。
在mutex用spin-lock实现的情况下，当一个线程发生等待的时候回立即转入sleep，让其他线程运行，这种情况就是“lock-holder preemption”，在多个guest下回造成极大的消耗，极端的情况这个线程一直无法获取cpu资源
当然这个在host环境下并不会发生。因为guest os里面的cpu并不完全属于自己。
目前来说可以让hypervisor解决这个问题，但是如果从内核设计来说应该完全避免这种情况的发生。 OSv根本没有spin-lock，并没有放弃基本的lock或者严格限制在一个处理器的环境。


OSv使用为每个cpu设置队列及lock算法达到lock-free
OSv使用普通线程执行所有事情，中断处理只是换新一个线程服务中断设备， kernel的代码在普通的线程上也像个普通的app，OSv的设计重点主要减少上下切换的时间，从而提高效率。
OSv的lock-free的mutex是通过数据结构实现的， OSv lock-free的mutex： 一个cpu的paused不会造成其他cpu的spinning。因此kernel和app code避免了lock-holder preemption问题。
最后，每个调度程序程序有自己的运行队列，所以大部分调度只是针对本地的cpu，所以并不需要锁保护，当调度程序需要跨cpu的时候就需要lock-free算法了，比如唤醒一个属于不同cpu的线程。


2.3 network channels
每个云操作系统必须提供高可用的TCP/IP协议栈， OSv实现的是依据Van Jacobson’s net channelideas [10]，