虚拟机（xen）中credit调度算法分析---(二)

 

上面我已经介绍了schedule.c文件中调度部分的代码,那么接下来正式进入主题，说说sched_credit.c文件中的主要涉及调度的数据结构与函数。
     首先我们说说Xen的Credit调度器：管理员为每个domain分配weight值来决定credit值，Xen按照credit值公平调度各个domain。Domain中VCPU有两种状态，UNDER和OVER。OVER表示Domain中VCPU的credit值已用完，UNDER表示credit值还有剩余。在进行调度时，调度器只关心VCPU所处的状态，而不会进一步关心其剩余的credit值，处于UNDER状态的VCPU总是优先于OVER状态的VCPU被调度，只有当UNDER状态的VCPU都无法运行时才会调度到OVER状态的VCPU，所以，只有当处理器空闲时才允许破坏credit的公平性调度策略。处于相同状态的VCPU按照先进先出的方式运行，当处于队列首部的虚拟机被调度到时，在其credit值足够的情况下，允许其运行三个调度时长，即30ms。系统每隔10ms触发一次调度中断，当前正在运行的VCPU会被减掉100个credit，当所有VCPU的credit值总和变为负值时，为所有VCPU重新分配credit。
     当事件被发送到domain的VCPU时，如果VCPU处于空闲状态，Xen就会会将其唤醒，然后，调度器会被立即运行，重新计算调度顺序，如果新被唤醒的虚拟机具有较高的优先级(这里指的是BOOST状态，不是BOOST的话，应该直接被放入到UNDER状态的最后一个)，则之前正在运行的虚拟机会被抢占调度。在Credit最初的设计中，接收到事件的VCPU总是被放在调度队列的尾部，虽然调度器会立即重新计算调度顺序，但它必须等待排在其前面的所有VCPU都运行完才会被调度到。
PS:在响应敏感类应用中，事件响应延迟与其所处的队列位置密切相关，响应延迟普遍较长且波动明显。为了解决响应延迟时间过长的问题，Credit调度算法新加入了一个BOOST状态，处于BOOST态的虚拟机具有最高的优先级。空闲的虚拟机在通过事件通道接收到一个事件时会进入BOOST态，因为BOOST态优先级最高，如果允许调度器立即重新调度，则该虚拟机会被立即调度到。经实验证明，加入BOOST态的Credit算法可以大大降低响应延迟的平均值，但如果有多台虚拟机同时进行I/O操作，则他们都会被BOOST，从而无法体现BOOST态优先级高的优势，等待处理的事件仍有可能长时间得不到响应，所以，对波动现象改进很少。BOOST对I/O的带宽也有明显改进。

我在下面举个简单的计算credit的例子：