description/open_source: update phoronix vs LWN to date 20240520

2026-11-15 13:04:18 +08:00 · 2024-05-25 15:01:45 +08:00
1 parent 9ed852159a
commit d86c252acb
@@ -1135,6 +1135,7 @@ Fedora 尝试优化 systemd 开机以及重启的时间, 参见 phoronix 报道
 | 2024/03/27 | Wedson Almeida Filho <wedsonaf@gmail.com> | [In-place module initialisation](https://lore.kernel.org/all/20240327032337.188938-1-wedsonaf@gmail.com) | [Microsoft Engineer Sends Rust Linux Kernel Patches For In-Place Module Initialization](https://www.phoronix.com/news/Linux-Rust-In-Place-Module-Init) | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20240327032337.188938-1-wedsonaf@gmail.com) |
 | 2024/03/22 | Boqun Feng <boqun.feng@gmail.com> | [Memory model and atomic API in Rust](https://lore.kernel.org/all/20240322233838.868874-1-boqun.feng@gmail.com) | [A memory model for Rust code in the kernel](https://lwn.net/Articles/967049). | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20240322233838.868874-1-boqun.feng@gmail.com) |
 | 2024/05/14 | Wedson Almeida Filho <wedsonaf@gmail.com> | [Rust abstractions for VFS](https://lore.kernel.org/all/20240514131711.379322-1-wedsonaf@gmail.com) | 参见 phoronix 报道 [Microsoft Engineer Ports EXT2 File-System Driver To Rust](https://www.phoronix.com/news/Rust-VFS-Linux-V2-Now-With-EXT2). | v2 ☐☑✓ | [LORE v2,0/30](https://lore.kernel.org/all/20240514131711.379322-1-wedsonaf@gmail.com) |
+| 2024/05/20 | Danilo Krummrich <dakr@redhat.com> | [DRM Rust abstractions and Nova](https://lore.kernel.org/all/20240520172059.181256-1-dakr@redhat.com) | [RFC Patches Posted For Rust-Written NVIDIA "Nova" GPU Driver](https://www.phoronix.com/news/RFC-Rust-Nova-NVIDIA-Driver) | v1 ☐☑✓ | [LORE v1,0/8](https://lore.kernel.org/all/20240520172059.181256-1-dakr@redhat.com) |


 ## 22.2 C++
@@ -1105,11 +1105,14 @@ NUMA 系统中 CPU 访问不同节点的内存速度很有大的差别. 位于
 #### 2.2.3.2 Weighted memory interleaving
 -------

+Gregory Price 在 LSFMMBPF 2024 介绍了 2024 年社区提出的 Weighted memory interleaving 方向的探索. 参见 LWN 报道 [2024/05/18, Extending the mempolicy interface for heterogeneous systems](https://lwn.net/Articles/973964)

 | 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:----:|:----:|:---:|:----:|:---------:|:----:|
+| 2023/10/09 | Gregory Price <gourry.memverge@gmail.com> | [mm: mempolicy: Multi-tier weighted interleaving](https://lore.kernel.org/all/20231009204259.875232-1-gregory.price@memverge.com) | 参见 LWN 报道 [Weighted interleaving for memory tiering](https://lwn.net/Articles/948037). | v2 ☐☑✓ | [LORE v2,0/3](https://lore.kernel.org/all/20231009204259.875232-1-gregory.price@memverge.com) |
 | 2023/11/22 | Gregory Price <gourry.memverge@gmail.com> | [mm/mempolicy: Make task->mempolicy externally modifiable via syscall and procfs](https://lore.kernel.org/all/20231122211200.31620-1-gregory.price@memverge.com) | 该补丁集允许其他特权进程修改当前任务的内存策略 task->mempolicy. 最终目标是使 mempolicy 更加灵活和可扩展, 例如添加交织权重 Weighted memory interleaving (由于热插拔事件, 可能需要在运行时更改). 通过对 mempolicy 进行外部修改, userland 守护进程可以对正在运行的任务进行运行时性能调整, 而无需使该软件具有 numa 意识. | v1 ☐☑✓ | [LORE v1,0/11](https://lore.kernel.org/all/20231122211200.31620-1-gregory.price@memverge.com) |
 | 2023/12/23 | Gregory Price <gourry.memverge@gmail.com> | [mempolicy2, mbind2, and weighted interleave](https://lore.kernel.org/all/20231223181101.1954-1-gregory.price@memverge.com) | 参照 LWN 报道 [Weighted memory interleaving and new system calls](https://lwn.net/Articles/969379). | v5 ☐☑✓ | [LORE v5,0/11](https://lore.kernel.org/all/20231223181101.1954-1-gregory.price@memverge.com) |
+| 2024/02/20 | Gregory Price <gourry.memverge@gmail.com> | [mm/mempolicy: weighted interleave system default weights](https://lore.kernel.org/all/20240220202529.2365-1-gregory.price@memverge.com) | 参见 LWN 报道 [2024/05/18, Extending the mempolicy interface for heterogeneous systems](https://lwn.net/Articles/973964). | v1 ☐☑✓ | [LORE v1,0/1](https://lore.kernel.org/all/20240220202529.2365-1-gregory.price@memverge.com) |


 ### 2.2.4 内存水线
@@ -1739,6 +1742,8 @@ Date:   Wed Sep 11 14:20:35 2013 -0700

 BUDDY 提供了页面的分配和回收机制, 而在运行时, SLAB 等对象分配器向 BUDDY 一次性 "批发" 一些内存, 加工切块以后 "散卖" 出去. 等自己 "批发" 的库存耗尽了, 那么就再去向 BUDDY 申请批发一些. 在这个过程中, BUDDY 是一个内存的批发商, 接受一些大的内存订单, 而 SLAB 等对象分配器像是一个二级分销商, 把申请的内存零售出去, 一段时间以后如果客户不需要使用内存了, 那么 SLAB 这些分销商再零碎的回收回去, 当自己库存足够多的时候, 会再把库存退回给 BUDDY 这个批发商.

+在 6.4 版本中, 针对低内存系统的 SLOB 分配器被删除, 随后 SLAB 也被删除, 内核中只剩下 SLUB. 内核开发人员现在可以更自由地改进 SLUB, 而不用担心破坏其他 SLUB. LSFMMBPF 2024 上 SLAB 的 maintainer Vlastimil Babka 对 SLUB 机制的未来做了规划和展望, 参见 LWN 报道 [2024/05/20, What's next for the SLUB allocator](https://lwn.net/Articles/974138).
+

 https://lore.kernel.org/patchwork/patch/47616/
 https://lore.kernel.org/patchwork/patch/46669/
@@ -1784,11 +1789,12 @@ Linux slab 分配器使用了这种思想和其他一些思想来构建一个在

 与传统的内存管理模式相比,  slab 缓存分配器提供了很多优点. 首先, 内核通常依赖于对小对象的分配, 它们会在系统生命周期内进行无数次分配. slab 缓存分配器通过对类似大小的对象进行缓存而提供这种功能, 从而避免了常见的碎片问题. slab 分配器还支持通用对象的初始化, 从而避免了为同一目而对一个对象重复进行初始化. 最后, slab 分配器还可以支持硬件缓存对齐和着色, 这允许不同缓存中的对象占用相同的缓存行, 从而提高缓存的利用率并获得更好的性能.

+最终 SLAB 分配器于 v6.8 从内核中移除.

 | 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:----:|:----:|:---:|:----:|:---------:|:----:|
 | 2023/04/01 | Vlastimil Babka <vbabka@suse.cz> | [mm: remove all the slab allocators](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=eb07c4f39c3e858a7d0cc4bb15b8a304f83f0497) | 由于 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 文件中只保留一个将所有内容传递给页面分配器的层. 这将允许用户逐渐转移并直接使用页面分配器. 总结优势:<br>1. 需要维护的代码更少: 这个补丁删除了超过 13k 行, 如果我在这方面花了更多的时间, 以及以后随着用户从遗留层过渡, 可以删除更多的代码.<br>2. 简化的 MEMCG_KMEM 记帐: 虽然我很懒, 只是在这个补丁中将其标记为 BROKEN, 但既然我们使用了页面分配器, 那么使用页面 MEMCG 记帐应该是微不足道的. 每个对象的核算在过去经历了几次迭代, 而且总是很复杂, 增加了开销. 相比之下, 页面会计要简单得多.<br>3. 简化了 KASAN 和朋友: 在这个补丁中也很懒, 所以不能启用它们, 但应该很容易修复, 只在页面级别工作.<br>4. 更简单的调试: 只需使用 debug_pagealloc=on, 无需查找复杂得离谱的 slub_debug 参数的确切语法.<br>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), [[LSF/MM/BPF TOPIC] SLOB+SLAB allocators removal and future SLUB improvements](https://lwn.net/ml/linux-mm/4b9fc9c6-b48c-198f-5f80-811a44737e5f@suse.cz) 以及 LWN 报道 [A slab allocator (removal) update](https://lwn.net/Articles/932201). 参见 [Linux's SLAB Allocator Is Officially Deprecated](https://www.phoronix.com/news/SLAB-Officially-Deprecated). | v1 ☐☑ 6.5-rc1 | [LORE v1,0/1](https://lore.kernel.org/r/20230401094658.11146-1-vbabka@suse.cz) |
-| 2023/11/20 | Vlastimil Babka <vbabka@suse.cz> | [remove the SLAB allocator](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=ecf9a253ce120082ce0a8aff806c4de4865cfcc5) | TODO | v2 ☐☑✓ | [LORE v1](https://lore.kernel.org/all/20231113191340.17482-22-vbabka@suse.cz)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/21](https://lore.kernel.org/all/20231120-slab-remove-slab-v2-0-9c9c70177183@suse.cz) |
+| 2023/11/20 | Vlastimil Babka <vbabka@suse.cz> | [remove the SLAB allocator](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=ecf9a253ce120082ce0a8aff806c4de4865cfcc5) | TODO | v2 ☐☑✓ v6.8-rc1 | [2023/11/13, LORE v1,0/20](https://lore.kernel.org/all/20231113191340.17482-22-vbabka@suse.cz)<br>*-*-*-*-*-*-*-* <br>[LORE v2,00/21](https://lore.kernel.org/all/20231120-slab-remove-slab-v2-0-9c9c70177183@suse.cz) |



@@ -1810,6 +1816,14 @@ Linux slab 分配器使用了这种思想和其他一些思想来构建一个在
 **2.6.22(2007 年 7 月发布)**


+
+SLUB 这是第二个对象分配器实现. 引入这个新的实现的原因是 SLAB 存在的一些问题. 比如 NUMA 的支持, SLAB 引入时内核还没支持 NUMA, 因此, 一开始就没把 NUMA 的需求放在设计理念里, 结果导致后来的对 NUMA 的支持比较臃肿奇怪, 一个典型的问题是, SLAB 为追踪这些缓存, 在每个 CPU, 每个 node, 上都维护着对象队列. 同时, 为了满足 NUMA 分配的局部性, 每个 node 上还维护着所有其他 node 上的队列, 这样导致 SLAB 内部为维护这些队列就得花费大量的内存空间, 并且是 O(n^2) 级别的. 这在大规模的 NUMA 机器上, 浪费的内存相当可观. 同时, 还有别的一些使用上的问题, 导致开发者对其不满, 因而引入了新的实现. 参见 [The SLUB allocator](https://lwn.net/Articles/229984).
+
+SLUB 在解决了上述的问题之上, 提供与 SLAB 完全一样的接口, 所以用户可以无缝切换, 而且, 还提供了更好的调试支持. 早在几年前, 各大发行版中的对象分配器就已经切换为 SLUB 了.
+
+关于性能, 前阵子为公司的系统切换 SLUB, 做过一些性能测试, 在一台两个 NUMA node, 32 个逻辑 CPU , 252 GB 内存的机器上, 在相同的 workload 测试下, SLUB 综合来说, 体现出了比 SLAB 更好的性能和吞吐量.
+
+
 | 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:----:|:----:|:---:|:----:|:---------:|:----:|
 | 2007/02/28 | Christoph Lameter <clameter@engr.sgi.com> | [SLUB The unqueued slab allocator V6](https://lore.kernel.org/patchwork/patch/77393) | 优化调度器的路径, 减少对 rq->lock 的争抢, 实现 lockless. | v3 ☑ 2.6.22-rc1 | [PatchWork v3](https://lore.kernel.org/patchwork/patch/75156)<br>*-*-*-*-*-*-*-* <br>[PatchWork v6](https://lore.kernel.org/patchwork/patch/75156), [commit 81819f0fc828 SLUB core](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=81819f0fc8285a2a5a921c019e3e3d7b6169d225) |
@@ -1821,12 +1835,6 @@ Linux slab 分配器使用了这种思想和其他一些思想来构建一个在
 | 2023/08/08 | Vlastimil Babka <vbabka@suse.cz> | [SLUB percpu array caches and maple tree nodes](https://patchwork.kernel.org/project/linux-mm/cover/20230808095342.12637-7-vbabka@suse.cz/) | 773975 | v1 ☐☑ | [LORE v1,0/5](https://lore.kernel.org/r/20230808095342.12637-7-vbabka@suse.cz)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/7](https://lore.kernel.org/r/20230810163627.6206-9-vbabka@suse.cz) |


-SLUB 这是第二个对象分配器实现. 引入这个新的实现的原因是 SLAB 存在的一些问题. 比如 NUMA 的支持, SLAB 引入时内核还没支持 NUMA, 因此, 一开始就没把 NUMA 的需求放在设计理念里, 结果导致后来的对 NUMA 的支持比较臃肿奇怪, 一个典型的问题是, SLAB 为追踪这些缓存, 在每个 CPU, 每个 node, 上都维护着对象队列. 同时, 为了满足 NUMA 分配的局部性, 每个 node 上还维护着所有其他 node 上的队列, 这样导致 SLAB 内部为维护这些队列就得花费大量的内存空间, 并且是 O(n^2) 级别的. 这在大规模的 NUMA 机器上, 浪费的内存相当可观. 同时, 还有别的一些使用上的问题, 导致开发者对其不满, 因而引入了新的实现. 参见 [The SLUB allocator](https://lwn.net/Articles/229984).
-
-SLUB 在解决了上述的问题之上, 提供与 SLAB 完全一样的接口, 所以用户可以无缝切换, 而且, 还提供了更好的调试支持. 早在几年前, 各大发行版中的对象分配器就已经切换为 SLUB 了.
-
-关于性能, 前阵子为公司的系统切换 SLUB, 做过一些性能测试, 在一台两个 NUMA node, 32 个逻辑 CPU , 252 GB 内存的机器上, 在相同的 workload 测试下, SLUB 综合来说, 体现出了比 SLAB 更好的性能和吞吐量.
-


 ### 2.3.3 SLOB
@@ -3476,6 +3484,7 @@ MGLRU 的开发者在 LPC-2022 上演示了 MGLRU [Multi-Gen LRU: Current Status

 MGLRU 合入后, 引起了不少场景的性能劣化, 参见 phoronix 报道 [An MGLRU Performance Regression Fix Is On The Way Plus Another Optimization](https://www.phoronix.com/news/MGLRU-SVT-Performance-Fix).

+hakavlad 提供了简单的 shell 脚本和 oneshot systemd 服务 [hakavlad/mg-lru-helper](https://github.com/hakavlad/mg-lru-helper) , 可以在引导时或运行中启用或禁用多代 LRU, 并获取 MGLRU 的当前状态. 并梳理了 MGLRU 历史各个版本的 PATCHSET 以及相关报道. 并对比测试了 MGLRU 以及 ClassicLRU 的性能差异 [cache-tests/mg-LRU-v3_vs_classic-LRU](https://github.com/hakavlad/cache-tests/tree/main/mg-LRU-v3_vs_classic-LRU).

 *   实现

@@ -3497,8 +3506,7 @@ MGLRU 合入后, 引起了不少场景的性能劣化, 参见 phoronix 报道 [A
 ### 4.2.8 工作集大小的探测(Better LRU list balancing)
 -------

-https://lore.kernel.org/patchwork/patch/222042
-https://github.com/hakavlad/le9-patch
+

 **3.15(2014 年 6 月发布)**

@@ -4071,6 +4079,7 @@ v2.5 的时候引入了 shrink 机制, 并提供了 API 统一了各个模块的
 [系统软件工程师必备技能 - 进程内存的 working set size(WSS)测量](https://blog.csdn.net/juS3Ve/article/details/85333717)


+
 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).
@@ -4221,9 +4230,13 @@ PowerPC 体系结构 (POWER10) 支持热/冷页面跟踪功能(Hot/Cold page tra
 ### 4.4.7 Working Set Control
 -------

+内核不提供在内存压力下保护工作集的方法. 用户空间需要一定数量的匿名和干净的文件页才能正常运行. 首先, 用户空间需要共享库和可执行二进制文件的缓存. 如果干净文件页的数量低于某个级别, 则可能会发生抖动甚至死锁.
+
+[`LE9-PATCH`](https://github.com/hakavlad/le9-patch) 提供了一些 sysctl 旋钮, 用于对干净的文件页面进行软保护和硬保护, 从而在内存压力下保护 Working Set(匿名和干净的文件页).

 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:---:|:----:|:---:|:----:|:---------:|:----:|
+| 2010/10/28 | Mandeep Singh Baines <msb@chromium.org> | [RFC: vmscan: add min_filelist_kbytes sysctl for protecting the working set](https://lore.kernel.org/all/20101028191523.GA14972@google.com) | Linux 桌面在沉重的内存压力下可能会非常难以忍受, 正如多年来所展示的那样, 如今越来越多的注意力转向 OOMD/systemd-oomd 和其他替代方案, 以更好地处理 Linux 内存不足/内存不足的情况, 尤其是当今的桌面软件和 Web 浏览器消耗越来越多的内存. 帮助这种情况的另一项努力是 "le9" Linux 内核补丁. 保护干净的文件页(页面缓存)可用于防止抖动、减少内存压力下的 I/O、避免高延迟并防止在接近 OOM 的条件下发生活锁. 当前的 le9 补丁提供了两个 sysctl 旋钮, 用于对干净的文件页面进行软保护和硬保护. 当前的 le9 补丁基于最初由 Mandeep Singh Baines (2010) 和 Marcus Linsner (2018-2019) 创建的补丁. 参见 ["le9" Strives To Make Linux Very Usable On Systems With Small Amounts Of RAM](https://www.phoronix.com/news/le9-Linux-Low-RAM), [le9-patch, Add sysctl knobs for protecting the working set](https://github.com/hakavlad/le9-patch). | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20101028191523.GA14972@google.com) |
 | 2021/11/30 | Alexey Avramov <hakavlad@inbox.lv> | [mm/vmscan: add sysctl knobs for protecting the working set](https://lore.kernel.org/all/20211130201652.2218636d@mail.inbox.lv) | 内核没有提供在内存压力下保护工作集的方法. 用户空间的正常操作需要一定数量的匿名和干净的文件页面. 首先, 用户空间需要共享库和可执行二进制文件的缓存. 如果干净文件页面的数量低于一定的水平, 那么就会发生抖动甚至是动态锁. 该补丁提供了 sysctl, 用于在内存压力下保护工作集 (匿名和干净的文件页面). vm.anon_min_kbytes sysctl 旋钮提供匿名页面的**硬**保护. 当前节点上的匿名页面数量低于 vm.anon_min_kbytes 时, 在任何情况下都不会被回收. 这个 sysctl 可用于防止匿名内存不足时的过多交换抖动(例如, 当内存将被 zram 模块的压缩数据过度填充时). 缺省值由 CONFIG_ANON_MIN_KBYTES 定义 (建议在 Kconfig 中为 0). vm.clean_low_kbytes 旋钮提供尽最大努力保护干净的文件页面. 当前节点上的文件页面清理量小于 vm 时, 不会在内存压力下进行回收. 除非我们威胁要 OOM. 使用此旋钮保护干净的文件页面, 可以在交换时使用. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20211130201652.2218636d@mail.inbox.lv) |


@@ -5912,8 +5925,8 @@ VMA 的读锁定是使用两个序列号完成的: 一个在 vm_area_struct 中,
 | 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:----:|:----:|:---:|:----:|:---------:|:----:|
 | 2022/08/29 | Suren Baghdasaryan <surenb@google.com> | [per-VMA locks proposal](https://lore.kernel.org/all/20220829212531.3184856-1-surenb@google.com) | TODO | v1 ☐☑✓ | [2022/08/29 LORE v1,0/28](https://lore.kernel.org/all/20220829212531.3184856-1-surenb@google.com)<br>*-*-*-*-*-*-*-* <br>[2022/09/01 LORE v1,0/28](https://lore.kernel.org/all/20220901173516.702122-1-surenb@google.com) |
-| 2023/01/09 | Suren Baghdasaryan <surenb@google.com> | [Per-VMA locks](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=c7f8f31c00d187a2c71a241c7f2bd6aa102a4e6f) | 710245 | v1 ☐☑ 6.4-rc1 | [LORE v1,0/41](https://lore.kernel.org/r/20230109205336.3665937-1-surenb@google.com)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/33](https://lore.kernel.org/r/20230127194110.533103-1-surenb@google.com)<br>*-*-*-*-*-*-*-* <br>[LORE v3,00/35](https://lore.kernel.org/all/20230216051750.3125598-1-surenb@google.com)<br>*-*-*-*-*-*-*-* <br>[LORE v4,0/33](https://lore.kernel.org/all/20230227173632.3292573-1-surenb@google.com) |
-| 2023/03/14 | Heiko Carstens <hca@linux.ibm.com> | [s390/mm: try VMA lock-based page fault handling first](https://patchwork.kernel.org/project/linux-mm/patch/20230314132808.1266335-1-hca@linux.ibm.com/) | 729931 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20230314132808.1266335-1-hca@linux.ibm.com) |
+| 2023/01/09 | Suren Baghdasaryan <surenb@google.com> | [Per-VMA locks](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=c7f8f31c00d187a2c71a241c7f2bd6aa102a4e6f) | 开启了 x86,ARM64,POWER 架构. | v1 ☐☑ 6.4-rc1 | [LORE v1,0/41](https://lore.kernel.org/r/20230109205336.3665937-1-surenb@google.com)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/33](https://lore.kernel.org/r/20230127194110.533103-1-surenb@google.com)<br>*-*-*-*-*-*-*-* <br>[LORE v3,00/35](https://lore.kernel.org/all/20230216051750.3125598-1-surenb@google.com)<br>*-*-*-*-*-*-*-* <br>[LORE v4,0/33](https://lore.kernel.org/all/20230227173632.3292573-1-surenb@google.com) |
+| 2023/03/14 | Heiko Carstens <hca@linux.ibm.com> | [s390/mm: try VMA lock-based page fault handling first](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=e06f47a16573decc57498f2d02f9af3bb3e84cf2) | 729931 | v1 ☐☑ 6.4-rc1 | [LORE v1,0/1](https://lore.kernel.org/r/20230314132808.1266335-1-hca@linux.ibm.com) |
 | 2023/04/04 | Matthew Wilcox (Oracle) <willy@infradead.org> | [Avoid the mmap lock for fault-around](https://lore.kernel.org/all/20230404135850.3673404-1-willy@infradead.org) | linux-next 树目前包含一些补丁 (主要来自 Suren), 这些补丁可以在没有 mmap 锁保护的情况下处理一些页面错误. 这个补丁集增加了在不使用 mmap 锁的情况下处理页缓存中已经存在的部分文件的页错误的能力. 作者采取了一种非常渐进的方法来解锁. | v1 ☐☑✓ | [LORE v1,0/6](https://lore.kernel.org/all/20230404135850.3673404-1-willy@infradead.org)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/9](https://lore.kernel.org/r/20230711202047.3818697-1-willy@infradead.org) |
 | 2023/04/14 | Suren Baghdasaryan <surenb@google.com> | [mm: handle swap page faults if the faulting page can be locked](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ea65d9a7db3819b26e673ea987eb830ed207afd0) | 当在 VMA 锁定保护下处理页面故障时, 所有交换页面故障(swap page faults)都会使用 mmap_lock 重试, 因为如果不能立即锁定 folio, 则 folio_lock_or_retry 实现必须放弃并重新获取 mmap_lock. 这个补丁修改为只在对开锁定失败时重试, 而不是重试所有交换的页面错误. | v1 ☐☑✓ | [LORE v1,0/1](https://lore.kernel.org/all/20230414180043.1839745-1-surenb@google.com) |
 | 2023/04/28 | Suren Baghdasaryan <surenb@google.com> | [mm: change per-VMA lock statistics to be disabled by default](https://patchwork.kernel.org/project/linux-mm/patch/20230428173533.18158-1-surenb@google.com) | 743905 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20230428173533.18158-1-surenb@google.com) |
@@ -7472,6 +7485,8 @@ CSDN 宣传博客 [内存不超过 5M, datop 在识别冷热内存及跨 numa

 2.  [KSM tries again](https://lwn.net/Articles/330589)

+此外 [uksmd](https://codeberg.org/pf-kernel/uksmd) 提供了一个 Userspace KSM helper daemon, [CachyOS](https://github.com/CachyOS/uksmd) 将其用在了自己的发行版中. 守护进程会定期检查用户空间任务列表, 并通知 ksmd kthread 设置相关进程 mm_struct 的 MM_VM_MERGE_ANY 标记, 以自动合并具有相同内容的内存页. 仅处理长期任务. 该机制依赖于 v6.4 [mm: process/cgroup ksm support](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=07115fcc15b4aa5c268fb80b82ad15868a82a285) 以及 [pf-kernel/linux](https://codeberg.org/pf-kernel/linux) 内核提供的 `process_ksm_{enable,disable,status}()` 系统调用.
+

 | 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:----:|:----:|:---:|:----:|:---------:|:----:|
@@ -7487,12 +7502,12 @@ CSDN 宣传博客 [内存不超过 5M, datop 在识别冷热内存及跨 numa
 | 2022/08/24 | CGEL <cgel.zte@gmail.com> | [ksm: count allocated rmap_items and update documentation](https://patchwork.kernel.org/project/linux-mm/cover/20220824040036.215002-1-xu.xin16@zte.com.cn/) | 670470 | v2 ☐☑ | [LORE v2,0/2](https://lore.kernel.org/r/20220824040036.215002-1-xu.xin16@zte.com.cn)<br>*-*-*-*-*-*-*-* <br>[LORE v5,0/2](https://lore.kernel.org/r/20220830143731.299702-1-xu.xin16@zte.com.cn) |
 | 2022/08/29 | Qi Zheng <zhengqi.arch@bytedance.com> | [add common struct mm_slot and use it in THP and KSM](https://patchwork.kernel.org/project/linux-mm/cover/20220829143055.41201-1-zhengqi.arch@bytedance.com) | 672053 | v1 ☐☑ | [LORE v1,0/7](https://lore.kernel.org/r/20220829143055.41201-1-zhengqi.arch@bytedance.com)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/7](https://lore.kernel.org/r/20220831031951.43152-1-zhengqi.arch@bytedance.com) |
 | 2022/10/08 | xu.xin.sc@gmail.com <xu.xin.sc@gmail.com> | [ksm: support tracking KSM-placed zero-pages](https://lore.kernel.org/all/20221008070156.308465-1-xu.xin16@zte.com.cn) | 在使能 use_zero_pages 之前, ksm 的 pages_sharing 基本是准确的. 但是当启用 use_zero_pages 时, 所有与内核零页合并的空页都不会计算在 pages_sharing 或 pages_shared 中. 这是因为这些空页面被合并为零页面, KSM 不再管理这些页面, 这至少会导致两个问题: 1. MADV_UNMERGEABLE 和其他触发取消共享的方法将不会取消 KSM 放置的共享零页(这至少是违反 MADV_UNMERGEABLE 文档的), 参见[链接](https://lore.kernel.org/lkml/4a3daba6-18f9-d252-697c-197f65578c44@redhat.com). 2. 当启用 use_zero_pages 时, 我们无法知道有多少页是 KSM 放置的零页, 这导致 KSM 对所有实际合并的页面不透明. 通过这个补丁集我们可以精确地取消共享零页 (ksm - 放置) 并计算 ksm 零页. | v1 ☐☑✓ | [2022/10/08 LORE v1,0/5](https://lore.kernel.org/all/20221008070156.308465-1-xu.xin16@zte.com.cn)<br>*-*-*-*-*-*-*-* <br>[2022/10/11 LORE v3,0/5](https://lore.kernel.org/all/20221011022006.322158-1-xu.xin16@zte.com.cn)<br>*-*-*-*-*-*-*-* <br>[2022/12/26 LORE v4,0/6](https://lore.kernel.org/r/202212260959492929897@zte.com.cn)<br>*-*-*-*-*-*-*-* <br>[LORE v5,0/6](https://lore.kernel.org/r/202212300911327101708@zte.com.cn)<br>*-*-*-*-*-*-*-* <br>[LORE v7,0/6](https://lore.kernel.org/r/202304131346489021903@zte.com.cn)<br>*-*-*-*-*-*-*-* <br>[2023/05/22 LORE v8,0/6](https://lore.kernel.org/r/202305221842587200002@zte.com.cn)<br>*-*-*-*-*-*-*-* <br>[LORE v9,0/5](https://lore.kernel.org/r/202305241351365661923@zte.com.cn)<br>*-*-*-*-*-*-*-* <br>[LORE v10,0/5](https://lore.kernel.org/r/202305251341580149313@zte.com.cn) |
-| 2023/04/06 | Stefan Roesch <shr@devkernel.io> | [mm: process/cgroup ksm support](https://patchwork.kernel.org/project/linux-mm/cover/20230123173748.1734238-1-shr@devkernel.io/) | 到目前为止, KSM 只能通过为内存区域调用 madvise 来启用. 这组补丁允许在进程 / cgroup 级别启用/禁用 KSM. 参见 [Process-level kernel samepage merging control](https://lwn.net/Articles/928510) | v1 ☐☑ | [LORE v1,0/20](https://lore.kernel.org/r/20230123173748.1734238-1-shr@devkernel.io)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/19](https://lore.kernel.org/r/20230210215023.2740545-1-shr@devkernel.io)<br>*-*-*-*-*-*-*-* <br>[LORE v3,0/3](https://lore.kernel.org/r/20230224044000.3084046-1-shr@devkernel.io)<br>*-*-*-*-*-*-*-* <br>[LORE v4,0/3](https://lore.kernel.org/all/20230310182851.2579138-1-shr@devkernel.io)<br>*-*-*-*-*-*-*-* <br>[LORE v5,0/3](http://lore.kernel.org/all/20230406165339.1017597-1-shr@devkernel.io)<br>*-*-*-*-*-*-*-* <br>[LORE v5,0/3](https://lore.kernel.org/r/20230406165339.1017597-1-shr@devkernel.io)<br>*-*-*-*-*-*-*-* <br>[LORE v7,0/3](https://lore.kernel.org/r/20230413233115.1878303-1-shr@devkernel.io)<br>*-*-*-*-*-*-*-* <br>[LORE v8,0/3](https://lore.kernel.org/r/20230415225913.3206647-1-shr@devkernel.io)<br>*-*-*-*-*-*-*-* <br>[LORE v9,0/3](https://lore.kernel.org/r/20230418051342.1919757-1-shr@devkernel.io) |
+| 2023/04/06 | Stefan Roesch <shr@devkernel.io> | [mm: process/cgroup ksm support](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=07115fcc15b4aa5c268fb80b82ad15868a82a285) | 到目前为止, KSM 只能通过为内存区域调用 madvise 来启用. 这组补丁允许在进程 / cgroup 级别启用/禁用 KSM. 参见 [Process-level kernel samepage merging control](https://lwn.net/Articles/928510) | v1 ☐☑ v6.4-rc1 | [LORE v1,0/20](https://lore.kernel.org/r/20230123173748.1734238-1-shr@devkernel.io)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/19](https://lore.kernel.org/r/20230210215023.2740545-1-shr@devkernel.io)<br>*-*-*-*-*-*-*-* <br>[LORE v3,0/3](https://lore.kernel.org/r/20230224044000.3084046-1-shr@devkernel.io)<br>*-*-*-*-*-*-*-* <br>[LORE v4,0/3](https://lore.kernel.org/all/20230310182851.2579138-1-shr@devkernel.io)<br>*-*-*-*-*-*-*-* <br>[LORE v5,0/3](http://lore.kernel.org/all/20230406165339.1017597-1-shr@devkernel.io)<br>*-*-*-*-*-*-*-* <br>[LORE v5,0/3](https://lore.kernel.org/r/20230406165339.1017597-1-shr@devkernel.io)<br>*-*-*-*-*-*-*-* <br>[LORE v7,0/3](https://lore.kernel.org/r/20230413233115.1878303-1-shr@devkernel.io)<br>*-*-*-*-*-*-*-* <br>[LORE v8,0/3](https://lore.kernel.org/r/20230415225913.3206647-1-shr@devkernel.io)<br>*-*-*-*-*-*-*-* <br>[LORE v9,0/3](https://lore.kernel.org/all/20230418051342.1919757-1-shr@devkernel.io) |
 | 2023/02/10 | Stefan Roesch <shr@devkernel.io> | [[v1] mm: add tracepoints to ksm](https://patchwork.kernel.org/project/linux-mm/patch/20230210214645.2720847-1-shr@devkernel.io/) | 720845 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20230210214645.2720847-1-shr@devkernel.io)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/1](https://lore.kernel.org/r/20230313204606.3581988-1-shr@devkernel.io) |
 | 2023/02/27 | Stefan Roesch <shr@devkernel.io> | [[v1] prctl: add flags to enable KSM at the process level](https://patchwork.kernel.org/project/linux-mm/patch/20230227220206.436662-1-shr@devkernel.io/) | 725338 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20230227220206.436662-1-shr@devkernel.io) |
 | 2023/08/11 | Stefan Roesch <shr@devkernel.io> | [[mm/ksm: add pages scanned metric](https://patchwork.kernel.org/project/linux-mm/patch/20230811193655.2518943-1-shr@devkernel.io/) | 775482 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20230811193655.2518943-1-shr@devkernel.io) |
 | 2023/08/17 | Stefan Roesch <shr@devkernel.io> | [proc/ksm: add ksm stats to /proc/pid/smaps](https://patchwork.kernel.org/project/linux-mm/patch/20230817162301.3472457-1-shr@devkernel.io/) | 777100 | v3 ☐☑ | [LORE v3,0/1](https://lore.kernel.org/r/20230817162301.3472457-1-shr@devkernel.io) |
-| 2024/03/29 | Hui Zhu <teawater@gmail.com> | [mm: Introduce uKSM for user-controlled KSM](https://lore.kernel.org/all/20240329104035.62942-1-teawater@antgroup.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240329104035.62942-1-teawater@antgroup.com) |
+| 2024/03/29 | Hui Zhu <teawater@gmail.com> | [mm: Introduce uKSM for user-controlled KSM](https://lore.kernel.org/all/20240329104035.62942-1-teawater@antgroup.com) | 作者提供了一个使用 uKSM 接口跟踪和合并指定任务页面的示例应用程序, 可在 GitHub 获取 [teawater/uksmd](https://github.com/teawater/uksmd). | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240329104035.62942-1-teawater@antgroup.com) |


 ## 14.2 HWPoison - 内存页错误的处理
@@ -28,11 +28,11 @@

 此调度策略包含除上述实时进程之外的其他进程, 亦称普通进程. 采用分时策略, 根据动态优

-先级 (可用 **nice()** API 设置), 分配 CPU 运算资源.  ** 注意: 这类进程比上述两类实时进程优先级低, 换言之, 在有实时进程存在时, 实时进程优先调度 **.
+先级 (可用 **nice()** API 设置), 分配 CPU 运算资源.  **注意: 这类进程比上述两类实时进程优先级低, 换言之, 在有实时进程存在时, 实时进程优先调度**.

 Linux 除了实现上述策略, 还额外支持以下策略:

- **SCHED\_IDLE** 优先级最低, ** 在系统空闲时才跑这类进程 **(如利用闲散计算机资源跑地外文明搜索, 蛋白质结构分析等任务, 是此调度策略的适用者)
+- **SCHED\_IDLE** 优先级最低, **在系统空闲时才跑这类进程**(如利用闲散计算机资源跑地外文明搜索, 蛋白质结构分析等任务, 是此调度策略的适用者)

 - **SCHED\_BATCH** 是 SCHED\_OTHER 策略的分化, 与 SCHED\_OTHER 策略一样, 但针对吞吐量优化

@@ -67,7 +67,7 @@ git log --oneline v5.15...v5.16 | grep -E "Merge tag | Linux"  | grep -E "sched|
 | 6.3 | NA | [Linux 6.3 Scheduler Updates Bring Fixes & Minor Optimizations](https://www.phoronix.com/news/Linux-6.3-Scheduler), [scheduler changes for v6.3](https://lore.kernel.org/lkml/Y%2FNttaqRZ+zaHIjo@gmail.com) |
 | 6.4 | NA | NA |
 | 6.5 | NA | [Linux 6.5 To Enhance Load Balancing For Intel Hybrid CPUs](https://www.phoronix.com/news/Linux-6.5-Intel-Hybrid-Sched), [Scheduler changes for v6.5](https://lore.kernel.org/lkml/ZJq3HtUKZp2uMWLu@gmail.com) |
-
+| 6.10 | NA | [Linux 6.10 Scheduler Changes Bring More Refinements](https://phoronix.com/news/Linux-6.10-Scheduler), [[GIT PULL] Scheduler changes for v6.10](https://lore.kernel.org/lkml/ZkG0nxxBPB%2F03Q%2Fl@gmail.com) |

 cgit 上查看 sched 所有的 log 信息 :

@@ -359,6 +359,18 @@ SCHED_IDLE 跟 SCHED_BATCH 一样, 是 CFS 中的一个策略, SCHED\_IDLE 的
 | 2022/10/27 | Chuyi Zhou <zhouchuyi@bytedance.com> | [sched/fair: favor non-idle group in tick preemption](https://lore.kernel.org/all/20221027081630.34081-1-zhouchuyi@bytedance.com) | [commit 304000390f88 ("sched: Cgroup SCHED_IDLE support")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=304000390f88d049c85e9a0958ac5567f38816ee) 在支持了 group 级别的 SCHED_IDLE 时, 在 check_preempt_wakeup() 路径下, 实现了 SCHED_IDLE 的感知, 总是 [倾向于抢占空闲的 group sched_entity 而不是非空闲 group sched_entity 组](https://elixir.bootlin.com/linux/v5.15/source/kernel/sched/fair.c#L7125), 反之不允许抢占. 但是 check_preempt_tick() 中却没有感知 SCHED_IDLE, 类似地非空闲的 sched_entity 相对于空闲 sched_entity 应该更具有竞争优势. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20221027081630.34081-1-zhouchuyi@bytedance.com) |


+#### 1.1.5.5 Idle Injection Framework
+-------
+
+
+| 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:----:|:----:|:---:|:---:|:-----------:|:---:|
+| 2018/06/12 | Daniel Lezcano <daniel.lezcano@linaro.org> | [powercap/drivers/idle_injection: Add an idle injection framework](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=88763a5cf80ca59a7c3bea32681ce8f697d9995f) | 最初, 通过添加一个插入空闲周期的新策略, 对 ARM 的 cpu_cooling 设备进行了更改. intel_powerclamp 驱动程序执行类似的操作. 与其在 cpuColing 设备中私下实现空闲注入, 不如在专用框架中移动空闲注入代码, 并让其他框架有机会利用它. 该框架依赖于 smpboot kthreads, 该线程通过其主循环处理热插拔和 [un] 驻车的公共代码. 此代码之前曾使用 CPU 冷却设备进行过测试, 并经历了多次迭代. 它现在导致拆分代码和 API 在头文件中导出. 它在 CPU 冷却设备上测试成功. | v6 ☐☑✓ v4.19-rc1 | [LORE](https://lore.kernel.org/all/1528804816-32636-1-git-send-email-daniel.lezcano@linaro.org) |
+| 2022/11/07 | Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> | [Per CPU idle injection](https://lore.kernel.org/all/20221108030342.1127216-1-srinivas.pandruvada@linux.intel.com) | TODO | v1 ☐☑✓  | [LORE v1,0/4](https://lore.kernel.org/all/20221108030342.1127216-1-srinivas.pandruvada@linux.intel.com) |
+| 2023/02/01 | Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> | [Use idle_inject framework for intel_powerclamp](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=acbc661032b8aa0e8359ac77074769ade34a176c) | TODO | v5 ☐☑✓ v6.3-rc1 | [LORE v5,0/4](https://lore.kernel.org/all/20230201182854.2158535-1-srinivas.pandruvada@linux.intel.com) |
+| 2023/01/17 | Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> | [thermal/idle_inject: Support 100% idle injection](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c7cd6f04c0dfb6d44337f92b4c32126d20339873) | TODO | v1 ☐☑✓ v6.3-rc1 | [LORE](https://lore.kernel.org/all/20230117182240.2817822-1-srinivas.pandruvada@linux.intel.com) |
+
+

 ### 1.1.6 吭哧吭哧跑计算 SCHED\_BATCH
 -------
@@ -448,9 +460,10 @@ RT_RUNTIME_SHARE 这个机制本身是为了解决不同 CPU 上, 以及不同

 | 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:----:|:----:|:---:|:----:|:---------:|:----:|
-| 2016/11/07 | Daniel Bristot de Oliveira <bristot@redhat.com> | [sched/rt: RT_RUNTIME_GREED sched feature](https://lore.kernel.org/patchwork/patch/732374) | 限制 RT_RUNTIME_SHARE 的生效场景, 开启了 RT_RUNTIME_GREED 的情况下, RT_RUNTIME_SHARE 将尽量的绿色无害. 即当发现当前 RT 可以窃取时间, 但是有其他 CFS 进程已经在等待的时候, 那么他将主动放弃窃取的机会, 让位给 CFS 进程运行 | v1 ☐ | [PatchWork](https://lore.kernel.org/patchwork/patch/732374) |
+| 2016/11/07 | Daniel Bristot de Oliveira <bristot@redhat.com> | [sched/rt: RT_RUNTIME_GREED sched feature](https://lore.kernel.org/patchwork/patch/732374) | 限制 RT_RUNTIME_SHARE 的生效场景, 开启了 RT_RUNTIME_GREED 的情况下, RT_RUNTIME_SHARE 将尽量的绿色无害. 即当发现当前 RT 可以窃取时间, 但是有其他 CFS 进程已经在等待的时候, 那么他将主动放弃窃取的机会, 让位给 CFS 进程运行. | v1 ☐ | [PatchWork](https://lore.kernel.org/patchwork/patch/732374) |
 | 2016/11/15 | Daniel Bristot de Oliveira <bristot@redhat.com> | [sched/rt: disable RT_RUNTIME_SHARE by default and document it](https://lore.kernel.org/patchwork/cover/735472) | RT_RUNTIME_GREED 无法合入主线后, 作者尝试默认关掉 RT_RUNTIME_SHARE | v1 ☐ | [PatchWork](https://lore.kernel.org/patchwork/patch/735472) |
 | 2020/09/21 | Daniel Bristot de Oliveira <bristot@redhat.com> | [sched/rt: Disable RT_RUNTIME_SHARE by default](https://lore.kernel.org/patchwork/patch/1309182) | 最后一次尝试默认关掉 RT_RUNTIME_SHARE, 终于被主线接受 | RFC ☑ 5.10-rc1 | [PatchWork](https://lore.kernel.org/patchwork/patch/1309182)<br>*-*-*-*-*-*-*-* <br>[commit 2586af1ac187](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2586af1ac187f6b3a50930a4e33497074e81762d) |
+| 2024/04/10 | Atul Pant <quic_atulpant@quicinc.com> | [Disable RT-throttling for idle-inject threads](https://lore.kernel.org/all/20240410045417.3048209-1-quic_atulpant@quicinc.com) | 作者正试图通过在 CPU 上使用空闲注入来实现一种散热解决方案. 然而, 作者在当前的空闲注入框架中面临一些限制. 作者希望开始在 CPU 上无限期地注入空闲周期(直到 CPU 的温度/功率降至阈值以下). 这将允许将热 CPU 保持在睡眠状态, 直到我们看到温度 / 功率的提高. 如果我们将空闲持续时间设置为一个大值或具有 100% 的空闲注入率, 则空闲注入 RT 线程会受到 RT 节流的影响. 这导致 CPU 退出睡眠状态并消耗一些电力. 为了解决这一限制, 我们提出了一种解决方案, 在空闲注入线程运行时禁用 RT 节流. 我们通过不计算空闲注入线程的运行时来实现这一点. | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20240410045417.3048209-1-quic_atulpant@quicinc.com) |



@@ -6544,12 +6557,12 @@ c. 在多个进程之间共享 (例如进程会话).
 ## 10.3 IPC
 -------

-### 10.3.1 Continuation
+### 10.3.1 Continuation/Activation
 -------

 [User-level Real-Time Network System on Microkernel-based Operating Systems]()

-早在 1991 年, Richard P. Draves 等开发者就使用 Continuation 机制优化了内部线程和进程间 RPC, 从而改进 Mach 3.0 操作系统的性能. 与以前版本的 Mach 3.0 相比, 我们的新系统每线程占用的空间减少了 85%. 跨地址空间远程过程调用的执行速度提高了 14%. 异常处理运行速度提高了 60% 以上. 参见 ACM 论文 [Using Continuations to Implement Thread Management and Communication in Operating Systems](https://dl.acm.org/doi/10.1145/121132.121155) 以及 [User-level Real-Time Network System on Microkernel-based Operating Systems](https://keio.pure.elsevier.com/en/publications/user-level-real-time-network-system-on-microkernel-based-operatin/fingerprints). 随后 IOS XNU-Drawin 的内核集成了 Mach 3.0, 从而继承了这一功能.
+早在 1991 年, Richard P. Draves 等开发者就使用 Continuation 机制优化了内部线程和进程间 RPC, 从而改进 Mach 3.0 操作系统的性能. 与以前版本的 Mach 3.0 相比, 新系统每线程占用的空间减少了 85%. 跨地址空间远程过程调用的执行速度提高了 14%. 异常处理运行速度提高了 60% 以上. 参见 ACM 论文 [Using Continuations to Implement Thread Management and Communication in Operating Systems](https://dl.acm.org/doi/10.1145/121132.121155) 以及 [User-level Real-Time Network System on Microkernel-based Operating Systems](https://keio.pure.elsevier.com/en/publications/user-level-real-time-network-system-on-microkernel-based-operatin/fingerprints). 随后 IOS XNU-Drawin 的内核集成了 Mach 3.0, 从而继承了这一功能.

 以一个 client 向 server IPC 请求数据为例, 当前 linix 上传统的 IPC 需要经历 3 次切换 (包括进程 / 线程切换以及线程的栈切换).

@@ -6816,13 +6829,15 @@ YouTuBe 上 ASPLOS'23 关于 Plugsched 的介绍 [ASPLOS'23 - Session 7C - Effic
 | 调度器 | 描述 |
 |:-----:|:----:|
 | [CacULE CPU Scheduler](https://github.com/hamadmarri/cacule-cpu-scheduler) | 是基于交互性评分机制 (CacULE Interactivity Score) 的 CFS 补丁集. 交互性分数的灵感来自 FreeBSD 的 ULE 调度器, 可以增强系统响应能力 / 延迟. ARCHLINUX 的开发者 ptr1337, 同样移植了 [CacULE Scheduler](https://github.com/ptr1337/linux-cacule), [CachyOS/linux-cachyos](https://github.com/CachyOS/linux-cachyos). 使用 calc_interactivity(), calc_cache_score(), calc_starve_score() 分别计算任务的交互性评分 (Interactivity Score), 缓存亲和性评分 (Cache Score) 以及饥饿评分 (Starve Score), 然后将 CFS 的选取下一个任务机制 pick_next_task_fair 更改为 ULE 的评分机制, 以便选取要运行的下一个任务. |
-| [Task Type(TT) CPU Scheduler](https://github.com/hamadmarri/TT-CPU-Scheduler) | 根据任务的行为检测并识别任务类型, 并根据其类型控制调度. 基于任务类型的好处是允许调度程序进行更多控制, 并选择接下来在 CPU 中运行的最佳任务. 当前有 5 种类型: 实时 (REALTIME), 交互 (INTERACTIVE), 无类型 (NO_TYPE), 计算密集型 (CPU_BOUND), 批处理 (BATCH). 调度器通过 detect_type() 周期性地探测应用的 task_type. |
 | [Baby-CPU-Scheduler](https://github.com/hamadmarri/Baby-CPU-Scheduler) | 一个非常基本, 轻量级但性能非常高的调度器 Basic Scheduler (BS). 可以将其用作 Linux 上的基本调度程序进行学习 |
+| [Task Type(TT) CPU Scheduler](https://github.com/hamadmarri/TT-CPU-Scheduler) | 根据任务的行为检测并识别任务类型, 并根据其类型控制调度. 基于任务类型的好处是允许调度程序进行更多控制, 并选择接下来在 CPU 中运行的最佳任务. 当前有 5 种类型: 实时 (REALTIME), 交互 (INTERACTIVE), 无类型 (NO_TYPE), 计算密集型 (CPU_BOUND), 批处理 (BATCH). 调度器通过 detect_type() 周期性地探测应用的 task_type. |
+| [ECHO(Enhanced CPU Handling Orchestrator) CPU Scheduler](https://github.com/hamadmarri/ECHO-CPU-Scheduler) | 该策略是 SRTF(Shortest Remaining Task Next) 和 RR(Round Robin) 的混合.<br>1. 任务的 estimation 使用了 SRTF, 使用了滑动平均来计算虚拟运行时间, 其中虚拟运行时计算是从 CFS 移植的 (它计算基于任务优先级调整). PICK 时每次选择具有最小估计虚拟运行时的下一个任务<br>2. CPU 上的所有任务都有一个共享配额(默认 35us), 每个任务在每个周期都将获得 `shared_quota/nr_tasks` 的时间片. 一个正在运行的任务的最小切片是 7us, 除非唤醒的任务必须在当前任务之前运行，然后它会抢占它.<br>3. 负载均衡器与 TT 调度器一样, 有微小的变化. CPU0 负责在其他 CPU 之间移动任务, 此外, 默认情况下会启用候选平衡器. 几个调度器的性能对比参见 [hamadmarri/benchmarks](https://github.com/hamadmarri/benchmarks). |
 | [BORE/Burst-Oriented Response Enhancer (BORE) CPU Scheduler](https://github.com/firelzrd/bore-scheduler) | BORE(面向突发的响应增强器) 是 CFS(完全公平调度程序) 的增强版本, CFS 是 Linux 中默认的 CPU 调度程序, 旨在保持 CFS 的高吞吐量性能, 同时在尽可能宽的负载情况下提供对用户输入的更高响应能力. 为了实现这一目标, BORE 为每个单独的任务引入了一个称为 "突发性" 的灵活性维度, 部分偏离了 CFS 固有的 "完全公平" 原则. 延迟是指任务在显式放弃后通过进入睡眠、IO 等待或屈服而消耗的累积 CPU 时间得出的分数. 该分数代表了广泛的时间特征, 从纳秒到数百秒不等, 在不同的任务中有所不同. 参见 [foxhoundsk 的博客](https://hackmd.io/@foxhoundsk/bore-sched) |
 | [MuQss/Multiple run-queues for BFS](https://lore.kernel.org/all/1355591803.23863.3.camel@findus-T530) | [两个非常有意思的适合桌面使用的 Linux task 调度器: BFS 和 MuqSS](https://blog.csdn.net/juS3Ve/article/details/102380529)<br>[操作系统调度算法 5——MuQss, 多队列跳表调度器](https://zhuanlan.zhihu.com/p/373693657), [ckolivas/linux](https://github.com/ckolivas/linux), [CK 的博客](http://ck-hack.blogspot.com). [细说 CFS 与 MuQSS 以及 load-balance](https://blog.csdn.net/qq_23662505/article/details/120220689), [MuQSS_调度器 - The_MuQSS_CPU_scheduler](https://github.com/jiebaomaster/linux-kernel-doc-translate/blob/master/lwn/MuQSS_调度器 - The_MuQSS_CPU_scheduler.md) |



+
 #### 11.2.5.2 User Sensitive Factors for Scheduler
 -------

@@ -7038,7 +7053,19 @@ ECRTS 2020(32nd Euromicro Conference on Real-Time Systems) 上 Daniel 等人发
 ### 12.4.6 Scheduler Behavioural Analysis
 -------

-| 5 | [SystraceParser](https://github.com/Binse-Park/SystraceParser) | [Scheduler Behavioural Testing](https://www.youtube.com/watch?v=I_MZ9XS3_zc&t=7s) |
+| 编号 | 工具 | 描述 | 链接 |
+|:---:|:----:|:---:|:---:|
+| 1 | [SystraceParser](https://github.com/Binse-Park/SystraceParser) | [Scheduler Behavioural Testing](https://www.youtube.com/watch?v=I_MZ9XS3_zc&t=7s) | NA |
+
+
+## 12.5 功耗
+-------
+
+| 编号 | 工具 | 描述 | 链接 |
+|:---:|:----:|:---:|:---:|
+| 1 | Turbostat | [tools/power/x86/turbostat](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/tools/power/x86/turbostat) | [Turbostat Gains New Features & New Hardware Support With Linux 6.10](https://www.phoronix.com/news/Linux-6.10-Turbostat) |
+
+

 ** 引用: **

@@ -665,7 +665,7 @@ cba6167f0adb



+[uksmd](https://codeberg.org/pf-kernel/uksmd) 提供了一个 Userspace KSM helper daemon, [CachyOS](https://github.com/CachyOS/uksmd) 将其用在了自己的发行版中. 守护进程会定期检查用户空间任务列表, 并通知 ksmd kthread 设置相关进程 mm_struct 的 MM_VM_MERGE_ANY 标记, 以自动合并具有相同内容的内存页. 仅处理长期任务. 该机制依赖于 v6.4 [mm: process/cgroup ksm support](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=07115fcc15b4aa5c268fb80b82ad15868a82a285) 以及 [pf-kernel/linux](https://codeberg.org/pf-kernel/linux) 内核提供的 `process_ksm_{enable,disable,status}()` 系统调用;
+
+

-| 日期 | LWN | 翻译 |
-|:---:|:----:|:---:|
-| 2007/04/17 | [An update and future plans for DAMON](https://lwn.net/Articles/973702) | NA |
@@ -86,6 +86,7 @@ systrace, perfetto, drgn, systemtep

 [LWN/A kernel debugger in Python: drgn(https://lwn.net/Articles/789641)
 [LWN: 想用python命令来调试kernel吗？drgn就是了！](https://blog.csdn.net/Linux_Everything/article/details/93270705)
+[pf-kernel/crush](https://codeberg.org/pf-kernel/crush) crush 是一种实验性尝试, 至少部分地使用 Python 和更现代的 drgn 后端重写 crash util.

 *   ControlFlag