OSv—Optimizing the Operating System for Virtual Machines 3

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


从图a， 所有的中断内容（硬中断和软中断）和程序（packets）内容的处理都在网络协议栈，这就造成在大量socket连接及数据处理时了内容访问和数据共享之间的lock、cache line的竞争，导致性能恶化。


为了解决上述竞争问题，在OSv中所有的packet处理是有一个线程， 当处理packets接收， 使用一个简单分类器 channel， 这是一个单例的生产者和消费者队列处理packet的转发到相应的应用程序，
每个管道管理一个简单的数据流类型， 比如TCP连接或者UDP路径是直接由网卡到socket。


另外，现在只有一个线程访问数据，locking变得简单多了，同时减少run-time和maintenance的overhead


图C， 
1：因为socket receive buffer 和 send buffer现在在同一个线程，所以并不需要拆分出两个lock。
2：等待队列已经减少和代替 内部交换的排它锁的数据同步问题。
3：TCP lock和socket lock已经合并，因此现在处理TCP都伴随着处理socket的内容。 


2.4 线程调度
OSv线程调度设计的核心lock-free, preemptive, tick-less, fair, scalable and efficient.
lock-free： section 2.2已经解释了， OSV的调度也不应该使用spin-lock ，显然的也不能使用sleep mutex


preemptive： OSv完全支持抢占式多任务的， 线程自动的被调度（waiting， yielding or waking up）， 任意一种都可以在任何时间发生，
抢占式被由中断出发， 所有线程都可以被抢占，并不区分app和kernel。 使用preemp-disable计数器一个线程可以临时的避免被抢占，
这个功能在一些case非常有用，比如 保持每个CPU可以 或者 RCU locks。 在一个现在已经禁用抢占式的时候接收不到中断型号，但是一旦该线程启用了抢占式，这个线程最终还是会接收到以前中断信号。

Tick-less ： 大多数经典的kernel，甚至最新的kernel， 都利用周期时钟中断， 比如TICK， Tick会造成周期性的调度。 内核为每个线程都标记时间片，然后分配给时间片给每个线程。

Tick带来很多方便，但是也有好多不利的方面，最重要的就是执行时钟中断浪费cpu时间，另外一个事实就是在一个虚拟机中执行中断比在物理机上要更慢， 还有涉及到hypervisor退出问题。
由于ticks在虚拟化方面的缺点， OSv实现了自己的设计，使用high resolution clock， 调度器计算每个线程的精确的执行时间，使用其近似值代替ticks， 不过有时候时钟中断也会被用到。
无论如何公平调度算法决定哪个线程运行， 也计算出该线程什么时候需要切换到下一个线程。 调度程序也使用延迟值避免频繁切换在两个busy thread。 默认的延迟值为2ms， 两个busy thread就会
造成4ms的时间片的延迟， 调度器不在再1s内执行超过500个的时钟中断， 如果没有多个线程不断的出现竞争这个值会更低。


Fair： 每次重新调度， 调度器比句觉得哪个CPU将要运行，且需要执行多少时间。 一个公平的调度器必须记录每个线程的run-time， 实现公平调度或者实现针对不同优先级别的线程提高响应的百分比。
但是如果使用每个线程的总体运行时间图调度会马上找出不平衡。 比如：如果一个现在没有使用线程超过10s 而接下来将要运行， 这个会造成这个线程接下来会运行10s，这样调度器就实现的公平分配时间。
相反，我们通过使用run-time的历史值来实现公平运行。
OSv调度器计算每个线程的最近run time的指数衰竭值。调度器会选择使用最低的平均值来确定哪个线程运行， 同时计算这个线程可以运行的的时间。
我们的平均运行时间是一个浮点值， 有意思的是有些kernel里面是禁止使用浮点数的。这也是无奈的选择，但是让kernel里面允许浮点数的原因是OSv不区分kernel和user space。
最大的困惑是阻塞在实现使用平均运行实现它的可伸缩性。 每个调度器去更新所有线程的的平均运行时间有点不切实际。