假如你是设计者,你会设计怎样的调度机制呢?
时间片
最简单的,小学生都能想出来的一种,每个 ready task,按照一个固定的时间片轮流执行。
大家不要抢,挨个儿排队执行。执行完时间片,就排在后面。
这个方案的问题很明显,就是实时性不佳。
就是一些高优先级的任务得不到及时处理。
很显然,得加入 优先级。
时间片轮转的可抢占优先级
加入优先级。
分为可抢占、不可抢占:
- 不可抢占,就是当前的任务必须运行结束,才能调度下一个最高优先级的执行。显然,实时性有问题。
- 可抢占,一旦有新的高优先级任务出现,就可以抢占当前任务,实时性比较好。
到目前位置,都没啥新奇的。
下面就开始放大招了。(2.4内核)
实时进程、普通进程
2.4 内核,采用一个 叫 goodness 的函数,来评估每个进程可运行的 “权重” wight 大小,选取权重最大的执行即可。
这里 linux 又将进程分为两类,实时进程、普通进程。
实时进程优先级理应很高,所以他的优先级直接 权重 +1000 的base, 然后加上实时进程内部的优先级。
普通进程的权重数量级为 几十 而已,但是它的权重计算比较复杂,涉及到动态优先级和静态优先级。
动态优先级、静态优先级
所谓的动态优先级,就是 当前进程 时间片还剩多少个单位(counter),很好理解,就是还没开始运行的任务,优先级肯定比 已经运行了一段时间的任务优先级高。毕竟出于公平的原则,大家都得得到运行的时间才对。
这个counter 值,没消耗完一个时间片,就会被 减1.
所谓的静态优先级,就是一个 叫 nice 的整数,表示一个程序的谦让程度(-20 ~ 19),这玩意比较微妙,数值越大,表示约“谦让”,也就是优先级越低,这个是 nice 值,是创建任务的时候就定下来的,所以叫 “静态”优先级。
goodness
基于上面的综合因素考量,2.4内核的 goodness 函数如下,计算出来的 weight,是评判调度顺序的唯一标准:
伪代码逻辑很清晰:
就是先判断进程的类型,如果是 实时的,优先级非常非常高。直接 weight 1000 开外了,然后再加上实时进程各自的优先级。
接下来才是 普通的进程,先看动态优先级,如果 count 值为0 ,也就是时间片用完了,那也直接退出,优先级设置为最低的 -1.
否则呢,先做个微调:
if (p->mm == this_mm || !p->mm)
这句话的意思是说:p->mm 如果为NULL,说明该进程无需用户空间(比如内核线程),则无需切换到用户空间,如果 p->mm == this_mm,说明该进程的用户空间就是当前进程的用户空间。该进程完全有可能得到运行。对于上述两种情况,需要适当给一些奖励,因为他们的进程切换开销比较小。比较适合得到调度。
最后,我们通过:
weight += 20 - p->nice,加入静态优先级 nice,越 “谦让”,这个 weight 就越小。
至此,我们就能根据 goodness 计算出每个 进程的 weight 值,从大到小运行即可。
2.6内核的优化
上面 2.4内核 的调度策略有个最大的问题,就是只有一个 就绪队列。对于时间片已经为 0 的,依然存在于就绪队列中,显然这是不合理的(时间片耗尽的,就应该滚出去先),如果这个队列很长,光遍历一遍就会耗费很多时间,对于一些硬实时场景,不太适合。
于是 2.6 内核采用了一种优化,设计了两个队列,一个 active 队列,一个 expired 队列:
看上面的解释,很容易理解了。
这样就解决了单就绪队列导致的遍历时间过长的问题。
后来
等 2.6.23 之后,就采用了 CFS 调度器去调度普通进程了,实时进程还是用之前的办法。
待续。。。