Mirrors_BOOKS/LDD-LinuxDeviceDrivers
1
0
Fork 0
mirror of https://github.com/gatieme/LDD-LinuxDeviceDrivers.git synced 2026-09-24 05:53:54 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

description/open_source: update phoronix to date 20220930

Browse Source
This commit is contained in:
Cheng Jian
2022-09-30 19:48:11 +08:00
parent 78bc1875e5
commit 7f14155f75
3 changed files with 96 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files
study/kernel/00-DESCRIPTION/DEBUGGING.md
+2
View File
@@ -358,6 +358,8 @@ $reclaim = current\_mem \times reclaim\_ratio \times max(0,1 – \frac{psi_some}
| 2020/09/11 | Kan Liang <kan.liang@linux.intel.com> | [TopDown metrics support for Ice Lake (perf tool)](https://lore.kernel.org/lkml/20200911144808.27603-1-kan.liang@linux.intel.com) | 为 perf metrics 分析增加对 Ice Lake 的支持. 将原本 group 重命名为 topdown. | v3 ☑ 5.10-rc1 | [PatchWork v3,0/4](https://lore.kernel.org/lkml/20200911144808.27603-1-kan.liang@linux.intel.com) |
| 2021/04/07 | John Garry <john.garry@huawei.com> | [perf arm64 metricgroup support](https://patchwork.kernel.org/project/linux-arm-kernel/cover/1617791570-165223-1-git-send-email-john.garry@huawei.com) | perf 支持 HiSilicon hip08 平台的 topdown metric. 支持到 Level 3. 自此鲲鹏 920 的 ARM64 服务器上, 可以使用:<br>`sudo perf stat -M TopDownL1 sleeep 1`<br>来进行 TopDown 分析了. | v1 ☑ 5.13-rc1 | [PatchWork 0/5](https://patchwork.kernel.org/project/linux-arm-kernel/cover/1614784938-27080-1-git-send-email-john.garry@huawei.com)<br>*-*-*-*-*-*-*-* <br>[PatchWork v2,0/6](https://patchwork.kernel.org/project/linux-arm-kernel/cover/1616668398-144648-1-git-send-email-john.garry@huawei.com)<br>*-*-*-*-*-*-*-* <br>[PatchWork v3,0/6](https://patchwork.kernel.org/project/linux-arm-kernel/cover/1617791570-165223-1-git-send-email-john.garry@huawei.com) |
| 2022/05/28 | zhengjun <zhengjun.xing@linux.intel.com> | [perf vendor events intel: Add metrics for Sapphirerapids](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=1bcca2b1bd67f3c0e5c3a88ed16c6389f01a5b31) | TODO | v2 ☑✓ 5.19-rc1 | [LORE v2,0/2](https://lore.kernel.org/all/20220528095933.1784141-1-zhengjun.xing@linux.intel.com) |
| 2022/08/25 | zhengjun.xing@linux.intel.com <zhengjun.xing@linux.intel.com> | [perf stat: Capitalize topdown metricsnel.org/all/20220825015458.3252239-1-zhengjun.xing@linux.intel.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/9-1-zhengjun.xing@linux.intel.com) |
## 11.3 Userspace counter access
-------
study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md
+64 -18
View File
@@ -3314,6 +3314,9 @@ v12 版本已经没有什么特性变更, 仅仅是一些 bugfix, 参见 phoroni
MGLRU 的开发者在 LPC-2022 上演示了 MGLRU [Multi-Gen LRU: Current Status & Next Steps](https://lpc.events/event/16/contributions/1269), phoronix 对此进行了跟踪报道, 参见 [MGLRU Looks Like One Of The Best Linux Kernel Innovations Of The Year](https://www.phoronix.com/news/MGLRU-LPC-2022).
之前 MGLRU 一直在 Andrew Morton 的 mm-unstable 分支, 2022 年 9 月中旬被 pick 到了 mm-stable, 为 v6.1 的 合入做准备. 参见 phoronix 报道 [MGLRU Patches Merged To "mm-stable" Ahead Of Linux 6.1 - New Benchmarks Look Good](https://www.phoronix.com/news/MGLRU-Reaches-mm-stable).
* 实现
传统的 LRU 页面回收仅仅通过 ACTIVE/INACTIVE 划分页面的冷热和老化程度, 这是一锤子买卖, 粒度非常粗, 对页面也机器不友好, 一个页面要么热页, 可以被宣判延刑, 要么是冷页, 可以立即被回收. 而 MGLRU 将页面的冷热程度做了更细粒度的划分.
@@ -4910,6 +4913,7 @@ David Rientjes 率先提出了这种想法 [Hugepage collapse in process context
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2022/03/11 | maobibo <maobibo@loongson.cn> | [mm/khugepaged: sched to numa node when collapse huge page](https://patchwork.kernel.org/project/linux-mm/patch/20220311090119.2412738-1-maobibo@loongson.cn/) | 622550 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220311090119.2412738-1-maobibo@loongson.cn)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/1](https://lore.kernel.org/r/20220315040549.4122396-1-maobibo@loongson.cn) |
| 2022/05/27 | Jiaqi Yan <jiaqiyan@google.com> | [Memory poison recovery in khugepaged collapsing](https://patchwork.kernel.org/project/linux-mm/cover/20220527190731.322722-1-jiaqiyan@google.com/) | 645671 | v4 ☐☑ | [LORE v4,0/2](https://lore.kernel.org/r/20220527190731.322722-1-jiaqiyan@google.com) |
| 2022/09/07 | Zach O'Keefe <zokeefe@google.com> | [mm: add file/shmem support to MADV_COLLAPSE](https://lore.kernel.org/all/20220907144521.3115321-1-zokeefe@google.com) | TODO | v3 ☐☑✓ | [2022/08/12 LORE 0/9](https://lore.kernel.org/linux-mm/20220812012843.3948330-1-zokeefe@google.com)<br>*-*-*-*-*-*-*-* <br>[2022/08/26 LORE v2,0/9](https://lore.kernel.org/linux-mm/20220826220329.1495407-1-zokeefe@google.com)<br>*-*-*-*-*-*-*-* <br>[2022/09/07 LORE v3,0/10](https://lore.kernel.org/all/20220907144521.3115321-1-zokeefe@google.com)<br>*-*-*-*-*-*-*-* <br>[2022/09/22 LORE v4,00/10](https://lore.kernel.org/all/20220922224046.1143204-1-zokeefe@google.com) |
### 7.2.5 THP splitting/reclaim/migration
@@ -5362,9 +5366,21 @@ Dirty COW(CVE-2016-5195) 是近几年影响比较严重的问题, 参见 [Dirty
### 8.2.5 MMAP locking
### 8.2.5 MMAP Locking Scalability
-------
当用户空间通过 malloc()/mmap() 等使用内存时, 只是分配了虚拟内存, 即只在进程地址空间中建立了VMA, 并没有分配物理内存, 因此自然也没有建立虚拟内存与物理内存的关联. 当进程首次访问时会触发缺页异常处理.
当进程发生缺页异常时, 由于需要对进程空间 VMA 进行操作, 开始缺页前会先持进程的 mmap_sem 锁, 缺页完成后释放 mmap_sem.
进程缺页处理时需要持有 mmap_sem 的 reader 锁. mmap_sem 锁是进程为了保护自身虚拟地址空间不受多线程并发访问影响而设计的. 而频繁发生缺页时, mmap_sem 锁的竞争将会非常激烈.
由于 map_sem 锁的存在, 多线程程序访问内存方面的并发能力严重受到该锁的竞争激烈程度的制约. 要改善这个问题, 毫无疑问是需要减少 mmap_sem 锁的竞争.
| 时间 | 讨论 |
|:----:|:----:|
| 2013 年 | [LSFMM: Problems with mmap_sem](https://lwn.net/Articles/548098) |
@@ -5372,41 +5388,71 @@ Dirty COW(CVE-2016-5195) 是近几年影响比较严重的问题, 参见 [Dirty
| 2015 年 | [Topics of interest from the MM summit](https://events.static.linuxfound.org/sites/events/files/slides/mm.pdf) |
| 2017 年 | [Another attempt at speculative page-fault handling](https://lwn.net/Articles/730531) |
| 2018 年 | [Zone-lock and mmap_sem scalability](https://lwn.net/Articles/753269), [The LRU lock and mmap_sem](https://lwn.net/Articles/753058) |
| 2019 年 | [Splitting the mmap_sem](https://lore.kernel.org/all/20191203222147.GV20752@bombadil.infradead.org) |
| 2019 年 | [How to get rid of mmap_sem](https://lwn.net/Articles/787629) |
| 2021 年 | [Introducing maple trees](https://lwn.net/Articles/845507) |
| 2021 年 | [LSF/MM TOPIC] mmap locking topics](https://www.spinics.net/lists/linux-mm/msg258803.html) |
| 2022 年 | [The ongoing search for mmap_lock scalability](https://lwn.net/Articles/893906)<br>LPC-2022 [Scalability solutions for the mmap_lock - Maple Tree and per-VMA locks](https://lpc.events/event/16/contributions/1271) |
#### 8.2.5.1 SPF(Speculative page faults)
-------
* mmap_sem Scalability
[投机性缺页异常(SPF)原理分析](https://zhuanlan.zhihu.com/p/567855662)
[投机性缺页异常处理](https://developer.aliyun.com/article/767293)
[spf_test](https://github.com/surenbaghdasaryan/spf_test/blob/main/spf_test.c)
为了解决这个问题, 内核研发人员 Peter Zijlstra 提出了 投机性缺页SPF(Speculative page-fault handling) 优化来实现对进程 VMA 的无锁读访问, 并在 v4.17(2009 年)开发窗口期间发出了第一版的补丁集. 它的基本思路是通过避免在缺页异常处理中使用 mmapsem, 无锁遍历 VMA, 从而提高内存访问的性能.
投机性缺页就像一场赌博, 它在赌访问 VMA 时 VMA 没有被修改, 如果 VMA 没有被修改, 它就赌赢了, 这个过程确实不需要持锁; 如果VMA被修改了, 它就赌输了, SPF 做的工作就没有任何意义, 还是需要继续传统的缺页处理. 当然, 如果系统整体情况大部分时候 SPF 赌赢了, 它其实就赚了.
但是我们不得不说, 设计和使用 mmap_sem 就是为了解决一些不好解决的同步问题, 如果想要无锁化, 那这些问题就得想其他的办法去解决.
| 问题 1 | SPF 优化策略 | SPF 实现 |
|:------:|:----------:|:--------:|
| 无锁处理 PageFault 的区间越大, SPF 赌输的概率越大 | 缩小临界区的大小 | 尽可能把与 VMA 状态无关的工作都先做掉, 然后在直接改变进程地址空间之前再检查一下 VMA 是否发生了改变. 举例来说, 当我们从磁盘读数据到内存的时候, 我们可以先分配一个内存页, 将数据读取出来, 这些阶段都是不需要 mmap_sem 的, 而当我们把这个页加入到进程地址空间的时候我们需要一个一致的 VMA, 所以这个时候是需要拿 mmap_sem 的 |
| 写冲突. 无锁处理 PageFault 期间, 对应的 VMA 描述中的区域可能发生改变. | 通过 seqlock 保护 VMA 修改 | 在 VMA 中增加顺序锁 seqlock, 所有修改 VMA 的地方都会增加 sequence count计数, 在缺页时工作前先获取一次 sequence count, 然后不持 mmap_sem 锁情况下进行缺页处理, 处理完成后, 需要再获取一次 sequence count, 检查有计数有没有发生改变, 如果发生了改变, 说明 VMA 在这个期间被修改过了, 如果没有发生改变, 说明 VMA 在这个期间没有被修改过. |
| 释放冲突. 无锁处理 PageFault 期间, 对应的 VMA 可能被释放. | 最早 Peter 的版本建议通过 [SRCU(RCU的一种可睡眠的变体)来串行化 VMA](https://lore.kernel.org/lkml/20100104182813.479668508@chello.nl/) 的更新. 这可以保证在处理缺页异常的时候, VMA 结构是存在的. Laurent 接手后 v10 期间发现它引起了性能的下降. v11 基于 SRCU 保护 VMA 释放的灵感通过 [mm_rb_lock 来实现](https://lore.kernel.org/linux-mm/1526555193-7242-19-git-send-email-ldufour@linux.vnet.ibm.com). mm_rb_lock 锁机引入了 vma_get() 和 vma_put() 使得得在访问 RB Tree 时使用不持有 mmap_sem. v12 又改成 [sequence lock](https://lore.kernel.org/lkml/20190416134522.17540-20-ldufour@linux.ibm.com). 不过后来 Michel Lespinasse 接手的版本使用了 [rcu safe vma freeing](https://lore.kernel.org/all/20220128131006.67712-12-michel@lespinasse.org). |
| TLB失效. 很多行为, 例如 unmapping 一个内存区域, 都会导致 TLB 的失效. 失效 TLB 的过程是发送处理期间中断(IPI)来告诉每个 CPU 失效它自己的 TLB. unmap的调用路径可能会在锁住特定的页表项期间进行 TLB 失效操作. 此时, Speculative-fault-handling 可能在关中断的情况下尝试获取页表锁, 如果这种尝试的页表项被锁在 unmap 的路径上, 处理器会在关中断的情况下自旋, 因此永远收不到 TLB 失效的IPI, 这将导致死锁. | 优先尝试SPF无锁访问 | 在 speculative 路径使用 trylock 操作获取锁, 如果获取锁失败, 则立即 fall back 到传统 page fault 处理流程上. |
| 时间线 | 对应版本 | 描述 |
|:-----:|:-------:|:---:|
| 2009 | NA | speculative page fault 相关的 patch 由 Hiroyuki Kamezawa 在 2009 年发布 |
| 2010 | NA | 接下来 Peter Zijlstra 组织了内核社区的讨论并开发了他自己的实现, 他使用了 RCU 来完成无锁读 VMA. 不过 Peter 的实现也有一些问题, 所以没能被合并进主干. |
| 2014 | NA | 由于很多之前导致他的 patch 不能工作的问题都已经解决了, 所以 Peter Zijlstra 重启了这个想法. 然而, 讨论再次无疾而终. |
| 2019 | NA | Dufourt 在最新内核移植了 PeterZ 的 patch, 同时也添加了自己的一些 patch, 然后重新发送到了邮件列表. 不过 Dufour 提到, 他的 patch 集里仍然存在 TLB 失效的问题. |
| 2022 | v5.12~v5.17 | Michel 继续了这项工作 |
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2009/12/18 | KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> | [speculative page fault](https://lore.kernel.org/all/20091218093849.8ba69ad9.kamezawa.hiroyu@jp.fujitsu.com) | TODO | v1 ☐☑✓ | [LORE v1,0/11](https://lore.kernel.org/all/20091218093849.8ba69ad9.kamezawa.hiroyu@jp.fujitsu.com) |
| 2009/12/24 | KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> | [asynchronous page fault](https://lkml.org/lkml/2009/12/24/153) | TODO | v1 ☐☑✓ | [LORE v1,0/11](https://lkml.org/lkml/2009/12/24/153) |
| 2010/01/04 | Peter Zijlstra <a.p.zijlstra@chello.nl> | [Speculative pagefault -v3](https://lore.kernel.org/lkml/20100104182429.833180340@chello.nl) | SPF | RFC v3 ☐ | [PatchWork](https://lore.kernel.org/lkml/20100104182429.833180340@chello.nl) |
| 2019/04/16 | Laurent Dufour <ldufour@linux.vnet.ibm.com> | [Speculative page faults](http://lore.kernel.org/patchwork/patch/1062659) | SPF | v12 ☐ | [LORE v11,00/26](https://lore.kernel.org/linux-mm/1526555193-7242-1-git-send-email-ldufour@linux.vnet.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v12,00/31](https://lore.kernel.org/lkml/20190416134522.17540-1-ldufour@linux.ibm.com) |
| 2022/01/28 | Michel Lespinasse <michel@lespinasse.org> | [Speculative page faults (anon vmas only)](http://lore.kernel.org/patchwork/patch/1420569) | SPF | v11 ☐ | [LORE 00/29](https://lore.kernel.org/lkml/20210430195232.30491-1-michel@lespinasse.org)<br>*-*-*-*-*-*-*-* <br>[PatchWork RFC,00/37](https://lore.kernel.org/patchwork/patch/1408784)<br>*-*-*-*-*-*-*-* <br>[PatchWork v1](https://lore.kernel.org/patchwork/patch/1420569)<br>*-*-*-*-*-*-*-* <br>[PatchWork v2,00/35](https://patchwork.kernel.org/project/linux-mm/cover/20220128131006.67712-1-michel@lespinasse.org) |
#### 8.2.5.2 mmap_sem Scalability
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2018/03/21 | Yang Shi <yang.shi@linux.alibaba.com> | [Drop mmap_sem during unmapping large map](https://lore.kernel.org/all/1521581486-99134-1-git-send-email-yang.shi@linux.alibaba.com) | 1521581486-99134-1-git-send-email-yang.shi@linux.alibaba.com | v1 ☐☑✓ | [LORE v1,0/8](https://lore.kernel.org/all/1521581486-99134-1-git-send-email-yang.shi@linux.alibaba.com) |
* SPF(Speculative page faults)
[投机性缺页异常(SPF)原理分析](https://zhuanlan.zhihu.com/p/567855662)
[spf_test](https://github.com/surenbaghdasaryan/spf_test/blob/main/spf_test.c)
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2010/01/04 | Peter Zijlstra <a.p.zijlstra@chello.nl> | [Speculative pagefault -v3](http://lore.kernel.org/patchwork/patch/183997) | SPF | RFC v3 ☐ | [PatchWork](https://lore.kernel.org/patchwork/patch/183997) |
| 2019/04/16 | Laurent Dufour <ldufour@linux.vnet.ibm.com> | [Speculative page faults](http://lore.kernel.org/patchwork/patch/1062659) | SPF | v12 ☐ | [PatchWork v12,00/31](https://lore.kernel.org/patchwork/patch/1062659) |
| 2022/01/28 | Michel Lespinasse <michel@lespinasse.org> | [Speculative page faults (anon vmas only)](http://lore.kernel.org/patchwork/patch/1420569) | SPF | v11 ☐ | [PatchWork RFC,00/37](https://lore.kernel.org/patchwork/patch/1408784)<br>*-*-*-*-*-*-*-* <br>[PatchWork v1](https://lore.kernel.org/patchwork/patch/1420569)<br>*-*-*-*-*-*-*-* <br>[PatchWork v2,00/35](https://patchwork.kernel.org/project/linux-mm/cover/20220128131006.67712-1-michel@lespinasse.org) |
* Fine grained MM locking
#### 8.2.5.3 Fine grained MM locking
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2013/01/31 | Michel Lespinasse <walken@google.com> | [Mapping range lock](https://lore.kernel.org/patchwork/patch/356467) | 文件映射的 mapping lock | RFC ☐ | [PatchWork RFC](https://lore.kernel.org/patchwork/patch/356467) |
| 2020/02/24 | Michel Lespinasse <walken@google.com> | [Fine grained MM locking](https://patchwork.kernel.org/project/linux-mm/cover/20200224203057.162467-1-walken@google.com) | 细粒度 MM MMAP lock | RFC ☐ | [PatchWork RFC](https://patchwork.kernel.org/project/linux-mm/cover/20200224203057.162467-1-walken@google.com), [fine_grained_mm.pdf](https://linuxplumbersconf.org/event/4/contributions/556/attachments/304/509/fine_grained_mm.pdf) |
* per-VMA locks
#### 8.2.5.4 per-VMA locks
-------
[Concurrent page-fault handling with per-VMA locks](https://lwn.net/Articles/906852)
@@ -5416,8 +5462,8 @@ Dirty COW(CVE-2016-5195) 是近几年影响比较严重的问题, 参见 [Dirty
| 2022/08/29 | Suren Baghdasaryan <surenb@google.com> | [per-VMA locks proposal](https://lore.kernel.org/all/20220829212531.3184856-1-surenb@google.com) | TODO | v1 ☐☑✓ | [2022/08/29 LORE v1,0/28](https://lore.kernel.org/all/20220829212531.3184856-1-surenb@google.com)<br>*-*-*-*-*-*-*-* <br>[2022/09/01 LORE v1,0/28](https://lore.kernel.org/r/20220901173516.702122-1-surenb@google.com) |
* Maple Tree
#### 8.2.5.5 Maple Tree
-------
[Maple Tree "RFC" Patches Sent Out As New Data Structure To Help With Linux Performance](https://www.phoronix.com/scan.php?page=news_item&px=Maple-Tree-Linux-RFC)
study/kernel/00-DESCRIPTION/SCHEDULER.md
+30 -7
View File
@@ -2478,7 +2478,7 @@ Peter 将 sched/numa 的整体思路上也做了不断的调整和改动, 也开
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:---:|:----------:|:----:|
| 2021/10/27 | Gang Li <ligang.bdlg@bytedance.com> | [sched/numa: add per-process numa_balancing](https://lkml.org/lkml/2021/10/27/517) | 这个补丁在 prctl 中添加了一个新的 api PR_NUMA_BALANCING 来控制当个进程参与和禁止 numa_balancing. 在执行 numa_balancing 时, 大量的页面错误会导致性能损失. 因此, 那些关心最坏情况下性能的进程需要禁用 numa_balancing. 相反, 另一些则允许暂时的性能损失以换取更高的平均性能, 因此启用 numa 平衡对它们来说更好. 但是当前 numa balancing 只能由 `/proc/sys/kernel/numa_balancing` 全局控制. 因此这个特性希望禁用/启用每个进程的 numa_balancing. 在 mm_struct 下添加 numa_balancing. 然后在 task_tick_numa 中使用来控制. mm ->numa_balancing 仅在全局 numa_balancing 启用时有效. 当全局 numa_balancing 被禁用时, mm->numa_blancing 不会改变, 当你想要获得进程 numa_balancing 状态时, 你总是会得到 0, 并且当你使用 prctl set 它时, 内核将返回 err. | v1 ☐ | [LKML](https://lkml.org/lkml/2021/10/27/517)<br>*-*-*-*-*-*-*-* <br>[LORE v1,0/1](https://lore.kernel.org/r/20220224075227.27127-1-ligang.bdlg@bytedance.com) |
| 2021/10/27 | Gang Li <ligang.bdlg@bytedance.com> | [sched/numa: add per-process numa_balancing](https://lkml.org/lkml/2021/10/27/517) | 这个补丁在 prctl 中添加了一个新的 api PR_NUMA_BALANCING 来控制当个进程参与和禁止 numa_balancing. 在执行 numa_balancing 时, 大量的页面错误会导致性能损失. 因此, 那些关心最坏情况下性能的进程需要禁用 numa_balancing. 相反, 另一些则允许暂时的性能损失以换取更高的平均性能, 因此启用 numa 平衡对它们来说更好. 但是当前 numa balancing 只能由 `/proc/sys/kernel/numa_balancing` 全局控制. 因此这个特性希望禁用/启用每个进程的 numa_balancing. 在 mm_struct 下添加 numa_balancing. 然后在 task_tick_numa 中使用来控制. mm ->numa_balancing 仅在全局 numa_balancing 启用时有效. 当全局 numa_balancing 被禁用时, mm->numa_blancing 不会改变, 当你想要获得进程 numa_balancing 状态时, 你总是会得到 0, 并且当你使用 prctl set 它时, 内核将返回 err. | v1 ☐ | [LKML](https://lkml.org/lkml/2021/10/27/517)<br>*-*-*-*-*-*-*-* <br>[LORE v1,0/1](https://lore.kernel.org/r/20220224075227.27127-1-ligang.bdlg@bytedance.com)<br>*-*-*-*-*-*-*-* <br>[2022/09/29 LORE v4](https://lore.kernel.org/all/20220929064359.46932-1-ligang.bdlg@bytedance.com) |
| 2014/05/14 | Rik van Riel <riel@redhat.com> | [sched/numa: Allow task switch if load imbalance improves](https://linuxplumbersconf.org/event/4/contributions/480) | 目前 NUMA 平衡代码只允许在 NUMA 节点上的负载处于平衡状态时在 NUMA 节点之间移动任务. 当负载开始不平衡时, 它就崩溃了. 因此这个补丁引入 load_too_imbalanced() 来判定, 如果不平衡较小, 或者新的不平衡小于原来的不平衡, 则允许在 NUMA 节点之间移动任务. | v1 ☑ 3.16-rc1 | [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e63da03639cc9e6e83b62e7ef8ffdbb92421416a) |
| 2018/09/21 | Srikar Dronamraju <srikar@linux.vnet.ibm.com> | [sched/numa: Avoid task migration for small NUMA improvement](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6fd98e775f24fd41520928d345f5db3ff52bb35d) | 如果 NUMAC 层次的任务迁移带来的改进非常小(小于 SMALLIMP), 那么应该尽量避免任务迁移. 否则可能会带来 pingpong(进程来回迁移颠簸), 甚至 cache-miss 引起的性能下降. | v1 ☑ 4.19-rc7 | [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6fd98e775f24fd41520928d345f5db3ff52bb35d) |
@@ -4390,7 +4390,8 @@ LPC-2022 [Dynamic Energy Model to handle leakage power](https://lpc.events/event
不管是服务器领域, 还是终端以及嵌入式 rtos 等场景, 性能与功耗都是一个永恒的话题. 因此我们经常把它们合在一起称为"性能, 功耗与热". 而这些都离不开调度器的参与. 调度器通过之前提到的两个核心功能: 选核和选进程, 提升系统的性能和吞吐量, 再或者在满足性能的前提下通过功耗感知的调度来降低功耗. 之前我们提到的手段都是围绕着调度核心功能的. 通过选核让更多的 CPU 能够处于 IDLE 状态是可以降低功耗的, EAS 的实现已经与 CPUIDLE 紧密结合. 但是别忘了, 我们还有 DVFS, 通过调压调频也可以降低功耗. 因此 EAS 也提供了一些手段能够让调度器感知 CPUFREQ 框架.
1. 传统 CPU 调频策略
### 7.3.1 传统 CPU 调频策略
-------
CPUFREQ 调频框架主要分为 3 块: CPUFreq 驱动和 CPUFreq 核心模块、CPUFreq Governor.
@@ -4400,7 +4401,8 @@ CPUFreq 驱动是处理和平台相关的逻辑, Governor 中实现了具体的
但是对于 CPU 的负载, 没有谁比调度器还清楚的了. 所以 cpufreq governor 完全没必要自己去做负载采样, 应该从内核调度器那里获取. 因此在 EAS 设计的早期, 基于调度器的 cpufreq governor 就是这样引出来的.
2. 调度器驱动的调频
### 7.3.2 调度器驱动的调频
-------
当时内核社区中, 逐渐实现了两个成形的方案.
@@ -4419,20 +4421,32 @@ CPUFreq 驱动是处理和平台相关的逻辑, Governor 中实现了具体的
| 2016/03/13 | Michael Turquette <mturquette@baylibre.com> | [schedutil enhancements](https://lore.kernel.org/all/1457932932-28444-1-git-send-email-mturquette+renesas@baylibre.com) | 1457932932-28444-1-git-send-email-mturquette+renesas@baylibre.com | v1 ☐☑✓ | [LORE v1,0/8](https://lore.kernel.org/all/1457932932-28444-1-git-send-email-mturquette+renesas@baylibre.com) |
3. schedutil 后续优化
### 7.3.3 schedutil 后续优化
-------
| 时间 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----------:|:---:|
| 2021/08/12 | Viresh Kumar <viresh.kumar@linaro.org> | [Add callback to register with energy model](https://lore.kernel.org/patchwork/cover/1424708) | 当前许多 cpufreq 驱动程序向每个策略的注册了能耗模型, 并通过相同的操作 dev_pm_opp_of_register_em() 来完成. 但是随着 thermal-cooling 的完善, 可以在 cpufreq 层次通过新的回调 register_em 来完成这个工作. | v3 ☐ | [PatchWork V3,0/9](https://patchwork.kernel.org/project/linux-arm-kernel/cover/cover.1628742634.git.viresh.kumar@linaro.org) |
| 2021/09/08| Viresh Kumar <viresh.kumar@linaro.org> | [Inefficient OPPs](https://patchwork.kernel.org/project/linux-pm/cover/1631109930-290049-1-git-send-email-vincent.donnefort@arm.com) | schedutil 中增加了对低能效(inefficient) OPP 的感知, 引入 CPUFREQ_RELATION_E 标记来使得 CPUFREQ 只使用和引用有效的频点.<br>Arm 的 Power 团队在为谷歌的 Pixel4 开发一个实验性内核, 以评估和改进现实生活中 Android 设备上的主线性能和能耗. 发现 SD855 SoC 有几个效率低下的 OPP. 这些 OPP 尽管频率较低, 但功耗却较高, 任务这种频率下工作, 性能不光下降了, 功耗也很高. 通过将它们从 EAS 能效模型中移除, 使得最高效的 CPU 在任务分配上更有吸引力, 有助于减少中、大型 CPU 的运行时间, 同时提高了集群的空闲时间. 由于集群之间存在巨大的能源成本差异, 因此增加空闲时间对该平台来说至关重要. | v7 ☑ 5.16-rc1 | [PatchWork v7,0/9](https://patchwork.kernel.org/project/linux-pm/cover/1631109930-290049-1-git-send-email-vincent.donnefort@arm.com) |
4. 各个厂商基于 schedutil 的进一步优化和改进
### 7.3.4 各个厂商基于 schedutil 的进一步优化和改进
-------
华为针对 schedutil 进行优化, 通过 CONFIG_CPU_FREQ_GOV_SCHEDUTIL_OPT, 提供了一套与 interactive 兼容的参数和机制, 实现了用户态对 schedutil 决策的干预和优化. 参见 [mate40, cpufreq_schedutil](https://github.com/gatieme/MobileModels/blob/huawei/noh-mate40/kernel/sched/cpufreq_schedutil.c)
高通在自己基于 AOSP 的 GKI 中, 提供了一个 schedutil 类似的调频 GOVERNOR [CPUFREQ_WALT](https://source.codeaurora.cn/quic/la/kernel/msm-5.10/tree/kernel/sched/walt/cpufreq_walt.c?h=kernel.lnx.5.10.r1-rel), 与 WALT 地深度绑定和优化. 并通过 waltgov_tunables 提供了近似于 interactive 的少量参数, 允许用户态干预. 只是这里实现的 target_load 是通过 target_load_thresh 和 target_load_shift 映射得到的, 参见 [walt_map_util_freq()](https://source.codeaurora.cn/quic/la/kernel/msm-5.10/tree/kernel/sched/walt/cpufreq_walt.c?h=kernel.lnx.5.10.r1-rel#n204). 因此用户对于 target_load 的设置相比较原来 interactive 直接设置 target_loads 参数的方式更弱一些.
### 7.3.5 其他 governor
-------
[Google's CPUFreq "Interactive" Governor Looks To Go Mainline](https://www.phoronix.com/news/CPUFreq-Interactive-Governor)
| 时间 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----------:|:---:|
| 2015/10/27 | Bálint Czobor <czoborbalint@gmail.com> | [cpufreq: interactive: New 'interactive' governor](https://lore.kernel.org/all/1445967059-6897-1-git-send-email-czoborbalint@gmail.com) | TODO | v1 ☐☑✓ | [LORE v1,0/70](https://lore.kernel.org/all/1445967059-6897-1-git-send-email-czoborbalint@gmail.com) |
## 7.4 Frequency Invariance Engine
-------
@@ -5044,6 +5058,7 @@ PREEMPT-RT PATCH 的核心思想是最小化内核中不可抢占部分的代码
| 日期 | LWN | 翻译 |
|:---:|:----:|:---:|
| 2019/09/09 | LPC-2019 上关于 latency nice 的演讲: [Task latency-nice](https://lpc.events/event/4/contributions/482) | NA |
| 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) |
| 2022/03/17 | [Improved response times with latency nice](https://lwn.net/Articles/887842) | [LWN: 采用 latency nice 改善响应时间](https://blog.csdn.net/Linux_Everything/article/details/123887454) |
| 2022/04/05 | NA | 国内对这组补丁的分析 [latency-nice 优先级补丁源码分析](https://blog.csdn.net/qq_23662505/article/details/123977540) |
@@ -5083,7 +5098,7 @@ enqueue_task_fair()
|:-----:|:----:|:----:|:----:|:------------:|:----:|
| 2020/02/28 | Parth Shah <parth@linux.ibm.com> | [Introduce per-task latency_nice for scheduler hints](https://lore.kernel.org/all/20200228090755.22829-1-parth@linux.ibm.com) | 20200228090755.22829-1-parth@linux.ibm.com | v5 ☐☑✓ | [LORE v4,0/4](https://lore.kernel.org/lkml/20200224085918.16955-1-parth@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v5,0/4](https://lore.kernel.org/all/20200228090755.22829-1-parth@linux.ibm.com) |
| 2020/05/07 | Parth Shah <parth@linux.ibm.com> | [IDLE gating in presence of latency-sensitive tasks](https://lore.kernel.org/all/20200507133723.18325-1-parth@linux.ibm.com) | 20200507133723.18325-1-parth@linux.ibm.com | v1 ☐☑✓ | [LORE v1,0/4](https://lore.kernel.org/all/20200507133723.18325-1-parth@linux.ibm.com) |
| 2022/09/16 | Vincent Guittot <vincent.guittot@linaro.org> | [Add latency_nice priority](https://lore.kernel.org/all/20220311161406.23497-1-vincent.guittot@linaro.org) | 参见 [Improved response times with latency nice](https://lwn.net/Articles/887842). | v1 ☐☑✓ | [2022/03/11 LORE v1,0/6](https://lore.kernel.org/all/20220311161406.23497-1-vincent.guittot@linaro.org)<br>*-*-*-*-*-*-*-* <br>[2022/05/12 LORE v2,0/7](https://lore.kernel.org/all/20220512163534.2572-1-vincent.guittot@linaro.org)<br>*-*-*-*-*-*-*-* <br>[2022/09/09 LORE v3,0/8](https://lore.kernel.org/all/20220909130309.25458-1-vincent.guittot@linaro.org)<br>*-*-*-*-*-*-*-* <br>[2022/09/16 LORE v4,0/8](https://lore.kernel.org/all/20220916080305.29574-1-vincent.guittot@linaro.org) |
| 2022/09/16 | Vincent Guittot <vincent.guittot@linaro.org> | [Add latency_nice priority](https://lore.kernel.org/all/20220311161406.23497-1-vincent.guittot@linaro.org) | 参见 [Improved response times with latency nice](https://lwn.net/Articles/887842). | v1 ☐☑✓ | [2022/03/11 LORE v1,0/6](https://lore.kernel.org/all/20220311161406.23497-1-vincent.guittot@linaro.org)<br>*-*-*-*-*-*-*-* <br>[2022/05/12 LORE v2,0/7](https://lore.kernel.org/all/20220512163534.2572-1-vincent.guittot@linaro.org)<br>*-*-*-*-*-*-*-* <br>[2022/09/09 LORE v3,0/8](https://lore.kernel.org/all/20220909130309.25458-1-vincent.guittot@linaro.org)<br>*-*-*-*-*-*-*-* <br>[2022/09/16 LORE v4,0/8](https://lore.kernel.org/all/20220916080305.29574-1-vincent.guittot@linaro.org)<br>*-*-*-*-*-*-*-* <br>[2022/09/25 LORE v5,0/8](https://lore.kernel.org/all/20220925143908.10846-1-vincent.guittot@linaro.org) |
### 8.9.2 Xen CPU Scheduling
-------
@@ -5180,6 +5195,14 @@ CONFIG_HUAWEI_SCHED_VIP 被标记为 vip_prio, 为 VIP 线程提供了近似于
| 2020/05/11 | Pratik Rajesh Sampat <psampat@linux.ibm.com> | [Alternate history mechanism for the TEO governor](https://lore.kernel.org/all/20200511141055.43029-1-psampat@linux.ibm.com) | 20200511141055.43029-2-psampat@linux.ibm.com | v1 ☐☑✓ | [LORE v1,0/1](https://lore.kernel.org/all/20200511141055.43029-1-psampat@linux.ibm.com) |
## 9.3 CPU-Idle latency
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2020/9/2 | Pratik Rajesh Sampat | [Selftest for cpuidle latency measurement](https://lkml.org/lkml/2020/9/2/356) | 678872 | v1 ☐☑ | [LORE v1,0/1](https://lkml.org/lkml/2020/9/2/356) |
| 2021/04/12 | Pratik Rajesh Sampat <psampat@linux.ibm.com> | [CPU-Idle latency selftest framework](https://lore.kernel.org/all/20210412074309.38484-1-psampat@linux.ibm.com) | TODO | v4 ☐☑✓ | [LORE RFC,0/2](https://lore.kernel.org/all/20210315114827.46036-1-psampat@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/2](https://lore.kernel.org/all/20210401114504.13466-1-psampat@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v3,0/2](https://lore.kernel.org/all/20210404083354.23060-1-psampat@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v4,0/2](https://lore.kernel.org/all/20210412074309.38484-1-psampat@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v5,0/2](https://lore.kernel.org/all/20210430082804.38018-1-psampat@linux.ibm.com) |
# 10 进程管理
-------