现在的位置: 首页 > 综合 > 正文

虚拟机(xen)中credit调度算法分析—(二)

2019年05月06日 ⁄ 综合 ⁄ 共 1117字 ⁄ 字号 评论关闭

 

上面我已经介绍了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的例子:

 

【上篇】
【下篇】

抱歉!评论已关闭.