description/open_source: update phoronix vs LWN to date 20250515

2026-08-18 00:58:21 +08:00 · 2025-09-19 21:18:33 +08:00
parent 065558971f
commit 4e5b8ab0c8
8 changed files with 185 additions and 70 deletions
@@ -98,6 +98,9 @@ Apple [专利号-WO2021US19353-Apple-ON-DEMAND MEMORY ALLOCATION](https://xueshu
 ## 5.1 竞赛
 -------

+
+[亦安的数字小站--CBP2025分支预测器冠军](https://mp.weixin.qq.com/s/AK69HoXs4Xhr9ILxKjcOew?poc_token=HAhUnWij9lMWeaJK7C3mUZFNXE0x3Yu1xKSuEc-l)
+
 | 竞赛 | 描述 |
 |:---:|:----:|
 | [Data Prefetching Championship](https://dpc3.compas.cs.stonybrook.edu) | 数据预取锦标赛, 目标是在一个通用框架中比较不同的数据预取算法. L1、L2 和 L3 数据缓存的预取器必须在竞争规则中指定的固定存储预算内实施. 参赛作品将根据组委会提供的框架在一系列基准上的表现进行评估. [3rd 属于](https://dpc3.compas.cs.stonybrook.edu) |
@@ -83,6 +83,9 @@ blogexcerpt: 虚拟化 & KVM 子系统

 [eBPF - Unleash the Linux kernel](https://aymanace2049.hashnode.dev/ebpf-unleash-the-linux-kernel)

+
+[eBPF 进阶: 内核新特性进展一览](https://ebpf.top/post/ebpf_and_kernel_feature/)
+
 # 2 工作流程
 -------

@@ -582,7 +582,7 @@ bperf 试图通过允许多个 "周期" 或 "指令" 的 perf_event (在不同
 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:---:|:----:|:---:|:----:|:---------:|:----:|
 | 2025/02/03 | Dmitry Vyukov <dvyukov@google.com> | [perf report: Add latency and parallelism profiling](https://lore.kernel.org/all/cover.1738592865.git.dvyukov@google.com) | [phoronix, 2025/03/31, Linux 6.15 Perf Tooling Introduces New Support For Latency Profiling](https://www.phoronix.com/news/Linux-6.15-Perf-Tools-Latency) | v4 ☐☑✓ | [LORE v4,0/8](https://lore.kernel.org/all/cover.1738592865.git.dvyukov@google.com) |
-| 2024/11/22 | Swapnil Sapkal <swapnil.sapkal@amd.com> | [perf sched: Introduce stats tool](https://lore.kernel.org/all/20241122084452.1064968-1-swapnil.sapkal@amd.com) | 目标是为 perf sched 引入一个新的统计工具 perf sched stats, 用于更高效地分析调度器行为, 尤其是在长时间运行或调度密集型工作负载下.<br>1. 问题" 现有的 perf sched record 工具虽然功能强大, 但在长时间运行或调度密集型工作负载下, 会产生大量数据(例如在高核心数服务器上运行 hackbench 时, 生成的 perf.data 文件可能达到 56GB), 并且解析和写入这些数据需要很长时间(约 137 分钟), 这使得其在实际使用中变得不切实际.<br>2. 目标: 通过引入 perf sched stats 工具, 提供一种更轻量级的解决方案. 该工具通过在工作负载运行前后对 `/proc/schedstat` 文件进行快照, 几乎不对工作负载运行产生干扰, 并且解析和保存数据的时间非常短, 生成的 perf.data 文件也更小.<br>3. 实现了 `perf sched stats record/report/diff` 子命令.<br>报告格式: perf sched stats report 会输出详细的调度统计信息, 包括 CPU 调度统计、负载均衡统计、任务唤醒统计等. 报告中还包括字段描述、总运行时间、CPU 调度统计、负载均衡统计等.<br>差分报告: perf sched stats diff 可以比较两次运行之间的差异, 显示字段的变化百分比和平均 jiffies 间隔.<br>实时模式: 实时模式：perf sched stats 支持实时模式, 类似于 perf stat, 可以实时输出调度统计信息. | v2 ☐☑✓ | [LORE v2,0/6](https://lore.kernel.org/all/20241122084452.1064968-1-swapnil.sapkal@amd.com)<br>*-*-*-*-*-*-*-* <br>[LORE v3,0/8](https://lore.kernel.org/all/20250311120230.61774-1-swapnil.sapkal@amd.com) |
+| 2024/11/22 | Swapnil Sapkal <swapnil.sapkal@amd.com> | [perf sched: Introduce stats tool](https://lore.kernel.org/all/20241122084452.1064968-1-swapnil.sapkal@amd.com) | 目标是为 perf sched 引入一个新的统计工具 perf sched stats, 用于更高效地分析调度器行为, 尤其是在长时间运行或调度密集型工作负载下.<br>1. 问题" 现有的 perf sched record 工具虽然功能强大, 但在长时间运行或调度密集型工作负载下, 会产生大量数据(例如在高核心数服务器上运行 hackbench 时, 生成的 perf.data 文件可能达到 56GB), 并且解析和写入这些数据需要很长时间(约 137 分钟), 这使得其在实际使用中变得不切实际.<br>2. 目标: 通过引入 perf sched stats 工具, 提供一种更轻量级的解决方案. 该工具通过在工作负载运行前后对 `/proc/schedstat` 文件进行快照, 几乎不对工作负载运行产生干扰, 并且解析和保存数据的时间非常短, 生成的 perf.data 文件也更小.<br>3. 实现了 `perf sched stats record/report/diff` 子命令.<br>报告格式: perf sched stats report 会输出详细的调度统计信息, 包括 CPU 调度统计、负载均衡统计、任务唤醒统计等. 报告中还包括字段描述、总运行时间、CPU 调度统计、负载均衡统计等.<br>差分报告: perf sched stats diff 可以比较两次运行之间的差异, 显示字段的变化百分比和平均 jiffies 间隔.<br>实时模式: 实时模式：perf sched stats 支持实时模式, 类似于 perf stat, 可以实时输出调度统计信息. | v2 ☐☑✓ | [LORE v2,0/6](https://lore.kernel.org/all/20241122084452.1064968-1-swapnil.sapkal@amd.com)<br>*-*-*-*-*-*-*-* <br>[LORE v3,0/8](https://lore.kernel.org/all/20250311120230.61774-1-swapnil.sapkal@amd.com)<br>*-*-*-*-*-*-*-* <br>[LORE v4, 00/11](https://lore.kernel.org/all/20250826051039.2626894-1-swapnil.sapkal@amd.com) |



@@ -1300,7 +1300,8 @@ Fedora 尝试优化 systemd 开机以及重启的时间, 参见 phoronix 报道
 | 2025/05/14 | Gabriele Monaco <gmonaco@redhat.com> | [rv: Add monitors to validate task switch](https://lore.kernel.org/all/20250514084314.57976-1-gmonaco@redhat.com) | 这个补丁集旨在为 Linux 内核的 RV( Runtime Verification) 子系统添加任务切换验证监控器. 核心内容包括: <br>-1. 替换与增强现有监控器: 原有 `tss` 监控器被更全面的 `sts` 替代, 验证调度上下文中的任务切换, 并确保每次调度调用都伴随切换( 包括无效切换) , 同时禁止中断.<br>2. 新增三个监控器:<br>2.1 `nrp`: 验证抢占需设置 `need_resched`, 切换后清除该标志, 包含对嵌套抢占的处理. <br>2.2 `sssw`: 验证任务挂起需设置为可睡眠状态, 切换后需唤醒. <br>2.3 `opid`: 验证唤醒和 `need_resched` 操作需在中断与抢占禁用环境下进行.<br>3. 适配新 tracepoint: 更新 `sched_set_state`等 trace 点以支持新监控逻辑. <br>4. 修复与清理: 包括工具行为修复、SIGTERM 支持、注册错误返回、race condition 重试机制等.  | v2 ☐☑✓ | [2025/05/14, LORE v2, 0/12](https://lore.kernel.org/all/20250514084314.57976-1-gmonaco@redhat.com)<br>*-*-*-*-*-*-*-* <br>[2025/07/15, LORE v3, 00/17](https://lore.kernel.org/all/20250715071434.22508-1-gmonaco@redhat.com)<br>*-*-*-*-*-*-*-* <br>[2025/07/21, LORE v4, 00/14](https://lore.kernel.org/all/20250721082325.71554-1-gmonaco@redhat.com)<br>*-*-*-*-*-*-*-* <br>[2025/07/28, LORE v5, 0/9](https://lore.kernel.org/all/20250728135022.255578-1-gmonaco@redhat.com) |
 | 2025/05/12 | Nam Cao <namcao@linutronix.de> | [RV: Linear temporal logic monitors for RT application](https://lore.kernel.org/all/cover.1747046848.git.namcao@linutronix.de) |旨在为实时( RT) 应用引入基于线性时序逻辑( LTL)的运行时验证( RV) 监控机制. 补丁系列包括以下关键内容: <br>1. LTL监控支持: 新增 LTL 监控模块, 相比原先的确定性自动机, LTL 更简洁直观,适合表达实时规则;<br>2. RT 应用监控器(rtapp): 作为容器封装子监控模块;<br>3.  页错误监控( rtapp_pagefault): 用于检测实时任务中的页错误; <br>4. 睡眠监控( rtapp_sleep): 检测实时线程中可能引起延迟的睡眠行为;<br>5. 配置支持: 允许配置每任务监控器数量, 以同时启用多个监控; <br>6. 文档更新: 补充 LTL 和监控器相关文档; <br>7. 代码结构优化: 整合 dot2k 和 rvgen 工具, 重构模板与类结构, 提升代码可维护性.<br>各版本更新主要修复脚本问题、优化检测逻辑、处理边缘情况, 并调整部分架构的跟踪点. 补丁已覆盖 x86、ARM64 和 RISC-V 架构. | v8 ☐☑✓ | [2025/05/12, LORE v8, 0/22](https://lore.kernel.org/all/cover.1747046848.git.namcao@linutronix.de) |
 | 2025/07/30 | Nam Cao <namcao@linutronix.de> | [rv: LTL per-cpu monitor type and real-time scheduling monitor](https://lore.kernel.org/all/cover.1753879295.git.namcao@linutronix.de) | 邮件提出了一组 5 个补丁, 旨在为 Linux 内核的 Roving( rv) 子系统添加对线性时序逻辑(LTL) 的 per-cpu 监控类型支持, 并新增一个用于验证实时调度(real-time scheduling) 的监控模块. 该系列补丁首先对现有 LTL 监控代码进行重构, 以支持多种监控类型; 随后实现 per-cpu 监控机制, 类似于现有的确定性自动机监控. 此外, 补丁还引入了新的 trace point 用于实时任务的入队与出队事件, 并通过 rvgen 工具生成LTL 监控代码. 最终新增的 rts 监控模块可检测实时调度行为是否符合预期. | v1 ☐☑✓ | [2025/07/30, LORE v1, 0/5](https://lore.kernel.org/all/cover.1753879295.git.namcao@linutronix.de) |
-| 2025/07/23 | Gabriele Monaco <gmonaco@redhat.com> | [tools/verification: Improvements to rv and rvgen](https://lore.kernel.org/all/20250723161240.194860-1-gmonaco@redhat.com) | 改进 Linux 内核中的 rv 和 rvgen 验证工具. 主要内容包括: <br>1. 修复 rv 工具在使用 -s 选项时跳过 idle 任务的问题;<br>2. 增加 rv 对 SIGTERM 信号的优雅终止处理; <br>3. 修改 dot2c 脚本避免生成超过 100 列的代码行; <br>4. 调整 RV Kconfig 文件中嵌套监控模块的顺序; <br>5. 在 DA 监控初始化失败时返回正确错误码, 而非 0. | v1 ☐☑✓ | [2025/07/23, LORE v1, 0/5](https://lore.kernel.org/all/20250723161240.194860-1-gmonaco@redhat.com) |
+| 2025/07/23 | Gabriele Monaco <gmonaco@redhat.com> | [tools/verification: Improvements to rv and rvgen](https://lore.kernel.org/all/20250723161240.194860-1-gmonaco@redhat.com) | 改进 Linux 内核中的 rv 和 rvgen 验证工具. 主要内容包括: <br>1. 修复 rv 工具在使用 -s 选项时跳过 idle 任务的问题;<br>2. 增加 rv 对 SIGTERM 信号的优雅终止处理; <br>3. 修改 dot2c 脚本避免生成超过 100 列的代码行; <br>4. 调整 RV Kconfig 文件中嵌套监控模块的顺序; <br>5. 在 DA 监控初始化失败时返回正确错误码, 而非 0. | v1 ☐☑✓ | [2025/07/23, LORE v1, 0/5](https://lore.kernel.org/all/20250723161240.194860-1-gmonaco@redhat.com)<br>*-*-*-*-*-*-*-* <br>[2025/08/06, LORE v2, 0/5](https://lore.kernel.org/all/cover.1754466623.git.namcao@linutronix.de)<br>*-*-*-*-*-*-*-* <br>[2025/08/11, LORE v3, 0/5](https://lore.kernel.org/all/cover.1754900299.git.namcao@linutronix.de) |
+| 2025/08/14 | Gabriele Monaco <gmonaco@redhat.com> | [rv: Add Hybrid Automata monitor type, per-object and deadline monitors](https://lore.kernel.org/all/20250814150809.140739-1-gmonaco@redhat.com) | 改进 Linux 内核中的 RV( Runtime Verification) 监控功能, 目标是增强内核运行时验证能力, 提升调度与实时性监控的准确性. 核心内容包括: <br>1. 混合自动机(Hybrid Automata) 监控类型: 扩展确定性自动机, 支持环境变量约束判断, 适用于定时自动机场景. <br>2. 对象级监控(Per-object Monitors): 支持为任意对象(如任务) 创建监控实例, 通过 ID 索引存储监控数据. <br>3. 期限(Deadline)监控集合: 新增 throttle 和 nomiss 监控模块, 用于验证 deadline 调度器的时间行为. <br>4.  对 da_monitor 进行宏清理与重构, 提升代码可维护性. <br>5.  多处文档更新与 rvgen 工具链改进, 支持新监控类型的生成与集成. | v1 ☐☑✓ | [2025/08/14, LORE v1, 0/17](https://lore.kernel.org/all/20250814150809.140739-1-gmonaco@redhat.com) |


 # 21 新语言支持
@@ -494,8 +494,8 @@ Proxy Execution 是一种通用形式的优先级继承机制, 它旨在解决
 | 2024/05/06 | John Stultz <jstultz@google.com> | [Preparatory changes for Proxy Execution](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=af0c8b2bf67b25756f27644936e74fd9a6273bd2) | Proxy Execution 是一种通用的优先级继承机制的实现方法, 用于解决优先级反转问题和其他类似的问题. 这些预备补丁的目的是为后续更复杂的 Proxy Execution 相关补丁打下基础.<br>在发送第 7 版 Proxy Execution 补丁集时, John Stultz 收到了反馈, 指出补丁集变得过于庞大难以审查. 因此, 根据 Qais Yousef 的建议, 他决定将补丁集分为两部分：一部分是预备性的更改, 另一部分是更复杂的功能实现. 参见 [phoronix, 2024/10/18, Linux 6.13 Poised To Land Prep Patches Working Toward Proxy Execution](https://www.phoronix.com/news/Linux-6.13-Prep-For-Proxy-Exec). | v10 ☐☑✓ v6.13-rc1 | [2024/02/24, LORE v8,0/7](https://lore.kernel.org/all/20240224001153.2584030-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/04/01, LORE v9,0/7](https://lore.kernel.org/all/20240401234439.834544-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[LORE v10,0/7](https://lore.kernel.org/all/20240507045450.895430-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/07/09, LORE v11,0/7](https://lore.kernel.org/all/20240709203213.799070-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/08/13, LORE v12,0/7](https://lore.kernel.org/all/20240813235736.1744280-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/08/29, RESEND, LORE v12,0/7](https://lore.kernel.org/all/20240829225212.6042-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/10/09, RESEND x3, LORE v12,0/7](https://lore.kernel.org/all/20241009235352.1614323-1-jstultz@google.com) |
 | 2024/02/02 | Metin Kaya <metin.kaya@arm.com> | [sched: Add trace events for Proxy Execution (PE)](https://lore.kernel.org/all/20240202083338.1328060-1-metin.kaya@arm.com) | 添加 `sched_[start，finish]_task_selection` 跟踪事件以测量 PE 补丁在任务选择中的延迟. 此外, 在 PE 中引入有趣事件的跟踪事件:<br>1. sched_pe_enque_sleeping_task: 一个任务在睡眠任务(互斥体所有者)的等待队列中排队.<br>2. sched_pe_cross_mote_cpu: 依赖链跨远程 cpu.<br>3. sched_pe_task_is_migration: 互斥所有者任务迁移. 可以通过以下命令测试新的跟踪事件: `perf record -e sched:sched_start_task_selection -e sched:sched_finish_task_selection -e sched:sched_pe_enque_sleeping_task -e sched:sched_pe_cross_mote_cpu -e sched:sched_pe_task_is_migration`. 此补丁基于 John 的 [Proxy Execution v7 补丁系列](https://lore.kernel.org/linux-kernel/CANDhNCrHd+5twWVNqBAhVLfhMhkiO0KjxXBmwVgaCD4kAyFyWw@mail.gmail.com). | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240202083338.1328060-1-metin.kaya@arm.com) |
 | 2024/11/05 | John Stultz <jstultz@google.com> | [Single CPU Proxy Execution (v13)](https://lore.kernel.org/all/20241106025656.2326794-1-jstultz@google.com) | 这组补丁的主要目的是实现单 CPU 代理执行(Single CPU Proxy Execution)机制, 这是一种通用形式的优先级继承(priority inheritance)方法, 旨在解决某些特定场景下的调度问题.<br>1. 实现单 CPU 代理执行机制, 支持作为构建和运行时选项.<br>2. 重新设计互斥锁的 blocked_on 结构, 以便更好地支持代理执行.<br>3. 处理代理执行带来的假设变化, 确保调度器的正确性.<br>4. 实现初始逻辑, 使锁持有者可以在同一 CPU 上代替等待任务运行.<br>通过这些改动, 调度器在处理某些特定场景下的优先级继承问题时更加高效和灵活, 提高了系统的整体性能和响应速度. 参见 [Paper](https://static.lwn.net/images/conf/rtlws11/papers/proc/p38.pdf) | v13 ☐☑✓ | [LORE v13,0/7](https://lore.kernel.org/all/20241106025656.2326794-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/11/25, LORE v14,0/7](https://lore.kernel.org/all/20241125195204.2374458-1-jstultz@google.com) |
-| 2025/03/12 | John Stultz <jstultz@google.com> | [Single RunQueue Proxy Execution](https://lore.kernel.org/all/20250312221147.1865364-1-jstultz@google.com) | 单运行队列(RunQueue)代理执行(Proxy Execution)的 V15 版本, 这是一种通用的优先级继承机制. <br>1. 问题: 在多核系统中, 当一个高优先级任务被低优先级任务阻塞时, 传统的优先级继承机制可能无法有效解决优先级反转问题, 尤其是在涉及多个运行队列(RunQueue)时.<br>2. 目标: 通过引入代理执行机制, 允许高优先级任务在等待锁时, 将执行权"代理"给其他任务, 从而减少高优先级任务的等待时间, 并提高系统的响应能力.<br>3. 核心思想: 当一个任务被阻塞时, 如果锁的持有者和等待者在同一个运行队列上, 那么可以将执行权"代理"给锁的持有者, 从而避免高优先级任务长时间等待. 参见报道 [phoronix, 2025/07/17, Single RunQueue Proxy Execution Appears Ready For Linux 6.17](http://phoronix.com/news/Linux-6.17-Proxy-Execution). | v15 ☐☑✓ | [2025/03/12, LORE v15,0/7](https://lore.kernel.org/all/20250312221147.1865364-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2025/04/12, LORE v16, 0/7](https://lore.kernel.org/all/20250412060258.3844594-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2025/05/16, LORE v17, 0/8](https://lore.kernel.org/all/20250516031814.1870508-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2025/06/02, LORE RESEND v17, 0/8](https://lore.kernel.org/all/20250602221004.3837674-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2025/06/25, LORE v18, 0/8](https://lore.kernel.org/all/20250625203110.2299275-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2025/07/07, LORE RESEND v18, 0/8](https://lore.kernel.org/all/20250707204409.1028494-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2025/07/12, LORE v19, 0/8](https://ore.kernel.org/all/20250712033407.2383110-1-jstultz@google.com) |
-| 2025/07/22 | John Stultz <jstultz@google.com> | [Donor Migration for Proxy Execution](https://lore.kernel.org/all/20250722070600.3267819-1-jstultz@google.com) | John Stultz 提交了 Proxy Execution 系列补丁的" Donor Migration" 部分(v20), 旨在实现阻塞等待任务的迁移, 以支持跨 CPU 代理执行锁拥有者. 该部分基于 Peter Zijlstra 已合入的 Single-RQ 补丁<br>主要新增了任务阻塞状态的序列化机制、三态 blocked_on_state 支持、平衡回调清理逻辑、以及支持 donor 迁移与链式迁移. 补丁还涉及对锁定机制和调度器的修改, 以防止任务在不合适的 CPU 上运行.<br>待解决问题包括: dl_server 导致的测试挂起、调度扩展( sched_ext) 兼容性、性能回归测试、以及链式迁移对 RT/DL 负载均衡的保证. | v20 ☐☑✓ | [2025/07/22, LORE v20, 0/6](https://lore.kernel.org/all/20250722070600.3267819-1-jstultz@google.com) |
+| 2025/03/12 | John Stultz <jstultz@google.com> | [Single RunQueue Proxy Execution](https://lore.kernel.org/all/20250312221147.1865364-1-jstultz@google.com) | 单运行队列(RunQueue)代理执行(Proxy Execution)的 V15 版本, 这是一种通用的优先级继承机制. <br>1. 问题: 在多核系统中, 当一个高优先级任务被低优先级任务阻塞时, 传统的优先级继承机制可能无法有效解决优先级反转问题, 尤其是在涉及多个运行队列(RunQueue)时.<br>2. 目标: 通过引入代理执行机制, 允许高优先级任务在等待锁时, 将执行权"代理"给其他任务, 从而减少高优先级任务的等待时间, 并提高系统的响应能力.<br>3. 核心思想: 当一个任务被阻塞时, 如果锁的持有者和等待者在同一个运行队列上, 那么可以将执行权"代理"给锁的持有者, 从而避免高优先级任务长时间等待. 参见报道 [phoronix, 2025/07/17, Single RunQueue Proxy Execution Appears Ready For Linux 6.17](http://phoronix.com/news/Linux-6.17-Proxy-Execution). | v15 ☐☑✓ | [2025/03/12, LORE v15,0/7](https://lore.kernel.org/all/20250312221147.1865364-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2025/04/12, LORE v16, 0/7](https://lore.kernel.org/all/20250412060258.3844594-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2025/05/16, LORE v17, 0/8](https://lore.kernel.org/all/20250516031814.1870508-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2025/06/02, LORE RESEND v17, 0/8](https://lore.kernel.org/all/20250602221004.3837674-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2025/06/25, LORE v18, 0/8](https://lore.kernel.org/all/20250625203110.2299275-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2025/07/07, LORE RESEND v18, 0/8](https://lore.kernel.org/all/20250707204409.1028494-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2025/07/12, LORE v19, 0/8](https://lore.kernel.org/all/20250712033407.2383110-1-jstultz@google.com) |
+| 2025/07/22 | John Stultz <jstultz@google.com> | [Donor Migration for Proxy Execution](https://lore.kernel.org/all/20250722070600.3267819-1-jstultz@google.com) | John Stultz 提交了 Proxy Execution 系列补丁的" Donor Migration" 部分(v20), 旨在实现阻塞等待任务的迁移, 以支持跨 CPU 代理执行锁拥有者. 该部分基于 Peter Zijlstra 已合入的 Single-RQ 补丁<br>主要新增了任务阻塞状态的序列化机制、三态 blocked_on_state 支持、平衡回调清理逻辑、以及支持 donor 迁移与链式迁移. 补丁还涉及对锁定机制和调度器的修改, 以防止任务在不合适的 CPU 上运行.<br>待解决问题包括: dl_server 导致的测试挂起、调度扩展( sched_ext) 兼容性、性能回归测试、以及链式迁移对 RT/DL 负载均衡的保证. | v20 ☐☑✓ | [2025/07/22, LORE v20, 0/6](https://lore.kernel.org/all/20250722070600.3267819-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2025/09/04, LORE v21, 0/6](https://lore.kernel.org/all/20250904002201.971268-3-jstultz@google.com) |


 # 12 深入理解并行编程
@@ -554,16 +554,23 @@ SCaLE 21x 上 Alison Chaiken 关于 WorkQueue 的讨论, 参见 [Diagnosing work
 | 2025/06/20 | Frederic Weisbecker <frederic@kernel.org> | [cpuset/isolation: Honour kthreads preferred affinity](https://lore.kernel.org/all/20250620152308.27492-1-frederic@kernel.org) | 这组补丁旨在改进 Linux 内核中 **kthread 的 CPU 亲和性管理**, 使其在 **cpuset 隔离分区变化时仍能尊重预设的亲和性偏好**. 当前在 cpuset 隔离状态变更时, 未绑定的 kthread 可能被错误地调度到非预期的 CPU 上, 导致性能或隔离性问题.<br>补丁集核心更改包括: <br>1. 将 **housekeeping 的 cpumask 管理改为 RCU 指针**, 支持动态更新;<br>2. 在 cpuset 变化时通过 housekeeping 机制通知 kthread 和 workqueue 更新亲和性;<br>3. 整合 isolcpus 和 cpuset 的隔离状态到 HK_TYPE_DOMAIN;<br>4. 为未来支持 cpuset 控制 nohz_full= 配置打下基础.<br5. >此外, 多个子系统( 如 block、net、mm) 增加了对隔离 cpuset 变化的并发保护, 提升了系统稳定性和调度准确性. | v1 ☐☑✓ | [2025/06/20, LORE v1, 0/27](https://lore.kernel.org/all/20250620152308.27492-1-frederic@kernel.org) |


-# 13 Windows NT Synchronization Primitive Driver
+## 12.3 混合自适应锁
+
+### 12.3.1 Windows NT Synchronization Primitive Driver
 -------

-
-
-
 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:---:|:----:|:---:|:----:|:---------:|:----:|
-| 2024/02/14 | Elizabeth Figura <zfigura@codeweavers.com> | [NT synchronization primitive driver](https://lore.kernel.org/all/20240214233645.9273-1-zfigura@codeweavers.com) | 参见 LWN 报道 [Windows NT synchronization primitives for Linux](https://lwn.net/Articles/961884) 以及 phoronix 报道 [Windows NT Synchronization Primitive Driver Updated For The Linux Kernel](https://www.phoronix.com/news/NTSYNC-Linux-Update-February)
- | v1 ☐☑✓ | [2024/02/14 LORE v1,00/31](https://lore.kernel.org/all/20240214233645.9273-1-zfigura@codeweavers.com)<br>*-*-*-*-*-*-*-* <br>[2024/02/19 LORE v2,00/31](https://lore.kernel.org/lkml/20240219223833.95710-1-zfigura@codeweavers.com) |
+| 2024/02/14 | Elizabeth Figura <zfigura@codeweavers.com> | [NT synchronization primitive driver](https://lore.kernel.org/all/20240214233645.9273-1-zfigura@codeweavers.com) | 参见 LWN 报道 [Windows NT synchronization primitives for Linux](https://lwn.net/Articles/961884) 以及 phoronix 报道 [Windows NT Synchronization Primitive Driver Updated For The Linux Kernel](https://www.phoronix.com/news/NTSYNC-Linux-Update-February) | v1 ☐☑✓ | [2024/02/14 LORE v1,00/31](https://lore.kernel.org/all/20240214233645.9273-1-zfigura@codeweavers.com)<br>*-*-*-*-*-*-*-* <br>[2024/02/19 LORE v2,00/31](https://lore.kernel.org/lkml/20240219223833.95710-1-zfigura@codeweavers.com) |
+
+### 12.3.2 自适应锁
+-------
+
+
+| 编号 | 时间 | 论文 | 团队 | 描述 | 链接 |
+|:---:|:----:|:---:|:---:|:----:|:----:|
+|  1  | 2025/09/02 | [FlexGuard: Fast mutual exclusion independent of subscription, SOSP '25]() | INRIA (Paris) 的 Whisper 团队 | NA | NA |
+|  2  |


 <br>
@@ -28,11 +28,11 @@

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

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

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

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

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

@@ -862,7 +862,7 @@ Chang 的 patch set 采用了与之前不同的方法: 允许 cgroup 将一些
 | 2022/12/12 | Peng Zhang <zhangpeng.00@bytedance.com> | [sched: Throttling through task work for cfs bandwidth](https://lore.kernel.org/all/20221212061321.36422-1-zhangpeng.00@bytedance.com) | 若任务占用资源并在内核空间中被限制, 则可能会导致阻塞, 从而造成或者加剧优先级翻转的问题. 这组补丁试图通过在任务返回到用户模式时使用 task_work 来限制任务来解决此问题.<br> 这个补丁使用 task_work 在任务返回到用户空间时将 throttle 的任务出队, 然后在 unthrottle 时再将其入列. 当前能正常工作, 但目前的实现并没有考虑到所有的细节, 比如竞争条件、负载跟踪等. 作者认为这种解决方案的最大缺点是, 在解锁过程中可能有太多的任务需要排队, 从而导致巨大的开销和延迟. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20221212061321.36422-1-zhangpeng.00@bytedance.com) |
 | 2024/02/02 | Valentin Schneider <vschneid@redhat.com> | [sched/fair: Defer CFS throttle to user entry](https://lore.kernel.org/all/20231130161245.3894682-1-vschneid@redhat.com) | Peter 之前再 [Re: [PATCH] sched/fair: Make the BW replenish timer expire in hardirq context for PREEMPT_RT](https://lore.kernel.org/all/20231031160120.GE15024@noisy.programming.kicks-ass.net) 提到 , 对 CFS 任务进行 BW throttle 的时候, 并不在更新运行时统计信息发现 cfs_rq 已经耗尽其配额时, 立即执行 throttle, 而是等待任务即将返回到用户空间时再进行 throttle, 这是非常安全的, 在 PREEMPT_RT 的内核上可以有效地防止内核态优先级翻转, 因为如果它在用户空间中, 则无法持有任何内核内锁. | v1 ☐☑✓ | [2023/11/30, LORE v1,0/2](https://lore.kernel.org/all/20231130161245.3894682-1-vschneid@redhat.com)<br>*-*-*-*-*-*-*-* <br>[2024/02/02, LORE v2,0/5](https://lore.kernel.org/all/20240202080920.3337862-1-vschneid@redhat.com)[2024/07/11, LORE V3,00/10](https://lore.kernel.org/all/20240711130004.2157737-1-vschneid@redhat.com/) |
 | 2025/02/20 | K Prateek Nayak <kprateek.nayak@amd.com> | [sched/fair: Defer CFS throttling to exit to user mode](https://lore.kernel.org/all/20250220093257.9380-1-kprateek.nayak@amd.com) | TODO | v1 ☐☑✓ | [LORE v1,0/22](https://lore.kernel.org/all/20250220093257.9380-1-kprateek.nayak@amd.com) |
-| 2025/03/17 | Aaron Lu <ziqianlu@bytedance.com> | [Defer throttle when task exits to user](https://lore.kernel.org/all/20250313072030.1032893-1-ziqianlu@bytedance.com) | [Valentin Schneider 工作"sched/fair: Defer CFS throttle to user entry"](https://lore.kernel.org/all/20231130161245.3894682-1-vschneid@redhat.com) 的续作. <br>1. 核心思想: 当一个任务的 CFS 配额耗尽时, 不是立即将其节流, 而是延迟到任务退出到用户空间时再进行节流. 这样可以避免任务在内核空间中被阻塞, 从而减少任务挂起的风险.<br> 实现方式: 在 CFS 节流路径中, 为每个任务添加一个任务工作(task work), 以便在任务返回用户空间时执行节流操作.<nr> 在任务返回用户空间时, 任务工作会将任务从运行队列中移除, 并将其添加到 CFS 运行队列的 limbo 列表中, 以便后续恢复.<br> 在 CFS 解除节流路径中, 将 limbo 列表中的任务重新加入运行队列. | v1 ☐☑✓ | [2025/03/17, LORE v1,0/7](https://lore.kernel.org/all/20250313072030.1032893-1-ziqianlu@bytedance.com)<br>*-*-*-*-*-*-*-* <br>[2025/04/09, LORE v2,0/7](https://lore.kernel.org/lkml/20250409120746.635476-1-ziqianlu@bytedance.com)<br>*-*-*-*-*-*-*-* <br>[2025/05/20, LORE v3, 0/7](https://lore.kernel.org/all/20250520104110.3673059-1-ziqianlu@bytedance.com)<br>*-*-*-*-*-*-*-* <br>[2025/07/15, LORE v3, 0/5](https://lore.kernel.org/all/20250715071658.267-1-ziqianlu@bytedance.com) |
+| 2025/03/17 | Aaron Lu <ziqianlu@bytedance.com> | [Defer throttle when task exits to user](https://lore.kernel.org/all/20250313072030.1032893-1-ziqianlu@bytedance.com) | [Valentin Schneider 工作"sched/fair: Defer CFS throttle to user entry"](https://lore.kernel.org/all/20231130161245.3894682-1-vschneid@redhat.com) 的续作. <br>1. 核心思想: 当一个任务的 CFS 配额耗尽时, 不是立即将其节流, 而是延迟到任务退出到用户空间时再进行节流. 这样可以避免任务在内核空间中被阻塞, 从而减少任务挂起的风险.<br> 实现方式: 在 CFS 节流路径中, 为每个任务添加一个任务工作(task work), 以便在任务返回用户空间时执行节流操作.<nr> 在任务返回用户空间时, 任务工作会将任务从运行队列中移除, 并将其添加到 CFS 运行队列的 limbo 列表中, 以便后续恢复.<br> 在 CFS 解除节流路径中, 将 limbo 列表中的任务重新加入运行队列. 参见 phoronix 报道 [phoronix, 2025/09/03, Linux Scheduler Adapted For A Latency Win & Avoiding An RT Deadlock](https://www.phoronix.com/news/Linux-CFS-Defer-Throttle) | v1 ☐☑✓ | [2025/03/17, LORE v1,0/7](https://lore.kernel.org/all/20250313072030.1032893-1-ziqianlu@bytedance.com)<br>*-*-*-*-*-*-*-* <br>[2025/04/09, LORE v2,0/7](https://lore.kernel.org/lkml/20250409120746.635476-1-ziqianlu@bytedance.com)<br>*-*-*-*-*-*-*-* <br>[2025/05/20, LORE v3, 0/7](https://lore.kernel.org/all/20250520104110.3673059-1-ziqianlu@bytedance.com)<br>*-*-*-*-*-*-*-* <br>[2025/07/15, LORE v3, 0/5](https://lore.kernel.org/all/20250715071658.267-1-ziqianlu@bytedance.com) |


 ### 2.1.4 leaf_cfs_rq
@@ -2729,6 +2729,15 @@ void nohz_run_idle_balance(int cpu)
 | 2020/05/26 | Peter Zijlstra <peterz@infradead.org> | [Fix the scheduler-IPI mess.](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=19a1f5ec699954d21be10f74ff71c2a7079e99ad) | TODO | v1 ☐☑✓ | [LORE v1,0/7](https://lore.kernel.org/all/20200526161057.531933155@infradead.org) |


+#### 4.5.7.3 Distributed nohz idle CPU tracking
+-------
+
+
+
+| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:---:|:----:|:---:|:----:|:---------:|:----:|
+| 2025/09/04 | K Prateek Nayak <kprateek.nayak@amd.com> | [sched/fair: Distributed nohz idle CPU tracking for idle load balancing](https://lore.kernel.org/all/20250904041516.3046-1-kprateek.nayak@amd.com) | 旨在改进 Linux 调度器中 nohz idle CPU 的跟踪机制, 以支持更高效的空闲负载均衡. 目前的全局 cpumask 和 idle 状态跟踪机制在频繁访问时存在性能瓶颈, 补丁将跟踪机制分布化, 基于 sd_llc_shared 拓扑结构维护每个 LLC 的 idle 状态和 cpumask.<br>主要改进包括: <br>- 实现 per-LLC 的 nohz 跟踪和全局" nohz_shared_list" 管理;<br>- 减少原子操作, 仅在 idle 状态边界变化时更新全局计数;<br>- 支持热插拔和 cpuset 的状态修正;<br>- 逐步替代现有全局变量 "nohz. idle_cpus_mask"  和 "nohz. nr_cpus".<br> 性能测试显示, 在部分场景下调度性能有所提升, 但部分测试中也出现延迟上升等回归问题, 作者指出这可能与运行环境噪声有关. <br><br>总结: 本 RFC 提出了一种分布式 nohz idle 跟踪机制, 旨在减少全局竞争, 提升调度性能, 适用于未来基于 push 的负载均衡机制.  | v1 ☐☑✓ | [2025/09/04, LORE v1, 0/19](https://lore.kernel.org/all/20250904041516.3046-1-kprateek.nayak@amd.com) |
+

 ## 4.6 自动 NUMA 均衡 (Automatic NUMA balancing)
 -------
@@ -3854,7 +3863,7 @@ v3.0 [commit 317f394160e9 ("sched: Move the second half of ttwu() to the remote
 | 2022/05/13 | Tianchen Ding <dtcccc@linux.alibaba.com> | [sched: Queue task on wakelist in the same llc if the wakee cpu is idle](https://lore.kernel.org/all/20220513062427.2375743-1-dtcccc@linux.alibaba.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20220513062427.2375743-1-dtcccc@linux.alibaba.com)<br>*-*-*-*-*-*-*-* <br>[LORE v2](https://lore.kernel.org/lkml/20220527090544.527411-1-dtcccc@linux.alibaba.com) |
 | 2021/08/15 | Thomas Gleixner <tglx@linutronix.de> | [sched: Split out the wakeup state check](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43295d73adc8d3780e9f34206663e336678aaff8) | [locking, sched: The PREEMPT-RT locking infrastructure](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=026659b9774e4c586baeb457557fcfc4e0ad144b) 的其中一个补丁. | v5 ☑✓ 5.15-rc1 | [LORE v5,03/72](https://lore.kernel.org/all/20210815211302.088945085@linutronix.de) |

-### 4.7.1.3 lockless wake-queues
+#### 4.7.1.3 lockless wake-queues
 -------

 [commit 7675104990ed ("sched: Implement lockless wake-queues")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7675104990ed255b9315a82ae827ff312a2a88a2) 实现了一个轻量级的 lockless wake-queues(WAKE_Q) 机制. [Linux 中的 wake_q_add () 函数](https://coderatwork.cn/posts/linux-wake_q_add)
@@ -3957,6 +3966,12 @@ Mike Galbraith 调试发现, 触发这个问题的原因是因为 wake_affine_we
 | 慢路径 find_idlest_cpu() | 通过搜索 SD_BALANCE_FORK 或 SD_BALANCE_EXEC 标记的最高 sched_domain 来唤醒处于最空闲状态的空闲 CPU 上的任务. |


+| 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:----:|:----:|:---:|:---:|:----------:|:----:|
+| 2025/08/12 | yaozhenguo <yaozhenguo1@gmail.com> | [sched/fair: Introduce WAKEUP_SELECT_IDLE sched feature](https://lore.kernel.org/all/20250812101650.44110-1-yaozhenguo@jd.com) | 邮件提出了一项新的调度特性 `WAKEUP_SELECT_IDLE`, 用于控制是否将唤醒任务调度到仅运行 `SCHED_IDLE` 任务的 CPU 上. 当前在云主机环境中, 管理监控软件通常设为 `SCHED_IDLE` 优先级, 但若 vCPU 唤醒持续选择此类 CPU, 可能导致监控服务无法及时执行, 即使系统中存在真正空闲的 CPU. 作者通过新增配置开关, 允许用户通过 debugfs 控制调度行为, 从而避免低优先级任务过度延迟关键服务. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250812101650.44110-1-yaozhenguo@jd.com) |
+
+
+
 ### 4.7.4 Cache-to-Cache Latency
 -------

@@ -3986,16 +4001,23 @@ wojiush| 2023/03/27 | Aaron Lu <aaron.lu@intel.com> | [sched/fair: Make tg->load
 | 2023/09/11 | Chen Yu <yu.c.chen@intel.com> | [Makes it easier for the wakee to choose previous CPU](https://lore.kernel.org/all/cover.1694397335.git.yu.c.chen@intel.com) | 当任务 P 被唤醒时, 调度程序会利用 select_idle_sibling() 为其寻找空闲的 CPU. 因为它可以提高缓存的本地性. 但在很多情况下前一个 CPU 已被其他唤醒器占用, 因此 P 必须寻找另一个空闲的 CPU. 在保持调度器工作保护的同时, 引入任务迁移可以使许多工作负载受益. 受 Mathieu 关于限制任务迁移率 [sched/eevdf: Rate limit task migration](https://lore.kernel.org/lkml/20230905171105.1005672-1-mathieu.desnoyers@efficios.com) 的启发，本补丁考虑了任务的平均睡眠时间. 如果任务的睡眠时间较短, 则会将其上一个 CPU 标记为缓存热区, 并持续一小段时间. 在标记期间, 其他唤醒者不得使用该空闲 CPU, 直到超时为止. 之后, 如果该任务再次被唤醒, 它就会发现之前的 CPU 仍处于空闲状态, 并在 select_idle_sibling() 中选择它. | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/cover.1694397335.git.yu.c.chen@intel.com) |


-### 4.7.5 sync wakeup
+### 4.7.5 特殊情况
 -------

-### 4.7.5 child runs first
+#### 4.7.5.1 child runs first
 -------

 | 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:----:|:----:|:---:|:---:|:----------:|:----:|
 | 2021/09/12 | Yang Yang <yang.yang29@zte.com.cn>/<cgel.zte@gmail.com> | [sched: Add a new version sysctl to control child runs first](https://lkml.org/lkml/2021/9/12/4) | 旧版本的 sysctl_sched_child_runs_first 有一些问题. 首先, 它允许设置值大于 1, 这是不必要的. 其次, 它没有遵循能力法则. 第三, 它没有使用 static key. 这个新版本修复了所有问题. | v1 ☐ | [LKML](https://lkml.org/lkml/2021/9/12/4) |

+#### 4.7.5.2 yield
+-------
+
+| 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:----:|:----:|:---:|:---:|:----------:|:----:|
+| 2025/08/08 | Kuba Piecuch <jpiecuch@google.com> | [sched: add ability to throttle sched_yield() calls to reduce contention](https://lore.kernel.org/all/20250808200250.2016584-1-jpiecuch@google.com) | 该邮件由 Kuba Piecuch 提出, 旨在解决多线程程序中频繁调用 `sched_yield() ` 引发的性能争用问题. 问题源于 `sched_yield() ` 会触发 `update_curr() `, 进而导致多个线程对共享变量 `cputime_atomic. sum_exec_runtime` 进行频繁原子操作, 引发 cacheline 争用, Google 曾因此出现整机锁死情况. <br><br> 为此, 作者提出通过新增 `yield_interval_ns` 调试接口, 限制线程在指定时间间隔内最多执行一次 `sched_yield() `, 以缓解争用. 默认值为 0, 关闭限流功能. 性能测试表明, 开启限流后, 原子操作引发的 CPU 占比从 80% 降至 1-2%, 但 `sched_yield() ` 调用次数减少约 60%. <br><br> 作者还对比了其他方案, 最终认为当前补丁改动最小、收益最高. 补丁集中包含 3 项修改, 主要涉及调度类接口调整与限流功能实现.  | v1 ☐☑✓ | [2025/08/08, LORE v1, 0/3](https://lore.kernel.org/all/20250808200250.2016584-1-jpiecuch@google.com) |
+


 ## 4.8 Group Balancer