Android开发教程之Linux调度器BFS简介.pptxVIP

Android开发教程之Linux 调度器 BFS 简介(2) 多队列 vs 单一队列 向前看还是向后看 BFS 实现原理 虚拟 Deadline ( Virtual Deadline ) 进程队列的表示方法和调度策略 Task Selection i.e. Pick Next 基本的调度场景 进程 wakeup：Task Insertion 进程 Sleep 进程用完自己的时间片 结束语 在 Linux 内核进入 2.6 时，调度器采用 per cpu run queue 从而克服了单一 run queue 的局限。在多 CPU 系统中，单一 run queue 意味着 run queue 成为了系统的瓶颈，因为在同一时刻，一个 CPU 访问 run queue 时，其他的 CPU 即使空闲也必须等待。当使用 per CPU 的 run queue 之后，每个 CPU 不必再使用大锁，从而能够并行地处理调度。 但很多事情都不像第一眼看上去那样简单。 Android开发教程之多队列 vs 单一队列 Kolivas 发现，采用 per cpu run queue 所带来的好处会被追求公平性的 load balance 代码所抵消。在目前的 CFS 调度器中，每颗 CPU 只维护本地 run queue 中所有进程的公平性，为了实现跨 CPU 的调度公平性，CFS 必须定时进行 load balance，将一些进程从繁忙的 CPU 的 run queue 中移到其他空闲的 run queue 中。 这个 load balance 的过程需要获得其他 run queue 的锁，这种操作降低了多运行队列带来的并行性。 并且在复杂情况下，这种因 load balance 而引入的 footprint 将非常可观。 Android开发教程 当然，load balance 引入的加锁操作依然比全局锁的代价要低，这种代价差异随着 CPU 个数的增加而更加显著。但请您注意，BFS 并不打算为那些拥有 1024 个 CPU 的系统工作，假若系统中的 CPU 个数有限时，多 run queue 的优势便不明显了。 而 BFS 采用单一队列之后，每一个需要调度的新进程都可以在全局范围内查找最合适的 CPU，而无需 CFS 那样等待 load balance 代码来决定，这减少了多 CPU 之间裁决的延迟，最终的结果是更小的调度延迟。 Android开发教程 量，而是交互性程序的流畅体验。从 SD 开始，Kolivas 就告诉内核黑客们，完全公平能够从根本上保证交互性。他始终坚持一个基本观点：调度器应该 forward look only。决不要去考虑一个进程的过去。 CFS 却偏偏要考虑进程的过去。2.6.23 的时候，CFS 记录并使用 sleep time。之后不久，在 2.6.24 发布的时候，CFS 合并了“Real Fair Scheduler”，删除了 sleep time。因此在 2.6.24 之后的内核中，CFS 终于也不再考虑进程过去的睡眠时间。 Android开发教程之向前看还是向后看 但 CFS 还是保留了 sleeper fairness 的思想，当进程 wakeup 的时候，在 place_entity() 函数中，CFS 将对 sleeper 进行奖励，以便其能尽快得到 CPU。这个策略是非常微妙的，我们在 2.1 节中详细介绍了 sleeper fairness 的演进过程。假如您花些时间回头再看看，就会发现 sleeper fairness 曾造成怎样严重的延迟问题。虽然 Ingo 自称 Gentle fairness 解决了延迟问题，但从代码上看，Gentle Fairness 只是对 sleeper 的奖励减半而已。因此我们可以说，CFS 依然对 Sleeper 进程进行奖励，这代表着一种偏好，一种“不公平”。而这，正是 BFS 所反对的。 Android开发教程 BFS 中，当一个进程 wakeup 时，调度器将根据进程的 deadline 来进行选择（关于 deadline 本文将在第 4 章中详细描述），其结果是，更早睡眠的进程能更快地得到调度；CFS 的 sleeper fairness 则意味着要根据 wakeup 的时间来选择下一个被调度的进程，更早 wakeup 的进程会更快得到调度。 这种不同究竟会对桌面应用造成何种影响尚没有理论依据可以参考。但我个人认为，BFS 的策略更加合理。 您现在可能已经读得有些烦躁了 ( 这些英文加中文的说些啥啊 )，所以我还是尽快介绍一下 BFS 的实现细节吧。然后或许您会理解我，有些词还是不翻译更好。 Android开发教程 调度器是非常复杂的话题，尤其是 CFS 调