mirror of
https://github.com/gatieme/LDD-LinuxDeviceDrivers.git
synced 2026-09-24 05:53:54 +08:00
description/LKML: update patchwork to day 20220818
This commit is contained in:
Cheng Jian
@@ -203,6 +203,7 @@ $reclaim = current\_mem \times reclaim\_ratio \times max(0,1 – \frac{psi_some}
|
||||
| 2020/03/03 | Suren Baghdasaryan <surenb@google.com> | [psi: Add PSI_CPU_FULL state and some code optimization](ttps://lore.kernel.org/patchwork/patch/1388805) | 1. 添加 PSI_CPU_FULL 状态标记 cgroup 中的所有非空闲任务在 cgroup 之外的 CPU 资源上被延迟, 或者 cgroup 被 throttle<br>2. 使用 ONCPU 状态和当前的 in_memstall 标志来检测回收, 删除 timer tick 中的钩子, 使代码更简洁和可维护.<br>4. 通过移除两个任务的每个公共cgroup祖先的psi_group_change()调用来优化自愿睡眠开关. | v2 ☑ 5.13-rc1 | [Patchwork](https://lore.kernel.org/patchwork/patch/1388805) |
|
||||
| 2020/03/31 | Yafang Shao <laoar.shao@gmail.com> | [psi: enhance psi with the help of ebpf](https://lwn.net/Articles/1218304) | 引入 psi_memstall_type 标记 MEMSTALL 的类别, 并在 tracepoint 输出, 从而可以被 ebpf 使用来增强工具. | v4 ☑ [4.20-rc1](https://kernelnewbies.org/Linux_4.20#Core_.28various.29) | [Patchwork](https://lore.kernel.org/patchwork/patch/1218304) |
|
||||
| 2022/07/21 | Chengming Zhou <zhouchengming@bytedance.com> | [sched/psi: some optimization and extension](https://lore.kernel.org/all/20220721040439.2651-1-zhouchengming@bytedance.com) | 优化 PSI 的性能, 同时增加对 IRQ/SOFTIRQ 的负载压力跟踪. | v1 ☐☑✓ | [LORE v1,0/9](https://lore.kernel.org/all/20220721040439.2651-1-zhouchengming@bytedance.com) |
|
||||
| 2022/08/01 | CGEL <cgel.zte@gmail.com> | [[RFC,1/2] psi: introduce memory.pressure.stat](https://patchwork.kernel.org/project/linux-mm/patch/20220801004205.1593100-1-ran.xiaokai@zte.com.cn/) | 664363 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/20220801004205.1593100-1-ran.xiaokai@zte.com.cn) |
|
||||
|
||||
|
||||
# 7 DYNAMIC_DEBUG
|
||||
|
||||
@@ -526,7 +526,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)<br>*-*-*-*-*-*-*-* <br>[PatchWork v3,0/9](https://lore.kernel.org/r/20220126183429.1840447-1-pasha.tatashin@soleen.com) |
|
||||
| 2021/12/21 | Pasha Tatashin <pasha.tatashin@soleen.com> | [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 <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)<br>*-*-*-*-*-*-*-* <br>[LORE v4,0/4](https://lore.kernel.org/r/20220418034444.520928-1-tongtiangen@huawei.com)<br>*-*-*-*-*-*-*-* <br>[LORE v5,0/5](https://lore.kernel.org/r/20220421082042.1167967-1-tongtiangen@huawei.com)<br>*-*-*-*-*-*-*-* <br>[LORE v7,0/6](https://lore.kernel.org/r/20220507110114.4128854-1-tongtiangen@huawei.com) |
|
||||
| 2022/05/31 | Matthew Wilcox <willy@infradead.org> | [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) |
|
||||
| 2022/05/31 | Matthew Wilcox <willy@infradead.org> | [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)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/16](https://lore.kernel.org/r/20220809171854.3725722-1-willy@infradead.org) |
|
||||
|
||||
### 1.7.4 Local Page Tables
|
||||
-------
|
||||
@@ -632,7 +632,7 @@ MTE 实现了锁和密钥访问内存. 这样在内存访问期间, 可以在内
|
||||
|
||||
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|
||||
|:----:|:----:|:---:|:----:|:---------:|:----:|
|
||||
| 2021/02/05 | "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> | [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)<br>*-*-*-*-*-*-*-* <br>[LORE v1,0/8](https://lore.kernel.org/r/20220610143527.22974-1-kirill.shutemov@linux.intel.com) |
|
||||
| 2021/02/05 | "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> | [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)<br>*-*-*-*-*-*-*-* <br>[LORE v1,0/8](https://lore.kernel.org/r/20220610143527.22974-1-kirill.shutemov@linux.intel.com))<br>*-*-*-*-*-*-*-* <br>[LORE v1,0/11](https://lore.kernel.org/r/20220815041803.17954-1-kirill.shutemov@linux.intel.com) |
|
||||
|
||||
|
||||
## 1.9 page attributes
|
||||
@@ -1692,7 +1692,7 @@ kmalloc 的 API 家族对 mm 非常关键, 但有一个缺点, 就是它的对
|
||||
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|
||||
|:----:|:----:|:---:|:----:|:---------:|:----:|
|
||||
| 2022/04/14 | Hyeonggon Yoo <42.hyeyoo@gmail.com> | [common kmalloc subsystem on SLAB/SLUB](https://patchwork.kernel.org/project/linux-mm/cover/20220308114142.1744229-1-42.hyeyoo@gmail.com) | 清理 slab 公共代码. 在这组补丁之后后, kmalloc 子系统在 SLAB 和 SLUB 之间得到了完美的推广. | v1 ☐☑ | [2022/03/08 LORE v1,00/15](https://lore.kernel.org/r/20220308114142.1744229-1-42.hyeyoo@gmail.com)<br>*-*-*-*-*-*-*-* <br>[2022/04/14 LORE v2,0/23](https://lore.kernel.org/r/20220414085727.643099-1-42.hyeyoo@gmail.com)<br>*-*-*-*-*-*-*-* <br>[2022/07/12 LORE v3,0/15](https://lore.kernel.org/r/20220712133946.307181-1-42.hyeyoo@gmail.com) |
|
||||
| 2022/07/01 | Feng Tang <feng.tang@intel.com> | [mm/slub: enable debugging memory wasting of kmalloc](https://lore.kernel.org/all/20220701135954.45045-1-feng.tang@intel.com) | 这个补丁帮助显示了当前 kmalloc 下的浪费的空间, 信息在 `/sys/kernel/debug/slab/kmalloc-xx/alloc_traces` 中显示, 显示的格式为: waste=总共浪费的字节数目/单词请求浪费的字节数目. | v1 ☐☑✓ | [LORE RFC](https://lore.kernel.org/r/20220630014715.73330-1-feng.tang@intel.com)<br>*-*-*-*-*-*-*-* <br>[LORE](https://lore.kernel.org/all/20220701135954.45045-1-feng.tang@intel.com)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/2](https://lore.kernel.org/r/20220725112025.22625-1-feng.tang@intel.com) |
|
||||
| 2022/07/01 | Feng Tang <feng.tang@intel.com> | [mm/slub: enable debugging memory wasting of kmalloc](https://lore.kernel.org/all/20220701135954.45045-1-feng.tang@intel.com) | 这个补丁帮助显示了当前 kmalloc 下的浪费的空间, 信息在 `/sys/kernel/debug/slab/kmalloc-xx/alloc_traces` 中显示, 显示的格式为: waste=总共浪费的字节数目/单词请求浪费的字节数目. | v1 ☐☑✓ | [LORE RFC](https://lore.kernel.org/r/20220630014715.73330-1-feng.tang@intel.com)<br>*-*-*-*-*-*-*-* <br>[LORE](https://lore.kernel.org/all/20220701135954.45045-1-feng.tang@intel.com)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/2](https://lore.kernel.org/r/20220725112025.22625-1-feng.tang@intel.com)<br>*-*-*-*-*-*-*-* <br>[LORE v4,0/17](https://lore.kernel.org/r/20220817101826.236819-1-42.hyeyoo@gmail.com) |
|
||||
|
||||
|
||||
### 2.3.6 改进与优化
|
||||
@@ -1970,6 +1970,7 @@ gpu 和高吞吐量设备在 TLB 丢失和随后的页表遍行情况下, 与 CP
|
||||
| 2015/02/23 | SeongJae Park <sj38.park@gmail.com> | [introduce gcma](https://lore.kernel.org/patchwork/patch/544555) | [GCMA(Guaranteed Contiguous Memory Allocator)方案](http://ceur-ws.org/Vol-1464/ewili15_12.pdf), 倾向于使用 writeback 的page cache 和 完成 swap out 的 anonymous pages 来做 seconday client, 进行迁移. 从而确保 primary client 的分配. | RFC v2 ☐ | [PatchWork](https://lore.kernel.org/patchwork/patch/544555), [GitHub](https://github.com/sjp38/linux.gcma/releases/tag/gcma/rfc/v2) |
|
||||
| 2021/03/02 | Minchan Kim <minchan@kernel.org> | [mm: vmstat: add cma statistics](https://lore.kernel.org/all/20210302183346.3707237-1-minchan@kernel.org) | 将 CMA 分配统计信息输出到 vmstat, 从而可以使用户知道系统使用 CMA 分配成功 (CMA_ALLOC_SUCCESS) 和失败 (CMA_ALLOC_SUCCESS) 的次数和频率. | v2 ☐☑✓ | [LORE](https://lore.kernel.org/all/20210302183346.3707237-1-minchan@kernel.org) |
|
||||
| 2022/04/24 | lipeifeng@oppo.com <lipeifeng@oppo.com> | [mm/page_alloc: give priority to free cma-pages from pcplist to buddy](https://patchwork.kernel.org/project/linux-mm/patch/20220424032734.1542-1-lipeifeng@oppo.com/) | 在许多情况下, cma pages 将回退到可移动页面. 当 cma 页面被释放给 pcplist 时, 我们优先将其从 pcplist 释放给 buddy, 以避免 cma 页面在有足够的自由移动页面时很快被用作可移动页面, 这样可以在 buddy 中节省更多的 cma 页面, 从而减少 cma_alloc 时的页面迁移. | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220424032734.1542-1-lipeifeng@oppo.com) |
|
||||
| 2022/08/10 | Charan Teja Kalla <quic_charante@quicinc.com> | [mm/cma_debug: show complete cma name in debugfs directories](https://patchwork.kernel.org/project/linux-mm/patch/1660152485-17684-1-git-send-email-quic_charante@quicinc.com/) | 666670 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/1660152485-17684-1-git-send-email-quic_charante@quicinc.com) |
|
||||
|
||||
|
||||
#### 2.4.2.2 contiguous pages
|
||||
@@ -3604,6 +3605,7 @@ Refault Distance 算法是为了解决前者, 在第二次读时, 人为地把 p
|
||||
| 2019/11/07 | Johannes Weiner <hannes@cmpxchg.org> | [mm: fix page aging across multiple cgroups](https://lore.kernel.org/patchwork/patch/1150211) | 我们希望VM回收系统中最冷的页面. 但是现在VM可以在一个cgroup中回收热页, 而在其他cgroup中明明有更适合回收的冷缓存. 这是因为回收算法的一部分(非活动/活动列表的平衡, 这是用来保护热缓存数据不受一次性流IO影响的部分.)并不是真正意识到 cgroup 层次结构的.<br>递归 cgroup 回收方案将以相同的速率以循环方式扫描和旋转每个符合条件的 cgroup 的物理 LRU 列表, 从而在所有这些cgroup的页面之间建立一个相对顺序. 然而, 非活动/活动的平衡决策是在每个cgroup内部本地做出的, 所以当一个cgroup冷页面运行不足时, 它的热页面将被回收——即使在相同的回收运行中, 但是同级的 cgroup 中却可能有足够的冷缓存.<br>这组补丁通过将非活动/活动平衡决策提升到回收运行的顶层来修复这个问题. 这要么是一个cgroup达到了它的极限, 要么是直接的全局回收, 如果有物理内存压力. 从那里, 它采用了一个cgroup子树的递归视图来决定是否有必要取消页面. | v1 ☑ [5.5-rc1](https://kernelnewbies.org/Linux_5.5#Memory_management) | [PatchWork](https://lore.kernel.org/patchwork/patch/1150211) |
|
||||
| 2020/04/03 | Joonsoo Kim <iamjoonsoo.kim@lge.com> | [workingset protection/detection on the anonymous LRU list](https://lwn.net/Articles/815342) | 实现对匿名 LRU 页面列表的工作集保护和检测. 在之前的实现中, 新创建的或交换中的匿名页, 都是默认加入到 active LRU list, 然后逐渐降级到 inactive LRU list. 这造成在某种场景下新申请的内存(即使被使用一次cold page)也会把在a ctive list 的 hot page 挤到 inactive list. 为了解决这个的问题, 这组补丁, 将新创建或交换的匿名页面放到 inactive LRU list 中, 只有当它们被足够引用时才会被提升到活动列表. 另外, 因为这些更改可能导致新创建的匿名页面或交换中的匿名页面交换不活动列表中的现有页面, 所以工作集检测被扩展到处理匿名LRU列表. 以做出更优的决策. | v5 ☑ [5.9-rc1](https://kernelnewbies.org/Linux_5.9#Memory_management) | [PatchWork v5](https://lore.kernel.org/patchwork/patch/1219942), [Patchwork v7](https://lore.kernel.org/patchwork/patch/1278082), [ZhiHu](https://zhuanlan.zhihu.com/p/113220105) |
|
||||
| 2020/05/20 | Johannes Weiner <hannes@cmpxchg.org> | [mm: balance LRU lists based on relative thrashing v2](https://lore.kernel.org/patchwork/patch/1245255) | 基于相对抖动平衡 LRU 列表(重新实现了页面缓存和匿名页面之间的 LRU 平衡, 以便更好地与快速随机 IO 交换设备一起工作). : 在交换和缓存回收之间平衡的回收代码试图仅基于内存引用模式预测可能的重用. 随着时间的推移, 平衡代码已经被调优到一个点, 即它主要用于页面缓存, 并推迟交换, 直到 VM 处于显著的内存压力之下. 因为 commit a528910e12ec Linux 有精确的故障 IO 跟踪-回收错误页面的最终代价. 这允许我们使用基于 IO 成本的平衡模型, 当缓存发生抖动时, 这种模型更积极地扫描匿名内存, 同时能够避免不必要的交换风暴. | v1 ☑ [5.8-rc1](https://kernelnewbies.org/Linux_5.8#Memory_management) | [PatchWork v1](https://lore.kernel.org/patchwork/patch/685701)<br>*-*-*-*-*-*-*-* <br>[PatchWork v2](https://lore.kernel.org/lkml/20200520232525.798933-1-hannes@cmpxchg.org) |
|
||||
| 2022/08/16 | Yang Shi <shy828301@gmail.com> | [mm: memcg: export workingset refault stats for cgroup v1](https://patchwork.kernel.org/project/linux-mm/patch/20220816185801.651091-1-shy828301@gmail.com/) | 668186 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220816185801.651091-1-shy828301@gmail.com) |
|
||||
|
||||
|
||||
|
||||
@@ -4661,6 +4663,7 @@ Google 的工程师 Mina Almasry 提出了一种新的思路, 通过 [mremap 的
|
||||
| 2022/05/27 | Mike Kravetz <mike.kravetz@oracle.com> | [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)<br>*-*-*-*-*-*-*-*<br>[LORE v1,0/4](https://lore.kernel.org/r/20220616210518.125287-1-mike.kravetz@oracle.com)<br>*-*-*-*-*-*-*-*<br>[[LORE v2,0/4](https://lore.kernel.org/r/20220621235620.291305-1-mike.kravetz@oracle.com) |
|
||||
| 2022/06/24 | James Houghton <jthoughton@google.com> | [hugetlb: Introduce HugeTLB high-granularity mapping](https://patchwork.kernel.org/project/linux-mm/cover/20220624173656.2033256-1-jthoughton@google.com/) | 引入了HugeTLB高粒度映射(HGM)(曾经叫做 HugeTLB double mapping)的概念. 高粒度映射不需要分解大页面本身;它只影响它们的映射方式. 从广义上讲, 它主要探索如何在不同粒度上映射 HugeTLB 页面, 更重要的是, 部分映射 HugeTLB 页面. | v1 ☐☑ | [LORE v1,0/26](https://lore.kernel.org/r/20220624173656.2033256-1-jthoughton@google.com) |
|
||||
| 2022/06/28 | Muchun Song <songmuchun@bytedance.com> | [Simplify hugetlb vmemmap and improve its readability](https://patchwork.kernel.org/project/linux-mm/cover/20220628092235.91270-1-songmuchun@bytedance.com/) | 654499 | v2 ☐☑ | [LORE v2,0/8](https://lore.kernel.org/r/20220628092235.91270-1-songmuchun@bytedance.com) |
|
||||
| 2022/08/02 | Joao Martins <joao.m.martins@oracle.com> | [[v1] mm/hugetlb_vmemmap: remap head page to newly allocated page](https://patchwork.kernel.org/project/linux-mm/patch/20220802180309.19340-1-joao.m.martins@oracle.com/) | 664896 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220802180309.19340-1-joao.m.martins@oracle.com) |
|
||||
|
||||
|
||||
## 7.2 透明大页的支持
|
||||
@@ -5087,7 +5090,7 @@ khugepaged 处理流程
|
||||
|
||||
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|
||||
|:---:|:----:|:---:|:----:|:---------:|:----:|
|
||||
| 2022/08/05 | alexlzhu@fb.com <alexlzhu@fb.com> | [mm: add thp_utilization metrics to /proc/thp_utilization](https://lore.kernel.org/all/20220805184016.2926168-1-alexlzhu@fb.com) | 由于性能的提高或降低取决于特定应用程序如何使用物理内存, THP 在历史上一直是针对每个应用程序启用的. 当 THP 被大量利用时, 由于 TLB 缓存失败的减少, 应用程序性能会得到改善. 长期以来, 人们一直怀疑启用 THP 时的性能下降是由于大量未充分利用的匿名 THP 造成的. 以前, 没有办法跟踪到底有多少 THP 被实际使用. 通过这个补丁, 帮助开发者了解 THP 的使用情况, 以便在分页方面做出更智能的决策. 这个更改引入了一个工具, 该工具扫描匿名 THP 的所有物理内存, 并根据使用率将它们分组到桶中. 它还包括一个位于 `/sys/kernel/debug/thp_utilization` 下的接口. THP 的利用率定义为 THP 中非零页面的百分比. 工作线程将扫描所有物理内存, 并获得所有匿名 THP 的利用率. 它将通过定期扫描所有物理内存来收集这些信息, 寻找匿名 THP, 根据利用率将它们分组到桶中, 并通过 `/sys/kernel/debug/thp_utilization` 下的 debugfs 报告利用率信息. | v3 ☐☑✓ | [LORE v2](https://lore.kernel.org/lkml/20220809014950.3616464-1-alexlzhu@fb.com)<br>*-*-*-*-*-*-*-* <br>[LORE v3](https://lore.kernel.org/all/20220805184016.2926168-1-alexlzhu@fb.com) |
|
||||
| 2022/08/05 | alexlzhu@fb.com <alexlzhu@fb.com> | [mm: add thp_utilization metrics to /proc/thp_utilization](https://lore.kernel.org/all/20220805184016.2926168-1-alexlzhu@fb.com) | 由于性能的提高或降低取决于特定应用程序如何使用物理内存, THP 在历史上一直是针对每个应用程序启用的. 当 THP 被大量利用时, 由于 TLB 缓存失败的减少, 应用程序性能会得到改善. 长期以来, 人们一直怀疑启用 THP 时的性能下降是由于大量未充分利用的匿名 THP 造成的. 以前, 没有办法跟踪到底有多少 THP 被实际使用. 通过这个补丁, 帮助开发者了解 THP 的使用情况, 以便在分页方面做出更智能的决策. 这个更改引入了一个工具, 该工具扫描匿名 THP 的所有物理内存, 并根据使用率将它们分组到桶中. 它还包括一个位于 `/sys/kernel/debug/thp_utilization` 下的接口. THP 的利用率定义为 THP 中非零页面的百分比. 工作线程将扫描所有物理内存, 并获得所有匿名 THP 的利用率. 它将通过定期扫描所有物理内存来收集这些信息, 寻找匿名 THP, 根据利用率将它们分组到桶中, 并通过 `/sys/kernel/debug/thp_utilization` 下的 debugfs 报告利用率信息. | v3 ☐☑✓ | [LORE v2](https://lore.kernel.org/lkml/20220809014950.3616464-1-alexlzhu@fb.com)<br>*-*-*-*-*-*-*-* <br>[LORE v3](https://lore.kernel.org/all/20220805184016.2926168-1-alexlzhu@fb.com)<br>*-*-*-*-*-*-*-* <br>[LORE v3,0/1](https://lore.kernel.org/r/20220818000112.2722201-1-alexlzhu@fb.com) |
|
||||
|
||||
|
||||
### 7.2.10 优化 struct page 的内存占用
|
||||
@@ -6141,7 +6144,7 @@ Intel 的吴峰光 [PMEM NUMA node and hotness accounting/migration](https://lor
|
||||
| 2021/12/11 | Baolin Wang <baolin.wang@linux.alibaba.com> | [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/07/13 | Huang Ying <ying.huang@intel.com> | [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 ☐☑ | [2022/04/08 LORE v1,0/3](https://lore.kernel.org/r/20220408071222.219689-1-ying.huang@intel.com)<br>*-*-*-*-*-*-*-* <br>[2022/06/22 LORE v1,0/3](https://lore.kernel.org/r/20220622083519.708236-1-ying.huang@intel.com)<br>*-*-*-*-*-*-*-* <br>[2022/07/13 LORE v1,0/3](https://lore.kernel.org/r/20220713083954.34196-1-ying.huang@intel.com) |
|
||||
| 2022/04/13 | Jagdish Gediya <jvgediya@linux.ibm.com> | [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)<br>*-*-*-*-*-*-*-* <br>[LORE v3,0/7](https://lore.kernel.org/r/20220422195516.10769-1-jvgediya@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v1,0/3](https://lore.kernel.org/r/20220426085105.60822-1-ying.huang@intel.com)<br>*-*-*-*-*-*-*-* <br>[LORE v1,0/3](https://lore.kernel.org/r/20220510063958.86985-1-ying.huang@intel.com) |
|
||||
| 2022/07/14 | Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> | [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)<br>*-*-*-*-*-*-*-* <br>[LORE v5,0/9](https://lore.kernel.org/r/20220603134237.131362-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v6,0/13](https://lore.kernel.org/r/20220610135229.182859-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v7,0/12](https://lore.kernel.org/r/20220622082513.467538-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v9,0/8](https://lore.kernel.org/r/20220714045351.434957-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v10,0/8](https://lore.kernel.org/r/20220720025920.1373558-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v11,0/8](https://lore.kernel.org/r/20220728190436.858458-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v12,0/8](https://lore.kernel.org/r/20220729061349.968148-1-aneesh.kumar@linux.ibm.com) |
|
||||
| 2022/07/14 | Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> | [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)<br>*-*-*-*-*-*-*-* <br>[LORE v5,0/9](https://lore.kernel.org/r/20220603134237.131362-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v6,0/13](https://lore.kernel.org/r/20220610135229.182859-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v7,0/12](https://lore.kernel.org/r/20220622082513.467538-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v9,0/8](https://lore.kernel.org/r/20220714045351.434957-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v10,0/8](https://lore.kernel.org/r/20220720025920.1373558-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v11,0/8](https://lore.kernel.org/r/20220728190436.858458-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v12,0/8](https://lore.kernel.org/r/20220729061349.968148-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v13,0/9](https://lore.kernel.org/r/20220808062601.836025-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v14,0/10](https://lore.kernel.org/r/20220812055710.357820-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v15,0/10](https://lore.kernel.org/r/20220818131042.113280-1-aneesh.kumar@linux.ibm.com) |
|
||||
| 2022/06/06 | Aneesh Kumar K V <aneesh.kumar@linux.ibm.com> | [mm/demotion: Add sysfs ABI documentation](https://patchwork.kernel.org/project/linux-mm/patch/87r1428k9n.fsf@linux.ibm.com/) | 647508 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/87r1428k9n.fsf@linux.ibm.com) |
|
||||
| 2022/06/07 | Johannes Weiner <hannes@cmpxchg.org> | [mm: mempolicy: N:M interleave policy for tiered memory nodes](https://patchwork.kernel.org/project/linux-mm/patch/20220607171949.85796-1-hannes@cmpxchg.org/) | 648110 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220607171949.85796-1-hannes@cmpxchg.org) |
|
||||
| 2022/06/14 | Tim Chen <tim.c.chen@linux.intel.com> | [Cgroup accounting of memory tier usage](https://patchwork.kernel.org/project/linux-mm/cover/cover.1655242024.git.tim.c.chen@linux.intel.com/) | 650358 | v1 ☐☑ | [LORE v1,0/3](https://lore.kernel.org/r/cover.1655242024.git.tim.c.chen@linux.intel.com) |
|
||||
@@ -6428,6 +6431,7 @@ KFENCE 的灵感来自于 [GWP-ASan](http://llvm.org/docs/GwpAsan.html), 这是
|
||||
| 2022/06/09 | Jason A. Donenfeld <Jason@zx2c4.com> | [mm/kfence: select random number before taking raw lock](https://patchwork.kernel.org/project/linux-mm/patch/20220609121709.12939-1-Jason@zx2c4.com/) | 648846 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220609121709.12939-1-Jason@zx2c4.com)<br>*-*-*-*-*-*-*-*<br>[LORE v2,0/1](https://lore.kernel.org/r/20220609123319.17576-1-Jason@zx2c4.com) |
|
||||
| 2022/06/28 | Yee Lee <yee.lee@mediatek.com> | [[v2,1/1] mm: kfence: apply kmemleak_ignore_phys on early allocated pool](https://patchwork.kernel.org/project/linux-mm/patch/20220628113714.7792-2-yee.lee@mediatek.com/) | 654579 | v2 ☐☑ | [LORE v2,0/1](https://lore.kernel.org/r/20220628113714.7792-2-yee.lee@mediatek.com) |
|
||||
| 2022/07/27 | Imran Khan <imran.f.khan@oracle.com> | [[RFC] mm/kfence: Introduce kernel parameter for selective usage of kfence.](https://patchwork.kernel.org/project/linux-mm/patch/20220727234241.1423357-1-imran.f.khan@oracle.com/) | 663583 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220727234241.1423357-1-imran.f.khan@oracle.com) |
|
||||
| 2022/08/14 | Imran Khan <imran.f.khan@oracle.com> | [[v3] kfence: add sysfs interface to disable kfence for selected slabs.](https://patchwork.kernel.org/project/linux-mm/patch/20220814195353.2540848-1-imran.f.khan@oracle.com/) | 667448 | v3 ☐☑ | [LORE v3,0/1](https://lore.kernel.org/all/20220814195353.2540848-1-imran.f.khan@oracle.com) |
|
||||
|
||||
|
||||
## 13.4 Debugging
|
||||
@@ -6579,6 +6583,7 @@ DAMON 利用两个核心机制 : **基于区域的采样**和**自适应区域
|
||||
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|
||||
|:----:|:----:|:---:|:----:|:---------:|:----:|
|
||||
| 2021/12/16 | Qi Zheng <zhengqi.arch@bytedance.com> | [add MemAvailable to per-node meminfo](https://patchwork.kernel.org/project/linux-mm/cover/20211216124655.32247-1-zhengqi.arch@bytedance.com) | 在 `/proc/meminfo` 中, 展示了所有可用内存的总和显示为 "MemAvailable". 将相同的计数器也添加到 `/sys` 下的每个节点 `meminfo` 中. | v1 ☐ | [PatchWork 0/1,v2](https://patchwork.kernel.org/project/linux-mm/cover/20211216124655.32247-1-zhengqi.arch@bytedance.com/) |
|
||||
| 2022/08/16 | Kefeng Wang <wangkefeng.wang@huawei.com> | [[RFC] mm, proc: add PcpFree to meminfo](https://patchwork.kernel.org/project/linux-mm/patch/20220816084426.135528-1-wangkefeng.wang@huawei.com/) | 667921 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220816084426.135528-1-wangkefeng.wang@huawei.com) |
|
||||
|
||||
|
||||
|
||||
@@ -6680,6 +6685,7 @@ DAMON 利用两个核心机制 : **基于区域的采样**和**自适应区域
|
||||
| 2022/05/08 | CGEL <cgel.zte@gmail.com> | [mm/ksm: introduce ksm_force for each process](https://patchwork.kernel.org/project/linux-mm/patch/20220508091426.928094-1-xu.xin16@zte.com.cn) | 要使用 KSM, 我们必须在应用程序代码中显式调用 madvise(), 这意味着在操作系统上安装的应用程序需要卸载, 源代码需要修改. 很不方便. 为了改变这种情况, 我们在 `/proc/<pid>` 下添加一个 proc 文件 ksm_force, 以支持动态地打开/关闭进程的 MM 的 KSM 扫描.<br>1. 如果 ksm_force 设置为 1, 强制该 mm 的所有匿名和 "合格" 的 VMA 参与 KSM 扫描, 而不显式调用 madvise() 将 VMA 标记为 MADV_MERGEABLE. 但仅当 "/sys/kernel/mm/ksm/run" 的 klob 设置为 1 时有效.<br>2. 如果 ksm_force 设置为 0, 则取消该进程的 ksm_force 特性, 并取消属于 vma 的合并页面, 这些 vma 不再被合并, 但是依旧保留合并的 MADV_MERGEABLE 区域的行为. | v4 ☐☑ | [LORE v4,0/1](https://lore.kernel.org/r/20220508091426.928094-1-xu.xin16@zte.com.cn)<br>*-*-*-*-*-*-*-* <br>[LORE v6,0/1](https://lore.kernel.org/r/20220510122242.1380536-1-xu.xin16@zte.com.cn)<br>*-*-*-*-*-*-*-* <br>[LORE v7,0/1](https://lore.kernel.org/all/20220512070347.1628163-1-xu.xin16@zte.com.cn) |
|
||||
| 2022/06/09 | CGEL <cgel.zte@gmail.com> | [mm/ksm: provide global_force to see maximum potential merging](https://patchwork.kernel.org/project/linux-mm/patch/20220609055658.703472-1-xu.xin16@zte.com.cn/) | 648704 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220609055658.703472-1-xu.xin16@zte.com.cn) |
|
||||
| 2022/07/01 | CGEL <cgel.zte@gmail.com> | [[linux-next] mm/madvise: allow KSM hints for process_madvise](https://patchwork.kernel.org/project/linux-mm/patch/20220701084323.1261361-1-xu.xin16@zte.com.cn/) | 655733 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220701084323.1261361-1-xu.xin16@zte.com.cn) |
|
||||
| 2022/08/12 | CGEL <cgel.zte@gmail.com> | [propose auto-run mode of ksm and its tests](https://patchwork.kernel.org/project/linux-mm/cover/20220812101102.41422-1-xu.xin16@zte.com.cn/) | 667133 | v2 ☐☑ | [LORE v2,0/5](https://lore.kernel.org/r/20220812101102.41422-1-xu.xin16@zte.com.cn) |
|
||||
|
||||
|
||||
|
||||
@@ -6964,7 +6970,7 @@ ZONE_MOVABLE 一个 pseudo zone, 它实际是从内核划分的某个 zone 中
|
||||
|:----:|:----:|:---:|:----:|:---------:|:----:|
|
||||
| 2013/01/14 | Tang Chen <tangchen@cn.fujitsu.com> | [Add movablecore_map boot option](https://lore.kernel.org/all/1358154925-21537-1-git-send-email-tangchen@cn.fujitsu.com) | 1358154925-21537-1-git-send-email-tangchen@cn.fujitsu.com | v5 ☐☑✓ | [LORE v5,0/5](https://lore.kernel.org/all/1358154925-21537-1-git-send-email-tangchen@cn.fujitsu.com) |
|
||||
| 2021/02/15 | Pavel Tatashin <pasha.tatashin@soleen.com> | [prohibit pinning pages in ZONE_MOVABLE](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=e44605a8b1aa13d892addc59ec3d416cb186c77b) | 参见 [Preserving the mobility of ZONE_MOVABLE](https://lwn.net/Articles/843326) | v11 ☑ 5.13-rc1 | [LWN v7 00/14](https://lwn.net/ml/linux-kernel/20210122033748.924330-1-pasha.tatashin@soleen.com/), [LORE v7,0/4](https://lore.kernel.org/lkml/20210122033748.924330-1-pasha.tatashin@soleen.com)<br>*-*-*-*-*-*-*-* <br>[LORE v11,00/14](https://lore.kernel.org/all/20210215161349.246722-1-pasha.tatashin@soleen.com), [关键 COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d1e153fea2a8940273174fc17733c44323d35cd5) |
|
||||
|
||||
| 2022/08/18 | Wupeng Ma <mawupeng1@huawei.com> | [watermark related improvement on zone movable](https://patchwork.kernel.org/project/linux-mm/cover/20220818090430.2859992-1-mawupeng1@huawei.com/) | 668702 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/20220818090430.2859992-1-mawupeng1@huawei.com) |
|
||||
|
||||
|
||||
### 14.13.2 配置参数
|
||||
|
||||
@@ -569,8 +569,8 @@ coscheduling 协同调度是为了解决云服务场景, 为不同用户提供
|
||||
|
||||
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|
||||
|:----:|:----:|:---:|:----:|:---------:|:----:|
|
||||
| 2019/12/19 | Jan H. Schönherr | [[RFC,00/60] Coscheduling for Linux](https://lore.kernel.org/lkml/20180907214047.26914-1-jschoenh@amazon.de) | 亚马逊的协同调度方案 | RFC ☐ | [LORE RFC,00/60](https://lore.kernel.org/lkml/20180907214047.26914-1-jschoenh@amazon.de) |
|
||||
| 2019/12/19 | Peter & Kirill Tkhai 等 | [Core scheduling](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=67692435c411e5c53a1c588ecca2037aebd81f2e) | 核调度器, 限制同一个 SMT 域内的两个 CPU 只能运行同一组进程.<br>1. v3 合入了 8 个重构的补丁.<br>2. | v9 ☑ 5.4-rc1 | [2019/02/18 LORE RFC](https://lore.kernel.org/lkml/20190218165620.383905466@infradead.org)<br>*-*-*-*-*-*-*-* <br>[2019/04/23 LORE v2,00/17](https://lore.kernel.org/lkml/cover.1556025155.git.vpillai@digitalocean.com)<br>*-*-*-*-*-*-*-* <br>[2019/05/29 LORE v3,00/16](https://lore.kernel.org/all/cover.1559129225.git.vpillai@digitalocean.com)<br>*-*-*-*-*-*-*-* <br>[2019/10/30 LORE v4,00/19](https://lore.kernel.org/lkml/cover.1572437285.git.vpillai@digitalocean.com)<br>*-*-*-*-*-*-*-* <br>[2020/03/04 LORE v5,00/13](https://lore.kernel.org/lkml/cover.1583332764.git.vpillai@digitalocean.com)<br>*-*-*-*-*-*-*-* <br>[2020/06/30 LORE v6,00/16](https://lore.kernel.org/lkml/cover.1593530334.git.vpillai@digitalocean.com)<br>*-*-*-*-*-*-*-* <br>[2020/08/28 LORE v7,00/23](https://lore.kernel.org/lkml/cover.1598643276.git.jdesfossez@digitalocean.com)<br>*-*-*-*-*-*-*-* <br>[2020/10/19 LORE v8,00/26](https://lore.kernel.org/lkml/20201020014336.2076526-1-joel@joelfernandes.org)<br>*-*-*-*-*-*-*-* <br>[2020/11/17 LORE v9,00/32](https://lore.kernel.org/lkml/20201117232003.3580179-1-joel@joelfernandes.org) |
|
||||
| 2018/09/07 | Jan H. Schönherr | [[RFC,00/60] Coscheduling for Linux](https://lore.kernel.org/lkml/20180907214047.26914-1-jschoenh@amazon.de) | 亚马逊的协同调度方案 | RFC ☐ | [LORE RFC,00/60](https://lore.kernel.org/lkml/20180907214047.26914-1-jschoenh@amazon.de) |
|
||||
| 2019/02/18 | Peter & Kirill Tkhai 等 | [Core scheduling](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=67692435c411e5c53a1c588ecca2037aebd81f2e) | 核调度器, 限制同一个 SMT 域内的两个 CPU 只能运行同一组进程.<br>1. v3 合入了 8 个重构的补丁.<br>2. | v9 ☑ 5.4-rc1 | [2019/02/18 LORE RFC](https://lore.kernel.org/lkml/20190218165620.383905466@infradead.org)<br>*-*-*-*-*-*-*-* <br>[2019/04/23 LORE v2,00/17](https://lore.kernel.org/lkml/cover.1556025155.git.vpillai@digitalocean.com)<br>*-*-*-*-*-*-*-* <br>[2019/05/29 LORE v3,00/16](https://lore.kernel.org/all/cover.1559129225.git.vpillai@digitalocean.com)<br>*-*-*-*-*-*-*-* <br>[2019/10/30 LORE v4,00/19](https://lore.kernel.org/lkml/cover.1572437285.git.vpillai@digitalocean.com)<br>*-*-*-*-*-*-*-* <br>[2020/03/04 LORE v5,00/13](https://lore.kernel.org/lkml/cover.1583332764.git.vpillai@digitalocean.com)<br>*-*-*-*-*-*-*-* <br>[2020/06/30 LORE v6,00/16](https://lore.kernel.org/lkml/cover.1593530334.git.vpillai@digitalocean.com)<br>*-*-*-*-*-*-*-* <br>[2020/08/28 LORE v7,00/23](https://lore.kernel.org/lkml/cover.1598643276.git.jdesfossez@digitalocean.com)<br>*-*-*-*-*-*-*-* <br>[2020/10/19 LORE v8,00/26](https://lore.kernel.org/lkml/20201020014336.2076526-1-joel@joelfernandes.org)<br>*-*-*-*-*-*-*-* <br>[2020/11/17 LORE v9,00/32](https://lore.kernel.org/lkml/20201117232003.3580179-1-joel@joelfernandes.org) |
|
||||
| 2021/03/25 | Joel Fernandes 等 | [Core scheduling remaining patches rebase](https://lore.kernel.org/patchwork/cover/1369931) | Core scheduling v9 的大部分补丁都已经在 TIP 分支了, 部分未合入补丁的重构与适配. | v10 ☐ | [2021/01/23 LORE v10,0/5](https://lore.kernel.org/lkml/20210123011704.1901835-1-joel@joelfernandes.org)<br>*-*-*-*-*-*-*-* <br>[2021/03/24 LORE v10 resend,0/8](https://lore.kernel.org/lkml/20210324214020.34142-1-joel@joelfernandes.org) |
|
||||
| 2021/04/01 | Peter Zijlstra | [sched: Core scheduling interfaces](https://lore.kernel.org/lkml/20210401131012.395311786@infradead.org/) | Peter 将 TIP 分支 core scheduling 进行了重构. 重新设计了 Core scheduling 的接口. | v11 ☐ |[2021/04/01 v11,0/9](https://lore.kernel.org/lkml/20210401131012.395311786@infradead.org) |
|
||||
| 2021/04/22 | Peter Zijlstra | [sched: Core Scheduling](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=9f26990074931bbf797373e53104216059b300b1) | Peter 重构后完整的 Core scheduling. | v12 ☑ 5.14-rc1 |[2021/04/22 LORE v12,00/19](https://lore.kernel.org/lkml/20210422120459.447350175@infradead.org) |
|
||||
@@ -1208,7 +1208,8 @@ X86 下提供了一种 Fake Numa 的方式来模拟 NUMA 配置.
|
||||
|
||||
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|
||||
|:---:|:----:|:---:|:----:|:---------:|:----:|
|
||||
| 2022/07/19 | Tariq Toukan <tariqt@nvidia.com> | [Introduce and use NUMA distance metrics](https://lore.kernel.org/all/20220719162339.23865-1-tariqt@nvidia.com) | NVIDIA 工程师一直在 Linux 内核中研究 NUMA 距离指标, 以取代某些驱动程序目前用于 NUMA 感知内存分配的简单本地/远程 NUMA 首选项接口. 在他们的测试中, 这种改进的 NUMA 距离处理对吞吐量和 CPU 利用率产生了"显著的性能影响". 根据调度程序的 sched_numa_find_closest() 实现并公开 CPU spread API sched_cpus_set_spread(). 在给定 NUMA 节点的情况下, 基于距离设置 CPU 分布替代基于 cpumask_local_spread() 的传统逻辑. 在 mlx5 和 enic 设备驱动程序中使用它. 这将使得 NUMA 首选项(本地/远程)替换为考虑实际距离的改进首选项, 因此短距离的远程 NUMA 优先于较远的 NUMA. | v3 ☐☑✓ | [LORE v3,0/3](https://lore.kernel.org/all/20220719162339.23865-1-tariqt@nvidia.com) |
|
||||
| 2022/07/19 | Tariq Toukan <tariqt@nvidia.com> | [Introduce and use NUMA distance metrics](https://lore.kernel.org/all/20220719162339.23865-1-tariqt@nvidia.com) | NVIDIA 工程师一直在 Linux 内核中研究 NUMA 距离指标, 以取代某些驱动程序目前用于 NUMA 感知内存分配的简单本地/远程 NUMA 首选项接口. 在他们的测试中, 这种改进的 NUMA 距离处理对吞吐量和 CPU 利用率产生了"显著的性能影响". 根据调度程序的 sched_numa_find_closest() 实现并公开 CPU spread API sched_cpus_set_spread(). 在给定 NUMA 节点的情况下, 基于距离设置 CPU 分布替代基于 cpumask_local_spread() 的传统逻辑. 在 mlx5 和 enic 设备驱动程序中使用它. 这将使得 NUMA 首选项(本地/远程)替换为考虑实际距离的改进首选项, 因此短距离的远程 NUMA 优先于较远的 NUMA. | v3 ☐☑✓ | [LORE v3,0/3](https://lore.kernel.org/all/20220719162339.23865-1-tariqt@nvidia.com)<br>*-*-*-*-*-*-*-* <br>[2022/07/28 LORE v4,0/3](20220728191203.4055-1-tariqt@nvidia.com) |
|
||||
| 2022/08/17 | Valentin Schneider <vschneid@redhat.com> | [cpumask, sched/topology: NUMA-aware CPU spreading interface](https://lore.kernel.org/all/20220816180727.387807-1-vschneid@redhat.com) | TODO | v1 ☐☑✓ | [2022/08/16 LORE v1,0/5](https://lore.kernel.org/all/20220816180727.387807-1-vschneid@redhat.com)<br>*-*-*-*-*-*-*-* <br>[2022/08/17 LORE v2,0/5](https://lore.kernel.org/lkml/20220817175812.671843-1-vschneid@redhat.com) |
|
||||
|
||||
|
||||
## 4.2 负载均衡总概
|
||||
|
||||
Reference in New Issue
Block a user