From d248da5294c3bbc9f04dfe075e59a98939bbc070 Mon Sep 17 00:00:00 2001 From: Cheng Jian Date: Wed, 22 Jun 2022 20:58:08 +0800 Subject: [PATCH] description/memory: update patchwork series to 20220530 --- study/kernel/00-DESCRIPTION/ARCH.md | 35 +++++++++++++++++ study/kernel/00-DESCRIPTION/BPF.md | 1 + study/kernel/00-DESCRIPTION/DEBUGGING.md | 2 +- study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md | 38 ++++++++++++++----- study/kernel/00-DESCRIPTION/SCHEDULER.md | 15 ++++++-- 5 files changed, 77 insertions(+), 14 deletions(-) diff --git a/study/kernel/00-DESCRIPTION/ARCH.md b/study/kernel/00-DESCRIPTION/ARCH.md index fb5ca30..85517c4 100644 --- a/study/kernel/00-DESCRIPTION/ARCH.md +++ b/study/kernel/00-DESCRIPTION/ARCH.md @@ -65,6 +65,8 @@ blogexcerpt: 虚拟化 & KVM 子系统 ### 1.1.1 split lock detect ------- +[字节跳动技术团队的博客--深入剖析 split locks，i++ 可能导致的灾难](https://blog.csdn.net/ByteDanceTech/article/details/124701175) + 拆分锁是指原子指令对跨越多个高速缓存行的数据进行操作. 由于原子性质, 在两条高速缓存行上工作时需要全局总线锁, 这反过来又会对整体系统性能造成很大的性能影响. 当原子指令跨越多个 cache line, 并且需要确保原子性所需的总线锁时, 就会发生拆分总线锁. 这些拆分锁总线至少比单个 cacheline 内的原子操作多需要 1000 个 cycles. 在锁定总线期间, 其他 CPU 或 BUS 代理要求控制 BUS 的请求被阻止, 阻止其他 CPU 的 BUS 访问, 加上配置总线锁定协议的开销不仅会降低一个 CPU 的性能, 还会降低整体系统性能. @@ -91,6 +93,7 @@ v5.7 引入了拆分锁检测的支持, 这依赖于 x86_64 intel CPU 遇到拆 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2020/01/26 | Luck, Tony | [x86/split_lock: Enable split lock detection by kernel](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6650cdd9a8ccf00555dbbe743d58541ad8feb6a7) | 支持 拆分锁检测(split_lock_detect). | v17 ☑✓ v5.7-rc1| [LORE](https://lore.kernel.org/all/20200126200535.GB30377@agluck-desk2.amr.corp.intel.com) | +| 2020/11/06 | Chenyi Qiang | [Add bus lock VM exit support](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=c32b1b896d2ab30ac30bc39194bac47a09f7f497) | 虚拟化支持 bus lock 检测. | v5 ☑✓ 5.12-rc1 | [LORE v5,0/4](https://lore.kernel.org/all/20201106090315.18606-1-chenyi.qiang@intel.com) | | 2021/03/22 | Fenghua Yu | [x86/bus_lock: Enable bus lock detection](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=ebca17707e38f2050b188d837bd4646b29a1b0c2) | 拆分锁检测支持 Bus Lock. 参见 [Intel's Bus Lock Detection Might Be Ready For The Mainline Linux Kernel](https://www.phoronix.com/scan.php?page=news_item&px=Intel-Bus-Lock-Detection-2021) | v6 ☑✓ 5.13-rc1 | [LORE v6,0/3](https://lore.kernel.org/all/20210322135325.682257-1-fenghua.yu@intel.com) | | 2021/04/19 | Fenghua Yu | [x86/bus_lock: Set rate limit for bus lock](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=d28397eaf4c27947a1ffc720d42e8b3a33ae1e2a) | 通过限制总线锁的速率而不是杀死进程来缓解拆分锁带来的问题. | v1 ☑✓ 5.14-rc1 | [Patchwork 0/4](https://lore.kernel.org/all/20210419214958.4035512-1-fenghua.yu@intel.com) | | 2022/03/10 | Tony Luck | [Make life miserable for split lockers](https://lore.kernel.org/all/20220310204854.31752-1-tony.luck@intel.com) | 通过强制用户空间对拆分锁进行顺序访问. 在解决问题的同时, 也确保了在这些条件下整体系统性能更好. 参见 [Linux 5.19 To "Make Life Miserable" In Slowing Down Bad Behaving Split-Lock Apps](https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.19-Split-Lock). | v2 ☐☑✓ | [LORE v2,0/2](https://lore.kernel.org/all/20220310204854.31752-1-tony.luck@intel.com) | @@ -308,6 +311,7 @@ ARM & Linaro [Kernel versions highlights](https://developer.arm.com/tools-and-so ARM64 架构文档地址下载 [cpu-architecture](https://developer.arm.com/architectures/cpu-architecture) +[ARM Processors 网站](https://developer.arm.com/Processors/Cortex-A710) 列出了 ARM 公版的所有 CPU 架构. [Memory Layout on AArch64 Linux](https://www.kernel.org/doc/html/latest/arm64/memory.html) @@ -792,6 +796,37 @@ Rosetta 是一个转译过程, 允许用户在 Apple Silicon 上运行包含 x86 [macOS 13 Adding Ability To Use Rosetta In ARM Linux VMs For Speedy x86_64 Linux Binaries](https://www.phoronix.com/scan.php?page=news_item&px=macOS-13-Rosetta-Linux-Binaries) + +## 6.8 芯片设计 +------- + +Tachyum 宣布其设计一款完全通用的处理器 Prodigy T16128, 预计 2023 年发布, [Tachyum's Monster 128 Core 5.7GHz 'Universal Processor' Does Everything](https://www.tomshardware.com/news/tachyum-128-core-all-purpose-cpu), 号称一款芯片上可以同时运行通用计算, 高性能计算以及 AI 等业务和负载, 原生支持 x86, ARM, RISC-V 和 ISA 的二进制. + +Google Google 推出[芯片设计门户网站](https://developers.google.com/silicon), 计划名为 Open MPW Shuttle Program, 允许任何人利用开源 PDK 和其他开源 EDA 工具来提交开源集成电路设计, Google 会为他们免费制造, 不会收取任何费用。虽然芯片制造是在 130 纳米工艺（SKY130）上完成的, 但这一计划对资金有限的开源硬件项目具有巨大的推动作用. + + +中国科学院大学("国科大")的 ["一生一芯" 计划](https://ysyx.org). + + +## 6.9 预取 +------- + +富士通添加了 sysfs 接口来控制 CPU L2 Cache/DCU 等硬件的预取行为, 以便从用户空间对 A64FX 处理器和 x86 行性能调优. + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:---:|:----:|:---:|:----:|:---------:|:----:| +| 2022/06/07 | Kohei Tarumizu | [Add hardware prefetch control driver for A64FX and x86](https://lore.kernel.org/all/20220607120530.2447112-1-tarumizu.kohei@fujitsu.com) | TODO | v5 ☐☑✓ | [LORE v5,0/6](https://lore.kernel.org/all/20220607120530.2447112-1-tarumizu.kohei@fujitsu.com) | + + +openEuler 提供了 [openEuler/prefetch_tuning](https://gitee.com/openeuler/prefetch_tuning) 提供了鲲鹏芯片设计的渔区相关寄存器读写接口, 用于读取和配置在 CPU 的硬件层面的芯片性能调优参数. 内核中更是提供了 [CONFIG_HISILICON_ERRATUM_HIP08_RU_PREFETCH](https://gitee.com/openeuler/kernel/commit/13ab4b7fa6f92eb9819a01129c4e4a0a9c401ee8) 来在启动时配置预期. + + +## 6.10 Software Branch Hinting +------- + +[Software Branch Hinting](https://labs.engineering.asu.edu/mps-lab/research-themes/low-power-computing/sbh/) + +
* 本作品/博文 ( [AderStep-紫夜阑珊-青伶巷草 Copyright ©2013-2017](http://blog.csdn.net/gatieme) ), 由 [成坚(gatieme)](http://blog.csdn.net/gatieme) 创作. diff --git a/study/kernel/00-DESCRIPTION/BPF.md b/study/kernel/00-DESCRIPTION/BPF.md index 750545c..cfbbc00 100644 --- a/study/kernel/00-DESCRIPTION/BPF.md +++ b/study/kernel/00-DESCRIPTION/BPF.md @@ -70,6 +70,7 @@ blogexcerpt: 虚拟化 & KVM 子系统 [狄卫华--eBPF 技术全面介绍 -- 历史、现在、未来(阅码场--直播回放)](https://shop.yomocode.com/live_pc/l_627e47efe4b0cedf38b1850f), 直播视频解读 [一文读懂 eBPF 的前世今生](https://mp.weixin.qq.com/s/ww510TUdLG8jd6VzfQnjxw) +[bpftrace Cheat Sheet](https://www.brendangregg.com/BPF/bpftrace-cheat-sheet.html) # 2 工作流程 ------- diff --git a/study/kernel/00-DESCRIPTION/DEBUGGING.md b/study/kernel/00-DESCRIPTION/DEBUGGING.md index 28b5d20..251c230 100644 --- a/study/kernel/00-DESCRIPTION/DEBUGGING.md +++ b/study/kernel/00-DESCRIPTION/DEBUGGING.md @@ -520,7 +520,7 @@ Mold 是目前 Unix 链接器的现代替代品, 已经达到了 1.0 版本. 由 2021 年 12 月 [Mold 1.0 发布](https://www.phoronix.com/scan.php?page=news_item&px=Mold-1.0-Released), 作为非常有前途的高性能链接器, 是当前主流编译器等(如 GNU 的 Gold 和 LLVM 的 LLD) 首选替代方案. 随即 GCC 12 宣布增加了[对 Mold 的支持](https://www.phoronix.com/scan.php?page=news_item&px=GCC-12-Mold-Linker). 紧接着 Mold 宣布 1.0.1 将[维护 1 年](https://www.phoronix.com/scan.php?page=news_item&px=Mold-1.0.1-Released), 成为事实上的 LTS 版本. - +2022 年 6 月 Mold 1.3 继续对 LTO 进行了优化. 参见 phoronix 报道 [Mold 1.3 High Speed Linker Released With LTO Improvements](https://www.phoronix.com/scan.php?page=news_item&px=Mold-1.3-Released). # 14 FTRACE ------- diff --git a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md index 6575327..5491141 100644 --- a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md +++ b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md @@ -324,6 +324,9 @@ Linux 一开始是在一台i386上的机器开发的, i386 的硬件页表是2 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2022/04/29 | Matthew Wilcox (Oracle) | [Folio patches for 5.19](https://patchwork.kernel.org/project/linux-mm/cover/20220429192329.3034378-1-willy@infradead.org/) | 637111 | v1 ☐☑ | [LORE v1,0/21](https://lore.kernel.org/r/20220429192329.3034378-1-willy@infradead.org)
*-*-*-*-*-*-*-*
[LORE v2,0/26](https://lore.kernel.org/r/20220504182857.4013401-1-willy@infradead.org) | +| 2022/05/27 | Miaohe Lin | [mm/vmscan: don't try to reclaim freed folios](https://patchwork.kernel.org/project/linux-mm/patch/20220527080451.48549-1-linmiaohe@huawei.com/) | 645512 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220527080451.48549-1-linmiaohe@huawei.com) | +| 2022/05/28 | FanJun Kong | [mm/slub: replace alloc_pages with folio_alloc](https://patchwork.kernel.org/project/linux-mm/patch/20220528161157.3934825-1-bh1scw@gmail.com/) | 645771 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220528161157.3934825-1-bh1scw@gmail.com) | +| 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) | ### 1.4.2 Pulling slabs out of struct page @@ -521,6 +524,7 @@ 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)
*-*-*-*-*-*-*-*
[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)
*-*-*-*-*-*-*-*
[LORE v7,0/6](https://lore.kernel.org/r/20220507110114.4128854-1-tongtiangen@huawei.com) | +| 2022/05/31 | Matthew Wilcox | [Allocate and free frozen pages](https://patchwork.kernel.org/project/linux-mm/cover/20220531150611.1303156-1-willy@infradead.org/) | 我们已经有了冻结页面的能力(安全地将其引用计数减少到 0). 一些用户(如 slab)希望能够分配冻结的页面并避免触及引用计数. 它还可以避免在这些页面上进行虚假的临时引用. | v1 ☐☑ | [LORE v1,0/6](https://lore.kernel.org/r/20220531150611.1303156-1-willy@infradead.org) | ### 1.7.4 Local Page Tables ------- @@ -612,7 +616,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) | +| 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) | ## 1.9 page attributes @@ -1210,7 +1214,7 @@ PCP 页面对内存碎片可能有潜在的冲击, 它可能会意外导致碎 | 2021/09/21 | Nicolas Saenz Julienne | [mm: Remote LRU per-cpu pagevec cache/per-cpu page list drain support](https://patchwork.kernel.org/project/linux-mm/cover/20210921161323.607817-1-nsaenzju@redhat.com) | 本系列介绍了 mm/swap.c 的每个 CPU LRU pagevec 缓存和 mm/page_alloc 的每个 CPU 页面列表的另一种锁定方案 remote_pcpu_cache_access, 这将允许远程 CPU 消耗它们.
目前, 只有一个本地 CPU 被允许更改其每个 CPU 列表, 并且当进程需要它时, 它会按需这样做 (通过在本地 CPU 上排队引流任务).
大多数系统会迅速处理这个问题, 但它会给 NOHZ_FULL CPU 带来问题, 这些 CPU 无法在不破坏其功能保证(延迟、带宽等) 的情况下接受任何类型的中断. 如果这些进程能够远程耗尽列表本身, 就可以与隔离的 CPU 共存, 但代价是更多的锁约束.
通过 static key remote_pcpu_cache_access 来控制该特性的开启与否, 对于非 nohz_full 用户来说, 默认禁用它, 这保证了最小的功能或性能退化. 而只有当 NOHZ_FULL 的初始化过程成功时, 该特性才会被启用. | v2 ☐ | [2021/09/21 PatchWork 0/6](https://patchwork.kernel.org/project/linux-mm/cover/20210921161323.607817-1-nsaenzju@redhat.com)
*-*-*-*-*-*-*-*
[2021/11/03 PatchWork v2,0/3](https://patchwork.kernel.org/project/linux-mm/cover/20211103170512.2745765-1-nsaenzju@redhat.com) | | 2022/02/08 | Nicolas Saenz Julienne | [mm/page_alloc: Remote per-cpu lists drain support](https://lore.kernel.org/all/20220208100750.1189808-1-nsaenzju@redhat.com) | 参见 [Remote per-CPU page list draining](https://lwn.net/Articles/884448) | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20220208100750.1189808-1-nsaenzju@redhat.com) | | 2022/02/24 | Suren Baghdasaryan | [mm: page_alloc: replace mm_percpu_wq with kthreads in drain_all_pages](https://lore.kernel.org/all/20220225012819.1807147-1-surenb@google.com) | 20220225012819.1807147-1-surenb@google.com | v1 ☐☑✓ | [LORE v1,0/1](https://lore.kernel.org/all/20220225012819.1807147-1-surenb@google.com) | -| 2022/05/09 | Mel Gorman | [Drain remote per-cpu directly](https://patchwork.kernel.org/project/linux-mm/cover/20220420095906.27349-1-mgorman@techsingularity.net) | 直接使用了 IRQ 安全的 local_lock() 保护 PCP lists. local_lock 本身可以防止迁移, 禁用 IRQ 可以防止在页面分配过程中由于被中断打断而造成异常. 一个自旋锁 [spinlock](https://lore.kernel.org/all/20220509130805.20335-6-mgorman@techsingularity.net) 被添加到 per_cpu_pages 结构中, 以保护列表的内容, 而 local_lock_irq 则进一步阻止迁移和 IRQ 重入. 从而允许一个 CPU 安全地清空远程 PCP lists. | v1 ☐☑ | [2022/04/20 LORE v1,0/6](https://lore.kernel.org/r/20220420095906.27349-1-mgorman@techsingularity.net)
*-*-*-*-*-*-*-*
[2022/05/09 LORE v2,0/6](https://lore.kernel.org/r/20220509130805.20335-1-mgorman@techsingularity.net)
*-*-*-*-*-*-*-*
[LORE v3,0/6](https://lore.kernel.org/r/20220512085043.5234-1-mgorman@techsingularity.net) | +| 2022/05/09 | Mel Gorman | [Drain remote per-cpu directly](https://patchwork.kernel.org/project/linux-mm/cover/20220420095906.27349-1-mgorman@techsingularity.net) | 直接使用了 IRQ 安全的 local_lock() 保护 PCP lists. local_lock 本身可以防止迁移, 禁用 IRQ 可以防止在页面分配过程中由于被中断打断而造成异常. 一个自旋锁 [spinlock](https://lore.kernel.org/all/20220509130805.20335-6-mgorman@techsingularity.net) 被添加到 per_cpu_pages 结构中, 以保护列表的内容, 而 local_lock_irq 则进一步阻止迁移和 IRQ 重入. 从而允许一个 CPU 安全地清空远程 PCP lists. | v1 ☐☑ | [2022/04/20 LORE v1,0/6](https://lore.kernel.org/r/20220420095906.27349-1-mgorman@techsingularity.net)
*-*-*-*-*-*-*-*
[2022/05/09 LORE v2,0/6](https://lore.kernel.org/r/20220509130805.20335-1-mgorman@techsingularity.net)
*-*-*-*-*-*-*-*
[LORE v3,0/6](https://lore.kernel.org/r/20220512085043.5234-1-mgorman@techsingularity.net)
*-*-*-*-*-*-*-*
[LORE v1,0/7](https://lore.kernel.org/r/20220613125622.18628-1-mgorman@techsingularity.net) | #### 2.2.5.3 PCP Batch-Free free_pcppages_bulk @@ -3242,7 +3246,11 @@ v8 和 v9 测试时, 测试场景进一步扩大, 参见 [MGLRU Continues To Loo v10 基本趋于稳定, 已经尝试发送合并请求 [LWN: Merging the multi-generational LRU](https://lwn.net/Articles/894859). 参见 [MGLRU Revised A 10th Time For Improving Linux Performance, Better Under Memory Pressure](https://www.phoronix.com/scan.php?page=news_item&px=MGLRU-v10). -至此, MGLRU 已经在 Cassandra, Hadooop, MySQL/MariaDB, Memcached, MongoDB, PostgreSQL, Redis 等场景都获得了较好的结果. v11 版本时, Google 已经向数千万 Chrome OS 用户和大约 100 万 Android 用户推出了 MGLRU. Google 的 Fleetwide 分析显示, 除了其他 UX 指标的改进之外, kswapd CPU 使用率总体降低了 40%, 其中第 75 百分位的 low-memory kills 次数减少了 85%, 第 50 百分位的应用启动时间减少了 18%. [MGLRU 再次为有希望的 Linux 性能改进而加速](https://www.phoronix.com/scan.php?page=news_item&px=MGLRU-v11-Linux-Perf). +至此, MGLRU 已经在 Cassandra, Hadooop, MySQL/MariaDB, Memcached, MongoDB, PostgreSQL, Redis 等场景都获得了较好的结果. + +v11 版本时, Google 已经向数千万 Chrome OS 用户和大约 100 万 Android 用户推出了 MGLRU. Google 的 Fleetwide 分析显示, 除了其他 UX 指标的改进之外, kswapd CPU 使用率总体降低了 40%, 其中第 75 百分位的 low-memory kills 次数减少了 85%, 第 50 百分位的应用启动时间减少了 18%. [MGLRU 再次为有希望的 Linux 性能改进而加速](https://www.phoronix.com/scan.php?page=news_item&px=MGLRU-v11-Linux-Perf). + +v12 版本已经没有什么特性变更, 仅仅是一些 bugfix, 参见 phoronix 报道 [Performance-Boosting MGLRU Patches Updated Against Current Linux 5.19 State](https://www.phoronix.com/scan.php?page=news_item&px=MGLRU-v12-For-Linux-5.19-rc). * 实现 @@ -3251,7 +3259,7 @@ v10 基本趋于稳定, 已经尝试发送合并请求 [LWN: Merging the multi-g | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| -| 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) | +| 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) | @@ -3406,6 +3414,7 @@ inactive LRU list 应该足够小, 这样 VM 就不需要做太多的工作, 但 | 2009/07/16 | Konstantin Khlebnikov | [throttle direct reclaim when too many pages are isolated already (v3)](https://lore.kernel.org/lkml/20090715235318.6d2f5247@bree.surriel.com) | 当隔离的页面过多时限制直接回收的进行.
当太多进程进入直接回收时, 所有页面都有可能从 LRU 上取下. 这样做的一个结果是, 页面回收代码中的下一个进程认为已经没有可回收的页面了, 并触发内存不足终止.
这个问题的一个解决方案是永远不要让太多进程进入页面回收路径, 从而导致整个 LRU 被清空. 将系统限制为仅隔离一半的非活动列表进行回收应该是安全的.
这个补丁引入了 too_many_isolated() 函数. | v3 ☑✓ 2.6.32-rc1 | [PatchWork v3](https://lore.kernel.org/lkml/20090715235318.6d2f5247@bree.surriel.com), [commit](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=35cd78156c499ef83f60605e4643d5a98fef14fd) | | 2009/11/25 | Rik van Riel | [vmscan: do not evict inactive pages when skipping an active list scan](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b39415b2731d7dec5e612d2d12595da82399eedf) | AIM7运行时, 发现最近的内核提前触发了匿名页的换出(swapping out). 这是由于 shrink_list() 中[在 !inactive_anon_is_low() 的时候依旧执行了 shrink_inactive_list()](https://elixir.bootlin.com/linux/v2.6.32/source/mm/vmscan.c), 而我们真正想做的是让一些匿名页面提前老化, 以便它们在非活动列表上有额外的时间被引用. 显而易见的解决办法是, 当我们调用 shrink_list() 来扫描一个活动列表时, 确保回收时不会落入扫描/回收非活动页面的陷阱. 因此如果 shrink 的是 active LRUs, 则不要再回收 inactive LRUs. 这个更改是安全的, 因为 [shrink_zone()](https://elixir.bootlin.com/linux/v2.6.32/source/mm/vmscan.c#L1630) 中的循环确保在应该回收时仍然会收缩 anon 和文件非活动列表.
这个补丁引入了 [inactive_list_is_low()](https://elixir.bootlin.com/linux/v2.6.33/source/mm/vmscan.c#L1464). | v1 ☑✓ 2.6.33-rc1 | [PatchWork](https://lore.kernel.org/patchwork/patch/179466) | | 2012/04/26 | Konstantin Khlebnikov | [mm: replace struct mem_cgroup_zone with struct lruvec](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=f9be23d6da035241b7687b25e64401171986dcef) | memcg naturalization -rc5](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=6b208e3f6e35aa76d254c395bdcd984b17c6b626) 引入了 lruvec 和 [mem_cgroup_zone](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f16015fbf2f6ac45505d6ad21455ff9f6c14473d), 这里为了[移除 mem_cgroup_zone](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f9be23d6da035241b7687b25e64401171986dcef), 添加了 [zone 到 lruvec 的联系](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7f5e86c2ccc1480946d2c869d7f7d5278e828092), 从而 MEMCG 中可以直接通过 lruvec->zone 获取到 zone, 之前 zone 中已经包含了 lruvec, 至此不管是 MEMCG 还是 global 都可以通过 lruvec_zone() 函数直接从 lruvec 查到对应的 zone.
这个过程中 inactive_file_is_low() 等函数的参数都从 struct mem_cgroup_zone 修改为 struct lruvec. | v1 ☑✓ 3.5-rc1 | [LORE v1,00/12](https://lore.kernel.org/all/20120426074632.18961.17803.stgit@zurg), [关键 commit](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c56d5c7dfeb5cc754e17fa3d423086a3c551c219) | +| 2016/01/29 | Johannes Weiner | [mm: workingset: per-cgroup thrash detection](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=23047a96d7cfcfca1a6d026ecaec526ea4803e9e) | TODO | v2 ☑✓ 4.6-rc1 | [LORE v2,0/5](https://lore.kernel.org/all/1454090047-1790-1-git-send-email-hannes@cmpxchg.org) | | 2016/04/04 | Johannes Weiner | [mm: vmscan: reduce size of inactive file list](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=59dc76b0d4dfdd7dc46a1010e4afb44f60f3e97f) | [mm: support bigger cache workingsets and protect against writes](https://lore.kernel.org/lkml/1459790018-6630-1-git-send-email-hannes@cmpxchg.org) 的其中一个补丁, 整个 patchset 修复了数据库场景的 Page Cache LRU 处理的一些问题, 之前的 2 个补丁不再允许那些只写没有读的文件页被激活到 active list 上, 从而将 active list 上一些频繁访问的文件页面反而被驱逐到 inactive list, 造成性能抖动. 这个补丁删除了要求[非活动文件列表的最小文件缓存大小为 50%](https://elixir.bootlin.com/linux/v4.6/source/mm/vmscan.c#L1929) 的强制措施. 采用通过 workingset refault() 来进行探测的方法, 可以使在较短时间间隔后再次访问的最近收回的文件页直接升级到活动列表. 有了这种机制, 我们可以(在更大的系统上)为活动文件列表提供更多的内存, 这样我们就可以在内存中缓存更多经常使用的文件页, 而不会让它们被流式写入、一旦使用流式文件读取等页面驱逐出去. 这个补丁缩小了 inactive file list 的大小(之前是各占 50%), 不再允许在匿名内存使用的相同比率上增加活动列表, 这同样将有助于数据库工作负载(只有一半的页面缓存可用于缓存数据库 workingset). | v1 ☑✓ 4.7-rc1 | [LORE v1,0/3](https://lore.kernel.org/all/1459790018-6630-1-git-send-email-hannes@cmpxchg.org), [关键 COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=59dc76b0d4dfdd7dc46a1010e4afb44f60f3e97f) | | 2016/07/21 | Mel Gorman
Minchan Kim | [mm: consider per-zone inactive ratio to deactivate](https://lore.kernel.org/patchwork/patch/699874) | Joonsoo Kim 和 Minchan Kim 都报告了在 32 位平台上过早地触发了 OOM. 常见的问题是区域约束的高阶分配失败. 两个问题的原因都是因为: pgdat 被过早地认为是不可回收, 并且活动/非活动列表的轮换不足.
这组补丁做了如下部分:
1. 不考虑扫描时跳过的页面. 这避免了pgdat被过早地标记为不可回收
2. 补丁 2-4 增加了每个区域的统计数据. 如果每个区域的LRU计数是可用的, 那么就没有必要估计是否应该根据pgdat统计信息重试回收和压缩, 因此重新实现了近似的 pgdat 统计数据.
3. inactive_list_is_low() 中的主动去激活的逻辑存在问题, 导致 Minchan Kim 报告的问题, 有可能当前 zone 上明明有 8M 的匿名页面, 但是通过非原子的 order-0 分配却触发了 OOM, 因为该区域中的所有页面都在活动列表中. 在补丁 5 中, 如果所有符合条件的区域的非活动/活动比例需要更正, 那么一个区域受限的全局回收将会旋转列表. 较高的区域页面在开始时可能会被提前旋转, 但这是维护总体LRU年龄的更安全的选择. | v5 ☑ [4.8-rc1](https://kernelnewbies.org/Linux_4.8#Memory_management) | [Patchwork RFC](https://lore.kernel.org/patchwork/patch/699587)
*-*-*-*-*-*-*-*
[Patchwork v1](https://lore.kernel.org/patchwork/patch/699874)
*-*-*-*-*-*-*-*
[Patchwork v2](https://lore.kernel.org/patchwork/patch/700111)
*-*-*-*-*-*-*-*
[关注 commit](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f8d1a31163fcb3bf93f6c78770c3c1915f065bf9) | | 2017/01/16 | Michal Hocko | [mm, vmscan: cleanup lru size claculations](https://lore.kernel.org/patchwork/patch/751448) | 使用 lruvec_lru_size() 精简了 inactive_list_is_low() 的流程. | v1 ☑ 4.11-rc1 | [PatchWork v1,1/3](https://lore.kernel.org/patchwork/patch/751448) | @@ -3758,7 +3767,7 @@ __alloc_pages_direct_reclaim() | 2010/11/09 | Glauber Costa | [vmscan: per-node deferred work](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1d3d4437eae1bb2963faab427f65f90663c64aa1) | 实现 per node 的内存回收. | v1 ☑ 3.19-rc1 | [LORE](https://lore.kernel.org/lkml/20101109123246.GA11477@amd), [LORE v9,00/17](https://lore.kernel.org/all/153112469064.4097.2581798353485457328.stgit@localhost.localdomain), [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1d3d4437eae1bb2963faab427f65f90663c64aa1) | | 2010/11/09 | Nick Piggin | [mm: vmscan implement per-zone shrinkers](https://lore.kernel.org/all/153063036670.1818.16010062622751502.stgit@localhost.localdomain/) | 实现 per zone 的内存回收. | v1 ☑ 3.19-rc1 | [LORE](https://lore.kernel.org/lkml/20101109123246.GA11477@amd), [LORE v9,00/17](https://lore.kernel.org/all/153112469064.4097.2581798353485457328.stgit@localhost.localdomain), [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6b4f7799c6a5703ac6b8c0649f4c22f00fa07513) | | 2012/11/28 | Dave Chinner | [Numa aware LRU lists and shrinkers](https://lore.kernel.org/all/1354058086-27937-1-git-send-email-david@fromorbit.com) | 实现 SHRINKER_NUMA_AWARE | v1 ☐☑✓ | [LORE v1,0/19](https://lore.kernel.org/all/1354058086-27937-1-git-send-email-david@fromorbit.com) | -| 2022/04/22 | Roman Gushchin | [mm: introduce shrinker debugfs interface](https://patchwork.kernel.org/project/linux-mm/cover/20220416002756.4087977-1-roman.gushchin@linux.dev/) | 内核中有 50 多个不同的 shrinker, 在内存压力下, 内核会按照它们在系统中创建/注册的顺序对它们施加一些压力. 其中一些只能包含很少的对象, 一些可以相当大. 有些可以有效地回收内存, 有些则不然. 但是当前却没有有效的方法对单个 shrinker 进行计数和扫描, 并对其进行分析. 现有的唯一调试机制是 do_shrink_slab() 中的两个 TRACEPOINT: mm_shrink_slab_start 和 mm_shrink_slab_end. 不过, 它们并没有涵盖所有内容: 报告 0 个对象的 shrinker永远不会出现, 也不支持支持支持 MEMCG 的 shrinker. shrinker 通过其扫描功能进行识别, 但这并不总是足够的. 为了为内存 shrinker 提供更好的可见性和调试选项, 这个补丁集引入了 `/sys/kernel/shrinker` 接口, 在某种程度上类似于 `/sys/kernel/slab`. 为系统中注册的每个 shrinker 创建一个目录, 该目录包含两个文件结点 "count" 和 "scan" , 允许触发 count_objects() 和 scan_objects() 回调. 对于 MEMCG-Aware 和 NUMA-Aware 的 shrinker, 还额外提供了 count_memcg、scan_memcg、count_node、scan_node、count_memcg_node 和 scan_memcg_node. 它们允许获取每个 MEMCG 和每个 NUMA NODE 的对象计数, 并仅收缩特定的 MEMCG 或者 NUMA NODE. 为了使调试更加愉快, 补丁集还为所有 shrinker 命名, 以便 sysfs 条目可以有更多有意义的名称. | v2 ☐☑ | [LORE v1,0/5](https://lore.kernel.org/r/20220416002756.4087977-1-roman.gushchin@linux.dev)
*-*-*-*-*-*-*-*
[LORE v1,0/5](https://lore.kernel.org/all/20220422015853.748291-1-roman.gushchin@linux.dev)
*-*-*-*-*-*-*-*
[LORE v2,0/7](https://lore.kernel.org/r/20220422202644.799732-1-roman.gushchin@linux.dev)
*-*-*-*-*-*-*-*
[LORE v3,0/6](https://lore.kernel.org/r/20220509183820.573666-1-roman.gushchin@linux.dev) | +| 2022/04/22 | Roman Gushchin | [mm: introduce shrinker debugfs interface](https://patchwork.kernel.org/project/linux-mm/cover/20220416002756.4087977-1-roman.gushchin@linux.dev/) | 内核中有 50 多个不同的 shrinker, 在内存压力下, 内核会按照它们在系统中创建/注册的顺序对它们施加一些压力. 其中一些只能包含很少的对象, 一些可以相当大. 有些可以有效地回收内存, 有些则不然. 但是当前却没有有效的方法对单个 shrinker 进行计数和扫描, 并对其进行分析. 现有的唯一调试机制是 do_shrink_slab() 中的两个 TRACEPOINT: mm_shrink_slab_start 和 mm_shrink_slab_end. 不过, 它们并没有涵盖所有内容: 报告 0 个对象的 shrinker永远不会出现, 也不支持支持支持 MEMCG 的 shrinker. shrinker 通过其扫描功能进行识别, 但这并不总是足够的. 为了为内存 shrinker 提供更好的可见性和调试选项, 这个补丁集引入了 `/sys/kernel/shrinker` 接口, 在某种程度上类似于 `/sys/kernel/slab`. 为系统中注册的每个 shrinker 创建一个目录, 该目录包含两个文件结点 "count" 和 "scan" , 允许触发 count_objects() 和 scan_objects() 回调. 对于 MEMCG-Aware 和 NUMA-Aware 的 shrinker, 还额外提供了 count_memcg、scan_memcg、count_node、scan_node、count_memcg_node 和 scan_memcg_node. 它们允许获取每个 MEMCG 和每个 NUMA NODE 的对象计数, 并仅收缩特定的 MEMCG 或者 NUMA NODE. 为了使调试更加愉快, 补丁集还为所有 shrinker 命名, 以便 sysfs 条目可以有更多有意义的名称. | v2 ☐☑ | [LORE v1,0/5](https://lore.kernel.org/r/20220416002756.4087977-1-roman.gushchin@linux.dev)
*-*-*-*-*-*-*-*
[LORE v1,0/5](https://lore.kernel.org/all/20220422015853.748291-1-roman.gushchin@linux.dev)
*-*-*-*-*-*-*-*
[LORE v2,0/7](https://lore.kernel.org/r/20220422202644.799732-1-roman.gushchin@linux.dev)
*-*-*-*-*-*-*-*
[LORE v3,0/6](https://lore.kernel.org/r/20220509183820.573666-1-roman.gushchin@linux.dev)
*-*-*-*-*-*-*-*
[LORE v5,0/6](https://lore.kernel.org/r/20220601032227.4076670-1-roman.gushchin@linux.dev) | | 2022/04/21 | Kent Overstreet | [Printbufs & shrinker OOM reporting](https://patchwork.kernel.org/project/linux-mm/cover/20220419203202.2670193-1-kent.overstreet@gmail.com) | 633514 | v1 ☐☑ | [LORE v1,0/4](https://lore.kernel.org/all/20220419203202.2670193-1-kent.overstreet@gmail.com)
*-*-*-*-*-*-*-*
[LORE v1,0/4](https://lore.kernel.org/all/20220421234837.3629927-1-kent.overstreet@gmail.com) | @@ -3864,6 +3873,9 @@ Facebook 指出他们也面临过同样的问题, 所有的 workload 都需要 * process_mrelease + +华为终端手机上实现了一个名为 [xreclaimer(Fast process memory reclaimer)](https://github.com/gatieme/MobileModels/blob/huawei/noh-mate40/mm/xreclaimer) 快速回收进程内存的方案, 在进程退出时快速回收. + | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2021/08/09 | SeongJae Park | [mm: introduce process_mrelease system call](https://lore.kernel.org/patchwork/patch/1474134) | 引入 process_mrelease() 加速进程的清理, 以更快地释放被杀死的进程的内存.
我们经常希望能杀死不必要的进程, 为更重要的进程释放内存. 例如 Facebook 的 OOM killer 守护程序 oomd 和 Android的低内存killer守护程序lmkd. 对于这样的系统组件, 能够快速有效地释放内存非常. 但是不幸的是, 当一个进程接收到 SIGKILL 信号的时候并不一定能及时释放自己的内存, 这可能会受到很多因素的影响, 譬如进程的状态(它可能是处于 uninterruptible sleep 态)、正在运行进程的的 core 的 OPP 级别等. 而通过调用这个新的 process_mrelease() 系统调用, 它会在调用者的上下文中释放被杀死的进程的内存. 这种方式下, 内存的释放更可控, 因为它直接在当前 CPU 上运行, 只取决于调用者任务的优先级大小. 释放内存的工作量也将由调用方承担. | v9 ☑ [5.15-rc1](https://kernelnewbies.org/LinuxChanges#Linux_5.15.Introduce_process_mrelease.282.29_system_call) | [PatchWork v9,1/2](https://lore.kernel.org/patchwork/patch/1474134) | @@ -4113,7 +4125,7 @@ do_read_fault() | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:---:|:----:|:---:|:---:|:----------:|:----:| -| 2022/05/16 | Hsin-Yi Wang | [Implement readahead for squashfs](https://patchwork.kernel.org/project/linux-mm/cover/20220516105100.1412740-1-hsinyi@chromium.org/) | 641926 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/20220516105100.1412740-1-hsinyi@chromium.org) | +| 2022/05/16 | Hsin-Yi Wang | [Implement readahead for squashfs](https://patchwork.kernel.org/project/linux-mm/cover/20220516105100.1412740-1-hsinyi@chromium.org/) | 641926 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/20220516105100.1412740-1-hsinyi@chromium.org)
*-*-*-*-*-*-*-*
[LORE v4,0/3](https://lore.kernel.org/r/20220601103922.1338320-1-hsinyi@chromium.org)
*-*-*-*-*-*-*-*
[LORE v5,0/3](https://lore.kernel.org/r/20220606150305.1883410-1-hsinyi@chromium.org)
*-*-*-*-*-*-*-*
[LORE v7,0/4](https://lore.kernel.org/r/20220617083810.337573-1-hsinyi@chromium.org) | ## 6.3 DirtyPage @@ -4577,6 +4589,7 @@ Google 的工程师 Mina Almasry 提出了一种新的思路, 通过 [mremap 的 | 2013/03/20 | David Rientjes | [mm, hugetlb: include hugepages in meminfo](https://lore.kernel.org/all/alpine.DEB.2.02.1303201207110.28997@chino.kir.corp.google.com) | alpine.DEB.2.02.1303201207110.28997@chino.kir.corp.google.com | v2 ☐☑✓ | [LORE](https://lore.kernel.org/all/alpine.DEB.2.02.1303201207110.28997@chino.kir.corp.google.com) | | 2022/04/15 | Christophe Leroy | [mm, hugetlbfs: Allow for "high" userspace addresses](https://patchwork.kernel.org/project/linux-mm/patch/ab847b6edb197bffdfe189e70fb4ac76bfe79e0d.1650033747.git.christophe.leroy@csgroup.eu/) | 632590 | v10 ☐☑ | [LORE v10](https://lore.kernel.org/r/ab847b6edb197bffdfe189e70fb4ac76bfe79e0d.1650033747.git.christophe.leroy@csgroup.eu) | | 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) | ## 7.2 透明大页的支持 @@ -4738,7 +4751,7 @@ David Rientjes 率先提出了这种想法 [Hugepage collapse in process context | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2021/02/16 | David Rientjes | [Hugepage collapse in process context](https://lore.kernel.org/all/d098c392-273a-36a4-1a29-59731cdf5d3d@google.com) | 允许用户空间通过新的 process_madvise() 调用来诱导 HugePage Collapse | RFC,v1 ☐ | [LORE RFC v1,00/14](https://lore.kernel.org/all/d098c392-273a-36a4-1a29-59731cdf5d3d@google.com) | -| 2022/03/08 | Zach O'Keefe | [mm: userspace hugepage collapse](https://patchwork.kernel.org/project/linux-mm/cover/20220308213417.1407042-1-zokeefe@google.com/) | 这组补丁为用户空间提供了一种机制, 可以在进程上下文中将符合条件的内存范围压缩为 THP, 从而允许用户精细化地控制自己的 HugePages 使用策略. 借鉴了 David Rientjes 的想法. | v1 ☐☑ | [LORE v1,00/14](https://lore.kernel.org/r/20220308213417.1407042-1-zokeefe@google.com)
*-*-*-*-*-*-*-*
[LORE v2,0/12](https://lore.kernel.org/r/20220414180612.3844426-1-zokeefe@google.com)
*-*-*-*-*-*-*-*
[LORE v3,0/12](https://lore.kernel.org/r/20220426144412.742113-1-zokeefe@google.com)
*-*-*-*-*-*-*-*
[LORE v4,0/12](https://lore.kernel.org/r/20220502181714.3483177-1-zokeefe@google.com)
*-*-*-*-*-*-*-*
[LORE v5,0/12](https://lore.kernel.org/r/20220504214437.2850685-1-zokeefe@google.com) | +| 2022/06/04 | Zach O'Keefe | [mm: userspace hugepage collapse](https://patchwork.kernel.org/project/linux-mm/cover/20220308213417.1407042-1-zokeefe@google.com/) | 这组补丁为用户空间提供了一种机制, 可以在进程上下文中将符合条件的内存范围压缩为 THP, 从而允许用户精细化地控制自己的 HugePages 使用策略. 借鉴了 David Rientjes 的想法. | v1 ☐☑ | [LORE v1,00/14](https://lore.kernel.org/r/20220308213417.1407042-1-zokeefe@google.com)
*-*-*-*-*-*-*-*
[LORE v2,0/12](https://lore.kernel.org/r/20220414180612.3844426-1-zokeefe@google.com)
*-*-*-*-*-*-*-*
[LORE v3,0/12](https://lore.kernel.org/r/20220426144412.742113-1-zokeefe@google.com)
*-*-*-*-*-*-*-*
[LORE v4,0/12](https://lore.kernel.org/r/20220502181714.3483177-1-zokeefe@google.com)
*-*-*-*-*-*-*-*
[LORE v5,0/12](https://lore.kernel.org/r/20220504214437.2850685-1-zokeefe@google.com)
*-*-*-*-*-*-*-*
[LORE v6,0/15](https://lore.kernel.org/r/20220604004004.954674-1-zokeefe@google.com) | * 其他 @@ -4746,6 +4759,7 @@ David Rientjes 率先提出了这种想法 [Hugepage collapse in process context | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2022/03/11 | maobibo | [mm/khugepaged: sched to numa node when collapse huge page](https://patchwork.kernel.org/project/linux-mm/patch/20220311090119.2412738-1-maobibo@loongson.cn/) | 622550 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220311090119.2412738-1-maobibo@loongson.cn)
*-*-*-*-*-*-*-*
[LORE v2,0/1](https://lore.kernel.org/r/20220315040549.4122396-1-maobibo@loongson.cn) | +| 2022/05/27 | Jiaqi Yan | [Memory poison recovery in khugepaged collapsing](https://patchwork.kernel.org/project/linux-mm/cover/20220527190731.322722-1-jiaqiyan@google.com/) | 645671 | v4 ☐☑ | [LORE v4,0/2](https://lore.kernel.org/r/20220527190731.322722-1-jiaqiyan@google.com) | ### 7.2.5 THP splitting/reclaim/migration @@ -4929,12 +4943,13 @@ swap out 的时候打散, swap in 的时候可能又需要重新聚合回来, * Delay splitting THP during swapping out -支持 THP SWAP 的第一步是逐步延迟拆分 THP, 最终避免在 THP 交换期间拆分 THP, 并在整个 THP 中进行交换. +支持 THP SWAP 的第一步是逐步延迟拆分 THP, 最终避免在 THP 交换期间拆分 THP, 并在整个 THP 中进行交换. [LWN 717707: 页交换（swap）的改进计划](https://tinylab.org/lwn-717707). | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2017/05/15 | "Huang, Ying" | [THP swap: Delay splitting THP during swapping out/STEP 1](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=747552b1e71b400fa32a221e072be2c0b7661f14) | 在这个补丁集完成了延迟拆分 THP, 将拆分大页面的时间几乎从交换的第一步推迟到为 THP 分配交换空间并将 THP 添加到交换缓存之后. 这将减少交换缓存管理中使用的锁的获取/释放.
在 8 个进程的 vm-scalability swap-w-seq 测试用例(测试用例创建了 8 个进程, 它们依次分配和写入匿名页面, 直到 RAM 和交换设备的一部分用完)中, 使用补丁集, 换出的吞吐量提高了 15.5%(从 3.73GB/s 提高到 4.31GB/s). | v11 ☑ 4.13-rc1 | [2016/08/09 LORE RFC,00/11](https://lore.kernel.org/lkml/1470760673-12420-1-git-send-email-ying.huang@intel.com)[2016/09/01 LORE v2,00/10](https://lore.kernel.org/lkml/1472743023-4116-1-git-send-email-ying.huang@intel.com)
*-*-*-*-*-*-*-*
[LORE v3,00/12](https://lore.kernel.org/all/20170724051840.2309-1-ying.huang@intel.com)
*-*-*-*-*-*-*-*
[2017/05/15 LORE v11,0/5](https://lore.kernel.org/lkml/20170515112522.32457-1-ying.huang@intel.com) | | 2017/07/14 | "Huang, Ying" | [THP swap: Delay splitting THP during swapping out/STEP 2](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=fe490cc0fe9e6ee48cc48bb5dc463bc5f0f1428f) | 这是 THP (透明大页) 交换优化的 STEP 2. 在 STEP 1, 拆分大页面的时机从交换的第一步延迟到为 THP 分配交换空间并将 THP 添加到交换缓存之后. 在 STEP 2 中, 拆分被进一步延迟到交换完成之后. 在这个补丁集中, 对匿名 THP 回收的更多操作(如 TLB 刷新、将 THP 写入交换设备、将 THP 从交换缓存中删除) 被批处理. 从而提高了匿名 THP 交换的性能. | v3 ☑ 4.14-rc1 | [2017/06/23 LORE v2,00/12](https://lore.kernel.org/lkml/20170623071303.13469-1-ying.huang@intel.com)
*-*-*-*-*-*-*-*
[2017/07/24 LORE v3,00/12](https://lore.kernel.org/all/20170724051840.2309-1-ying.huang@intel.com) | +| 2022/05/27 | Barry Song <21cnbao@gmail.com> | [[v2] arm64: enable THP_SWAP for arm64](https://patchwork.kernel.org/project/linux-mm/patch/20220527100644.293717-1-21cnbao@gmail.com/) | 645555 | v2 ☐☑ | [LORE v2,0/1](https://lore.kernel.org/r/20220527100644.293717-1-21cnbao@gmail.com) | * Swapout/swapin THP in one piece @@ -5037,6 +5052,7 @@ khugepaged 处理流程 | 2019/12/19 | Colin Cross | [mm: add a field to store names for private anonymous memory](https://lore.kernel.org/patchwork/patch/416962) | 在二进制中通过 xxx_sched_class 地址顺序标记调度类的优先级, 从而可以通过直接比较两个 xxx_sched_class 地址的方式, 优化调度器中两个热点函数 pick_next_task()和check_preempt_curr(). | v2 ☐ | [PatchWork RFC](https://lore.kernel.org/patchwork/patch/416962)
*-*-*-*-*-*-*-*
[PatchWork v2](https://lore.kernel.org/patchwork/patch/416962) | | 2022/03/10 | Alex Sierra | [split vm_normal_pages for LRU and non-LRU handling](https://patnux-mm/cover/20220310172633.9151-1-alex.sierra@amd.com/) | DEVICE_COHERENT 页面在 "普通" 页面可以被内核中的各种调用者使用的方式上引入了微妙的区别.
为了在 CPU 页表中进行映射和 COW, 它们的行为就像普通页面一样. 但它们不支持 LRU 列表、NUMA 迁移或 THP. 因此, 我们将 vm_normal_page 拆分为两个函数 vm_normal_any_page 和 vm_normal_lru_page. 后者将只返回那些可以放在 LRU 列表中, 并且支持 NUMA 迁移、KSM 和 THP 的页面.
在自测试中添加了 HMM 测试, 以使用设备连贯页面来执行这些更改. 名为 hmm_cow_in_device 的新测试将测试标记为 COW 的页面, 并在设备区域中分配. 此外, 还向 hmm_gup_test 中添加了更多的配置, 以测试基本的获取用户页面和设备区域页面中的获取用户页面的快速路径. | v1 ☐☑ | [LORE v1,0/3](https://lore.kernel.org/rsierra@amd.com) | | 2022/05/19 | Chih-En Lin | [Introduce Copy-On-Write to Page Table](https://patchwork.kernel.org/project/linux-mm/cover/20220519183127.3909598-1-shiyn.lin@gmail.com/) | 643289 | v1 ☐☑ | [LORE v1,0/6](https://lore.kernel.org/r/20220519183127.3909598-1-shiyn.lin@gmail.com) | +| 2022/05/27 | Jakub Matěna | [Refactor of vma_merge and new merge call](https://patchwork.kernel.org/project/linux-mm/cover/20220527104810.24736-1-matenajakub@gmail.com/) | 645578 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/20220527104810.24736-1-matenajakub@gmail.com)
*-*-*-*-*-*-*-*
[LORE v2,0/2](https://lore.kernel.org/r/20220527211708.839033-1-matenajakub@gmail.com)
*-*-*-*-*-*-*-*
[LORE v1,0/2](https://lore.kernel.org/r/20220602145642.16948-1-matenajakub@gmail.com) | ### 8.1.1 具名匿名页 Anonymous VMA naming @@ -6020,6 +6036,7 @@ Intel 的吴峰光 [PMEM NUMA node and hotness accounting/migration](https://lor | 2021/12/11 | Baolin Wang | [Add speculative numa fault support](https://lore.kernel.org/patchwork/patch/1479229) | 这个 RFC 补丁集为分级内存等场景添加了推测性的 numa 错误支持. 在分层内存系统上, 它将依靠 numa 平衡将慢内存和热内存提升为快内存, 以提高性能. 因此, 我们可以根据某些工作负载的数据局部性, 提前在低速内存中提升多个顺序页面, 以提高性能. 那么现在有多少页面需要提升到最快的内存是最好的? 现在这个 RFC 补丁集只实现了一个基本而简单的机制来推测每个 VMA 的 numa 故障窗口. 它将为每个 VMA 引入一个新的原子成员来记录 numa 故障窗口信息, 该信息用于确定它是扩展还是减少 numa 故障窗口的顺序流. 在分层内存系统中测试 mysql 可以看到大约 6% 的改进. 注意: 这个补丁集是[基于实现分级内存提升的补丁集 NUMA balancing: optimize page placement for memory tiering system](https://lore.kernel.org/lkml/87bl2gsnrd.fsf@yhuang6-desk2.ccr.corp.intel.com). 参见报道 [Speculative NUMA Fault Support Proposed For Improving Tiered Memory Linux Performance](https://www.phoronix.com/scan.php?page=news_item&px=Speculative-NUMA-Fault) | v1 ☐ | [LORE](https://lore.kernel.org/lkml/cover.1639306956.git.baolin.wang@linux.alibaba.com), [PatchWork](https://patchwork.kernel.org/project/linux-mm/cover/cover.1639306956.git.baolin.wang@linux.alibaba.com) | | 2022/04/08 | Huang Ying | [memory tiering: hot page selection](https://patchwork.kernel.org/project/linux-mm/cover/20220408071222.219689-1-ying.huang@intel.com/) | 在分级内存的系统中, 需要使用 NUMA 来优化页面在内存中的位置. 基本上, 最初的 NUMA Balancing 实现选择并提升最近访问最多(mostly recently accessed/MRU)的页面. 但最近访问的页面可能很冷. 因此, 在这个补丁集中, 我们基于 NUMA 平衡页表扫描和页面 Page Fault & Hint 之间的延迟实现了一个新的热页识别算法. 另外一方面热页升级可能会在系统中产生一些开销. 为了控制开销, 实现了一种简单的提升速率限制机制. 用于识别热页的热阈值通常取决于工作负载. 因此, 我们还实现了一个热页阈值自动调整算法. 基本思想是增加/减少热页阈值, 使通过热页阈值提升到快速内存的页面数接近速率限制. | v1 ☐☑ | [LORE v1,0/3](https://lore.kernel.org/r/20220408071222.219689-1-ying.huang@intel.com) | | 2022/04/13 | Jagdish Gediya | [mm: demotion: Introduce new node state N_DEMOTION_TARGETS](https://patchwork.kernel.org/project/linux-mm/cover/20220413092206.73974-1-jvgediya@linux.ibm.com/) | 631805 | v2 ☐☑ | [LORE v2,0/5](https://lore.kernel.org/r/20220413092206.73974-1-jvgediya@linux.ibm.com)
*-*-*-*-*-*-*-*
[LORE v3,0/7](https://lore.kernel.org/r/20220422195516.10769-1-jvgediya@linux.ibm.com)
*-*-*-*-*-*-*-*
[LORE v1,0/3](https://lore.kernel.org/r/20220426085105.60822-1-ying.huang@intel.com)
*-*-*-*-*-*-*-*
[LORE v1,0/3](https://lore.kernel.org/r/20220510063958.86985-1-ying.huang@intel.com) | +| 2022/05/27 | Aneesh Kumar K.V | [mm/demotion: Memory tiers and demotion](https://patchwork.kernel.org/project/linux-mm/cover/20220527122528.129445-1-aneesh.kumar@linux.ibm.com/) | 645595 | v4 ☐☑ | [LORE v4,0/7](https://lore.kernel.org/r/20220527122528.129445-1-aneesh.kumar@linux.ibm.com)
*-*-*-*-*-*-*-*
[LORE v5,0/9](https://lore.kernel.org/r/20220603134237.131362-1-aneesh.kumar@linux.ibm.com)
*-*-*-*-*-*-*-*
[LORE v6,0/13](https://lore.kernel.org/r/20220610135229.182859-1-aneesh.kumar@linux.ibm.com) | ## 12.2 远端内存 @@ -6236,6 +6253,7 @@ ARM 引入了一个[内存标签扩展](https://community.arm.com/developer/ip-p | 2021/02/05 | Andrey Konovalov | [kasan: optimizations and fixes for HW_TAGS](https://lore.kernel.org/patchwork/patch/1376340) | NA | v3 ☑ [5.12-rc1](https://kernelnewbies.org/Linux_5.11#Memory_management) | [PatchWork mm,v3,mm,00/13](https://patchwork.kernel.org/project/linux-mm/cover/cover.1612546384.git.andreyknvl@google.com) | | 2021/12/30 | andrey.konovalov@linux.dev | [kasan, vmalloc, arm64: add vmalloc tagging support for SW/HW_TAGS](https://patchwork.kernel.org/project/linux-mm/cover/cover.1638308023.git.andreyknvl@google.com/) | NA | v1 ☐ | [2021/11/30 PatchWork 00/31](https://patchwork.kernel.org/project/linux-mm/cover/cover.1638308023.git.andreyknvl@google.com)
*-*-*-*-*-*-*-*
[2021/12/13 PatchWork v3,00/38](https://patchwork.kernel.org/project/linux-mm/cover/cover.1639432170.git.andreyknvl@google.com)
*-*-*-*-*-*-*-*
[2021/12/20 PatchWork v4,00/39](https://patchwork.kernel.org/project/linux-mm/cover/cover.1640036051.git.andreyknvl@google.com))
*-*-*-*-*-*-*-*
[2021/12/30 PatchWork v5,00/39](https://patchwork.kernel.org/project/linux-mm/cover/cover.1640891329.git.andreyknvl@google.com) | | 2022/02/02 | Christophe Leroy | [mm/kasan: Add CONFIG_KASAN_SOFTWARE](https://patchwork.kernel.org/project/linux-mm/patch/a480ac6f31eece520564afd0230c277c78169aa5.1643791473.git.christophe.leroy@csgroup.eu/) | 610616 | v1 ☐ | [PatchWork v1,0/4](https://lore.kernel.org/r/a480ac6f31eece520564afd0230c277c78169aa5.1643791473.git.christophe.leroy@csgroup.eu) | +| 2022/06/13 | andrey.konovalov@linux.dev | [kasan: switch tag-based modes to stack ring from per-object metadata](https://patchwork.kernel.org/project/linux-mm/cover/cover.1655150842.git.andreyknvl@google.com/) | 649958 | v1 ☐☑ | [LORE v1,0/32](https://lore.kernel.org/r/cover.1655150842.git.andreyknvl@google.com) | ### 13.3.5 KCSAN @@ -6425,7 +6443,7 @@ DAMON 利用两个核心机制 : **基于区域的采样**和**自适应区域 | 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) | | 2022/04/29 | SeongJae Park | [mm/damon: Support online tuning](https://patchwork.kernel.org/project/linux-mm/cover/20220429160606.127307-1-sj@kernel.org/) | 637059 | v1 ☐☑ | [LORE v1,0/14](https://lore.kernel.org/r/20220429160606.127307-1-sj@kernel.org) | | 2022/05/07 | Gautam Menghani | [Add documentation for Enum value 'NR_DAMON_OPS' in](https://patchwork.kernel.org/project/linux-mm/patch/20220507165620.110706-1-gautammenghani201@gmail.com/) | 639422 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220507165620.110706-1-gautammenghani201@gmail.com) | -| 2022/05/13 | SeongJae Park | [mm/damon/schemes: Extend DAMOS for Proactive LRU-lists Sorting](https://patchwork.kernel.org/project/linux-mm/cover/20220513150000.25797-1-sj@kernel.org/) | 641448 | v1 ☐☑ | [LORE v1,0/3](https://lore.kernel.org/r/20220513150000.25797-1-sj@kernel.org) | +| 2022/05/13 | SeongJae Park | [mm/damon/schemes: Extend DAMOS for Proactive LRU-lists Sorting](https://patchwork.kernel.org/project/linux-mm/cover/20220513150000.25797-1-sj@kernel.org/) | 641448 | v1 ☐☑ | [LORE v1,0/3](https://lore.kernel.org/r/20220513150000.25797-1-sj@kernel.org)
*-*-*-*-*-*-*-*
[LORE v1,0/8](https://lore.kernel.org/r/20220613192301.8817-1-sj@kernel.org) | ### 13.4.5 vmstat @@ -6849,7 +6867,7 @@ ZONE_MOVABLE 一个 pseudo zone, 它实际是从内核划分的某个 zone 中 | 2016/01/08 | Taku Izumi | [mm: Introduce kernelcore=mirror option](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=342332e6a925e9ed015e5465062c38d2b86ec8f9) | 内存镜像, 提供内存可靠性分级的功能.
通过 UEFI BIOS(规范 2.5) 上报镜像内存(即高可靠内存 mirrored/reliable)的范围和非镜像内存(即低可靠内存)的两种内存. 内核默认使用高可靠的内存, 用 NORMAL ZONE 管理, 用户态优先使用普通(低可靠的)内存, 使用 MOVABLE ZONE 管理. | v4 ☑ 4.6-rc1 | [LKML RFC](https://lkml.org/lkml/2015/10/9/24)
*-*-*-*-*-*-*-*
[LKML v1](https://lkml.org/lkml/2015/10/15/9)
*-*-*-*-*-*-*-*
[LKML v2,0/2](https://lkml.org/lkml/2015/11/27/18)
*-*-*-*-*-*-*-*
[LKML v3,0/2](https://lkml.org/lkml/2015/12/8/836)
*-*-*-*-*-*-*-*
[LKML v4,0/2](https://lkml.org/lkml/2016/1/8/88), [PatchWork v4,0/2](https://lore.kernel.org/lkml/1452241523-19559-1-git-send-email-izumi.taku@jp.fujitsu.com) | | 2016/06/27 | Xishi Qiu | [mm: mirrored memory support for page buddy allocations](https://lore.kernel.org/lkml/558E084A.60900@huawei.com) | 内存镜像的功能 | RFC v2 ☐ | [PatchWork RFC,v2,0/8](https://lore.kernel.org/lkml/558E084A.60900@huawei.com) | | 2018/2/12 | David Rientjes | [mm: Introduce kernelcore=mirror option](http://lore.kernel.org/patchwork/patch/574230) | `kernelcore=` 和 `movablecore=` 都可以分别用于定义系统上 ZONE_NORMAL 和 ZONE_MOVABLE 的数量. 然而, 这需要在指定命令行时知道系统内存容量. 这个补丁引入了将 `kernelcore` 和 `movablecore` 定义为系统总内存的百分比的能力. 这对于希望将 ZONE_MOVABLE 的数量定义为系统内存的比例(而不是硬编码的字节值)的系统软件来说是很方便的. 要定义百分比, 参数的最后一个字符应该是 '%'. | v4 ☑ 4.17-rc1 | [LKML 1/2](https://lkml.org/lkml/2018/2/12/1024) | -| 2022/03/26 | mawupeng | [introduce mirrored memory support for arm64](https://patchwork.kernel.org/project/linux-mm/cover/20220326064632.131637-1-mawupeng1@huawei.com) | 镜像内存支持 arm64. 参见 phoronix 报道 [Huawei Working On UEFI Mirrored Memory Support For Linux AArch64](https://www.phoronix.com/scan.php?page=news_item&px=Linux-AArch64-Mirrored-Memory). | v1 ☐☑ | [LORE v1,0/9](https://lore.kernel.org/all/20220326064632.131637-1-mawupeng1@huawei.com)
*-*-*-*-*-*-*-*
[LORE v2,0/9](https://lore.kernel.org/r/20220414101314.1250667-1-mawupeng1@huawei.com) | +| 2022/03/26 | mawupeng | [introduce mirrored memory support for arm64](https://patchwork.kernel.org/project/linux-mm/cover/20220326064632.131637-1-mawupeng1@huawei.com) | 镜像内存支持 arm64. 参见 phoronix 报道 [Huawei Working On UEFI Mirrored Memory Support For Linux AArch64](https://www.phoronix.com/scan.php?page=news_item&px=Linux-AArch64-Mirrored-Memory). | v1 ☐☑ | [LORE v1,0/9](https://lore.kernel.org/all/20220326064632.131637-1-mawupeng1@huawei.com)
*-*-*-*-*-*-*-*
[LORE v2,0/9](https://lore.kernel.org/r/20220414101314.1250667-1-mawupeng1@huawei.com)
*-*-*-*-*-*-*-*
[LORE v3,0/6](https://lore.kernel.org/r/20220607093805.1354256-1-mawupeng1@huawei.com) | | 2022/04/19 | mawupeng | [Add support to relocate kernel image to mirrored region](https://patchwork.kernel.org/project/linux-mm/cover/20220419070150.254377-1-mawupeng1@huawei.com/) | 633242 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/20220419070150.254377-1-mawupeng1@huawei.com) | diff --git a/study/kernel/00-DESCRIPTION/SCHEDULER.md b/study/kernel/00-DESCRIPTION/SCHEDULER.md index 1abe6d7..18fd1ba 100644 --- a/study/kernel/00-DESCRIPTION/SCHEDULER.md +++ b/study/kernel/00-DESCRIPTION/SCHEDULER.md @@ -469,6 +469,7 @@ ARCHLINUX 的开发者 [hamadmarri](https://github.com/hamadmarri) 为 linux 开 ARCHLINUX 的开发者 ptr1337, 同样移植了 [CacULE Scheduler](https://github.com/ptr1337/linux-cacule), [CachyOS/linux-cachyos](https://github.com/CachyOS/linux-cachyos). +[libhunt](https://www.libhunt.com/compare-linux-cacule-vs-linux-cachyos) 提供了两个 GITHUB 仓库的对比信息. ## 1.5 调度类的一些其他优化点 ------- @@ -3450,22 +3451,26 @@ Oracle 数据库具有类似的虚拟化功能, 称为 Oracle Multitenant, 其 | 2021/03/26 | Rik van Riel | [sched/fair: bring back select_idle_smt, but differently](https://lore.kernel.org/patchwork/patch/1402916) | Mel Gorman 上面的补丁在 9fe1f127b913("sched/fair: Merge select_idle_core/cpu()") 中做了一些出色的工作, 从而提高了内核查找空闲 CPU 的效率, 可以有效地降低任务等待运行的时间. 但是较多的均衡和迁移, 减少的局部性和相应的 L2 缓存丢失的增加会带来一些负面的效应. 这个补丁重新将 `select_idle_smt` 引入回来, 并做了优化, 修复了性能回归, 在搜索所有其他 CPU 之前, 检查 prev 的兄弟 CPU 是否空闲. | v2 ☑ v5.12-rc7 | [PatchWork](https://lore.kernel.org/patchwork/patch/1402916), [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c722f35b513f807629603bbf24640b1a48be21b5) | | 2021/07/26 | Mel Gorman | [Modify and/or delete SIS_PROP](https://lore.kernel.org/patchwork/cover/1467090) | NA | RFC | [PatchWork RFC,0/9](https://lore.kernel.org/patchwork/cover/1467090) | | 2021/08/04 | Mel Gorman | [Reduce SIS scanning](https://lore.kernel.org/patchwork/cover/1472054) | 将 [Modify and/or delete SIS_PROP](https://lore.kernel.org/patchwork/cover/1467090) 拆开进行提交. | RFC ☐ | [PatchWork 0/2](https://lore.kernel.org/patchwork/cover/1472054) | -| 2022/05/05 | Abel Wu | [sched/fair: filter out overloaded cpus in SIS](https://lore.kernel.org/all/20220505122331.42696-1-wuyun.abel@bytedance.com) | [introduce sched-idle balancing](https://lore.kernel.org/all/20220217154403.6497-1-wuyun.abel@bytedance.com) 的其中一个补丁, v3 之后单独发到社区. | v3 ☐☑✓ | [LORE v3](https://lore.kernel.org/all/20220505122331.42696-1-wuyun.abel@bytedance.com) | * SIS_PROP to search idle CPU based on sum of util_avg 当前 select_idle_cpu() 使用 Per CPU 的平均空闲时间来估计 LLC 域总的空闲时间, 并计算需要扫描的 CPU 数量. 这可能是不一致的, 因为 CPU 的空闲时间不一定与域的空闲时间相关. 因此, 当系统非常繁忙时, 负载可能会被低估, 从而导致过度搜索. -当 LLC 域相对繁忙时, 在 LLC 域中搜索空闲的 CPU 是非常耗时的. 更糟糕的是, 如果 domain 域内所有 CPU 都过载, 那么在迭代整个 LLC 域之后, 它可能仍然无法找到空闲的 CPU. 通过测试发现 netperf 的 99th 分位延迟 与 select_idle_cpu() 所花费的时间相当. 也就是说, 当系统过载时, 搜索空闲 CPU 可能成为瓶颈. 因此 Chen Yu 建议 [sched: Stop searching for idle cpu if the LLC domain is overloaded](https://lore.kernel.org/all/20220207034013.599214-1-yu.c.chen@intel.com). 通过判断如果 sd_llc_shared 域已经 overloaded, 则跳过 select_idle_cpu() 不再在 LLC 域内扫描空闲 CPU. 基于 Mel Gorman 的补丁 [sched/fair: Track efficiency of select_idle_sibling](https://lore.kernel.org/lkml/20210726102247.21437-2-mgorman@techsingularity.net) 测试了 select_idle_sibling() 的效率. +当 LLC 域相对繁忙时, 在 LLC 域中搜索空闲的 CPU 是非常耗时的. 更糟糕的是, 如果 domain 域内所有 CPU 都过载, 那么在迭代整个 LLC 域之后, 它可能仍然无法找到空闲的 CPU. 通过测试发现 netperf 的 99th 分位延迟 与 select_idle_cpu() 所花费的时间相当. 也就是说, 当系统过载时, 搜索空闲 CPU 可能成为瓶颈. Intel 的 Chen Yu 借助 Mel Gorman 的调度调测补丁 [sched/fair: Track efficiency of select_idle_sibling](https://lore.kernel.org/lkml/20210726102247.21437-2-mgorman@techsingularity.net) 测试了 select_idle_sibling() 的效率, 然后通过 bpftrace 显示的 histogram 很直观的反映了这个现象. + +因此 Chen Yu 建议 [sched: Stop searching for idle cpu if the LLC domain is overloaded](https://lore.kernel.org/all/20220207034013.599214-1-yu.c.chen@intel.com). 通过判断如果 sd_llc_shared 域已经 overloaded, 则跳过 select_idle_cpu() 不再在 LLC 域内扫描空闲 CPU. 随后[在 Peter 的建议](https://lore.kernel.org/lkml/20220207135253.GF23216@worktop.programming.kicks-ass.net)下, Chen Yu 在 V2 实现了一种 [util_avg 到扫描 CPU 数量 nr_idle_scan 的线性映射 f(x)](https://lore.kernel.org/all/20220310005228.11737-1-yu.c.chen@intel.com). 算法改进为了一种[基于 util_avg 来处理 SIS_PROP 的方法](https://lore.kernel.org/all/20220207034013.599214-1-yu.c.chen@intel.com), 其主要思想是用基于域的度量来代替平均 CPU 空闲时间. 选择平均 CPU 利用率 (util_avg) 作为候选者. 通常, 要扫描的 CPU 数量应该与该域中 util_avg 的总和成反比. 也就是说, util_avg 越低, select_idle_cpu() 应该扫描更多空闲 CPU, 反之亦然. 选择 util_avg 的好处是, 它是累计历史活动的度量, 似乎比瞬时度量 (如 rq->nr_running) 更准确. 此外, 还可以从周期性负载平衡中借用 util_avg, 这可以减轻 select_idle_cpu() 的开销. + +此外 ByteDance 的 Abel Wu 也发现了这个问题, 并尝试通过过滤掉过载的 CPU 来提高 SIS 的搜索效率, [sched/fair: filter out overloaded cpus in SIS](https://lore.kernel.org/lkml/20220505122331.42696-1-wuyun.abel@bytedance.com). 如果系统过载越多, 搜索的 CPU 就会越少. 过载的 CPU 通过 LLC 共享域进行跟踪, 在 TICK 时进行更新. | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:----:|:---:|:----------:|:---:| | 2022/04/29 | Chen Yu | [sched/fair: Introduce SIS_UTIL to search idle CPU based on sum of util_avg](https://lore.kernel.org/all/20220310005228.11737-1-yu.c.chen@intel.com) | | v2 ☐☑✓ | [LORE v1](https://lore.kernel.org/all/20220207034013.599214-1-yu.c.chen@intel.com)
*-*-*-*-*-*-*-*
[LORE v2](https://lore.kernel.org/all/20220310005228.11737-1-yu.c.chen@intel.com)
*-*-*-*-*-*-*-*
[LORE v3](https://lore.kernel.org/lkml/20220428182442.659294-1-yu.c.chen@intel.com) | +| 2022/06/19 | Abel Wu | [sched/fair: improve scan efficiency of SIS](https://lore.kernel.org/all/20220619120451.95251-1-wuyun.abel@bytedance.com) | 引入 SIS 过滤器, 以帮助在扫描深度有限时提高扫描效率. 过滤器仅包含未占用的 CPU, 并在 SMT 级负载平衡期间更新. 预计系统过载越多, 扫描的 CPU 就越少. [introduce sched-idle balancing](https://lore.kernel.org/all/20220217154403.6497-1-wuyun.abel@bytedance.com) 的其中一个补丁, v3 之后单独发到社区 [v3 sched/fair: filter out overloaded cpus in SIS](https://lore.kernel.org/all/20220505122331.42696-1-wuyun.abel@bytedance.com). v4 之后扩展成一个补丁集. | v4 ☐☑✓ | [2022/05/05, LORE v3](https://lore.kernel.org/all/20220505122331.42696-1-wuyun.abel@bytedance.com)
*-*-*-*-*-*-*-*
[2022/06/19, LORE v4,0/7](https://lore.kernel.org/all/20220619120451.95251-1-wuyun.abel@bytedance.com) | ### 5.3.5 SIS avg_idle @@ -3529,10 +3534,14 @@ Oracle 数据库具有类似的虚拟化功能, 称为 Oracle Multitenant, 其 [Benchmarking The AMD EPYC Speed Boost Coming To Linux 5.18, Thanks To Scheduler/NUMA Improvement](https://www.phoronix.com/scan.php?page=article&item=linux-imbalance-epyc&num=1) 中在 AMD EPYC 上进行了性能测试. +[With A Few Lines Of Code, AMD's Nice Performance Optimization For Linux 5.20](https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.20-AMD-NUMA-Imbalance), [6 行代码的补丁优化 Linux 5.20, Stream 性能提升 40%!](https://mp.weixin.qq.com/s/tOR8j_3sw4OyRFDAP32uLw) + + | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:----:|:---:|:----------:|:---:| | 2021/12/01 | Mel Gorman | [Adjust NUMA imbalance for multiple LLCs](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=e496132ebedd870b67f1f6d2428f9bb9d7ae27fd) | [commit 7d2b5dd0bcc4 ("sched/numa: Allow a floating imbalance between NUMA nodes")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7d2b5dd0bcc4) 允许 NUMA 节点之间的不平衡, 这样通信任务不会被 load balance 分开. 当 LLC 和 node 之间有 1:1 的关系时, 这种方法可以很好地工作, 但是对于多个 LLC, 如果独立的任务过早地使用 CPU 共享缓存, 这种方法就不太理想了. 本系列解决了两个问题:
1. 调度程序域权重的使用不一致, 以及当每个 NUMA 节点有许多 LLC 时性能不佳. NUMA之间允许的不均衡的进程数目不再是一个固定的值 NUMA_IMBALANCE_MIN(2), 而是在 build_sched_domains() 中实际探测 NUMA 域下辖的 LLC 的数目, 作为 sd->imb_numa_nr. | v4 ☑✓ 5.18-rc1 | [PatchWork v3,0/2](https://lore.kernel.org/lkml/20211201151844.20488-1-mgorman@techsingularity.net)
*-*-*-*-*-*-*-*
[LORE v4,0/2](https://lore.kernel.org/lkml/20211210093307.31701-1-mgorman@techsingularity.net)
*-*-*-*-*-*-*-*
[LORE v6,0/2](https://lore.kernel.org/all/20220208094334.16379-1-mgorman@techsingularity.net) | -| 2022/02/17 | K Prateek Nayak | [sched/fair: Consider cpu affinity when allowing NUMA imbalance in find_idlest_group](https://lore.kernel.org/all/20220217055408.28151-1-kprateek.nayak@amd.com) | 当前的调度程序代码只是检查本地组中的任务数是否小于允许的 NUMA 不平衡阈值. 该阈值以前是 NUMA 域跨度的 25%), 但在 Mel 补丁集 "Adjust NUMA imbalance for multiple LLCs" 中 commit e496132ebedd ("sched/fair: Adjust the allowed NUMA imbalance when SD_NUMA spans multiple LLCs" 现在等于 NUMA 域中的 LLC 数目, 通常情况下这种机制运行良好.
但是对于进程都通过 numactl/taskset PIN 到一组分散的 CPU 上的情况(比如每个 LLC 域中选一个 CPU), 任务的数量将始终在阈值内, 因此所有 8 个流线程将在第一个 SOCKET 上唤醒, 从而导致次优性能. 在最初的少量 CPU 上堆积之后, 虽然负载平衡器可以工作, 但是稳定的均衡状态, 并且需要频繁的迁移 PING PONG.
我们可以通过检查本地组中允许的 CPU 数量是否少于本地组中运行的任务数量来检测并避免这种堆积, 并使用此信息将本来会堆积的县城分散到下一个 SOCKET 中(毕竟, 这个慢路径的目标是在初始放置期间找到最空闲的组和最空闲的 CPU). | v4 ☐☑✓ | [LORE](https://lore.kernel.org/all/20220217055408.28151-1-kprateek.nayak@amd.com) | +| 2022/05/20 | Mel Gorman | [Mitigate inconsistent NUMA imbalance behaviour](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=026b98a93bbdbefb37ab8008df84e38e2fedaf92) | TODO | v2 ☐☑✓ | [LORE v2,0/4](https://lore.kernel.org/all/20220520103519.1863-1-mgorman@techsingularity.net) | +| 2022/02/17 | K Prateek Nayak | [sched/fair: Consider cpu affinity when allowing NUMA imbalance in find_idlest_group](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=f5b2eeb49991047f8f64785e7a7857d6f219d574) | 当前的调度程序代码只是检查本地组中的任务数是否小于允许的 NUMA 不平衡阈值. 该阈值以前是 NUMA 域跨度的 25%), 但在 Mel 补丁集 "Adjust NUMA imbalance for multiple LLCs" 中 commit e496132ebedd ("sched/fair: Adjust the allowed NUMA imbalance when SD_NUMA spans multiple LLCs" 现在等于 NUMA 域中的 LLC 数目, 通常情况下这种机制运行良好.
但是对于进程都通过 numactl/taskset PIN 到一组分散的 CPU 上的情况(比如每个 LLC 域中选一个 CPU), 任务的数量将始终在阈值内, 因此所有 8 个流线程将在第一个 SOCKET 上唤醒, 从而导致次优性能. 在最初的少量 CPU 上堆积之后, 虽然负载平衡器可以工作, 但是稳定的均衡状态, 并且需要频繁的迁移 PING PONG.
我们可以通过检查本地组中允许的 CPU 数量是否少于本地组中运行的任务数量来检测并避免这种堆积, 并使用此信息将本来会堆积的县城分散到下一个 SOCKET 中(毕竟, 这个慢路径的目标是在初始放置期间找到最空闲的组和最空闲的 CPU). | v4 ☐☑✓ | [LORE](https://lore.kernel.org/all/20220217055408.28151-1-kprateek.nayak@amd.com)
*-*-*-*-*-*-*-*
[LORE v7](https://lore.kernel.org/all/20220407111222.22649-1-kprateek.nayak@amd.com) | ## 5.6 相关学术研究