From 010aedb8aadd765fd5410f16b13e66bf8e204cc3 Mon Sep 17 00:00:00 2001 From: gatieme Date: Sat, 4 Sep 2021 22:11:01 +0800 Subject: [PATCH] description/memory: update 20210904 v2 --- study/kernel/00-DESCRIPTION/DEBUGGING.md | 2 +- study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md | 19 +++++++++++++------ 2 files changed, 14 insertions(+), 7 deletions(-) diff --git a/study/kernel/00-DESCRIPTION/DEBUGGING.md b/study/kernel/00-DESCRIPTION/DEBUGGING.md index f824de2..a18b125 100644 --- a/study/kernel/00-DESCRIPTION/DEBUGGING.md +++ b/study/kernel/00-DESCRIPTION/DEBUGGING.md @@ -223,7 +223,7 @@ Facebook 在 2018 年开源了一套解决重要计算集群管理问题的 Linu | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2020/05/07 | Anthony Yznaga | [PKRAM: Preserved-over-Kexec RAM](https://lore.kernel.org/patchwork/cover/856356) | NA | v11 ☑ 4.15-rc2 | [PatchWork RFC,00/43](https://lore.kernel.org/patchwork/cover/1237362) | -| 2021/08/02 | Pavel Tatashin | [arm64: MMU enabled kexec relocation](https://patchwork.kernel.org/project/linux-mm/cover/20210802215408.804942-1-pasha.tatashin@soleen.com) | NA | v16 ☐ | [PatchWork v16,00/15](https://patchwork.kernel.org/project/linux-mm/cover/20210802215408.804942-1-pasha.tatashin@soleen.com) | +| 2021/08/02 | Pavel Tatashin | [arm64: MMU enabled kexec relocation](https://patchwork.kernel.org/project/linux-mm/cover/20210802215408.804942-1-pasha.tatashin@soleen.com) | 在 kexec 重定位期间启用 MMU, 以提高重启性能.
如果 kexec 功能用于快速的系统更新, 并且停机时间最少, 那么重新定位 kernel + initramfs 将占用重新引导的很大一部分时间.
重定位慢的原因是它在没有 MMU 的情况下进行, 因此不能从 D-Cache 中受益. | v16 ☐ | [PatchWork v16,00/15](https://patchwork.kernel.org/project/linux-mm/cover/20210802215408.804942-1-pasha.tatashin@soleen.com) | # 11 perf diff --git a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md index c171364..013f233 100644 --- a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md +++ b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md @@ -1669,22 +1669,27 @@ Facebook 指出他们也面临过同样的问题, 所有的 workload 都需要 |:----:|:----:|:---:|:----:|:---------:|:----:| | 2007/02/09 | David Rientjes | [smaps: extract pmd walker from smaps code](https://lore.kernel.org/patchwork/cover/73779) | Referenced Page flag, 通过在 /proc/PID/smap 中新增 pages referenced 计数的支持, 同时引入 `/proc/PID/clear_refs` 允许用户重置进程页面的 referenced 标记. 通过这种方式用户可以找出特定时间段内被访问过的页. 从而估计出进程的 WSS, 区分冷热页. | v1 ☑ 2.6.22-rc1 | [PatchWork v1 0/3](https://lore.kernel.org/patchwork/cover/73777) | | 2007/10/09 | Matt Mackall | [maps4: pagemap monitoring v4](https://lore.kernel.org/patchwork/cover/95279) | 引入 CONFIG_PROC_PAGE_MONITOR, 管理了 `/proc/pid/clear_refs`, `/proc/pid/smaps`, `/proc/pid/pagemap`, `/proc/kpagecount`, `/proc/kpageflags` 多个接口. | v1 ☑ 2.6.25-rc1 | [PatchWork v4 0/12](https://lore.kernel.org/patchwork/cover/95279) | -| 2011/09/28 | Rik van Riel | [V2: idle page tracking / working set estimation](https://lore.kernel.org/patchwork/cover/268228) | Google 的 kstaled 方案, 通过跟踪那些长期和回收未使用页面, 来减少内存使用, 同时不降低业务的性能. | v2 ☐ | [PatchWork RFC](https://lore.kernel.org/patchwork/cover/268228) | -| 2015/07/19 | Vladimir Davydov | [idle memory tracking](https://lore.kernel.org/patchwork/cover/580794) | Google 的 idle page 跟踪技术, CONFIG_IDLE_PAGE_TRACKING 跟踪长期未使用的页面. | v9 ☑ 4.3-rc1 | [PatchWork RFC](https://lore.kernel.org/patchwork/cover/580794), [REDHAT Merge](https://lists.openvz.org/pipermail/devel/2015-October/067103.html), [commit](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=33c3fc71c8cfa3cc3a98beaa901c069c177dc295) | | 2018/12/26 | Fengguang Wu | [PMEM NUMA node and hotness accounting/migration](https://lore.kernel.org/patchwork/cover/1027864) | 尝试使用 NVDIMM/PMEM 作为易失性 NUMA 内存, 使其对普通应用程序和虚拟内存透明. 其中引入 `/proc/PID/idle_pages` 接口, 用于用户空间驱动的热点页面进行统计. 实现冷热页扫描, 以及页面回收路径下的被动内核冷页面迁移, 改进了用于活动用户空间热/冷页面迁移的move_pages() | RFC v2 ☐ 4.20 | PatchWork RFC,v2,00/21](https://lore.kernel.org/patchwork/cover/1027864), [LKML](https://lkml.org/lkml/2018/12/26/138), [github/intel/memory-optimizer](http://github.com/intel/memory-optimizer) | | 2021/03/18 | liubo | [etmem: swap and scan](https://gitee.com/openeuler/kernel/issues/I3W4XW) | openEuler 实现的内存分级扩展技术. | v1 ☐ 4.19 | [etmem tools](https://gitee.com/src-openeuler/etmem) | | 2021/07/20 | SeongJae Park | [Introduce DAMON-based Proactive Reclamation](https://lwn.net/Articles/863753) | 该补丁集改进了用于生产质量的通用数据访问模式内存管理的引擎, 并在其之上实现了主动回收. | v2 ☐ | [PatchWork RFC](https://lore.kernel.org/patchwork/cover/1438747)
*-*-*-*-*-*-*-*
[PatchWork v2](https://lore.kernel.org/patchwork/cover/1442732)
*-*-*-*-*-*-*-*
[PatchWork v3](https://lore.kernel.org/patchwork/cover/1464866) | -| 2021/08/09 | SeongJae Park | [mm: introduce process_mrelease system call](https://lore.kernel.org/patchwork/patch/1474134) | 我们经常希望能杀死不必要的进程, 为更重要的进程释放内存. 例如 Facebook 的 OOM killer 守护程序 oomd 和 Android的低内存killer守护程序lmkd. 对于这样的系统组件, 能够快速有效地释放内存非常. 但是重要不幸的是, 在接收到 SIGKILL 后, 进程释放内存所需的时间可能会根据进程的状态(不间断睡眠)、进程正在运行的内核的大小和 OPP 级别而有所不同. 以更可预测的方式释放目标进程资源的机制将提高系统控制内存压力的能力.
引入 process_mrelease 系统调用, 该调用从调用方的上下文中释放即将死亡的进程的内存. 这样, 内存将以一种更可控的方式释放, 并具有CPU相关性和调用方的优先级.
释放内存的工作量也将由调用方承担. | v9 ☐ | [PatchWork v9,1/2](https://lore.kernel.org/patchwork/cover/1474134) | -### 4.4.2 其他释放手段 + +### 4.4.2 idle memory tracking ------- | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| -| 2021/08/09 | Suren Baghdasaryan | [mm: introduce process_mrelease system call](https://lwn.net/Articles/864184) | 引入 process_mrelease() 加速进程的清理.
在现代系统中，系统组件监控系统的内存状况并负责控制系统内存压力并不罕见。实现这一目标的一种方法是杀死非必要的过程，为更重要的过程释放内存。 -在现代系统中, 系统组件监控系统的内存状况并负责控制系统内存压力并不罕见. 实现这一目标的一种方法是杀死非必要的过程, 为更重要的进程留出更充足的内存.
这方面的例子是 Facebook 的 OOM 杀手 daemon (称为 oomd) 和 Android 的低记忆杀手 daemon(称为 lmkd).
对于这样的系统组件, 能够快速有效地释放内存非常重要. 不幸的是, 在接收到 SIGKILL 之后, 过程释放内存所需的时间可能会根据过程的状态(不间断的睡眠), 过程正在运行的核心的大小和 OPP 级别而变化. 以更可预测的方式释放目标过程资源的机制将提高系统控制其内存压力的能力.
引入 process_mrelease() 系统调用, 从调用者的上下文中释放垂死过程的内存. 这样, 内存就可以通过CPU亲和力和调用者的优先级以更可控的方式释放. | v9 ☐ | [PatchWork v9,1/2](https://lore.kernel.org/patchwork/cover/1474134) | +| 2011/09/28 | Rik van Riel | [V2: idle page tracking / working set estimation](https://lore.kernel.org/patchwork/cover/268228) | Google 的 kstaled 方案, 通过跟踪那些长期和回收未使用页面, 来减少内存使用, 同时不降低业务的性能. | v2 ☐ | [PatchWork RFC](https://lore.kernel.org/patchwork/cover/268228) | +| 2015/07/19 | Vladimir Davydov | [idle memory tracking](https://lore.kernel.org/patchwork/cover/580794) | Google 的 idle page 跟踪技术, CONFIG_IDLE_PAGE_TRACKING 跟踪长期未使用的页面. | v9 ☑ 4.3-rc1 | [PatchWork RFC](https://lore.kernel.org/patchwork/cover/580794), [REDHAT Merge](https://lists.openvz.org/pipermail/devel/2015-October/067103.html), [commit](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=33c3fc71c8cfa3cc3a98beaa901c069c177dc295) | +### 4.4.3 其他释放手段 +------- + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:----:|:---------:|:----:| +| 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 后, 进程释放内存所需的时间可能会根据进程的状态(不间断睡眠)、进程正在运行的内核的大小和 OPP 级别而有所不同. 以更可预测的方式释放目标进程资源的机制将提高系统控制内存压力的能力.
引入 process_mrelease 系统调用, 该调用从调用方的上下文中释放即将死亡的进程的内存. 这样, 内存将以一种更可控的方式释放, 并具有CPU相关性和调用方的优先级.
释放内存的工作量也将由调用方承担. | v9 ☐ | [PatchWork v9,1/2](https://lore.kernel.org/patchwork/cover/1474134) | + # 5 Swappiness @@ -2003,6 +2008,7 @@ Linux 内核在脏页数量到达一定门槛时, 或者用户在命令行输入 | 2020/12/22 | Liang Li | [add support for free hugepage reporting](https://lore.kernel.org/patchwork/cover/1355899) | Free page reporting 只支持伙伴系统中的页面, 它不能报告为 hugetlbfs 预留的页面. 这个补丁在 hugetlb 的空闲列表中增加了对报告巨大页的支持, 它可以被 virtio_balloon 驱动程序用于内存过载和预归零空闲页, 以加速内存填充和页面错误处理. | RFC ☐ | [PatchWork RFC,0/3](https://patchwork.kernel.org/project/linux-mm/cover/20201222074538.GA30029@open-light-1.localdomain) | | 2021/08/16 | Mike Kravetz | [hugetlb: add demote/split page functionality](https://lore.kernel.org/patchwork/cover/1465517) | 实现了 hugetlb 降低策略. 提供了一种“就地”将 hugetlb 页面分割为较小的页面的方法. | v1 ☐ 5.14 | [2021/07/21 PatchWork 0/8](https://patchwork.kernel.org/project/linux-mm/cover/20210721230511.201823-1-mike.kravetz@oracle.com)
*-*-*-*-*-*-*-*
[2021/08/16 PatchWork RESEND,0/8](https://patchwork.kernel.org/project/linux-mm/cover/20210816224953.157796-1-mike.kravetz@oracle.com) | | 2021/08/20 | yaozhenguo | [hugetlbfs: add hugepages_node kernel parameter](https://lore.kernel.org/patchwork/cover/1479318) | 当前内核允许指定启动时要分配的 hugepages 数目. 但目前所有节点的 hugepages 都是平衡的. 在某些场景中, 我们只需要在一个节点中使用 hugepags.
例如: DPDK 需要与 NIC 位于同一节点的 hugepages. 如果 DPDK 在 node1 中需要 4 个 1G 大小的 HugePage, 并且系统有 16 个 numa 节点. 我们必须在内核 cmdline 中保留 64 个 HugePage. 但是, 只使用了 4 个 hugepages. 其他的应该在引导后释放. 如果系统内存不足(例如: 64G), 这将是一项不可能完成的任务. 因此, 添加 hugepages_node 内核参数以指定启动时要分配的 hugepages 的节点数. | v1 ☐ 5.14-rc7 | [2021/07/21 PatchWork 0/8](https://lore.kernel.org/patchwork/cover/1479318) | +| 2021/07/30 | Mina Almasry | [mm, hugepages: add mremap() support for hugepage backed vma](https://patchwork.kernel.org/project/linux-mm/patch/20210730221522.524256-1-almasrymina@google.com) | 只需重新定位页表条目, 即可为 hugepage 的 vma 段支持 mremap(). 页面表条目将重新定位到 mremap() 上的新虚拟地址. | v1 ☑ [5.12-rc1](https://kernelnewbies.org/Linux_5.12#Memory_management) | [PatchWork v1](https://patchwork.kernel.org/project/linux-mm/patch/20210730221522.524256-1-almasrymina@google.com) | ## 7.2 透明大页的支持 @@ -2105,6 +2111,7 @@ Anthony Yznaga 接替了之前同事 Nitin Gupta 的工作, 并基于 Mel 的思 | 2013/09/23 | "Kirill A. Shutemov" | [Transparent huge page cache: phase 1, everything but mmap()](https://lore.kernel.org/patchwork/cover/408000) | 这组补丁集为内核页面缓存增加了巨页的支持. 为了证明建议的更改是功能性的, 为最简单的文件系统 ramfs 启用了该特性, 但是 mmap 除外, 这将在后续的合入中修复. | v4 ☐ | [PatchWork v6,00/22](https://lore.kernel.org/patchwork/cover/408000) | | 2016/06/15 | "Kirill A. Shutemov" | [THP-enabled tmpfs/shmem](https://lore.kernel.org/patchwork/cover/701302) | 这是我的补丁集的第一个版本, 它旨在将 THO 带到 ext4, 它还没有准备好应用或正式使用, 但足以展示该方法.
基本原理与 tmpfs 相同, 并构建在它的基础上. 主要区别在于, 我们需要处理从备份存储器的读取和回写. | v9 ☑ 4.8-rc1 | [PatchWork v1,RFC,00/33](https://lore.kernel.org/patchwork/cover/658181)
*-*-*-*-*-*-*-*
[PatchWork v9,00/32](https://lore.kernel.org/patchwork/cover/685554)
*-*-*-*-*-*-*-*
[PatchWork v9-rebased2,00/37](https://lore.kernel.org/patchwork/cover/689355) | | 2016/07/26 | "Kirill A. Shutemov" | [ext4: support of huge pages](https://lore.kernel.org/patchwork/cover/701302) | 这是我的补丁集的第一个版本, 它旨在将 THO 带到 ext4, 它还没有准备好应用或正式使用, 但足以展示该方法.
基本原理与 tmpfs 相同, 并构建在它的基础上. 主要区别在于, 我们需要处理从备份存储器的读取和回写. | RFC,v1 ☐ | [PatchWork v1,RFC,00/33](https://lore.kernel.org/patchwork/cover/701302) | +| 2021/07/30 | Hugh Dickins | [tmpfs: HUGEPAGE and MEM_LOCK fcntls and memfds](https://patchwork.kernel.org/project/linux-mm/cover/2862852d-badd-7486-3a8e-c5ea9666d6fb@google.com) | 一系列 HUGEPAGE 和 MEM_LOCK tmpfs fcntls 和 memfd_create 标志的清理和修复工作. | v1 ☐ | [PatchWork 00/16](https://patchwork.kernel.org/project/linux-mm/cover/2862852d-badd-7486-3a8e-c5ea9666d6fb@google.com) |