From dfd53eb41b657e47120f9312086a9349a19c2823 Mon Sep 17 00:00:00 2001 From: Cheng Jian Date: Mon, 25 Apr 2022 22:52:40 +0800 Subject: [PATCH] description: uppdate to v5.17 https://kernelnewbies.org/Linux_5.17 --- study/kernel/00-DESCRIPTION/ARCH.md | 8 ++++- study/kernel/00-DESCRIPTION/DEBUGGING.md | 36 ++++++++++++++++++- study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md | 32 ++++++++++------- study/kernel/00-DESCRIPTION/SCHEDULER.md | 11 +++++- 4 files changed, 72 insertions(+), 15 deletions(-) diff --git a/study/kernel/00-DESCRIPTION/ARCH.md b/study/kernel/00-DESCRIPTION/ARCH.md index 5a84941..74a847e 100644 --- a/study/kernel/00-DESCRIPTION/ARCH.md +++ b/study/kernel/00-DESCRIPTION/ARCH.md @@ -548,6 +548,8 @@ ARM v8.2 引入了 [UAO](https://community.arm.com/arm-community-blogs/b/archite ## 4.1 Straight Line Speculation ------- +[Blocking straight-line speculation — eventually](https://lwn.net/Articles/877845) + Google 的 SafeSide 小组发现 ARM CPU 存在新的投机执行漏洞, 可导致侧信道攻击. 研究人员在 Armv8-A(Cortex-A) CPU 体系结构中发现了一个名为直线推测( Straight-Line Speculation , SLS) 的新漏洞, 被追踪为 [CVE-2020-13844](https://nvd.nist.gov/vuln/detail/CVE-2020-13844). 该漏洞可导致攻击者对 ARM 架构处理器进行侧边信道攻击(SCA). 让目标处理器通过预先访问数据来提升性能, 然后再扔掉所有使用过的计算分支(computational branches), 而 SLS 则通过类似的侧道攻击就能让黑客从处理器直接获得(窃取)重要数据. @@ -564,7 +566,8 @@ SLS 被认为是 Spectre 漏洞的变体, 但二者的攻击范围略有不同, | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| -| 2021/06/10 | Anup Patel | [ARM: Implement Clang's SLS mitigation](https://patchwork.kernel.org/project/linux-security-module/patch/20210212051500.943179-1-jiancai@google.com) | RISC-V高级核心本地中断(Advacned Core Local Interruptor-ACLINT) 支持 | v8 ☐ | [2021/06/10Patchwork v7,0/8](https://patchwork.kernel.org/project/linux-riscv/cover/20210830041729.237252-1-anup.patel@wdc.com)
*-*-*-*-*-*-*-*
[LWN v8, 0/8](https://lwn.net/Articles/872513) | +| 2021/06/10 | Anup Patel | [ARM: Implement Clang's SLS mitigation](https://patchwork.kernel.org/project/linux-security-module/patch/20210212051500.943179-1-jiancai@google.com) | NA | v8 ☐ | [2021/06/10Patchwork v7,0/8](https://patchwork.kernel.org/project/linux-riscv/cover/20210830041729.237252-1-anup.patel@wdc.com)
*-*-*-*-*-*-*-*
[LWN v8, 0/8](https://lwn.net/Articles/872513) | +| 2021/12/04 | Peter Zijlstra | [x86: Add stright-line-speculation mitigations](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=e463a09af2f0677b9485a7e8e4e70b396b2ffb6f) | 20211204134338.760603010@infradead.org | v2 ☑✓ 5.17-rc1 | [LORE v2,0/6](https://lore.kernel.org/all/20211204134338.760603010@infradead.org) | ## 4.2 Control-Flow Enforcement Technology (CET) @@ -613,6 +616,7 @@ ARM 规范 [DEN0098](https://developer.arm.com/documentation/den0098/latest) 中 Arm True Random Number Generator Firmware Interface 1.0 于去年发布, 最终由Arm TrustZone的TRNG或其他原始噪声等硬件设备 提供支持. + | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2020/12/11 | Vladimir Murzin | [ARM: arm64: Add SMCCC TRNG entropy service](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=38db987316a38a3fe55ff7f5f4653fcb520a9d26) | NA | v4 ☑ 5.12-rc1 | [LORE v4,0/5](https://lore.kernel.org/lkml/20201211160005.187336-1-andre.przywara@arm.com) | @@ -628,6 +632,8 @@ Arm True Random Number Generator Firmware Interface 1.0 于去年发布, 最终 [Uniting the Linux random-number devices](https://lwn.net/Articles/884875) +[Random number generator enhancements for Linux 5.17 and 5.18](https://www.zx2c4.com/projects/linux-rng-5.17-5.18) + | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2021/11/21 | "Stephan Müller" | [/dev/random - a new approach](https://lore.kernel.org/lkml/2036923.9o76ZdvQCi@positron.chronox.de) | 随机数实现改进. | v1 ☐ | [Patchwork v43 00/15](https://lore.kernel.org/lkml/2036923.9o76ZdvQCi@positron.chronox.de) | diff --git a/study/kernel/00-DESCRIPTION/DEBUGGING.md b/study/kernel/00-DESCRIPTION/DEBUGGING.md index 2c848e0..2a00900 100644 --- a/study/kernel/00-DESCRIPTION/DEBUGGING.md +++ b/study/kernel/00-DESCRIPTION/DEBUGGING.md @@ -290,6 +290,14 @@ Facebook 在 2018 年开源了一套解决重要计算集群管理问题的 Linu | 2020/09/11 | Kan Liang | [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 | [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 服务器上, 可以使用:
`sudo perf stat -M TopDownL1 sleeep 1`
来进行 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)
*-*-*-*-*-*-*-*
[PatchWork v2,0/6](https://patchwork.kernel.org/project/linux-arm-kernel/cover/1616668398-144648-1-git-send-email-john.garry@huawei.com)
*-*-*-*-*-*-*-*
[PatchWork v3,0/6](https://patchwork.kernel.org/project/linux-arm-kernel/cover/1617791570-165223-1-git-send-email-john.garry@huawei.com) | +## 11.3 Userspace counter access +------- + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:----:|:---------:|:----:| +| 2021/12/08 | Rob Herring | [arm64 userspace counter support](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=aa1005d15d2aee10e5b93a25db076c47e05c4efa) | 20211208201124.310740-1-robh@kernel.org | v13 ☑✓ 5.17-rc1 | [LORE v13,0/5](https://lore.kernel.org/all/20211208201124.310740-1-robh@kernel.org) | + + ## 11.4 分支预测 ------- @@ -480,7 +488,7 @@ v2: [Fast Kernel Headers v2 Posted - Speeds Up Clang-Built Linux Kernel Build By | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| -| 2022/01/02 | Ingo Molnar | ["Fast Kernel Headers" Tree -v1: Eliminate the Linux kernel's "Dependency Hell"](https://lore.kernel.org/lkml/YdIfz+LMewetSaEB@gmail.com) | "Fast Kernel Headers" 的补丁集, 新增 config 配置, CONFIG_FAST_HEADERS 和 CONFIG_KALLSYMS_FAST.
这个补丁集非常庞大, 包含了 2000+ 补丁, 这可能是内核有史以来代码量最大的一个功能. 但是效果也很不错.
1. 启用了 CONFIG_FAST_HEADERS 的内核每小时的内核构建次数可能比当前的库存内核多出 78%, 在支持的架构上，绝对内核构建性能可以提高 50~80%.将许多高级标头与其他标头分离, 取消不相关的函数, 类型和 API 标头的分离, 头文件的自动依赖关系处理以及各种其他更改.
2. CONFIG_KALLSYMS_FAST 则实现了一个基于 objtool 的未压缩符号表功能, 它避免了 vmlinux 对象文件的通常三重链接, 这是增量内核构建的主要瓶颈. 由于即使使用 distro 配置, kallsyms 表也只有几十 MB 大, 因此在内核开发人员的桌面系统上, 内存成本是可以接受的. 不过当前只在 x86_64 下实现了此功能.
到目前为止, 这个庞大的补丁系列已经在 x86/x86_64, SPARC, MIPS 和 ARM64 上进行了测试. | v1 ☐ | [LORE RFC, 0000/2297](https://patchwork.kernel.org/project/kernel-hardening/patch/1495829844-69341-20-git-send-email-keescook@chromium.org)[LORE v2,](https://lore.kernel.org/lkml/Ydm7ReZWQPrbIugn@gmail.com), [LORE -v3, 0000/2300](https://lore.kernel.org/lkml/YjBr10JXLGHfEFfi@gmail.com) | +| 2022/01/02 | Ingo Molnar | ["Fast Kernel Headers" Tree -v1: Eliminate the Linux kernel's "Dependency Hell"](https://lore.kernel.org/lkml/YdIfz+LMewetSaEB@gmail.com) | "Fast Kernel Headers" 的补丁集, 新增 config 配置, CONFIG_FAST_HEADERS 和 CONFIG_KALLSYMS_FAST.
这个补丁集非常庞大, 包含了 2000+ 补丁, 这可能是内核有史以来代码量最大的一个功能. 但是效果也很不错.
1. 启用了 CONFIG_FAST_HEADERS 的内核每小时的内核构建次数可能比当前的库存内核多出 78%, 在支持的架构上, 绝对内核构建性能可以提高 50~80%.将许多高级标头与其他标头分离, 取消不相关的函数, 类型和 API 标头的分离, 头文件的自动依赖关系处理以及各种其他更改.
2. CONFIG_KALLSYMS_FAST 则实现了一个基于 objtool 的未压缩符号表功能, 它避免了 vmlinux 对象文件的通常三重链接, 这是增量内核构建的主要瓶颈. 由于即使使用 distro 配置, kallsyms 表也只有几十 MB 大, 因此在内核开发人员的桌面系统上, 内存成本是可以接受的. 不过当前只在 x86_64 下实现了此功能.
到目前为止, 这个庞大的补丁系列已经在 x86/x86_64, SPARC, MIPS 和 ARM64 上进行了测试. | v1 ☐ | [LORE RFC, 0000/2297](https://patchwork.kernel.org/project/kernel-hardening/patch/1495829844-69341-20-git-send-email-keescook@chromium.org)[LORE v2,](https://lore.kernel.org/lkml/Ydm7ReZWQPrbIugn@gmail.com), [LORE -v3, 0000/2300](https://lore.kernel.org/lkml/YjBr10JXLGHfEFfi@gmail.com) | 由于这组补丁如此庞大, 涉及的模块也如此多, 因此它不可能在短时间内合入, 因此 Ingo 决定先从调度入手, [Merge branch 'sched/fast-headers' into sched/core](https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=sched/core&id=ccacfe56d7ecdd2922256b87e9ea46f13bb03b55), 先行合并到 TIP 分支, 这些补丁将构建内核的调度程序部分所需的 CPU 时间减少了 60.9%. 挂钟时间下降了3.9%. 参见 [Linux Scheduler Build Improvements From "Fast Kernel Headers" Queued, FKH v3 Posted](https://www.phoronix.com/scan.php?page=news_item&px=Sched-Core-Fast-Kernel-Headers). @@ -533,6 +541,11 @@ Mold 是目前 Unix 链接器的现代替代品, 已经达到了 1.0 版本. 由 ## 14.5 OSNOISE & TimerLat ------- +OSNOISE & TimerLat Tracer 用于跟踪系统内部活动的噪音, 分析那些对业务应用可能造成性能干扰的因素. 是将 PREEMPT_RT 合入 mainline 的一部分工作. + +### 14.5.1 OSNOISE & TimerLat Tracer +------- + 在高性能计算 (HPC) 的上下文中, 操作系统噪声 (OSNOISE) 是指应用程序由于操作系统内部的活动而遭受的干扰. 在 Linux 的上下文中, NMI、IRQ、softirqs 和任何其他系统线程都可能对应用程序造成噪音. 此外, 与硬件相关的作业也会产生噪音, 例如, 通过 SMIs. 关心操作系统窃取的每一微秒的 HPC 用户和开发人员不仅需要一种精确的方法来测量 OSNOISE, 而且主要是找出谁在窃取 CPU 时间, 以便他们可以追求系统的完美调谐. 因此为 linux 内核设计了 [OSNOISE Tracer](https://docs.kernel.org/trace/OSNOISE-tracer.html) 来分析和发现干扰源. OSNOISE Tracer 运行内核内循环, 测量有多少时间可用. 它通过启用抢占, softirq 和 IRQ 来做到这一点, 从而在其执行期间允许所有 OSNOISE 源. @@ -546,6 +559,27 @@ Mold 是目前 Unix 链接器的现代替代品, 已经达到了 1.0 版本. 由 |:----:|:----:|:---:|:----:|:---------:|:----:| | 2021/06/22 | Daniel Bristot de Oliveira | [hwlat improvements and osnoise/timerlat tracers](https://patchwork.kernel.org/project/linux-trace-devel/patch/162936876189.187130.17558311387542061930.stgit@devnote2) | NA | v5 ☑ 5.14-rc1 | [Patchwork v5,09/14](https://lore.kernel.org/all/e649467042d60e7b62714c9c6751a56299d15119.1624372313.git.bristot@redhat.com), [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bce29ac9ce0bb0b0b146b687ab978378c21e9078) | | 2021/11/29 | Daniel Bristot de Oliveira | [osnoise: Support multiple instances (for RTLA)](https://patchwork.kernel.org/project/linux-trace-devel/patch/162936876189.187130.17558311387542061930.stgit@devnote2) | 为 osnoise/timerlat 跟踪器启用多个实例. 目前, osnoise 和 timerlat 仅在单个实例上运行. 为了减少这种限制, 本系列增加了对同一跟踪程序的并行实例的支持. 也就是说, 可以使用不同的跟踪配置运行 osnoise tracer 的两个实例. 例如, 一个仅用于跟踪器输出, 另一个用于跟踪器和一组跟踪点. 这个补丁集是 RTLA 的内核依赖项. 此修补程序集与 [RTLA](https://patchwork.kernel.org/project/linux-trace-devel/cover/cover.1638182284.git.bristot@kernel.org) 一起发送, 但我们将内核和用户空间修补程序集分开. | v9 ☑ 5.16-rc1 | [Patchwork V9,0/9](https://patchwork.kernel.org/project/linux-trace-devel/cover/cover.1635702894.git.bristot@kernel.org), [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2fac8d6486d5c34e2ec7028580142b8209da3f92) | + +### 14.5.2 New Real-Time Linux Analysis (RTLA) tool +------- + +在 OSNOISE & TimerLat Tracer 合入后, 开发者又向 linux 社区提交了一个用于实时性(噪音)分析的工具集(RTLA/Real-Time Linux Analysis), 它包含一组旨在分析 Linux 实时性的工具(命令). 它并没有将 Linux 作为一个黑盒进行测试, 而是利用内核 OSNOISE & TimerLat Tracer 提供关于意外结果的属性和根源的精确信息, 使用户和开发人员更容易收集性能和跟踪数据, 并帮助微调他们的系统或者算法. + + +参见作者 [Daniel's 关于 RTLA 的 Blog](https://bristot.me/and-now-linux-has-a-real-time-linux-analysis-rtla-tool), RTLA 可以理解为 OSNOISE & TimerLat TRACER 的用户界面, 提供了一个直观的界面来使用和处理数据. 对于那些不熟悉 PREEMPT_RT, 但是必须却想要评估内核实时性的开发人员来说, 这也是很有帮助的. + +比如通过如下命令: + +```cpp +rtla timerlat top-p f: 95-t 150-t trace_output.txt +``` + +用户可以得到高优先级任务所经历的延迟的信息(-pf: 95), 如果延迟高于150us (-t 150), 并且将带有调试信息的跟踪日志保存在 trace_output.txt 中. + +其他评估调度延迟的方法, 可以参照 [Demystifying the Real-Time Linux Scheduling Latency](https://bristot.me/demystifying-the-real-time-linux-latency). + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:----:|:---------:|:----:| | 2021/12/10 | Daniel Bristot de Oliveira | [RTLA: An interface for osnoise/timerlat tracers](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=5dce5904e3b9bc11d9635dd3458c7ff32caebb59) | [rtla](https://github.com/bristot/rtsl) 是一个旨在分析 Linux 实时属性的工具集. rtla 并没有将 Linux 作为一个黑盒来测试, 而是利用内核跟踪功能来提供关于属性和意外结果的根本原因的精确信息. 首先, 它提供了一个 osnoise 和 timerlat 示踪器的接口. 在未来, 它还将作为 rtsl 和其他延迟 / 噪声跟踪器的基础. V6 版本前五个补丁是 [osnoise: Support multiple instances](https://lore.kernel.org/lkml/cover.1628775552.git.bristot@kernel.org) 的重新发送, 它为 osnoise/timerlat 跟踪器启用多个实例. 接下来的七个补丁是 rtla, rtla osnoise 和 rtla timerlat. 后面的版本都将内核态和用户态拆开来提交. 参见 [Linux 5.17 Picks Up A Real-Time Analysis Tool](https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.17-RTLA) | v5 ☐ 5.17-rc1 | [2021/10/27 Patchwork v6,00/20](https://lore.kernel.org/lkml/cover.1635284863.git.bristot@kernel.org)
*-*-*-*-*-*-*-*
[2021/11/29 Patchwork v8,00/14](https://patchwork.kernel.org/project/linux-trace-devel/cover/cover.1638182284.git.bristot@kernel.org)
*-*-*-*-*-*-*-*
[LORE v9,00/14](https://lore.kernel.org/all/cover.1639158831.git.bristot@kernel.org) | diff --git a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md index cab7465..a4e6e19 100644 --- a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md +++ b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md @@ -306,12 +306,13 @@ Linux 一开始是在一台i386上的机器开发的, i386 的硬件页表是2 [Struct slab comes to 5.17](https://lwn.net/Articles/881039/) +受 Page Folio 启发的一个工作. slab 分配器使用的数据结构之前是内嵌在 struct page 中的, 将 struct slab 从 struct page 中分离出来. 与 struct folio 类似, 它总是一个 head page. 这带来了更好的类型安全性、将大型 kmalloc 分配与真正的 slab 分离以及清理. | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2022/01/04 | "Matthew Wilcox (Oracle)" | [Separate struct slab from struct page](https://patchwork.kernel.org/project/linux-mm/cover/20211004134650.4031813-1-willy@infradead.org) | struct page 结构定义中比较复杂的部分之一是 slab 分配器所使用的部分. 一般来说, 如果将 slab 的数据类型从 page 结构体中分离是有好处的, 而且它还有助于防止尾页滑落到任何地方. | v2 ☐ | [2021/07/15 PatchWork RFC,00/62](https://patchwork.kernel.org/project/linux-mm/cover/20211004134650.4031813-1-willy@infradead.org)
*-*-*-*-*-*-*-*
[2021/12/01 PatchWork v2,00/33](https://patchwork.kernel.org/project/linux-mm/cover/20211201181510.18784-1-vbabka@suse.cz)
*-*-*-*-*-*-*-*
[2022/01/04 PatchWork v4,00/32](https://patchwork.kernel.org/project/linux-mm/cover/20220104001046.12263-1-vbabka@suse.cz) | | 2021/10/12 | Johannes Weiner | [PageSlab: eliminate unnecessary compound_head() calls](https://patchwork.kernel.org/project/linux-mm/cover/20211012180148.1669685-1-hannes@cmpxchg.org) | 重构代码, 消除二义性, 使得代码更加简洁. PageSlab() 目前对所有调用站点施加一个 compound_head() 调用, 即使只有极少数情况会遇到尾页. 这组补丁气泡尾分辨率到少数需要它的网站, 并消除它在其他地方. 这个改动很独立, 它的灵感来自于 Willy 的补丁 Separate struct slab from struct page](https://patchwork.kernel.org/project/linux-mm/cover/20210715200030.899216-1-willy@infradead.org). 为了让逻辑更清晰, 代码更简洁. PageSlab() 的调用应该完全从对 compound_head() 的无限制调用中分离出来, 因为它们本身就有不必要的开销. | v1 ☐ | [PatchWork 00/11](https://patchwork.kernel.org/project/linux-mm/cover/20211012180148.1669685-1-hannes@cmpxchg.org), [LKML](https://lkml.org/lkml/2021/10/12/820) | -| 2022/01/04 | Vlastimil Babka | [Separate struct slab from struct page](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=07f910f9b7295b6a28b337fedb56e612684c5659) | NA | RFC ☑ [5.17-rc1](https://kernelnewbies.org/Linux_5.17#Memory_management) | [PatchWork RFC,00/32](https://patchwork.kernel.org/project/linux-mm/cover/20211116001628.24216-1-vbabka@suse.cz)
*-*-*-*-*-*-*-*
[PatchWork v4,00/32](https://patchwork.kernel.org/project/linux-mm/cover/20220104001046.12263-1-vbabka@suse.cz) | +| 2022/01/04 | Vlastimil Babka | [Separate struct slab from struct page](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=07f910f9b7295b6a28b337fedb56e612684c5659) | NA | v4 ☑ [5.17-rc1](https://kernelnewbies.org/Linux_5.17#Memory_management) | [PatchWork RFC,00/32](https://patchwork.kernel.org/project/linux-mm/cover/20211116001628.24216-1-vbabka@suse.cz)
*-*-*-*-*-*-*-*
[PatchWork v4,00/32](https://patchwork.kernel.org/project/linux-mm/cover/20220104001046.12263-1-vbabka@suse.cz) | ### 1.4.3 MEMCG Folio @@ -492,7 +493,8 @@ MADV_PAGEOUT 在某种程度上类似于 MADV_DONTNEED, 它提示内核当前不 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| -| 2022/01/26 | Pasha Tatashin | [Hardening page _refcount](https://patchwork.kernel.org/project/linux-mm/cover/20211026173822.502506-1-pasha.tatashin@soleen.com) | 目前很难从根本上解决 `_refcount` 问题, 因为它们通常在损坏发生后才会显现出来. 然而, 它们可能导致灾难性的故障, 如内存损坏.
通过添加更多的检查来提高可调试性, 确保 `page->_refcount` 永远不会变成负数(例如, 双空闲不发生, 或冻结后空闲等).
1. 增加了对 `_refcount` 异常值的检测.
2. 删除了 set_page_count(), 这样就不会无条件地用不受限制的值覆盖 `_refcount` | RFC,0/8 ☐ | [PatchWork RFC,0/8](https://patchwork.kernel.org/project/linux-mm/cover/20211026173822.502506-1-pasha.tatashin@soleen.com)
*-*-*-*-*-*-*-*
[PatchWork RFC,v2,00/10](https://patchwork.kernel.org/project/linux-mm/cover/20211117012059.141450-1-pasha.tatashin@soleen.com)
*-*-*-*-*-*-*-*
[PatchWork v2,0/9](https://patchwork.kernel.org/project/linux-mm/cover/20211221150140.988298-1-pasha.tatashin@soleen.com), [LORE v2,0/9](https://lore.kernel.org/all/20211221154650.1047963-1-pasha.tatashin@soleen.com)
*-*-*-*-*-*-*-*
[PatchWork v3,0/9](https://lore.kernel.org/r/20220126183429.1840447-1-pasha.tatashin@soleen.com) | +| 2022/01/26 | Pasha Tatashin | [Hardening page _refcount](https://patchwork.kernel.org/project/linux-mm/cover/20211026173822.502506-1-pasha.tatashin@soleen.com) | 目前很难从根本上解决 `_refcount` 问题, 因为它们通常在损坏发生后才会显现出来. 然而, 它们可能导致灾难性的故障, 如内存损坏.
通过添加更多的检查来提高可调试性, 确保 `page->_refcount` 永远不会变成负数(例如, 双空闲不发生, 或冻结后空闲等).
1. 增加了对 `_refcount` 异常值的检测.
2. 删除了 set_page_count(), 这样就不会无条件地用不受限制的值覆盖 `_refcount` | RFC,0/8 ☐ | [PatchWork RFC,0/8](https://patchwork.kernel.org/project/linux-mm/cover/20211026173822.502506-1-pasha.tatashin@soleen.com)
*-*-*-*-*-*-*-*
[PatchWork RFC,v2,00/10](https://patchwork.kernel.org/project/linux-mm/cover/20211117012059.141450-1-pasha.tatashin@soleen.com)
*-*-*-*-*-*-*-*
[PatchWork v2,0/9](https://patchwork.kernel.org/project/linux-mm/cover/20211221150140.988298-1-pasha.tatashin@soleen.com)
*-*-*-*-*-*-*-*
[PatchWork v3,0/9](https://lore.kernel.org/r/20220126183429.1840447-1-pasha.tatashin@soleen.com) | +| 2021/12/21 | Pasha Tatashin | [page table check](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d283d422c6c4f0264fe8ecf5ae80036bf73f4594) | NA | v3 ☐☑✓ | [LORE v3,0/4](https://lore.kernel.org/all/20211221154650.1047963-1-pasha.tatashin@soleen.com) | | 2022/04/21 | Tong Tiangen | [mm: page_table_check: add support on arm64 and riscv](https://patchwork.kernel.org/project/linux-mm/cover/20220317141203.3646253-1-tongtiangen@huawei.com) | 页面表检查通过将新页面的页面表条目(PTE, PMD 等)添加到表中, 在用户空间访问新页面时执行额外的验证 X86 支持它.
这个补丁集做了一些简单的更改, 使其更容易支持新的体系结构, 然后我们在 ARM64 和 RICV 上支持这个功能. | v1 ☐☑ | [LORE v1,0/4](https://lore.kernel.org/r/20220317141203.3646253-1-tongtiangen@huawei.com)
*-*-*-*-*-*-*-*
[LORE v2,0/4](https://lore.kernel.org/r/20220322144447.3563146-1-tongtiangen@huawei.com)
*-*-*-*-*-*-*-*
[LORE v4,0/4](https://lore.kernel.org/r/20220418034444.520928-1-tongtiangen@huawei.com)
*-*-*-*-*-*-*-*
[LORE v5,0/5](https://lore.kernel.org/r/20220421082042.1167967-1-tongtiangen@huawei.com) | ### 1.7.4 Local Page Tables @@ -894,7 +896,7 @@ NUMA 系统中 CPU 访问不同节点的内存速度很有大的差别. 位于 | 2017/04/11 | Vlastimil Babka | [cpuset/mempolicies related fixes and cleanups](https://lore.kernel.org/all/20170411140609.3787-1-vbabka@suse.cz) | 20170411140609.3787-1-vbabka@suse.cz | v1 ☐☑✓ | [LORE v1,0/6](https://lore.kernel.org/all/20170411140609.3787-1-vbabka@suse.cz) | | 2021/03/17 | Feng Tang | [Introduced multi-preference mempolicy](https://lore.kernel.org/all/1615952410-36895-1-git-send-email-feng.tang@intel.com) | 1615952410-36895-1-git-send-email-feng.tang@intel.com | v4 ☐☑✓ | [LORE v4,0/13](https://lore.kernel.org/all/1615952410-36895-1-git-send-email-feng.tang@intel.com) | | 2021/08/03 | Feng Tang | [Introduce multi-preference mempolicy](https://lore.kernel.org/patchwork/patch/1471473) | 参见 LWN 报道 [NUMA policy and memory types](https://lwn.net/Articles/862707).
引入 MPOL_PREFERRED_MANY 的 policy, 该 mempolicy 模式可用于 set_mempolicy 或 mbind 接口.
1. 与 MPOL_PREFERRED 模式一样, 它允许应用程序为满足内存分配请求的节点设置首选项. 但是与 MPOL_PREFERRED 模式不同, 它需要一组节点.
2. 与 MPOL_BIND 接口一样, 它在一组节点上工作, 与 MPOL_BIND 不同, 如果首选节点不可用, 它不会导致 SIGSEGV 或调用 OOM killer. | v7 ☑ 5.15-rc1 | [LORE v4,00/13](https://lore.kernel.org/lkml/1615952410-36895-1-git-send-email-feng.tang@intel.com)
*-*-*-*-*-*-*-*
[LORE v7,0/5](https://patchwork.kernel.org/project/linux-mm/cover/1627970362-61305-1-git-send-email-feng.tang@intel.com), [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/tools/perf/builtin-record.c?id=a38a59fdfa10be55d08e4530923d950e739ac6a2) | -| 2021/11/01 | "Aneesh Kumar K.V" | [mm: add new syscall set_mempolicy_home_node](https://patchwork.kernel.org/project/linux-mm/cover/20211101050206.549050-1-aneesh.kumar@linux.ibm.com) | 增加了 set_mempolicy_home_node() 来为用户空间的一段地址 [start, srart + len] 指定内存分配的主节点 home_node. 主节点 home_node 应与 MPOL_PREFERRED_MANY 或 MPOL_BIND 内存分配策略结合使用. 这些策略可以指定一组将用于新内存分配的节点, 但不能说明这些节点中的哪个节点(如果有)是首选节点. 如果设置了 home_node, 则分配内存时将优先在该节点上进行分配; 否则, 主节点 home_node 内存不足, 则将回退到有效策略允许的其他节点上分配, 首选最接近主节点的节点. 其目的是让应用程序能够更好地控制内存分配, 同时避免来自慢速节点的内存. 参见 LWN 报道 [Some upcoming memory-management patches](https://lwn.net/Articles/875587). | v1 ☐ | [PatchWork v4,0/3](https://patchwork.kernel.org/project/linux-mm/cover/20211101050206.549050-1-aneesh.kumar@linux.ibm.com) | +| 2021/11/01 | "Aneesh Kumar K.V" | [mm: add new syscall set_mempolicy_home_node](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=21b084fdf2a49ca1634e8e360e9ab6f9ff0dee11) | 增加了 set_mempolicy_home_node() 来为用户空间的一段地址 [start, srart + len] 指定内存分配的主节点 home_node. 主节点 home_node 应与 MPOL_PREFERRED_MANY 或 MPOL_BIND 内存分配策略结合使用. 这些策略可以指定一组将用于新内存分配的节点, 但不能说明这些节点中的哪个节点(如果有)是首选节点. 如果设置了 home_node, 则分配内存时将优先在该节点上进行分配; 否则, 主节点 home_node 内存不足, 则将回退到有效策略允许的其他节点上分配, 首选最接近主节点的节点. 其目的是让应用程序能够更好地控制内存分配, 同时避免来自慢速节点的内存. 参见 LWN 报道 [Some upcoming memory-management patches](https://lwn.net/Articles/875587). | v1 ☑✓ 5.17-rc1 | [PatchWork v4,0/3](https://patchwork.kernel.org/project/linux-mm/cover/20211101050206.549050-1-aneesh.kumar@linux.ibm.com) | | 2022/04/12 | Wei Yang | [mm/page_alloc: add same penalty is enough to get round-robin order](https://lore.kernel.org/all/20220412001319.7462-1-richard.weiyang@gmail.com) | 20220412001319.7462-1-richard.weiyang@gmail.com | v3 ☐☑✓ | [LORE](https://lore.kernel.org/all/20220412001319.7462-1-richard.weiyang@gmail.com) | @@ -1843,7 +1845,7 @@ vmalloc_to_page 则提供了通过 vmalloc 地址查找到对应 page 的操作. | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| -| 2021/10/25 | Alistair Popple | [extend vmalloc support for constrained allocations](https://patchwork.kernel.org/project/linux-mm/cover/20211018114712.9802-1-mhocko@kernel.org) | 第一个补丁为 vmalloc 实现 NOFS/NOIO支持. 第二个补丁增加了 NOFAIL 支持, 第三个补丁将所有支持打包到 kvmalloc 中, 并删除了现在可以直接使用 kvmalloc 的 ceph_kvmalloc. | v2 ☑ 4.13-rc1 | [2021/10/18 PatchWork RFC,0/3](https://patchwork.kernel.org/project/linux-mm/cover/20211018114712.9802-1-mhocko@kernel.org)
*-*-*-*-*-*-*-*
[2021/10/25 PatchWork 0/4](https://patchwork.kernel.org/project/linux-mm/cover/20211025150223.13621-1-mhocko@kernel.org) | +| 2021/11/22 | Alistair Popple | [extend vmalloc support for constrained allocations](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=a421ef303008b0ceee2cfc625c3246fa7654b0ca) | 扩展 vmalloc 对受限分配的支持.
第一个补丁为 vmalloc 实现 NOFS/NOIO支持. 第二个补丁增加了 NOFAIL 支持, 第三个补丁将所有支持打包到 kvmalloc 中, 并删除了现在可以直接使用 kvmalloc 的 ceph_kvmalloc. | v2 ☑ 5.17-rc1 | [2021/10/18 PatchWork RFC,0/3](https://patchwork.kernel.org/project/linux-mm/cover/20211018114712.9802-1-mhocko@kernel.org)
*-*-*-*-*-*-*-*
[2021/10/25 PatchWork 0/4](https://patchwork.kernel.org/project/linux-mm/cover/20211025150223.13621-1-mhocko@kernel.org)
*-*-*-*-*-*-*-*
[LORE v2,0/4](https://lore.kernel.org/all/20211122153233.9924-1-mhocko@kernel.org) | | 2022/01/19 | "Uladzislau Rezki (Sony)" | [mm/vmalloc: Move draining areas out of caller context](https://patchwork.kernel.org/project/linux-mm/patch/20220119143540.601149-1-urezki@gmail.com) | NA | v1 ☐ | [PatchWork 1/3](https://patchwork.kernel.org/project/linux-mm/patch/20220119143540.601149-1-urezki@gmail.com)
*-*-*-*-*-*-*-*
[PatchWork v3,0/1](https://lore.kernel.org/r/20220131144058.35608-1-urezki@gmail.com) | | 2022/01/27 | Christophe Leroy | [Allocate module text and data separately](https://patchwork.kernel.org/project/linux-mm/cover/cover.1643282353.git.christophe.leroy@csgroup.eu/) | 本系列允许架构将 module 的数据放在 vmalloc 区域而不是模块区域. 在 powerpc book3s/32 的机器上, 了设置数据非可执行性, 这是必需的, 因为不可能以页面为基础设置可执行性, 这是每256 mb的段执行一次. 模块区有 exec 权, vmalloc 区则没有. 没有这个更改模块, 即使开启了 CONFIG_STRICT_MODULES_RWX, 模块数据仍然是可执行的. 这在其他 powerpc/32 上也很有用, 可以最大限度地增加代码接近内核的机会, 从而避免使用 PLT 和 trampoline 等. | v2 ☐☑ | [PatchWork v2,0/5](https://lore.kernel.org/r/cover.1643282353.git.christophe.leroy@csgroup.eu)
*-*-*-*-*-*-*-*
[PatchWork v3,0/6](https://lore.kernel.org/r/cover.1643475473.git.christophe.leroy@csgroup.eu) | | 2022/03/08 | Paolo Bonzini | [mm: vmalloc: introduce array allocation functions](https://patchwork.kernel.org/project/linux-mm/cover/20220308105918.615575-1-pbonzini@redhat.com/) | 实现了四个数组分配函数来替换 vmalloc(array_size()) 和 vzalloc (array_size()), Linux 中当前有几十个这样的函数. 函数负责乘法和溢出检查, 特别混乱, 作者这样实现后这样代码更清晰, 并使开发人员更容易避免溢出错误. | v1 ☐☑ | [LORE v1,0/3](https://lore.kernel.org/r/20220308105918.615575-1-pbonzini@redhat.com) | @@ -4480,7 +4482,7 @@ HugeTLB CMA 在设计的时候, 已经考虑了 NUMA 的存在. |:----:|:----:|:---:|:----:|:---------:|:----:| | 2021/10/05 | Zhenguo Yao | [hugetlbfs: Extend the definition of hugepages parameter to support node allocation](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=b5389086ad7be0453c55e0069a89856d1fbdf605) | 当前内核允许指定启动时要分配的 hugepages 数目. 但目前所有节点的 hugepages 都是平衡的. 在某些场景中, 我们只需要在一个节点中使用 hugepags.
例如: DPDK 需要与 NIC 位于同一节点的 hugepages. 如果 DPDK 在 node1 中需要 4 个 1G 大小的 HugePage, 并且系统有 16 个 numa 节点. 我们必须在内核 cmdline 中保留 64 个 HugePage. 但是, 只使用了 4 个 hugepages. 其他的应该在引导后释放. 如果系统内存不足(例如: 64G), 这将是一项不可能完成的任务. 因此, 添加 hugepages_node 内核参数以指定启动时要分配的 hugepages 的节点数. | v1 ☑ 5.16-rc1 | [2021/08/20 PatchWork RFC](https://patchwork.kernel.org/project/linux-mm/patch/20210820030536.25737-1-yaozhenguo1@gmail.com)
*-*-*-*-*-*-*-*
[2021/08/23 PatchWork v1]](https://patchwork.kernel.org/project/linux-mm/patch/20210823130154.75070-1-yaozhenguo1@gmail.com)
*-*-*-*-*-*-*-*
[2021/10/05 PatchWork v8](https://patchwork.kernel.org/project/linux-mm/patch/20211005054729.86457-1-yaozhenguo1@gmail.com), [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b5389086ad7be0453c55e0069a89856d1fbdf605) | | 2021/10/15 | Baolin Wang | [hugetlb: Support node specified when using cma for gigantic hugepages](https://patchwork.kernel.org/project/linux-mm/patch/bb790775ca60bb8f4b26956bb3f6988f74e075c7.1634261144.git.baolin.wang@linux.alibaba.com) | 所有在线节点的 hugepages 运行时分配的 CMA 区域大小是平衡的, 但我们还希望指定每个节点的 CMA 大小, 或者在某些情况下仅指定一个节点, 这与 [hugetlb 的分 numa 节点指定大小](https://patchwork.kernel.org/project/linux-mm/patch/20211005054729.86457-1-yaozhenguo1@gmail.com)类似. | v3 ☐ | [2021/10/10 PatchWork v1](https://patchwork.kernel.org/project/linux-mm/patch/bb790775ca60bb8f4b26956bb3f6988f74e075c7.1634261144.git.baolin.wang@linux.alibaba.com)
*-*-*-*-*-*-*-*
[2021/10/15 PatchWork v3](https://patchwork.kernel.org/project/linux-mm/patch/bb790775ca60bb8f4b26956bb3f6988f74e075c7.1634261144.git.baolin.wang@linux.alibaba.com) | -| 2021/11/17 | Mina Almasry | [hugetlb: Add `hugetlb.*.numa_stat` file](https://patchwork.kernel.org/project/linux-mm/patch/20211019215437.2348421-1-almasrymina@google.com) | 添加 `hugetlb.*.numa_stat`, 它显示 hugetlb 在 cgroup 的 numa 使用信息. 类似于 memory.numa_stat. | v7 ☐ | [PatchWork v1](https://patchwork.kernel.org/project/linux-mm/patch/20211019215437.2348421-1-almasrymina@google.com)
*-*-*-*-*-*-*-*
[PatchWork v2](https://patchwork.kernel.org/project/linux-mm/patch/20211020190952.2658759-1-almasrymina@google.com)
*-*-*-*-*-*-*-*
[PatchWork v7](https://patchwork.kernel.org/project/linux-mm/patch/20211117201825.429650-1-almasrymina@google.com) | +| 2021/11/17 | Mina Almasry | [hugetlb: Add `hugetlb.*.numa_stat` file](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f47761999052b1cc987dd3e3d3adf47997358fc0) | 添加 `hugetlb.*.numa_stat`, 它显示 hugetlb 在 cgroup 的 numa 使用信息. 类似于 memory.numa_stat. | v8 ☑ 5.17-rc1 | [PatchWork v1](https://patchwork.kernel.org/project/linux-mm/patch/20211019215437.2348421-1-almasrymina@google.com)
*-*-*-*-*-*-*-*
[PatchWork v2](https://patchwork.kernel.org/project/linux-mm/patch/20211020190952.2658759-1-almasrymina@google.com)
*-*-*-*-*-*-*-*
[PatchWork v7](https://patchwork.kernel.org/project/linux-mm/patch/20211117201825.429650-1-almasrymina@google.com)
*-*-*-*-*-*-*-*
[LORE v8](https://lore.kernel.org/all/20211123001020.4083653-1-almasrymina@google.com) | ### 7.1.8 代码段大页 @@ -4977,8 +4979,6 @@ khugepaged 处理流程 ### 8.1.1 具名匿名页 Anonymous VMA naming ------- -参见 LWN 报道 [Not-so-anonymous virtual memory areas](https://lwn.net/Articles/867818) - 用户空间进程通常有多个分配器, 每个分配器执行匿名 MMAP 以获取内存. 在整体检查单个进程或系统的内存使用情况时, 如果能够分解每个层分配的各种堆并检查它们的大小、RSS和物理内存使用情况对分析内核的内存分配和管理非常有用. 因此内核开发者提出匿名 VMA 命名方案, 可以有效地对进程不同名称的 VMA 的进行统计, 比较和区分. 以前有很多匿名VMA 命名的尝试. @@ -4987,7 +4987,10 @@ khugepaged 处理流程 后续 Sumit Semwal 发现这组补丁并没有被主线接受, 而一个非常相似的补丁已经存在 Android 中用于命名匿名 vma 很多年了, 参见 [ANDROID: mm: add a field to store names for private anonymous memory](https://github.com/aosp-mirror/kernel_common/commit/533e4ed309748abb89ae53548af7afe1649ac48a). 因此他[接替了 Colin Cross 的工作, 并继续发到了 v7 版本](https://lore.kernel.org/linux-mm/20200901161459.11772-1-sumit.semwal@linaro.org), [Kees Cook](https://lore.kernel.org/linux-mm/5d0358ab-8c47-2f5f-8e43-23b89d6a8e95@intel.com/) 对这个补丁提出了担忧, 他注意到这个补丁缺少字符串清理功能, 并且使用了来自内核的用户空间指针. 社区建议 strndup_user() 来自 userspace 的字符串, 执行适当的检查并将副本存储为 vm_area_struct 成员. fork() 期间额外 strdup() 的性能影响应该通过分配大量(64k)具有最长名称和定时 fork() 的 vma 来衡量. -接着, Suren Baghdasaryan 继续着这项工作. 实现了社区之间的 review 意见, 并优化了简单的重计数, 以避免在 fork() 期间 strdup() 名称所带来的性能开销. +接着, Suren Baghdasaryan 继续着这项工作. 实现了社区之间的 review 意见, 并优化了简单的重计数, 以避免在 fork() 期间 strdup() 名称所带来的性能开销. 最终于 v5.17 合入主线. 参见 LWN 报道 [Not-so-anonymous virtual memory areas](https://lwn.net/Articles/867818). + +使用 CONFIG_ANON_VMA_NAME 开启这个功能. [用户空间](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9a10064f5625d5572c3626c1516e0bebc6c9fe9b)可以通过调用 [prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, start, len, (unsigned long) name) 来设置内存区域的名称](https://elixir.bootlin.com/linux/v5.17/source/kernel/sys.c#L2294). 使用 struct anon_vma_name 记录具名匿名页的名字, 记录在 [struct vm_area_struct->anon_name](https://elixir.bootlin.com/linux/v5.17/source/include/linux/mm_types.h#L423) 中. [其次](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9a10064f5625d5572c3626c1516e0bebc6c9fe9b)在 `/proc/pid/maps` 和 `/proc/pid/smaps` 中添加一个[字段](https://elixir.bootlin.com/linux/v5.17/source/fs/proc/task_mmu.c#L333), 以显示用户空间为匿名 vmas 提供的名称. 已命名匿名 vmas 的名称显示为 `[anon:anon_name]`. + | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| @@ -6101,9 +6104,11 @@ ARM 引入了一个[内存标签扩展](https://community.arm.com/developer/ip-p [An introduction to lockless algorithms](https://lwn.net/Articles/844224) +[Detecting missing memory barriers with KCSAN](https://lwn.net/Articles/877200) + | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| -| 2021/11/30 | Andrey Konovalov | [kcsan: Support detecting a subset of missing memory barriers](https://lwn.net/Articles/877200) | KCSAN 增加对 LKMM 定义的弱内存子集建模的支持, 它支持检测由于丢失内存障碍而导致的数据竞争子集.
当内存操作的结果应该由 barrier 来排序时, KCSAN 可以检测数据竞争, 在这种情况下, 冲突只发生在由于重新排序访问而丢失 barrier 的情况下.
KCSAN 检测内存障碍缺失的方法是基于对访问重新排序的建模, 设置了观察点检测对每个内存访问, 也选择在其功能范围内进行模拟重排序. 由于运行时不能"预取"访问, 我们只能对延迟访问效果进行建模, 一旦选择了某个访问进行重新排序, 就会在每次其他访问中检查它, 直到函数范围结束. 如果遇到适当的内存障碍, 访问将不再考虑重新排序. | v3 ☐ | [2021/10/05 PatchWork 00/23](https://patchwork.kernel.org/project/linux-mm/cover/20211005105905.1994700-1-elver@google.com)
*-*-*-*-*-*-*-*
[2021/11/18 PatchWork v2,00/23](https://patchwork.kernel.org/project/linux-mm/cover/20211118081027.3175699-1-elver@google.com)
*-*-*-*-*-*-*-*
[2021/11/30 PatchWork v3,00/25](https://patchwork.kernel.org/project/linux-mm/cover/20211130114433.2580590-1-elver@google.com) | +| 2021/11/30 | Andrey Konovalov | [kcsan: Support detecting a subset of missing memory barriers](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=bd3d5bd1a0ad386475ea7a3de8a91e7d8a600536) | KCSAN 增加对 LKMM 定义的弱内存子集建模的支持, 它支持检测由于丢失内存障碍而导致的数据竞争子集.
当内存操作的结果应该由 barrier 来排序时, KCSAN 可以检测数据竞争, 在这种情况下, 冲突只发生在由于重新排序访问而丢失 barrier 的情况下.
KCSAN 检测内存障碍缺失的方法是基于对访问重新排序的建模, 设置了观察点检测对每个内存访问, 也选择在其功能范围内进行模拟重排序. 由于运行时不能"预取"访问, 我们只能对延迟访问效果进行建模, 一旦选择了某个访问进行重新排序, 就会在每次其他访问中检查它, 直到函数范围结束. 如果遇到适当的内存障碍, 访问将不再考虑重新排序. | v3 ☑ 5.17-rc1 | [2021/10/05 PatchWork 00/23](https://patchwork.kernel.org/project/linux-mm/cover/20211005105905.1994700-1-elver@google.com)
*-*-*-*-*-*-*-*
[2021/11/18 PatchWork v2,00/23](https://patchwork.kernel.org/project/linux-mm/cover/20211118081027.3175699-1-elver@google.com)
*-*-*-*-*-*-*-*
[2021/11/30 PatchWork v3,00/25](https://patchwork.kernel.org/project/linux-mm/cover/20211130114433.2580590-1-elver@google.com)
*-*-*-*-*-*-*-*
[2021/12/24 LORE kcsan for 5.17, 00/29](https://lore.kernel.org/all/20211214220356.GA2236323@paulmck-ThinkPad-P17-Gen-1) | ### 13.3.6 KMSAN ------- @@ -6268,6 +6273,9 @@ DAMON 利用两个核心机制 : **基于区域的采样**和**自适应区域 | 2022/03/15 | Xin Hao | [mm/damon: Add CMA minotor support](https://patchwork.kernel.org/project/linux-mm/cover/cover.1647378112.git.xhao@linux.alibaba.com/) | 为 DAMON 增加 CMA 内存监控功能. 在某些内存紧张的情况下, 通过监控 CMA 内存释放更多内存将是一个不错的选择. | v1 ☐☑ | [LORE v1,0/3](https://lore.kernel.org/r/cover.1647378112.git.xhao@linux.alibaba.com) | | 2021/01/07 | SeongJae Park | [tools/perf: Integrate DAMON in perf](https://lore.kernel.org/all/20210107120729.22328-1-sjpark@amazon.com) | perf 支持 DAMON 监控. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20210107120729.22328-1-sjpark@amazon.com) | | 2022/04/18 | Yuanchu Xie | [[RESEND] selftests/damon: add damon to selftests root Makefile](https://patchwork.kernel.org/project/linux-mm/patch/20220418202017.3583638-1-yuanchu@google.com/) | 633136 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220418202017.3583638-1-yuanchu@google.com) | +| 2021/12/10 | SeongJae Park | [mm/damon/schemes: Extend stats for better online analysis and tuning](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=dbcb9b9f954f71fb46be34af624c9edaaa171414) | 20211210150016.35349-1-sj@kernel.org | v1 ☑✓ 5.17-rc1 | [LORE v1,0/6](https://lore.kernel.org/all/20211210150016.35349-1-sj@kernel.org) | +| 2022/01/14 | Baolin Wang | [mm/damon: add access checking for hugetlb pages](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49f4203aae06ba9d67b500c90339b262b0a52637) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/6afcbd1fda5f9c7c24f320d26a98188c727ceec3.1639623751.git.baolin.wang@linux.alibaba.com), [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49f4203aae06ba9d67b500c90339b262b0a52637) | + ### 13.4.5 vmstat ------- @@ -6275,7 +6283,7 @@ DAMON 利用两个核心机制 : **基于区域的采样**和**自适应区域 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2021/08/05 | Mel Gorman | [Protect vmstats on PREEMPT_RT](https://lore.kernel.org/patchwork/patch/1472709) | NA | v2 ☐ | [PatchWork 0/1,v2](https://patchwork.kernel.org/project/linux-mm/cover/20210723100034.13353-1-mgorman@techsingularity.net) | -| 2021/12/22 | Shakeel Butt | [memcg: add per-memcg vmalloc stat](https://patchwork.kernel.org/project/linux-mm/patch/20211221215336.1922823-1-shakeelb@google.com) | NA | v1 ☐ | [PatchWork v1](https://patchwork.kernel.org/project/linux-mm/patch/20211221215336.1922823-1-shakeelb@google.com)
*-*-*-*-*-*-*-*
[PatchWork v2](https://patchwork.kernel.org/project/linux-mm/patch/20211222052457.1960701-1-shakeelb@google.com) | +| 2021/12/22 | Shakeel Butt | [memcg: add per-memcg vmalloc stat](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4e5aa1f4c2b489bc6f3ab5ca54747b18a847289d) | NA | v1 ☑✓ 5.17-rc1 | [PatchWork v1](https://patchwork.kernel.org/project/linux-mm/patch/20211221215336.1922823-1-shakeelb@google.com)
*-*-*-*-*-*-*-*
[PatchWork v2](https://patchwork.kernel.org/project/linux-mm/patch/20211222052457.1960701-1-shakeelb@google.com) | ### 13.4.6 meminfo @@ -6540,8 +6548,8 @@ DAMON 利用两个核心机制 : **基于区域的采样**和**自适应区域 | 2014/05/06 | David Rientjes | [mm, migration: add destination page freeing callback](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=aeef4b83806f49a0c454b7d4578671b71045bee2) | alpine.DEB.2.02.1405070336200.16568@chino.kir.corp.google.com | v4 ☑✓ 3.16-rc1 | [LORE 1/2](https://lore.kernel.org/all/alpine.DEB.2.02.1404301744110.8415@chino.kir.corp.google.com)
*-*-*-*-*-*-*-*
[LORE v4,0/6](https://lore.kernel.org/all/alpine.DEB.2.02.1405061920470.18635@chino.kir.corp.google.com) | | 2021/08/05 | Christoph Lameter | [Some cleanup for page migration](https://lore.kernel.org/patchwork/patch/1472581) | NA | v1 ☐ | [PatchWork 0/5](https://lore.kernel.org/patchwork/patch/49754) | | 2021/09/22 | John Hubbard | [mm/migrate: de-duplicate migrate_reason strings](https://patchwork.kernel.org/project/linux-mm/patch/20210922041755.141817-2-jhubbard@nvidia.com/) | NA | v1 ☐ | [PatchWork 0/5](https://patchwork.kernel.org/project/linux-mm/patch/20210922041755.141817-2-jhubbard@nvidia.com/) | -| 2021/11/03 | Baolin Wang | [Improve the migration stats](https://patchwork.kernel.org/project/linux-mm/cover/cover.1635936218.git.baolin.wang@linux.alibaba.com) | 根据与 [Zi Yan](https://lore.kernel.org/linux-mm/7E44019D-2A5D-4BA7-B4D5-00D4712F1687@nvidia.com) 的谈话, 这个补丁集改变了 migrate_pages() 的返回值, 以避免返回的数字大于用户通过 move_pages() 系统调用尝试迁移的页面数. 还修复了 trace_mm_compaction_migratepages() 中的 hugetlb 迁移统计和迁移统计. | v1 ☐ | [PatchWork](https://lore.kernel.org/linux-mm/b35e54802a9a82d03d24845b463e9d9a68f7fd6b.1635491660.git.baolin.wang@linux.alibaba.com)
*-*-*-*-*-*-*-*
[PatchWork RFC,0/3](https://patchwork.kernel.org/project/linux-mm/cover/cover.1635936218.git.baolin.wang@linux.alibaba.com) | -| 2021/11/11 | Baolin Wang | [Support multiple target nodes demotion](https://patchwork.kernel.org/project/linux-mm/cover/cover.1636616548.git.baolin.wang@linux.alibaba.com) | 对于同时有1个快速(DRAM)内存节点和多个慢速(持久内存)内存节点的系统, 根据当前节点降级策略不感知节点之间的距离, 速度和带宽等. 该补丁修改了 node_demotion 数据结构, 以支持多个目标节点, 并建立迁移路径以支持多个目标节点验证节点距离是否是最好的. | v1 ☐ | [PatchWork v1](https://patchwork.kernel.org/project/linux-mm/patch/8850612186ea23eb5d328d84e4008a6b60f418e1.1636514506.git.baolin.wang@linux.alibaba.com)
*-*-*-*-*-*-*-*
[PatchWork v2](https://patchwork.kernel.org/project/linux-mm/patch/f6d68800ff2efcb0720599ae092d30765a640232.1636428988.git.baolin.wang@linux.alibaba.com)
*-*-*-*-*-*-*-*
[PatchWork v2,0/2](hhttps://patchwork.kernel.org/project/linux-mm/cover/cover.1636616548.git.baolin.wang@linux.alibaba.com)
*-*-*-*-*-*-*-*
[PatchWork v3](https://patchwork.kernel.org/project/linux-mm/patch/a31dc065a7901bcdca0d9642d0def0f57e865e20.1636683991.git.baolin.wang@linux.alibaba.com) | +| 2021/11/03 | Baolin Wang | [Improve the migration stats](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=84b328aa81216e08804d8875d63f26bda1298788) | 根据与 [Zi Yan](https://lore.kernel.org/linux-mm/7E44019D-2A5D-4BA7-B4D5-00D4712F1687@nvidia.com) 的谈话, 这个补丁集改变了 migrate_pages() 的返回值, 以避免返回的数字大于用户通过 move_pages() 系统调用尝试迁移的页面数. 还修复了 trace_mm_compaction_migratepages() 中的 hugetlb 迁移统计和迁移统计. | v1 ☑✓ 5.17-rc1 | [PatchWork](https://lore.kernel.org/linux-mm/b35e54802a9a82d03d24845b463e9d9a68f7fd6b.1635491660.git.baolin.wang@linux.alibaba.com)
*-*-*-*-*-*-*-*
[PatchWork RFC,0/3](https://patchwork.kernel.org/project/linux-mm/cover/cover.1635936218.git.baolin.wang@linux.alibaba.com)
*-*-*-*-*-*-*-*
[LORE v1,0/3](https://lore.kernel.org/all/cover.1636275127.git.baolin.wang@linux.alibaba.com) | +| 2021/11/11 | Baolin Wang | [Support multiple target nodes demotion](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ac16ec835314677dd7405dfb5a5e007c3ca424c7) | 对于同时有1个快速(DRAM)内存节点和多个慢速(持久内存)内存节点的系统, 根据当前节点降级策略不感知节点之间的距离, 速度和带宽等. 该补丁修改了 node_demotion 数据结构, 以支持多个目标节点, 并建立迁移路径以支持多个目标节点验证节点距离是否是最好的. | v1 ☑✓ 5.17-rc1 | [PatchWork v1](https://patchwork.kernel.org/project/linux-mm/patch/8850612186ea23eb5d328d84e4008a6b60f418e1.1636514506.git.baolin.wang@linux.alibaba.com)
*-*-*-*-*-*-*-*
[PatchWork v2](https://patchwork.kernel.org/project/linux-mm/patch/f6d68800ff2efcb0720599ae092d30765a640232.1636428988.git.baolin.wang@linux.alibaba.com)
*-*-*-*-*-*-*-*
[PatchWork v2,0/2](hhttps://patchwork.kernel.org/project/linux-mm/cover/cover.1636616548.git.baolin.wang@linux.alibaba.com)
*-*-*-*-*-*-*-*
[PatchWork v3](https://patchwork.kernel.org/project/linux-mm/patch/a31dc065a7901bcdca0d9642d0def0f57e865e20.1636683991.git.baolin.wang@linux.alibaba.com)
*-*-*-*-*-*-*-*
[LORE v4](https://lore.kernel.org/all/00728da107789bb4ed9e0d28b1d08fd8056af2ef.1636697263.git.baolin.wang@linux.alibaba.com) | | 2022/01/28 | Anshuman Khandual | [mm/migration: Add trace events](https://patchwork.kernel.org/project/linux-mm/cover/1643368182-9588-1-git-send-email-anshuman.khandual@arm.com) | 增加进程迁移的 tracepoint. | v3 ☐ | [PatchWork V3,0/2](https://patchwork.kernel.org/project/linux-mm/cover/1643368182-9588-1-git-send-email-anshuman.khandual@arm.com) | diff --git a/study/kernel/00-DESCRIPTION/SCHEDULER.md b/study/kernel/00-DESCRIPTION/SCHEDULER.md index 87cd4b2..a99c862 100644 --- a/study/kernel/00-DESCRIPTION/SCHEDULER.md +++ b/study/kernel/00-DESCRIPTION/SCHEDULER.md @@ -2602,7 +2602,8 @@ ARM & Linaro 的内核团队针对 Android/linux 等做了大量的调度的优 -### 12.5.1 调度器延迟基准测试 +### 12.4.1 调度器延迟基准测试 +------- | benchmark | 描述 | 测试目的 | |:---------:|:---:|:-------:| @@ -2611,6 +2612,14 @@ ARM & Linaro 的内核团队针对 Android/linux 等做了大量的调度的优 | [adrestia](https://github.com/mfleming/adrestia) | 更简单的调度器唤醒延迟微基准测试, hackbench 等进行 pipe 测试往往都经过了 futex 路径. 因此 [Matt Fleming](https://www.codeblueprint.co.uk) 在 2016 年编写了此 benchmark, 以便通过在唤醒路径中覆盖测试到不同的路径. 同时提供了第 95 百分位唤醒延迟值. | 第 95 百分位唤醒延迟值 | | [unixbench/context1]() | NA | NA | +### 12.4.2 调度器延迟分析 +------- + + +ECRTS 2020(32nd Euromicro Conference on Real-Time Systems) 上 Daniel 等人发表了论文 [Demystifying the Real-Time Linux Scheduling Latency](https://bristot.me/demystifying-the-real-time-linux-latency). 他们源代码开源在 Github [bristot/rtsl, Real-Time Linux Scheduling Latency](https://github.com/bristot/rtsl). 更多详细的信息可以参考 [Daniel's Blog, Demystifying the Real-Time Linux Scheduling Latency](https://bristot.me/demystifying-the-real-time-linux-latency). + +随后 2022 年, Daniel 等人开发了 OSNOISE & TimerLat Tracer 用于跟踪系统内部活动的噪音, 分析那些对业务应用可能造成性能干扰的因素. 这些 TRACER 于 v5.14 合入. 是 PREEMPT_RT 合入 mainline 的一部分工作. 随后 v5.17 提供了 RTLA 作为基于 OSNOISE & TimerLat Tracer 数据分析的工具集用于分析和测试系统的实时性. 参见 [And now Linux has a Real-Time Linux Analysis (RTLA) tool!](https://bristot.me/and-now-linux-has-a-real-time-linux-analysis-rtla-tool) + **引用: **