From 78bc1875e58a0cf09cc24ebec4e2fde67aef4f38 Mon Sep 17 00:00:00 2001 From: Cheng Jian Date: Sun, 25 Sep 2022 16:14:13 +0800 Subject: [PATCH] description/open_source: update phoronix to date 20220925 --- study/kernel/00-DESCRIPTION/ARCH.md | 2 +- study/kernel/00-DESCRIPTION/BPF.md | 15 +++ study/kernel/00-DESCRIPTION/DEBUGGING.md | 10 +- study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md | 91 ++++++++++++++++--- study/kernel/00-DESCRIPTION/SCHEDULER.md | 87 +++++++++++++++++- study/kernel/00-DESCRIPTION/VIRT.md | 11 +++ 6 files changed, 196 insertions(+), 20 deletions(-) diff --git a/study/kernel/00-DESCRIPTION/ARCH.md b/study/kernel/00-DESCRIPTION/ARCH.md index 053b737..9473dcd 100644 --- a/study/kernel/00-DESCRIPTION/ARCH.md +++ b/study/kernel/00-DESCRIPTION/ARCH.md @@ -496,7 +496,7 @@ TLB entry shootdown 常常或多或少的带来一些性能问题. | 2015/07/06 | Mel Gorman | [TLB flush multiple pages per IPI v7](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=c7e1e3ccfbd153c890240a391f258efaedfa94d0) | BATCHED_UNMAP_TLB_FLUSH 完成了 TLB 批处理, 在批量解除页面映射后, 发送一个 IPI 来刷新多个 TLB range 的条目, 而不是每个 TLB entry 刷新都发送一个 IPI. | v7 ☑✓ 4.3-rc1 | [LORE v5,0/3](https://lore.kernel.org/all/1433767854-24408-1-git-send-email-mgorman@suse.de)
*-*-*-*-*-*-*-*
[LORE v7,0/4](https://lore.kernel.org/all/1436189996-7220-1-git-send-email-mgorman@suse.de) | | 2017/05/07 | Andy Lutomirski | [x86 TLB flush cleanups, moving toward PCID support](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=d6e41f1151feeb118eee776c09323aceb4a415d9) | TODO | v1 ☑✓ 4.13-rc1 | [LORE v1,0/10](https://lore.kernel.org/all/cover.1494160201.git.luto@kernel.org) | | 2021/02/23 | Barry Song | [Documentation/features: mark BATCHED_UNMAP_TLB_FLUSH doesn't apply to ARM64](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6bfef171d0d74cb050112e0e49feb20bfddf7f42) | 在 x86 上, BATCHED_UNMAP_TLB_FLUSH 用于批处理 TLB, 在解除页面映射后, 发送一个 IPI 到 TLB 刷新所有条目. 在 arm64 上, TLB shootdown 是由硬件完成的. 刷新指令是内部共享的. 本地刷新限制在启动(每个 CPU 1 次)和任务获得新的 ASID 时. 因此, 将该特性标记为 "TODO" 是不恰当的. 所以这个补丁对某些架构上不需要的这类功能标记为 "N/A". | v1 ☑✓ 5.13-rc1 | [LORE](https://lore.kernel.org/all/20210223003230.11976-1-song.bao.hua@hisilicon.com) | -| 2022/07/11 | Barry Song <21cnbao@gmail.com> | [mm: arm64: bring up BATCHED_UNMAP_TLB_FLUSH](https://lore.kernel.org/all/20220711034615.482895-1-21cnbao@gmail.com) | 虽然 ARM64 有硬件来完成 TLB shootdown, 但硬件广播的开销并不小. 最简单的微基准测试表明, 即使在只有 8 核的 snapdragon 888 上, ptep_clear_flush() 的开销也是巨大的, 即使只分页一个进程映射的一个页面, perf top 显示这造成 5.36% 的 CPU 消耗. 当页面由多个进程映射或硬件有更多 CPU 时, 由于 TLB 分解的可扩展性较差, 成本应该会更高. 在这种场景下同样的基准测试可能会导致大约 100 核的 ARM64 服务器上 16.99% 的 CPU 消耗. 该补丁集利用了现有的 BATCHED_UNMAP_TLB_FLUSH 进行了优化.
1. 仅在第一阶段 arch_tlbbatch_add_mm() 中发送 tlbi 指令.
2. 等待 dsb 完成 tlbi, 同时在 arch_tlbbatch_flush() 中执行 tlbbatch sync. 在 snapdragon 上的测试表明, ptep_clear_flush() 的开销已被该补丁集优化掉. 即使在 snapdragon 888 上通过单个进程映射一个页面, 微基准也能提升 5% 的性能. | v2 ☐☑✓ | [LORE v1,0/4](https://lore.kernel.org/lkml/20220707125242.425242-1-21cnbao@gmail.com)
*-*-*-*-*-*-*-*
[LORE v2,0/4](https://lore.kernel.org/all/20220711034615.482895-1-21cnbao@gmail.com) | +| 2022/07/11 | Barry Song <21cnbao@gmail.com> | [mm: arm64: bring up BATCHED_UNMAP_TLB_FLUSH](https://lore.kernel.org/all/20220711034615.482895-1-21cnbao@gmail.com) | 虽然 ARM64 有硬件来完成 TLB shootdown, 但硬件广播的开销并不小. 最简单的微基准测试表明, 即使在只有 8 核的 snapdragon 888 上, ptep_clear_flush() 的开销也是巨大的, 即使只分页一个进程映射的一个页面, perf top 显示这造成 5.36% 的 CPU 消耗. 当页面由多个进程映射或硬件有更多 CPU 时, 由于 TLB 分解的可扩展性较差, 成本应该会更高. 在这种场景下同样的基准测试可能会导致大约 100 核的 ARM64 服务器上 16.99% 的 CPU 消耗. 该补丁集利用了现有的 BATCHED_UNMAP_TLB_FLUSH 进行了优化.
1. 仅在第一阶段 arch_tlbbatch_add_mm() 中发送 tlbi 指令.
2. 等待 dsb 完成 tlbi, 同时在 arch_tlbbatch_flush() 中执行 tlbbatch sync. 在 snapdragon 上的测试表明, ptep_clear_flush() 的开销已被该补丁集优化掉. 即使在 snapdragon 888 上通过单个进程映射一个页面, 微基准也能提升 5% 的性能. | v2 ☐☑✓ | [LORE v1,0/4](https://lore.kernel.org/lkml/20220707125242.425242-1-21cnbao@gmail.com)
*-*-*-*-*-*-*-*
[LORE v2,0/4](https://lore.kernel.org/all/20220711034615.482895-1-21cnbao@gmail.com)
*-*-*-*-*-*-*-*
[LORE v3,0/4](https://lore.kernel.org/r/20220822082120.8347-1-yangyicong@huawei.com)
*-*-*-*-*-*-*-*
[LORE v4,0/2](https://lore.kernel.org/r/20220921084302.43631-1-yangyicong@huawei.com) | ### 2.2.5 relaxed TLB flushes ------- diff --git a/study/kernel/00-DESCRIPTION/BPF.md b/study/kernel/00-DESCRIPTION/BPF.md index 5259ce5..b67215b 100644 --- a/study/kernel/00-DESCRIPTION/BPF.md +++ b/study/kernel/00-DESCRIPTION/BPF.md @@ -479,6 +479,21 @@ glcc 则实现了 eBPF 驱动和 libbpf 的支持, 允许 eBPF 程序无需修 [bcc/ebpf 安装及示例（2019）](http://arthurchiao.art/blog/bcc-ebpf-tutorial-zh) + +# 9 WASM(WebAssembly) +------- + +[WebAssembly 中文网|Wasm 中文文档](https://www.wasm.com.cn) + +## 9.1 Wasmtime +------- + +2019 年, 英特尔、Mozilla 和红帽就启动了字节码联盟, 作为一项旨在促进"无处不在"运行 WebAssembly, 并将 WASM 的范围扩展到 Web 浏览器之外的倡议. 开发三年后(2022 年), WebAssembly 运行时 Wasmtime 1.0 发布了. 参见 phoronix 报道 [Wasmtime 1.0 Released - Bytecode Alliance Declares It Production Ready](https://www.phoronix.com/news/Wasmtime-1.0-Released). + + +Wasmtime 完全开源, 使用 Rust 编程语言, 是的, 并且符合 WASI 标准. Wasmtime还支持与 C/C++, Python, .NET, Go 和其他编程语言的集成, 同时在 Windows / Linux / macOS 平台上运行等等. + +
* 本作品/博文 ( [AderStep-紫夜阑珊-青伶巷草 Copyright ©2013-2017](http://blog.csdn.net/gatieme) ), 由 [成坚(gatieme)](http://blog.csdn.net/gatieme) 创作. diff --git a/study/kernel/00-DESCRIPTION/DEBUGGING.md b/study/kernel/00-DESCRIPTION/DEBUGGING.md index b494f1b..b481ea2 100644 --- a/study/kernel/00-DESCRIPTION/DEBUGGING.md +++ b/study/kernel/00-DESCRIPTION/DEBUGGING.md @@ -125,6 +125,9 @@ https://lwn.net/Articles/422487/ | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2009/08/05 | Arjan van de Ven | [Implement crashkernel=auto](https://lore.kernel.org/patchwork/cover/166256) | 实现 crashkernel=auto . | v1 ☐ | [PatchWork](https://lore.kernel.org/patchwork/cover/166256) | +| 2022/08/28 | Baoquan He | [arm64, kdump: enforce to take 4G as the crashkernel low memory end](https://patchwork.kernel.org/project/linux-mm/cover/20220828005545.94389-1-bhe@redhat.com/) | 671768 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/20220828005545.94389-1-bhe@redhat.com) | + +[crash extension modules](https://crash-utility.github.io/extensions.html) # 5 REFCOUNT @@ -166,14 +169,13 @@ Load Averages 是一项历史悠久的指标, 在 1973 年 8 月的 RFC 546 中 ## 6.3 memory vmpressure ------- - - | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2018/08/28 | Johannes Weiner | [psi: pressure stall information for CPU, memory, and IO v4](https://lwn.net/Articles/759781) | 引入 PSI 评估系统 CPU, MEMORY, IO 等资源的压力. | v4 ☑ [4.20-rc1](https://kernelnewbies.org/Linux_4.20#Core_.28various.29) | [LWN](https://lwn.net/Articles/544652), [](https://lkml.org/lkml/2013/2/10/140), [关键 commit](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=70ddf637eebe47e61fb2be08a59315581b6d2f38) | | 2022/02/19 | Suren Baghdasaryan | [[1/1] mm: count time in drain_all_pages during direct reclaimas memory pressure](https://patchwork.kernel.org/project/linux-mm/patch/20220219174940.2570901-1-surenb@google.com/) |615990 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220219174940.2570901-1-surenb@google.com) | +| 2022/09/10 | Christoph Hellwig | [improve pagecache PSI annotations](https://lore.kernel.org/all/20220910065058.3303831-1-hch@lst.de) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20220910065058.3303831-1-hch@lst.de)
*-*-*-*-*-*-*-*
[LORE v2](https://lore.kernel.org/all/20220915094200.139713-1-hch@lst.de) | -## 6.4 PSI +## 6.4 PSI Core ------- [知乎-兰新宇--Linux 的资源控制监测 - PSI [上]](https://zhuanlan.zhihu.com/p/523716850) @@ -204,6 +206,8 @@ $reclaim = current\_mem \times reclaim\_ratio \times max(0,1 – \frac{psi_some} | 2020/03/31 | Yafang Shao | [psi: enhance psi with the help of ebpf](https://lwn.net/Articles/1218304) | 引入 psi_memstall_type 标记 MEMSTALL 的类别, 并在 tracepoint 输出, 从而可以被 ebpf 使用来增强工具. | v4 ☑ [4.20-rc1](https://kernelnewbies.org/Linux_4.20#Core_.28various.29) | [Patchwork](https://lore.kernel.org/patchwork/patch/1218304) | | 2022/07/21 | Chengming Zhou | [sched/psi: some optimization and extension](https://lore.kernel.org/all/20220721040439.2651-1-zhouchengming@bytedance.com) | 优化 PSI 的性能, 同时增加对 IRQ/SOFTIRQ 的负载压力跟踪. | v1 ☐☑✓ | [LORE v1,0/9](https://lore.kernel.org/all/20220721040439.2651-1-zhouchengming@bytedance.com) | | 2022/08/01 | CGEL | [[RFC,1/2] psi: introduce memory.pressure.stat](https://patchwork.kernel.org/project/linux-mm/patch/20220801004205.1593100-1-ran.xiaokai@zte.com.cn/) | 664363 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/20220801004205.1593100-1-ran.xiaokai@zte.com.cn) | +| 2022/09/10 | Christoph Hellwig | [[1/5] mm: add PSI accounting around ->read_folio and ->readahead calls](https://patchwork.kernel.org/project/linux-mm/patch/20220910065058.3303831-2-hch@lst.de/) | 675899 | v1 ☐☑ | [LORE v1,0/5](https://lore.kernel.org/r/20220910065058.3303831-2-hch@lst.de) | +| 2022/09/15 | Christoph Hellwig | [improve pagecache PSI annotations v2](https://lore.kernel.org/all/20220915094200.139713-1-hch@lst.de) | TODO | v2 ☐☑✓ | [LORE](https://lore.kernel.org/all/20220915094200.139713-1-hch@lst.de) | # 7 DYNAMIC_DEBUG diff --git a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md index f892c13..dd37df5 100644 --- a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md +++ b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md @@ -330,6 +330,15 @@ Linux 一开始是在一台i386上的机器开发的, i386 的硬件页表是2 | 2022/06/17 | Matthew Wilcox | [Convert the swap code to be more folio-based](https://patchwork.kernel.org/project/linux-mm/cover/20220617175020.717127-1-willy@infradead.org/) | 651513 | v1 ☐☑ | [LORE v1,0/22](https://lore.kernel.org/r/20220617175020.717127-1-willy@infradead.org) | | 2022/06/08 | Miaohe Lin | [[v2] mm/vmscan: don't try to reclaim freed folios](https://patchwork.kernel.org/project/linux-mm/patch/20220608141432.23258-1-linmiaohe@huawei.com/) | 648484 | v2 ☐☑ | [LORE v2,0/1](https://lore.kernel.org/r/20220608141432.23258-1-linmiaohe@huawei.com) | +#### 1.4.1.4 Memory folios @6.0 +------- + + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:----:|:---------:|:----:| +| 2022/08/29 | Sidhartha Kumar | [begin converting hugetlb code to folios](https://patchwork.kernel.org/project/linux-mm/cover/20220829230014.384722-1-sidhartha.kumar@oracle.com/) | 672211 | v1 ☐☑ | [LORE v1,0/7](https://lore.kernel.org/r/20220829230014.384722-1-sidhartha.kumar@oracle.com)
*-*-*-*-*-*-*-*
[LORE v2,0/6](https://lore.kernel.org/r/20220906165445.146913-1-sidhartha.kumar@oracle.com) | + + ### 1.4.2 Pulling slabs out of struct page ------- @@ -584,6 +593,8 @@ Linux 进程使用不同的虚拟地址空间. 因此, 管理该地址空间状 |:----:|:----:|:---:|:----:|:---------:|:----:| | 2021/11/10 | Qi Zheng | [Free user PTE page table pages](https://patchwork.kernel.org/project/linux-mm/cover/20210819031858.98043-1-zhengqi.arch@bytedance.com) | 这个补丁系列的目的是在所有 PTE 条目都为空时释放用户 PTE 页表页面.
一些malloc库(例如 jemalloc 或 tcmalloc) 通常通过 mmap() 分配 VAs 的数量, 而不取消这些 VAs 的映射. 如果需要, 他们将使用 madvise(MADV_DONTNEED) 来释放物理内存. 但是 madvise() 不会释放页表, 因此当进程接触到巨大的虚拟地址空间时, 它会生成许多页表.
PTE 页表占用大量内存的原因是 madvise(MADV_DONTNEED) 只清空 PTE 并释放物理内存, 但不释放 PTE 页表页. 这组补丁通过释放那些空的 PTE 页表来节省内存. | v1 ☐ | [PatchWork 0/7](https://lore.kernel.org/patchwork/patch/1461972)
*-*-*-*-*-*-*-*
[2021/08/19 PatchWork v2,0/9](https://patchwork.kernel.org/project/linux-mm/cover/20210819031858.98043-1-zhengqi.arch@bytedance.com)
*-*-*-*-*-*-*-*
[2021/11/10 PatchWork v3,00/15](https://patchwork.kernel.org/project/linux-mm/cover/20211110084057.27676-1-zhengqi.arch@bytedance.com) | | 2022/04/29 | Qi Zheng | [Try to free user PTE page table pages](https://patchwork.kernel.org/project/linux-mm/cover/20220429133552.33768-1-zhengqi.arch@bytedance.com/) | 636959 | v1 ☐☑ | [LORE v1,0/18](https://lore.kernel.org/r/20220429133552.33768-1-zhengqi.arch@bytedance.com) | +| 2022/08/25 | Qi Zheng | [Try to free empty and zero user PTE page table pages](https://patchwork.kernel.org/project/linux-mm/cover/20220825101037.96517-1-zhengqi.arch@bytedance.com/) | 671004 | v1 ☐☑ | [LORE v1,0/7](https://lore.kernel.org/r/20220825101037.96517-1-zhengqi.arch@bytedance.com) | + ## 1.8 安全 ------- @@ -632,7 +643,7 @@ MTE 实现了锁和密钥访问内存. 这样在内存访问期间, 可以在内 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| -| 2021/02/05 | "Kirill A. Shutemov" | [Linear Address Masking enabling](https://patchwork.kernel.org/project/linux-mm/cover/20210205151631.43511-1-kirill.shutemov@linux.intel.com) | [线性地址屏蔽(LAM)](https://software.intel.com/content/dam/develop/external/us/en/documents-tps/architecture-instruction-set-extensions-programming-reference.pdf) 修改应用于 64 位线性地址的检查, 允许软件将未翻译的地址位用于元数据. 手册参见 [ISE, Chapter 14](https://patchwork.kernel.org/project/linux-mm/cover/20210205151631.43511-1-kirill.shutemov@linux.intel.com). 代码参见 [kas/linux.git](https://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git/log/?h=lam). | RFC ☐ | [PatchWork RFC,0/9](https://patchwork.kernel.org/project/linux-mm/cover/20210205151631.43511-1-kirill.shutemov@linux.intel.com)
*-*-*-*-*-*-*-*
[LORE v1,0/8](https://lore.kernel.org/r/20220610143527.22974-1-kirill.shutemov@linux.intel.com))
*-*-*-*-*-*-*-*
[LORE v1,0/11](https://lore.kernel.org/r/20220815041803.17954-1-kirill.shutemov@linux.intel.com) | +| 2021/02/05 | "Kirill A. Shutemov" | [Linear Address Masking enabling](https://patchwork.kernel.org/project/linux-mm/cover/20210205151631.43511-1-kirill.shutemov@linux.intel.com) | [线性地址屏蔽(LAM)](https://software.intel.com/content/dam/develop/external/us/en/documents-tps/architecture-instruction-set-extensions-programming-reference.pdf) 修改应用于 64 位线性地址的检查, 允许软件将未翻译的地址位用于元数据. 手册参见 [ISE, Chapter 14](https://patchwork.kernel.org/project/linux-mm/cover/20210205151631.43511-1-kirill.shutemov@linux.intel.com). 代码参见 [kas/linux.git](https://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git/log/?h=lam). | RFC ☐ | [PatchWork RFC,0/9](https://patchwork.kernel.org/project/linux-mm/cover/20210205151631.43511-1-kirill.shutemov@linux.intel.com)
*-*-*-*-*-*-*-*
[LORE v1,0/8](https://lore.kernel.org/r/20220610143527.22974-1-kirill.shutemov@linux.intel.com)
*-*-*-*-*-*-*-*
[LORE v1,0/11](https://lore.kernel.org/r/20220815041803.17954-1-kirill.shutemov@linux.intel.com)
*-*-*-*-*-*-*-*
[LORE v1,0/11](https://lore.kernel.org/r/20220830010104.1282-1-kirill.shutemov@linux.intel.com) | ## 1.9 page attributes @@ -1426,6 +1437,14 @@ v2.6.16-rc1 时, 大家发现 pcp->low 水线貌似并没有什么太大的用 | 2021/05/25 | Mel Gorman | [Calculate pcp->high based on zone sizes and active CPUs](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=74f44822097c665041010994502b5971d6cd9f04) | pcp->high 和 pcp->batch 根据 zone 内内存的大小进行调整. 移除了不适用的 vm.percpu_pagelist_fraction 参数. | v2 ☑ 5.14-rc1 | [LORE v1,0/6](https://lore.kernel.org/all/20210521102826.28552-1-mgorman@techsingularity.net)
*-*-*-*-*-*-*-*
[LORE v2,0/6](https://lore.kernel.org/lkml/20210525080119.5455-1-mgorman@techsingularity.net) | +#### 2.2.5.6 Other PCP Improving +------- + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:----:|:---------:|:----:| +| 2022/08/24 | Mel Gorman | [[1/1] mm/page_alloc: Leave IRQs enabled for per-cpu page allocations](https://patchwork.kernel.org/project/linux-mm/patch/20220824141802.23395-1-mgorman@techsingularity.net/) | 670701 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220824141802.23395-1-mgorman@techsingularity.net) | + + #### 2.2.5.7 PCP 分配器框架变更与优化时间线(总结) ------- @@ -1916,9 +1935,10 @@ vmalloc_to_page 则提供了通过 vmalloc 地址查找到对应 page 的操作. | 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) | +| 2022/08/29 | Feng Tang | [mm/slub: some debug enhancements for kmalloc objects](https://patchwork.kernel.org/project/linux-mm/cover/20220829075618.69069-1-feng.tang@intel.com/) | 671907 | v4 ☐☑ | [LORE v4,0/4](https://lore.kernel.org/r/20220829075618.69069-1-feng.tang@intel.com)
*-*-*-*-*-*-*-*
[LORE v6,0/4](https://lore.kernel.org/r/20220913065423.520159-1-feng.tang@intel.com) | -### 2.4.2 连续内存分配器(下·) +### 2.4.2 连续内存分配器(下) ------- 物理上连续的大页面对于 gpu、fpga、nic 和 RDMA 控制器等设备非常重要, 因为它们在大页面上操作时通常可以获得更好的性能. 当然, CPU 的性能也是如此, 但是有一个重要的区别: @@ -3292,7 +3312,7 @@ v12 版本已经没有什么特性变更, 仅仅是一些 bugfix, 参见 phoroni 社区开发者们对 MGLRU 的合入保持了极大的热情和关注, 参见 [MGLRU Patches Picked Up By Andrew Morton's "mm-unstable" Branch Ahead Of Linux 6.1](https://www.phoronix.com/news/MGLRU-MM-Branch) 和 [MGLRU Linux Performance Looking Very Good For OpenWrt Router Use](https://www.phoronix.com/news/MGLRU-Performance-OpenWRT) -MGLRU 的开发者在 LRC-2022 上演示了 MGLRU, phoronix 对此进行了跟踪报道, 参见 [MGLRU Looks Like One Of The Best Linux Kernel Innovations Of The Year](https://www.phoronix.com/news/MGLRU-LPC-2022). +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). * 实现 @@ -3301,7 +3321,10 @@ MGLRU 的开发者在 LRC-2022 上演示了 MGLRU, phoronix 对此进行了跟 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| -| 2022/04/07 | Yu Zhao | [Multigenerational LRU Framework(https://lwn.net/Articles/856931) | Multi-Gen LRU Framework, 将 LRU 的列表划分为多代老化. 通过 CONFIG_LRU_GEN 来控制. | v10 ☐ | [Patchwork v1,00/14](https://lore.kernel.org/patchwork/patch/1394674)
*-*-*-*-*-*-*-*
[PatchWork v2,00/16](https://lore.kernel.org/patchwork/patch/1412560)
*-*-*-*-*-*-*-*
[2021/05/20 PatchWork v3,00/14](https://patchwork.kernel.org/project/linux-mm/cover/20210520065355.2736558-1-yuzhao@google.com)
*-*-*-*-*-*-*-*
[2021/08/18 PatchWork v4,00/11](https://patchwork.kernel.org/project/linux-mm/cover/20210818063107.2696454-1-yuzhao@google.com)
*-*-*-*-*-*-*-*
[2021/11/11 PatchWork v5,00/10](https://patchwork.kernel.org/project/linux-mm/cover/20211111041510.402534-1-yuzhao@google.com)
*-*-*-*-*-*-*-*
[2022/01/04 PatchWork v6,0/9](https://patchwork.kernel.org/project/linux-mm/cover/20220104202227.2903605-1-yuzhao@google.com)
*-*-*-*-*-*-*-*
[2022/02/08 PatchWork v7,0/12](https://lore.kernel.org/all/20220208081902.3550911-1-yuzhao@google.com)
*-*-*-*-*-*-*-*
[2022/03/08 LORE v8,0/14](https://lore.kernel.org/all/20220308234723.3834941-1-yuzhao@google.com)
*-*-*-*-*-*-*-*
[2022/03/09 LORE v9,0/14](https://lore.kernel.org/all/20220309021230.721028-1-yuzhao@google.com)
*-*-*-*-*-*-*-*
[2022/04/07 LORE,v10,00/14](https://lore.kernel.org/lkml/20220407031525.2368067-1-yuzhao@google.com)
*-*-*-*-*-*-*-*
[LORE v11,00/14](https://lore.kernel.org/lkml/20220518014632.922072-1-yuzhao@google.com)
*-*-*-*-*-*-*-*
[LORE v12,00/14](https://lore.kernel.org/lkml/20220614071650.206064-1-yuzhao@google.com)
*-*-*-*-*-*-*-*
[LORE v13,00/14](https://lore.kernel.org/lkml/20220706220022.968789-1-yuzhao@google.com)
*-*-*-*-*-*-*-*
[LORE v14,00/14](https://lore.kernel.org/lkml/20220815071332.627393-1-yuzhao@google.com) | +| 2022/04/07 | Yu Zhao | [Multigenerational LRU Framework(https://lwn.net/Articles/856931) | Multi-Gen LRU Framework, 将 LRU 的列表划分为多代老化. 通过 CONFIG_LRU_GEN 来控制. | v10 ☐ | [Patchwork v1,00/14](https://lore.kernel.org/patchwork/patch/1394674)
*-*-*-*-*-*-*-*
[PatchWork v2,00/16](https://lore.kernel.org/patchwork/patch/1412560)
*-*-*-*-*-*-*-*
[2021/05/20 PatchWork v3,00/14](https://patchwork.kernel.org/project/linux-mm/cover/20210520065355.2736558-1-yuzhao@google.com)
*-*-*-*-*-*-*-*
[2021/08/18 PatchWork v4,00/11](https://patchwork.kernel.org/project/linux-mm/cover/20210818063107.2696454-1-yuzhao@google.com)
*-*-*-*-*-*-*-*
[2021/11/11 PatchWork v5,00/10](https://patchwork.kernel.org/project/linux-mm/cover/20211111041510.402534-1-yuzhao@google.com)
*-*-*-*-*-*-*-*
[2022/01/04 PatchWork v6,0/9](https://patchwork.kernel.org/project/linux-mm/cover/20220104202227.2903605-1-yuzhao@google.com)
*-*-*-*-*-*-*-*
[2022/02/08 PatchWork v7,0/12](https://lore.kernel.org/all/20220208081902.3550911-1-yuzhao@google.com)
*-*-*-*-*-*-*-*
[2022/03/08 LORE v8,0/14](https://lore.kernel.org/all/20220308234723.3834941-1-yuzhao@google.com)
*-*-*-*-*-*-*-*
[2022/03/09 LORE v9,0/14](https://lore.kernel.org/all/20220309021230.721028-1-yuzhao@google.com)
*-*-*-*-*-*-*-*
[2022/04/07 LORE,v10,00/14](https://lore.kernel.org/lkml/20220407031525.2368067-1-yuzhao@google.com)
*-*-*-*-*-*-*-*
[LORE v11,00/14](https://lore.kernel.org/lkml/20220518014632.922072-1-yuzhao@google.com)
*-*-*-*-*-*-*-*
[LORE v12,00/14](https://lore.kernel.org/lkml/20220614071650.206064-1-yuzhao@google.com)
*-*-*-*-*-*-*-*
[LORE v13,00/14](https://lore.kernel.org/lkml/20220706220022.968789-1-yuzhao@google.com)
*-*-*-*-*-*-*-*
[LORE v14,00/14](https://lore.kernel.org/lkml/20220815071332.627393-1-yuzhao@google.com)
*-*-*-*-*-*-*-*
[LORE v15,0/14](https://lore.kernel.org/r/20220918080010.2920238-1-yuzhao@google.com) | +| 2022/09/11 | Yuanchu Xie | [mm: multi-gen LRU: per-process heatmaps](https://patchwork.kernel.org/project/linux-mm/cover/20220911083418.2818369-1-yuanchu@google.com/) | 675988 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/20220911083418.2818369-1-yuanchu@google.com) | +| 2022/09/18 | Yu Zhao | [[v14-fix,01/11] mm: multi-gen LRU: update admin guide](https://patchwork.kernel.org/project/linux-mm/patch/20220918204755.3135720-1-yuzhao@google.com/) | 677981 | v1 ☐☑ | [LORE v1,0/11](https://lore.kernel.org/r/20220918204755.3135720-1-yuzhao@google.com) | +| 2022/09/20 | zhaoyang.huang | [[RFC] mm: track bad page via kmemleak](https://patchwork.kernel.org/project/linux-mm/patch/1663679468-16757-1-git-send-email-zhaoyang.huang@unisoc.com/) | 678650 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/1663679468-16757-1-git-send-email-zhaoyang.huang@unisoc.com) | @@ -3856,7 +3879,7 @@ v2.5 的时候引入了 shrink 机制, 并提供了 API 统一了各个模块的 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:---:|:----:|:---:|:----:|:---------:|:----:| | 2022/08/05 | alexlzhu@fb.com | [mm: add thp_utilization metrics to /proc/thp_utilization](https://lore.kernel.org/all/20220805184016.2926168-1-alexlzhu@fb.com) | 由于性能的提高或降低取决于特定应用程序如何使用物理内存, THP 在历史上一直是针对每个应用程序启用的. 当 THP 被大量利用时, 由于 TLB 缓存失败的减少, 应用程序性能会得到改善. 长期以来, 人们一直怀疑启用 THP 时的性能下降是由于大量未充分利用的匿名 THP 造成的. 以前, 没有办法跟踪到底有多少 THP 被实际使用. 通过这个补丁, 帮助开发者了解 THP 的使用情况, 以便在分页方面做出更智能的决策. 这个更改引入了一个工具, 该工具扫描匿名 THP 的所有物理内存, 并根据使用率将它们分组到桶中. 它还包括一个位于 `/sys/kernel/debug/thp_utilization` 下的接口. THP 的利用率定义为 THP 中非零页面的百分比. 工作线程将扫描所有物理内存, 并获得所有匿名 THP 的利用率. 它将通过定期扫描所有物理内存来收集这些信息, 寻找匿名 THP, 根据利用率将它们分组到桶中, 并通过 `/sys/kernel/debug/thp_utilization` 下的 debugfs 报告利用率信息. | v3 ☐☑✓ | [LORE v2](https://lore.kernel.org/lkml/20220809014950.3616464-1-alexlzhu@fb.com)
*-*-*-*-*-*-*-*
[LORE v3](https://lore.kernel.org/all/20220805184016.2926168-1-alexlzhu@fb.com)
*-*-*-*-*-*-*-*
[LORE v3,0/1](https://lore.kernel.org/r/20220818000112.2722201-1-alexlzhu@fb.com) | -| 2022/08/25 | alexlzhu@fb.com | [THP Shrinker](https://lore.kernel.org/all/cover.1661461643.git.alexlzhu@fb.com) | TODO | v1☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/cover.1661461643.git.alexlzhu@fb.com) | +| 2022/08/25 | alexlzhu@fb.com | [THP Shrinker](https://lore.kernel.org/all/cover.1661461643.git.alexlzhu@fb.com) | TODO | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/cover.1661461643.git.alexlzhu@fb.com)
*-*-*-*-*-*-*-*
[LORE v1,0/3](https://lore.kernel.org/r/cover.1661461643.git.alexlzhu@fb.com) | ## 4.4 主动的页面回收(Proactive Reclaim) @@ -4713,7 +4736,10 @@ Google 的工程师 Mina Almasry 提出了一种新的思路, 通过 [mremap 的 | 2022/05/08 | Mike Kravetz | [hugetlb: Change huge pmd sharing synchronization again](https://patchwork.kernel.org/project/linux-mm/cover/20220420223753.386645-1-mike.kravetz@oracle.com/) | 之前 [v5.7 中添加了](https://lore.kernel.org/linux-mm/43faf292-245b-5db5-cce9-369d8fb6bd21@infradead.org) commit c0d0381ade79 ("hugetlbfs: use i_mmap_rwsem for more pmd sharing synchronization") 时, 社区就[报告了性能回归](https://lore.kernel.org/lkml/20200622005551.GK5535@shao2-debian). 当时, Mike Kravetz 提出了一个[解决回归的建议](https://lore.kernel.org/linux-mm/20200706202615.32111-1-mike.kravetz@oracle.com), 但没有被合入. 这个补丁集使用一个新的 hugetlb 特定的 per-vma rw 信号量来同步 PMD 共享. 为了更好的演示这个性能回归, 作者构造了一个简单的测试用例. | v2 ☐☑ | [2022/04/20 LORE v2,0/6](https://lore.kernel.org/r/20220420223753.386645-1-mike.kravetz@oracle.com)
*-*-*-*-*-*-*-*
[2022/05/08 LORE v3,0/8](https://lore.kernel.org/r/20220508183420.18488-1-mike.kravetz@oracle.com) | | 2022/05/27 | Mike Kravetz | [hugetlb: speed up linear address scanning](https://patchwork.kernel.org/project/linux-mm/cover/20220527225849.284839-1-mike.kravetz@oracle.com/) | 645704 | v1 ☐☑ | [LORE v1,0/3](https://lore.kernel.org/r/20220527225849.284839-1-mike.kravetz@oracle.com)
*-*-*-*-*-*-*-*
[LORE v1,0/4](https://lore.kernel.org/r/20220616210518.125287-1-mike.kravetz@oracle.com)
*-*-*-*-*-*-*-*
[[LORE v2,0/4](https://lore.kernel.org/r/20220621235620.291305-1-mike.kravetz@oracle.com) | | 2022/06/24 | James Houghton | [hugetlb: Introduce HugeTLB high-granularity mapping](https://patchwork.kernel.org/project/linux-mm/cover/20220624173656.2033256-1-jthoughton@google.com/) | 引入了HugeTLB高粒度映射(HGM)(曾经叫做 HugeTLB double mapping)的概念. 高粒度映射不需要分解大页面本身;它只影响它们的映射方式. 从广义上讲, 它主要探索如何在不同粒度上映射 HugeTLB 页面, 更重要的是, 部分映射 HugeTLB 页面. | v1 ☐☑ | [LORE v1,0/26](https://lore.kernel.org/r/20220624173656.2033256-1-jthoughton@google.com) | -| 2022/08/24 | Mike Kravetz | [hugetlb: Use new vma mutex for huge pmd sharing synchronization](https://lore.kernel.org/all/20220824175757.20590-1-mike.kravetz@oracle.com) | TODO | v1 ☐☑✓ | [LORE v1,0/8](https://lore.kernel.org/all/20220824175757.20590-1-mike.kravetz@oracle.com) | +| 2022/08/24 | Mike Kravetz | [hugetlb: Use new vma mutex for huge pmd sharing synchronization](https://lore.kernel.org/all/20220824175757.20590-1-mike.kravetz@oracle.com) | TODO | v1 ☐☑✓ | [LORE v1,0/8](https://lore.kernel.org/all/20220824175757.20590-1-mike.kravetz@oracle.com)
*-*-*-*-*-*-*-*
[LORE v2,0/9](https://lore.kernel.org/all/20220914221810.95771-1-mike.kravetz@oracle.com) | +| 2022/09/16 | Mike Kravetz | [hugetlb: freeze allocated pages before creating hugetlb pages](https://patchwork.kernel.org/project/linux-mm/patch/20220916214638.155744-1-mike.kravetz@oracle.com/) | 677766 | v2 ☐☑ | [LORE v2,0/1](https://lore.kernel.org/r/20220916214638.155744-1-mike.kravetz@oracle.com)
*-*-*-*-*-*-*-*
[LORE v3,0/1](https://lore.kernel.org/r/20220921202702.106069-1-mike.kravetz@oracle.com) | +| 2022/09/21 | Doug Berger | [mm/hugetlb: hugepage migration enhancements](https://patchwork.kernel.org/project/linux-mm/cover/20220921223639.1152392-1-opendmb@gmail.com/) | 679187 | v1 ☐☑ | [LORE v1,0/3](https://lore.kernel.org/r/20220921223639.1152392-1-opendmb@gmail.com) | +| 2022/09/01 | Muchun Song | [mm: hugetlb: eliminate memory-less nodes handling](https://patchwork.kernel.org/project/linux-mm/patch/20220901083023.42319-1-songmuchun@bytedance.com/) | 673136 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220901083023.42319-1-songmuchun@bytedance.com) | ## 7.2 透明大页的支持 @@ -5142,6 +5168,11 @@ khugepaged 处理流程 |:---:|:----:|:---:|:----:|:---------:|:----:| | 2022/08/05 | alexlzhu@fb.com | [mm: add thp_utilization metrics to /proc/thp_utilization](https://lore.kernel.org/all/20220805184016.2926168-1-alexlzhu@fb.com) | 由于性能的提高或降低取决于特定应用程序如何使用物理内存, THP 在历史上一直是针对每个应用程序启用的. 当 THP 被大量利用时, 由于 TLB 缓存失败的减少, 应用程序性能会得到改善. 长期以来, 人们一直怀疑启用 THP 时的性能下降是由于大量未充分利用的匿名 THP 造成的. 以前, 没有办法跟踪到底有多少 THP 被实际使用. 通过这个补丁, 帮助开发者了解 THP 的使用情况, 以便在分页方面做出更智能的决策. 这个更改引入了一个工具, 该工具扫描匿名 THP 的所有物理内存, 并根据使用率将它们分组到桶中. 它还包括一个位于 `/sys/kernel/debug/thp_utilization` 下的接口. THP 的利用率定义为 THP 中非零页面的百分比. 工作线程将扫描所有物理内存, 并获得所有匿名 THP 的利用率. 它将通过定期扫描所有物理内存来收集这些信息, 寻找匿名 THP, 根据利用率将它们分组到桶中, 并通过 `/sys/kernel/debug/thp_utilization` 下的 debugfs 报告利用率信息. | v3 ☐☑✓ | [LORE v2](https://lore.kernel.org/lkml/20220809014950.3616464-1-alexlzhu@fb.com)
*-*-*-*-*-*-*-*
[LORE v3](https://lore.kernel.org/all/20220805184016.2926168-1-alexlzhu@fb.com)
*-*-*-*-*-*-*-*
[LORE v3,0/1](https://lore.kernel.org/r/20220818000112.2722201-1-alexlzhu@fb.com) | +* Improve awareness for exiting processe + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:---:|:----:|:---:|:----:|:---------:|:----:| +| 2022/09/21 | Rongwei Wang | [[RFC] mm/khugepaged: Improve awareness for exiting processes](https://patchwork.kernel.org/project/linux-mm/patch/20220921032759.41473-1-rongwei.wang@linux.alibaba.com/) | 678876 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220921032759.41473-1-rongwei.wang@linux.alibaba.com) | @@ -5357,7 +5388,9 @@ Dirty COW(CVE-2016-5195) 是近几年影响比较严重的问题, 参见 [Dirty * SPF(Speculative page faults) +[投机性缺页异常(SPF)原理分析](https://zhuanlan.zhihu.com/p/567855662) +[spf_test](https://github.com/surenbaghdasaryan/spf_test/blob/main/spf_test.c) | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| @@ -5380,7 +5413,7 @@ Dirty COW(CVE-2016-5195) 是近几年影响比较严重的问题, 参见 [Dirty | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| -| 2022/08/29 | Suren Baghdasaryan | [per-VMA locks proposal](https://lore.kernel.org/all/20220829212531.3184856-1-surenb@google.com) | TODO | v1 ☐☑✓ | [LORE v1,0/28](https://lore.kernel.org/all/20220829212531.3184856-1-surenb@google.com) | +| 2022/08/29 | Suren Baghdasaryan | [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)
*-*-*-*-*-*-*-*
[2022/09/01 LORE v1,0/28](https://lore.kernel.org/r/20220901173516.702122-1-surenb@google.com) | * Maple Tree @@ -5390,7 +5423,7 @@ Dirty COW(CVE-2016-5195) 是近几年影响比较严重的问题, 参见 [Dirty | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| -| 2022/04/26 | Liam Howlett | [Introducing the Maple Tree](https://lore.kernel.org/patchwork/patch/1477973) | Maple Tree 是一种基于 RCU 安全范围的 B树, 旨在高效使用现代处理器缓存. 在内核中有许多地方, 基于范围的非重叠树是有益的, 尤其是具有简单接口的树. Maple Tree 的第一个用户是 vm_area_struct, 当前替换了三个结构: 增强 rbtree、vma 缓存和 mm_struct 中的 vma linked 链表. 长期目标是减少或消除 mmap_sem 争用. | v9 ☐ | [2021/08/17 PatchWork v2,00/61](https://patchwork.kernel.org/project/linux-mm/cover/20210817154651.1570984-1-Liam.Howlett@oracle.com)
*-*-*-*-*-*-*-*
[2021/10/05 PatchWork v3](https://patchwork.kernel.org/project/linux-mm/cover/20211005012959.1110504-1-Liam.Howlett@oracle.com)
*-*-*-*-*-*-*-*
[2021/12/01 PatchWork v4,00/66](https://patchwork.kernel.org/project/linux-mm/cover/20211201142918.921493-1-Liam.Howlett@oracle.com)
*-*-*-*-*-*-*-*
[2022/02/02 PatchWork v5,00/70](https://patchwork.kernel.org/project/linux-mm/cover/20220202024137.2516438-1-Liam.Howlett@oracle.com)
*-*-*-*-*-*-*-*
[2022/04/04 LORE v7,00/70](https://lore.kernel.org/r/20220404143501.2016403-1-Liam.Howlett@oracle.com)
*-*-*-*-*-*-*-*
[2022/04/26 LORE v8,0/70](https://lore.kernel.org/r/20220426150616.3937571-1-Liam.Howlett@oracle.com)
*-*-*-*-*-*-*-*
[LORE v9,0/69](https://lore.kernel.org/r/20220504010716.661115-1-Liam.Howlett@oracle.com)
*-*-*-*-*-*-*-*
[2022/06/21 LORE v10,0/69](https://lore.kernel.org/all/20220621204632.3370049-1-Liam.Howlett@oracle.com)
*-*-*-*-*-*-*-*
[2022/07/17 LORE v11,0/69](https://lore.kernel.org/r/20220717024615.2106835-1-Liam.Howlett@oracle.com) | +| 2022/08/22 | Liam Howlett | [Introducing the Maple Tree](https://lore.kernel.org/patchwork/patch/1477973) | Maple Tree 是一种基于 RCU 安全范围的 B树, 旨在高效使用现代处理器缓存. 在内核中有许多地方, 基于范围的非重叠树是有益的, 尤其是具有简单接口的树. Maple Tree 的第一个用户是 vm_area_struct, 当前替换了三个结构: 增强 rbtree、vma 缓存和 mm_struct 中的 vma linked 链表. 长期目标是减少或消除 mmap_sem 争用. | v9 ☐ | [2021/08/17 PatchWork v2,00/61](https://patchwork.kernel.org/project/linux-mm/cover/20210817154651.1570984-1-Liam.Howlett@oracle.com)
*-*-*-*-*-*-*-*
[2021/10/05 PatchWork v3](https://patchwork.kernel.org/project/linux-mm/cover/20211005012959.1110504-1-Liam.Howlett@oracle.com)
*-*-*-*-*-*-*-*
[2021/12/01 PatchWork v4,00/66](https://patchwork.kernel.org/project/linux-mm/cover/20211201142918.921493-1-Liam.Howlett@oracle.com)
*-*-*-*-*-*-*-*
[2022/02/02 PatchWork v5,00/70](https://patchwork.kernel.org/project/linux-mm/cover/20220202024137.2516438-1-Liam.Howlett@oracle.com)
*-*-*-*-*-*-*-*
[2022/04/04 LORE v7,00/70](https://lore.kernel.org/r/20220404143501.2016403-1-Liam.Howlett@oracle.com)
*-*-*-*-*-*-*-*
[2022/04/26 LORE v8,0/70](https://lore.kernel.org/r/20220426150616.3937571-1-Liam.Howlett@oracle.com)
*-*-*-*-*-*-*-*
[LORE v9,0/69](https://lore.kernel.org/r/20220504010716.661115-1-Liam.Howlett@oracle.com)
*-*-*-*-*-*-*-*
[2022/06/21 LORE v10,0/69](https://lore.kernel.org/all/20220621204632.3370049-1-Liam.Howlett@oracle.com)
*-*-*-*-*-*-*-*
[2022/07/17 LORE v11,0/69](https://lore.kernel.org/r/20220717024615.2106835-1-Liam.Howlett@oracle.com)
*-*-*-*-*-*-*-*
[2022/08/22 ORE v13,0/70](https://lore.kernel.org/r/20220822150128.1562046-1-Liam.Howlett@oracle.com) | | 2022/05/04 | Liam Howlett | [Prepare for maple tree](https://patchwork.kernel.org/project/linux-mm/cover/20220504002554.654642-1-Liam.Howlett@oracle.com/) | 638130 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220504002554.654642-1-Liam.Howlett@oracle.com) | @@ -5591,6 +5624,12 @@ RMAP 反向映射是一种物理地址反向映射虚拟地址的方法. | 2021/03/25 | Tetsuo Handa | [memcg: killed threads should not invoke memcg OOM killer](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7775face207922ea62a4e96b9cd45abfdc7b9840) | 如果当前线程在等待 oom_lock 时被杀死, 我们不需要调用 memcg OOM Killer | v3 ☐ | [PatchWork](https://patchwork.kernel.org/project/linux-mm/patch/01370f70-e1f6-ebe4-b95e-0df21a0bc15e@i-love.sakura.ne.jp), [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7775face207922ea62a4e96b9cd45abfdc7b9840) | | 2021/10/23 | Vasily Averin | [memcg: prohibit unconditional exceeding the limit of dying tasks](https://patchwork.kernel.org/project/linux-mm/patch/b89715b5-6df7-34a3-f7b9-efa8e0eefd3e@virtuozzo.com) | 内存 cgroup charge 的过程中允许杀死或退出的任务超过硬限制. 假设这些任务占用的内存数量是绑定的, 并且在任务退出时, 大部分内存将被释放. 这类似于任务访问内存储备时的全局 OOM 情况的启发式策略. 在 memcg 水平上没有全局内存短缺, 所以 memcg 启发式比较轻松.
不过, 上述假设过于乐观. 例如:
1. vmalloc 可以扩展到真正大的请求, 启发式将允许这一点. 我们曾经在 vmalloc 分配器中有一个被杀死的任务的早期中断, 但这已经被提交 b8c8a338f75e ("Revert vmalloc: back off when the current task is killed"). 所恢复. 可能还有其他类似的代码路径在分配和充电循环中不检查致命信号.
2. 还有一些内核对象统计到给 memcg, 但是它们没有绑定到进程生命周期. 据观察, 触发这些旁路并造成全球 OOM 情况并非真的很难.
解决这些问题的一种潜在方法是限制过剩的数量(类似于有限房间储备的全局 OOM). 这当然是可能的, 但我们并不清楚需要多少额外的内存, 并且仍然可以防止全局 oom, 因为这将不得不考虑整个 memcg 配置.
这个补丁通过完全删除启发式的策略来解决这个问题. 绕过只允许请求, 要么不能失败, 或失败是不可取的, 而超出应该仍然受到限制. 实现一个被杀死或即将死亡的任务, 如果它已经通过 OOM 杀手阶段, 就不能再被 charge. | v3 ☐ | [2021/10/20 PatchWork RFC,0/2](https://patchwork.kernel.org/project/linux-mm/cover/fe1d45a1-276d-b0f4-fb71-8f5c1a9e8872@virtuozzo.com/)
*-*-*-*-*-*-*-*
[2021/10/05 PatchWork v2,0/2](https://patchwork.kernel.org/project/linux-mm/cover/21d79b86-476c-a8f2-e950-2339606f1253@virtuozzo.com)
*-*-*-*-*-*-*-*
[2021/10/20 PatchWork v3,0/2](https://patchwork.kernel.org/project/linux-mm/cover/20e50917-3589-bcb7-0174-b6fccfd15c66@virtuozzo.com) | +* Cpuset OOM + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:----:|:---------:|:----:| +| 2022/09/21 | Gang Li | [[RFC,v1] mm: oom: introduce cpuset oom](https://patchwork.kernel.org/project/linux-mm/patch/20220921064710.89663-1-ligang.bdlg@bytedance.com/) | 678906 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220921064710.89663-1-ligang.bdlg@bytedance.com) | + ## 9.3 KMEMCG ------- @@ -5882,7 +5921,7 @@ zone->lru_锁是一个竞争激烈的锁, 因此 2012 年左右 Konstantin Khleb 在完成这一步之后, 内核已经可以提供基本的内存热插拔支持. 值得一提的是, 内存热插拔的工作, Fujitsu 中国这边的内核开放者贡献了很多 patch. 谢谢他们! -## 10.5 improving in-kernel auto-online support +## 10.5 improving in-kernel auto-online support ------- * 虚拟机内存热缩优化 @@ -6032,6 +6071,7 @@ FRONTSWAP 对应的另一个后端叫 [ZSWAP](https://lwn.net/Articles/537422). |:----:|:----:|:---:|:---:|:----------:|:----:| | 2021/08/19 | Johannes Weiner | [mm: Kconfig: simplify zswap configuration](https://lore.kernel.org/patchwork/patch/1479229) | 重构 CONFIG_ZSWAP. | v1 ☐ | [PatchWork](https://lore.kernel.org/patchwork/patch/1479229) | | 2022/04/27 | Johannes Weiner | [zswap: cgroup accounting & control](https://patchwork.kernel.org/project/linux-mm/cover/20220427160016.144237-1-hannes@cmpxchg.org/) | 636247 | v1 ☐☑ | [LORE v1,0/5](https://lore.kernel.org/r/20220427160016.144237-1-hannes@cmpxchg.org)
*-*-*-*-*-*-*-*
[LORE v2,0/6](https://lore.kernel.org/all/20220510152847.230957-1-hannes@cmpxchg.org) | +| 2022/08/25 | Liu Shixin | [Delay the initializaton of zswap](https://patchwork.kernel.org/project/linux-mm/cover/20220825142037.3214152-1-liushixin2@huawei.com/) | 671093 | v1 ☐☑ | [LORE v1,0/3](https://lore.kernel.org/r/20220825142037.3214152-1-liushixin2@huawei.com) | ### 11.2.3.2 ZTREE @@ -6349,6 +6389,7 @@ SLAB 作为一个相对独立的子模块, 一直有自己完善的调试支持, |:----:|:----:|:---:|:----:|:---------:|:----:| | 2020/08/04 | Andrey Konovalov | [kasan: support stack instrumentation for tag-based mode](https://lore.kernel.org/patchwork/patch/1284062) | NA | v11 ☑ 5.9-rc1 | [PatchWork v2,0/5](https://lore.kernel.org/patchwork/patch/1284062), [Clang](https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html) | | 2022/03/23 | andrey.konovalov@linux.dev | [kasan, arm64, scs, stacktrace: collect stack traces from Shadow Call Stack](https://patchwork.kernel.org/project/linux-mm/cover/cover.1648049113.git.andreyknvl@google.com) | 目前, 当保存 alloc 和 free 堆栈跟踪时, kasan 总是使用正常的堆栈跟踪收集例程, 它依赖于 unwind. 通过复制帧从阴影调用堆栈收集堆栈跟踪, 每当它被启用. 这减少了 30% 的启动时间, 所有的 KASAN 模式时, 影子呼叫堆栈被启用. 堆栈栈位通过新的 stack_trace_save_shadow () 接口从 Shadow Call Stack 中收集. | v2 ☐☑ | [LORE v2,0/4](https://lore.kernel.org/r/cover.1648049113.git.andreyknvl@google.com)
*-*-*-*-*-*-*-*
[LORE v3,0/3](https://lore.kernel.org/r/cover.1649877511.git.andreyknvl@google.com) | +| 2022/09/10 | Peter Collingbourne | [kasan: also display registers for reports from HW exceptions](https://patchwork.kernel.org/project/linux-mm/patch/20220910052426.943376-1-pcc@google.com/) | 675886 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220910052426.943376-1-pcc@google.com) | #### 13.3.4.2 Software tag-based KASAN @@ -6434,7 +6475,7 @@ v4 的报道 [KernelMemorySanitizer v4 Published While Already Having Found 300+ | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| -| 2021/12/14 | Alexander Potapenko | [Add KernelMemorySanitizer infrastructure](https://patchwork.kernel.org/project/linux-mm/cover/20211214162050.660953-1-glider@google.com) | 该补丁集包含 KMSAN 运行时实现, 以及使 KMSAN 工作所需的对其他子系统的修改.
1. 添加KMSAN所需的现有代码的更改和重构.
2. 通用代码中的 KMSAN 相关声明、KMSAN 运行时库.
3. 添加来自不同子系统的钩子, 以通知 KMSAN 有关内存的信息.
4. 通过显式初始化内存、禁用可能欺骗KMSAN的优化代码、有选择地跳过检测来防止错误报告的更改.
5. Noinstr 的处理.
这个补丁集允许在 QEMU 上启动并运行 defconfig + KMSAN 内核, 而不会出现已知的误报. 然而, 它不能保证在某些设备或测试较少的子系统的驱动程序中没有误报, 尽管 KMSAN 在 syzbot 上使用较大的配置进行了积极的测试. | v1 ☐ | [PatchWork 00/43](https://patchwork.kernel.org/project/linux-mm/cover/20211214162050.660953-1-glider@google.com)
*-*-*-*-*-*-*-*
[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) | +| 2022/08/26 | Alexander Potapenko | [Add KernelMemorySanitizer infrastructure](https://patchwork.kernel.org/project/linux-mm/cover/20211214162050.660953-1-glider@google.com) | 该补丁集包含 KMSAN 运行时实现, 以及使 KMSAN 工作所需的对其他子系统的修改.
1. 添加KMSAN所需的现有代码的更改和重构.
2. 通用代码中的 KMSAN 相关声明、KMSAN 运行时库.
3. 添加来自不同子系统的钩子, 以通知 KMSAN 有关内存的信息.
4. 通过显式初始化内存、禁用可能欺骗KMSAN的优化代码、有选择地跳过检测来防止错误报告的更改.
5. Noinstr 的处理.
这个补丁集允许在 QEMU 上启动并运行 defconfig + KMSAN 内核, 而不会出现已知的误报. 然而, 它不能保证在某些设备或测试较少的子系统的驱动程序中没有误报, 尽管 KMSAN 在 syzbot 上使用较大的配置进行了积极的测试. | v1 ☐ | [PatchWork 00/43](https://patchwork.kernel.org/project/linux-mm/cover/20211214162050.660953-1-glider@google.com)
*-*-*-*-*-*-*-*
[LORE v3,00/46](https://lore.kernel.org/lkml/20220426164315.625149-1-glider@google.com)
*-*-*-*-*-*-*-*
[2022/07/01 LORE v4,00/45](https://lore.kernel.org/all/20220701142310.2188015-1-glider@google.com)
*-*-*-*-*-*-*-*
[2022/08/26 LORE v5,0/44](https://lore.kernel.org/r/20220826150807.723137-1-glider@google.com)
*-*-*-*-*-*-*-*
[2022/09/05 LORE v6,0/44](https://lore.kernel.org/r/20220905122452.2258262-1-glider@google.com)
*-*-*-*-*-*-*-*
[LORE v7,0/43](https://lore.kernel.org/r/20220915150417.722975-1-glider@google.com) | @@ -6506,6 +6547,8 @@ KFENCE 的灵感来自于 [GWP-ASan](http://llvm.org/docs/GwpAsan.html), 这是 | 2022/02/08 | Waiman Long | [mm/page_owner: Extend page_owner to show memcg information](https://patchwork.kernel.org/project/linux-mm/cover/20220128195642.416743-1-longman@redhat.com) | 609625 | v1 ☐ | [PatchWork v1,0/2](https://lore.kernel.org/r/20220128195642.416743-1-longman@redhat.com)
*-*-*-*-*-*-*-*
[PatchWorkv2,0/3](https://lore.kernel.org/r/20220129205315.478628-1-longman@redhat.com)
*-*-*-*-*-*-*-*
[PatchWorkv3,0/4](https://lore.kernel.org/r/20220131192308.608837-1-longman@redhat.com)
*-*-*-*-*-*-*-*
[PatchWorkv4,0/4](https://lore.kernel.org/r/20220202203036.744010-1-longman@redhat.com)
*-*-*-*-*-*-*-*
[PatchWork v5,0/4](https://lore.kernel.org/r/20220208000532.1054311-1-longman@redhat.com) | | 2022/02/19 | Yixuan Cao | [mm/page_owner.c: record tgid](https://patchwork.kernel.org/project/linux-mm/patch/20220219180450.2399-1-caoyixuan2019@email.szu.edu.cn/) | 615993 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220219180450.2399-1-caoyixuan2019@email.szu.edu.cn) | | 2022/03/22 | Yinan Zhang | [[1/2] mm/page_owner.c: introduce vmalloc allocator for page_owner](https://patchwork.kernel.org/project/linux-mm/patch/20220322032225.1402992-1-zhangyinan2019@email.szu.edu.cn/) | 625342 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/20220322032225.1402992-1-zhangyinan2019@email.szu.edu.cn) | +| 2022/08/24 | lizhe.67@bytedance.com | [[v2] page_ext: introduce boot parameter 'early_page_ext'](https://patchwork.kernel.org/project/linux-mm/patch/20220824065058.81051-1-lizhe.67@bytedance.com/) | 670498 | v2 ☐☑ | [LORE v2,0/1](https://lore.kernel.org/r/20220824065058.81051-1-lizhe.67@bytedance.com)
*-*-*-*-*-*-*-*
[LORE v3,0/1](https://lore.kernel.org/r/20220825063102.92307-1-lizhe.67@bytedance.com)
*-*-*-*-*-*-*-*
[LORE v4,0/1](https://lore.kernel.org/r/20220825102714.669-1-lizhe.67@bytedance.com) | +| 2022/09/01 | Oscar Salvador | [page_owner: print stacks and their counter](https://patchwork.kernel.org/project/linux-mm/cover/20220901044249.4624-1-osalvador@suse.de/) | 673059 | v1 ☐☑ | [LORE v1,0/3](https://lore.kernel.org/r/20220901044249.4624-1-osalvador@suse.de) | ### 13.4.3 PROC_PAGE_MONITOR @@ -6734,6 +6777,7 @@ DAMOS 借助 debugfs 定制自己的监控处理方案. 例如, 配置 `echo "40 |:----:|:----:|:---:|:----:|:---------:|:----:| | 2021/10/01 | SeongJae Park | [Implement Data Access Monitoring-based Memory Operation Schemes](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=68536f8e01e571f553f78fa058ba543de3834452) | 实现了 DAMON 的基于数据访问监视的操作方案 (DAMOS).
DAMON 可以用作支持数据访问的内存管理优化的原语. 因此, 希望进行此类优化的用户应该运行 DAMON, 读取监视结果, 分析并优化内存管理方案.
然而, 在许多其他情况下, 用户只是希望系统对具有特定时间的特定访问频率的特定大小的内存区域应用内存管理操作. 例如, "page out a memory region than 100mib only rare visits more than 2 minutes", 或者 "Do not use THP For a memory region than 2mib rarely visits more than 1 seconds". 为了使工作更容易且不冗余, 这个补丁集实现了 DAMON 的一个新特性, 称为基于数据访问监视的操作方案 (DAMOS). 使用该特性, 用户可以以简单的方式描述常规方案, 并要求 DAMON 自行执行这些方案.
DAMOS 对于内存管理优化是准确和有用的.
1. THP 的一个实验性的基于 DAMON 的操作方案 'ethp' 减少了 76.15% 的 THP 内存开销, 同时保留了 51.25% 的 THP 加速.
2. 另一个实验性的基于 damon 的 "主动回收" 实现 "prcl", 减少了 93.38% 的 residential sets 和 23.63% 的内存占用, 而在最好的情况下只产生 1.22% 的运行时开销 (parsec3/freqmine). | v1 ☑ 5.16-rc1 | [2020/12/16 PatchWork RFC,v15.1,0/8](https://patchwork.kernel.org/project/linux-mm/cover/20201216084404.23183-1-sjpark@amazon.com)
*-*-*-*-*-*-*-*
[2021/10/01 PatchWork 0/7](https://patchwork.kernel.org/project/linux-mm/cover/20211001125604.29660-1-sj@kernel.org) | | 2021/12/21 | Changbin Du | [Add a new scheme to support demotion on tiered memory system](https://patchwork.kernel.org/project/linux-mm/cover/cover.1640077468.git.baolin.wang@linux.alibaba.com) | 现在, 在具有不同内存类型的分级内存系统上, shrink_page_list() 中的回收路径已经支持将页面降级以减慢内存节点的速度, 而不是丢弃页面. 然而, 此时快速内存节点的内存水印已经紧张, 这将增加页面降级期间的内存分配延迟. 因此, 从用户空间主动降格冷页面的新方法将更有帮助. 我们可以依靠用户空间中的 DAMON 来帮助监控快速内存节点上的冷内存, 并主动降级冷页面来降低内存节点的速度, 以保持快速内存节点处于健康状态. 这个补丁集引入了一个名为 DAMOS_DEMOTE 的新模式来支持这个特性. | v2 ☐ | [LORE 0/2](https://lore.kernel.org/all/cover.1640077468.git.baolin.wang@linux.alibaba.com) | +| 2022/09/13 | haoxin | [mm/damon: add MADV_COLLAPSE support in damos_action](https://patchwork.kernel.org/project/linux-mm/patch/20220913114735.22841-1-xhao@linux.alibaba.com/) | 676533 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220913114735.22841-1-xhao@linux.alibaba.com) | #### 13.6.4.2 DAMON-based Reclamation @@ -6811,6 +6855,9 @@ CSDN 宣传博客 [内存不超过5M, datop 在识别冷热内存及跨 numa 访 | 2022/06/09 | CGEL | [mm/ksm: provide global_force to see maximum potential merging](https://patchwork.kernel.org/project/linux-mm/patch/20220609055658.703472-1-xu.xin16@zte.com.cn/) | 648704 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220609055658.703472-1-xu.xin16@zte.com.cn) | | 2022/07/01 | CGEL | [[linux-next] mm/madvise: allow KSM hints for process_madvise](https://patchwork.kernel.org/project/linux-mm/patch/20220701084323.1261361-1-xu.xin16@zte.com.cn/) | 655733 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220701084323.1261361-1-xu.xin16@zte.com.cn) | | 2022/08/12 | CGEL | [propose auto-run mode of ksm and its tests](https://patchwork.kernel.org/project/linux-mm/cover/20220812101102.41422-1-xu.xin16@zte.com.cn/) | 667133 | v2 ☐☑ | [LORE v2,0/5](https://lore.kernel.org/r/20220812101102.41422-1-xu.xin16@zte.com.cn) | +| 2022/08/22 | CGEL | [ksm: count allocated ksm rmap_items for each process](https://patchwork.kernel.org/project/linux-mm/patch/20220822053653.204150-1-xu.xin16@zte.com.cn/) | 669627 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220822053653.204150-1-xu.xin16@zte.com.cn) | +| 2022/08/24 | CGEL | [ksm: count allocated rmap_items and update documentation](https://patchwork.kernel.org/project/linux-mm/cover/20220824040036.215002-1-xu.xin16@zte.com.cn/) | 670470 | v2 ☐☑ | [LORE v2,0/2](https://lore.kernel.org/r/20220824040036.215002-1-xu.xin16@zte.com.cn)
*-*-*-*-*-*-*-*
[LORE v5,0/2](https://lore.kernel.org/r/20220830143731.299702-1-xu.xin16@zte.com.cn) | +| 2022/08/29 | Qi Zheng | [add common struct mm_slot and use it in THP and KSM](https://patchwork.kernel.org/project/linux-mm/cover/20220829143055.41201-1-zhengqi.arch@bytedance.com) | 672053 | v1 ☐☑ | [LORE v1,0/7](https://lore.kernel.org/r/20220829143055.41201-1-zhengqi.arch@bytedance.com)
*-*-*-*-*-*-*-*
[LORE v2,0/7](https://lore.kernel.org/r/20220831031951.43152-1-zhengqi.arch@bytedance.com) | @@ -7095,7 +7142,7 @@ ZONE_MOVABLE 一个 pseudo zone, 它实际是从内核划分的某个 zone 中 |:----:|:----:|:---:|:----:|:---------:|:----:| | 2013/01/14 | Tang Chen | [Add movablecore_map boot option](https://lore.kernel.org/all/1358154925-21537-1-git-send-email-tangchen@cn.fujitsu.com) | 1358154925-21537-1-git-send-email-tangchen@cn.fujitsu.com | v5 ☐☑✓ | [LORE v5,0/5](https://lore.kernel.org/all/1358154925-21537-1-git-send-email-tangchen@cn.fujitsu.com) | | 2021/02/15 | Pavel Tatashin | [prohibit pinning pages in ZONE_MOVABLE](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=e44605a8b1aa13d892addc59ec3d416cb186c77b) | 参见 [Preserving the mobility of ZONE_MOVABLE](https://lwn.net/Articles/843326) | v11 ☑ 5.13-rc1 | [LWN v7 00/14](https://lwn.net/ml/linux-kernel/20210122033748.924330-1-pasha.tatashin@soleen.com/), [LORE v7,0/4](https://lore.kernel.org/lkml/20210122033748.924330-1-pasha.tatashin@soleen.com)
*-*-*-*-*-*-*-*
[LORE v11,00/14](https://lore.kernel.org/all/20210215161349.246722-1-pasha.tatashin@soleen.com), [关键 COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d1e153fea2a8940273174fc17733c44323d35cd5) | -| 2022/08/18 | Wupeng Ma | [watermark related improvement on zone movable](https://patchwork.kernel.org/project/linux-mm/cover/20220818090430.2859992-1-mawupeng1@huawei.com/) | 668702 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/20220818090430.2859992-1-mawupeng1@huawei.com) | +| 2022/08/18 | Wupeng Ma | [watermark related improvement on zone movable](https://patchwork.kernel.org/project/linux-mm/cover/20220818090430.2859992-1-mawupeng1@huawei.com) | 668702 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/20220818090430.2859992-1-mawupeng1@huawei.com)
*-*-*-*-*-*-*-*
[LORE v3,0/2](https://lore.kernel.org/r/20220905032858.1462927-1-mawupeng1@huawei.com) | ### 14.13.2 配置参数 @@ -7167,7 +7214,27 @@ ZONE_MOVABLE 一个 pseudo zone, 它实际是从内核划分的某个 zone 中 | 2022/03/15 | Christoph Hellwig | [staging: remove ashmem](https://patchwork.kernel.org/project/linux-mm/patch/20220315123457.2354812-1-hch@lst.de) | ashmem 的主线替代品是 memfd, 因此从 `drivers/staging` 中删除遗留代码. | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220315123457.2354812-1-hch@lst.de) | -## 14.15 Document +## 14.15 Page Walk +------- + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:----:|:---------:|:----:| +| 2022/08/22 | Rolf Eike Beer | [Minor improvements for pagewalk code](https://patchwork.kernel.org/project/linux-mm/cover/3200642.44csPzL39Z@devpool047/) | 669775 | v1 ☐☑ | [LORE v1,0/6](https://lore.kernel.org/r/3200642.44csPzL39Z@devpool047) | + + +## 14.16 Code Tagging Framework(代码标记框架) +------- + +通过代码标记标识源代码中的特定位置, 该位置在编译时生成, 可以嵌入到特定于应用程序的结构中. [Code tagging framework and applications](https://lore.kernel.org/all/20220830214919.53220-1-surenb@google.com) 代码标记框架采用了"为给定类型的对象定义一个特殊的 elf 部分, 以便我们可以在运行时遍历它们"的老技巧, 并为它创建一个适当的库. + +并提供代码标记的几个应用程序, 提供内存分配跟踪(Memory allocation tracking)、动态故障注入(Dynamic fault injection +)、延迟跟踪(Latency tracking)和改进的错误代码报告(Improved error codes). + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:---:|:----:|:---:|:----:|:---------:|:----:| +| 2022/08/30 | Suren Baghdasaryan | [Code tagging framework and applications](https://lore.kernel.org/all/20220830214919.53220-1-surenb@google.com) | TODO | v1 ☐☑✓ | [LORE v1,0/30](https://lore.kernel.org/all/20220830214919.53220-1-surenb@google.com) | + +## 14.17 Document ------- [Improving memory-management documentation](https://lwn.net/Articles/894374) diff --git a/study/kernel/00-DESCRIPTION/SCHEDULER.md b/study/kernel/00-DESCRIPTION/SCHEDULER.md index d161ab0..f2047b5 100644 --- a/study/kernel/00-DESCRIPTION/SCHEDULER.md +++ b/study/kernel/00-DESCRIPTION/SCHEDULER.md @@ -696,6 +696,16 @@ Chang 的 patch set 采用了与之前不同的方法: 允许 cgroup 将一些 | 2021/06/21 | JHuaixin Chang | [sched/fair: Burstable CFS bandwidth controller](https://lore.kernel.org/patchwork/cover/1396878) | 突发任务的带宽控制优化, 通过临时之前剩余累计的配额, 使得突发进程在当前周期的配额突然用尽之后, 还可以临时使用之前累计的配额使用, 从而降低突发任务的时延. | v6 ☑ 5.14-rc1 | [ 2020/12/17 v1](https://lore.kernel.org/patchwork/cover/1354613)
*-*-*-*-*-*-*-*
[2021/01/20 v2](https://lore.kernel.org/patchwork/cover/1368037)
*-*-*-*-*-*-*-*
[2021/01/21 v3](https://lore.kernel.org/patchwork/cover/1368746)
*-*-*-*-*-*-*-*
[2021-02-02 v4](https://lore.kernel.org/patchwork/cover/1396878)
*-*-*-*-*-*-*-*
[2021/05/20 v5](https://lore.kernel.org/patchwork/cover/1433660)
*-*-*-*-*-*-*-*
[2021/06/21 v6](https://lore.kernel.org/patchwork/cover/1449268)
*-*-*-*-*-*-*-*
[commit](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f4183717b370ad28dd0c0d74760142b20e6e7931) | | 2021/08/30 | Huaixin Chang | [Add statistics and ducument for cfs bandwidth burst](https://lore.kernel.org/patchwork/cover/1396878) | 为 Burstable CFS bandwidth 添加统计信息和文档. | v1 ☑ 5.16-rc1 | [2020/12/17 v1](https://lore.kernel.org/patchwork/cover/1396878)
*-*-*-*-*-*-*-*
[2021/08/30 LORE v2 0/2](https://lore.kernel.org/all/20210830032215.16302-1-changhuaixin@linux.alibaba.com) | | 2021/11/29 | Honglei Wang | [sched/fair: prevent cpu burst too many periods](https://lore.kernel.org/patchwork/cover/1396878) | commit f4183717b370 ("sched/fair: Introduce the burstable CFS controller") 引入了一个问题, 任务在持久性期间可能获得比配额更多的 cpu. 例如, 一个任务组的配额为每周期 100ms, 可以获得 100ms 突发, 其平均利用率约为每周期 105ms. 一旦这个组获得了一个空闲时间段, 它就有机会在公共带宽配置中获得超过其配额的 10 个或更多时间段的计算能力(例如, 100 毫秒作为时间段). 这意味着任务获得了可以 "偷走" 完成日常工作的能力, 因为所有任务都可以安排出去或睡觉, 以帮助团队获得空闲时间. cpu burst 的本来目的是帮助处理突发性工作负载. 但是, 如果一个任务组在没有突发性工作负载的情况下, 能够在持续时间内获得超过其配额的计算能力, 那么它违背了初衷. 此修补程序将突发限制为一个时段, 以便在很长时间内不会突破配额限制. 有了这个, 我们可以给任务组更多的 cpu 突发能力来处理真正的突发性工作负载, 而不必担心被恶意 "窃取". | v1 ☑ 5.16-rc1 | [LKML](https://lkml.org/lkml/2021/11/29/663) | +| 2022/05/18 | Fam Zheng | [sched: Enable root level cgroup bandwidth control](https://lore.kernel.org/all/20220518100841.1497391-1-fam.zheng@bytedance.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20220518100841.1497391-1-fam.zheng@bytedance.com) | + + +### 2.1.4 leaf_cfs_rq +------- + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:----:|:---------:|:----:| +| 2022/05/26 | Chengming Zhou | [sched/fair: optimize and simplify rq](https://lore.kernel.org/all/20220526103929.14976-1-zhouchengming@bytedance.com) | TODO | v3 ☐☑✓ | [LORE v3,0/2](https://lore.kernel.org/all/20220526103929.14976-1-zhouchengming@bytedance.com) | + ## 2.2 实时进程的组调度支持(RT Group Scheduling) @@ -1206,6 +1216,7 @@ enqueue_task() | 2018/05/30 | Srikar Dronamraju | [Skip numa distance for offline nodes](https://lore.kernel.org/patchwork/patch/1433871) | NA | v1 ☐ | [LORE 0/3](https://lore.kernel.org/lkml/20210520154427.1041031-1-srikar@linux.vnet.ibm.com) | | 2019/5/13 | Len Brown | [v6 multi-die/package topology support](https://lore.kernel.org/patchwork/patch/1433871) | 支持 DIE 拓扑层级. | v6 ☑ 5.3-rc1 | [LKML 0/19](https://lkml.org/lkml/2019/5/13/768) | | 2020/03/11 | Valentin Schneider | [sched: Instrument sched domain flags](https://lore.kernel.org/patchwork/cover/1224722) | 基于上一组补丁, 重构了 SD_FLAGS 的定义 | v4 ☑ 5.10-rc1 | [PatchWork v5,00/17](https://lore.kernel.org/patchwork/cover/1224722)
*-*-*-*-*-*-*-*
[LORE v6,00/17](https://lore.kernel.org/all/20200817113003.20802-1-valentin.schneider@arm.com) | +| 2022/07/04 | Sudeep Holla | [arch_topology: Updates to add socket support and fix cluster ids](https://lore.kernel.org/all/20220704101605.1318280-1-sudeep.holla@arm.com) | [Impact of recent CPU topology changes on Android's phantom domains](https://lpc.events/event/16/contributions/1342) | v6 ☐☑✓ | [LORE v6,0/21](https://lore.kernel.org/all/20220704101605.1318280-1-sudeep.holla@arm.com) | ### 4.1.2 3-hops 问题 @@ -3265,6 +3276,8 @@ v3.0 版本 [sched: Reduce runqueue lock contention -v6](https://git.kernel.org/ | 2013/08/09 | Oleg Nesterov | [sched: fix the theoretical signal_wake_up() vs schedule() race](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e0acd0a68ec7dbf6b7a81a87a867ebd7ac9b76c4) | 20130812170257.GA32358@redhat.com | v1 ☑✓ 3.11-rc6 | [LORE v1](https://lore.kernel.org/lkml/20130812170257.GA32358@redhat.com) | | 2015/08/03 | tip-bot for Peter Zijlstra | [sched: Introduce the 'trace_sched_waking' tracepoint](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fbd705a0c6184580d0e2fbcbd47a37b6e5822511) | NA | v1 ☑✓ 4.3-rc1 | [LORE](https://lore.kernel.org/all/tip-fbd705a0c6184580d0e2fbcbd47a37b6e5822511@git.kernel.org/) | | 2020/05/24 | Mel Gorman | [Optimise try_to_wake_up() when wakee is descheduling](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=2ebb17717550607bcd85fb8cf7d24ac870e9d762) | 唤醒时如果 wakee 进程正在睡眠或者调度(释放 CPU), 优化在 on_cpu 的自旋等待时间 | v1 ☑ 5.8-rc1 | [LORE 0/2](https://lore.kernel.org/lkml/20200524202956.27665-1-mgorman@techsingularity.net) | +| 2022/08/24 | Peng Wang | [sched/fair: select waker's cpu for wakee on sync wakeup](https://lore.kernel.org/all/1508aa17d1a169077c8d8d8c22d2bd529101af0e.1661313074.git.rocking@linux.alibaba.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/1508aa17d1a169077c8d8d8c22d2bd529101af0e.1661313074.git.rocking@linux.alibaba.com) | +| 2022/09/16 | Chen Yu | [sched/fair: Choose the CPU where short task is running during wake up](https://lore.kernel.org/all/20220915165407.1776363-1-yu.c.chen@intel.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20220915165407.1776363-1-yu.c.chen@intel.com) | ### 4.7.1.1 TTWU 中的内存屏障 @@ -4294,6 +4307,9 @@ Misfit Task 对调度器**负载均衡**做了如下改造, 参见 [commit cad68 ### 7.2.5 Energy Model ------- +#### 7.2.5.1 Energy Model +------- + EAS 依赖于 EM(Energy Model) 提供的能效模型等信息来计算能效最优的调度行为. v5.0 EAS 合入主线之前, 内核通过 init_sched_energy_costs() 解析 DTB 中 sched-energy-costs, freq-energy-model, busy-cost-data 等节点和字段来构建 CPU 的能效表. @@ -4313,6 +4329,22 @@ v5.0 EAS 合入主线之后, 引入了 EM, 各平台或者设备通过 [em_dev_r | 2021/08/12 | Viresh Kumar | [Add callback to register with energy model](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=37f188318ea3f1da75b32df3b1a19f45d9840652) | TODO | v3 ☑✓ 5.15-rc1 | [LORE v3,0/9](https://lore.kernel.org/all/cover.1628742634.git.viresh.kumar@linaro.org) | +#### 7.2.5.2 Dynamic Energy Model to handle leakage power +------- + +LPC-2022 [Dynamic Energy Model to handle leakage power](https://lpc.events/event/16/contributions/1341) + +能量模型(EM) 框架描述 CPU 功率模型, 用于任务调度决策或热控制. 它是在启动期间以受支持的方式之一设置的, 并且在正常运行期间不会修改. 测试发现: 首先芯片的功耗也受其温度的影响,首先同样的 CPU 核即使同一个频点, 在不同温度下, 其功耗也存在差异, 因此不同温度下, CPU 核的能效曲线不同(温度越高, 功耗越高, 能效越差). 其次不同芯片(微架构/工艺)对温度的敏感度也不同, 因此不同温度下, 不同 CPU 核(大核/小核)的能效曲线变化也存在差异. + +为了更好地解决诸如此类问题, ARM 提出希望允许在运行时修改EM. EM 运行时修改将引入新功能: + +1. 允许提供(启动后)每个 OPP 的总功率值, 不限于任何公式或 DTS 数据. + +2. 为芯片不同的工艺和集成方式, 允许提供适合的 SoC 的功率值. + +3. 允许在运行时根据 SoC 的当前温度修改功率值, 因为与小核和中核相比, 大核的能效对温度更敏感. + + ### 7.2.6 IPA(Thermal 管控) ------- @@ -4985,7 +5017,7 @@ PREEMPT-RT PATCH 的核心思想是最小化内核中不可抢占部分的代码 |:----:|:----:|:---:|:----:|:---------:|:----:| | 2017/05/12 | Rohit Jain | [Interrupt Aware Scheduler](https://lkml.org/lkml/2017/5/12/512) | NA | v1 ☐ | [LORE 0/5](https://lore.kernel.org/lkml/1494612267-29465-1-git-send-email-rohit.k.jain@oracle.com) | | 2021/09/20 | Libo Chen | [Overeager pulling from wake_wide() in interrupt heavy workloads](https://lkml.org/lkml/2017/5/12/512) | 当前 wake_affine() 机制并不感知 ISR 唤醒的场景, 在这种场景下, 在中断上下文发起唤醒 wakee 进程的请求, 其实的 waker 并不是真正的 waker, 而是因为唤醒发生时中断正好打断了这个 waker 进程. wake_affine() 机制仍旧比较 waker/wakee 进程的 wakee_flips 到导致错误的唤醒. 作者讲了一个 IST 唤醒的场景, 导致 CPU 唤醒到中断所在的 NUMA NODE, 但是系统中其他 NODE 却是空闲的. | v1 ☐ | [Slide](https://linuxplumbersconf.org/event/11/contributions/1044/attachments/801/1508/lpc21_wakeup_pulling_libochen.pdf) | -| 2022/08/22 | John Stultz | [Softirq -rt Optimizations](https://lore.kernel.org/all/20220822190501.2171100-1-jstultz@google.com) | TODO | v2 ☐☑✓ | [LORE v2,0/2](https://lore.kernel.org/all/20220822190501.2171100-1-jstultz@google.com) | +| 2022/08/22 | John Stultz | [Softirq -rt Optimizations](https://lore.kernel.org/all/20220822190501.2171100-1-jstultz@google.com) | TODO | v2 ☐☑✓ | [LORE v2,0/2](https://lore.kernel.org/all/20220822190501.2171100-1-jstultz@google.com)
*-*-*-*-*-*-*-*
[LORE v2,0/2](https://lore.kernel.org/all/20220822190501.2171100-1-jstultz@google.com) | | 2020/12/04 | Thomas Gleixner | [softirq: Make it RT aware](https://lore.kernel.org/all/20201204170151.960336698@linutronix.de) | TODO | v2 ☐☑✓ | [LORE v2,0/9](https://lore.kernel.org/all/20201204170151.960336698@linutronix.de) | @@ -5015,6 +5047,8 @@ PREEMPT-RT PATCH 的核心思想是最小化内核中不可抢占部分的代码 | 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) | +| 2022/09/13 | LPC-2022 上关于 latency nice 的演讲: [Latency hints for CFS task](https://lpc.events/event/16/contributions/1273) | NA | + 2020 年, Parth Shah 提出了 latency nice 的概念. 旨在对应用的延迟进行感知和标记, 降低延迟敏感应用程序的调度延迟, 使其更快地获得 CPU 时间. latency_nice 值与现有 nice 值相对应, 介于 -20 和 19 之间. 数字越低, 优先级越高. @@ -5049,7 +5083,7 @@ enqueue_task_fair() |:-----:|:----:|:----:|:----:|:------------:|:----:| | 2020/02/28 | Parth Shah | [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)
*-*-*-*-*-*-*-*
[LORE v5,0/4](https://lore.kernel.org/all/20200228090755.22829-1-parth@linux.ibm.com) | | 2020/05/07 | Parth Shah | [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/09 | Vincent Guittot | [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)
*-*-*-*-*-*-*-*
[2022/05/12 LORE v2,0/7](https://lore.kernel.org/all/20220512163534.2572-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/09/09 LORE v3,0/8](https://lore.kernel.org/all/20220909130309.25458-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[LORE v4,0/8](https://lore.kernel.org/all/20220916080305.29574-1-vincent.guittot@linaro.org) | +| 2022/09/16 | Vincent Guittot | [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)
*-*-*-*-*-*-*-*
[2022/05/12 LORE v2,0/7](https://lore.kernel.org/all/20220512163534.2572-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/09/09 LORE v3,0/8](https://lore.kernel.org/all/20220909130309.25458-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/09/16 LORE v4,0/8](https://lore.kernel.org/all/20220916080305.29574-1-vincent.guittot@linaro.org) | ### 8.9.2 Xen CPU Scheduling ------- @@ -5177,11 +5211,56 @@ CONFIG_HUAWEI_SCHED_VIP 被标记为 vip_prio, 为 VIP 线程提供了近似于 ### 10.1.2 进程退出 ------- +#### 10.1.2.1 进程退出时的处理 +------- + | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| -| 2021/11/18 | Sebastian Andrzej Siewior | [kernel/fork: Move thread stack free otu of the scheduler path](https://lore.kernel.org/all/20211118143452.136421-1-bigeasy@linutronix.de) | [sched: Delay task stack freeing on RT](https://lore.kernel.org/all/20210928122411.593486363@linutronix.de) 的完善方案. 在 finish_task_switch() 完成后任务可能会死亡并退出, 这时候虽然快速回收任务堆栈有利于繁重的工作负载, 但这是内核实时性延迟的源头. 因此, 延迟启用 RT 的内核上的堆栈清理. | v1 ☐ | [PatchWork 0/8](https://lore.kernel.org/all/20211118143452.136421-1-bigeasy@linutronix.de) | +| 2021/11/18 | Sebastian Andrzej Siewior | [kernel/fork: Move thread stack free out of the scheduler path](https://lore.kernel.org/all/20211118143452.136421-1-bigeasy@linutronix.de) | [sched: Delay task stack freeing on RT](https://lore.kernel.org/all/20210928122411.593486363@linutronix.de) 的完善方案. 在 finish_task_switch() 完成后任务可能会死亡并退出, 这时候虽然快速回收任务堆栈有利于繁重的工作负载, 但这是内核实时性延迟的源头. 因此, 延迟启用 RT 的内核上的堆栈清理. | v1 ☐ | [PatchWork 0/8](https://lore.kernel.org/all/20211118143452.136421-1-bigeasy@linutronix.de) | | 2021/11/18 | Linus Torvalds | [task: Making tasks on the runqueue rcu protected](https://lore.kernel.org/all/20211118143452.136421-1-bigeasy@linutronix.de) | [sched: Delay task stack freeing on RT](https://lore.kernel.org/all/20210928122411.593486363@linutronix.de) 的完善方案. 在 finish_task_switch() 完成后任务可能会死亡并退出, 这时候虽然快速回收任务堆栈有利于繁重的工作负载, 但这是内核实时性延迟的源头. 因此, 延迟启用 RT 的内核上的堆栈清理. | v1 ☐ | [PatchWork 0/8](https://lore.kernel.org/all/20211118143452.136421-1-bigeasy@linutronix.de) | +#### 10.1.2.2 reaper 进程 +------- + +linux 下, reaper 线程用于释放已经执行结束的线程所占用的资源. 通常这个工作由父进程通过 wait() 或者 waitpid() 完成. 在 linux 中, 父进程死亡后, 需要由其他 reaper 进程来完成这项工作. 粗略地说: + +1. 如果父亲还有其他活着的线索, 这条线索就是 reaper. + +2. 否则, 如果有一个父亲的祖先(中间没有 pidns 级别变化), 同时它有 PR_SET_CHILD_SUBREAPER 设置, 这个祖先将是一个 reaper. + +3. 否则, 父亲的祖先将成为孩子们的 reaper. + + + +### 10.1.3 进程冻结与恢复 +------- + +CRIU 是一个在 Linux 用户空间 (userspace) 上实现了 checkpoint/restore 功能的软件工具. + +Checkpoint/Restore In Userspace 或者 CRIU 是一个软件工具, 通过使用这个工具, 你可以冻结或者部分冻结一个应用程序的执行, 并将其执行状态保存到磁盘中一系列文件中. 你可以使用这些文件来恢复继续运行这个应用程序, 从之前被冻结的点上开始执行. 与其他软件不同的是 CRIU 最大的特点是在用户空间中执行. + + +对于 CRIU 来说, 社区传统的 reaper 管理方式存在较多问题. 当 CRIU 开始转储进程时, 它不知道进程及其资源的创建顺序. 进程可以拥有以下资源: + +a. 只能在克隆进程时继承; + +b. 只能由特定进程创建; + +c. 在多个进程之间共享(例如进程会话). + +对于这样的资源, CRIU 恢复需要重新创建这样的进程创建顺序, 同时创建所需的进程树拓扑并允许继承所有资源. + +当进程重养育涉及到子-子-收割者时, 可以在进程树中大量混合进程, 这样就不容易明显地恢复一切正确. + +所以我们引入 CABD(最近的在世后代) 来帮助 CRIU 克服这个问题: + +我们希望将流程放到另一个树中——CABA树. 这棵树不会以任何方式影响重新养育或进程创建, 只是向 CRIU 提供了一个新信息, 以便我们可以了解重新养育的子进程是从哪里被重新养育的. 尽管原来的父进程已经死亡, 可能也是父进程的父进程, 但我们仍然可以获得关于仍然活着的进程的信息, 它最初是进程序列(已经死亡的进程)的父进程, 它通向我们—— CABA. + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:----:|:---------:|:----:| +| 2022/09/08 | Pavel Tikhomirov | [Add CABA tree to task_struct](https://patchwork.kernel.org/project/linux-mm/patch/20220908220944.822942-1-ptikhomirov@virtuozzo.com) | 675404 | v4 ☐☑ | [LORE v4,0/2](https://lore.kernel.org/all/20220908220944.822942-1-ptikhomirov@virtuozzo.com) | + + ## 10.3 IPC ------- @@ -5394,7 +5473,7 @@ B 站 Plugsched 介绍视频 [纯干货解读：Plugsched, 首次实现 Linux ke | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:---:|:----:|:---:|:----:|:---------:|:----:| -| 2022/09/08 | Waiman Long | [sched: Persistent user requested affinity](https://lore.kernel.org/all/20220908194121.858462-1-longman@redhat.com) | COMMIT b90ca8badbd1 ("sched: Introduce task_struct::user_cpus_ptr to track requested affinity") 引入了 user_cpus_ptr (狭义地)来保持 CPU 的亲和性不受非对称 CPU 设置的影响.
该补丁集扩展了 user_cpus_ptr, 通过 sched_setaffinity() API 存储用户请求的 CPU 亲和性. 有了这些可用的信息, 它将使 cpuset 和 set_cpus_allowed_ptr() 的其他调用者(如 HOTPLUG)能够在当前 cpuset 的 CPUs 约束内保持 CPU 的亲和性尽可能接近用户想要的. 否则, CPU 层次结构的更改或热插拔事件可能会将受影响 CPU 集中的任务的 cpumask 重置为默认的 cpuset cpus 值, 即使这些任务具有用户之前显式设置的 CPU 亲和性.
这还意味着, 成功调用 sched_setaffinity() 之后, user_cpus_ptr 将继续分配, 直到任务退出, 除非在一些罕见的情况下. | v8 ☐☑✓ | [LORE v8,0/7](https://lore.kernel.org/all/20220908194121.858462-1-longman@redhat.com) | +| 2022/09/08 | Waiman Long | [sched: Persistent user requested affinity](https://lore.kernel.org/all/20220908194121.858462-1-longman@redhat.com) | COMMIT b90ca8badbd1 ("sched: Introduce task_struct::user_cpus_ptr to track requested affinity") 引入了 user_cpus_ptr (狭义地)来保持 CPU 的亲和性不受非对称 CPU 设置的影响.
该补丁集扩展了 user_cpus_ptr, 通过 sched_setaffinity() API 存储用户请求的 CPU 亲和性. 有了这些可用的信息, 它将使 cpuset 和 set_cpus_allowed_ptr() 的其他调用者(如 HOTPLUG)能够在当前 cpuset 的 CPUs 约束内保持 CPU 的亲和性尽可能接近用户想要的. 否则, CPU 层次结构的更改或热插拔事件可能会将受影响 CPU 集中的任务的 cpumask 重置为默认的 cpuset cpus 值, 即使这些任务具有用户之前显式设置的 CPU 亲和性.
这还意味着, 成功调用 sched_setaffinity() 之后, user_cpus_ptr 将继续分配, 直到任务退出, 除非在一些罕见的情况下. | v8 ☐☑✓ | [LORE v8,0/7](https://lore.kernel.org/all/20220908194121.858462-1-longman@redhat.com)
*-*-*-*-*-*-*-*
[LORE v9,0/7](https://lore.kernel.org/all/20220916183217.1172225-1-longman@redhat.com)
*-*-*-*-*-*-*-*
[LORE v10,0/5](https://lore.kernel.org/all/20220922180041.1768141-1-longman@redhat.com) | ## 11.5 其他 diff --git a/study/kernel/00-DESCRIPTION/VIRT.md b/study/kernel/00-DESCRIPTION/VIRT.md index b29f705..d67a909 100644 --- a/study/kernel/00-DESCRIPTION/VIRT.md +++ b/study/kernel/00-DESCRIPTION/VIRT.md @@ -182,6 +182,17 @@ Anbox 使用 Linux 命名空间 (user, pid, uts, net, mount, ipc) 在容器中 [Android apps on Linux with Waydroid](https://lwn.net/Articles/901459) + + +# 8 MEMORY +------- + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:---:|:----:|:---:|:----:|:---------:|:----:| +| 2022/08/23 | Yosry Ahmed | [KVM: mm: count KVM mmu usage in memory stats](https://patchwork.kernel.org/project/linux-mm/cover/20220823004639.2387269-1-yosryahmed@google.com/) | 669960 | v7 ☐☑ | [LORE v7,0/4](https://lore.kernel.org/r/20220823004639.2387269-1-yosryahmed@google.com) | +| 2022/09/15 | Chao Peng | [KVM: mm: fd-based approach for supporting KVM](https://patchwork.kernel.org/project/linux-mm/cover/20220915142913.2213336-1-chao.p.peng@linux.intel.com/) | 677360 | v8 ☐☑ | [LORE v8,0/8](https://lore.kernel.org/r/20220915142913.2213336-1-chao.p.peng@linux.intel.com) | + +
* 本作品/博文 ( [AderStep-紫夜阑珊-青伶巷草 Copyright ©2013-2017](http://blog.csdn.net/gatieme) ), 由 [成坚(gatieme)](http://blog.csdn.net/gatieme) 创作.