description/memory: direct_compact

2026-09-24 05:53:54 +08:00 · 2022-04-02 21:15:31 +08:00
parent aed61a110e
commit cea38c87c3
2 changed files with 107 additions and 42 deletions
@@ -278,7 +278,7 @@ Linux 一开始是在一台i386上的机器开发的, i386 的硬件页表是2

 最终该特性与 5.16 合入, [Memory Folios Merged For Linux 5.16](https://www.phoronix.com/scan.php?page=news_item&px=Memory-Folios-Lands-Linux-5.16), 代码仓库 [willy/pagecache.git](http://git.infradead.org/users/willy/pagecache.git), 合入链接 [GIT,PULL Memory folios for v5.1](https://patchwork.kernel.org/project/linux-mm/patch/YX4RkYNNZtO9WL0L@casper.infradead.org), [Merge tag 'folio-5.16' of git://git.infradead.org/users/willy/pagecache](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49f8275c7d9247cf1dd4440fc8162f784252c849)

-
+[[GIT,PULL] Folio patches for 5.18 (MM part)](https://patchwork.kernel.org/project/linux-mm/patch/Yjh+EuacJURShtJI@casper.infradead.org/)

 内存管理(memory management) 一般是以 page 为单位进行的, 一个 page 通常包含 4,096 个字节, 也可能更大. 内核已经将 page 的概念扩展到所谓的 compound page(复合页), 即一组组物理连续的单独 page 的组合. 这又使得 "page" 的定义变得有些模糊了. Matthew Wilcox 提出了 "page folio" 的概念, 它实际上仍然是一个 page structure, 只是保证了它一定不是 tail page. 任何接受 folio page 参数的函数都会是对整个 compound page 进行操作(如果传入的确实是一个 compound page 的话), 这样就不会有任何歧义. 从而可以使内核里的内存管理子系统更加清晰; 也就是说, 如果某个函数被改为只接受 folio page 作为参数的话, 很明确, 它们不适用于对 tail page 的操作. 通过 folio 结构来管理内存. 它提供了一些具有自身价值的基础设施, 将内核的文本缩减了约 6kB.

@@ -499,7 +499,7 @@ MADV_PAGEOUT 在某种程度上类似于 MADV_DONTNEED, 它提示内核当前不
 | 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:----:|:----:|:---:|:----:|:---------:|:----:|
 | 2022/01/26 | Pasha Tatashin <pasha.tatashin@soleen.com> | [Hardening page _refcount](https://patchwork.kernel.org/project/linux-mm/cover/20211026173822.502506-1-pasha.tatashin@soleen.com) | 目前很难从根本上解决 `_refcount` 问题, 因为它们通常在损坏发生后才会显现出来. 然而, 它们可能导致灾难性的故障, 如内存损坏.<br>通过添加更多的检查来提高可调试性, 确保 `page->_refcount` 永远不会变成负数(例如, 双空闲不发生, 或冻结后空闲等).<br>1. 增加了对 `_refcount` 异常值的检测.<br>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)<br>*-*-*-*-*-*-*-* <br>[PatchWork RFC,v2,00/10](https://patchwork.kernel.org/project/linux-mm/cover/20211117012059.141450-1-pasha.tatashin@soleen.com)<br>*-*-*-*-*-*-*-* <br>[PatchWork v2,0/9](https://patchwork.kernel.org/project/linux-mm/cover/20211221150140.988298-1-pasha.tatashin@soleen.com), [LORE v2,0/9](https://lore.kernel.org/all/20211221154650.1047963-1-pasha.tatashin@soleen.com)<br>*-*-*-*-*-*-*-* <br>[PatchWork v3,0/9](https://lore.kernel.org/r/20220126183429.1840447-1-pasha.tatashin@soleen.com) |
-| 2022/03/17 | Tong Tiangen <tongtiangen@huawei.com> | [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 支持它.<br>这个补丁集做了一些简单的更改, 使其更容易支持新的体系结构, 然后我们在 ARM64 和 RICV 上支持这个功能. | v1 ☐☑ | [LORE v1,0/4](https://lore.kernel.org/r/20220317141203.3646253-1-tongtiangen@huawei.com) |
+| 2022/03/17 | Tong Tiangen <tongtiangen@huawei.com> | [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 支持它.<br>这个补丁集做了一些简单的更改, 使其更容易支持新的体系结构, 然后我们在 ARM64 和 RICV 上支持这个功能. | v1 ☐☑ | [LORE v1,0/4](https://lore.kernel.org/r/20220317141203.3646253-1-tongtiangen@huawei.com)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/4](https://lore.kernel.org/r/20220322144447.3563146-1-tongtiangen@huawei.com) |


 ### 1.7.3 安全
@@ -1414,6 +1414,7 @@ gpu 和高吞吐量设备在 TLB 丢失和随后的页表遍行情况下, 与 CP
 这不是一个完整的解决方案, 它只是缓解这一问题. 所谓回收是指 MM 在分配内存遇到内存紧张时, 会把一部分内存页面回收. 而[成块回收](https://lwn.net/Articles/211199), 就是尝试成块回收目标回收页相邻的页面, 以形成一块满足需求的高阶连续页块. 这种方法有其局限性, 就是成块回收时没有考虑被连带回收的页面可能是"热页", 即被高强度使用的页, 这对系统性能是损伤.


+*   引入 Lumpy Reclaim

 | 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:----:|:----:|:---:|:----:|:---------:|:----:|
@@ -1421,6 +1422,21 @@ gpu 和高吞吐量设备在 TLB 丢失和随后的页表遍行情况下, 与 CP
 | 2008/07/01 | Mel Gorman <mel@csn.ul.ie> | [Reclaim page capture v1](https://lore.kernel.org/patchwork/patch/121203) | 大 order 页面分配的有一次探索. 这种方法是捕获直接回收中释放的页面, 以便在空闲页面被竞争的分配程序重新分配之前增加它们被压缩的机会. | v1 ☐  | [Patchwork V5](https://lore.kernel.org/patchwork/patch/121203) |
 | 2007/08/02 | Andy Whitcroft <apw@shadowen.org> | [Synchronous Lumpy Reclaim V3](https://lore.kernel.org/patchwork/patch/87667) | 当以较高的阶数应用回收时, 可能会启动大量IO. 这组补丁尝试修复这个问题, 用于在 VM 事件记录器中中将页面标记为非活动时修复, 并在直接回收连续区域时等待页面写回. | v3 ☑ 2.6.23-rc4 | [Patchwork V5](https://lore.kernel.org/patchwork/patch/87667) |

+*   使用内存规整替代 Lumpy Reclaim
+
+| 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:----:|:----:|:---:|:----:|:---------:|:----:|
+| 2010/11/22 | Mel Gorman <mel@csn.ul.ie> | [Use memory compaction instead of lumpy reclaim during high-order allocations V2](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=f3a310bc4e5ce7e55e1c8e25c31e63af017f3e50) | 在分配大内存时, 不再使用成块回收(lumpy reclaim)策略, 而是使用内存规整(memory compaction) | v2 ☑ 2.6.38-rc1 | [2010/11/11 LORE RFC v1,0/3](https://lore.kernel.org/all/1289502424-12661-1-git-send-email-mel@csn.ul.ie)<br>*-*-*-*-*-*-*-* <br>[2010/11/22 LORE v2,0/7](https://lore.kernel.org/lkml/1290440635-30071-1-git-send-email-mel@csn.ul.ie) |
+
+
+*   Lumpy Reclaim 的寿终正寝
+
+| 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:----:|:----:|:---:|:----:|:---------:|:----:|
+| 2012/03/19 | Konstantin Khlebnikov <khlebnikov@openvz.org> | [mm: forbid lumpy-reclaim in shrink_active_list()](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1480de0340a8d5f094b74d7c4b902456c9a06903) | 将 shrink_active_list () 的回收模式重置为 RECLAIM_MODE_SINGLE | RECLAIM_MODE_ASYNC. 其中 SYNC/ASYNC 只在 shrink_page_list() 中使用, 不影响 shrink_active_list().<br>当前 shrink_active_list() 有时工作在成块回收 RECLAIM_MODE_LUMPYRECLAIM 模式, 然后会在 age_active_anon() 中重置回收模式 sc->reclaim_mode. 整体行为和逻辑过于复杂和混乱, 通常, shrink_active_list() 为下一次 shrink_inactive_list() 填充 inactive 列表.  Lumpy Reclaim 时 shring_inactive_list() 将所选页面周围的页面从活动列表和非活动列表中分离出来. 因此, 没必要在 shrink_active_list() 中进行块状隔离. 参见 [LKML](https://lkml.org/lkml/2012/3/15/583). | v1 ☑✓ 3.4-rc1 | [LORE](https://lore.kernel.org/all/20120319091821.17716.54031.stgit@zurg) |
+| 2012/04/11 | Mel Gorman <mgorman@suse.de> | [Removal of lumpy reclaim V2](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=23b9da55c5b0feb484bd5e8615f4eb1ce4169453) | 删除了消除了内存规整路径下的[成块状回收](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c53919adc045bf803252e912f23028a68525753d)和一些[引起阻塞的逻辑](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=41ac1999c3e3563e1810b14878a869c79c9368bb). 最终的结果是, 页面回收过程中脏页上的暂停现在就只剩下了 wait_iff_consugged(). | v1 ☑✓ 3.5-rc1 | [LORE RFC v1,0/2](https://lore.kernel.org/all/1332950783-31662-1-git-send-email-mgorman@suse.de)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/3](https://lore.kernel.org/all/1334162298-18942-1-git-send-email-mgorman@suse.de) |
+
+

 ## 3.3 通过迁移类型分组来实现反碎片
 -------
@@ -1605,6 +1621,8 @@ Mel Gorman 观察到, 所有使用的内存页有三种情形:
 | 2(RECLAIM_WRITE) | 可以将 cache 中的脏数据写回硬盘, 以回收内存. |
 | 4(RECLAIM_UNMAP) | 可以用 swap 方式回收内存 |

+
+
 *   适用场景

 参考 [Documentation/admin-guide/sysctl/vm](https://elixir.bootlin.com/linux/v5.12/source/Documentation/admin-guide/sysctl/vm.rst#L981).
@@ -1694,6 +1712,17 @@ Mel Gorman 观察到, 所有使用的内存页有三种情形:
 | 2016/05/31 | Minchan Kim <minchan@kernel.org> | [Support non-lru page migration](https://lore.kernel.org/patchwork/patch/683233) | 支持非lru页面迁移, 主要解决zram和GPU驱动程序造成的碎片问题<br>到目前为止, 我们只允许对 LRU 页面进行迁移, 这足以生成高阶页面. 但是最近, 嵌入式系统以及终端等设备使用了大量不可移动的页面(如zram、GPU内存), 因此我们看到了一些关于小高阶分配问题的报道. 问题主要是由<br>1. zram 和 GPU 驱动造成的碎片. 在内存压力下, 它们的页面被分散到所有的页块中, 无法进行迁移, 内存规整也不能很好地工作, 所以收缩业务所有的页面, 使得系统非常慢.<br>2. 另一个问题是他们不能使用CMA内存空间, 所以当OOM kill发生时, 我可以在CMA区域看到很多空闲页面, 这不是内存效率. 我们的产品有很大的CMA内存, 虽然CMA中有很大的空闲空间, 但是过多的回收区域来分配GPU和zram页面, 很容易使系统变得很慢. 之前为了解决这个问题, 我们做了几项努力(例如, 增强压缩算法、SLUB回退到0阶页、保留内存、vmalloc等), 但如果系统中存在大量不可移动页, 则从长远来看, 它们的解决方案是无效的. 因此尝试了当前这种方案.  | v2 ☑ [4.8-rc1](https://kernelnewbies.org/Linux_4.8#Memory_management) | [PatchWork](https://lore.kernel.org/patchwork/patch/683233) |


+#### 4.1.1.5 与 NUMA 的冲突
+-------
+
+[十年后数据库还是不敢拥抱 NUMA?](https://zhuanlan.zhihu.com/p/387117470)
+
+
+| 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:----:|:----:|:---:|:----:|:---------:|:----:|
+| 2014/04/07 | Mel Gorman <mgorman@suse.de> | [Disable zone_reclaim_mode by default](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=5f7a75acdb24c7b9c436b3a0a66eec12e101d19c) | 1396910068-11637-1-git-send-email-mgorman@suse.de | v1 ☑✓ 3.16-rc1 | [LORE v1,0/2](https://lore.kernel.org/all/1396910068-11637-1-git-send-email-mgorman@suse.de)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/2](https://lore.kernel.org/lkml/1396945380-18592-1-git-send-email-mgorman@suse.de) |
+
+

 ### 4.1.2 内存回收的慢速路径与直接内存回收 Direct Reclaim
 -------
@@ -1819,7 +1848,8 @@ fde82aaa731de8a23d817971f6080041a4917d06

 | 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:----:|:----:|:---:|:----:|:---------:|:----:|
-| 2016/07/21 | Vlastimil Babka <vbabka@suse.cz> | [compaction-related cleanups v5](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=c3486f5376696034d0fcbef8ba70c70cfcb26f51) | 20160721073614.24395-1-vbabka@suse.cz | v5 ☑✓ 4.8-rc1 | [LORE v5,0/8](https://lore.kernel.org/all/20160721073614.24395-1-vbabka@suse.cz) |
+| 2016/07/21 | Vlastimil Babka <vbabka@suse.cz> | [compaction-related cleanups v5](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=c3486f5376696034d0fcbef8ba70c70cfcb26f51) | 20160721073614.24395-1-vbabka@suse.cz | v5 ☑✓ 4.8-rc1 | [LORE v5,0/8](https://lore.kernel.org/all/20160721073614.24395-1-vbabka@suse.cz), [关注 COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=a5508cd83f10f663e05d212cb81f600a3af46e40) |
+| 2016/09/26 | Vlastimil Babka <vbabka@suse.cz> | [followups to reintroduce compaction feedback for OOM decisions](https://lore.kernel.org/all/20160926162025.21555-1-vbabka@suse.cz) | 20160926162025.21555-1-vbabka@suse.cz | v1 ☑✓ | [LORE v1,0/4](https://lore.kernel.org/all/20160926162025.21555-1-vbabka@suse.cz) |

 4.  CMA 与 `__perform_reclaim()`

@@ -1829,21 +1859,22 @@ fde82aaa731de8a23d817971f6080041a4917d06
 |:----:|:----:|:---:|:----:|:---------:|:----:|
 | 2012/01/25 | Marek Szyprowski <m.szyprowski@samsung.com> | [`mm: extract reclaim code from __alloc_pages_direct_reclaim()`](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bba9071087108d3de70bea274e35064cc480487b) | `__perform_reclaim()` 函数从 `__alloc_pages_direct_reclaim()` 中分离出来.<br>后来在 v3.8 [commit bc357f431c83 ("mm: cma: remove watermark hacks")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bc357f431c836c6631751e3ef7dfe7882394ad67) 移除了 `__reclaim_pages()`. | v1 ☑✓ 3.5-rc1 | [LORE](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bba9071087108d3de70bea274e35064cc480487b) |

-
-
-
 5.  其他

 | 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:----:|:----:|:---:|:----:|:---------:|:----:|
-| 2012/01/24 | Rik van Riel <riel@redhat.com> | [kswapd vs compaction improvements](https://lore.kernel.org/all/20120124131822.4dc03524@annuminas.surriel.com) | 20120124131822.4dc03524@annuminas.surriel.com | v2 ☐☑✓ | [LORE v2,0/3](https://lore.kernel.org/all/20120124131822.4dc03524@annuminas.surriel.com) |
+| 2012/01/24 | Rik van Riel <riel@redhat.com> | [kswapd vs compaction improvements](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=aff622495c9a0b56148192e53bdec539f5e147f2) | 20120124131822.4dc03524@annuminas.surriel.com | v2 ☑✓ 3.4-rc1 | [LORE v2,0/3](https://lore.kernel.org/all/20120124131822.4dc03524@annuminas.surriel.com) |
 | 2012/08/07 | Mel Gorman <mgorman@suse.de> | [Improve hugepage allocation success rates under load](https://lore.kernel.org/all/1344342677-5845-1-git-send-email-mgorman@suse.de) | 1344342677-5845-1-git-send-email-mgorman@suse.de | v1 ☐☑✓ | [LORE v1,0/6](https://lore.kernel.org/all/1344342677-5845-1-git-send-email-mgorman@suse.de) |
 | 2012/12/11 | Marek Szyprowski <m.szyprowski@samsung.com> | [mm: cma: remove watermark hacks](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bc357f431c836c6631751e3ef7dfe7882394ad67) | TODO | v1 ☑✓ 3.8-rc1 | [LORE](https://lore.kernel.org/lkml/1352357985-14869-1-git-send-email-m.szyprowski@samsung.com), [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bc357f431c836c6631751e3ef7dfe7882394ad67) |

 cfd19c5a9ecf8e5e38de2603077c4330af21316e
-33c2d21438daea807947923377995c73ee8ed3fc
 a8161d1ed6098506303c65b3701dedba876df42a

+| 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:----:|:----:|:---:|:----:|:---------:|:----:|
+| 2016/08/10 | Mel Gorman <mel@csn.ul.ie> | [make direct compaction more deterministic](https://lore.kernel.org/patchwork/patch/692460) | 更有效地直接规整(压缩迁移). 在内存分配的慢速路径 `__alloc_pages_slowpath` 中的之前一直会先尝试直接回收和规整, 直到分配成功或返回失败.<br>1. 当回收先于压缩时更有可能成功, 因为压缩需要满足某些苛刻的条件和水线要求, 并且在有更多的空闲页面时会增加压缩成功的概率.<br>2. 另一方面, 从轻异步压缩(如果水线允许的话)开始也可能更有效, 特别是对于较小 order 的申请. 因此[这个补丁])(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a8161d1ed6098506303c65b3701dedba876df42a)将慢速路径下的尝试流程修正为将先进行 MIGRATE_ASYNC 异步迁移(规整), 再尝试内存直接回收, 接着进行 MIGRATE_SYNC_LIGHT 轻度同步迁移(规整). 并引入了[直接规整的优先级](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a5508cd83f10f663e05d212cb81f600a3af46e40). | RFC v2 ☑ 4.8-rc1 & 4.9-rc1 | [PatchWork v3](https://lore.kernel.org/patchwork/patch/692460)<br>*-*-*-*-*-*-*-* <br>[PatchWork series 1 v5](https://lore.kernel.org/patchwork/patch/700017)<br>*-*-*-*-*-*-*-* <br>[PatchWork series 2 v6](https://lore.kernel.org/patchwork/patch/705827) |
+
+
 #### 4.1.2.4 `__alloc_pages_may_oom()`
 -------

@@ -2908,7 +2939,36 @@ v2.5 的时候引入了 shrink 机制, 并提供了 API 统一了各个模块的
 ## 4.4 主动的页面回收
 -------

-### 4.4.1 [Proactively reclaiming idle memory](https://lwn.net/Articles/787611)
+
+1.  冷热页区分:  为了能识别那些可以回收的页面, 必须对那些不常用的页面有效地进行跟踪, 即 idle page tracking.
+
+2.  进程内存的 working set size(WSS) 估计: 为了在回收了内存之后还能满足业务的需求, 保障业务性能不下降, 需要能预测出业务运行所需要的实际最小内存. brendangregg 大神对此也有描述, [Working Set Size Estimation](https://www.brendangregg.com/wss.html), 并设计了 wss 工具 [Working Set Size (WSS) Tools for Linux](https://github.com/brendangregg/wss).
+
+### 4.4.1 Idle and stale page tracking
+-------
+
+
+[系统软件工程师必备技能-进程内存的working set size(WSS)测量](https://blog.csdn.net/juS3Ve/article/details/85333717)
+
+[Idle and stale page tracking](https://lwn.net/Articles/461461)
+
+首先是 Google 的方案, 这个特性很好的诠释了上面量两部分的内容, 参见 [V2: idle page tracking / working set estimation](https://lore.kernel.org/patchwork/patch/268228). 其主要实现思路如下:
+
+1.  Google 最开始实现的方案是内核跟踪空闲页面的信息, 并暴露到新增的一个 procfs 的 bitmap 节点 `/sys/kernel/mm/page_idle/bitmap`,  然后 user-space 进程会频繁读取该 sysfs. 参见 [idle memory tracking](https://lore.kernel.org/lkml/cover.1437303956.git.vdavydov@parallels.com), 不过这个方案CPU占用率偏高, 并且内存浪费的也不少.
+
+2.  所以目前 Google 尝试在此基础上进行优化, 形成一个新方案, 基于一个名为 [kstaled 的 kernel thread](https://lkml.org/lkml/2011/9/16/368), 参见 [V2, 0/9: idle page tracking / working set estimation](https://lore.kernel.org/lkml/1317170947-17074-1-git-send-email-walken@google.com). 这个 kernel thread 会利用 page 里的 flag 来跟踪 idle page, 所以不会再浪费更多系统内存了, 不过仍然需要挺多 CPU 时间的. 还有一个新加的 kreclaimd 线程来扫描内存, 回收那些空闲(没人读写访问)太久的页面. CPU 的开销并不小, 会随着需要跟踪的内存空间大小, 以及扫描的频率而线性增加. 在一个 512GB 内存的系统上, 可能会需要一个CPU完全用于做这部分工作. 大多数的时间都是在遍历 reverse-map 列表来查找 page mapping. 他们试过把 reverse-map 的查找去掉, 而是创建一个 PMD page table 链表, 可以改善这部分开销. 这样能减少 CPU 占用率到原来的 2/7. 还有另一个优化是把 kreclaimd 的扫描去掉而直接利用 kstaled 传入的一组页面, 也有明显的效果.
+
+基于 kstaled/kreclaimd 的方案, 没有合入主线, 但是 idle memory tracking 的方案在优化后, 于 4.3 合入了主线, 命名为 [IDLE_PAGE_TRACKING](https://www.kernel.org/doc/html/latest/admin-guide/mm/idle_page_tracking.html). 作者基于这个特性进程运行所需的实际内存预测(WSS), 并提供了一[系列工具 idle_page_tracking](https://github.com/sjp38/idle_page_tracking)来完成这个工作, 参见 [Idle Page Tracking Tools](https://sjp38.github.io/post/idle_page_tracking).
+
+Facebook 指出他们也面临过同样的问题, 所有的 workload 都需要放到 container 里去执行, 用户需要明确申明需要使用多少内存, 不过其实没人知道自己真的会用到多少内存, 因此用户申请的内存数量都太多了, 也就有了类似的overcommit和reclaim问题. Facebook的方案是采用 [PSI(pressure-stall information)](https://lwn.net/Articles/759781), 根据这个来了解内存是否变得很紧张了, 相应的会把LRU list里最久未用的page砍掉. 假如这个举动导致更多的 refault 发生. 不过通过调整内存的回收就调整的激进程度可以缓和 refault. 从而达到较合理的结果, 同时占用的CPU时间也会小得多. 描述其设计方案的论文在 ASPLOS’22 中发表, 并成为四篇 Best Paper 之一, 参见 [TMO: Transparent Memory Offloading in Datacenters](https://dl.acm.org/doi/10.1145/3503222.3507731). 网络上的分析 [知乎, 大荒落 TMO: Transparent Memory Offloading in Datacenters](https://zhuanlan.zhihu.com/p/477786756).
+
+
+| 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:----:|:----:|:---:|:----:|:---------:|:----:|
+| 2011/09/28 | Rik van Riel <riel@redhat.com> | [V2: idle page tracking / working set estimation](https://lore.kernel.org/patchwork/patch/268228) | Google 的 kstaled 方案, 通过跟踪那些长期和回收未使用页面, 来减少内存使用, 同时不降低业务的性能. | v2 ☐ | [LORE v1,0/8](https://lore.kernel.org/all/1316230753-8693-1-git-send-email-walken@google.com)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/9](https://lore.kernel.org/lkml/1317170947-17074-1-git-send-email-walken@google.com) |
+| 2015/07/19 | Vladimir Davydov <vdavydov@parallels.com> | [idle memory tracking](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=d3691d2c6d3e72624c987bbef6f322631bbb2d5d) | Google 的 idle page 跟踪技术, CONFIG_IDLE_PAGE_TRACKING 跟踪长期未使用的页面. | v9 ☑ 4.3-rc1 | [PatchWork RFC]https://lore.kernel.org/lkml/cover.1437303956.git.vdavydov@parallels.com), [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.2 [Proactively reclaiming idle memory](https://lwn.net/Articles/787611)
 -------

 [LWN: 主动回收较少使用的内存页面](https://blog.csdn.net/Linux_Everything/article/details/96416633)
@@ -2917,25 +2977,8 @@ v2.5 的时候引入了 shrink 机制, 并提供了 API 统一了各个模块的

 [Software-defined far memory in warehouse scale computers](https://blog.acolyer.org/2019/05/22/sw-far-memory)

-[系统软件工程师必备技能-进程内存的working set size(WSS)测量](https://blog.csdn.net/juS3Ve/article/details/85333717)
-
 [LSF/MM 2019](https://lwn.net/Articles/lsfmm2019) 期间, 主动回收 IDLE 页面的议题引起了开发者的关注. 通过对业务持续一段时间的页面使用进行监测, 回收掉那些不常用的或者没必要的页面, 在满足业务需求的前提下, 可以节省大量的内存. 这可能比启发式的 kswapd 更有效. 这包括两部分的内容:

-1.  冷热页区分:  为了能识别那些可以回收的页面, 必须对那些不常用的页面有效地进行跟踪, 即 idle page tracking.
-
-2.  进程内存的 working set size(WSS) 估计: 为了在回收了内存之后还能满足业务的需求, 保障业务性能不下降, 需要能预测出业务运行所需要的实际最小内存. brendangregg 大神对此也有描述, [Working Set Size Estimation](https://www.brendangregg.com/wss.html), 并设计了 wss 工具 [Working Set Size (WSS) Tools for Linux](https://github.com/brendangregg/wss).
-
-
-首先是 Google 的方案, 这个特性很好的诠释了上面量两部分的内容, 参见[V2: idle page tracking / working set estimation](https://lore.kernel.org/patchwork/patch/268228). 其主要实现思路如下:
-
-1.  目前已经实现好的方案有一个 user-space 进程会频繁读取 sysfs 提供的 bitmap. 参见 [idle memory tracking](https://lore.kernel.org/patchwork/patch/580794), 引入了一个 `/sys/kernel/mm/page_idle/bitmap`, 不过这个方案CPU占用率偏高, 并且内存浪费的也不少.
-
-2.  所以目前 Google 在试一个新方案, 基于一个名为 kstaled 的 kernel thread, 参见 [V2: idle page tracking / working set estimation](https://lore.kernel.org/patchwork/patch/268228). 这个 kernel thread 会利用 page 里的 flag 来跟踪 idle page, 所以不会再浪费更多系统内存了, 不过仍然需要挺多 CPU 时间的. 还有一个新加的 kreclaimd 线程来扫描内存, 回收那些空闲(没人读写访问)太久的页面. CPU 的开销并不小, 会随着需要跟踪的内存空间大小, 以及扫描的频率而线性增加. 在一个 512GB 内存的系统上, 可能会需要一个CPU完全用于做这部分工作. 大多数的时间都是在遍历 reverse-map 列表来查找 page mapping. 他们试过把 reverse-map 的查找去掉, 而是创建一个 PMD page table 链表, 可以改善这部分开销. 这样能减少 CPU 占用率到原来的 2/7. 还有另一个优化是把 kreclaimd 的扫描去掉而直接利用 kstaled 传入的一组页面, 也有明显的效果.
-
-基于 kstaled 的方案, 没有合入主线, 但是 idle memory tracking 的方案在优化后, 于 4.3 合入了主线, 命名为 [IDLE_PAGE_TRACKING](https://www.kernel.org/doc/html/latest/admin-guide/mm/idle_page_tracking.html). 作者基于这个特性进程运行所需的实际内存预测(WSS), 并提供了一[系列工具 idle_page_tracking](https://github.com/sjp38/idle_page_tracking)来完成这个工作, 参见 [Idle Page Tracking Tools](https://sjp38.github.io/post/idle_page_tracking).
-
-Facebook 指出他们也面临过同样的问题, 所有的 workload 都需要放到 container 里去执行, 用户需要明确申明需要使用多少内存, 不过其实没人知道自己真的会用到多少内存, 因此用户申请的内存数量都太多了, 也就有了类似的overcommit和reclaim问题. Facebook的方案是采用 [PSI(pressure-stall information)](https://lwn.net/Articles/759781), 根据这个来了解内存是否变得很紧张了, 相应的会把LRU list里最久未用的page砍掉. 假如这个举动导致更多的 refault 发生. 不过通过调整内存的回收就调整的激进程度可以缓和 refault. 从而达到较合理的结果, 同时占用的CPU时间也会小得多. 描述其设计方案的论文在 ASPLOS’22 中发表, 并成为四篇 Best Paper 之一, 参见 [TMO: Transparent Memory Offloading in Datacenters](https://dl.acm.org/doi/10.1145/3503222.3507731). 网络上的分析 [知乎, 大荒落 TMO: Transparent Memory Offloading in Datacenters](https://zhuanlan.zhihu.com/p/477786756).
-

 后来还有一些类似的特性也达到了很好的效果.

@@ -2952,18 +2995,10 @@ Facebook 指出他们也面临过同样的问题, 所有的 workload 都需要
 | 2018/12/26 | Fengguang Wu <fengguang.wu@intel.com> | [PMEM NUMA node and hotness accounting/migration](https://lore.kernel.org/patchwork/patch/1027864) | 尝试使用 NVDIMM/PMEM 作为易失性 NUMA 内存, 使其对普通应用程序和虚拟内存透明. 其中引入 `/proc/PID/idle_pages` 接口, 用于用户空间驱动的热点页面进行统计. 实现冷热页扫描, 以及页面回收路径下的被动内核冷页面迁移, 改进了用于活动用户空间热/冷页面迁移的move_pages() | RFC v2 ☐ 4.20 | PatchWork RFC,v2,00/21](https://lore.kernel.org/patchwork/patch/1027864), [LKML](https://lkml.org/lkml/2018/12/26/138), [github/intel/memory-optimizer](http://github.com/intel/memory-optimizer) |
 | 2021/03/18 | liubo <liubo254@huawei.com> | [etmem: swap and scan](https://gitee.com/openeuler/kernel/issues/I3W4XW) | openEuler 实现的内存分级扩展技术. | v1 ☐ 4.19 | [etmem tools](https://gitee.com/src-openeuler/etmem) |
 | 2021/10/19 | SeongJae Park <sjpark@amazon.com> | [Introduce DAMON-based Proactive Reclamation](https://lwn.net/Articles/863753) | 该补丁集改进了用于生产质量的通用数据访问模式内存管理的引擎, 并在其之上实现了主动回收. | v4 ☑ 5.16-rc1 | [PatchWork RFC,00/13](https://patchwork.kernel.org/project/linux-mm/cover/20210720131309.22073-1-sj38.park@gmail.com)<br>*-*-*-*-*-*-*-* <br>[PatchWork RFC,v2,00/14](https://patchwork.kernel.org/project/linux-mm/patch/20210608115254.11930-15-sj38.park@gmail.com)<br>*-*-*-*-*-*-*-* <br>[PatchWork RFC,v3,00/15](https://patchwork.kernel.org/project/linux-mm/cover/20210720131309.22073-1-sj38.park@gmail.com)<br>*-*-*-*-*-*-*-* <br>[PatchWork v4 00/15](https://patchwork.kernel.org/project/linux-mm/cover/20211019150731.16699-1-sj@kernel.org) |
+| 2022/03/31 | Yosry Ahmed <yosryahmed@google.com> | [memcg: introduce per-memcg reclaim interface](https://patchwork.kernel.org/project/linux-mm/patch/20220331084151.2600229-1-yosryahmed@google.com) | MEMCG 中引入 memory.reclaim 使得用户空间可以通过持续探测 MEMCG 并触发主动回收以回收少量内存. 随着 LRU 不断排序, 这将提供更准确和最新的工作集估计, 并可能提供更具确定性的内存过度使用行为. 内存超分配控制器可以对正在运行的应用程序不断变化的行为提供更主动的响应, 而不是被动响应. 在这种情况下, 用户空间回收器的目的不是完全替代 KSWAPD 或直接回收, 而是主动识别内存节约机会, 回收策略设置的一些冷页, 以释放内存, 用于要求更高的作业或安排新作业.<br>谷歌数据中心使用了用户空间主动回收器. 此外, Meta 的[论文 TMO](https://dl.acm.org/doi/pdf/10.1145/3503222.3507731) 最近引用了一个非常类似的特性, 用于用户空间主动回收. | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220331084151.2600229-1-yosryahmed@google.com) |



-### 4.4.2 idle memory tracking
-------
-
-| 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
-|:----:|:----:|:---:|:----:|:---------:|:----:|
-| 2011/09/28 | Rik van Riel <riel@redhat.com> | [V2: idle page tracking / working set estimation](https://lore.kernel.org/patchwork/patch/268228) | Google 的 kstaled 方案, 通过跟踪那些长期和回收未使用页面, 来减少内存使用, 同时不降低业务的性能. | v2 ☐ | [PatchWork RFC](https://lore.kernel.org/patchwork/patch/268228) |
-| 2015/07/19 | Vladimir Davydov <vdavydov@parallels.com> | [idle memory tracking](https://lore.kernel.org/patchwork/patch/580794) | Google 的 idle page 跟踪技术, CONFIG_IDLE_PAGE_TRACKING 跟踪长期未使用的页面. | v9 ☑ 4.3-rc1 | [PatchWork RFC](https://lore.kernel.org/patchwork/patch/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 其他释放手段
 -------

@@ -3290,6 +3325,7 @@ Linux 内核在脏页数量到达一定门槛时, 或者用户在命令行输入
 | 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:----:|:----:|:---:|:----:|:---------:|:----:|
 | 2021/07/13 | Jan Kara <jack@suse.cz> | [writeback: Fix bandwidth estimates](https://patchwork.kernel.org/project/linux-mm/cover/20210712165811.13163-1-jack@suse.cz) | NA | v2 ☐ | [PatchWork 0/5,v2](https://patchwork.kernel.org/project/linux-mm/cover/20210712165811.13163-1-jack@suse.cz) |
+| 2011/08/10 | Mel Gorman <mgorman@suse.de> | [Reduce filesystem writeback from page reclaim v3](https://lore.kernel.org/all/1312973240-32576-1-git-send-email-mgorman@suse.de) | 1312973240-32576-1-git-send-email-mgorman@suse.de | v3 ☐☑✓ | [LORE v3,0/7](https://lore.kernel.org/all/1312973240-32576-1-git-send-email-mgorman@suse.de) |



@@ -3482,6 +3518,7 @@ huge page 最开始只支持 PMD 级别(基础页 4K, 则 PMD 级别为 2MB)的
 | 2020/12/05 | Andi Kleen <ak@linux.intel.com> | [mm: support more pagesizes for MAP_HUGETLB/SHM_HUGETLB](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=42d7395feb56f0655cd8b68e06fc6063823449f8) | Free page reporting 只支持伙伴系统中的页面, 它不能报告为 hugetlbfs 预留的页面. 这个补丁在 hugetlb 的空闲列表中增加了对报告巨大页的支持, 它可以被 virtio_balloon 驱动程序用于内存过载和预归零空闲页, 以加速内存填充和页面错误处理. | v7 ☑ 3.8-rc1 | [LWN v7](https://lwn.net/Articles/533650), [LORE v7](https://lore.kernel.org/lkml/1352157848-29473-2-git-send-email-andi@firstfloor.org), [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=42d7395feb56f0655cd8b68e06fc6063823449f8) |
 | 2015/12/17 | David Woods <dwoods@ezchip.com> | [arm64: Add support for PTE contiguous bit.](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=66b3923a1a0f77a563b43f43f6ad091354abbfe9) | 引入 hugetlb cgroup | v5 ☑ 4.5-rc1 | [LKML v5](https://lore.kernel.org/lkml/1450380686-20911-1-git-send-email-dwoods@ezchip.com) |
 | 2017/08/22 | Punit Agrawal <punit.agrawal@arm.com> | [arm64: Enable contiguous pte hugepage support](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=828f193dd62a40ade5ea8b24cb8b0a22c30df673) | 20170822104249.2189-1-punit.agrawal@arm.com | v7 ☑✓ 4.14-rc1 | [LORE v7,0/9](https://lore.kernel.org/all/20170822104249.2189-1-punit.agrawal@arm.com) |
+| 2022/03/23 | Steve Capper <steve.capper@arm.com> | [tlb: hugetlb: Add arm64 contiguous hint awareness](https://patchwork.kernel.org/project/linux-mm/patch/20220323165218.35499-1-steve.capper@arm.com/) | 该补丁实现了 per-arch 的 tlb_remove_huge_tlb_entry() 能力, 并提供了一个覆盖连续提示大小的 arm64 实现. 在更新 mmu_gather 结构时, tlb_remove_huge_tlb_entry 要支持不同 level HugePage 支持. 但是当前只支持了 PMD_SIZE 和 PUD_SIZE. 而 arm64 上还有两个巨页面需要覆盖: CONT_PTE_SIZE 和 CONT_PMD_SIZE, 当最终用户试图使用大页时, 由于相关 tlb 未正确更新 tlb 结构, 可能会出现 VM_BUG_ON. | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/all/20220323165218.35499-1-steve.capper@arm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/1](https://lore.kernel.org/r/20220330112543.863-1-steve.capper@arm.com) |


 ### 7.1.5 HugeTLB CGROUP
@@ -3619,7 +3656,7 @@ Google 的工程师 Mina Almasry 提出了一种新的思路, 通过 [mremap 的
 | 2021/10/07 | Mike Kravetz <mike.kravetz@oracle.com> | [hugetlb: add demote/split page functionality](https://lore.kernel.org/patchwork/patch/1465517) | 实现了 hugetlb 降低策略. 提供了一种"就地"将 hugetlb 页面分割为较小的页面的方法. | v4 ☐ | [2021/07/21 PatchWork 0/8](https://patchwork.kernel.org/project/linux-mm/cover/20210721230511.201823-1-mike.kravetz@oracle.com)<br>*-*-*-*-*-*-*-* <br>[2021/08/16 PatchWork RESEND,0/8](https://patchwork.kernel.org/project/linux-mm/cover/20210816224953.157796-1-mike.kravetz@oracle.com)<br>*-*-*-*-*-*-*-* <br>[2021/09/23 PatchWork v2,0/4](https://patchwork.kernel.org/project/linux-mm/cover/20210923175347.10727-1-mike.kravetz@oracle.com)<br>*-*-*-*-*-*-*-* <br>[2021/10/07 PatchWork v4,0/5](https://patchwork.kernel.org/project/linux-mm/cover/20211007181918.136982-1-mike.kravetz@oracle.com) |
 | 2022/02/01 | Anshuman Khandual <anshuman.khandual@arm.com> | [mm/hugetlb: Generalize ARCH_WANT_GENERAL_HUGETLB](https://patchwork.kernel.org/project/linux-mm/patch/1643718465-4324-1-git-send-email-anshuman.khandual@arm.com/) | 610328 |v1 ☐☑ | [PatchWork v1,0/1](https://lore.kernel.org/r/1643718465-4324-1-git-send-email-anshuman.khandual@arm.com) |
 | 2022/03/07 | Mike Kravetz <mike.kravetz@oracle.com> | [hugetlb: do not demote poisoned hugetlb pages](https://patchwork.kernel.org/project/linux-mm/patch/20220307215707.50916-1-mike.kravetz@oracle.com/) | 621194 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220307215707.50916-1-mike.kravetz@oracle.com) |
-| 2022/03/07 | Muchun Song <songmuchun@bytedance.com> | [add hugetlb_free_vmemmap sysctl](https://patchwork.kernel.org/project/linux-mm/cover/20220307130708.58771-1-songmuchun@bytedance.com/) | 621009 | v3 ☐☑ | [LORE v3,0/4](https://lore.kernel.org/r/20220307130708.58771-1-songmuchun@bytedance.com) |
+| 2022/03/18 | Muchun Song <songmuchun@bytedance.com> | [add hugetlb_free_vmemmap sysctl](https://patchwork.kernel.org/project/linux-mm/cover/20220307130708.58771-1-songmuchun@bytedance.com/) | 621009 | v3 ☐☑ | [2022/03/07 LORE v3,0/4](https://lore.kernel.org/r/20220307130708.58771-1-songmuchun@bytedance.com)<br>*-*-*-*-*-*-*-* <br>[2022/03/18 LORE v4,0/4](https://lore.kernel.org/r/20220318100720.14524-1-songmuchun@bytedance.com) |



@@ -3803,7 +3840,7 @@ David Rientjes 率先提出了这种想法 [Hugepage collapse in process context
 | 2018/01/03 | Michal Hocko <mhocko@kernel.org> | [unclutter thp migration](https://lore.kernel.org/patchwork/patch/869414) | THP 迁移以令人惊讶的语义侵入了通用迁移. 迁移分配回调应该检查 THP 是否可以立即迁移, 如果不是这样, 则分配一个简单的页面进行迁移. 取消映射和移动, 然后通过将 THP 拆分为小页面, 同时将标题页面移动到新分配的 order-0 页面来修复此问题. 剩余页面通过拆分页面移动到 LRU 列表. 如果 THP 分配失败, 也会发生同样的情况. 这真的很难看而且容易出错. | v1 ☐ | [PatchWork 0/3](https://lore.kernel.org/patchwork/patch/869414) |
 | 2019/08/22 | Yang Shi <yang.shi@linux.alibaba.com> | [Make deferred split shrinker memcg aware](https://lore.kernel.org/patchwork/patch/869414) | 目前, THP 延迟分割收缩器不了解 memcg, 这可能会导致某些配置过早地处罚 OOM.<br>通过引入每个 memcg 延迟拆分队列, 转换延迟拆分收缩器 memcg aware. THP 应位于每个节点或每个 memcg 延迟拆分队列上(如果它属于 memcg). 当页面迁移到另一个 memcg 时, 它也将迁移到目标 memcg 的延迟分割队列.<br>对于每个 memcg 列表, 重复使用第二个尾页的延迟列表, 因为同一个 THP 不能位于多个延迟拆分队列上.<br>使延迟分割收缩器不依赖于 memcg kmem, 因为它不是 slab. 过上述更改, 即使禁用了 memcg kmem(配置 cgroup.memory=nokmem), 测试也不会触发OOM. | v6 ☑ 5.4-rc1 | [PatchWork v6,0/4](https://patchwork.kernel.org/project/linux-mm/cover/1566496227-84952-1-git-send-email-yang.shi@linux.alibaba.com) |
 | 2018/01/03 | Michal Hocko <mhocko@kernel.org> | [unclutter thp migration](https://lore.kernel.org/patchwork/patch/869414) | THP 迁移以令人惊讶的语义侵入了通用迁移. 迁移分配回调应该检查 THP 是否可以立即迁移, 如果不是这样, 则分配一个简单的页面进行迁移. 取消映射和移动, 然后通过将 THP 拆分为小页面, 同时将标题页面移动到新分配的 order-0 页面来修复此问题. 剩余页面通过拆分页面移动到 LRU 列表. 如果 THP 分配失败, 也会发生同样的情况. 这真的很难看而且容易出错. | v1 ☐ | [PatchWork 0/3](https://lore.kernel.org/patchwork/patch/869414) |
-| 2020/11/19 | Zi Yan <ziy@nvidia.com> | [Split huge pages to any lower order pages and selftests.](https://patchwork.kernel.org/project/linux-mm/cover/20201119160605.1272425-1-zi.yan@sent.com) | NA | v1 ☐ | [PatchWork 0/7](https://patchwork.kernel.org/project/linux-mm/cover/20201119160605.1272425-1-zi.yan@sent.com) |
+| 2020/11/19 | Zi Yan <ziy@nvidia.com> | [Split huge pages to any lower order pages and selftests.](https://patchwork.kernel.org/project/linux-mm/cover/20201119160605.1272425-1-zi.yan@sent.com) | NA | v1 ☐ | [PatchWork 0/7](https://patchwork.kernel.org/project/linux-mm/cover/20201119160605.1272425-1-zi.yan@sent.com)<br>*-*-*-*-*-*-*-* <br>[LORE v1,0/5](https://lore.kernel.org/r/20220321142128.2471199-1-zi.yan@sent.com) |


 #### 7.2.5.2 splitting test
@@ -4187,8 +4224,8 @@ Dirty COW(CVE-2016-5195) 是近几年影响比较严重的问题, 参见 [Dirty
 | 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:----:|:----:|:---:|:----:|:---------:|:----:|
 | 2022/01/26 | David Hildenbrand <david@redhat.com> | [mm: COW fixes part 1: fix the COW security issue for THP and hugetlb](https://patchwork.kernel.org/project/linux-mm/cover/20211217113049.23850-1-david@redhat.com) | NA | v1 ☐ | [PatchWork v1,00/11](https://patchwork.kernel.org/project/linux-mm/cover/20211217113049.23850-1-david@redhat.com)<br>*-*-*-*-*-*-*-* <br>[PatchWork v2,0/9](https://lore.kernel.org/r/20220126095557.32392-1-david@redhat.com)<br>*-*-*-*-*-*-*-* <br>[PatchWork v3,0/9](https://lore.kernel.org/r/20220131162940.210846-1-david@redhat.com) |
-| 2022/03/15 | David Hildenbrand <david@redhat.com> | [mm: COW fixes part 2: reliable GUP pins of anonymous pages](https://patchwork.kernel.org/project/linux-mm/cover/20220224122614.94921-1-david@redhat.com/) | 617540 | v1 ☐☑ | [2022/02/24 LORE v1,0/13](https://lore.kernel.org/r/20220224122614.94921-1-david@redhat.com))<br>*-*-*-*-*-*-*-* <br>[2022/03/08 LORE v1,0/15](https://lore.kernel.org/r/20220308141437.144919-1-david@redhat.com)<br>*-*-*-*-*-*-*-* <br>[2022/03/15 LORE v2,0/15](https://lore.kernel.org/r/20220315104741.63071-1-david@redhat.com) |
-| 2022/03/15 | David Hildenbrand <david@redhat.com> | [mm: COW fixes part 3: reliable GUP R/W FOLL_GET of anonymous pages](https://patchwork.kernel.org/project/linux-mm/cover/20220315141837.137118-1-david@redhat.com/) | 623540 | v1 ☐☑ | [LORE v1,0/7](https://lore.kernel.org/r/20220315141837.137118-1-david@redhat.com) |
+| 2022/03/15 | David Hildenbrand <david@redhat.com> | [mm: COW fixes part 2: reliable GUP pins of anonymous pages](https://patchwork.kernel.org/project/linux-mm/cover/20220224122614.94921-1-david@redhat.com/) | 617540 | v1 ☐☑ | [2022/02/24 LORE v1,0/13](https://lore.kernel.org/r/20220224122614.94921-1-david@redhat.com))<br>*-*-*-*-*-*-*-* <br>[2022/03/08 LORE v1,0/15](https://lore.kernel.org/r/20220308141437.144919-1-david@redhat.com)<br>*-*-*-*-*-*-*-* <br>[2022/03/15 LORE v2,0/15](https://lore.kernel.org/r/20220315104741.63071-1-david@redhat.com)<br>*-*-*-*-*-*-*-* <br>[LORE v3,0/16](https://lore.kernel.org/r/20220329160440.193848-1-david@redhat.com) |
+| 2022/03/15 | David Hildenbrand <david@redhat.com> | [mm: COW fixes part 3: reliable GUP R/W FOLL_GET of anonymous pages](https://patchwork.kernel.org/project/linux-mm/cover/20220315141837.137118-1-david@redhat.com/) | 623540 | v1 ☐☑ | [LORE v1,0/7](https://lore.kernel.org/r/20220315141837.137118-1-david@redhat.com)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/8](https://lore.kernel.org/r/20220329164329.208407-1-david@redhat.com) |


 | [CVE-2020-29374](https://nvd.nist.gov/vuln/detail/CVE-2020-29374)  | Intra Process Memory Corruptions due to Wrong COW (FOLL_GET) |
@@ -4394,6 +4431,7 @@ RMAP 反向映射是一种物理地址反向映射虚拟地址的方法.
 | 2009/09/25 | KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> | [memcg updates v5](https://lore.kernel.org/patchwork/patch/129608) | IO 感知的 MEMCG. | v7 ☐ | [PatchWork 0/12](https://lore.kernel.org/patchwork/patch/129608) |
 | 2009/06/15 | Balbir Singh <balbir@linux.vnet.ibm.com>| [Remove the overhead associated with the root cgroup](https://lore.kernel.org/patchwork/patch/160500) | 通过删除与 root cgroup 有关的开销来降低 mem cgroup 的开销<br>1. 删除了与计算 root cgroup中所有页面相关的开销. 作为一个副作用, 我们不能再在 root cgroup中设置内存硬限制.<br>2. 添加了一个新的标记 PCG_ACCT_LRU, 用于跟踪页面是否已被计入. page_cgroup的标记现在被原子地设置, pcg_default_flags 现在已经过时并被删除. | v5 ☑ 2.6.32-rc1 | [PatchWork v5](https://lore.kernel.org/patchwork/patch/160500) |
 | 2009/07/10 | Balbir Singh <balbir@linux.vnet.ibm.com>| [Memory controller soft limit patches (v9)](https://lore.kernel.org/patchwork/patch/163652) | 实现内存资源控制器的软限制.<br>软限制是内存资源控制器的一个新特性, 类似的东西已经以共享的形式存在于组调度程序中. CPU控制器对共享的解释是非常不同的. 对于管理员希望过度使用系统的环境, 软限制是最有用的特性, 这样只有在内存争用时, 限制才会生效. 当前的软限制实现为内存控制器提供了 soft_limit_in_bytes 接口, 而不是为内存+交换控制器提供的接口. 该实现维护一个 RB-Tree, 其中的组超过了其软限制, 并开始从超出该限制的组中回收最大数量的组. | v9 ☑ 2.6.32-rc1 | [PatchWork RFC,0/5](https://lore.kernel.org/patchwork/patch/163652) |
+| 2022/03/31 | zhaoyang.huang <zhaoyang.huang@unisoc.com> | [[RFC] cgroup: introduce dynamic protection for memcg](https://patchwork.kernel.org/project/linux-mm/patch/1648713656-24254-1-git-send-email-zhaoyang.huang@unisoc.com) | 动态限制的 MEMCG.<br>对于某些类型的 MEMCG, 使用情况因场景而异. 例如, 多媒体应用的使用范围可能在 50MB 到 500MB 之间, 这是通过在其虚拟地址空间中加载特殊算法生成的, 如果没有用户空间的交互, 很难保护扩展的使用. 此外, 固定的 mem.low 有点违背了它的软保护作用, 因为它会以同样的方式响应任何系统的内存压力. 在此基础上, 提出了一种基于组水印和系统内存压力的动态保护方案. 目标是: 1. 动态保护, 无固定设置限值. 2. 正确的内存保护值. 3. 基于时间的衰变保护 4. 记忆压力相关保护.<br>引入 elow, emin<br>1. 在保护方面, elow 是根据水印的比例在适当的范围内.<br>2. 经过时间通过 decayed_watermark 对 elow 有积极的影响.<br>3. 内存压力对 low 有负面影响, 当系统压力较小时, low 可以保持更多的使用. | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/1648713656-24254-1-git-send-email-zhaoyang.huang@unisoc.com) |



@@ -4496,7 +4534,7 @@ git://github.com/glommer/linux.git kmemcg-slab
 | 2022/02/01 | Yosry Ahmed <yosryahmed@google.com> | [memcg: add per-memcg total kernel memory stat](https://patchwork.kernel.org/project/linux-mm/patch/20220201200823.3283171-1-yosryahmed@google.com/) | 610482 | v1 ☐☑ | [PatchWork v1,0/1](https://lore.kernel.org/r/20220201200823.3283171-1-yosryahmed@google.com)<br>*-*-*-*-*-*-*-* <br>[PatchWork v2,0/1](https://lore.kernel.org/r/20220203193856.972500-1-yosryahmed@google.com) |


-## 9.4 memcg LRU
+## 9.4 MEMCG LRU
 -------

 ### 9.4.1 双 LRU 方案(per-memcg 的 per-zone LRU + 全局 LRU)
@@ -4581,12 +4619,18 @@ zone->lru_锁是一个竞争激烈的锁, 因此 2012 年左右 Konstantin Khleb
 | 2012/02/20 | Hugh Dickins <hughd@google.com> | [mm/memcg: per-memcg per-zone lru locking](https://lore.kernel.org/patchwork/patch/288055) | per-memcg lru lock | v1 ☐ 3.4 | [PatchWork v1, 00/10](https://lore.kernel.org/lkml/alpine.LSU.2.00.1202201518560.23274@eggly.anvils) |
 | 2020/12/05 | Alex Shi <alex.shi@linux.alibaba.com> | [per memcg lru lock](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=15b447361794271f4d03c04d82276a841fe06328) | per memcg LRU lock | v21 ☑ [5.11](https://kernelnewbies.org/Linux_5.11#Memory_management) | [LORE v4,0/9](https://lore.kernel.org/lkml/1574166203-151975-1-git-send-email-alex.shi@linux.alibaba.com)<br>*-*-*-*-*-*-*-* <br>[LORE v21,00/19](https://lore.kernel.org/all/1604566549-62481-1-git-send-email-alex.shi@linux.alibaba.com) |

+### 9.4.5 MEMCG Reclaim
+-------
+
+
 | 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:----:|:----:|:---:|:----:|:---------:|:----:|
 | 2011/05/26 | KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> | [memcg async reclaim](https://lore.kernel.org/patchwork/patch/251835) | 实现 MEMCG 的异步回收机制(Asynchronous memory reclaim)<br>1. 当使用 memc g时, 应用程序可以看到由 memcg 限制引起的内存回收延迟. 一般来说, 这是不可避免的. 有一类应用程序, 它使用许多干净的文件缓存并执行一些交互式工作.<br>2. 如果内核能够帮助后台回收内存, 那么应用程序的延迟就会在一定程度上被隐藏(这取决于应用程序的睡眠方式). 这组补丁程序添加了控制开关 memory.async_control 启用异步回收. 采用动态计算的方法计算了边缘的大小. 该值被确定为减少应用程序达到限制的机会.<br>使用了新引入的 WQ_IDLEPRI 类型(使用 SCHED_IDLE 调度策略)的 kworker(memcg_async_shrinker) 来完整回收的操作. 通过使用 SCHED_IDLE, 系统繁忙的时候异步内存回收只能消耗 0.3% 的 CPU, 但如果cpu空闲, 可以使用很多 CPU. | v3 ☐ | [LORE FRC,0/7](https://lkml.org/lkml/2011/5/10/204)<br>*-*-*-*-*-*-*-* <br>[PatchWork RFC,v3,0/10](https://lore.kernel.org/lkml/20110526141047.dc828124.kamezawa.hiroyu@jp.fujitsu.com) |
 | 2017/05/30 | Johannes Weiner <hannes@cmpxchg.org> | [mm: per-lruvec slab stats](https://lore.kernel.org/patchwork/patch/793422) | Josef 正在研究一种平衡 slab 缓存和 page cache 的新方法. 为此, 他需要 lruvec 级别的 slab 缓存统计信息. 这些补丁通过添加基础设施来实现这一点, 该基础设施允许每个 lruvec 更新和读取通用 VM 统计项, 然后将一些现有VM记帐站点(包括slab记帐站点)切换到这个新的 cgroup 感知 API. | v1 ☑ 4.13-rc1 | [PatchWork 0/6](https://lore.kernel.org/patchwork/patch/793422) |
 | 2021/02/17 | Yang Shi <shy828301@gmail.com> | [Make shrinker's nr_deferred memcg aware](https://lore.kernel.org/patchwork/patch/1393744) | 最近, 在一些 vfs 元数据繁重的工作负载上看到了大量的 one-off slab drop, 造成收缩器了大量累积的 nr_deferred 对象.<br>这个是由多种原因导致的.<br>这组补丁集使 nr_deferred 变成 per-memcg 来解决问题. | v10 ☑ 5.13-rc1 | [PatchWork v10,00/13](https://patchwork.kernel.org/project/linux-mm/cover/20210217001322.2226796-1-shy828301@gmail.com) |
 | 2021/10/19 | Huangzhaoyang <huangzhaoyang@gmail.com> | [mm: skip current when memcg reclaim](https://patchwork.kernel.org/project/linux-mm/patch/1634628576-27448-1-git-send-email-huangzhaoyang@gmail.com) | NA | v2 ☐ | [PatchWork v1](https://patchwork.kernel.org/project/linux-mm/patch/1634278529-16983-1-git-send-email-huangzhaoyang@gmail.com)<br>*-*-*-*-*-*-*-* <br>[PatchWork v2](https://patchwork.kernel.org/project/linux-mm/patch/1634628576-27448-1-git-send-email-huangzhaoyang@gmail.com) |
+| 2022/03/31 | Yosry Ahmed <yosryahmed@google.com> | [memcg: introduce per-memcg reclaim interface](https://patchwork.kernel.org/project/linux-mm/patch/20220331084151.2600229-1-yosryahmed@google.com) | 用户空间主动回收器可以持续探测 MEMCG 以回收少量内存. 随着 LRU 不断排序, 这将提供更准确和最新的工作集估计, 并可能提供更具确定性的内存过度使用行为. 内存超分配控制器可以对正在运行的应用程序不断变化的行为提供更主动的响应, 而不是被动响应. 在这种情况下, 用户空间回收器的目的不是完全替代 KSWAPD 或直接回收, 而是主动识别内存节约机会, 回收策略设置的一些冷页, 以释放内存, 用于要求更高的作业或安排新作业.<br>谷歌数据中心使用了用户空间主动回收器. 此外, Meta 的[论文 TMO](https://dl.acm.org/doi/pdf/10.1145/3503222.3507731) 最近引用了一个非常类似的特性, 用于用户空间主动回收. | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220331084151.2600229-1-yosryahmed@google.com) |
+



@@ -5123,6 +5167,7 @@ SLAB 作为一个相对独立的子模块, 一直有自己完善的调试支持,
 | 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:----:|:----:|:---:|:----:|:---------:|:----:|
 | 2020/08/04 | Andrey Konovalov <andreyknvl@google.com> | [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 <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) |


 #### 13.3.4.2 Software tag-based KASAN
@@ -5262,6 +5307,7 @@ KFENCE 的灵感来自于 [GWP-ASan](http://llvm.org/docs/GwpAsan.html), 这是
 | 2021/12/28 | Minchan Kim <minchan@kernel.org> | [mm: introduce page pin owner](https://patchwork.kernel.org/project/linux-mm/patch/20211228175904.3739751-1-minchan@kernel.org) | NA | RFC,v2 ☐ | [PatchWork RFC,v2](https://patchwork.kernel.org/project/linux-mm/patch/20211228175904.3739751-1-minchan@kernel.org) |
 | 2022/02/08 | Waiman Long <longman@redhat.com> | [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)<br>*-*-*-*-*-*-*-* <br>[PatchWorkv2,0/3](https://lore.kernel.org/r/20220129205315.478628-1-longman@redhat.com)<br>*-*-*-*-*-*-*-* <br>[PatchWorkv3,0/4](https://lore.kernel.org/r/20220131192308.608837-1-longman@redhat.com)<br>*-*-*-*-*-*-*-* <br>[PatchWorkv4,0/4](https://lore.kernel.org/r/20220202203036.744010-1-longman@redhat.com)<br>*-*-*-*-*-*-*-* <br>[PatchWork v5,0/4](https://lore.kernel.org/r/20220208000532.1054311-1-longman@redhat.com) |
 | 2022/02/19 | Yixuan Cao <caoyixuan2019@email.szu.edu.cn> | [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 <zhangyinan2019@email.szu.edu.cn> | [[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) |


 ### 13.4.3 PROC_PAGE_MONITOR
@@ -5421,6 +5467,7 @@ DAMON 利用两个核心机制 : **基于区域的采样**和**自适应区域
 | 2021/07/14 | Zhansaya Bagdauletkyzy <zhansayabagdaulet@gmail.com> | [add KSM selftests](https://lore.kernel.org/patchwork/patch/1459608) | 新增 KSM 相关的 selftest. | v1 ☑ NA | [PatchWork v2,0/4](https://patchwork.kernel.org/project/linux-mm/cover/cover.1626252248.git.zhansayabagdaulet@gmail.com) |
 | 2021/08/19 | Zhansaya Bagdauletkyzy <zhansayabagdaulet@gmail.com> | [add KSM performance tests](https://lore.kernel.org/patchwork/patch/1470603) | 新增 KSM 性能相关的 selftest. | v1 ☑ NA | [PatchWork 0/2](https://patchwork.kernel.org/project/linux-mm/cover/cover.1627828548.git.zhansayabagdaulet@gmail.com)<br>*-*-*-*-*-*-*-* <br>[PatchWork v3,0/2](https://patchwork.kernel.org/project/linux-mm/cover/cover.1629386192.git.zhansayabagdaulet@gmail.com) |
 | 2022/03/14 | Lv Ruyi <cgel.zte@gmail.com> | [ksm: Count ksm-merging pages for each process](https://patchwork.kernel.org/project/linux-mm/patch/20220314015355.2111696-1-xu.xin16@zte.com.cn/) | 由于当前 KSM 只计算 KSM 合并页面的数量(例如, ksm_pages_sharing 和 ksm_pages_shared), 无法看到更细粒度的 KSM 合并, 对于上层应用程序优化, 无法根据每个进程的 KSM 页面合并概率轻松设置合并区域. 因此, 有必要添加额外的统计手段, 以便上层用户能够了解每个进程的详细 KSM 合并信息.<br>这个补丁在 proc 下添加了一个名为 ksm_merging_pages 的新文件, 以表示该进程中涉及的 KSM 合并页面. | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/all/20220314015355.2111696-1-xu.xin16@zte.com.cn)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/1](https://lore.kernel.org/all/20220315114849.2119443-1-xu.xin16@zte.com.cn) |
+| 2022/03/23 | CGEL <cgel.zte@gmail.com> | [mm/vmstat: add events for ksm cow](https://patchwork.kernel.org/project/linux-mm/patch/20220323031730.2342930-1-yang.yang29@zte.com.cn/) | 当用户想要节省内存时, 可以通过调用 madvise MADV_MERGEABLE 来使用 KSM, 但是这会导致 KSM COW 延迟. 用户可以通过读取 `/sys/kernel/mm/ksm/pages_sharing` 来了解 KSM 节省了多少内存, 但他们不知道 KSM COW 的成本, 这对于一些延迟敏感的任务来说是很重要的. 因此, 添加 KSM COW 事件(KSM_COW_SUCCESS 和 KSM_COW_FAIL)来帮助用户评估是否或如何使用 KSM. | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/all/20220323031730.2342930-1-yang.yang29@zte.com.cn)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/1](https://lore.kernel.org/all/20220323075714.2345743-1-yang.yang29@zte.com.cn)<br>*-*-*-*-*-*-*-* <br>[LORE v3,0/1](https://lore.kernel.org/all/20220324104332.2350482-1-yang.yang29@zte.com.cn) |



@@ -5722,6 +5769,7 @@ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e
 | 2016/01/08 | Taku Izumi <izumi.taku@jp.fujitsu.com> | [mm: Introduce kernelcore=mirror option](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=342332e6a925e9ed015e5465062c38d2b86ec8f9) | 内存镜像, 提供内存可靠性分级的功能.<br>通过 UEFI BIOS(规范 2.5) 上报镜像内存(即高可靠内存 mirrored/reliable)的范围和非镜像内存(即低可靠内存)的两种内存. 内核默认使用高可靠的内存, 用 NORMAL ZONE 管理, 用户态优先使用普通(低可靠的)内存, 使用 MOVABLE ZONE 管理. | v4 ☑ 4.6-rc1 | [LKML RFC](https://lkml.org/lkml/2015/10/9/24)<br>*-*-*-*-*-*-*-* <br>[LKML v1](https://lkml.org/lkml/2015/10/15/9)<br>*-*-*-*-*-*-*-* <br>[LKML v2,0/2](https://lkml.org/lkml/2015/11/27/18)<br>*-*-*-*-*-*-*-* <br>[LKML v3,0/2](https://lkml.org/lkml/2015/12/8/836)<br>*-*-*-*-*-*-*-* <br>[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 <qiuxishi@huawei.com> | [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 <rientjes@google.com> | [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 <mawupeng1@huawei.com> | [introduce mirrored memory support for arm64](https://patchwork.kernel.org/project/linux-mm/cover/20220326064632.131637-1-mawupeng1@huawei.com) | 镜像内存支持 arm64. | v1 ☐☑ | [LORE v1,0/9](https://lore.kernel.org/all/20220326064632.131637-1-mawupeng1@huawei.com) |


 ### 14.13.4 其他 ZONE_MOVABLE 相关
@@ -5744,6 +5792,7 @@ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e
 | 2022/01/18 | Khalid Aziz <khalid.aziz@oracle.com> | [Add support for shared PTEs across processes](https://patchwork.kernel.org/project/linux-mm/cover/cover.1642526745.git.khalid.aziz@oracle.com) | NA| v9 ☑ 4.6-rc1 | [LKML RFC,0/6](https://patchwork.kernel.org/project/linux-mm/cover/cover.1642526745.git.khalid.aziz@oracle.com) |
 | 2022/02/11 | Charan Teja Kalla <quic_charante@quicinc.com> | [mm: shmem: implement POSIX_FADV_[WILL|DONT]NEED for shmem](https://patchwork.kernel.org/project/linux-mm/patch/1644572051-24091-1-git-send-email-quic_charante@quicinc.com/) | 613418 | v4 ☐☑ | [PatchWork v4,0/1](https://lore.kernel.org/r/1644572051-24091-1-git-send-email-quic_charante@quicinc.com)<br>*-*-*-*-*-*-*-* <br>[LORE v5,0/2](https://lore.kernel.org/r/cover.1646987674.git.quic_charante@quicinc.com) |
 | 2022/03/14 | Xavier Roche <xavier.roche@algolia.com> | [[v4] tmpfs: support for file creation time](https://patchwork.kernel.org/project/linux-mm/patch/20220314211150.GA123458@xavier-xps/) | 623317 | v4 ☐☑ | [LORE v4,0/1](https://lore.kernel.org/r/20220314211150.GA123458@xavier-xps)|
+| 2022/03/28 | Gabriel Krisman Bertazi <krisman@collabora.com> | [shmem: Allow userspace monitoring of tmpfs for lack of space.](https://patchwork.kernel.org/project/linux-mm/cover/20220322222738.182974-1-krisman@collabora.com/) | 625589 | v1 ☐☑ | [2022/03/22 LORE v1,0/3](https://lore.kernel.org/r/20220322222738.182974-1-krisman@collabora.com)<br>*-*-*-*-*-*-*-* <br>[2022/03/28 LORE v2,0/3](https://lore.kernel.org/r/20220328020443.820797-1-krisman@collabora.com) |


 ### 14.14.2 Anonymous Shared Memory-Ashmem
@@ -1508,7 +1508,7 @@ Oracle 数据库具有类似的虚拟化功能, 称为 Oracle Multitenant, 其
 | 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:----:|:----:|:----:|:---:|:----------:|:---:|
 | 2021/12/01 | Mel Gorman <mgorman@techsingularity.net> | [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 共享缓存, 这种方法就不太理想了. 本系列解决了两个问题:<br>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)<br>*-*-*-*-*-*-*-* <br>[LORE v4,0/2](https://lore.kernel.org/lkml/20211210093307.31701-1-mgorman@techsingularity.net)<br>*-*-*-*-*-*-*-* <br>[LORE v6,0/2](https://lore.kernel.org/all/20220208094334.16379-1-mgorman@techsingularity.net) |
-| 2022/02/17 | K Prateek Nayak <kprateek.nayak@amd.com> | [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 数目, 通常情况下这种机制运行良好.<br>但是对于进程都通过 numactl/taskset PIN 到一组分散的 CPU 上的情况(比如每个 LLC 域中选一个 CPU), 任务的数量将始终在阈值内, 因此所有 8 个流线程将在第一个 SOCKET 上唤醒, 从而导致次优性能. 在最初的少量 CPU 上堆积之后, 虽然负载平衡器可以工作, 但是稳定的均衡状态, 并且需要频繁的迁移 PING PONG.<br>我们可以通过检查本地组中允许的 CPU 数量是否少于本地组中运行的任务数量来检测并避免这种堆积, 并使用此信息将本来会堆积的县城分散到下一个 SOCKET 中(毕竟, 这个慢路径的目标是在初始放置期间找到最空闲的组和最空闲的 CPU).  | v4 ☐☑✓ | [LORE](https://lore.kernel.org/all/20220217055408.28151-1-kprateek.nayak@amd.com) |
+| 2022/02/17 | K Prateek Nayak <kprateek.nayak@amd.com> | [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 数目, 通常情况下这种机制运行良好.<br>但是对于进程都通过 numactl/taskset PIN 到一组分散的 CPU 上的情况(比如每个 LLC 域中选一个 CPU), 任务的数量将始终在阈值内, 因此所有 8 个流线程将在第一个 SOCKET 上唤醒, 从而导致次优性能. 在最初的少量 CPU 上堆积之后, 虽然负载平衡器可以工作, 但是稳定的均衡状态, 并且需要频繁的迁移 PING PONG.<br>我们可以通过检查本地组中允许的 CPU 数量是否少于本地组中运行的任务数量来检测并避免这种堆积, 并使用此信息将本来会堆积的县城分散到下一个 SOCKET 中(毕竟, 这个慢路径的目标是在初始放置期间找到最空闲的组和最空闲的 CPU).  | v4 ☐☑✓ | [LORE](https://lore.kernel.org/all/20220217055408.28151-1-kprateek.nayak@amd.com) |



@@ -2271,6 +2271,16 @@ PREEMPT-RT PATCH 的核心思想是最小化内核中不可抢占部分的代码
 | 2020/05/07 | Parth Shah <parth@linux.ibm.com> | [IDLE gating in presence of latency-sensitive tasks](https://lore.kernel.org/all/20200507133723.18325-1-parth@linux.ibm.com) | 20200507133723.18325-1-parth@linux.ibm.com | v1 ☐☑✓ | [LORE v1,0/4](https://lore.kernel.org/all/20200507133723.18325-1-parth@linux.ibm.com) |
 | 2022/03/11 | Vincent Guittot <vincent.guittot@linaro.org> | [Add latency_nice priority](https://lore.kernel.org/all/20220311161406.23497-1-vincent.guittot@linaro.org) | 参见 [Improved response times with latency nice](https://lwn.net/Articles/887842). | v1 ☐☑✓ | [LORE v1,0/6](https://lore.kernel.org/all/20220311161406.23497-1-vincent.guittot@linaro.org) |

+### 8.9.2 Xen CPU Scheduling
+-------
+
+[Comparison of the three CPU schedulers in Xen](https://dl.acm.org/doi/10.1145/1330555.1330556)
+
+Xen 的 CPU 调度算法主要有 3 种: BVT(borrowed virtual time)调度算法、SEDF(simple earliest deadline first)调度算法、以及 [Credit 调度算法](https://www.cnblogs.com/linanwx/tag/Xen/).
+
+
+
+

 # 9 IDLE
 -------
@@ -2415,14 +2425,20 @@ Roman Gushchin 在邮件列表发起了 BPF 对调度器的潜在应用的讨论

 3.  使用 BPF 加速 ghOSt 内核调度器

-这与谷歌的 ghOSt 非常类似, 但是 ghOSt 比 BPF 的方式要激进很多, ghOSt 的目标是将调度代码转移到用户空间. 它们的核心动机似乎有些相似:使调度器更改更容易开发、验证和部署. 尽管他们的方法不同, 他们也使用 BPF 来加速一些热点路径. 但是作者认为使用 BPF 的方式也可以达到他们的目的. , 参见 [eBPF in CPU Scheduler](https://linuxplumbersconf.org/event/11/contributions/954/attachments/776/1463/eBPF%20in%20CPU%20Scheduler.pdf)
+这与谷歌的 ghOSt 非常类似, 但是 ghOSt 比 BPF 的方式要激进很多, ghOSt 的目标是将调度代码转移到用户空间. 它们的核心动机似乎有些相似:使调度器更改更容易开发、验证和部署. 尽管他们的方法不同, 他们也使用 BPF 来加速一些热点路径. 但是作者认为使用 BPF 的方式也可以达到他们的目的. 参见 [eBPF in CPU Scheduler](https://linuxplumbersconf.org/event/11/contributions/954/attachments/776/1463/eBPF%20in%20CPU%20Scheduler.pdf)

 | 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:----:|:----:|:---:|:----:|:---------:|:----:|
 | 2021/09/15 | Roman Gushchin <guro@fb.com> | [Scheduler BPF](https://www.phoronix.com/scan.php?page=news_item&px=Linux-BPF-Scheduler) | NA | RFC ☐ | [PatchWork rfc,0/6](https://patchwork.kernel.org/project/netdevbpf/cover/20210916162451.709260-1-guro@fb.com)<br>*-*-*-*-*-*-*-* <br>[LPC 2021](https://linuxplumbersconf.org/event/11/contributions/954)<br>*-*-*-*-*-*-*-* <br>[LKML](https://lkml.org/lkml/2021/9/16/1049), [LWN](https://lwn.net/Articles/869433), [LWN](https://lwn.net/Articles/873244) |

+### 11.2.3 PlugSched
+-------


+[Plugsched](https://gitee.com/anolis/plugsched) 是 OpenAnolos Linux 内核调度器子系统热升级的 SDK, 它可以实现在不重启系统、应用的情况下动态替换调度器子系统, 毫秒级 downtime. Plugsched 可以对生产环境中的内核调度特性动态地进行增、删、改, 以满足不同场景或应用的需求, 且支持回滚. 参见 [龙蜥开源 Plugsched：首次实现 Linux kernel 调度器热升级 | 龙蜥技术](https://openanolis.cn/blog/detail/532955762604705772).
+
+基于 Plugsched 实现的调度器热升级, 不修改现有内核代码, 就能获得较好的可修改能力, 天然支持线上的老内核版本. 如果提前在内核调度器代码的关键数据结构中加入 Reserve 字段, 可以额外获得修改数据结构的能力, 进一步提升可修改能力.
+

 ## 11.4 其他
 -------