标签：人人 running 归一化 长度 复杂度 实时 小技巧 交互 缺点
值得注意的是。在4.3BSD以后的BSD中，这个字段并非线性添加的，即不是每来一个时钟中断就会递增1，而是依照“越接近如今越重要，历史越久远越不重要”的原则衰减的。衰减因子为：(2*load)/(2*load+1).可见，越是离如今久远的CPU占用。越对总的CPU占用时间具有小的影响。为什么要强调p_cpu呢？由于在利他系统中。你占用CPU的时间越久，就越不符合利他行为的特征。随着p_cpu的积累，prio会逐渐添加。造成优先级降低，进而让出CPU。终于的行为还是利他的。
那么为何要有一个衰减指数呢？在利他系统中，长期占用CPU是一个“错误”的行为，可是假设知错能改，也能够既往不咎。非常久曾经的CPU占用仅仅起到參考作用就可以，没有决定性作用。
利他系统中，目的不在惩处。
在p_cpu的衰减因子中。有一个load。它指的是系统的总负载，也就是总进程数，你会发现，负载越大，因子越小，由于因子小于1，所以因子越小，p_cpu添加的速度越快。进程优先级的降低越快，每个进程的调度周期越短，保证全部进程的调度周期保持在一个大致同样的范围内，每个进程都不会过度饥饿。
nice：利他行为的直接体现，nice越大优先级越低。
我们总体看一下这个prio的计算公式。
假设nice是负值，说明这个进程不是那么“利他”，由于它的nice值并非那么的NICE！那么此时p_cpu就起到牵制它的作用了，假设nice的值是一个正值，而且非常大，则说明它在利他系统中非常NICE！此时p_cpu的意义就不大了。因此p_cpu的作用要除以4来造成“忽略最小项”的效果，我们再看nice是负值的情况p_cpu除以4的意义。在那种情况下，nice的值造成进程持续占领CPU，即便p_cpu的值除以4，它也是一个不小的值。
最后。注意。即便在利他系统中，也不是人人平等的，这就是nice值限制在一个范围内而不是一个固定值的原因，有些进程比較重要，它的nice值理所当然的低，没说的。
举个样例，即便在宗教系统，也分教皇。主教...
理解了朴素的UNIX调度机制后。我们会发现它是怎样得朴素和优美，每个进程的优先级上下波动，随时抢占(包含时钟中断发现了更高优先级的进程以及唤醒后的低内核优先级抢占。注意后者本文没有介绍，请參考UNIXv6或者《Windows Internals》)，p_cpu衰减因子的计算保证即便系统负载非常大，进程也不会过度饥饿，负载的添加对进程造成的影响仅仅是每个进程每次执行的时间降低了，由于切换密集了，这个策略十分适用于桌面交互式应用。
我给出一幅图，总体描写叙述一下UNIXv6的调度：
这又有什么意义呢？
我想说一句。在2008年。我实现了一个调度器。当时是在2.6.18内核上，当时还没有CFS(或许有了。可是我没有查到什么资料)。我们当时的需求是实时音视频传输，但同意丢帧。而且系统行为不随着系统负载的变化而变化。我当时的设计是将进程执行的平均时间片设置成一个常量T，然后计算：
Tt = nr_task * T
将Tt划分为nf_task个片段，每个片段长度为：
Ttn = Tt*(Wn/Wt)
当中，Wn为进程n的权重，而Wt为总权重。关于权重，我仅仅是简单依照nice进行归一化，保证总的全部的nice‘即weight值的和为1。以上就是一个简单的设计，你是不是认为和CFS狠像呢？我也认为！
可是在实现上，我却使用了链表而不是红黑树，由于链表简单。
后来想用堆实现，也作罢了。链表遍历不是啥大不了的事儿！
后来我看CFS，发现当中的下面代码来表示全部进程调度一遍的周期：
if (unlikely(nr_running > 5)) {
period = sysctl_sched_min_granularity;
period *= nr_running;
}认为CFS和我2008年的那个调度器实现犯了同一个错误。那就是假设nr_running非常之大，就会导致调度一遍的时间非常长久，依照BSD4.3 UNIX的思想，应该阻止添加全部进程调度一遍的时间才对。好吧。那我能限制period的最大值吗？能够！可是假设优先级公式本身保证了这一点。岂不是更加完美吗？对于Linux的O(n)以及O(1)调度器来讲。时间片都是优先级的函数。时间片的还有一个计算因子就是进程执行的特性，总体加起来计算一个动态优先级。对于Windows NT而言，全部线程的时间片是固定的，优先级包含线程的基本优先级数值以及动态调整的数值，不同优先级线程的每次执行时间都是一致的，所不同的是高优先级线程总是能够抢占低优先级线程从而先执行。这是和UNIXv6进程调度的本质差别，再次重申，UNIXv6的调度不是基于时间片的，进程根本就没有时间片。
时间片调度的优点在于时间片是预先分配的。降低了每次计算全部进程的动态优先级的开销，添加了系统吞吐能力，可是传统的时间片计算方式有一个缺点。那就是easy造成进程/线程饥饿。尽管WIndows NT採用了固定时间片来避免某优先级线程时间片过长。可是它不得不靠外部的平衡器来适时地发现饥饿线程并动态调整其到高优先级队列。UNIXv6的进程调度(其实说的是后来的BSD4.3+)全然没有这个问题：
a.依靠一个单一的公式来适应系统的负载，动态平滑调整优先级；
b.分离内核态执行优先级，提高I/O完毕后的响应速度。
它将时间片描写叙述为一个静态优先级的函数，对于固定的nice值，其时间片是固定的，即每个nice值相应一个时间片。然后依照先执行高优先级进程的策略来调度执行队列的进程，这会带来两个问题：
1.假设大量进程处在同样的高优先级，将会造成它们之间轮转执行。造成低于它们的全部优先级的进程持续饥饿；
2.I/O后的高速响应问题。
我们看一下Linux 2.6.23之前是怎么解决这些问题的。
这能够分类两种方案，对于O(n)算法而言。系统严格执行完预分配给进程的时间片而且仅仅执行1次，然后将其时间片设置为0，接下来当全部的进程时间片均为0的时候，一次性又一次设置全部进程的时间片，由于每个进程仅仅执行1次自己的时间片，那么即便它拥有再高的优先级。也总实用完的那一刻，这就避免了进程永远饥饿，对于I/O完毕的高速响应问题，O(n)并没有非常好的解决！注意，O(n)调度器是不可抢占的。即进程在时间片用完之前。不可抢占。
对于O(1)算法，相似的也是进程执行完分配给自己的时间片而且仅仅执行1次。然后重置其时间片并将其放在一个过期队列中，等全部的进程都在过期数组中了。切换过期数组而活动数组。我们能够看见，实际上O(1)调度器和O(n)调度器在本质上都是一致的，没有什么除了实现方式之外的其他差别。唯一的差别在于O(1)实现了抢占，复杂到死人的动态优先级的调整。“时间片再分片”以及饥饿避免机制：
内核抢占：刑可上大夫。仅仅要没有占用机要机构，无论是内核态还是用户态的进程，也无论时间片有没实用尽，均能够被抢占。这实际上是减小了内核保护的粒度。
动态优先级调整：依据进程的睡眠时间和实际占用CPU时间的比率来调整优先级，原则在于。睡眠越久的进程给与的补偿越高。这也是一个利他性补偿。
时间片再分片：在特殊的交互环境下，将一个超级长的计算型进程的时间片再次分片。分成非常小的slice。为其他进程提供执行机会；
饥饿避免：由于引入了上述的机制。难免由于优先级提升导致的高优先级进程们持续占有CPU，因此引入了饥饿避免机制。这实际上相似Windows NT的平衡器。可是不同的是。WIndows NT中。优先级调整和抢占是主线。而在Linux中，它们则是辅助功能。
有没有想过。O(1)的效果并没有想象的那么比O(n)好。O(1)仅仅对于交互式应用更加合理。对于吞吐优先的server而言，甚至不如O(n)，特别是内核抢占功能，在编译内核的时候，你会看到，假设你编译的是server而不是桌面版本号。建议是关闭内核抢占。由于总时间是一定的。切换时间占用多了。执行任务时间就少了。另外，对于server而言，一般都倾向于一次性完毕任务，最大化缓存的利用率，切换会导致缓存刷新。TLB刷新。
个人感觉，O(1)并没有较O(n)提高多少性能，可能沾光的仅仅是Ubuntu，Suse之类的桌面系统吧。
由于WinNT的调度器并没有规定“调度一轮”的概念，因此也就没有规定每个线程执行几个时间片，所以它的时间片是固定的。毕竟一个高优先级的线程可能会连续执行好几个时间片。仅仅要期间没有更高优先级的线程就绪。能够抢占高优先级线程的办法就是依赖系统将一个低优先级线程提升到一个高优先级队列，提升优先级的原因有好多：调度器事件提升，睡眠唤醒后提升；等锁控锁后提升。I/O完毕提升(延续自UNIXv6)。等待执行体资源后提升，交互式前台窗体线程提升，长期饥饿提升。
以上每一种优先级提升机制都有复杂的实现，且优先级的提升数值也不同。这说明。WinNT的调度器主线就是优先级调整，每个线程都有一个固定的基本优先级，它的作用在于线程优先级的回归。
对于server版本号和家庭版本号，WInNT定义的时间片是不同的。server追求高吞吐。要避免频繁切换，因此时间片就会更长，而家用版本号追求高响应性，因此时间片就会更短。这也符合UNIXv6的调度器设计思想。
WinNT调度器并没有体现利他系统应有的行为。而是全然依赖外部诸如优先级提升原因以及平衡器的操作，这就意味着它不是一个自洽的调度系统。仅仅有在WinNT这个环境下才干发挥其作用。
我在2008年设计自己(其实是为公司)的08调度器(姑且这个命名)的初衷在于O(1)调度器无法满足实时性需求，特别是在负载非常大的时候。
时间片是固定的。进程数量越多，调度完一轮的时间就越久，这是Linux的“按轮”调度思想最大弊端。WinNT调度器就没有这样的问题。由于随便一个线程的优先级在随意时刻都能够由于随意原因而得到随意的提升。最后收摊的就是平衡器。它能保证线程不会持续4秒以上的饥饿。
可是Linux的“按轮调度”全然做不到这一点，因此我实现了自己的08调度器。
怎么体现啊？先看一张图：
我们应该转换一种思维。将思路切换到虚拟时钟上。对于虚拟时钟而言，每个进程每次执行相等的时间片，系统总是选择虚拟时钟最小的进程执行。效果就是全部进程的虚拟时钟以同样的步进速度你追我赶。这就是平等的体现！每一轮的调度周期中，每个进程都能得到执行机会，执行多久呢？统一都执行N个虚拟时钟周期！
可是怎么相应到真实的时钟呢？答案是按权重来解释这N个虚拟时钟周期！每个虚拟时钟周期的真实时钟周期是：
Tr = T*(Wn/Wbase)
当中，T为时钟嘀嗒间隔，Wn为当前进程的权重，Wbase为參照权重，即nice为0的进程的权重，能够看出。进程权重越大，相应的真实时间越久。那么在随意一个周期T内，一个进程应该执行多少时间呢？非常easy。答案是T*(Wn/Wt)当中Wt为队列的全部进程的权重总和。
这十分相似我的08调度器！可是比我的精致。难道原因在于它使用了红黑树？...
在Linux 2.6.23到2.6.25之间，Linux CFS的实现比較朴素，它为每个队列维护了一个fair_clock变量跟踪虚拟时钟的步进，每个task都有一个key。其值为该task当前的虚拟时钟的值，为了保证公平，调度器总是选择虚拟时钟最小的task执行。
这些task存储在红黑树中，当然也能存在堆中。甚至链表中。到了2.6.25内核，CFS实现更直接了，抛弃了队列虚拟时钟的跟踪，而是直接应用T*(Wn/Wt)时间来决定进程n是否在本轮调度已经到期。
无论怎样，这个CFS调度器还是有一些问题，那就是总的一轮全部进程调度的时间没有被限制。还是会造成饥饿，可是红黑树的插入算法会导致task总是会从右到左移动。尽管会等非常久，但饥饿问题并非持续的(即使用链表也是这样，这是虚拟时钟随风奔跑决定的，不是算法决定的。)。这也是按轮调度的优势吧！
Linux CFS调度器在UNIXv6的平滑调度的基础上实现了“按轮”调度，实则一朵奇葩。
它并不动态改变进程的权重。而是依据其权重计算其虚拟时钟降低多少，CFS总是选择虚拟时钟最小的进程投入执行，如此一来。睡眠唤醒的进程就会领先得到执行机会，得到多少额外的机会就看它的权重了。
我已经无力关注CFS的细节，细节都是实现问题。假设你理解了原理，细节难道不能够自己实现吗？
最后我想说一下内核抢占。起初的UNIX系统为了保护内核数据而不同意内核抢占，鉴于这仅仅是一种相似锁一样的保护策略。它并非长久的，终于的内核抢占被差点儿全部的现代操作系统实现了。无论是WinNT还是Linux还是现代的UNIX变种。起初，UNIX在实现内核抢占的时候，仅仅是定义了一些内核可抢占的点，即那些没有占有不论什么可能导致相互排斥问题的机要机构的点。可是有一种反其道而行之的思想，即，与其说在不可抢占的内核中定义一些能够抢占的点，不如说在可抢占内核中定义一些不可抢占的点，且后者实现起来更easy。
无论是WinNT还是Linux，还是Solaris。都是这么实现的。
认为UNIXv6过时的XX们，你们懂CFS吗？你们受过排队之苦吗？朴素的东西永远都只是时。仅仅是你不懂而已...
标签：人人 running 归一化 长度 复杂度 实时 小技巧 交互 缺点
原文地址：http://www.cnblogs.com/liguangsunls/p/6913199.html
