diff --git a/study/kernel/00-DESCRIPTION/ARCH.md b/study/kernel/00-DESCRIPTION/ARCH.md index e515568..d00926b 100644 --- a/study/kernel/00-DESCRIPTION/ARCH.md +++ b/study/kernel/00-DESCRIPTION/ARCH.md @@ -222,7 +222,7 @@ ASYM_PACKING 用于平衡物理核心与 SMT 之间的负载均衡处理 (例如 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2021/09/10 | Ricardo Neri | [sched/fair: Fix load balancing of SMT siblings with ASYM_PACKING](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=4006a72bdd93b1ffedc2bd8646dee18c822a2c26) | 参见 [Fixing a corner case in asymmetric CPU packing](https://lwn.net/Articles/880367), 在使用非对称封装 (ASM_PACKING) 时, 可能存在具有三个优先级的 CPU 拓扑, 其中只有物理核心的子集支持 SMT. 这种架构下 ASM_PACKING 和 SMT 以及 load_balance 都存在冲突.
这种拓扑的一个实例是 Intel Alder Lake. 在 Alder Lake 上, 应该通过首先选择 Core(酷睿) cpu, 然后选择 Atoms, 最后再选择 Core 的 SMT 兄弟 cpu 来分散工作. 然而, 当前负载均衡器的行为与使用 ASYM_PACKING 时描述的不一致. 负载平衡器将选择高优先级的 CPU (Intel Core) 而不是中优先级的 CPU (Intel Atom), 然后将负载溢出到低优先级的 SMT 同级 CPU. 这使得中等优先级的 Atoms cpu 空闲, 而低优先级的 cpu sibling 繁忙.
1. 首先改善了 SMT 中 sibling cpu 优先级的计算方式, 它将比单个 core 优先级更低.
2. 当决定目标 CPU 是否可以从最繁忙的 CPU 提取任务时, 还检查执行负载平衡的 CPU 和最繁忙的候选组的 SMT 同级 CPU 的空闲状态. | v5 ☑ 5.16-rc1 | [PatchWork v1](https://lore.kernel.org/patchwork/cover/1408312)
*-*-*-*-*-*-*-*
[PatchWork v2](https://lore.kernel.org/patchwork/cover/1413015)
*-*-*-*-*-*-*-*
[PatchWork v3 0/6](https://lore.kernel.org/patchwork/cover/1428441)
*-*-*-*-*-*-*-*
[PatchWork v4,0/6](https://lore.kernel.org/patchwork/cover/1474500)
*-*-*-*-*-*-*-*
[LKML v5,0/6](https://lkml.org/lkml/2021/9/10/913), [LORE v5,0/6](https://lore.kernel.org/all/20210911011819.12184-1-ricardo.neri-calderon@linux.intel.com) | -| 2022/08/25 | Ricardo Neri | [sched/fair: Avoid unnecessary migrations within SMT domains](https://lore.kernel.org/all/20220825225529.26465-1-ricardo.neri-calderon@linux.intel.com) | TODO | v1 ☐☑✓ | [2022/08/25 LORE v1,0/4](https://lore.kernel.org/all/20220825225529.26465-1-ricardo.neri-calderon@linux.intel.com)
*-*-*-*-*-*-*-*
[2022/11/22 LORE v2,0/7](https://lore.kernel.org/lkml/20221122203532.15013-1-ricardo.neri-calderon@linux.intel.com)
*-*-*-*-*-*-*-*
[2023/02/07 LORE v3,0/10](https://lore.kernel.org/all/20230207045838.11243-1-ricardo.neri-calderon@linux.intel.com) | +| 2022/08/25 | Ricardo Neri | [sched/fair: Avoid unnecessary migrations within SMT domains](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=044f0e27dec6e30bb8875a4a12c5f2594964e93f) | 参见 phoronix 报道 [Linux 6.5 To Boast Improved Handling For Intel Hybrid CPUs With Hyper Threading](https://www.phoronix.com/news/Linux-6.4-Avoid-Unnecessary-SMT). | v1 ☐☑✓ | [2022/08/25 LORE v1,0/4](https://lore.kernel.org/all/20220825225529.26465-1-ricardo.neri-calderon@linux.intel.com)
*-*-*-*-*-*-*-*
[2022/11/22 LORE v2,0/7](https://lore.kernel.org/lkml/20221122203532.15013-1-ricardo.neri-calderon@linux.intel.com)
*-*-*-*-*-*-*-*
[2023/02/07 LORE v3,0/10](https://lore.kernel.org/all/20230207045838.11243-1-ricardo.neri-calderon@linux.intel.com) | #### 1.4.1.3 Intel Thread Director (ITD) @@ -403,6 +403,8 @@ SGX 旨在以硬件安全为强制性保障, 不依赖于固件和软件的安 | 2021/08/30 | Yu-cheng Yu | [Control-flow Enforcement: Shadow Stack](https://patchwork.kernel.org/project/linux-mm/cover/20210830181528.1569-1-yu-cheng.yu@intel.com) | 控制流执行(CET) 是英特尔处理器的一个新特性, 它可以阻止面向返回 / 跳转的编程攻击. 详情见 ["Intel 64 and IA-32 架构软件开发人员手册"](https://software.intel.com/content/www/us/en/develop/download/intel-64-and-ia-32-architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4.html). CET 可以保护应用程序和内核. 这是 CET 的第一部分, 本系列仅支持应用程序级保护, 并进一步分为阴影堆栈和间接分支跟踪. | v30 ☐ | [Patchwork v30,00/32](https://lore.kernel.org/linux-crypto/20210818033117.91717-1-tianjia.zhang@linux.alibaba.com) | | 2021/08/30 | Yu-cheng Yu | [Control-flow Enforcement: Indirect Branch Tracking](https://patchwork.kernel.org/project/linux-mm/cover/20210830182221.3535-1-yu-cheng.yu@intel.com) | 控制流执行(CET) 是英特尔处理器的一个新特性, 它可以阻止面向返回 / 跳转的编程攻击. 详情见 ["Intel 64 and IA-32 架构软件开发人员手册"](https://software.intel.com/content/www/us/en/develop/download/intel-64-and-ia-32-architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4.html). 这是 CET 的第二部分, 支持间接分支跟踪(IBT). 它是建立在阴影堆栈系列之上的. | v1 ☐ | [Patchwork v30,00/10](https://lore.kernel.org/linux-crypto/20210818033117.91717-1-tianjia.zhang@linux.alibaba.com) | | 2021/11/22 | Peter Zijlstra | [x86: Kernel IBT beginnings](https://lore.kernel.org/lkml/20211122170301.764232470@infradead.org) | IBT 的基础支持, 功能不完整, 但是够精简, 引入 CONFIG_X86_IBT 控制, 添加了 X86_IBT build 选项, 为编译器启用了 "-fcf-protection=branch" 支持, 并支持 objtool, 用于为可能的间接分支目标添加 ENDBR 指令以及内核入口点添加了 ENDBR 结束分支指令. | v11 ☐ | [Patchwork v11,0/7](https://lore.kernel.org/lkml/20211122170301.764232470@infradead.org) | +| 2023/05/11 | Yang Weijiang | [Enable CET Virtualization](https://lore.kernel.org/all/20230511040857.6094-1-weijiang.yang@intel.com) | [Intel Sends Out Latest Patches Preparing Linux CET Virtualization](https://www.phoronix.com/news/Intel-CET-Virtualization-v3) | v3 ☐☑✓ | [LORE v3,0/21](https://lore.kernel.org/all/20230511040857.6094-1-weijiang.yang@intel.com) | + ## 1.7 PPIN ------- @@ -956,6 +958,8 @@ https://blogs.vmware.com/vsphere/2021/10/introducing-project-capitola.html [Intel Has More CXL Improvements Ready For Linux 6.3](https://www.phoronix.com/news/Linux-6.3-CXL) +[Memory-management changes for CXL](https://lwn.net/Articles/931416) + ## 6.4 CPU IDLE(C-state) ------- diff --git a/study/kernel/00-DESCRIPTION/BPF.md b/study/kernel/00-DESCRIPTION/BPF.md index 9d90bcc..edc06d7 100644 --- a/study/kernel/00-DESCRIPTION/BPF.md +++ b/study/kernel/00-DESCRIPTION/BPF.md @@ -460,6 +460,7 @@ raw_tracepoint 相比 tracepoint | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:---:|:----:|:---:|:----:|:---------:|:----:| | 2015/10/14 | Wang Nan | [perf tools: filtering events using eBPF programs](https://lore.kernel.org/all/1444826502-49291-1-git-send-email-wangnan0@huawei.com) | TODO | v1 ☐☑✓ | [LORE v1,0/31](https://lore.kernel.org/all/1444826502-49291-1-git-send-email-wangnan0@huawei.com) | +| 2023/03/14 | Namhyung Kim | [perf record: Implement BPF sample filter (v5)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=c46bf3bd00167e09729f884dd479b0a8d1a63f95) | 社区有诉求基于 sample 数据进行更复杂的性能事件示例过滤. 最近内核增加了 BPF 程序可以访问性能样本数据, 这是用户空间部分启用这样的过滤.
perf record 具有 `--filter` 选项, 用于在命令行中对最后一个指定的事件设置筛选器. 到目前为止, 它只适用于跟踪点和英特尔 PT 事件. 这个补丁集将其扩展为使用 BPF, 以便为任何事件启用通用样本过滤器. 添加了一个新的过滤器表达式解析器(使用 flex/bison)来处理过滤器字符串. 当前它只接受用逗号分隔的非常简单的表达式. | v5 ☑✓ 6.4-rc1 | [LORE v5,0/10](https://lore.kernel.org/all/20230314234237.3008956-1-namhyung@kernel.org) | ## 8.3 coolbpf(surtrace & pyLCC) diff --git a/study/kernel/00-DESCRIPTION/DEBUGGING.md b/study/kernel/00-DESCRIPTION/DEBUGGING.md index feb5167..5590949 100644 --- a/study/kernel/00-DESCRIPTION/DEBUGGING.md +++ b/study/kernel/00-DESCRIPTION/DEBUGGING.md @@ -719,6 +719,15 @@ Intel 编译器随后也切到 LLVM 框架, 参见 [Intel Fully Embracing LLVM F | 2022/12/27 | Thomas Weißschuh | [reduce maximum memory usage](https://lore.kernel.org/all/20221216-objtool-memory-v2-0-17968f85a464@weissschuh.net) | 使用 objtool 处理 vmlinux.o 是内核构建中最占用内存的步骤. 通过减少最大内存使用量, 我们可以减少整个内核构建的最大内存使用.
因此, 在内核构建过程中, 内存不足的机器上的内存压力得到了缓解, 而且构建速度更快, 因为需要的交换更少. 参见 phoronix 报道 [New Patches Aim To Reduce Memory Use While Compiling The Linux Kernel](https://www.phoronix.com/news/Linux-Kernel-Build-Less-RAM). | v2 ☐☑✓ | [LORE v2,0/8](https://lore.kernel.org/all/20221216-objtool-memory-v2-0-17968f85a464@weissschuh.net) | +## 13.12 PIE +------- + + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:---:|:----:|:---:|:----:|:---------:|:----:| +| 2023/04/28 | Hou Wenlong | [x86/pie: Make kernel image's virtual address flexible](https://lore.kernel.org/all/cover.1682673542.git.houwenlong.hwl@antgroup.com) | 这些补丁允许 x86_64 上将内核构建为位置独立可执行文件(PIE). PIE 内核可以被重新定位在虚拟地址空间的顶部 2G 之下. 这个补丁集提供了一个例子, 允许内核映像在地址空间的顶部 512G 中重新定位. PIE 内核的最终目的是提高内核的安全性, 以及内核映像的虚拟地址的可扩展性, 甚至可以在地址空间的下半部分. 内核可以容纳更多的位置, 这意味着攻击者可以更难猜测. 参见 phoronix 报道 [New Patches Aim To Tackle Linux x86_64 PIE Support](https://www.phoronix.com/news/Linux-x86_64-PIE-2023). | v1 ☐☑✓ | [LORE v1,0/43](https://lore.kernel.org/all/cover.1682673542.git.houwenlong.hwl@antgroup.com) | + + # 14 FTRACE ------- @@ -907,7 +916,7 @@ Fedora 尝试优化 systemd 开机以及重启的时间, 参见 phoronix 报道 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| -| 2021/11/21 | David Woodhouse | [Parallel CPU bringup for x86_64](https://lkml.org/lkml/2021/12/9/664) | 随着核数的增多, 内核的启动速度越来越慢. 这组补丁能够并行启动辅助 (x86_64) CPU 内核. 对 v6 测hi发现可以显著改善 Sapphire Rapids CPU 系统的启动时间, 从 71s 降低到 14s. 随后 v7 增加了对 AMD CPU 的支持. | v1 ☐ | [LWN ](https://lwn.net/Articles/878161), [LKML](https://lkml.org/lkml/2021/12/9/664), [LORE 00/11](https://lkml.kernel.org/lkml/20211209150938.3518-1-dwmw2@infradead.org), [Phoronix 报道 v1](https://www.phoronix.com/news/Linux-x86_64-Parallel-CPU-Boot)
*-*-*-*-*-*-*-*
[LORE v3,0/9](https://lore.kernel.org/lkml/20211215145633.5238-1-dwmw2@infradead.org), [Phoronix 报道 v3](https://www.phoronix.com/news/Parallel-CPU-Bringup-AMD-Snag)
*-*-*-*-*-*-*-*
[LORE v6](https://lore.kernel.org/lkml/20230202215625.3248306-1-usama.arif@bytedance.com), [Phoronix 报道 v6](https://www.phoronix.com/news/Linux-CPU-Parallel-Bringup-2023)
*-*-*-*-*-*-*-*
[LORE v7](20230207230436.2690891-1-usama.arif@bytedance.com)
*-*-*-*-*-*-*-*
[LORE v17,0/8](https://lore.kernel.org/lkml/20230328195758.1049469-1-usama.arif@bytedance.com) | +| 2021/11/21 | David Woodhouse | [Parallel CPU bringup for x86_64](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=0c7ffa32dbd6b09a87fea4ad1de8b27145dfd9a6) | 随着核数的增多, 内核的启动速度越来越慢. 这组补丁能够并行启动辅助 (x86_64) CPU 内核. 对 v6 测hi发现可以显著改善 Sapphire Rapids CPU 系统的启动时间, 从 71s 降低到 14s. 随后 v7 增加了对 AMD CPU 的支持. 参见 [Parallel CPU Bring-Up Poised For Linux 6.5](https://www.phoronix.com/news/Parallel-CPU-Bringup-TIP-Linux). | v1 ☐ | [LWN ](https://lwn.net/Articles/878161), [LKML](https://lkml.org/lkml/2021/12/9/664), [LORE 00/11](https://lkml.kernel.org/lkml/20211209150938.3518-1-dwmw2@infradead.org), [Phoronix 报道 v1](https://www.phoronix.com/news/Linux-x86_64-Parallel-CPU-Boot)
*-*-*-*-*-*-*-*
[LORE v3,0/9](https://lore.kernel.org/lkml/20211215145633.5238-1-dwmw2@infradead.org), [Phoronix 报道 v3](https://www.phoronix.com/news/Parallel-CPU-Bringup-AMD-Snag)
*-*-*-*-*-*-*-*
[LORE v6](https://lore.kernel.org/lkml/20230202215625.3248306-1-usama.arif@bytedance.com), [Phoronix 报道 v6](https://www.phoronix.com/news/Linux-CPU-Parallel-Bringup-2023)
*-*-*-*-*-*-*-*
[LORE v7](20230207230436.2690891-1-usama.arif@bytedance.com)
*-*-*-*-*-*-*-*
[LORE v17,0/8](https://lore.kernel.org/lkml/20230328195758.1049469-1-usama.arif@bytedance.com) | | 2023/04/15 | Thomas Gleixner | [cpu/hotplug, x86: Reworked parallel CPU bringup](https://lore.kernel.org/all/20230414225551.858160935@linutronix.de) | [Reworked x86_64 Parallel Boot Support Posted For The Linux Kernel](https://www.phoronix.com/news/Linux-Parallel-Boot-x86-Rework) | v1 ☐☑✓ | [LORE v1,0/37](https://lore.kernel.org/all/20230414225551.858160935@linutronix.de) | diff --git a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md index 49b85d3..756eaec 100644 --- a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md +++ b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md @@ -1672,7 +1672,7 @@ https://lore.kernel.org/patchwork/patch/408914 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| -| 2023/04/01 | Vlastimil Babka | [mm: remove all the slab allocators](https://patchwork.kernel.org/project/linux-mm/patch/20230401094658.11146-1-vbabka@suse.cz) | 由于 SLOB 的拆除正在进行中, SLAB 的拆除也在计划中, 我意识到——为什么我们应该停止拆除 SLUB? 在 2023 年, 板坯分配器的作用是什么? [RAM 尺寸越来越大, 模块越来越便宜](https://www.theregister.com/2023/03/29/dram_prices_crash). 对象构造函数的技巧在 1994 年可能很有趣, 但对当代 CPU 来说却不是. 因此, slab 分配器现在所做的只是在页面分配器上添加一层不必要的复杂性. 因此, 这组补丁尝试删除所有三个 slab 分配器, 并且 slab.h 和 mm/slab_common.c 文件中只保留一个将所有内容传递给页面分配器的层. 这将允许用户逐渐转移并直接使用页面分配器. 总结优势:
1. 需要维护的代码更少: 这个补丁删除了超过 13k 行, 如果我在这方面花了更多的时间, 以及以后随着用户从遗留层过渡, 可以删除更多的代码.
2. 简化的 MEMCG_KMEM 记帐: 虽然我很懒, 只是在这个补丁中将其标记为 BROKEN, 但既然我们使用了页面分配器, 那么使用页面 MEMCG 记帐应该是微不足道的. 每个对象的核算在过去经历了几次迭代, 而且总是很复杂, 增加了开销. 相比之下, 页面会计要简单得多.
3. 简化了 KASAN 和朋友: 在这个补丁中也很懒, 所以不能启用它们, 但应该很容易修复, 只在页面级别工作.
4. 更简单的调试: 只需使用 debug_pagealloc=on, 无需查找复杂得离谱的 slub_debug 参数的确切语法.
5. 速度: 没有测量, 但对于页面分配器, 我们有 pcplist, 所以它应该可以很好地扩展. 不需要疯狂的 SLUB 的 cmpxchg_double()疯狂. 也许那个东西现在也可以移除. | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20230401094658.11146-1-vbabka@suse.cz) | +| 2023/04/01 | Vlastimil Babka | [mm: remove all the slab allocators](https://patchwork.kernel.org/project/linux-mm/patch/20230401094658.11146-1-vbabka@suse.cz) | 由于 SLOB 的拆除正在进行中, SLAB 的拆除也在计划中, 我意识到——为什么我们应该停止拆除 SLUB? 在 2023 年, 板坯分配器的作用是什么? [RAM 尺寸越来越大, 模块越来越便宜](https://www.theregister.com/2023/03/29/dram_prices_crash). 对象构造函数的技巧在 1994 年可能很有趣, 但对当代 CPU 来说却不是. 因此, slab 分配器现在所做的只是在页面分配器上添加一层不必要的复杂性. 因此, 这组补丁尝试删除所有三个 slab 分配器, 并且 slab.h 和 mm/slab_common.c 文件中只保留一个将所有内容传递给页面分配器的层. 这将允许用户逐渐转移并直接使用页面分配器. 总结优势:
1. 需要维护的代码更少: 这个补丁删除了超过 13k 行, 如果我在这方面花了更多的时间, 以及以后随着用户从遗留层过渡, 可以删除更多的代码.
2. 简化的 MEMCG_KMEM 记帐: 虽然我很懒, 只是在这个补丁中将其标记为 BROKEN, 但既然我们使用了页面分配器, 那么使用页面 MEMCG 记帐应该是微不足道的. 每个对象的核算在过去经历了几次迭代, 而且总是很复杂, 增加了开销. 相比之下, 页面会计要简单得多.
3. 简化了 KASAN 和朋友: 在这个补丁中也很懒, 所以不能启用它们, 但应该很容易修复, 只在页面级别工作.
4. 更简单的调试: 只需使用 debug_pagealloc=on, 无需查找复杂得离谱的 slub_debug 参数的确切语法.
5. 速度: 没有测量, 但对于页面分配器, 我们有 pcplist, 所以它应该可以很好地扩展. 不需要疯狂的 SLUB 的 cmpxchg_double()疯狂. 也许那个东西现在也可以移除. 参见 phoronix 报道 [Linux's SLAB Allocator Next On Deck For Deprecation & Removal](https://www.phoronix.com/news/Linux-Deprecating-Removing-SLAB)| v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20230401094658.11146-1-vbabka@suse.cz) | ### 2.3.1 SLAB @@ -2451,7 +2451,8 @@ v3.6 [commit 7db8889ab05b ("mm: have order> 0 compaction start off where it left | 2008/08/11 | Christoph Lameter | [Slab Fragmentation Reduction V14](https://lore.kernel.org/patchwork/patch/125818) | SLAB 抗碎片化 | v14 ☐ | [PatchWork v5](https://lore.kernel.org/patchwork/patch/90742)
*-*-*-*-*-*-*-*
[PatchWork v14](https://lore.kernel.org/patchwork/patch/125818) | | 2017/03/07 | Vlastimil Babka | [try to reduce fragmenting fallbacks](https://lore.kernel.org/patchwork/patch/766804) | 修复 [Regression in mobility grouping?](https://lkml.org/lkml/2016/9/28/94) 上报的碎片化问题, 通过修改 fallback 机制和 compaction 机制来减少永久随便化的可能性. 其中 fallback 修改时, 仅尝试从不同 migratetype 的 pageblock 中窃取的页面中挑选最小 (但足够) 的页面. | v3 ☑ [4.12-rc1](https://kernelnewbies.org/Linux_4.12#Memory_management) | [PatchWork v6](https://lore.kernel.org/patchwork/patch/766804), [KernelNewbies](https://kernelnewbies.org/Linux_4.12#Memory_management), [关键 commit 3bc48f96cf11 ("mm, page_alloc: split least stolen page in fallback")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3bc48f96cf11ce8699e419d5e47ae0d456403274) | | 2018/11/23 | Mel Gorman | [Fragmentation avoidance improvements v5](https://lore.kernel.org/patchwork/patch/1016503) | 伙伴系统页面分配时的反碎片化 | v5 ☑ 5.0-rc1 | [PatchWork v5](https://lore.kernel.org/patchwork/patch/1016503) | -| 2022/01/27 | Mike Rapoport | [Prototype for direct map awareness in page allocator](https://lore.kernel.org/all/20220127085608.306306-1-rppt@kernel.org) | [LSFMM-2022/Solutions for direct-map fragmentation](https://lwn.net/Articles/894557) | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20220127085608.306306-1-rppt@kernel.org) | +| 2022/01/27 | Mike Rapoport | [Prototype for direct map awareness in page allocator](https://lore.kernel.org/all/20220127085608.306306-1-rppt@kernel.org) | [LSFMM-2022/Solutions for direct-map fragmentation](https://lwn.net/Articles/894557), [Solutions for direct-map fragmentation](https://lwn.net/Articles/894557), [Reconsidering the direct-map fragmentation problem](https://lwn.net/Articles/931406) + | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20220127085608.306306-1-rppt@kernel.org) | # 4 页面回收 @@ -4117,6 +4118,15 @@ PowerPC 体系结构 (POWER10) 支持热/冷页面跟踪功能(Hot/Cold page tra 3. 页面提升. +### 4.4.6 Working Set Reporting +------ + + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:----:|:---------:|:----:| +| 2023/05/10 | Yuanchu Xie | [mm: Working Set Reporting](https://lore.kernel.org/all/20230509185419.1088297-1-yuanchu@google.com) | balloon device 是在来宾虚拟机和主机之间共享内存的典型机制. 开发这种 [auto-ballon 能力](https://www.linux-kvm.org/page/Projects/auto-ballooning)的早期项目于 2013 年完成. 最近, 已经创建了额外的VIRTIO设备(VIRTIO -mem、VIRTIO -pmem), 为许多用例提供了[更多的工具](https://kvmforum2020.sched.com/event/eE4U/virtio-balloonpmemmem-managing-guest-memory-david-hildenbrand-michael-s-tsirkin-red-hat), 每种工具都有优点和缺点，它在多虚拟机场景中特别有用, 在这种场景中, 内存被过度使用, 并且随着系统上工作负载的变化, 需要动态更改虚拟机内存大小. balloon device 现在有许多特性来帮助在来宾和主机之间明智地共享内存资源 (例如, 免费页面提示、统计、免费页面报告). 对于在多虚拟机环境中负责优化内存资源的主控制器程序, 它必须使用这些工具来回答两个具体问题: 统一的工作集报告结构, 适用于服务器和客户端. 它涉及主机上的每个节点直方图、每个内存直方图和虚拟气球驱动程序扩展.
有两种使用工作集报告的方法: 事件驱动和查询. 主机控制器可以接收来自 reclaim 的通知, 它会生成一个报告, 或者控制器可以直接查询直方图.
1. 补丁 1 引入了工作集报告机制和主机接口. 补丁 2 扩展了带有工作集报告的虚拟 balloon 驱动程序.
最初的 RFC 以 MGLRU 为基础, 旨在作为讨论和改进的概念验证. tj 和作者的目标是支持活动 / 非活动 LRU 和来自用户空间的工作集估计. 作者正在编写演示脚本并获得一些数据. | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20230509185419.1088297-1-yuanchu@google.com) | + + # 5 Swappiness ------- diff --git a/study/kernel/00-DESCRIPTION/SCHEDULER.md b/study/kernel/00-DESCRIPTION/SCHEDULER.md index eaf5f9f..829507c 100644 --- a/study/kernel/00-DESCRIPTION/SCHEDULER.md +++ b/study/kernel/00-DESCRIPTION/SCHEDULER.md @@ -1262,7 +1262,7 @@ enqueue_task() | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:---:|:----:|:---:|:----:|:---------:|:----:| | 2022/07/13 | Chengming Zhou | [sched: task load tracking optimization and cleanup](https://lore.kernel.org/all/20220713040430.25778-1-zhouchengming@bytedance.com) | TODO | v2 ☐☑✓ | [LORE v1,0/8](https://lore.kernel.org/lkml/20220709151353.32883-1-zhouchengming@bytedance.com)
*-*-*-*-*-*-*-*
[LORE v2,0/10](https://lore.kernel.org/all/20220713040430.25778-1-zhouchengming@bytedance.com) | -| 2023/03/27 | Aaron Lu | [sched/fair: Make tg->load_avg per node](https://lore.kernel.org/all/20230327053955.GA570404@ziqianlu-desk2) | 使用 sysbench 在一个 docker 实例中对 Postgres 进行基准测试, 并将 sysbench 的 nr_threads 设置为 nr_cpu 时, 可以观察到 update_cfs_group() 和 update_load_avg() 在一个 2sockets/112core/224cpu 的 Intel Sapphire Rapids 节点上显示了明显的 cpu 开销(10% 和 7.8%), 而在另一个节点的 cpu 的热点通常较低(4% 和 3%). 分析发现热点主要是访问 tg->load_avg, 其中 update_load_avg() 是写端, update_cfs_group() 是读端.
为什么只有一个节点的 CPU 有更大的开销, 原因是: task_group 是根据需要从 slab 分配的, 无论哪个 CPU 进行分配, 分配的 tg 将位于该节点上, 访问 tg->load_avg 将对同一节点上的 CPU 有更低的成本, 而对远程节点的 CPU 有更高的成本.
Tim Chen 告诉我, PeterZ 曾经提到过一种解决类似问题的方法, 即为每个节点设置一个计数器, 所以对 tg->load_avg 也做同样的事情.
优化后, 这两个节点上运行 5 分钟所看到的最坏的情况占比也才 2%.
针对这个工作负载有另外一个发现: 这个工作负载存在有很多唤醒时的任务迁移, 这就是为什么 update_load_avg() 和 update_cfs_group() 显示出明显的成本. 在 N 个实例中运行这个工作负载, 其中 N >= 2, sysbench 的 nr_threads 设置为 1/N nr_cpu, 在唤醒时间上的任务迁移大大减少, 上面提到的两个函数的开销也下降了很多. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20230327053955.GA570404@ziqianlu-desk2) | + # 4 基于调度域的负载均衡 @@ -2206,7 +2206,7 @@ v3.3 [commit 0b005cf54eac ("sched, nohz: Implement sched group, domain aware noh | 2019/01/17 | Valentin Schneider | [sched/fair: NOHZ cleanups and misfit improvement](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=b9a7b8831600afc51c9ba52c05f12db2266f01c7) | 降低 ARM big.LITTLE 平台 NOHZ 下不必要的 kick 操作. | v1 ☑✓ 5.1-rc2 | [LORE v1,0/5](https://lore.kernel.org/all/20190117153411.2390-1-valentin.schneider@arm.com)
*-*-*-*-*-*-*-*
[LORE v2,0/3](https://lore.kernel.org/lkml/20190211175946.4961-1-valentin.schneider@arm.com) | -### 4.5.6 Blocked Load Update for NO_HZ +### 4.5.6 Blocked Load Update for NO_HZ ------- #### 4.5.6.1 Update Blocked Load When NEWLY_IDLE @4.17 @@ -2424,7 +2424,7 @@ void nohz_run_idle_balance(int cpu) | 2014/1/28 | Mike Galbraith | [sched, nohz: Exclude isolated cores from load balancing](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d987fc7f3228) | isolated CPU 不再进行负载均衡. | v1 ☑ 3.15-rc1 | [LKML](https://lkml.org/lkml/2014/2/21/736) | -### 4.5.7 NO_HZ Idle Balancing 的其他更新 +### 4.5.7 NO_HZ Idle Balancing 的其他更新 ------- @@ -2587,6 +2587,7 @@ commit [6e5fb223e89d ("mm: sched: numa: Implement constant, per task Working Set |:----:|:----:|:---:|:---:|:----------:|:----:| | 2022/01/28 | Bharata B Rao | [sched/numa: Process Adaptive autoNUMA](https://lore.kernel.org/lkml/20220128052851.17162-1-bharata@amd.com) | 实现了一种进程自适应 autoNUMA 算法 (Process Adaptive autoNUMA, PAN). 在每个进程级别上收集 NUMA 故障统计信息, 以更好地捕获应用程序行为, 计算 autoNUMA 扫描周期.
在现有的扫描周期计算机制中: 1. 扫描周期是从每线程的统计数据中派生出来的. 2. 静态阈值(NUMA_PERIOD_threshold) 用于更改扫描速率.
这组补丁集将 NUMA fault 按照不同的维护划分, 如本地的与远程的 (local vs. remote), 私有的和共享的(private vs. shared). 然后在每个进程级别收集 numa faults 统计数据, 从而更好地捕获应用程序行为. 不再使用静态阈值, 而是根据远程故障率来学习和调整扫描速率, 可以更好地响应不同的工作负载行为. 由于进程的线程已经被视为一个 numa_group, 因此我们在任务的[内存管理] 中添加了一组度量标准, 以跟踪各种类型的错误并从中推导出扫描速度. 新的每进程故障统计数据只对每进程扫描周期计算有贡献, 而现有的每线程统计数据继续对 numa_group 统计数据有贡献, 后者最终确定跨节点迁移内存和线程的阈值. 参见 phoronix 的报道 [AMD Cooking Up A"PAN"Feature That Can Help Boost Linux Performance](https://www.phoronix.com/scan.php?page=news_item&px=AMD-PAN-Linux-RFC) | v0 ☐ | [LKML v0,0/5](https://lkml.org/lkml/2022/1/28/16), [LORE](https://lore.kernel.org/lkml/20220128052851.17162-1-bharata@amd.com) | | 2023/01/16 | Raghavendra K T | [sched/numa: Enhance vma scanning](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=d46031f40e0f7f7bf63914bb3f2e404ad3886ecd) | 借助了 Mel 的建议核想法, 不同于 Process Adaptive autoNUMA. 本补丁集
1. 最多跟踪 4 个最近访问 vma 的线程, 只扫描访问 vma 的线程. (注意: 只使用 unsigned int. 实验表明, 追踪 8 种不同的 pid 开销更大)
2. 前 2 次无条件允许线程扫描 vmas, 以保持扫描的初衷.
3. 如果有超过 4 个线程(即超过我们可以记住的 pid), 默认允许扫描, 因为我们可能会错过记录当前线程是否对 vma 有任何兴趣.
通过这个补丁集, 可以看到扫描开销(AutoNuma 开销) 大幅减少, 其中一些 enchmark 提高了性能, 而其他的几乎没有倒退. 参见 [知乎 - sched/numa: Enhance vma scanning](https://zhuanlan.zhihu.com/p/614407036) | v1 ☐☑✓ | [LORE v1,0/1](https://lore.kernel.org/all/cover.1673610485.git.raghavendra.kt@amd.com)
*-*-*-*-*-*-*-*
[LORE v2,0/3](https://lore.kernel.org/all/cover.1675159422.git.raghavendra.kt@amd.com)
*-*-*-*-*-*-*-*
[LORE v3,0/4](https://lore.kernel.org/all/cover.1677557481.git.raghavendra.kt@amd.com)
*-*-*-*-*-*-*-*
[LORE v3,0/4](https://lore.kernel.org/all/cover.1677672277.git.raghavendra.kt@amd.com) | +| 2023/05/03 | Raghavendra K T | [sched/numa: Disjoint set vma scan improvements](https://lore.kernel.org/all/cover.1683033105.git.raghavendra.kt@amd.com) | TODO | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/cover.1683033105.git.raghavendra.kt@amd.com) | ### 4.6.4 NUMA Balancing Placement And Migration @@ -3356,7 +3357,6 @@ v3.0 版本 [sched: Reduce runqueue lock contention -v6](https://git.kernel.org/ | 2015/08/03 | tip-bot for Peter Zijlstra | [sched: Introduce the'trace_sched_waking'tracepoint](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fbd705a0c6184580d0e2fbcbd47a37b6e5822511) | NA | v1 ☑✓ 4.3-rc1 | [LORE](https://lore.kernel.org/all/tip-fbd705a0c6184580d0e2fbcbd47a37b6e5822511@git.kernel.org/) | | 2020/05/24 | Mel Gorman | [Optimise try_to_wake_up() when wakee is descheduling](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=2ebb17717550607bcd85fb8cf7d24ac870e9d762) | 唤醒时如果 wakee 进程正在睡眠或者调度(释放 CPU), 优化在 on_cpu 的自旋等待时间 | v1 ☑ 5.8-rc1 | [LORE 0/2](https://lore.kernel.org/lkml/20200524202956.27665-1-mgorman@techsingularity.net) | | 2022/08/24 | Peng Wang | [sched/fair: select waker's cpu for wakee on sync wakeup](https://lore.kernel.org/all/1508aa17d1a169077c8d8d8c22d2bd529101af0e.1661313074.git.rocking@linux.alibaba.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/1508aa17d1a169077c8d8d8c22d2bd529101af0e.1661313074.git.rocking@linux.alibaba.com) | -| 2023/02/03 | Chen Yu | | v7 之前 title [sched/fair: Wake short task on current CPU](https://lore.kernel.org/all/cover.1675361144.git.yu.c.chen@intel.com), 其主要目的是避免在不必要时出现过多的跨 CPU 唤醒. 频繁的跨 CPU 唤醒会对某些工作负载造成严重损害, 尤其是在高核心数系统上. 如果唤醒和唤醒都是短时任务, 则通过将唤醒置于唤醒 CPU 上来禁止跨 CPU 唤醒. 短时间的任务可能会成为高负载系统的麻烦制造者, 因为它会带来频繁的上下文切换. 因此, 此策略仅在系统繁忙时生效. 此外, 当仍有空闲 CPU 时, 禁止空闲 CPU 扫描是不合理的. 首先利用第一个补丁 [sched/fair: Record the average duration of a task](https://lore.kernel.org/all/155aa36ba14b8a1f8e6c3ccda7999125edfff990.1675361144.git.yu.c.chen@intel.com) 跟踪任务的平均运行时间 dur_avg, 从而更好地定义小任务. 然后选择本地 CPU 进行唤醒. 测试发现, Intel 2 x 56C/112T 平台的性能有了显著提高. 例如, 在某些情况下, 它将缩放(1200+%), netperf(600+%). 商业 RDBMS 对 schbench、hacksbench、tbench 和 OLTP 工作负载没有明显影响. 参见 phoronix 报道 [Linux Performance Patches Revved To Avoid Too Many Unnecessary Cross-CPU Wake-ups](https://www.phoronix.com/news/Linux-Wake-Short-Task-CPU). | v5 ☐☑✓ | [LORE](https://lore.kernel.org/all/20220915165407.1776363-1-yu.c.chen@intel.com)
*-*-*-*-*-*-*-*
[LORE v2,0/2](https://lore.kernel.org/all/cover.1666531576.git.yu.c.chen@intel.com)
*-*-*-*-*-*-*-*
[LORE v5,0/2](https://lore.kernel.org/all/cover.1675361144.git.yu.c.chen@intel.com)
*-*-*-*-*-*-*-*
[LORE v6,0/2](https://lore.kernel.org/all/cover.1677069490.git.yu.c.chen@intel.com)
*-*-*-*-*-*-*-*
[LORE v7,0/2](https://lore.kernel.org/all/cover.1682060436.git.yu.c.chen@intel.com)
*-*-*-*-*-*-*-*
[LORE v8,0/2](https://lore.kernel.org/all/cover.1682661027.git.yu.c.chen@intel.com) | ### 4.7.1.1 TTWU 中的内存屏障 @@ -3674,6 +3674,32 @@ Mike Galbraith 调试发现, 触发这个问题的原因是因为 wake_affine_we | 慢路径 find_idlest_cpu() | 通过搜索 SD_BALANCE_FORK 或 SD_BALANCE_EXEC 标记的最高 sched_domain 来唤醒处于最空闲状态的空闲 CPU 上的任务. | +### 4.7.4 Cache-to-Cache Latency +------- + +多核系统运行大量频繁的上下文切换工作负载, 由于 Cache-to-Cache latency 而导致性能下降. + + +| 测试场景 | 现象 | 分析 | +|:-------:|:---:|:---:| +| 场景1 | Chen Yu 发现 will-it-scale context_switch1 用例 update_cfs_group() 和 update_load_avg() 的热点极高. 如果 waker 和 wakee 是彼此的亲和性较强, 那么将它们放在同一 SMT 域中可以减少 C2C 开销. perf c2c 结果表明, 在读取器 update_cfs_group() 和写入器 update_load_avg() 之间, HITM 事件的 c2c 开销的平均成本很高. | 两者都竞争相同的缓存行 tg->load_avg. +| 场景2 、 如果在唤醒期间有太多的跨核任务迁移, 问题会变得更加严重. Aaron Lu[ 使用 sysbench 在一个 docker 实例中对 Postgres 进行基准测试, 并将 sysbench 的 nr_threads 设置为 nr_cpu 时, 可以观察到 update_cfs_group() 和 update_load_avg() 在一个 2sockets/112core/224cpu 的 Intel Sapphire Rapids 节点上显示了明显的 cpu 开销(10% 和 7.8%), 而在另一个节点的 cpu 的热点通常较低(4% 和 3%). | 竞争时访问 tg->load_avg, 其中 update_load_avg() 是写端, update_cfs_group() 是读端. Aaron Lu 的测试为什么只有一个节点的 CPU 有更大的开销, 原因是: task_group 是根据需要从 slab 分配的, 无论哪个 CPU 进行分配, 分配的 tg 将位于该节点上, 访问 tg->load_avg 将对同一节点上的 CPU 有更低的成本, 而对远程节点的 CPU 有更高的成本. | + +PeterZ 曾经提到过一种解决类似问题的方法, 即为每个节点设置一个计数器, 所以对 tg->load_avg 也做同样的事情. 优化后, 这两个节点上运行 5 分钟所看到的最坏的情况占比也才 2%. 对这个工作负载有另外一个发现: 这个工作负载存在有很多唤醒时的任务迁移, 这就是为什么 update_load_avg() 和 update_cfs_group() 显示出明显的成本. 在 N 个实例中运行这个工作负载, 其中 N >= 2, sysbench 的 nr_threads 设置为 1/N nr_cpu, 在唤醒时间上的任务迁移大大减少, 上面提到的两个函数的开销也下降了很多. 参见 [sched/fair: Make tg->load_avg per node](https://lore.kernel.org/all/20230327053955.GA570404@ziqianlu-desk2). + +Chen Yu 开始提出了一种 SIS_CURRENT 的方式, 它唤醒了当前 CPU 上的短任务到 local CPU. 参见 [sched/fair: Introduce SIS_CURRENT to wake up short task on current CPU](https://lore.kernel.org/lkml/cover.1682661027.git.yu.c.chen@intel.com). Mike Galbraith 帮 Chen Yu 测试了 SIS_CURRENT, 虽然 SIS_CURRENT 在高端平台上带来了改进, 但它可能会增加任务堆积的风险, 并损害低端系统的延迟. 这种系统的 CPU 数量较少, C2C 的减少并不能抵消这种平台上对延迟的伤害. Mike 建议选择一个空闲的共享 L2 来缓解 C2C. Tim 和 Len 也建议可以借助 Cluster Scheduling 来缓解 C2C. + +Chen Yu 新的思路是, 首先在 SMT 域中扫描一个空闲的同级节点. 在之前的上下文切换周期中, 如果唤醒器和唤醒器相互唤醒, 则它们可能共享资源, 并且可以将唤醒器放在唤醒器旁边的空闲兄弟节点上, 以避免 C2C 开销. 但是, 在当前代码中, SMT 域没有 SD_CLUSTER 标志, 因此目前不能重用上述补丁. 目前的补丁只处理 SMT 域, 但由于 C2C 主要是关于共享 L2 的内核之间的缓存同步, 基于集群的唤醒也可以增强到包括 SMT 域. SMT 空闲同级应该优先于唤醒前一个 CPU, 因为后者仍有 C2C 开销的风险. 参见 [sched/fair: Introduce SIS_PAIR to wakeup task on local idle core first](https://lore.kernel.org/all/20230516011159.4552-1-yu.c.chen@intel.com). + + + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:---:|:----:|:---:|:----:|:---------:|:----:| +| 2023/02/03 | Chen Yu | [sched/fair: Introduce SIS_CURRENT to wake up short task on current CPU](https://lore.kernel.org/lkml/cover.1682661027.git.yu.c.chen@intel.com) | v7 之前 title [sched/fair: Wake short task on current CPU](https://lore.kernel.org/all/cover.1675361144.git.yu.c.chen@intel.com), 其主要目的是避免在不必要时出现过多的跨 CPU 唤醒. 频繁的跨 CPU 唤醒会对某些工作负载造成严重损害, 尤其是在高核心数系统上. 如果唤醒和唤醒都是短时任务, 则通过将唤醒置于唤醒 CPU 上来禁止跨 CPU 唤醒. 短时间的任务可能会成为高负载系统的麻烦制造者, 因为它会带来频繁的上下文切换. 因此, 此策略仅在系统繁忙时生效. 此外, 当仍有空闲 CPU 时, 禁止空闲 CPU 扫描是不合理的. 首先利用第一个补丁 [sched/fair: Record the average duration of a task](https://lore.kernel.org/all/155aa36ba14b8a1f8e6c3ccda7999125edfff990.1675361144.git.yu.c.chen@intel.com) 跟踪任务的平均运行时间 dur_avg, 从而更好地定义小任务. 然后选择本地 CPU 进行唤醒. 测试发现, Intel 2 x 56C/112T 平台的性能有了显著提高. 例如, 在某些情况下, 它将缩放(1200+%), netperf(600+%). 商业 RDBMS 对 schbench、hacksbench、tbench 和 OLTP 工作负载没有明显影响. 参见 phoronix 报道 [Linux Performance Patches Revved To Avoid Too Many Unnecessary Cross-CPU Wake-ups](https://www.phoronix.com/news/Linux-Wake-Short-Task-CPU). | v5 ☐☑✓ | [LORE](https://lore.kernel.org/all/20220915165407.1776363-1-yu.c.chen@intel.com)
*-*-*-*-*-*-*-*
[LORE v2,0/2](https://lore.kernel.org/all/cover.1666531576.git.yu.c.chen@intel.com)
*-*-*-*-*-*-*-*
[LORE v5,0/2](https://lore.kernel.org/all/cover.1675361144.git.yu.c.chen@intel.com)
*-*-*-*-*-*-*-*
[LORE v6,0/2](https://lore.kernel.org/all/cover.1677069490.git.yu.c.chen@intel.com)
*-*-*-*-*-*-*-*
[LORE v7,0/2](https://lore.kernel.org/all/cover.1682060436.git.yu.c.chen@intel.com)
*-*-*-*-*-*-*-*
[LORE v8,0/2](https://lore.kernel.org/all/cover.1682661027.git.yu.c.chen@intel.com) | +| 2023/03/27 | Aaron Lu | [sched/fair: Make tg->load_avg per node](https://lore.kernel.org/all/20230327053955.GA570404@ziqianlu-desk2) | 使用 sysbench 在一个 docker 实例中对 Postgres 进行基准测试, 并将 sysbench 的 nr_threads 设置为 nr_cpu 时, 可以观察到 update_cfs_group() 和 update_load_avg() 在一个 2sockets/112core/224cpu 的 Intel Sapphire Rapids 节点上显示了明显的 cpu 开销(10% 和 7.8%), 而在另一个节点的 cpu 的热点通常较低(4% 和 3%). 分析发现热点主要是访问 tg->load_avg, 其中 update_load_avg() 是写端, update_cfs_group() 是读端.
为什么只有一个节点的 CPU 有更大的开销, 原因是: task_group 是根据需要从 slab 分配的, 无论哪个 CPU 进行分配, 分配的 tg 将位于该节点上, 访问 tg->load_avg 将对同一节点上的 CPU 有更低的成本, 而对远程节点的 CPU 有更高的成本.
Tim Chen 告诉我, PeterZ 曾经提到过一种解决类似问题的方法, 即为每个节点设置一个计数器, 所以对 tg->load_avg 也做同样的事情.
优化后, 这两个节点上运行 5 分钟所看到的最坏的情况占比也才 2%.
针对这个工作负载有另外一个发现: 这个工作负载存在有很多唤醒时的任务迁移, 这就是为什么 update_load_avg() 和 update_cfs_group() 显示出明显的成本. 在 N 个实例中运行这个工作负载, 其中 N >= 2, sysbench 的 nr_threads 设置为 1/N nr_cpu, 在唤醒时间上的任务迁移大大减少, 上面提到的两个函数的开销也下降了很多. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20230327053955.GA570404@ziqianlu-desk2) | +| 2023/05/16 | Chen Yu | [sched/fair: Introduce SIS_PAIR to wakeup task on local idle core first](https://lore.kernel.org/all/20230516011159.4552-1-yu.c.chen@intel.com) | 在 SMT 域中扫描一个空闲的同级节点. 在之前的上下文切换周期中, 如果唤醒器和唤醒器相互唤醒, 则它们可能共享资源, 并且可以将唤醒器放在唤醒器旁边的空闲兄弟节点上, 以避免 C2C 开销. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20230516011159.4552-1-yu.c.chen@intel.com) | + + ### 4.7.5 sync wakeup ------- @@ -3976,6 +4002,7 @@ y = (1 - \frac{pct^{2}}{10000^{2}} \times x^{2}) \times llc\_weight | 2021/12/03 | Tim Chen | [Make Cluster Scheduling Configurable](https://lkml.org/lkml/2021/12/3/891) | Cluster Scheduling 并不适用于所有场景, 因此这组补丁支持了在运行时和引导时可以动态配置 Cluster Scheduling. 可以通过启动参数 `sched_cluster={1|0}` 来在启动时开启和关闭, 也可以通过 `/proc/sys/kernel/sched_cluster` 接口在运行时动态开启和关闭.
当系统负载适中时, 值得做额外的负载平衡来平衡 cluster 之间的负载, 以减少 cluster 内资源的争用. 但是如果系统负载较大, 各个资源已经得到充分利用, cluster 之间的负载平衡不太可能有助于减少 cluster 的资源争用, 因为 cluster 内已经完全繁忙.
同时由于不感知性能异构的 CPU 类型, 造成了 Intel Alder Lake CPU 上性能退化, 参见 [Linux 5.16's New Cluster Scheduling Is Causing Regression, Further Hurting Alder Lake](https://www.phoronix.com/scan.php?page=article&item=linux-516-regress&num=3). 因此在 x86 hybrid 类型的 CPU 上禁用 Cluster Scheduling.
在一个有 24 个 Atom 内核的 Jacobsville 系统上 (每个 cluster 有 4 个 Atom CPU 核共享一个 L2), 在 24 个 CPU 的系统上运行 mcf 基准测试, 从非常低的负载 1 个基准测试副本到 24 个基准测试副本. 我们看到, 在中等负载时吞吐量得到了提高, 但当系统满负载时, Cluster Scheduling 几乎没有什么提升.
不过 Peter 最终直接选择在 x86 hybrid CPUs 上禁用 cluster. 参见 commit [cabdc3a8475b ("sched,x86: Don't use cluster topology for x86 hybrid CPUs")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cabdc3a8475b918e55744f43719b26a82dc8fa6b). | v1 ☐ | [LORE 0/5](https://lkml.kernel.org/lkml/cover.1638563225.git.tim.c.chen@linux.intel.com), [Peter Zijlstra COMMIT](https://lore.kernel.org/all/163899885798.11128.4032422680527135079.tip-bot2@tip-bot2) | | 2022/01/26 | Yicong Yang | [sched/fair: Scan cluster before scanning LLC in wake-up path](https://lore.kernel.org/all/20220822073610.27205-1-yangyicong@huawei.com) | v5 之前叫 [sched/fair: Wake task within the cluster when possible](https://lore.kernel.org/all/20220126080947.4529-1-yangyicong@hisilicon.com). 这个补丁集负责唤醒路径的 cluster 感知, 在扫描整个 LLC 之前, 先在同一集群中其他的 CPU 尝试一下, 以使这些任务能够相互通信.
1. 引入 SD_CLUSTER 标记 cluster 域, 使用 per_cpu(sd_cluster, cpu) 和 per_cpu(sd_share_id, cpu) 标记 CPU 所属的 cluster 及其 ID
2. 接着 select_idle_cpu() 试图在扫描整个 LLC 之前先通过 scan_cluster() 找到目标 CPU cluster 域 per_cpu(sd_cluster, target) 内空闲的 CPU, 以获得更低的延迟. | v2 ☐☑✓ | [LORE 0/2](https://lore.kernel.org/lkml/20211215041149.73171-1-yangyicong@hisilicon.com)
*-*-*-*-*-*-*-*
[LORE v2,0/2](https://lore.kernel.org/all/20220126080947.4529-1-yangyicong@hisilicon.com)
*-*-*-*-*-*-*-*
[LORE v3,0/2](https://lore.kernel.org/lkml/20220608095758.60504-1-yangyicong@hisilicon.com)
*-*-*-*-*-*-*-*
[LORE v4,0/2](https://lore.kernel.org/lkml/20220609120622.47724-1-yangyicong@hisilicon.com)
*-*-*-*-*-*-*-*
[LORE v5,0/2](https://lore.kernel.org/lkml/20220720081150.22167-1-yangyicong@hisilicon.com)
*-*-*-*-*-*-*-*
[LORE v6,0/2](https://lore.kernel.org/lkml/20220726074758.46686-1-yangyicong@huawei.com)
*-*-*-*-*-*-*-*
[LORE v7,0/2](https://lore.kernel.org/all/20220822073610.27205-1-yangyicong@huawei.com) | | 2023/04/10 | K Prateek Nayak | [arch/x86: Set L2 Cache ID on AMD processors](https://lore.kernel.org/all/20230410163527.1626-1-kprateek.nayak@amd.com) | 将 Cluster Scheduler 扩展到 AMD 处理器上. 将 "l2c_id" 与拓扑扩展 "TOPOEXT" 特性连接起来, 用于在 AMD 处理器上设置, 以便共享相同 L2 缓存的线程集可以正确地映射到相同的集群 ID. 参见 phoronix 报道 [Linux Cluster-Aware Scheduling Being Extended To AMD Processors](https://www.phoronix.com/news/AMD-Linux-L2-Cluster-Scheduler) | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20230410163527.1626-1-kprateek.nayak@amd.com) | +| 2023/05/04 | Tim Chen | [Enable Cluster Scheduling for x86 Hybrid CPUs](https://lore.kernel.org/all/cover.1683156492.git.tim.c.chen@linux.intel.com) | 当集群调度首次引入 x86 时, 人们注意到, 在混合 CPU 上进行集群调度时, 单线程任务通常会在 Atom 核(或 E 核)上完成, 而不是在空闲的 Big 核(或 P 核)上, 从而导致性能降低. 因此, x86 混合 CPU 上的集群调度被禁用. 参见: [Linux 5.16's New Cluster Scheduling Is Causing Regression, Further Hurting Alder Lake](https://www.phoronix.com/review/linux-516-regress). Ricardo 最近推出了 [sched: Avoid unnecessary migrations within SMT domains](https://lore.kernel.org/lkml/20230406203148.19182-1-ricardo.neri-calderon@linux.intel.com) 系列, 极大地改进了 x86 混合 CPU 上 P 核和 E 核之间的负载平衡逻辑. 然而, 该补丁系列不足以允许在混合 x86 CPU 上启用集群调度. 此补丁系列提供了一些额外的修复程序, 用于在由 Big Core 的 SMT CPU 组成的集群调度组和由 Atom CPU 组成的群集调度组之间进行负载平衡. 在 Ricardo 的补丁系列之上继续 APPLY 当前补丁, 可以在 P 核和 E 核集群之间适当平衡负载. 空闲 CPU 按正确顺序使用: 1). 空闲 P 核上的 SMT CPU, 2). 空闲 E 核, 3). 未使用的 SMT CPU 和繁忙的同级.
在 x86 上, Cluster 中的 CPU 共享 L2. 现在, 在启用 Cluster Scheduling 的情况下, Cluster 之间的负载得到了平衡, 从而可能减少 L2 争用. 参见 [Intel Posts New Linux Patches For Cluster Scheduling With Hybrid CPUs](https://www.phoronix.com/news/Intel-Hybrid-CPU-Cluster-Sched) | v1 ☐☑✓ | [LORE v1,0/4](https://lore.kernel.org/lkml/20220825225529.26465-1-ricardo.neri-calderon@linux.intel.com)
*-*-*-*-*-*-*-*
[LORE v2,0/7](https://lore.kernel.org/lkml/20221122203532.15013-1-ricardo.neri-calderon@linux.intel.com)
*-*-*-*-*-*-*-*
[LORE v3,0/10](https://lore.kernel.org/lkml/20230207045838.11243-1-ricardo.neri-calderon@linux.intel.com)
*-*-*-*-*-*-*-*
[LORE v4,00/12](https://lore.kernel.org/lkml/20230406203148.19182-1-ricardo.neri-calderon@linux.intel.com) | ### 5.5.2 Multiple LLCs @@ -6281,7 +6308,7 @@ B 站 Plugsched 介绍视频 [纯干货解读：Plugsched, 首次实现 Linux ke | 2021/08/03 | Peter Oskolkov | [thread_info: use helpers to snapshot thread flags](https://lwn.net/Articles/722293) | 引入 read_ti_thread_flags() 规范对 thread_info 中 flag 的访问. 其中默认使用了 READ_ONCE. 防止开发者忘记了这样做. | v4 ☐ | [PatchWork v4,00/10](https://lore.kernel.org/patchwork/cover/1471548) | | 2023/03/30 | Mathieu Desnoyers | [sched: Introduce per-mm/cpu concurrency id state](https://lore.kernel.org/all/20230330230911.228720-1-mathieu.desnoyers@efficios.com) | 跟踪每个 mm/cpu 当前分配的 mm_cid, 而不是立即释放它们. 这消除了在多线程场景(多个进程, 每个进程有多个线程)中, 在属于不同内存空间的线程之间来回切换上下文时的大多数原子操作. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20230330230911.228720-1-mathieu.desnoyers@efficios.com) | | 2023/04/18 | Tejun Heo | [workqueue: Implement automatic CPU intensive detection and add monitoring](https://lore.kernel.org/all/20230418205159.724789-1-tj@kernel.org) | 为了减少并发工作线程的数量, 当前一个工作项保持在 RUNNING 状态时, 工作队列会阻止启动每个 CPU 的工作项. 因此, 每 CPU 工作项会消耗大量 CPU 周期, 即使它在正确的位置有 cond_resched(), 也可能会暂停其他每 CPU 工作项目.
为了支持可能占用 CPU 相当长一段时间的每 CPU 工作项, 工作队列具有 WQ_CPU_INTENIVE 标志, 该标志将通过标记的工作队列发布的工作项从并发管理中豁免——它们会立即启动, 不会阻塞其他工作项. 虽然这很有效, 但它很容易出错, 因为工作队列用户很容易忘记设置标志或不必要地设置标志. 此外, 错误标志设置的影响可能是相当间接的, 对根本原因具有挑战性.
这组补丁使工作队列能够根据 CPU 消耗量自动检测 CPU 密集型工作项. 如果一个工作项消耗的 CPU 时间超过阈值(默认情况下为 5ms), 则当它被调度出去时, 它会自动标记为 CPU 密集型, 从而取消对每个 CPU 的挂起工作项的启动.
这种机制并不是万无一失的, 因为如果许多占用 CPU 的工作项同时排队, 检测延迟可能会增加. 然而, 在这种情况下, 更大的问题可能是 CPU 被每个 CPU 的工作项饱和, 解决方案是使它们无法绑定. 未来的更改将通过改进 UNBOUND 工作队列的局部性行为, 并最终删除显式 WQ_CPU_INTENIVE 标志, 使其更具吸引力.
同时, 添加统计信息和监控脚本. 在调试与工作队列相关的问题时, 缺乏可见性一直是一个痛点, 随着这一变化以及为工作队列计划的更激烈的变化, 现在是解决这一缺点的好时机. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20230418205159.724789-1-tj@kernel.org) | -| 2023/01/13 | Nathan Huckleberry | [workqueue: Add WQ_SCHED_FIFO](https://lore.kernel.org/all/20230113210703.62107-1-nhuck@google.com) | 添加一个 WQ 标志, 允许工作队列使用具有最低重要 RT 优先级的 SCHED_FIFO. 这可以减少 CPU 负载时 IO 后处理的调度器延迟, 而不会影响其他 RT 工作负载.
这已被证明可以改善安卓系统上的应用程序启动时间[1].
调度程序延迟会影响几个驱动程序. 其中一些驱动程序已将后处理移至 IRQ 上下文中.
然而, 这可能会导致 Android 上实时线程的延迟峰值和抖动相关的 JANK. 将工作队列与 SCHED_FIFO 一起使用可以改善调度程序延迟, 而不会给 RT 线程带来延迟问题. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20230113210703.62107-1-nhuck@google.com) | +| 2023/01/13 | Nathan Huckleberry | [workqueue: Add WQ_SCHED_FIFO](https://lore.kernel.org/all/20230113210703.62107-1-nhuck@google.com) | 添加一个 WQ 标志, 允许工作队列使用具有最低重要 RT 优先级的 SCHED_FIFO. 这可以减少 CPU 负载时 IO 后处理的调度器延迟, 而不会影响其他 RT 工作负载.
这已被证明可以改善安卓系统上的应用程序启动时间[1].
调度程序延迟会影响几个驱动程序. 其中一些驱动程序已将后处理移至 IRQ 上下文中.
然而, 这可能会导致 Android 上实时线程的延迟峰值和抖动相关的 JANK. 将工作队列与 SCHED_FIFO 一起使用可以改善调度程序延迟, 而不会给 RT 线程带来延迟问题. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20230113210703.62107-1-nhuck@google.com)
*-*-*-*-*-*-*-*
[LORE v2](https://lore.kernel.org/all/20230510030752.542340-1-tj@kernel.org) | @@ -6328,6 +6355,8 @@ ARM & Linaro 的内核团队针对 Android/linux 等做了大量的调度的优 | 2019/06/04 | Qais Yousef | [sched: Add new tracepoints required for EAS testing](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=a056a5bed7fa67706574b00cf1122c38596b2be1) | 增加 PELT 的跟踪点.
新引入了 `trace_pelt_{cfs|rt|dl|irq}_tp` 等 tracepoint 点跟踪 RQ 的负载信息, 以及 `trace_pelt_se_tp` 等 sched_entity 级别的负载跟踪点, 还提供了 `trace_sched_overutilized_tp` 记录 RQ 和 SD 的 overutilized 状态. 主要是为了跟踪 PELT 的内容, 这是 EAS 做出决策时使用的信息. 了解 PELT 的变化, LISA 可以根据模拟不同场景的综合测试来验证 EAS 是否在做正确的事情. 除了 EAS 之外, 新的 tracepoint 点还可以帮助研究 CFS 负载均衡器和 CFS 任务组处理. | v2 ☑ 5.3-rc1 | [LORE v3,0/6](https://lore.kernel.org/lkml/1598605249-72651-1-git-send-email-vincent.donnefort@arm.com) | | 2020/06/19 | Phil Auld | [Sched: Add a tracepoint to track rq->nr_running](https://lore.kernel.org/patchwork/patch/1258690) | 增加 nr_running 的跟踪点. 通过 | v1 ☑ 5.9-rc1 | [PatchWork](https://lore.kernel.org/patchwork/patch/1258690), [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d246053a69196c7c27068870e9b4b66ac536f68)
*-*-*-*-*-*-*-*
[FixPatch](https://lore.kernel.org/patchwork/patch/1284621), [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a1bd06853ee478d37fae9435c5521e301de94c67) | | 2020/08/28 | | [sched/debug: Add new tracepoint to track cpu_capacity](https://lore.kernel.org/patchwork/patch/1296761) | 增加 cpu_capacity 的跟踪点 | v2 ☑ 5.10-rc1 | [PatchWork](https://lore.kernel.org/patchwork/cover/1296761), [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=51cf18c90ca1b51d1cb4af3064e85fcf8610b5d2) | +| 2023/05/09 | Lukasz Luba | [Add basic tracing for uclamp and schedutil](https://lore.kernel.org/all/20230509122246.1702397-1-lukasz.luba@arm.com) | TODO | v2 ☐☑✓ | [LORE v2,0/3](https://lore.kernel.org/all/20230509122246.1702397-1-lukasz.luba@arm.com) | + ## 12.3 debug 接口 ------- diff --git a/study/kernel/00-DESCRIPTION/TODO.md b/study/kernel/00-DESCRIPTION/TODO.md index 635e762..26ba752 100644 --- a/study/kernel/00-DESCRIPTION/TODO.md +++ b/study/kernel/00-DESCRIPTION/TODO.md @@ -18,8 +18,6 @@ https://lore.kernel.org/patchwork/project/lkml/list/?submitter=13305 - - | 2022/08/19 | Alexei Starovoitov | [bpf: BPF specific memory allocator.](https://patchwork.kernel.org/project/linux-mm/cover/20220819214232.18784-1-alexei.starovoitov@gmail.com/) | 669364 | v3 ☐☑ | [LORE v3,0/15](https://lore.kernel.org/r/20220819214232.18784-1-alexei.starovoitov@gmail.com)
*-*-*-*-*-*-*-*
[LORE v4,0/15](https://lore.kernel.org/r/20220826024430.84565-1-alexei.starovoitov@gmail.com)
*-*-*-*-*-*-*-*
[LORE v5,0/15](https://lore.kernel.org/r/20220901161547.57722-1-alexei.starovoitov@gmail.com)
*-*-*-*-*-*-*-*
[LORE v6,0/16](https://lore.kernel.org/r/20220902211058.60789-1-alexei.starovoitov@gmail.com) | | 2022/09/02 | Yafang Shao | [bpf: Introduce selectable memcg for bpf map](https://patchwork.kernel.org/project/linux-mm/cover/20220902023003.47124-1-laoar.shao@gmail.com/) | 673444 | v3 ☐☑ | [LORE v3,0/13](https://lore.kernel.org/r/20220902023003.47124-1-laoar.shao@gmail.com) | | 2022/11/07 | Song Liu | [execmem_alloc for BPF programs](https://patchwork.kernel.org/project/linux-mm/cover/20221107223921.3451913-1-song@kernel.org/) | 692973 | v2 ☐☑ | [LORE v2,0/5](https://lore.kernel.org/r/20221107223921.3451913-1-song@kernel.org)[LORE v4,0/6](https://lore.kernel.org/r/20221117202322.944661-1-song@kernel.org)
*-*-*-*-*-*-*-*
[LORE v5,0/6](https://lore.kernel.org/r/20221128190245.2337461-1-song@kernel.org) | @@ -365,5 +363,72 @@ https://www.latexlive.com -为解析 ascii 跟踪输出的流行方法提供一种更高效、更强大的替代方法, 以便从中提取有用的信息. 为了避免所有这些的开销和复杂性, 这个补丁集提供了一个直接到脚本的解释器路径来做同样的事情, 但以一种更规则化的方式, 它利用了跟踪基础结构提供的所有事件元信息, 例如为此目的设计的 "格式文件" 中包含的事件 / 字段信息. 它允许将通用脚本语言的全部功能应用于跟踪流, 以进行非琐碎的分析, 并突然提供了大量有用的工具和模块库(例如, 用于 Perl 的 CPAN), 以应用于创建新的、有趣的跟踪应用程序的问题. 当前只实现了一个 Perl 接口, 但其目的是使添加对其他语言(如 Python、Ruby 等)的支持相对容易——他们所需要做的就是以 Perl 实现为例, 提供自己的 trace_scripting_ops 实现和支持函数. + + + +使用 numa 扫描增强功能 [LORE v3,0/4](https://lore.kernel.org/all/cover.1677672277.git.raghavendra.kt@amd.com), 只允许以前访问过 vma 的线程进行扫描. 虽然这改善了显著的系统时间开销, 但也存在一些角落情况, 这确实需要一些放松, 例如 PeterZ 提出的担忧, 即属于不相交的 VMS 集合的线程之间的不公平可能会放大属于未扫描的一些任务的 vma 区域的副作用. 目前, 这是通过无条件地允许 mm 级别 (mm->numa_scan_seq) 的前两次扫描来处理的.
其中一个具有类似副作用的测试是 numa01_THREAD_ALLOC, 其中通过主线程进行分配, 并将其划分为 24MB 的内存块以连续地归零. + + + +(这是 LKP 测试默认运行的, 而 numa01 是 mmtests 默认运行的 (mmtests 由每个线程在整个 3GB 区域上操作) + +因此, 为了解决这个问题, 这里的建议是： + + + +1) 每个 vma 扫描计数器, 每次成功扫描 (可能扫描 256MB 或 sysctl_scan_size) 都会递增 2) 前几次进行无条件扫描 (准确地说, 正常扫描时会计算出一半的窗口)3) 在 vma 级别扫描整个 mm 时重置计数器 (这需要记住 mm->numa_scan_sequece) + +有了这个补丁, 我看到 numa01_THREAD_ALLOC 情况有了很好的改善, 但请注意, 在 [1] 中, 当基准测试运行时, 系统时间大幅减少, 这个补丁增加了一些系统时间. + + + + + + +这是将根 cfg_rq runnable_avg 作为一种考虑 CPU 频率和 "migrate_util" 类型负载平衡最繁忙 CPU 选择的 CPU 争用的方法的想法的实现. + + + +https://lkml.kernel.org/r/424e2c81-987d-f10e-106d-8b4c611768bc@arm.com 网站 + +| 2023/05/12 | Dietmar Eggemann | [sched: Consider CPU contention in frequency, EAS max util & load-balance busiest CPU selection](https://lore.kernel.org/all/20230512101029.342823-1-dietmar.eggemann@arm.com) | TODO | v2 ☐☑✓ | [LORE v1,0/1](https://lore.kernel.org/all/20230406155030.1989554-1-dietmar.eggemann@arm.com)[LORE v2,0/2](https://lore.kernel.org/all/20230512101029.342823-1-dietmar.eggemann@arm.com) | + + + + +[Discussion](https://lkml.kernel.org/r/424e2c81-987d-f10e-106d-8b4c611768bc@arm.com) + + + +[](https://www.phoronix.com/news/Linux-6.4-Avoid-Unnecessary-SMT) + + +| 2023/04/06 | Ricardo Neri | [sched: Avoid unnecessary migrations within SMT domains](https://lore.kernel.org/all/20230406203148.19182-1-ricardo.neri-calderon@linux.intel.com) | TODO | v4 ☐☑✓ | + + + +| 2023/03/07 | Jens Axboe | [Add FMODE_NOWAIT support to pipes](https://lore.kernel.org/all/20230308031033.155717-1-axboe@kernel.dk) | [Pipe FMODE_NOWAIT Support Sent In For Linux 6.4 As A 10~23x Performance Improvement](https://www.phoronix.com/news/Pipe-FMODE_NOWAIT-Linux-6.4). | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20230308031033.155717-1-axboe@kernel.dk) | + + +Web Pilot 根据 URL 生成文章摘要, 总结, 翻译. +AskYourPDF 从 PDF 文件内容生成摘要, 分析内容等. +Chat with PDF +kagi.com/summarizer + + +[A kernel without buffer heads](https://lwn.net/Articles/930173) +[Unprivileged BPF and authoritative security hooks](https://lwn.net/Articles/929746) +[Designated movable (memory) blocks](https://lwn.net/Articles/928795) +[The ongoing trouble with get_user_pages()](https://lwn.net/Articles/930667) +[A storage standards update at LSFMM+BPF](https://lwn.net/Articles/931282) +[A storage standards update at LSFMM+BPF](https://lwn.net/Articles/931282) + + +[Memory-management changes for CXL](https://lwn.net/Articles/931416) + +[The future of memory tiering](https://lwn.net/Articles/931421) + + +| 2023/05/16 | Chen Yu | [sched/fair: Introduce SIS_PAIR to wakeup task on local idle core first](https://lore.kernel.org/all/20230516011159.4552-1-yu.c.chen@intel.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20230516011159.4552-1-yu.c.chen@intel.com) | + diff --git a/study/kernel/00-DESCRIPTION/VIRT.md b/study/kernel/00-DESCRIPTION/VIRT.md index aaa8da3..7ac0b02 100644 --- a/study/kernel/00-DESCRIPTION/VIRT.md +++ b/study/kernel/00-DESCRIPTION/VIRT.md @@ -235,7 +235,13 @@ Anbox 使用 Linux 命名空间 (user, pid, uts, net, mount, ipc) 在容器中 |:---:|:----:|:---:|:----:|:---------:|:----:| | 2023/01/02 | Jinank Jain | [x86/hyperv: Add support for detecting nested hypervisor](https://lore.kernel.org/all/8e3e7112806e81d2292a66a56fe547162754ecea.1672639707.git.jinankjain@linux.microsoft.com) | [Microsoft Hyper-V Nested Hypervisor Support Comes For Linux 6.3](https://www.phoronix.com/news/Linux-6.3-Nested-Hyper-V) | v10 ☐☑✓ | [LORE v10,0/5](https://lore.kernel.org/all/8e3e7112806e81d2292a66a56fe547162754ecea.1672639707.git.jinankjain@linux.microsoft.com) | +# 11 Hypervisor +------- +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:---:|:----:|:---:|:----:|:---------:|:----:| +| 2023/04/24 | Elliot Berman | [Drivers for Gunyah hypervisor](https://lore.kernel.org/all/20230424231558.70911-1-quic_eberman@quicinc.com) | [Qualcomm Continues Working To Upstream Gunyah Hypervisor Support In Linux](https://www.phoronix.com/news/Qualcomm-Gunyah-Linux-v12) | v12 ☐☑✓ | [LORE v12,0/25](https://lore.kernel.org/all/20230424231558.70911-1-quic_eberman@quicinc.com) | +| 2023/05/12 | Yi-De Wu | [GenieZone hypervisor drivers](https://lore.kernel.org/all/20230512080405.12043-1-yi-de.wu@mediatek.com) | TODO | v3 ☐☑✓ | [LORE v1,0/6](https://lore.kernel.org/lkml/20230413090735.4182-1-yi-de.wu@mediatek.com)
*-*-*-*-*-*-*-*
[LORE v2,0/7](https://lore.kernel.org/lkml/20230428103622.18291-1-yi-de.wu@mediatek.com)
*-*-*-*-*-*-*-*
[LORE v3,0/7](https://lore.kernel.org/all/20230512080405.12043-1-yi-de.wu@mediatek.com) |