description/open_source: update phoronix vs LWN to date 20250330

2026-11-15 13:04:18 +08:00 · 2025-06-30 14:58:16 +08:00
1 parent 909b4ae945
commit 6542529cfb
@@ -165,7 +165,7 @@ blogexcerpt: 虚拟化 & KVM 子系统
 |  3  | 2025/03/06 | GIDD | NA | [Generalized Interpolating Discrete Diffusion](https://arxiv.org/abs/2503.04482), [AI自我纠错，Diffusion超越自回归！质量提升55%，已达理论证据下界](https://mp.weixin.qq.com/s/pu2NmYixfwZq94qFDBZ_YQ) |
 |  4  | 2025/03/12 | [BD3-LMs](https://m-arriola.com/bd3lms/) | Cornell Tech | 论文 [Block Diffusion: Interpolating Between Autoregressive and Diffusion Language Models](https://arxiv.org/abs/2503.09573), [爆火Block Diffusion引发LLM架构变革？自回归+扩散模型完美结合 | ICLR 2025](https://zhuanlan.zhihu.com/p/32576344984) |
 |  5  | 2025/04/02 | [Dream-7B](https://hkunlp.github.io/blog/2025/dream/) | University of Hong Kong<br>Huawei Noah’s Ark Lab | 参见 GitHub [HKUNLP/Dream](https://github.com/HKUNLP/Dream) |
-|  6  | 2025/04/12 | D1 | UCLA<BR>Meta AI | [dllm-reasoning/d1](https://github.com/dllm-reasoning/d1), 参见论文 [d1: Scaling Reasoning in Diffusion Large Language Models via Reinforcement Learning](https://dllm-reasoning.github.io/) |
+|  6  | 2025/04/12 | [D1](https://dllm-reasoning.github.io) | UCLA<BR>Meta AI | [dllm-reasoning/d1](https://github.com/dllm-reasoning/d1), 参见论文 [d1: Scaling Reasoning in Diffusion Large Language Models via Reinforcement Learning](https://arxiv.org/abs/2504.12216) |
 |  7  | 2024/10/24 | [SMDM](https://github.com/ML-GSAI/SMDM) | ML-GSAI | [Scaling up Masked Diffusion Models on Text](https://arxiv.org/abs/2410.18514) |


@@ -189,6 +189,8 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad

 [OLMoE](https://github.com/allenai/OLMoE)

+[Mixture of Lookup Experts](https://arxiv.org/abs/2503.15798) 由于 MoE 会动态选择 experts, 因此所有 EA 都需要加载到 VRAM 中. 它们的大参数大小仍然限制了部署, 而卸载(仅在需要时将专家加载到 VRAM)会显著增加推理延迟. 为了解决这个问题, 我们提出了 Mix of Lookup Experts(MoLE), 这是一种新的 MoE 架构, 在通信和 VRAM 使用方面都非常高效. 在 MoLE 中, 专家在训练期间是前馈网络(FFN), 将嵌入层的输出作为输入. 在推理之前, 这些专家可以重新参数化为查找表(LUT), 该查找表根据输入 ID 检索专家输出, 并卸载到存储设备. 因此, 我们不需要在推理过程中执行专家计算. 相反, 我们根据输入 ID 直接检索 EA 的计算结果并将其加载到 VRAM 中, 因此由此产生的通信开销可以忽略不计. 实验表明, 在相同的 FLOPs 和 VRAM 使用量下, MoLE 实现了与密集模型相当的推理速度, 并且在专家卸载的情况下明显快于 MoE, 同时保持与 MoE 相当的性能.
+
 ### 2.2.2 稀疏化
 -------

@@ -437,8 +439,8 @@ ARM-software/ComputeLibrary
 | 10  | [PyTorch 可视化工具介绍](https://zhuanlan.zhihu.com/p/658596017) | NA | PyTorch 可视化工具介绍. |
 | 11  | [attentionmech/mav](https://github.com/attentionmech/mav) | attentionmech | 一款可视化大模型内部工作原理的工具, 帮助用户更好的理解和分析模型在生成文本时的内部魔偶快, 包括注意力分布, 预测概率等. 参见 [知识图谱 + 知识库 RAG 项目 Yuxi-Know 及大模型推理内部可视化工具 OpenMAV 实现拆解](https://zhuanlan.zhihu.com/p/1893668626810270690) |
 | 12  | Logit Lens | NA | [2023/03/14, Eliciting Latent Predictions from Transformers with the Tuned Lens](https://arxiv.org/abs/2303.08112), [AlignmentResearch/tuned-lens](https://github.com/AlignmentResearch/tuned-lens) 和 [2025/02/24, LogitLens4LLMs: Extending Logit Lens Analysis to Modern Large Language Models](https://arxiv.org/abs/2503.11667), [zhenyu-02/LogitLens4LLMs](https://github.com/zhenyu-02/LogitLens4LLMs), 其他 [SullivanCastro/Logit-Lens](https://github.com/SullivanCastro/Logit-Lens), [arnab-api/Logit-Lens-Interpreting-GPT-2](https://github.com/arnab-api/Logit-Lens-Interpreting-GPT-2), [msakarvadia/Attentionlens](https://github.com/msakarvadia/Attentionlens) |
-| 13  | [](https://github.com/ZongqianLi/ReasonGraph) | NA | [ReasonGraph: Visualisation of Reasoning Paths](https://arxiv.org/abs/2503.03979) |
-
+| 13  | [ReasonGraph](https://github.com/ZongqianLi/ReasonGraph) | NA | [ReasonGraph: Visualisation of Reasoning Paths](https://arxiv.org/abs/2503.03979) |
+| 14  | [torchvista](https://github.com/sachinhosmani/torchvista) | 可视化交互式工具, 可以直接在 NodeBook 中可视化 PyTroch 模型的前向传播过程. 支持拖拽/缩放等交互, 并且可以在出现错误时进行部分可视化, 用户可直接点击节点查看参数和属性信息. |

 ## 4.3 评测平台
 -------
@@ -491,14 +493,14 @@ ARM-software/ComputeLibrary
 |:---:|:----:|:------:|:---:|:------:|:----:|
 | 2024/03/01 | 综述 | [NiuTrans/ABigSurveyOfLLMs](https://github.com/NiuTrans/ABigSurveyOfLLMs) | [NiuTrans](https://github.com/NiuTrans/ABigSurveyOfLLMs) | [NiuTrans](https://github.com/NiuTrans/ABigSurveyOfLLMs) | 一个关于大语言模型的综合性调研集合, 包含 150 多篇关于 LLM 的调研论文. 这些调研涵盖了 LLM 的各个方面, 包含通用调研, Transformer, 对齐, 提示学习, 上下文学习, 推理链, 提示工程, 数据, 评估, 社会问题, 安全性, 幻觉, 属性, 高效 LLM, 学习方法, 多模态 LLM, 基于知识的 LLM, 检索增强型 LLM, 知识编辑, LLM 扩展, LLM 与工具, LLM 与交互, 长序列 LLM, 以及 LLM 在教育, 法律, 医疗, 游戏, NLP 任务, 软件工程, 推荐系统, 图谱等领域的应用. |
 | 2024/01/16 | 多模态 | [A Survey of Resource-efficient LLM and Multimodal Foundation Models](https://arxiv.org/abs/2401.08092) | Mengwei Xu | [UbiquitousLearning](https://github.com/UbiquitousLearning/Efficient_Foundation_Model_Survey) | 一篇关于资源高效的大模型和多模态基础模型的综述论文. 论文涵盖了算法和系统两个方面的创新, 包括了高校的模型架构, 训练算法, 推理算法和模型压缩等内容. |
-| 2024/04/18 | 效率提升 | [The Efficiency Spectrum of Large Language Models: An Algorithmic Survey](https://arxiv.org/abs/2312.00678) | Tianyu Ding | [tding1](https://github.com/tding1/Efficient-LLM-Survey) | 一篇关于提供大语言模型效率的综合性调查论文, 全面回顾了旨在提高 LLM 效率的算法, 涵盖了扩展定律, 数据利用, 架构创新, 训练和调优策略以及推理计划等. |
-| 2024/05/23 | LLMs | [Efficient Large Language Models: A Survey](https://arxiv.org/abs/2312.03863) | Zhongwei Wan | [AIoT-MLSys-Lab](https://github.com/AIoT-MLSys-Lab/Efficient-LLMs-Survey) | 本文对高效 LLMs 研究的发展进行了系统而全面的回顾, 并将文献整理成由三个主要类别组成的分类法, 从模型中心、数据中心和框架中心的角度涵盖了不同但相互关联的高效 LLMs 主题, 并且从以模型为中心和以数据为中心的角度, 回顾了 LLMs 的算法层面和系统层面的高效技术. 详细介绍了每个分类下的具体技术, 如: 量化, 剪枝, 知识蒸馏, 数据选择, 提示工程等 <br>1. [知乎 -- 黄浴 -- 高效大语言模型：综述](https://zhuanlan.zhihu.com/p/671710012)<br>2. [知乎 -- 磐石 -- 大模型高效推理 I 推理技术框架总结](https://zhuanlan.zhihu.com/p/696850285)<br>3. [知乎 -- 享享学 AI-- 大模型 LLM 微调技术方法汇总！](https://zhuanlan.zhihu.com/p/673675939) |
-| 2024/04/22 | 综述 | [A Survey on Efficient Inference for Large Language Models](https://arxiv.org/abs/2404.14294) | Zixuan Zhou | NA | 1. [如何加速大模型推理？万字综述全面解析大语言模型高效推理技术](https://www.sohu.com/a/790365299_121119001)<br>2. [知乎 -- 罗清雨 -- 大语言模型高效推理综述](https://zhuanlan.zhihu.com/p/707685591) |
+| 2024/04/18 | 效率提升 | [The Efficiency Spectrum of Large Language Models: An Algorithmic Survey](https://arxiv.org/abs/2312.00678) | Tianyu Ding | [tding1](https://github.com/tding1/Efficient-LLM-Survey) | 一篇关于提供大语言模型效率的综合性调查论文, 全面回顾了旨在提高 LLM 效率的算法, 涵盖了扩展定律, 数据利用, 架构创新, 训练和调优策略以及推理计划等. [知乎-无影寺-【LLM/大模型】大语言模型效率谱：算法综述(](https://zhuanlan.zhihu.com/p/671376104) |
+| 2024/04/22 | 效率提升 | [A Survey on Efficient Inference for Large Language Models](https://arxiv.org/abs/2404.14294) | Zixuan Zhou | NA | 1. [如何加速大模型推理？万字综述全面解析大语言模型高效推理技术](https://www.sohu.com/a/790365299_121119001)<br>2. [知乎 -- 罗清雨 -- 大语言模型高效推理综述](https://zhuanlan.zhihu.com/p/707685591)<br>3. [LLM推理加速调研](https://zhuanlan.zhihu.com/p/699776257) |
+| 2024/05/23 | 效率提升 | [Efficient Large Language Models: A Survey](https://arxiv.org/abs/2312.03863) | Zhongwei Wan | [AIoT-MLSys-Lab](https://github.com/AIoT-MLSys-Lab/Efficient-LLMs-Survey) | 本文对高效 LLMs 研究的发展进行了系统而全面的回顾, 并将文献整理成由三个主要类别组成的分类法, 从模型中心、数据中心和框架中心的角度涵盖了不同但相互关联的高效 LLMs 主题, 并且从以模型为中心和以数据为中心的角度, 回顾了 LLMs 的算法层面和系统层面的高效技术. 详细介绍了每个分类下的具体技术, 如: 量化, 剪枝, 知识蒸馏, 数据选择, 提示工程等 <br>1. [知乎 -- 黄浴 -- 高效大语言模型：综述](https://zhuanlan.zhihu.com/p/671710012)<br>2. [知乎 -- 磐石 -- 大模型高效推理 I 推理技术框架总结](https://zhuanlan.zhihu.com/p/696850285)<br>3. [知乎 -- 享享学 AI-- 大模型 LLM 微调技术方法汇总！](https://zhuanlan.zhihu.com/p/673675939)<br>4. [CSDN-rommel rain-Efficient Large Language Models: A Survey](https://blog.csdn.net/qq_52024723/article/details/143415741) |
+| 2024/05/17 | 效率提升<br>多模态 | [Efficient Multimodal Large Language Models: A Survey](https://arxiv.org/abs/2405.10739), [CSDN-星夜Zn-Efficient Multimodal Large Language Models: A Survey (高效多模态大型语言模型综述-全文翻译)](https://blog.csdn.net/qq_29868553/article/details/144163118), [知乎-吕阿华-【MLLM研究综述】《Efficient Multimodal Large Language Models: A Survey》——腾讯最新多模态大模型综述](https://zhuanlan.zhihu.com/p/701495021) |
 | 2023/06/23 | 多模态 | [A Survey on Multimodal Large Language Models](https://arxiv.org/abs/2306.13549) | Shukang Yin | [BradyFU](https://github.com/BradyFU/Awesome-Multimodal-Large-Language-Models) | 本综述中主要介绍了多模态幻觉、多模态上下文学习 (Multimodal InContext Learning，M-ICL)、多模态思维链(Multimodal Chain of Thought，M-CoT) 和 LLM 辅助的视觉推理 (LLM-Aided Visual Reasoning，LAVR) 等. |
 | 2024/07/26 | 模型压缩 | [Comprehensive Study on Performance Evaluation and Optimization of Model Compression: Bridging Traditional Deep Learning and Large Language Models](https://arxiv.org/abs/2407.15904) | Aayush Saxena | [Comprehensive](https://arxiv.org/abs/2407.15904) | 近年来, 深度学习模型在大多数行业都取得了巨大成功. 这些模型的发展还导致模型大小和能源需求增加, 使其难以在低计算设备上的生产环境中进行部署. 全球互联设备数量的增加保证了压缩模型可以轻松部署在本地设备上, 但计算容量和电源可访问性较低. 不同的研究人员提出了广泛的解决方案来减小此类模型的大小和复杂性, 其中突出的是权重量化、参数修剪、网络修剪、低秩表示、权重共享、神经架构搜索、知识蒸馏等. 在这项研究工作中, 我们调查了使用量化和修剪技术进行压缩的各种训练有素的深度学习模型的性能影响. 我们在图像分类、对象检测、语言模型和基于生成模型的问题陈述中使用的常用深度学习模型上实施了量化和剪枝压缩技术. 我们还探讨了各种大型语言模型在量化和低秩适应后的性能. 我们对所有相关问题陈述使用了标准评估指标(模型的大小、准确性和推理时间), 并通过讨论挑战和未来的工作来总结本文. |
 | 2024/06/04 | 投机 | [Unlocking Efficiency in Large Language Model Inference:A Comprehensive Survey of Speculative Decoding](https://arxiv.org/abs/2401.07851) | Heming Xia | [hemingkx/SpeculativeDecodingPapers](https://github.com/hemingkx/SpeculativeDecodingPapers) | [COLING 2025 Tutorial:Speculative Decoding for Efficient LLM Inference](https://speculative-decoding.github.io), [知乎 - LLM 推理加速新范式！推测解码（Speculative Decoding）最新综述](https://zhuanlan.zhihu.com/p/678404136) |

-
 [Mobile Edge Intelligence for Large Language Models: A Contemporary Survey](https://arxiv.org/abs/2407.18921)
 [Edge Intelligence: Architectures, Challenges, and Applications](https://arxiv.org/abs/2003.12172)
 [A Survey on Model Compression for Large Language Models](https://arxiv.org/abs/2308.07633)
@@ -240,6 +240,7 @@ ASYM_PACKING 用于平衡物理核心与 SMT 之间的负载均衡处理 (例如
 |:----:|:----:|:---:|:----:|:---------:|:----:|
 | 2021/09/10 | Ricardo Neri <ricardo.neri-calderon@linux.intel.com> | [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 都存在冲突.<br> 这种拓扑的一个实例是 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 繁忙.<br>1. 首先改善了 SMT 中 sibling cpu 优先级的计算方式, 它将比单个 core 优先级更低.<br>2. 当决定目标 CPU 是否可以从最繁忙的 CPU 提取任务时, 还检查执行负载平衡的 CPU 和最繁忙的候选组的 SMT 同级 CPU 的空闲状态. | v5 ☑ 5.16-rc1 | [PatchWork v1](https://lore.kernel.org/patchwork/cover/1408312)<br>*-*-*-*-*-*-*-* <br>[PatchWork v2](https://lore.kernel.org/patchwork/cover/1413015)<br>*-*-*-*-*-*-*-* <br>[PatchWork v3 0/6](https://lore.kernel.org/patchwork/cover/1428441)<br>*-*-*-*-*-*-*-* <br>[PatchWork v4,0/6](https://lore.kernel.org/patchwork/cover/1474500)<br>*-*-*-*-*-*-*-* <br>[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 <ricardo.neri-calderon@linux.intel.com> | [sched/fair: Avoid unnecessary migrations within SMT domains](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=046a5a95c3b0425cfe79e43021d8ee90c1c4f8c9) | 参见 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)<br>*-*-*-*-*-*-*-* <br>[2022/11/22 LORE v2,0/7](https://lore.kernel.org/lkml/20221122203532.15013-1-ricardo.neri-calderon@linux.intel.com)<br>*-*-*-*-*-*-*-* <br>[2023/02/07 LORE v3,0/10](https://lore.kernel.org/all/20230207045838.11243-1-ricardo.neri-calderon@linux.intel.com) |
+| 2024/10/15 | Yicong Yang <yangyicong@huawei.com> | [Support SMT control on arm64](https://lore.kernel.org/all/20241015021841.35713-1-yangyicong@huawei.com) | TODO | v6 ☐☑✓ | [LORE v6,0/4](https://lore.kernel.org/all/20241015021841.35713-1-yangyicong@huawei.com) |


 #### 1.4.1.4 Intel Thread Director (ITD)
@@ -257,6 +258,7 @@ ASYM_PACKING 用于平衡物理核心与 SMT 之间的负载均衡处理 (例如

 随后发布了 v2, 参见 phoronix 报道 [Intel Advances Linux"IPC Classes"Design To Improve Load Balancing For Hybrid CPUs](https://www.phoronix.com/news/Intel-IPC-Classes-Post-RFC).

+[Evaluation of the Intel Thread Director technology on an Alder Lake processor](https://pmctrack-linux.github.io/assets/papers/apsys22-saez.pdf) 论文评估了 ITD 技术再 Alder Lake 上的任务调度效果, 论文通过实验测试了 ITD 在不同负载场景下的表现, 包括单线程、多线程及混合工作负载. 研究者对比了 Linux 默认调度策略(CFS)与 ITD 增强调度的差异, 并分析了硬件反馈机制对调度决策的影响. 论文使用了 [PMCSched](https://zildj1an.github.io/pmcsched-website) 和 [PMCTrack](https://github.com/jcsaezal/pmctrack) 工具, PMCSched 提供灵活的调度策略实现, PMCTrack 提供细粒度的性能数据, 两者结合帮助作者全面评估 ITD 技术的效果.

 ##### 1.4.1.4.1 Hardware Feedback Interface 支持
 -------
@@ -264,6 +266,10 @@ ASYM_PACKING 用于平衡物理核心与 SMT 之间的负载均衡处理 (例如

 phoronix 上所有关于 HFI 相关的报道 [phoronix, Hardware Feedback Interface Linux & Open-Source News](https://www.phoronix.com/search/Hardware+Feedback+Interface).

+[retrage/intel-hfi](https://github.com/retrage/intel-hfi) 提供了一个 HFI 的建议工具.
+
+[Intel® Thread Director Visualizer](https://www.intel.com/content/www/us/en/download/823315/intel-thread-director-visualizer.html) 这是一个桌面应用程序, 可帮助最终用户可视化 Alder Lake 及以上平台的 CPU 利用率和性能核和 E 核之间的分布.
+
 | 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:----:|:----:|:---:|:----:|:---------:|:----:|
 | 2021/11/06 | Ricardo Neri <ricardo.neri-calderon-AT-linux.intel.com> | [Thermal: Introduce the Hardware Feedback Interface for thermal and performance management](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=bd30cdfd9bd73b68e4977ce7c5540aa7b14c25cd) | 支持 Intel HFI.<br> 英特尔硬件反馈接口 (HFI) 提供系统中每个 CPU 的性能(performance) 和能效 (Energy efficiency) 的信息. 它使用一个在硬件和操作系统之间共享的表. 该表的内容可能由于系统运行条件的变化 (如达到热极限) 或外部因素的作用 (如热设计功率的变化) 而更新.<br>HFI 提供的信息被指定为相对于系统中其他 cpu 的数字、单元较少的能力. 这些功能的范围为 [0-255], 其中更高的数字表示更高的功能. 如果 CPU 的性能效率或能量能力效率为 0, 硬件建议分别出于性能、能量效率或热原因, 不要在该 CPU 上调度任何任务.<br> 内核或用户空间可以使用来自 HFI 的信息来修改任务放置或调整功率限制. 当前这个补丁集中于用户空间. 热通知框架 (thermal notification framework) 被扩展以支持 CPU capacity 的更新. | v1 ☑ 5.18-rc1 | [2021/11/06 LWN](https://lwn.net/Articles/875296)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/7](https://lore.kernel.org/lkml/20211220151438.1196-1-ricardo.neri-calderon@linux.intel.com), [phoronix v2](https://www.phoronix.com/scan.php?page=news_item&px=Intel-HFI-Linux-v2-2021)<br>*-*-*-*-*-*-*-* <br>[PatchWork v5,0/7](https://patchwork.kernel.org/project/linux-pm/cover/20220127193454.12814-1-ricardo.neri-calderon@linux.intel.com), [phoronix v5](https://www.phoronix.com/scan.php?page=news_item&px=Intel-HFI-For-Linux-5.18) |
@@ -317,7 +323,6 @@ hfi_update_work_fn
 | 2024/06/12 | v0.0.4 | 增强了其硬件反馈接口 (HFI) 监视器, 支持对来自被禁止的 CPU 的提示进行 HFI 监视, 支持多种低功耗状态, 支持工作负载类型提示, 并支持在低功耗模式转换期间更改能效偏好(EPP). | [phoronix, 2024/06/12, Intel Low Power Mode Daemon v0.0.4 Released To Optimize Hybrid CPUs On Linux](https://www.phoronix.com/news/Intel-LPMD-Low-Power-0.0.4). |
 | 2024/09/24 | v0.0.7 | 更改之一是新的 "--ignore-platform-check" 选项, 允许覆盖平台检查, 以便守护程序在未经验证的硬件平台上启动. 此新版本中还有 Autotool 构建系统改进和各种修复. | [phoronix, 2024/09/24, Intel's LPMD "Low Power Mode Daemon" Now Identifies As The "Energy Optimizer"](https://www.phoronix.com/news/Intel-LPMD-v0.0.7). |
 | 2024/10/16 | v0.0.8 | 引入工作负载类型代理支持, 支持特定于型号/SKU 的配置文件、英特尔 Meteor Lake P 配置文件和其他更改, 添加对 AC/DC 状态的检测, 还原时遵循电源配置文件守护程序默认 EPP, 引入 MeteorLake-P 平台特定的配置文件. | [phoronix, 2024/10/16, Intel Low Power Mode Daemon v0.0.8 Brings New Features](https://www.phoronix.com/news/Intel-Low-Power-LPMD-0.0.8) |
-| 2024/10/15 | Yicong Yang <yangyicong@huawei.com> | [Support SMT control on arm64](https://lore.kernel.org/all/20241015021841.35713-1-yangyicong@huawei.com) | TODO | v6 ☐☑✓ | [LORE v6,0/4](https://lore.kernel.org/all/20241015021841.35713-1-yangyicong@huawei.com) |


 #### 1.4.1.5 编译器支持
@@ -628,6 +633,9 @@ TLB entry shootdown 常常或多或少的带来一些性能问题.

 2.  IPI 的方式, 需要先由软件 (内核) 识别到哪些 CPU 中包含了这些需要 flush 的 TLB entry, 然后由本地 CPU 通过 IPI 请求的方式, 通知对应的 CPU 进行 shootdown 操作. 这种方式由硬件软件交互完成, 在 CPU 核数比较多, 且 shootdown 请求比较多的时候, 可能造成 TLB entry shootdown 广播风暴, 硬件 (NM) 处理不过来, 造成性能下降. 此时对于单个 task 的 TLB entry 来说, 残留的 CPU 往往是明确且有限的, 通过 IPI 的方式, 给硬件压力反而会小很多, 这时采用 IPI 的方式性能反而会好.

+导致 TLB shootdown 的一个关键因素是内存映射 I/O, 尤其是在 mmap-munmap 周期和页面高速缓存驱逐期间. 通常, 相同的物理页面在逐出后会重新分配给同一进程, 这为作系统提供了降低 TLB 击落频率的机会. 论文 [Skip TLB flushes for reused pages within mmap's](https://arxiv.org/abs/2409.10946) 通过扩展 mmap 功能, 可以避免这些"回收页面"的 TLB shootdown. 在 mmap 系统调用中引入并实施了"快速页面回收"(FPR) 功能. FPR-mmaps 仅在页面退出其回收周期并被分配到其他进程时触发 TLB shootdown, 从而维护安全性. 为了确保使用 FPR-mmap 指针时的一致性, 我们对虚拟内存管理进行了细微的调整, 以避免 ABA 问题.
+
+
 #### 2.2.3.1 TLB Shootdown 于 TLB IPIs Invalid
 -------

@@ -1442,7 +1450,7 @@ AMD-pstate 驱动程序利用 ITMT 体系结构提供的功能和数据结构,
 |:---:|:----:|:---:|:----:|:---------:|:----:|
 | 2023/08/29 | Yogesh Mohan Marmithu | [user queue patches for review](https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29010) | AMD RadeonSI 驱动程序的用户队列允许将作业直接提交到 GPU 硬件, 而无需使用 ioctl 命令通过 AMDGPU 内核驱动程序提交作业, 这可以通过直接向 GPU 硬件提交作业来避免因一些内核驱动程的开销所造成的延迟. 参见 [AMD User Queue Mesa Support Merged For Linux - Submitting Work Directly To The GPU](https://www.phoronix.com/news/Mesa-25.0-AMDGPU-User-Queue) | v5 ☐☑✓ | [LORE v5,0/8](https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29010) |
 | 2024/12/01 | Yonatan Maman <ymaman@nvidia.com> | [GPU Direct RDMA (P2P DMA) for Device Private Pages](https://lore.kernel.org/all/20241201103659.420677-1-ymaman@nvidia.com) | 参见 phoronix 报道 [phoronix, 2024/12/01, NVIDIA's New Linux Patches For GPU Direct RDMA For Device-Private Pages](https://www.phoronix.com/news/NVIDIA-Linux-P2P-DMA-RDMA-Priv) | v1 ☐☑✓ | [LORE v1,0/5](https://lore.kernel.org/all/20241201103659.420677-1-ymaman@nvidia.com) |
-| 2025/01/31 | Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> | [Improve gpu_scheduler trace events + uAPI](https://lore.kernel.org/all/20250131110328.706695-1-pierre-eric.pelloux-prayer@amd.com) | TODO | v7 ☐☑✓ | [LORE v7,0/7](https://lore.kernel.org/all/20250131110328.706695-1-pierre-eric.pelloux-prayer@amd.com)<br>*-*-*-*-*-*-*-* <br>[LORE v8,0/10](https://lore.kernel.org/all/20250320095818.40622-1-pierre-eric.pelloux-prayer@amd.com) |
+| 2025/01/31 | Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> | [Improve gpu_scheduler trace events + uAPI](https://lore.kernel.org/all/20250131110328.706695-1-pierre-eric.pelloux-prayer@amd.com) | TODO | v7 ☐☑✓ | [LORE v7,0/7](https://lore.kernel.org/all/20250131110328.706695-1-pierre-eric.pelloux-prayer@amd.com)<br>*-*-*-*-*-*-*-* <br>[LORE v8,00/10](https://lore.kernel.org/all/20250320095818.40622-1-pierre-eric.pelloux-prayer@amd.com)<br>*-*-*-*-*-*-*-* <br>[LORE v9, 00/10](https://lore.kernel.org/all/20250424083834.15518-1-pierre-eric.pelloux-prayer@amd.com)<br>*-*-*-*-*-*-*-* <br>[LORE v11, 00/10](https://lore.kernel.org/all/20250526125505.2360-1-pierre-eric.pelloux-prayer@amd.com) |
 | 2024/11/28 | Raag Jadav <raag.jadav@intel.com> | [Introduce DRM device wedged event](https://lore.kernel.org/all/20241128153707.1294347-1-raag.jadav@intel.com) | [phoronix, 2025/02/20, Linux Finally Introducing A Standardized Way Of Informing User-Space Over Hung GPUs](https://www.phoronix.com/news/Linux-6.14-Wedged-GPUs-User), [phoronix, 2025/03/01, Linux's New Way Of Informing User-Space Over Hung GPUs May Become More Useful](https://www.phoronix.com/news/Extending-Linux-GPU-Wedge-Event). | v10 ☐☑✓ | [LORE v10,0/4](https://lore.kernel.org/all/20241128153707.1294347-1-raag.jadav@intel.com) |
 | 2025/03/07 | Matthew Auld | [drm/xe/uapi: Use hint for guc to set GT frequency](https://lists.freedesktop.org/archives/intel-xe/2025-January/066028.html) | [phoronix, 2025/03/07, Intel Xe Driver Introducing SVM, EU Stall Sampling & Other New Features For Linux 6.15](https://www.phoronix.com/news/Intel-Xe-SVM-For-Linux-6.15). | v5 ☐☑✓ | [LORE v5](https://lists.freedesktop.org/archives/intel-xe/2025-January/066028.html) |

@@ -546,6 +546,9 @@ bperf 试图通过允许多个 "周期" 或 "指令" 的 perf_event (在不同
 ## 11.10 data type profiling
 -------

+### 11.10.1 data type profiling
+-------
+
 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:---:|:----:|:---:|:----:|:---------:|:----:|
 | 2023/12/12 | Namhyung Kim <namhyung@kernel.org> | [perf tools: Introduce data type profiling](https://lore.kernel.org/all/20231213001323.718046-1-namhyung@kernel.org) | 这个功能可以关联性能监控单元 (PMU) 样本到它们引用的数据类型, 使用 DWARF 调试信息实现. 这个过程不需要对目标程序进行任何修改. 基本思想是使用 DWARF 位置表达式来确定变量的内存访问. 如果有一个样本在某条指令上, 可以使用 DWARF 调试信息来确定这条指令访问的是哪个变量以及它的类型. 使用方法: 使用 perf mem record 命令来收集精确的内存访问样本, 然后使用 perf report 或 perf annotate 来查看结果. 结果可以通过新添加的排序键 'type' 和 'typeoff' 来展示数据类型和字段的名称. 参见 LWN 报道 [LWN, 2023/12/21, Data-type profiling for perf](https://lwn.net/Articles/955709) | v3 ☐☑✓ | [2023/12/12, LORE v3,0/17](https://lore.kernel.org/all/20231213001323.718046-1-namhyung@kernel.org) |
@@ -555,6 +558,15 @@ bperf 试图通过允许多个 "周期" 或 "指令" 的 perf_event (在不同
 | 2025/04/02 | Zecheng Li <zecheng@google.com> | [sched/fair: Reorder scheduling related structs to reduce cache misses](https://lore.kernel.org/all/20250402212904.8866-1-zecheng@google.com) | 主要目标是通过重新排列与调度相关的数据结构(struct cfs_rq 和 struct sched_entity)来提高缓存局部性, 从而减少缓存未命中, 提升 CFS(完全公平调度器)调度相关操作的性能, 尤其是在拥有数百个核心和约 1000 个 cgroup 的服务器上. | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20250402212904.8866-1-zecheng@google.com) |


+### 11.10.2 修改数据排布
+-------
+
+| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:---:|:----:|:---:|:----:|:---------:|:----:|
+| 2025/06/09 | Zecheng Li <zecheng@google.com> | [sched/fair: Optimize cfs_rq and sched_entity allocation for better data locality](https://lore.kernel.org/all/20250609193834.2556866-1-zecheng@google.com) | 旨在优化调度器中 `cfs_rq` 和 `sched_entity` 的内存布局, 以提升数据局部性和缓存效率. 主要优化包括: <br><br>1.  **合并分配**: 对于非根任务组( task group) , 将 `cfs_rq` 与其对应的 `sched_entity` 分配在同一内存区域, 减少指针跳转. <br>2.  **使用 percpu 分配器**: 通过 percpu 分配方式提升 CPU 访问局部性, 减少 LLC( Last Level Cache) 缺失. <br><br>性能测试显示, 在构建的 cgroups 树结构下, AMD 和 Intel 平台 LLC miss 分别减少最多 11. 69% 和 31. 96%, AMD 内核 IPC 提升 25%. 其他基准测试( 如 sysbench、hackbench、ebizzy) 未见明显退化. <br><br>补丁共 3 个, 修改了调度核心、调试、公平调度器及头文件, 删除了 task_group 的 `se` 指针数组, 并改变了内存分配方式.  | v2 ☐☑✓ | [2025/06/09, LORE v2, 0/3](https://lore.kernel.org/all/20250609193834.2556866-1-zecheng@google.com) |
+| 2025/06/02 | Zecheng Li <zecheng@google.com> | [sched/fair: Reorder scheduling related structs to reduce cache misses](https://lore.kernel.org/all/20250602180544.3626909-1-zecheng@google.com) | 旨在通过重排 `struct cfs_rq` 和 `struct sched_entity` 的字段顺序以减少缓存缺失, 提升 CFS 调度性能, 尤其适用于具有大量核心和 cgroup 的服务器环境.   <br><br>重排基于实际工作负载分析, 优化了热点字段的布局, 提升了缓存局部性. 性能测试显示, 在 Intel 和 AMD 平台上, LLC( Last Level Cache) 缺失分别减少了约 17. 6%-21. 37%. 目标函数如 `tg_throttle_down`、`__update_load_avg_cfs_rq` 等的缓存缺失显著下降.   <br><br>虽然应用吞吐量提升不明显( 因调度开销仅占约1%) , 但对大规模 cgroup 层级结构的工作负载具有显著意义. v2 版本新增了缓存对齐宏, 优化了不同缓存行大小平台的内存使用, 并补充了更多基准测试结果.   <br><br>补丁共涉及 4 个文件, 总计 184 插入, 45 删除.  | v2 ☐☑✓ | [2025/06/02, LORE v2, 0/3](https://lore.kernel.org/all/20250602180544.3626909-1-zecheng@google.com) |
+
+
 ## 11.11 能量统计
 -------

@@ -991,6 +1003,9 @@ GCC "-fschedule-insns" 选项允许对指令进行重新排序, 以在所需数
 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:---:|:----:|:---:|:----:|:---------:|:----:|
 | 2023/06/12 | Peter Zijlstra <peterz@infradead.org> | [Scope-based Resource Management](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=7170509cadbb76e5fa7d7b090d2cbdb93d56a2de) | [Scope-based resource management for the kernel](https://lwn.net/Articles/934679) 以及 [Scope-Based Resource Management Infrastructure Merged For Linux 6.5](https://www.phoronix.com/news/Linux-6.5-Scope-Resource-Manage). | v3 ☐☑✓ 6.6-rc1 | [LORE v3,0/57](https://lore.kernel.org/all/20230612090713.652690195@infradead.org) |
+| 2025/06/13 | Jemmy Wong <jemmywong512@gmail.com> | [sched/topology: Add lock guard support](https://lore.kernel.org/all/20250613083709.19071-1-jemmywong512@gmail.com) | 针对 Linux 调度器拓扑(`sched/topology`) 的补丁, 用于添加锁保护(lockguard) 支持, <br>主要更新包括: 将锁保护逻辑移入 `sched_init_domains` 函数内部; <br>用 `sched_global_validate` 函数替代原有的 `do{}while( 0) ` 宏; 该补丁旨在提升调度器在多线程环境下的同步安全性, 确保调度域初始化过程中的并发访问控制. | v2 ☐☑✓ | [2025/06/13, LORE v2, 0/1](https://lore.kernel.org/all/20250613083709.19071-1-jemmywong512@gmail.com) |
+| 2025/06/19 | Jemmy Wong <jemmywong512@gmail.com> | [sched: Add more Scope-based Resource Management Support](https://lore.kernel.org/all/406C7288-E330-46D3-94A6-F42FB828F613@gmail.com) | NA | v1 ☐☑✓ | [2025/06/19, LORE RFC, 00/13](https://lore.kernel.org/all/406C7288-E330-46D3-94A6-F42FB828F613@gmail.com) |
+

 ### 13.13.2 变长数组 (flexible array) 与 `__counted_by`
 -------
@@ -1278,6 +1293,8 @@ Fedora 尝试优化 systemd 开机以及重启的时间, 参见 phoronix 报道
 | 2022/06/16 | Daniel Bristot de Oliveira <bristot@kernel.org> | [The Runtime Verification (RV) interface](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=e88043c0ac16f19960048372dcffc6df7c05c5b8) | 运行时验证 Linux 内核的行为. 运行时验证(RV) 是一种轻量级 (但严格) 的方法, 它补充了经典的穷举验证技术 (如模型检查和定理证明), 并为复杂系统提供了一种更实用的方法. RV 不依赖于系统的细粒度模型 (例如, 重新实现指令级别), 而是通过分析系统实际执行的轨迹, 并将其与系统行为的形式化规范进行比较来工作. RV 使用确定性自动机是一种成熟的方法. | v4 ☐☑✓ 6.0-rc1 | [LORE v4,0/20](https://lore.kernel.org/all/cover.1655368610.git.bristot@kernel.org)<br>*-*-*-*-*-*-*-* <br>[LORE v9,00/16](https://lore.kernel.org/all/cover.1659052063.git.bristot@kernel.org) |
 | 2022/11/11 | Daniel Bristot de Oliveira <bristot@kernel.org> | [verification/rv: Add rv tool](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=afc70ccb962861e068e04c6089827493f5160a0a) | (用户空间)运行时验证工具 rv. 该工具旨在成为内核 rv 监视器的接口, 以及用户空间控制监视器. 该工具接收命令作为第一个参数 <br>1. list 列出所有可用的监视器 <br>2. mon 运行给定的监视器 <br> 每个监视器都是工具内的一个独立软件, 可以有自己的参数. | v2 ☐☑✓ 6.2-rc1 | [LORE v2,0/3](https://lore.kernel.org/all/cover.1668180100.git.bristot@kernel.org) |
 | 2025/03/05 | Gabriele Monaco <gmonaco@redhat.com> | [rv: Add scheduler specification monitors](https://lore.kernel.org/all/20250305140406.350227-1-gmonaco@redhat.com) | 主要目的是向 Linux 内核添加调度器规范监视器(scheduler specification monitors). 以下是该系列补丁的一些关键点:<br>1. 引入调度器跟踪点: 为 RV(Runtime Verification) 任务模型添加了与调度相关的跟踪点(tracepoints).<br>2. 支持嵌套监视器: 通过在 sysfs 监控文件夹中创建一个名为 sched 的监控器来实现对其他监控器的支持. 这个 sched 监控器本身是一个空容器, 用于容纳其他监控器. 控制这个 sched 监控器(启用、禁用、设置反应器)可以同时控制所有嵌套的监控器.<br>3. 新增多种监控器: 增加了每任务(per-task)和每 CPU(per-cpu)监控器, 如 snroc, scpd, snep, sncid 等. 添加了 sco 和 tss 每 CPU 监控器. 该系列补丁旨在使 Linux 内核能够更好地支持运行时验证, 特别是针对调度器的行为进行更细致的监控和验证. 这包括但不限于提高对不同调度策略和抢占模式下行为的理解, 以及帮助开发者更容易地发现和调试与调度相关的问题. 此外, 它还使得能够区分不同的预抢占禁用情况成为可能, 这对于确保系统的实时性和响应性至关重要. | v5 ☐☑✓ | [LORE v5,0/9](https://lore.kernel.org/all/20250305140406.350227-1-gmonaco@redhat.com) |
+| 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) |
+| 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) |


 # 21 新语言支持
@@ -478,4 +478,4 @@ kpatch 的实现一直是根据内核的进展而演进的, 对 JUMP_LABEL 的

 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:---:|:----:|:---:|:----:|:---------:|:----:|
-| 2025/03/20 | Pasha Tatashin <pasha.tatashin@soleen.com> | [Live Update Orchestrator](https://lore.kernel.org/all/20250320024011.2995837-1-pasha.tatashin@soleen.com) | LUO 旨在最小化停机时间的情况下, 促进实时内核更新. 它特别适用于云计算环境, 允许在不完全中断运行中的虚拟机的情况下进行管理程序更新, 通过在内核重启期间保持选定设备的运行状态来实现.<br>具体来说, 这个补丁系列包括三个部分:<br>1. Live Update Orchestrator (LUO): 这是一个新的内核子系统, 主要功能是协调内核的实时更新过程. 它包含一个状态机, 用于跟踪实时更新的进度, 并提供了一个回调 API, 让其他内核子系统可以参与到更新过程中来. 这些子系统包括 KVM、IOMMU、中断处理等.<br>2. 设备层基础设施 (dev_liveupdate): 引入了 dev_liveupdate 基础设施, 作为 LUO 的一部分使用, 支持设备的实时更新.<br>3. x86 架构支持: 在 x86 架构上启用了对 live update 的支持, 使该技术能够在基于 x86 的系统中应用.<br>总的来说, 这些补丁的目标是在内核升级时减少服务中断时间, 特别是对于云服务提供商而言, 这可以帮助他们在不影响客户业务连续性的前提下, 执行必要的维护和安全更新. 参见 [phoronix, 2025/03/20, Google Developing "Live Update Orchestrator" As New Means Of Live Linux Kernel Updates](https://www.phoronix.com/news/Google-Live-Update-Orchestrator) | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20250320024011.2995837-1-pasha.tatashin@soleen.com) |
+| 2025/03/20 | Pasha Tatashin <pasha.tatashin@soleen.com> | [Live Update Orchestrator](https://lore.kernel.org/all/20250320024011.2995837-1-pasha.tatashin@soleen.com) | LUO 旨在最小化停机时间的情况下, 促进实时内核更新. 它特别适用于云计算环境, 允许在不完全中断运行中的虚拟机的情况下进行管理程序更新, 通过在内核重启期间保持选定设备的运行状态来实现.<br>具体来说, 这个补丁系列包括三个部分:<br>1. Live Update Orchestrator (LUO): 这是一个新的内核子系统, 主要功能是协调内核的实时更新过程. 它包含一个状态机, 用于跟踪实时更新的进度, 并提供了一个回调 API, 让其他内核子系统可以参与到更新过程中来. 这些子系统包括 KVM、IOMMU、中断处理等.<br>2. 设备层基础设施 (dev_liveupdate): 引入了 dev_liveupdate 基础设施, 作为 LUO 的一部分使用, 支持设备的实时更新.<br>3. x86 架构支持: 在 x86 架构上启用了对 live update 的支持, 使该技术能够在基于 x86 的系统中应用.<br>总的来说, 这些补丁的目标是在内核升级时减少服务中断时间, 特别是对于云服务提供商而言, 这可以帮助他们在不影响客户业务连续性的前提下, 执行必要的维护和安全更新. 参见 [phoronix, 2025/03/20, Google Developing "Live Update Orchestrator" As New Means Of Live Linux Kernel Updates](https://www.phoronix.com/news/Google-Live-Update-Orchestrator) | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20250320024011.2995837-1-pasha.tatashin@soleen.com), [Linux 内核黑科技！Google 提出 LUO 挑战传统升级方式](https://mp.weixin.qq.com/s/RJAruIju_44U8oi8yTYTzw). |
@@ -491,7 +491,7 @@ 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. 核心思想: 当一个任务被阻塞时, 如果锁的持有者和等待者在同一个运行队列上, 那么可以将执行权"代理"给锁的持有者, 从而避免高优先级任务长时间等待. | 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/) |
+| 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. 核心思想: 当一个任务被阻塞时, 如果锁的持有者和等待者在同一个运行队列上, 那么可以将执行权"代理"给锁的持有者, 从而避免高优先级任务长时间等待. | 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) |


 # 12 深入理解并行编程
@@ -790,7 +790,7 @@ https://lore.kernel.org/all/20240830130309.2141697-1-vincent.guittot@linaro.org/

 | 编号 | 调度器 | 语言 | 用途 |
 |:---:|:-----:|:----:|:---:|
-|  1  | scx_lavd | 程序专注于交互性, 具体来说, 就是始终如一地从游戏中获得更高的帧速率. |
+|  1  | scx_lavd | NA | 程序专注于交互性, 具体来说, 就是始终如一地从游戏中获得更高的帧速率. |
 |  2  | scx_rustland | RUST | 将调度事件转发到用户空间, 在那里做出决策. 还包含 scx_rusty 用于复杂 CPU 拓扑上的负载平衡, 以及, 一个 scx_layered 分区计划程序. |
 |  3  |

@@ -819,7 +819,7 @@ https://lore.kernel.org/all/20240830130309.2141697-1-vincent.guittot@linaro.org/
 | 2025/01/08 | Honglei Wang <jameshongleiwang@126.com> | [sched_ext: switch class when preempted by higher priority scheduler](https://lore.kernel.org/all/20250108023328.37675-1-jameshongleiwang@126.com) | TODO | v2 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250108023328.37675-1-jameshongleiwang@126.com) |
 | 2024/12/16 | Michal Koutný <mkoutny@suse.com> | [Add kernel cmdline option for rt_group_sched](https://lore.kernel.org/all/20241216201305.19761-1-mkoutny@suse.com) | TODO | v1 ☐☑✓ | [LORE v1,0/9](https://lore.kernel.org/all/20241216201305.19761-1-mkoutny@suse.com)<br>*-*-*-*-*-*-*-* <br>[LORE v1,0/9](https://lore.kernel.org/all/20250210151239.50055-1-mkoutny@suse.com)<br>*-*-*-*-*-*-*-* <br>[LORE v2,00/10](https://lore.kernel.org/all/20250310170442.504716-1-mkoutny@suse.com/) |
 | 2025/01/14 | Florian Schmaus <flo@geekplace.eu> | [sched: provide sched_set_batch()](https://lore.kernel.org/all/20250114130513.498482-3-flo@geekplace.eu) | TODO | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20250114130513.498482-3-flo@geekplace.eu) |
-| 2024/12/04 | Tobias Huschle <huschle@linux.ibm.com> | [sched/fair: introduce new scheduler group type group_parked](https://lore.kernel.org/all/20241204112149.25872-1-huschle@linux.ibm.com) | TODO | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20241204112149.25872-1-huschle@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/3](https://lore.kernel.org/all/20250217113252.21796-1-huschle@linux.ibm.com) |
+| 2024/12/04 | Tobias Huschle <huschle@linux.ibm.com> | [sched/fair: introduce new scheduler group type group_parked](https://lore.kernel.org/all/20241204112149.25872-1-huschle@linux.ibm.com) | TODO | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20241204112149.25872-1-huschle@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/3](https://lore.kernel.org/all/20250217113252.21796-1-huschle@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v3,0/4](https://lore.kernel.org/all/20250512115325.30022-1-huschle@linux.ibm.com) |
 | 2025/01/13 | I Hsin Cheng <richard120310@gmail.com> | [sched/fair: Refactor can_migrate_task() to elimate looping](https://lore.kernel.org/all/20250113041249.6847-1-richard120310@gmail.com) | TODO | v2 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250113041249.6847-1-richard120310@gmail.com) |
 | 2025/01/16 | Phil Auld <pauld@redhat.com> | [sched: Mention autogroup disabled behavior](https://lore.kernel.org/all/20250116124654.2365691-1-pauld@redhat.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250116124654.2365691-1-pauld@redhat.com) |
 | 2024/11/13 | Juri Lelli <juri.lelli@redhat.com> | [Fix DEADLINE bandwidth accounting in root domain changes and hotplug](https://lore.kernel.org/all/20241113125724.450249-1-juri.lelli@redhat.com) | TODO | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20241113125724.450249-1-juri.lelli@redhat.com) |
@@ -882,5 +882,19 @@ https://xarjbochz9n.feishu.cn/wiki/WBX8wziSMiVBxFkKNVXcGjEsnqb?from=from_copylin



+https://www.aidenleong.com/lxr/linux-6.14.2/kernel/sched/idle.c
+https://ncnz67vv5cuy.feishu.cn/wiki/IN66w8dW8imkkUkKusMcy2jLnBb
+
+
+
+
+
+| 2025/05/28 | Ingo Molnar <mingo@kernel.org> | [sched: Use the SMP scheduler on UP too](https://lore.kernel.org/all/20250528080924.2273858-1-mingo@kernel.org) | Ingo Molnar 提出一组共 43 个补丁, 旨在将 Linux 调度器统一为 SMP( 对称多处理) 版本, 从而大幅减少调度器中 `CONFIG_SMP` 相关的预处理条件编译代码. 当前 `kernel/sched/` 中有 175 处 `CONFIG_SMP` 判断, 导致代码维护困难、易出错, 并影响可读性和可审查性. 该补丁系列将这一数量减少至 28 处, 删除近 1000 行代码, 提升了代码整洁度. <br><br>此改动使 UP( 单处理器) 调度器也使用 SMP 实现, 虽引入少量冗余代码和性能开销( 如上下文切换时间增加约 5%、内核体积增长约 0. 3% 文本段), 但换来更简单的维护模型. 作者强调, 未来若需优化 UP 性能或体积, 应通过合理方式( 如 `IS_ENABLED( ) `) 进行, 而非回归大量 `#ifdef`. 补丁系列已初步测试验证在 UP 系统上可正常启动和运行, 目前存放于指定 Git 仓库中.  | v1 ☐☑✓ | [2025/05/28, LORE v1, 0/43](https://lore.kernel.org/all/20250528080924.2273858-1-mingo@kernel.org) |
+| 2025/06/11 | Cheng-Yang Chou <yphbchou0911@gmail.com> | [sched_ext: Standardize preprocessor comment markers](https://lore.kernel.org/all/20250611135404.13851-1-yphbchou0911@gmail.com) | 旨在对 `sched/ext*. {c, h}` 文件中的 `#if/#else/#endif` 预处理注释标记进行标准化, 以提升代码一致性与可读性. 该工作遵循 Ingo Molnar 近期调度器清理工作的方向, 旨在减少 `CONFIG_SMP` 相关复杂性并删除冗余的 `#ifdef` 代码块. 此次修改不涉及任何功能变更. 补丁共修改 4 个文件, 删除 60 行、新增 3 行代码.  | v1 ☐☑✓ | [2025/06/11, LORE v1, 0/4](https://lore.kernel.org/all/20250611135404.13851-1-yphbchou0911@gmail.com) |
+
+
+
+
+
+

-H100 > A100 > A800 > H20danshi1