Mirrors_BOOKS/LDD-LinuxDeviceDrivers
1
0
Fork 0
mirror of https://github.com/gatieme/LDD-LinuxDeviceDrivers.git synced 2026-09-23 21:39:06 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

description/scheduler: EAS

Browse Source
This commit is contained in:
Cheng Jian
2022-07-06 19:36:55 +08:00
parent 475e45108d
commit 9f22888056
4 changed files with 89 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
study/kernel/00-DESCRIPTION/ARCH.md
+16 -1
View File
@@ -824,9 +824,24 @@ openEuler 提供了 [openEuler/prefetch_tuning](https://gitee.com/openeuler/pref
## 6.10 Software Branch Hinting
-------
[Software Branch Hinting](https://labs.engineering.asu.edu/mps-lab/research-themes/low-power-computing/sbh/)
[Software Branch Hinting](https://labs.engineering.asu.edu/mps-lab/research-themes/low-power-computing/sbh)
## 6.9 指令集
-------
| 指令集架构 | 描述 | 代表架构 |
|:--------:|:----:|:------:|
| CISC (Complex instruction set computer) 复杂指令集计算机 | NA | HP 的 PA-RISC，IBM 的 PowerPC，Compaq（被并入 HP）的 Alpha，MIPS 公司的 MIPS，SUN 公司的 SPARC 等. |
| RISC (Reduced instruction set computer) 精简指令集计算机 | NA | NA |
| [MISC (Minimal instruction set computer), 最小指令集计算机](http://en.wikipedia.org/wiki/Minimal_instruction_set_computer) | [从零开始手敲自举编译器(一): MISC 概览](https://zhuanlan.zhihu.com/p/412201989) 和 [github-whoiscc/miniboot/](https://github.com/whoiscc/miniboot) |
| [OISC (One instruction set computer, 单指令集计算机)](http://en.wikipedia.org/wiki/One_instruction_set_computer) | NA | NA |
| [ZISC (Zero instruction set computer)](https://en.wikipedia.org/wiki/Zero_instruction_set_computer) | NA | NA |
| VLIM (Very long instruction word) 超长指令字架构 | 通过将多条指令放入一个指令字, 有效的提高了 CPU 各个计算功能部件的利用效率, 提高了程序的性能. | NA |
| EPIC (Explicity parallel instruction computing) 显示并行指令集计算 | NA | Intel 的 IA-64 |
| EDGE | 显式数据图执行 (Explicit Data Graph Execution) 的指令集体系结构, 也被称为 EDGE 架构. | [微软处理器架构是新瓶装酒 历史早已证明是死路一条](http://www.360doc.com/content/18/0623/10/22587800_764605025.shtml), [与高通联手打造全新处理器架构，微软计算芯片界的至尊魔戒终浮现](https://zhuanlan.zhihu.com/p/38340253) | Microsoft 的 E2 |
<br>
* 本作品/博文 ( [AderStep-紫夜阑珊-青伶巷草 Copyright ©2013-2017](http://blog.csdn.net/gatieme) ), 由 [成坚(gatieme)](http://blog.csdn.net/gatieme) 创作.
study/kernel/00-DESCRIPTION/DEBUGGING.md
+1 -1
View File
@@ -538,7 +538,7 @@ Mold 是目前 Unix 链接器的现代替代品, 已经达到了 1.0 版本. 由
随后 2022 年, 开发者 Miko 建议所有架构都开启 `-O3` 编译内核 [Experimental -O3 Optimizing The Linux Kernel For Better Performance Brought Up Again](https://www.phoronix.com/scan.php?page=news_item&px=O3-Optimize-Kernel-2022-Patches), 但是遭到了 Linus 的强烈反对, [Linus Torvalds' Latest Commentary Against -O3'ing The Linux Kernel](https://www.phoronix.com/scan.php?page=news_item&px=Linus-Against-O3-Kernel), [LKML 回复](https://lore.kernel.org/lkml/CA+55aFz2sNBbZyg-_i8_Ldr2e8o9dfvdSfHHuRzVtP2VMAUWPg@mail.gmail.com).
随后 对内核使用 `-O3` 进行了较为详细的性能测试 [](https://www.phoronix.com/scan.php?page=article&item=linux-kernel-o3&num=7)
随后 对内核使用 `-O3` 进行了较为详细的性能测试, 参照 phoronix 报道 [Benchmarking The Linux Kernel With An "-O3" Optimized Build](https://www.phoronix.com/scan.php?page=article&item=linux-kernel-o3&num=7).
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md
+11 -3
View File
@@ -1669,9 +1669,15 @@ SLUB 在解决了上述的问题之上, 提供与 SLAB 完全一样的接口,
### 2.3.5 kmalloc
-------
kmalloc 的 API 家族对 mm 非常关键, 但有一个缺点, 就是它的对象大小被固定为 2 次方. 当用户请求内存为 '2^n +1' 字节时, 实际上会分配 2^(n+1) 字节, 所以在最坏的情况下, 大约有 50% 的内存空间浪费. 因此内核可能会以为浪费了太多的内存, 从而导致 OOM. 参见 [Crash kernel with 256 MB reserved memory runs into OOM condition](https://lkml.org/lkml/2019/8/12/266) 和 [Re: [PATCH] iommu/iova: change IOVA_MAG_SIZE to 127 to save memory](https://lore.kernel.org/lkml/2920df89-9975-5785-f79b-257d3052dfaf@huawei.com).
为了能辅助分析 kmalloc 本身造成的浪费(内碎片), [mm/slub: enable debugging memory wasting of kmalloc](https://lore.kernel.org/all/20220701135954.45045-1-feng.tang@intel.com) 增加了 waste 信息记录 kmalloc/slub 造成的内存浪费.
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2022/04/14 | Hyeonggon Yoo <42.hyeyoo@gmail.com> | [common kmalloc subsystem on SLAB/SLUB](https://patchwork.kernel.org/project/linux-mm/cover/20220308114142.1744229-1-42.hyeyoo@gmail.com) | 清理 slab 公共代码. 在这组补丁之后后, kmalloc 子系统在 SLAB 和 SLUB 之间得到了完美的推广. | v1 ☐☑ | [2022/03/08 LORE v1,00/15](https://lore.kernel.org/r/20220308114142.1744229-1-42.hyeyoo@gmail.com)<br>*-*-*-*-*-*-*-* <br>[2022/04/14 LORE v2,0/23](https://lore.kernel.org/r/20220414085727.643099-1-42.hyeyoo@gmail.com) |
| 2022/07/01 | Feng Tang <feng.tang@intel.com> | [mm/slub: enable debugging memory wasting of kmalloc](https://lore.kernel.org/all/20220701135954.45045-1-feng.tang@intel.com) | 这个补丁帮助显示了当前 kmalloc 下的浪费的空间, 信息在 `/sys/kernel/debug/slab/kmalloc-xx/alloc_traces` 中显示, 显示的格式为: waste=总共浪费的字节数目/单词请求浪费的字节数目. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20220701135954.45045-1-feng.tang@intel.com) |
### 2.3.6 改进与优化
@@ -3259,7 +3265,7 @@ v10 基本趋于稳定, 已经尝试发送合并请求 [LWN: Merging the multi-g
v11 版本时, Google 已经向数千万 Chrome OS 用户和大约 100 万 Android 用户推出了 MGLRU. Google 的 Fleetwide 分析显示, 除了其他 UX 指标的改进之外, kswapd CPU 使用率总体降低了 40%, 其中第 75 百分位的 low-memory kills 次数减少了 85%, 第 50 百分位的应用启动时间减少了 18%. [MGLRU 再次为有希望的 Linux 性能改进而加速](https://www.phoronix.com/scan.php?page=news_item&px=MGLRU-v11-Linux-Perf).
v12 版本已经没有什么特性变更, 仅仅是一些 bugfix, 参见 phoronix 报道 [Performance-Boosting MGLRU Patches Updated Against Current Linux 5.19 State](https://www.phoronix.com/scan.php?page=news_item&px=MGLRU-v12-For-Linux-5.19-rc).
v12 版本已经没有什么特性变更, 仅仅是一些 bugfix, 参见 phoronix 报道 [Performance-Boosting MGLRU Patches Updated Against Current Linux 5.19 State](https://www.phoronix.com/scan.php?page=news_item&px=MGLRU-v12-For-Linux-5.19-rc). 随后 phoronix 也对 MGLRU v12 做了一些基础的 benchmark 测试, 在进行的数十个基准测试中, 大多数测试显示性能没有变化. 但是, 当涉及到数据库等 I/O 工作负载时, MGLRU显示出实质性的帮助.
* 实现
@@ -4799,10 +4805,11 @@ David Rientjes 率先提出了这种想法 [Hugepage collapse in process context
#### 7.2.5.1 splitting
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2021/07/31 | Yu Zhao <yuzhao@google.com> | [mm: optimize thp for reclaim and migration](https://lore.kernel.org/patchwork/patch/1470432) | 对 THP 的回收和迁移进行优化.<br>使用配置 THP 为 always 的时候, 大量 THP 的内部碎片会造成不小的内存压力. 用户空间可以保留许多子页面不变, 但页面回收不能简单的根据 dirty bit 来识别他们.<brr>但是, 仍然可以通过检查子页面的内容来确定它是否等同于干净. 当拆分 THP 用于回收或迁移时, 我们可以删除只包含0的子页面, 从而避免将它们写回或复制它们. | v1 ☐ | [PatchWork 0/3](https://patchwork.kernel.org/project/linux-mm/cover/20210731063938.1391602-1-yuzhao@google.com) |
| 2021/05/29 | Ning Zhang <ningzhang@linux.alibaba.com> | [mm, THP: introduce a controller to trigger THP reclaim](https://github.com/gatieme/linux/commit/57456d1625ba9036968fa0be70a6036b88f2b2f4) | 实现 MEMCG 的 THP 回收. | v1 ☐ | [PatchWork 0/3](https://patchwork.kernel.org/project/linux-mm/cover/20210731063938.1391602-1-yuzhao@google.com) |
| 2021/05/29 | Ning Zhang <ningzhang@linux.alibaba.com> | [mm, THP: introduce a controller to trigger THP reclaim](https://github.com/gatieme/linux/commit/57456d1625ba9036968fa0be70a6036b88f2b2f4) | 实现 MEMCG 的 THP 回收. [THP reclaim功能](https://www.alibabacloud.com/help/zh/elastic-compute-service/latest/thp-reclaim). | v1 ☐ | [PatchWork 0/3](https://patchwork.kernel.org/project/linux-mm/cover/20210731063938.1391602-1-yuzhao@google.com) |
| 2018/01/03 | Michal Hocko <mhocko@kernel.org> | [unclutter thp migration](https://lore.kernel.org/patchwork/patch/869414) | THP 迁移以令人惊讶的语义侵入了通用迁移. 迁移分配回调应该检查 THP 是否可以立即迁移, 如果不是这样, 则分配一个简单的页面进行迁移. 取消映射和移动, 然后通过将 THP 拆分为小页面, 同时将标题页面移动到新分配的 order-0 页面来修复此问题. 剩余页面通过拆分页面移动到 LRU 列表. 如果 THP 分配失败, 也会发生同样的情况. 这真的很难看而且容易出错. | v1 ☐ | [PatchWork 0/3](https://lore.kernel.org/patchwork/patch/869414) |
| 2019/08/22 | Yang Shi <yang.shi@linux.alibaba.com> | [Make deferred split shrinker memcg aware](https://lore.kernel.org/patchwork/patch/869414) | 目前, THP 延迟分割收缩器不了解 memcg, 这可能会导致某些配置过早地处罚 OOM.<br>通过引入每个 memcg 延迟拆分队列, 转换延迟拆分收缩器 memcg aware. THP 应位于每个节点或每个 memcg 延迟拆分队列上(如果它属于 memcg). 当页面迁移到另一个 memcg 时, 它也将迁移到目标 memcg 的延迟分割队列.<br>对于每个 memcg 列表, 重复使用第二个尾页的延迟列表, 因为同一个 THP 不能位于多个延迟拆分队列上.<br>使延迟分割收缩器不依赖于 memcg kmem, 因为它不是 slab. 过上述更改, 即使禁用了 memcg kmem(配置 cgroup.memory=nokmem), 测试也不会触发OOM. | v6 ☑ 5.4-rc1 | [PatchWork v6,0/4](https://patchwork.kernel.org/project/linux-mm/cover/1566496227-84952-1-git-send-email-yang.shi@linux.alibaba.com) |
| 2018/01/03 | Michal Hocko <mhocko@kernel.org> | [unclutter thp migration](https://lore.kernel.org/patchwork/patch/869414) | THP 迁移以令人惊讶的语义侵入了通用迁移. 迁移分配回调应该检查 THP 是否可以立即迁移, 如果不是这样, 则分配一个简单的页面进行迁移. 取消映射和移动, 然后通过将 THP 拆分为小页面, 同时将标题页面移动到新分配的 order-0 页面来修复此问题. 剩余页面通过拆分页面移动到 LRU 列表. 如果 THP 分配失败, 也会发生同样的情况. 这真的很难看而且容易出错. | v1 ☐ | [PatchWork 0/3](https://lore.kernel.org/patchwork/patch/869414) |
@@ -6323,10 +6330,11 @@ KMSAN 最早的 github 仓库位于 : https://github.com/google/kmsan
v3 的报道 [KMSAN Patches For The Linux Kernel Updated For Catching Uninitialized Memory Problems](https://www.phoronix.com/scan.php?page=news_item&px=KernelMemorySanitizer-2022).
v4 的报道 [KernelMemorySanitizer v4 Published While Already Having Found 300+ Kernel Bugs](https://www.phoronix.com/scan.php?page=news_item&px=KernelMemorySanitizer-v4).
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2021/12/14 | Alexander Potapenko <glider@google.com> | [Add KernelMemorySanitizer infrastructure](https://patchwork.kernel.org/project/linux-mm/cover/20211214162050.660953-1-glider@google.com) | 该补丁集包含 KMSAN 运行时实现, 以及使 KMSAN 工作所需的对其他子系统的修改.<br>1. 添加KMSAN所需的现有代码的更改和重构.<br>2. 通用代码中的 KMSAN 相关声明、KMSAN 运行时库.<br>3. 添加来自不同子系统的钩子, 以通知 KMSAN 有关内存的信息.<br>4. 通过显式初始化内存、禁用可能欺骗KMSAN的优化代码、有选择地跳过检测来防止错误报告的更改.<br>5. Noinstr 的处理.<br>这个补丁集允许在 QEMU 上启动并运行 defconfig + KMSAN 内核, 而不会出现已知的误报. 然而, 它不能保证在某些设备或测试较少的子系统的驱动程序中没有误报, 尽管 KMSAN 在 syzbot 上使用较大的配置进行了积极的测试. | v1 ☐ | [PatchWork 00/43](https://patchwork.kernel.org/project/linux-mm/cover/20211214162050.660953-1-glider@google.com)<br>*-*-*-*-*-*-*-* <br>[LORE v3,00/46](https://lore.kernel.org/lkml/20220426164315.625149-1-glider@google.com) |
| 2021/12/14 | Alexander Potapenko <glider@google.com> | [Add KernelMemorySanitizer infrastructure](https://patchwork.kernel.org/project/linux-mm/cover/20211214162050.660953-1-glider@google.com) | 该补丁集包含 KMSAN 运行时实现, 以及使 KMSAN 工作所需的对其他子系统的修改.<br>1. 添加KMSAN所需的现有代码的更改和重构.<br>2. 通用代码中的 KMSAN 相关声明、KMSAN 运行时库.<br>3. 添加来自不同子系统的钩子, 以通知 KMSAN 有关内存的信息.<br>4. 通过显式初始化内存、禁用可能欺骗KMSAN的优化代码、有选择地跳过检测来防止错误报告的更改.<br>5. Noinstr 的处理.<br>这个补丁集允许在 QEMU 上启动并运行 defconfig + KMSAN 内核, 而不会出现已知的误报. 然而, 它不能保证在某些设备或测试较少的子系统的驱动程序中没有误报, 尽管 KMSAN 在 syzbot 上使用较大的配置进行了积极的测试. | v1 ☐ | [PatchWork 00/43](https://patchwork.kernel.org/project/linux-mm/cover/20211214162050.660953-1-glider@google.com)<br>*-*-*-*-*-*-*-* <br>[LORE v3,00/46](https://lore.kernel.org/lkml/20220426164315.625149-1-glider@google.com)[LORE v4,00/45](https://lore.kernel.org/all/20220701142310.2188015-1-glider@google.com) |
study/kernel/00-DESCRIPTION/SCHEDULER.md
+61 -3
View File
@@ -3757,12 +3757,17 @@ Oracle 数据库具有类似的虚拟化功能, 称为 Oracle Multitenant, 其
### 7.1.2 TurboSched
-------
后来到 2019 年, IBM 的 Parth Shah 有往社区推送了 TurboSched.
后来到 2019 年, IBM 的 Parth Shah 又往社区推送了 TurboSched.
[[SchedulerTaskPacking] Small background task packing](https://lore.kernel.org/lkml/39cc4666-6355-fb9f-654d-e85e1852bc6f@linux.ibm.com)
[TurboSched: the return of small-task packing](https://lwn.net/Articles/792471).
[TurboSched Is A New Linux Scheduler Focused On Maximizing Turbo Frequency Usage](https://www.phoronix.com/scan.php?page=news_item&px=Linux-TurboSched-V4)
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:---:|:----------:|:----:|
| 2019/10/07 | Parth Shah <parth@linux.ibm.com> | [TurboSched: A scheduler for sustaining Turbo Frequencies for longer durations](https://lwn.net/Articles/801473) | 尝试在繁忙的内核上打包小负载的后台任务, 这样可以通过保持其他核空闲来节省电源, 并允许更繁忙的核超频运行. | | v1 ☑ 4.11-rc1 | [PatchWork](https://lwn.net/Articles/801473) |
| 2019/10/07 | Parth Shah <parth@linux.ibm.com> | [TurboSched: A scheduler for sustaining Turbo Frequencies for longer durations](https://lwn.net/Articles/801473) | 尝试在繁忙的内核上打包小负载的后台任务, 这样可以通过保持其他核空闲来节省电源, 并允许更繁忙的核超频运行. | | v1 ☑ 4.11-rc1 | [LORE RFC,v6,0/5](https://lore.kernel.org/lkml/20200121063307.17221-1-parth@linux.ibm.com) |
## 7.2 能耗感知
-------
@@ -3830,13 +3835,48 @@ ARM EAS 支持的主页: [Energy Aware Scheduling (EAS)](https://developer.arm.c
|:----------:|:---:|:------:|
| sched_asym_cpucapacity | Capacity Aware Scheduling 特性开关 | [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df054e8445a4011e3d693c2268129c0456108663) || sched_energy_present | EAS 的特性开关. | [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1f74de8798c93ce14801cc4e772603e51c841c33) |
#### 7.2.3.1 Select an energy-efficient CPU on task wake-up
-------
2018 年, Quentin Perret 等开发的 EAS 终于在 v5.0 版本合入主线.
[commit 732cd75b8c92 ("sched/fair: Select an energy-efficient CPU on task wake-up")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=732cd75b8c920d3727e69957b14faa7c2d7c3b75) 在调度器中添加了一个 find_energy_efficient_cpu() 的函数(简称 feec()); 它的工作是为给定的任务找到最佳位置(从能耗的角度来看). 其核心逻辑是找到每个 perf_domain 性能域 中最不繁忙的 CPU, 并估计将任务放在该 CPU 上所产生的能源成本(或节省). 最不繁忙的 CPU 最有可能保持低功耗状态, 因此它为一些额外工作提供了逻辑目标.
由于, 将任务从一个 CPU 移动到另一个 CPU 是有代价的. 该任务可能会留下部分或全部内存缓存, 这会减慢其速度. 这会影响性能, 也不利于能源使用, 因此应尽可能避免使用. 为了防止 CPU 之间频繁地进程迁移, find_energy_efficient_cpu() 只有在结果是[至少节省了任务先前 CPU 所用能量的 6% 时](https://elixir.bootlin.com/linux/v5.0/source/kernel/sched/fair.c#L6576)才会迁移任务.
#### 7.2.3.2 Speed-up energy-aware wake-ups
-------
但是, 最佳能效 CPU 的计算和搜索成本很高, 以至于给调度决策增加了不必要的延迟. 因此, Perret 在 2019 年的 v5.4 版本中对其进行了重新设计. 目的是以更低的CPU成本获得相同的结果. 参见 [commit eb92692b2544 ("sched/fair: Speed-up energy-aware wake-ups")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eb92692b2544d3f415887dbbc98499843dfe568b) 补丁 COMMIT 说"没有功能更改(No functional changes intended.)". 然而, 事实证明, 有一个微妙的变化显然逃脱了审查：6%规则现在与整个系统使用的能量进行了比较, 而不仅仅是运行任务的先前CPU. 这是一个相对较高的移动门槛, 在具有足够CPU的系统上, 任务可能无法满足.
即使在较小的系统上, 新规则在许多情况下也能有效地阻止任务移动. 在运行相对较多的小任务的情况下尤其如此, 这种情况经常出现在 Android 设备上, 其中能效是一个真正的问题. 如果它不再能够移动任务以节省能源, 则 find_energy_efficient_cpu() 完成的所有工作都将被浪费, 并且设备的运行效率低于其他方式.
### 7.2.3.3 energy margin removal
-------
[Removing the scheduler's energy-margin heuristic](https://lwn.net/Articles/899303/)
回退 v5.4 的算法优化可以很直接的解决问题, 但是社区对此争议颇多, 因为本身 6% 这个收益阈值就没有任何理论以及数据依据, 在 EAS 的早期版本这个数字一直是 1.5%, 直到它在 v4 中被提高到6%, 参见 [[RFC PATCH v4 00/12] Energy Aware Scheduling](https://lore.kernel.org/all/20180628114043.24724-1-quentin.perret%40arm.com) 中 "Changed energy threshold for migration to from 1.5% to 6%". 这个改动最直接的原因可能是因为 6% 可以通过右移操作近似获得. 因此, Donnefort 直接建议完全删除 6% 的阈值, 并在看起来迁移可以降低能耗时直接迁移任务.
参见 [feec() energy margin removal](https://lore.kernel.org/all/20220621090414.433602-1-vdonnefort@google.com), 根据补丁集发布时的测试数据表明, 系统确实获得了更好能效, 视频基准测试可降低5.6%, 在某些测试中, CPU 性能略有降低, 但变化似乎并不显著.
Donnefort 称: 边距删除使内核能够充分利用能量模型, 任务更有可能放置在适合的位置, 这节省了大量的能量, 同时对性能的影响有限,
这种变化的一个可能的缺点可能是 CPU 之间任务的反弹增加, 但 Donnefort 表示, 测试"没有显示任何问题".
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:---:|:----------:|:----:|
| 2014/05/23 | Morten Rasmussen <morten.rasmussen@arm.com> | [sched: Energy cost model for energy-aware scheduling](https://lore.kernel.org/all/1400869003-27769-1-git-send-email-morten.rasmussen@arm.com) | TODO | v1 ☐☑✓ | [LORE RFC v1,0/16](https://lore.kernel.org/all/1400869003-27769-1-git-send-email-morten.rasmussen@arm.com) |
| 2018/12/03 | Quentin Perret <quentin.perret@arm.com> | [Energy Aware Scheduling](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=732cd75b8c920d3727e69957b14faa7c2d7c3b75) | 能效感知的调度器 EAS | v10 ☑ 5.0-rc1 | [LORE v10,00/15](https://lore.kernel.org/lkml/20181203095628.11858-1-quentin.perret@arm.com) |
| 2021/12/20 | Vincent Donnefort <vincent.donnefort@arm.com> | [Fix stuck overutilized](https://lkml.kernel.org/lkml/20211220114323.22811-1-vincent.donnefort@arm.com) | NA | v1 ☐ | [LORE 0/3](https://lkml.kernel.org/lkml/20211220114323.22811-1-vincent.donnefort@arm.com) |
| 2019/09/12 | Quentin Perret <qperret@qperret.net> | [sched/fair: Speed-up energy-aware wake-ups](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eb92692b2544d3f415887dbbc98499843dfe568b) | Speed-up energy-aware wake-ups from O(CPUS^2) to O(CPUS). | v1 ☑✓ 5.4-rc1 | [LORE](https://lore.kernel.org/all/20190912094404.13802-1-qperret@qperret.net) |
| 2021/05/04 | Pierre Gondois <Pierre.Gondois@arm.com> | [sched/fair: find_energy_efficient_cpu() enhancements](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=619e090c8e409e09bd3e8edcd5a73d83f689890c) | 防止 find_energy_efficient_cpu() 出现下溢. | v3 ☑✓ 5.14-rc1 | [LORE v3,0/2](https://lore.kernel.org/all/20210504090743.9688-1-Pierre.Gondois@arm.com) |
| 2021/12/20 | Vincent Donnefort <vincent.donnefort@arm.com> | [Fix stuck overutilized](https://lkml.kernel.org/lkml/20211220114323.22811-1-vincent.donnefort@arm.com) | NA | v1 ☐ | [LORE 0/3](https://lkml.kernel.org/lkml/20211220114323.22811-1-vincent.donnefort@arm.com) |
| 2022/06/21 | Vincent Donnefort <vdonnefort@google.com> | [feec() energy margin removal](https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?id=b812fc9768e0048582c8e18d7b66559c1758dde1) | feec() 将迁移任务以节省能源, 前提是它至少节省了系统消耗的总能源的 6%. 这种保守的方法对于终端来说是一个问题, 在这个系统中, 许多小任务会在总体上产生巨大的负载: 很少有任务可以迁移到较小的 CPU, 这会浪费大量的能量. 与其试图确定另一个裕度, 不如尝试删除它. | v11 ☐☑✓ | [LORE v11,0/7](https://lore.kernel.org/all/20220621090414.433602-1-vdonnefort@google.com) |
#### 7.2.3.x EAS timeline
-------
EAS 主线合入的特性时间线: [EAS Development for Mainline Linux](https://developer.arm.com/tools-and-software/open-source-software/linux-kernel/energy-aware-scheduling/eas-mainline-development)
@@ -4692,6 +4732,11 @@ PREEMPT-RT PATCH 的核心思想是最小化内核中不可抢占部分的代码
两年后, 2022 年, Vincent Guittot 在 Parth Shah 工作的基础上, 重提了 [Add latency_nice priority](https://lore.kernel.org/all/20220311161406.23497-1-vincent.guittot@linaro.org). 参见 LWN 报道.
[Scheduler wakeup path tuning surface: Use-Cases and Requirements](https://lore.kernel.org/lkml/87imfi2qbk.derkling@matbug.net)
[[SchedulerWakeupLatency] Per-task vruntime wakeup bonus](https://lore.kernel.org/lkml/87blla2pdt.derkling@matbug.net)
| 日期 | LWN | 翻译 |
|:---:|:----:|:---:|
| 2020/05/18 | [The many faces of Latency nice](https://lwn.net/Articles/820659) | [LWN: Latency nice 的方方面面](https://blog.csdn.net/Linux_Everything/article/details/106435501) |
@@ -4817,6 +4862,19 @@ Xen 的 CPU 调度算法主要有 3 种: BVT(borrowed virtual time)调度算法
2. server 线程唤醒后直接借助 client 的内核栈执行, server 和 client 都使用了 client 的内核栈, 不需要再进行数据传递, 直接调用 server 的 Continuation 返回到用户态执行.
### 10.3.2 Binder
-------
[Google 手册--使用 Binder IPC](https://source.android.com/devices/architecture/hidl/binder-ipc)
ANDROID 8 实现了 BINDER 对实时优先级传递的支持. 但是经过测试发现, 对部分场景性能存在负面影响, 因此社区并未合入.
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2017/10/26 | Martijn Coenen <maco@android.com> | [ANDROID: binder: RT priority inheritance](https://lore.kernel.org/all/20171026140750.119265-1-maco@android.com) | binder 支持 RT 优先级传递. | v3 ☐☑✓ | [LORE 00/13](https://lore.kernel.org/all/20170825093335.100892-1-maco@android.com)<br>*-*-*-*-*-*-*-* <br>[LORE v2,00/13](https://lore.kernel.org/all/20170831080430.118765-1-maco@android.com)<br>*-*-*-*-*-*-*-* <br>[LORE v3,0/6](https://lore.kernel.org/all/20171026140750.119265-1-maco@android.com) |
# 11 其他
-------