diff --git a/study/kernel/00-DESCRIPTION/SCHEDULER.md b/study/kernel/00-DESCRIPTION/SCHEDULER.md index 372d567..196018f 100755 --- a/study/kernel/00-DESCRIPTION/SCHEDULER.md +++ b/study/kernel/00-DESCRIPTION/SCHEDULER.md @@ -153,11 +153,11 @@ CFS 的测试性能比 RSDS 好, 并得到更多的开发者支持, 所以它最 可以八卦的是, Con Kolivas 因此离开了社区, 不过他本人否认是因为此事而心生龃龉. 后来, 2009 年, 他对越来越庞杂的 CFS 不满意, 认为 CFS 过分注重对大规模机器, 而大部分人都是使用少 CPU 的小机器, 因此于 2009年8月31日发布了 BFS 调度器(Brain Fuck Scheduler)[48](#refer-anchor-48). -BFS调度器的原理十分简单, 是为桌面交互式应用专门设计, 使得用户的桌面环境更为流畅, 早期使用CFS编译内核时, 音讯视讯同时出现会出现严重的停顿（delay）, 而使用 BFS 则没有这些问题。【注意】 +BFS调度器的原理十分简单, 是为桌面交互式应用专门设计, 使得用户的桌面环境更为流畅, 早期使用CFS编译内核时, 音讯视讯同时出现会出现严重的停顿（delay）, 而使用 BFS 则没有这些问题. 【注意】 -BFS 的原理是将所有行程被安排到103组伫列(queue)之中。BFS本身是O(n)调度器, 但大部份的时间比目前Linux上拥有O(log n)效能的主流调度器CFS还优异。[2]Con Kolivas 并没有打算将BFS应用在 mainline Linux[3]。他再度以 -ck 的补丁来维护这套原始码。 +BFS 的原理是将所有行程被安排到103组伫列(queue)之中. BFS本身是O(n)调度器, 但大部份的时间比目前Linux上拥有O(log n)效能的主流调度器CFS还优异. [2]Con Kolivas 并没有打算将BFS应用在 mainline Linux[3]. 他再度以 -ck 的补丁来维护这套原始码. -Android 曾经在试验性的分支, 使用 BFS 作为其操作系统排程器。但是经过测试发现对使用者并没有明显的改进, 因此并未合入之后发表的正式版本. 初次之外当时很多人和厂商都做过 BFS 和 CFS 的对比测试. +Android 曾经在试验性的分支, 使用 BFS 作为其操作系统排程器. 但是经过测试发现对使用者并没有明显的改进, 因此并未合入之后发表的正式版本. 初次之外当时很多人和厂商都做过 BFS 和 CFS 的对比测试. [Linux 调度器 BFS 简介](https://www.ibm.com/developerworks/cn/linux/l-cn-bfs) @@ -231,28 +231,28 @@ RT 有两种调度策略, SCHED_FIFO 先到先服务 和 SCHED_RR 时间片轮 系统中的实时进程将比 CFS 优先得到调度, 实时进程根据实时优先级决定调度权值 -RR进程和FIFO进程都采用实时优先级做为调度的权值标准, RR是FIFO的一个延伸。FIFO时, 如果两个进程的优先级一样, 则这两个优先级一样的进程具体执行哪一个是由其在队列中的位置决定的, 这样导致一些不公正性(优先级是一样的, 为什么要让你一直运行?),如果将两个优先级一样的任务的调度策略都设为RR,则保证了这两个任务可以循环执行, 保证了公平。 +RR进程和FIFO进程都采用实时优先级做为调度的权值标准, RR是FIFO的一个延伸. FIFO时, 如果两个进程的优先级一样, 则这两个优先级一样的进程具体执行哪一个是由其在队列中的位置决定的, 这样导致一些不公正性(优先级是一样的, 为什么要让你一直运行?),如果将两个优先级一样的任务的调度策略都设为RR,则保证了这两个任务可以循环执行, 保证了公平. SHCED_RR和SCHED_FIFO的不同： -1. 当采用SHCED_RR策略的进程的时间片用完, 系统将重新分配时间片, 并置于就绪队列尾。放在队列尾保证了所有具有相同优先级的RR任务的调度公平。 +1. 当采用SHCED_RR策略的进程的时间片用完, 系统将重新分配时间片, 并置于就绪队列尾. 放在队列尾保证了所有具有相同优先级的RR任务的调度公平. -2. SCHED_FIFO一旦占用cpu则一直运行。一直运行直到有更高优先级任务到达或自己放弃。 +2. SCHED_FIFO一旦占用cpu则一直运行. 一直运行直到有更高优先级任务到达或自己放弃. -3. 如果有相同优先级的实时进程（根据优先级计算的调度权值是一样的）已经准备好, FIFO时必须等待该进程主动放弃后才可以运行这个优先级相同的任务。而RR可以让每个任务都执行一段时间。 +3. 如果有相同优先级的实时进程（根据优先级计算的调度权值是一样的）已经准备好, FIFO时必须等待该进程主动放弃后才可以运行这个优先级相同的任务. 而RR可以让每个任务都执行一段时间. 相同点： -1. RR和FIFO都只用于实时任务。 +1. RR和FIFO都只用于实时任务. -2. 创建时优先级大于0(1-99)。 +2. 创建时优先级大于0(1-99). -3. 按照可抢占优先级调度算法进行。 +3. 按照可抢占优先级调度算法进行. -4. 就绪态的实时任务立即抢占非实时任务。 +4. 就绪态的实时任务立即抢占非实时任务. 由于 RT 比 NORMAL 进程拥有较高的优先级, 因此当系统中存在长时间运行的 RT 进程时, 系统通常通过默认的 RT_BANGWIDTH 机制来限制 RT 的带宽, 默认是 95%, 因此每 1S 种, CPU 将让出 0.05s 的时间给优先级较低的 NORMAL 进程运行. @@ -519,7 +519,7 @@ NUMA 机器一个重要特性就是不同 node 之间的内存访问速度有差 ------- 2019 年的 [Vincent Guittot](https://www.youtube.com/watch?v=cfv63BMnIug) 的 [sched/fair: rework the CFS load balance](https://lwn.net/Articles/793427) 是近几年特别有亮点的补丁. -. 博主个人一直是计算机先驱"高德纳"教授"文学化编程"思想的坚定追随者, 小米创始人雷军雷布斯先生也说"写代码要有写诗一样的感觉". 这种代码才真的让人眼前一亮, 如沐春风. 这个就是我看到 [rework_load_balance 这组补丁](https://lore.kernel.org/patchwork/cover/1141687) 的感觉. 这组补丁通过重构 (CFS) load_balance 的逻辑, 将原来逻辑混乱的 load_balance 变成了内核中一抹亮丽的风景, 不光使得整个 load_balance 的框架更清晰, 可读性更好. 更带来了性能的提升. +. 博主个人一直是计算机先驱"高德纳"教授"文学化编程"思想的坚定追随者, 小米创始人雷军雷布斯先生也说"写代码要有写诗一样的感觉". 这种代码才真的让人眼前一亮, 如沐春风. 这个就是我看到 [rework_load_balance 这组补丁](https://lore.kernel.org/patchwork/cover/1141687) 的感觉. 这组补丁通过重构 (CFS) load_balance 的逻辑, 将原来逻辑混乱的 load_balance 变成了内核中一抹亮丽的风景, 不光使得整个 load_balance 的框架更清晰, 可读性更好. 更带来了性能的提升. 它将系统中调度组的状态[归结于集中类型](https://lore.kernel.org/patchwork/patch/1141698), 对于其中的负载不均衡状态分别采用不同的处理方式. @@ -546,7 +546,7 @@ NUMA 机器一个重要特性就是不同 node 之间的内存访问速度有差 |:----:|:----:|:---:|:------:|:---:| | 2020/03/11 | [sched: Streamline select_task_rq() & select_task_rq_fair()](https://lore.kernel.org/patchwork/patch/1208449) | 选核流程上的重构和优化, 当然除此之外还做了其他操作, 比如清理了 sd->flags 信息, 甚至 sysfs 接口都变成只读了 | | | | 2020/03/11 | [sched: Instrument sched domain flags](https://lore.kernel.org/patchwork/cover/1208463) | 基于上一组补丁, 重构了 SD_FLAGS 的定义 | | | - + # 1.6 pick_next_task @@ -688,6 +688,66 @@ CPU的周期性调度, 和基于时间片的调度, 是要基于时钟中断来 2.6.25 引入了所谓的**高清嘀哒(High Resolution Tick)**, 以提供更精确的调度时钟中断．这个功能是基于**高精度时钟(High Resolution Timer)框架**, 这个框架让内核支持可以提供纳秒级别的精度的硬件时钟(将会在时钟子系统里讲). +## 1.8.5 混乱的 RT 优先级(RT 进程优先级管控) +------- + +Linux 内核会将大量(并且在不断增加中)工作放置在内核线程中, 这些线程是在内核地址空间中运行的特殊进程. 大多数内核线程运行在 SCHED_NORMAL 类中, 必须与普通用户空间进程争夺CPU时间. 但是有一些内核线程它的开发者们认为它们非常特殊, 应该比用户空间进程要有更高优先级. 因此也会把这些内核线程放到 SCHED_FIFO 中去. + +那么问题来了, 某个内核线程的实时优先级到底该设为多少呢? + +要回答这个问题, 不仅需要判断这个线程相对于所有其他实时线程是否更加重要, 还要跟用户态的实时进程比较谁更重要. 这是一个很难回答的问题, 更何况在不同的系统和工作模式下这个答案很有可能还会各不相同. + +所以无非两种可能性 +* 一般来说, 内核开发人员也就是看心情直接随便选一个实时优先级; +* 另外一种情况, 内核开发人员觉得自己的线程是那么的重要, 因此给他一个比较高的实时优先级; + +最近大神 Peter Zijlstra 又看到有内核开发者随便给内核线程设置优先级, 终于看不下去了, 指责这种把内核线程放入SCHED_FIFO的做法毫无意义: + +"the kernel has no clue what actual priority it should use for various things, so it is useless (or worse, counter productive) to even try" + +所以他发了一个系列 [[PATCH 00/23] sched: Remove FIFO priorities from modules](https://lore.kernel.org/patchwork/cover/1229354) 把设置内核线程优先级的接口干脆都给删了, 省得再有人瞎搞. 这个 PatchSet 主要做了下面几件事情: + +1. 不再导出原有的sched_setschedule() / sched_setattr() 接口 + +2. 增加了 sched_set_fifo(p) / sched_set_fifo_low(p) / sched_set_normal(p, nice) + +其中调用 sched_set_fifo() 会将指定进程放到 SCHED_FIFO 类中, 其优先级为 50 这只是 min 和 max 之间的一半位置. +对于需求不那么迫切的线程, sched_set_fifo_low()将优先级设置为最低值(1). +而调用 sched_set_normal() 会将线程返回给定好的值 SCHED_NORMAL 类. + +通过只留下这三个接口可以避免开发者们再不停地去随机选取内核线程优先级, 因为这样本来毫无意义, 当然如果需要的话系统管理员还是可以按需调整不同进/线程的优先级. + +这个特性最终在 5.9-rc1 的时候合入主线. + + + +# 1.9 调试信息 +------- + +## 1.9.1 统计信息 +------- + +阿里的王贇 [sched/numa: introduce numa locality](https://lore.kernel.org/patchwork/cover/1190383) 提供了 per-cgroup 的 NUMASTAT 功能, 发到了 2020/02/07 v8, 但是最终还是没能合入主线. + + +## 1.9.2 tracepoint +------- + +[`tracepoints-helpers`](https://github.com/auldp/tracepoints-helpers.git) +[`plot-nr-running`](https://github.com/jirvoz/plot-nr-running) + + +| 时间 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:------:|:---:| +| 2019/06/04 | [sched: Add new tracepoints required for EAS testing](https://lore.kernel.org/patchwork/patch/1296761) | 增加 PELT 的跟踪点 | v3, 5.3-rc1 | [PatchWork](https://lore.kernel.org/patchwork/patch/1296761) | +| 2020/06/19 | [Sched: Add a tracepoint to track rq->nr_running](https://lore.kernel.org/patchwork/patch/1258690) | 增加 nr_running 的跟踪点 | v1, 5.9-rc1 | [PatchWork](https://lore.kernel.org/patchwork/patch/1258690)
*-*-*-*-*-*-*-*
[FixPatch](https://lore.kernel.org/patchwork/patch/1284621) | +| 2020/08/28 | [sched/debug: Add new tracepoint to track cpu_capacity](https://lore.kernel.org/patchwork/patch/1296761) | 增加 cpu_capacity 的跟踪点 | + + + + + + **引用: **