diff --git a/study/kernel/00-DESCRIPTION/AI.md b/study/kernel/00-DESCRIPTION/AI.md
index 5f6491a..7102dd3 100644
--- a/study/kernel/00-DESCRIPTION/AI.md
+++ b/study/kernel/00-DESCRIPTION/AI.md
@@ -59,7 +59,7 @@ blogexcerpt: 虚拟化 & KVM 子系统
## 1.1 AI4OS
-------
-| 概要 | 论文/链接 | 描述 |
+| 概要 | 论文 / 链接 | 描述 |
|:---:|:--------:|:----:|
| 自动化故障定位、修复和分析 | [A Unified Debugging Approach via LLM-Based Multi-Agent Synergy](https://arxiv.org/abs/2404.17153) | 大型语言模型 (LLM) 在自动调试方面显示出了巨大潜力. 然而, 我们发现传统和基于 LLM 的调试工具面临着三个挑战: 1) 故障定位的上游不完美会影响下游的修复; 2) 处理复杂逻辑错误的不足; 3) 忽略程序上下文. 作者提出了第一个自动化的、统一的调试框架——FixAgent, 通过 LLM 代理协同作用. FixAgent 可以执行端到端的故障定位、修复和分析. LLM 可以从人类开发人员在调试中认可的通用软件工程原则中受益, 如 rubber duck debugging, 从而更好地理解程序功能和逻辑错误. 因此, 我们创建了三个受 rubber duck debugging 启发的设计来解决这些挑战. 它们是代理专业化和协同作用、关键变量跟踪和程序上下文理解, 这些要求 LLM 提供明确的解释, 并迫使它们关注关键的程序逻辑信息. 在广泛使用的 QuixBugs 数据集上的实验表明, FixAgent 正确修复了 80 个中的 79 个错误, 其中有 9 个以前从未被修复过. 即使没有故障位置信息和少于 0.6% 的采样时间, 它也比 CodeFlaws 上表现最佳的修复工具更可信地修补了 1.9 倍的缺陷. 平均而言, FixAgent 相对于使用不同 LLM 的基础模型平均增加了约 20% 的可信和正确的修复, 显示出我们设计的有效性. 此外, FixAgent 的正确率达到了惊人的 97.26%, 表明 FixAgent 有可能克服现有方法的过度拟合问题. |
| AI 辅助 Linux 补丁测试 | [Testing AI-enhanced reviews for Linux patches](https://lwn.net/Articles/987319) | 在 2024 年 7 月的 Netdev 0x18 大会上的一次演讲中, Brandeburg 概述了一个使用机器学习来审查包含发送到 netdev 邮件列表的补丁的电子邮件的实验. 大型语言模型(LLMs) 不会很快取代人工审阅者, 但它们可能是一个有用的补充, 可以帮助人类专注于更深入的审阅, 而不是简单的规则违规行为. 参见 [AI Enhanced Reviews for Linux Networking](https://netdevconf.info/0x18/docs/netdev-0x18-paper26-talk-slides/netdev_0x18_AI_Reviews.pdf) |
@@ -78,10 +78,25 @@ blogexcerpt: 虚拟化 & KVM 子系统
-------
-### 2.1 大模型汇总
+## 2.1 模型结构
-------
-### 2.1.1 大模型汇总
+
+[2025 年大模型与 Transformer 架构：重塑 AI 未来的科技革命](https://blog.csdn.net/lifetragedy/article/details/146948744)
+
+[Mamba详细介绍和RNN、Transformer的架构可视化对比](https://blog.csdn.net/deephub/article/details/136250003)
+
+
+| 编号 | 结构 | 描述 |
+|:---:|:---:|:----:|
+| 1 | Mamba | 线性复杂度的新星
Mamba 利用结构化空间状态对偶 (SSD/Structured Space-State Duality) 构建了一个稳健的理论框架, 使得原本为 Transformer 开发的算法和系统优化技术能够迁移应用于 SSM. Mamba 架构以其线性增长的低计算开销和硬件感知型算法, 在处理长序列数据方面表现出色, 显著提升了计算速度和性能. 与 Transformer 相比, Mamba 的计算开销随序列长度线性增长, 这使得它能够处理更长的文本序列, 同时大幅降低计算成本.
在 A100 GPU 上, Mamba 使用扫描进行循环计算, 能够将计算速度提升 3 倍. 不过, Mamba 架构也存在一些问题, 如记忆丢失、难以泛化到不同任务、在复杂模式方面的表现不及基于 Transformer 的语言模型等. |
+| 2 | RWKV | RNN 变体的新突破
RWKV 是循环神经网络 (RNN) 的一个创新变体. 它的架构由一系列堆叠的残差块组成, 每个残差块包含具有循环结构的时间混合(time-mixing)和通道混合(channel-mixing) 子块. RWKV 采用了动态状态演化(Dynamic State Evolution), 具备恒定的显存占用、恒定的推理生成速度以及 "无限" 的上下文长度, 完全不含自注意力机制.
然而, RWKV 基底模型对提示词(prompt)的格式非常敏感, 提示词的格式对生成结果有较大影响. 并且由于架构设计的原因, RWKV 模型在需要回顾的任务上表现较弱. |
+| 3 | Hyena | 高效低复杂度的全新尝试
Hyena 由两个高效的二次基元递归定义的算子, 交织隐式参数化的长卷积和数据控制的门控组成, 构建了一个高效、灵活且计算复杂度低的注意力替代算法. Hyena 的时间复杂度为 O(n*log(n)), 远低于 Transformer 的 O(n²).
在实际应用中, Hyena 能够显著缩小与注意力机制的差距. 当序列长度为 64K 时, Hyena 算子的速度是高度优化注意力的 100 倍. 不过, Hyena 运算不支持 Mas, ，这使得使用 Hyena 架构进行生成式预训练建模时不够灵活. |
+
+### 2.1.1 Transformer
+-------
+
+#### 2.1.1.1 模型汇总
-------
[Mooncake: Kimi's KVCache-centric Architecture for LLM Serving](https://arxiv.org/abs/2407.00079)
@@ -104,11 +119,13 @@ blogexcerpt: 虚拟化 & KVM 子系统
[[论文笔记]REACT: SYNERGIZING REASONING AND ACTING IN LANGUAGE MODELS](https://blog.csdn.net/yjw123456/article/details/139102046)
-### 2.1.2 云侧大模型
- -------
+[大语言模型宇宙 - 大模型架构配置概况](https://github.com/mannaandpoem/AGIDreamFactory)
+
+#### 2.1.1.2 云侧大模型
+-------
-### 2.1.3 端侧大模型
+#### 2.1.1.2 端侧大模型
-------
| 编号 | 模型 | 团队 | 详情 | 实例 |
@@ -120,6 +137,8 @@ blogexcerpt: 虚拟化 & KVM 子系统
| 5 | Qwen2-1.5B | NA | NA | NA |
+## 2.1.2 Mamba
+
## 2.2 稠密模型与稀疏模型
-------
@@ -131,20 +150,24 @@ blogexcerpt: 虚拟化 & KVM 子系统
MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Adaptive Mixture of Local Experts](https://www.cs.toronto.edu/~hinton/absps/jjnh91.pdf) 提出 MoE.
-[群魔乱舞：MoE大模型详解](https://www.zhihu.com/tardis/bd/art/677638939)
+[群魔乱舞：MoE 大模型详解](https://www.zhihu.com/tardis/bd/art/677638939)
[【论文阅读】MOE，《OUTRAGEOUSLY LARGE NEURAL NETWORKS: THE SPARSELY-GATED MIXTURE-OF-EXPERTS LAYER》](https://blog.csdn.net/bylander/article/details/138139345)
[【论文速读】MOD，《Mixture-of-Depths: Dynamically allocating compute in transformer-based language models》](https://blog.csdn.net/bylander/article/details/139536003)
-[Mixture of Depths论文解读](https://zhuanlan.zhihu.com/p/691324301)
+[Mixture of Depths 论文解读](https://zhuanlan.zhihu.com/p/691324301)
[OLMoE](https://github.com/allenai/OLMoE)
-### 2.2.2 稀疏化训练
+### 2.2.2 稀疏化
-------
-[【ICDE 2022】阿里发布稀疏模型训练框架HybridBackend，单位成本下训练吞吐提升至5倍](https://blog.csdn.net/weixin_48534929/article/details/124661176)
+[【ICDE 2022】阿里发布稀疏模型训练框架 HybridBackend, 单位成本下训练吞吐提升至 5 倍](https://blog.csdn.net/weixin_48534929/article/details/124661176)
+
+| 编号 | 技术 | 团队 | 介绍 |
+|:---:|:----:|:---:|:---:|
+| 1 | [D-LLM: A Token Adaptive Computing Resource Allocation Strategy for Large Language Models](https://blog.csdn.net/paixiaoxin/article/details/145521305) | NA | 本文提出了一种名为 D-LLM 的新型动态推理机制, 旨在为大型语言模型 (LLMs) 自适应地分配计算资源. 当前, LLMs 对每个词元的处理是等同的, 但作者认为并非所有词语都同等重要, 某些词语在简单问题中并不需要过多的计算资源. D-LLM 通过为每个 Transformer 层设计动态决策模块, 决定是否执行或跳过该层, 从而提高推理速度. 此外, 本文还提出了一种有效的驱逐策略, 以解决跳过层时 KV 缓存缺失的问题. 实验结果表明, D-LLM 在问答、摘要和数学解题任务中可减少高达 45% 的计算成本和 KV 存储, 在常识推理任务中可减少 50%, 且性能未受影响. |
## 2.3 模型压缩和量化
@@ -155,15 +178,13 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad
| 技术 | 描述 |
|:---:|:---:|
-| 量化 | 类似"量子级别的减肥", 神经网络模型的参数一般都用 float32 的数据表示, 但如果我们将 float32 的数据计算精度变成 int8 的计算精度. 则可以牺牲一点模型精度来换取更快的计算速度. |
-| 蒸馏 | 类似"老师教学生", 使用一个效果好的大模型指导一个小模型训练, 因为大模型可以提供更多的软分类信息量, 所以会训练出一个效果接近大模型的小模型. [详解4种模型压缩技术、模型蒸馏算法](https://zhuanlan.zhihu.com/p/638092734) |
-| 剪裁 | 类似"化学结构式的减肥", 将模型结构中对预测结果不重要的网络结构剪裁掉, 使网络结构变得更加"瘦身". 比如, 在每层网络, 有些神经元节点的权重非常小, 对模型加载信息的影响微乎其微. 如果将这些权重较小的神经元删除, 则既能保证模型精度不受大影响, 又能减小模型大小. 参见 [论文总结-模型剪枝](https://xmfbit.github.io/2018/10/03/paper-summary-model-pruning/) |
-| 神经网络架构搜索(NAS) | 类似"化学结构式的重构", 以模型大小和推理速度为约束进行模型结构搜索, 从而获得更高效的网络结构. 参见 [一文详解神经网络结构搜索(NAS)](https://zhuanlan.zhihu.com/p/73785074). |
+| 量化 | 类似 "量子级别的减肥", 神经网络模型的参数一般都用 float32 的数据表示, 但如果我们将 float32 的数据计算精度变成 int8 的计算精度. 则可以牺牲一点模型精度来换取更快的计算速度. |
+| 蒸馏 | 类似 "老师教学生", 使用一个效果好的大模型指导一个小模型训练, 因为大模型可以提供更多的软分类信息量, 所以会训练出一个效果接近大模型的小模型. [详解 4 种模型压缩技术、模型蒸馏算法](https://zhuanlan.zhihu.com/p/638092734) |
+| 剪裁 | 类似 "化学结构式的减肥", 将模型结构中对预测结果不重要的网络结构剪裁掉, 使网络结构变得更加 "瘦身". 比如, 在每层网络, 有些神经元节点的权重非常小, 对模型加载信息的影响微乎其微. 如果将这些权重较小的神经元删除, 则既能保证模型精度不受大影响, 又能减小模型大小. 参见 [论文总结 - 模型剪枝](https://xmfbit.github.io/2018/10/03/paper-summary-model-pruning/) |
+| 神经网络架构搜索(NAS) | 类似 "化学结构式的重构", 以模型大小和推理速度为约束进行模型结构搜索, 从而获得更高效的网络结构. 参见 [一文详解神经网络结构搜索(NAS)](https://zhuanlan.zhihu.com/p/73785074). |
-## 2.4 模型结构优化
--------
@@ -200,11 +221,11 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad
| 10 | MLC LLM | NA | MLC LLM 是一种通用部署解决方案. 可在客户端 (边缘计算), 例如 Android 或 iPhone 平台上, 本地部署 LLM. [MLC LLM：将 LLMs 部署到消费类硬件的优势、挑战以及解决方案](https://blog.csdn.net/FrenzyTechAI/article/details/132340135) |
| 11 | [PaddlePaddle/Anakin](https://github.com/PaddlePaddle/Anakin) | BaiDu | 一个高性能的跨平台推理引擎, 可以在 x86 CPU, ARM, NVIDIA GPU, AMD GPU, 比特大陆以及寒武纪等设备上运行. |
| 12 | [mllm](https://github.com/UbiquitousLearning/mllm) | [UbiquitousLearning](https://ubiquitouslearning.github.io/mllm_website) | 一个快速轻量级的多模态 LLM 推理引擎, 适用于移动和边缘设备, C/C++ 实现, 无任何其他依赖, 并针对多模态比如 fuyu-8B 进行了优化, 支持 ARM NEON 和 x86 AVX2 加速, 以及 4BIT 和 8BIT 整数量化. |
-| 13 | [XiaoMi/Mace](https://github.com/XiaoMi/mace) | 小米 | MACE (Mobile AI Compute Engine) 是一个针对移动异构计算平台优化的深度学习推理框架. 它专注于以下目标: 性能、功耗、响应性、内存使用和库体积、模型保护以及平台覆盖. MACE 支持 TensorFlow、Caffe和ONNX等多种模型格式, 并提供了丰富的示例和文档. |
+| 13 | [XiaoMi/Mace](https://github.com/XiaoMi/mace) | 小米 | MACE (Mobile AI Compute Engine) 是一个针对移动异构计算平台优化的深度学习推理框架. 它专注于以下目标: 性能、功耗、响应性、内存使用和库体积、模型保护以及平台覆盖. MACE 支持 TensorFlow、Caffe 和 ONNX 等多种模型格式, 并提供了丰富的示例和文档. |
| 14 | [Google-AI-Edge/litert](https://github.com/google-ai-edge/LiteRT) | Google Ai Edge | LiteRT(原名 TensorFlow-Lite) 是 Google 开源的高性能端侧 AI 运行时 |
| 15 | [AliBaBa/MNN](https://github.com/alibaba/MNN) | AliBaBa | MNN 是一个高效轻量级的深度学习框架, 在阿里巴巴的关键业务场景中得到广泛应用. 它支持深度学习模型的推理和训练, 在设备上具有业界领先的性能. MNN 还提供了一系列工具, 包括模型转换、压缩、表达式计算等功能. |
-| 16 | [Tencent/TNN](https://github.com/Tencent/TNN) | Tencent | TNN 是由腾讯优图实验室和广影实验室开发的一个跨平台、高性能的深度学习推理框架. 它具有跨平台能力、高性能、模型压缩和代码裁剪等多项优秀特性. TNN 在原有的 ncnn 和 Rapidnet 框架基础上, 进一步加强了对移动设备的支持和性能优化, 同时也借鉴了业界主流开源框架的高性能和良好扩展性特点, 扩展了对X86和NV GPU的支持. TNN已经被应用于腾讯移动QQ、微视、Pitu等多个应用中. |
-| 17 | [Paddle-Lite](https://github.com/PaddlePaddle/Paddle-Lite) | [PaddlePaddle](https://www.paddlepaddle.org.cn/lite) | Paddle Lite 面向端侧场景的轻量化推理引擎 Paddle Lite, 可以实现飞桨模型在 x86/ARM 平台下多种 OS 内的高效部署, 同时支持在 10 种以上的 GPU/NPU 异构后端上进行推理加速和混合调度. 是一个高性能、轻量级、灵活性强且易于扩展的深度学习推理框架, 定位于支持包括移动端、嵌入式以及边缘端在内的多种硬件平台. 它提供了简单易用的部署流程,支持多种硬件平台和多种编程语言,并且具有优秀的加速、优化策略及实现. |
+| 16 | [Tencent/TNN](https://github.com/Tencent/TNN) | Tencent | TNN 是由腾讯优图实验室和广影实验室开发的一个跨平台、高性能的深度学习推理框架. 它具有跨平台能力、高性能、模型压缩和代码裁剪等多项优秀特性. TNN 在原有的 ncnn 和 Rapidnet 框架基础上, 进一步加强了对移动设备的支持和性能优化, 同时也借鉴了业界主流开源框架的高性能和良好扩展性特点, 扩展了对 X86 和 NV GPU 的支持. TNN 已经被应用于腾讯移动 QQ、微视、Pitu 等多个应用中. |
+| 17 | [Paddle-Lite](https://github.com/PaddlePaddle/Paddle-Lite) | [PaddlePaddle](https://www.paddlepaddle.org.cn/lite) | Paddle Lite 面向端侧场景的轻量化推理引擎 Paddle Lite, 可以实现飞桨模型在 x86/ARM 平台下多种 OS 内的高效部署, 同时支持在 10 种以上的 GPU/NPU 异构后端上进行推理加速和混合调度. 是一个高性能、轻量级、灵活性强且易于扩展的深度学习推理框架, 定位于支持包括移动端、嵌入式以及边缘端在内的多种硬件平台. 它提供了简单易用的部署流程, 支持多种硬件平台和多种编程语言, 并且具有优秀的加速、优化策略及实现. |
| 18 | [uTensor]() | NA | NA |
| 19 | Core ML | Apple | NA |
| 20 | MediaPipe | Google |
@@ -216,37 +237,37 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad
| 编号 | 加速框架 | 团队 | 介绍 |
|:---:|:-------:|:---:|:---:|
| 1 | [ARM-software/CMSIS-NN](https://github.com/ARM-software/CMSIS-NN) | ARM | CMSIS-NN 是一个高性能的神经网络内核软件库, 旨在最大化 Arm Cortex-M 处理器上神经网络的性能并最小化内存占用. 它遵循 TensorFlow Lite for Microcontrollers 的 INT8 和 INT16 量化规范, 与 TensorFlow Lite 参考内核完全一致. 该库提供了针对不同 Arm 处理器架构的优化实现, 包括纯 C、 DSP 扩展和 MVE 扩展等. |
-| 2 | [SNPE](https://www.qualcomm.com/developer?redirect=qdn) | Qualcomm Snapdragon | SNPE 是 Qualcomm Snapdragon Neural Processing Engine 的简称. SNPE 是神经网络在骁龙平台上推理的开发套件, 方便开发者在使用高通芯片的设备上加速AI应用. 支持的模型框架: TensorFlow, CAFFE, ONNX, TensorFlowLite. 比如 [SNPE_Tutorial](https://github.com/gesanqiu/SNPE_Tutorial) |
-| 3 | [PX4/eigen](https://github.com/PX4/eigen) | PX4 | Eigen 是一个 C++ 模板库, 用于线性代数: 矩阵、向量、数值求解器和相关算法. 它提供了一个高效、灵活和易于使用的接口,适用于各种应用程序.|
-| 4 | [Google/XNNPACK](https://github.com/google/XNNPACK) | Google | XNNPACK 是一个针对 ARM、x86、WebAssembly 和 RISC-V 平台的高度优化的神经网络推理解决方案. 它不是直接面向深度学习从业者和研究人员使用的, 而是为诸如 TensorFlow Lite、TensorFlow.js、PyTorch、ONNX Runtime 和 MediaPipe 等高级机器学习框架提供低级性能原语,以加速它们的推理性能. |
+| 2 | [SNPE](https://www.qualcomm.com/developer?redirect=qdn) | Qualcomm Snapdragon | SNPE 是 Qualcomm Snapdragon Neural Processing Engine 的简称. SNPE 是神经网络在骁龙平台上推理的开发套件, 方便开发者在使用高通芯片的设备上加速 AI 应用. 支持的模型框架: TensorFlow, CAFFE, ONNX, TensorFlowLite. 比如 [SNPE_Tutorial](https://github.com/gesanqiu/SNPE_Tutorial) |
+| 3 | [PX4/eigen](https://github.com/PX4/eigen) | PX4 | Eigen 是一个 C++ 模板库, 用于线性代数: 矩阵、向量、数值求解器和相关算法. 它提供了一个高效、灵活和易于使用的接口, 适用于各种应用程序.|
+| 4 | [Google/XNNPACK](https://github.com/google/XNNPACK) | Google | XNNPACK 是一个针对 ARM、x86、WebAssembly 和 RISC-V 平台的高度优化的神经网络推理解决方案. 它不是直接面向深度学习从业者和研究人员使用的, 而是为诸如 TensorFlow Lite、TensorFlow.js、PyTorch、ONNX Runtime 和 MediaPipe 等高级机器学习框架提供低级性能原语, 以加速它们的推理性能. |
| 5 | [OpenBLAS](https://github.com/OpenMathLib/OpenBLAS) | OpenBLAS | 开源的 CPU 线性代数库，支持多线程和 SIMD 加速, 广泛应用于科学计算和深度学习框架(如 PyTorch). |
| 6 | [Intel MKL(Math Kernel Library)]() | NA | 针对 Intel CPU 优化的数学计算库, 支持矩阵运算、FFT 等. 在 Intel 平台上性能优于 Eigen. |
| 7 | [Arm Compute Library](https://github.com/ARM-software/ComputeLibrary) | ARM | Arm CPU/GPU 的加速库, 支持图像处理和机器学习算子. 针对 Cortex-A/Cortex-M 优化, 兼容 CMSIS-NN46. |
| 8 | [CuPy](https://github.com/cupy/cupy) | NA | 基于 NVIDIA GPU 的数值计算库，语法兼容 NumPy. 替代部分 Eigen 功能, 适合 GPU 加速场景. |
| 9 | [neon](https://github.com/NervanaSystems/neon) | Intel | neon 是英特尔公司开源的深度学习框架, 致力于在各种硬件上提供最佳性能. 它设计简单易用, 并且具有可扩展性. |
-| 10 | [lapack](https://github.com/Reference-LAPACK/lapack) | NA | LAPACK 是一个用于解决常见数值线性代数问题的 Fortran 子程序库. 它是一个免费提供的软件包, 可以包含在商业软件包中. LAPACK 包含了 Fortran 源代码、测试程序、基本线性代数子程序(BLAS)的 Fortran 参考实现, 以及 CBLAS 和 LAPACKE 的 C 接口. |
+| 10 | [lapack](https://github.com/Reference-LAPACK/lapack) | NA | LAPACK 是一个用于解决常见数值线性代数问题的 Fortran 子程序库. 它是一个免费提供的软件包, 可以包含在商业软件包中. LAPACK 包含了 Fortran 源代码、测试程序、基本线性代数子程序 (BLAS) 的 Fortran 参考实现, 以及 CBLAS 和 LAPACKE 的 C 接口. |
| 11 | [Tencent/ncnn](https://github.com/Tencent/ncnn) | Tencent | ncnn 是一个为手机端极致优化的高性能神经网络前向计算框架. 它从设计之初就深入考虑了手机端的部署和使用. ncnn 无第三方依赖、跨平台, 在手机端 CPU 上的速度快于目前所有已知的开源框架. 开发者可以轻松将深度学习算法移植到手机端高效执行, 开发出人工智能 APP, 将 AI 带到用户的指尖. ncnn 目前已在腾讯多款应用中使用, 如 QQ、Qzone、微信、天天 P 图等. |
## 3.2 推理加速
-------
-[知乎--LLM推理加速技术简介](https://zhuanlan.zhihu.com/p/691360124)
+[知乎 --LLM 推理加速技术简介](https://zhuanlan.zhihu.com/p/691360124)
-[bilibili--如何将大模型与小模型结合？这8种常用策略必看！附17篇案例论文和代码](https://www.bilibili.com/opus/887920175625535524)
+[bilibili-- 如何将大模型与小模型结合？这 8 种常用策略必看！附 17 篇案例论文和代码](https://www.bilibili.com/opus/887920175625535524)
-[知乎--刀刀宁聊大模型推理--笔记：学习推理加速半年之总结与迷思](https://zhuanlan.zhihu.com/p/704938096)
+[知乎 -- 刀刀宁聊大模型推理 -- 笔记：学习推理加速半年之总结与迷思](https://zhuanlan.zhihu.com/p/704938096)
-[知乎-锦年-全面解析 LLM 推理优化：技术、应用与挑战](https://zhuanlan.zhihu.com/p/18736565021)
+[知乎 - 锦年 - 全面解析 LLM 推理优化：技术、应用与挑战](https://zhuanlan.zhihu.com/p/18736565021)
### 3.2.1 KV Cache 压缩
-------
-[SnapKV: LLM在生成内容之前就知道您在寻找什么](https://blog.csdn.net/qq_36931982/article/details/139118015)
+[SnapKV: LLM 在生成内容之前就知道您在寻找什么](https://blog.csdn.net/qq_36931982/article/details/139118015)
[MiniCache 和 PyramidInfer 等 6 种优化 LLM KV Cache 的最新工作](https://www.51cto.com/aigc/913.html)
-[PyramidKV学习资料汇总 - 动态KV缓存压缩技术](https://blog.csdn.net/m0_56734068/article/details/142382328)
+[PyramidKV 学习资料汇总 - 动态 KV 缓存压缩技术](https://blog.csdn.net/m0_56734068/article/details/142382328)
[大模型推理加速：KV Cache Sparsity(稀疏化)方法](https://zhuanlan.zhihu.com/p/701580870)
@@ -260,12 +281,12 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad
[论文笔记：DejaVu、LLM in Flash、PowerInfer](https://zhuanlan.zhihu.com/p/675585887)
-[苹果极致LLM端侧方案：LLM in a flash](https://zhuanlan.zhihu.com/p/673775476)
+[苹果极致 LLM 端侧方案：LLM in a flash](https://zhuanlan.zhihu.com/p/673775476)
### 3.2.3 首 Token 时延优化
-------
-[[Prefill优化][万字]🔥原理&图解vLLM Automatic Prefix Cache(RadixAttention): 首Token时延优化](https://zhuanlan.zhihu.com/p/693556044)
+[[Prefill 优化][万字]🔥原理 & 图解 vLLM Automatic Prefix Cache(RadixAttention): 首 Token 时延优化](https://zhuanlan.zhihu.com/p/693556044)
### 3.2.4 投机执行
-------
@@ -274,30 +295,48 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad
[大模型推理妙招—投机采样(Speculative Decoding)](https://zhuanlan.zhihu.com/p/651359908)
-[最全LLM自投机算法汇总](https://zhuanlan.zhihu.com/p/706111755)
+[最全 LLM 自投机算法汇总](https://zhuanlan.zhihu.com/p/706111755)
-[LLM推理提速2.8倍，CMU清华姚班校友提出「投机式推理」引擎SpecInfer，小模型撬动大模型高效推理](https://www.jiqizhixin.com/articles/2023-05-30-3)
+[LLM 推理提速 2.8 倍，CMU 清华姚班校友提出「投机式推理」引擎 SpecInfer，小模型撬动大模型高效推理](https://www.jiqizhixin.com/articles/2023-05-30-3)
-[知乎-LLM推理加速新范式！推测解码（Speculative Decoding）最新综述](https://zhuanlan.zhihu.com/p/678404136)
+[知乎 - LLM 推理加速新范式！推测解码（Speculative Decoding）最新综述](https://zhuanlan.zhihu.com/p/678404136)
-[知乎-投机采样（Speculative Decoding），另一个提高LLM推理速度的神器（三）](https://zhuanlan.zhihu.com/p/681401656)
+[知乎 - 投机采样（Speculative Decoding），另一个提高 LLM 推理速度的神器（三）](https://zhuanlan.zhihu.com/p/681401656)
-[知乎-刀刀宁-聊聊大模型推理服务之投机推理](https://zhuanlan.zhihu.com/p/699166575)
+[知乎 - 刀刀宁 - 聊聊大模型推理服务之投机推理](https://zhuanlan.zhihu.com/p/699166575)
-[知乎-hemingkx-推测解码（Speculative Decoding）哪家强？-- 最新评测基准Spec-Bench分享](https://zhuanlan.zhihu.com/p/683995502)
+[知乎 - hemingkx - 推测解码（Speculative Decoding）哪家强？-- 最新评测基准 Spec-Bench 分享](https://zhuanlan.zhihu.com/p/683995502)
| 编号 | 算法 | 描述 |
|:---:|:---:|:----:|
| NA | NA | NA |
-### 3.2.5 分布式推理
+### 3.2.5 并行解码
+-------
+
+[Accelerating Transformer Inference for Translation via Parallel Decoding](https://arxiv.org/abs/2305.10427)
+
+
+
+### 3.2.6 分布式推理
+-------
+
+
+#### 3.2.6.1 分布式推理
-------
| 编号 | 加速框架 | 团队 | 介绍 |
|:---:|:-------:|:---:|:---:|
-| 1 | [b4rtaz/distributed-llama](https://github.com/b4rtaz/distributed-llama) | Bart Tadych(b4rtaz) | Distributed Llama 是一个开源项目, 旨在通过张量并行化技术在多台设备上分布式运行大型语言模型(LLM). 它可以在普通的 CPU 设备上运行 LLM, 通过分布工作负载来提高推理速度, 并将 RAM 使用量分散到多个节点上, 以加速大型语言模型(LLM)的推理. 该项目支持 Linux、macOS 和 Windows 操作系统, 并针对 ARM 和 x86_64 AVX2 CPU 进行了优化.
主要功能点:
1. 支持多个设备组成集群, 利用张量并行和高速以太网同步, 提高推理性能
2. 支持多种 Llama 模型, 包括 Llama 3.1 405B、Llama 3.3 70B 等
3. 提供简单的命令行工具, 可以快速启动根节点和工作节点
4. 支持 API 服务器, 方便集成到其他应用程序中 |
-| 2 | [exo-explore/exo](https://github.com/exo-explore/exo) | exo 实验室 | exo 是一个可以在家中使用普通设备运行自己的 AI 集群的项目
主要功能点:
1. 支持多种模型,包括 LLaMA、Mistral、LlaVA、Qwen 和 Deepseek 等
2. 动态模型分区,可根据当前网络拓扑和设备资源自动优化模型分布
3. 自动发现设备,无需手动配置
4. 提供与 ChatGPT 兼容的 API
5. 采用对等连接架构,设备之间地位平等. |
+| 1 | [b4rtaz/distributed-llama](https://github.com/b4rtaz/distributed-llama) | Bart Tadych(b4rtaz) | Distributed Llama 是一个开源项目, 旨在通过张量并行化技术在多台设备上分布式运行大型语言模型 (LLM). 它可以在普通的 CPU 设备上运行 LLM, 通过分布工作负载来提高推理速度, 并将 RAM 使用量分散到多个节点上, 以加速大型语言模型(LLM) 的推理. 该项目支持 Linux、macOS 和 Windows 操作系统, 并针对 ARM 和 x86_64 AVX2 CPU 进行了优化.
主要功能点:
1. 支持多个设备组成集群, 利用张量并行和高速以太网同步, 提高推理性能
2. 支持多种 Llama 模型, 包括 Llama 3.1 405B、Llama 3.3 70B 等
3. 提供简单的命令行工具, 可以快速启动根节点和工作节点
4. 支持 API 服务器, 方便集成到其他应用程序中 |
+| 2 | [exo-explore/exo](https://github.com/exo-explore/exo) | exo 实验室 | exo 是一个可以在家中使用普通设备运行自己的 AI 集群的项目
主要功能点:
1. 支持多种模型, 包括 LLaMA、Mistral、LlaVA、Qwen 和 Deepseek 等
2. 动态模型分区, 可根据当前网络拓扑和设备资源自动优化模型分布
3. 自动发现设备, 无需手动配置
4. 提供与 ChatGPT 兼容的 API
5. 采用对等连接架构, 设备之间地位平等. |
+| 3 | [NVIDIA Dynamo](https://developer.nvidia.cn/dynamo) | NVIDIA | NVIDIA Dynamo 是一个开源、低延迟的模块化推理框架, 用于在分布式环境中服务生成式 AI 模型. 它通过智能资源调度和请求路由、优化的内存管理和无缝的数据传输, 实现跨大型 GPU 集群的推理工作负载无缝扩展. NVIDIA Dynamo 支持所有主要的 AI 推理后端, 并提供专门针对大语言模型 (LLM) 的优化, 例如分解服务. |
+
+
+#### 3.2.6.2 异构推理
+-------
+
+[HeteroLLM: Accelerating Large Language Model Inference on Mobile SoCs platform with Heterogeneous AI Accelerators](https://arxiv.org/abs/2501.14794)
## 3.3 算子库
@@ -338,21 +377,21 @@ ARM-software/ComputeLibrary
[大模型分词：sentencepiece vs titoken](https://zhuanlan.zhihu.com/p/691609961)
[tokenizer（一）训练一个 LLM 分词器](https://zhuanlan.zhihu.com/p/688792019)
-[Tokenizer的系统梳理，并手推每个方法的具体实现](https://cloud.tencent.com/developer/article/2327739)
+[Tokenizer 的系统梳理，并手推每个方法的具体实现](https://cloud.tencent.com/developer/article/2327739)
[各种中文分词工具的使用方法](https://blog.csdn.net/PolarisRisingWar/article/details/125388765)
-[五款中文分词工具在线PK: Jieba, SnowNLP, PkuSeg,THULAC, HanLP](https://zhuanlan.zhihu.com/p/64409753)
+[五款中文分词工具在线 PK: Jieba, SnowNLP, PkuSeg,THULAC, HanLP](https://zhuanlan.zhihu.com/p/64409753)
| 编号 | 分词器 | 团队 | 详情 |
|:---:|:-----:|:----:|:---:|
-| 1 | [sentencepiece](https://github.com/google/sentencepiece) | Google | Unsupervised text tokenizer for Neural Network-based text generation.
SentencePiece 是谷歌开源的针对 NLP 场景提取词汇表 tokenizer 的开源项目, 它是谷歌推出的子词开源工具包, 其中集成了 BPE、ULM 子词算法. 除此之外, SentencePiece还能支持字符和词级别的分词. 更进一步, 为了能够处理多语言问题, sentencePiece 将句子视为 Unicode 编码序列, 从而子词算法不用依赖于语言的表示.
SentencePiece 提出的目的是在给定词汇表大小的前提下, 最大化词表信息编码 (词频 + 多样性)subword 编码. 比如英语中的 simple 和 simplify 这两个词意思是一样的, 是为了适应语法需求而有的变化, 所以使用独立的 token 对这两个单词编码是有冗余的, 另外一种场景是, 词频不一样, 有常用汉字一说, 也有常用英语单词一说. 出现较少的词使用独立的 token 在训练的时候相比其他高频词由于出现的太少而造成深度学习(信息压缩)这一过程容易丢失该信息. |
+| 1 | [sentencepiece](https://github.com/google/sentencepiece) | Google | Unsupervised text tokenizer for Neural Network-based text generation.
SentencePiece 是谷歌开源的针对 NLP 场景提取词汇表 tokenizer 的开源项目, 它是谷歌推出的子词开源工具包, 其中集成了 BPE、ULM 子词算法. 除此之外, SentencePiece 还能支持字符和词级别的分词. 更进一步, 为了能够处理多语言问题, sentencePiece 将句子视为 Unicode 编码序列, 从而子词算法不用依赖于语言的表示.
SentencePiece 提出的目的是在给定词汇表大小的前提下, 最大化词表信息编码 (词频 + 多样性)subword 编码. 比如英语中的 simple 和 simplify 这两个词意思是一样的, 是为了适应语法需求而有的变化, 所以使用独立的 token 对这两个单词编码是有冗余的, 另外一种场景是, 词频不一样, 有常用汉字一说, 也有常用英语单词一说. 出现较少的词使用独立的 token 在训练的时候相比其他高频词由于出现的太少而造成深度学习 (信息压缩) 这一过程容易丢失该信息. |
| 2 | [huggingface/tokenizers](https://github.com/huggingface/tokenizers) | Hugging Face | NA |
-| 3 | [openai/tiktoken](https://github.com/openai/tiktoken) | OpenAI | [OpenAI开源GPT-2的子词标记化神器——tiktoken，一个超级快的（Byte Pair Encoder，BPE）字节对编码Python库](https://zhuanlan.zhihu.com/p/592399697), [OpenAI 大模型高效Tokenizer: tiktoken](https://zhuanlan.zhihu.com/p/631840697) |
+| 3 | [openai/tiktoken](https://github.com/openai/tiktoken) | OpenAI | [OpenAI 开源 GPT-2 的子词标记化神器——tiktoken，一个超级快的（Byte Pair Encoder，BPE）字节对编码 Python 库](https://zhuanlan.zhihu.com/p/592399697), [OpenAI 大模型高效 Tokenizer: tiktoken](https://zhuanlan.zhihu.com/p/631840697) |
| 4 | [mlc-ai/tokenizers-cpp](https://github.com/mlc-ai/tokenizers-cpp) | mlc-ai | 一个跨平移台的 C++ 分词器, 包装并 bind 了 HuggingFace 以及 sentencepiece, 并提供了最小的通用 C++ API. |
| 5 | [rust-tokenizers](https://github.com/guillaume-be/rust-tokenizers) | guillaume-be | Rust-tokenizers 是一个高性能的 tokenizer 库, 支持多种现代语言模型, 包括 WordPiece、Byte-Pair Encoding (BPE) 和 Unigram (SentencePiece) 模型. 这些 tokenizer 广泛应用于自然语言处理领域, 特别是在 transformer 架构中. |
| 6 | [OpenNMT/Tokenizer](https://github.com/OpenNMT/Tokenizer) | OpenNMT | 一个快速, 通用, 可定制的文本分词器, 支持 C++/Python, 依赖最小. 提供了多种功能, 包括可逆分词, 子词分词, 高级文本分段, 大小写管理以及保护序列等. |
-## 4.2 Transformer
+## 4.2 可视化工具
-------
| 编号 | 工具 | 团队 | 详情 |
@@ -360,11 +399,14 @@ ARM-software/ComputeLibrary
| 1 | [Gemma Scope](https://www.163.com/dy/article/J8GVD23005566WT8.html) | Google DeepMind | [Google DeepMind 发布大模型可视化工具 Gemma Scope](https://www.163.com/dy/article/J8GVD23005566WT8.html) |
| 2 | [Inspectus](https://github.com/labmlai/inspectus) | labmlai | [探索语言模型的奥秘 - 体验 Inspectus 的强大视觉洞察力](https://github.com/labmlai/inspectus) |
| 3 | [Transformer Explainer](https://github.com/poloclub/transformer-explainer) | poloclub | 通过互动可视化的方式了解生成式 AI 中 Transformer 的工作原理. 他在浏览器中实时运行一个 GPT-2 模型, 允许用户使用自己的文本进行试验, 并实时观察 Transformer 的内部组件和操作如何协同工作来预测下一个 Token, 在线体验地址 [transformer-explainer/](https://poloclub.github.io/transformer-explainer) |
-| 4 | [BertViz](https://github.com/jessevig/bertviz) | Jessevig | 使用交互式的方式, 可视化 Transformer 语言模型 (如 BERT, GPT2) 的注意力机制, 可在 Jupyter 或 Colab 中运行, 通过简单的 Python API 支持大多数 Hugging Face 预训练模型 (如 BERT, GPT2, T5 等), BertViz 扩展了 Llion Jones 的 Tensor2Tensor 可视化工具, 提供了头视图, 模型视图, 神经元视图等多个不同的可视化方式, 每个视图都提供了一个独特的视角来了解注意力机制. 参见 [2019/04/11, Human-Computer Interaction (cs.HC), Visualizing Attention in Transformer-Based Language Representation Models](https://arxiv.org/abs/1904.02679). |
+| 4 | [BertViz](https://github.com/jessevig/bertviz) | Jessevig | 使用交互式的方式, 可视化 Transformer 语言模型 (如 BERT, GPT2) 的注意力机制, 可在 Jupyter 或 Colab 中运行, 通过简单的 Python API 支持大多数 Hugging Face 预训练模型 (如 BERT, GPT2, T5 等), BertViz 扩展了 Llion Jones 的 Tensor2Tensor 可视化工具, 提供了头视图, 模型视图, 神经元视图等多个不同的可视化方式, 每个视图都提供了一个独特的视角来了解注意力机制. 参见 [2019/04/11, Human-Computer Interaction (cs.HC), Visualizing Attention in Transformer-Based Language Representation Models](https://arxiv.org/abs/1904.02679) 和 [可解释 AI，在 Transformer 中可视化注意力（附代码）](https://mp.weixin.qq.com/s/vwJEBXCk6GrwN9-BVucoQA). |
| 5 | [LLM Visualization](https://github.com/bbycroft/llm-viz) | bbycroft | 将 Transformer 原理的详细细节通过交互可视化的方式一步步显示出来, 详细的展示了每一步的数学原理, 模型的网格结构, 参数构造的运行过程, 可以精确到每一步观察大模型运行的运算以及数据的变化. 作者的 [仓库 bbycroft/llm-viz](https://github.com/bbycroft/llm-viz) 以及 [在线演示地址 bbycroft.net/llm](https://bbycroft.net/llm), [@HansChanX](https://x.com/HansChanX) LLM 可视化演的中文翻译版本: [仓库 czhixin/llm-viz-cn](https://github.com/czhixin/llm-viz-cn) 以及 [示](https://llm-viz-cn.iiiai.com/llm). 其他 [Vaaaas/llm-viz-CN](https://github.com/Vaaaas/llm-viz-CN), 知乎报道 [矩阵模拟！Transformer 大模型 3D 可视化，GPT-3、Nano-GPT 每一层清晰可见](https://zhuanlan.zhihu.com/p/670287271) |
-| 6 | [Machine-Learning-Tokyo/Interactive_Tools](https://github.com/Machine-Learning-Tokyo/Interactive_Tools) | Machine-Learning-Tokyo |这个项目收集了各种用于机器学习、深度学习和数学的交互式工具. |
+| 6 | [Machine-Learning-Tokyo/Interactive_Tools](https://github.com/Machine-Learning-Tokyo/Interactive_Tools) | Machine-Learning-Tokyo | 这个项目收集了各种用于机器学习、深度学习和数学的交互式工具. |
| 7 | [hahnyuan/LLM-Viewer](https://github.com/hahnyuan/LLM-Viewer) | hahnyuan | 一个可视化语言与学习模型 LLMs 并分析在不同硬件平台上性能的工具. 可以进行网络级分析, 考虑峰值内存消耗和总推理时间成本等因素. 使用 LLM-Viewer, 可以获取 LLM 推理和性能优化的宝贵见解. 可以在 Web 浏览器或者命令行(CLI) 工具中使用. 在线体验地址 [LLM-Viewer Web](http://llm-viewer.com). 参见论文 [LLM Inference Unveiled: Survey and Roofline Model Insights](https://arxiv.org/abs/2402.16363). |
-
+| 8 | [A collection of my study notes for learners](https://www.k-a.in/notes.html) | k-a.in | Transformer/MoE Visualized |
+| 9 | [CNN Explainer](https://poloclub.github.io/cnn-explainer) | poloclub | CNN Explainer: 卷积神经网络可视化, 可交互有细节, 卷积激活池化一目了然, 该项目用 TensorFlow.js 加载一个 10 层的预训练模型, 相当于在浏览器上跑一个 CNN 模型, 可以了解 CNN 的处理过程. 这个网页工具还可以实现交互, 只要点击其中任何一个格子—CNN 中的 "神经元", 就能显示它的输入、经过的变化, 甚至连每一次卷积运算都能看得清清楚楚. [poloclub/cnn-explainer](https://github.com/poloclub/cnn-explainer), 参见论文 [CNN Explainer: Learning Convolutional Neural Networks with Interactive Visualization](https://arxiv.org/abs/2004.15004) |
+| 10 | [PyTorch 可视化工具介绍](https://zhuanlan.zhihu.com/p/658596017) | NA | NA | PyTorch 可视化工具介绍. |
+| 11 | [attentionmech/mav](https://github.com/attentionmech/mav) | attentionmech | 一款可视化大模型内部工作原理的工具, 帮助用户更好的理解和分析模型在生成文本时的内部魔偶快, 包括注意力分布, 预测概率等. 参见 [知识图谱 + 知识库 RAG 项目 Yuxi-Know 及大模型推理内部可视化工具 OpenMAV 实现拆解](https://zhuanlan.zhihu.com/p/1893668626810270690) |
## 4.3 评测平台
-------
@@ -387,20 +429,20 @@ ARM-software/ComputeLibrary
|:---:|:---:|
| [Hannibal046/Awesome-LLM](https://github.com/Hannibal046/Awesome-LLM) | 一份关于大型语言模型的精选论文列表, 尤其是与 ChatGPT 相关的论文. 它还包含用于 LLM 培训的框架、要部署 LLM 的工具、有关所有公开可用的 LLM 检查点和 API 的 LLM 课程和教程. |
| [dair-ai/ML-Papers-of-the-Week](https://github.com/dair-ai/ML-Papers-of-the-Week) | 每周 AI 热点论文. |
-| [Lightning-AI/litgpt](https://github.com/Lightning-AI/litgpt) | LitGPT 是一个强大的工具, 使开发人员能够利用LLM的最新进展. 其全面的功能、用户友好性以及不断发展的社区使其成为构建和部署LLM应用程序的理想选择. |
+| [Lightning-AI/litgpt](https://github.com/Lightning-AI/litgpt) | LitGPT 是一个强大的工具, 使开发人员能够利用 LLM 的最新进展. 其全面的功能、用户友好性以及不断发展的社区使其成为构建和部署 LLM 应用程序的理想选择. |
| [aishwaryanr/awesome-generative-ai-guide](https://github.com/aishwaryanr/awesome-generative-ai-guide) | 关于人工智能的开源综合站点, 汇总了相关的论文以及课程, 以及业界前沿资讯. |
| [LuckyyySTA/Awesome-LLM-hallucination](https://github.com/LuckyyySTA/Awesome-LLM-hallucination) | 这项研究调查了与大型语言模型幻觉相关的论文. 包括相关的调查或分析论文、幻觉原因、幻觉检测和基准、幻觉缓解, 以及该领域的挑战和开放性问题. |
-| [Datawhale](https://github.com/datawhalechina) | Datawhale 是一个专注于数据科学与 AI 领域的开源组织, 汇集了众多领域院校和知名企业的优秀学习者, 聚合了一群有开源精神和探索精神的团队成员. Datawhale 以 "for the learner, 和学习者一起成长"为愿景, 鼓励真实地展现自我、开放包容、互信互助、敢于试错和勇于担当. 同时 Datawhale 用开源的理念去探索开源内容、开源学习和开源方案, 赋能人才培养, 助力人才成长, 建立 起人与人, 人与知识, 人与企业和人与未来的联结. |
+| [Datawhale](https://github.com/datawhalechina) | Datawhale 是一个专注于数据科学与 AI 领域的开源组织, 汇集了众多领域院校和知名企业的优秀学习者, 聚合了一群有开源精神和探索精神的团队成员. Datawhale 以 "for the learner, 和学习者一起成长" 为愿景, 鼓励真实地展现自我、开放包容、互信互助、敢于试错和勇于担当. 同时 Datawhale 用开源的理念去探索开源内容、开源学习和开源方案, 赋能人才培养, 助力人才成长, 建立 起人与人, 人与知识, 人与企业和人与未来的联结. |
| [zjunlp/LLMAgentPapers](https://github.com/zjunlp/LLMAgentPapers) | 关于大型语言模型代理的必读论文. |
| [mli/paper-reading](https://github.com/mli/paper-reading) | 深度学习论文精读. |
| [mlabonne/llm-course](https://github.com/mlabonne/llm-course) | 大型语言模型课程. |
-| [AmadeusChan/Awesome-LLM-System-Papers](https://github.com/AmadeusChan/Awesome-LLM-System-Papers) | 收集了大语言模型系统论文, 涵盖了算法-系统协同设计, 推理系统相关的内容. |
+| [AmadeusChan/Awesome-LLM-System-Papers](https://github.com/AmadeusChan/Awesome-LLM-System-Papers) | 收集了大语言模型系统论文, 涵盖了算法 - 系统协同设计, 推理系统相关的内容. |
| [tensorchord/Awesome-LLMOps](https://github.com/tensorchord/Awesome-LLMOps) | 精选了 LLMOps 工具, 收集和整理了大量优秀的 LLMOps 工具, 涵盖了模型, 服务, 安全, 可观测性等多个领域. |
| [HqWu-HITCS/Awesome-Chinese-LLM](https://github.com/HqWu-HITCS/Awesome-Chinese-LLM) | 整理开源的中文大语言模型, 主要关注规模较小, 可私有化部署, 训练成本较低的模型. 包括底座模型, 垂直领域微调以及应用, 数据集合教程等内容 |
| [km1994/nlp_paper_study](https://github.com/km1994/nlp_paper_study) | 该仓库主要记录 NLP 算法工程师相关的顶会论文研读笔记. |
| [NexaAI/Awesome-LLMs-on-device](https://github.com/NexaAI/Awesome-LLMs-on-device) | 汇总了端侧 AI 的相关架构和优化技术, 包括前言的论文研究. |
-| [wdndev/llm_interview_note](https://github.com/wdndev/llm_interview_note) | 主要记录大语言大模型(LLMs) 算法(应用)工程师相关的知识及面试题. |
-| [冬于的博客-Transformer/BERT/实战](https://ifwind.github.io/2021/08/31/Transformer-BERT-实战) | 通过大量图讲述 Transformer 架构 |
+| [wdndev/llm_interview_note](https://github.com/wdndev/llm_interview_note) | 主要记录大语言大模型 (LLMs) 算法(应用) 工程师相关的知识及面试题. |
+| [冬于的博客 - Transformer/BERT / 实战](https://ifwind.github.io/2021/08/31/Transformer-BERT - 实战) | 通过大量图讲述 Transformer 架构 |
| [浅显易懂地介绍 llm.c [译]](https://baoyu.io/translations/llm/explaining-llm-c-in-layman-terms) | [Explainable Language Models: Existing and Novel Approaches](https://twitter.com/karpathy/status/1778153659106533806) 的译文, 参见 [karpathy/llm.c](https://github.com/karpathy/llm.c). |
| [DefTruth/Awesome-LLM-Inference](https://github.com/DefTruth/Awesome-LLM-Inference) | 收集了大量 LLM 推理相关的论文和仓库, 涵盖了并行计算, 量化压缩, 注意力机制优化, 上下文管理等. |
| [SylphAI-Inc/llm-engineer-handbook](https://github.com/SylphAI-Inc/llm-engineer-handbook) | NA |
@@ -418,17 +460,17 @@ 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 的算法层面和系统层面的高效技术. 详细介绍了每个分类下的具体技术, 如: 量化, 剪枝, 知识蒸馏, 数据选择, 提示工程等
1. [知乎--黄浴--高效大语言模型：综述](https://zhuanlan.zhihu.com/p/671710012)
2. [知乎--磐石--大模型高效推理 I 推理技术框架总结](https://zhuanlan.zhihu.com/p/696850285)
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)
2. [知乎--罗清雨--大语言模型高效推理综述](https://zhuanlan.zhihu.com/p/707685591) |
-| 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/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 的算法层面和系统层面的高效技术. 详细介绍了每个分类下的具体技术, 如: 量化, 剪枝, 知识蒸馏, 数据选择, 提示工程等
1. [知乎 -- 黄浴 -- 高效大语言模型：综述](https://zhuanlan.zhihu.com/p/671710012)
2. [知乎 -- 磐石 -- 大模型高效推理 I 推理技术框架总结](https://zhuanlan.zhihu.com/p/696850285)
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)
2. [知乎 -- 罗清雨 -- 大语言模型高效推理综述](https://zhuanlan.zhihu.com/p/707685591) |
+| 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) |
+| 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)
-| NA | NA | [Towards Efficient Generative Large Language Model Serving: ASurvey from Algorithms to Systems](https://arxiv.org/abs/2312.15234) | NA | NA | [知乎--路漫漫独求索--LLM推理加速技术简介](https://zhuanlan.zhihu.com/p/691360124)
+| NA | NA | [Towards Efficient Generative Large Language Model Serving: ASurvey from Algorithms to Systems](https://arxiv.org/abs/2312.15234) | NA | NA | [知乎 -- 路漫漫独求索 --LLM 推理加速技术简介](https://zhuanlan.zhihu.com/p/691360124)
[A Survey of Techniques for Maximizing LLM Performance]()
[Large Language Models: A Survey](https://arxiv.org/abs/2402.06196)
[A Survey of Large Language Models](https://arxiv.org/abs/2303.18223)
@@ -451,7 +493,7 @@ ARM-software/ComputeLibrary
|:---:|:----:|:------:|:---:|:------:|:----:|
| 2024/09/23 | 日常论文精选 | [metame-ai/awesome-llm-plaza](https://github.com/metame-ai/awesome-llm-plaza) | [metame-ai](https://github.com/metame-ai/awesome-llm-plaza) | [awesome-llm-plaza](https://github.com/metame-ai/awesome-llm-plaza) | 日常论文精选 |
| 2024/10/25 | 日常论文精选 | [xianshang33/llm-paper-daily](https://github.com/xianshang33/llm-paper-daily) | [xianshang33](https://github.com/xianshang33/llm-paper-daily) | [xianshang33/llm-paper-daily](https://github.com/xianshang33/llm-paper-daily) | 日常论文精选 |
-| 2024/11/25 | 日常论文速递 | NA | NA | [叶子的技术碎碎念-每周AI论文速递](http://leafw.cn) | NA |
+| 2024/11/25 | 日常论文速递 | NA | NA | [叶子的技术碎碎念 - 每周 AI 论文速递](http://leafw.cn) | NA |
diff --git a/study/kernel/00-DESCRIPTION/ARCH.md b/study/kernel/00-DESCRIPTION/ARCH.md
index 41b4a88..e18018d 100644
--- a/study/kernel/00-DESCRIPTION/ARCH.md
+++ b/study/kernel/00-DESCRIPTION/ARCH.md
@@ -666,7 +666,7 @@ TLB entry shootdown 常常或多或少的带来一些性能问题.
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
-| 2024/12/21 | Rik van Riel | [AMD broadcast TLB invalidation](https://lore.kernel.org/all/20241222040717.3096835-1-riel@surriel.com) | GCC 支持 Zen 3 的补丁对 INVLPGB 和 TLBSYNC 指令进行了支持, 参见 phoronix 报道 [phoronix, 2020/10/19, AMD Sends Out Patches Adding "Znver3" Support To GNU Binutils With New Instructions](https://www.phoronix.com/news/Znver3-Binutils-Support). 随后 Linux 内核开始支持使用 AMD INVLPGB 指令进行广播 TLB 失效. 参见 phoronix 报道 [phoronix, 2024/12/22, Linux Kernel Patches To Use AMD INVLPGB Instruction Show Huge Speed-Up](https://www.phoronix.com/news/AMD-INVLPGB-Linux-Benefits), [phoronix, 2025/01/13, AMD Broadcast TLB Invalidation Linux Patches Reworked In 4th Spin](https://www.phoronix.com/news/AMD-INVLPGB-Linux-v4-Patches) 和 phoronix 报道 [phoronix, 2025/02/05, AMD Broadcast TLB Invalidation Patches For Linux Updated, Intel RAR Eyed Next](https://www.phoronix.com/news/AMD-INVLPGB-Linux-v8), [phoronix, 2025/03/03, AMD Broadcast TLB Invalidation "INVLPGB" Support Appears Ready For The Linux Kernel](https://www.phoronix.com/news/AMD-INVLPGB-Ready-For-Linux) [phoronix, 2025/03/25, AMD INVLPGB Merged For Linux 6.15 To Provide Another Performance Advantage](https://www.phoronix.com/news/AMD-INVLPGB-Merged-Linux-6.15). | v1 ☐☑✓ | [LORE v1,0/10](https://lore.kernel.org/all/20241222040717.3096835-1-riel@surriel.com)
*-*-*-*-*-*-*-*
[LORE v8,00/12](https://lore.kernel.org/lkml/20250205014033.3626204-1-riel@surriel.com)
*-*-*-*-*-*-*-*
[LORE v14,0/13](https://lore.kernel.org/all/20250226030129.530345-1-riel@surriel.com) |
+| 2024/12/21 | Rik van Riel | [AMD broadcast TLB invalidation](https://lore.kernel.org/all/20241222040717.3096835-1-riel@surriel.com) | GCC 支持 Zen 3 的补丁对 INVLPGB 和 TLBSYNC 指令进行了支持, 参见 phoronix 报道 [phoronix, 2020/10/19, AMD Sends Out Patches Adding "Znver3" Support To GNU Binutils With New Instructions](https://www.phoronix.com/news/Znver3-Binutils-Support). 随后 Linux 内核开始支持使用 AMD INVLPGB 指令进行广播 TLB 失效. 参见 phoronix 报道 [phoronix, 2024/12/22, Linux Kernel Patches To Use AMD INVLPGB Instruction Show Huge Speed-Up](https://www.phoronix.com/news/AMD-INVLPGB-Linux-Benefits), [phoronix, 2024/12/29, Benchmarking The AMD INVLPGB Linux Kernel Patches For Better Performance](https://www.phoronix.com/review/AMD-INVLPGB-Linux), [phoronix, 2024/12/31, AMD INVLPGB Linux Patches Updated For Broadcast TLB Invalidation](https://www.phoronix.com/news/AMD-INVLPGB-Linux-Patches-v3), [phoronix, 2025/01/13, AMD Broadcast TLB Invalidation Linux Patches Reworked In 4th Spin](https://www.phoronix.com/news/AMD-INVLPGB-Linux-v4-Patches) 和 phoronix 报道 [phoronix, 2025/02/05, AMD Broadcast TLB Invalidation Patches For Linux Updated, Intel RAR Eyed Next](https://www.phoronix.com/news/AMD-INVLPGB-Linux-v8), [phoronix, 2025/03/03, AMD Broadcast TLB Invalidation "INVLPGB" Support Appears Ready For The Linux Kernel](https://www.phoronix.com/news/AMD-INVLPGB-Ready-For-Linux) [phoronix, 2025/03/25, AMD INVLPGB Merged For Linux 6.15 To Provide Another Performance Advantage](https://www.phoronix.com/news/AMD-INVLPGB-Merged-Linux-6.15). | v1 ☐☑✓ | [LORE v1,0/10](https://lore.kernel.org/all/20241222040717.3096835-1-riel@surriel.com)
*-*-*-*-*-*-*-*
[LORE v8,00/12](https://lore.kernel.org/lkml/20250205014033.3626204-1-riel@surriel.com)
*-*-*-*-*-*-*-*
[LORE v14,0/13](https://lore.kernel.org/all/20250226030129.530345-1-riel@surriel.com) |
### 2.2.4 BATCHED_UNMAP_TLB_FLUSH
@@ -1133,7 +1133,7 @@ https://blogs.vmware.com/vsphere/2021/10/introducing-project-capitola.html
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2024/03/24 | ira.weiny@intel.com | [DCD: Add support for Dynamic Capacity Devices (DCD)](https://lore.kernel.org/all/20240324-dcd-type2-upstream-v1-0-b7b00d623625@intel.com) | 动态容量设备 (DCD)(CXL 3.1 sec 9.13.3) 是一种 CXL 存储器设备, 它允许存储器容量动态变化, 而无需重置设备、重新配置 HDM 解码器或重新配置软件 DAX 区域. 动态容量最大的使用案例之一是允许主机在数据中心内动态共享内存, 而不增加每台主机连接的内存. 添加或删除内存的一般流程是让协调器协调内存的使用. 通常, 在这样的系统中有 5 个参与者, 即编排器、结构管理器、主机看到的设备、主机内核和主机用户. | v1 ☐☑✓ | [LORE v1,0/26](https://lore.kernel.org/all/20240324-dcd-type2-upstream-v1-0-b7b00d623625@intel.com) |
-| 2024/04/22 | Dongsheng Yang | [block: Introduce CBD (CXL Block Device)](https://lore.kernel.org/all/20240422071606.52637-1-dongsheng.yang@easystack.cn) | [CBD Proposed For The Linux Kernel: CXL Block Device](https://www.phoronix.com/news/Linux-CBD-CXL-Block-Device) | v1 ☐☑✓ | [LORE v1,0/7](https://lore.kernel.org/all/20240422071606.52637-1-dongsheng.yang@easystack.cn) |
+| 2024/04/22 | Dongsheng Yang | [Introduce CBD (CXL Block Device)](https://lore.kernel.org/all/20240422071606.52637-1-dongsheng.yang@easystack.cn) | [CBD Proposed For The Linux Kernel: CXL Block Device](https://www.phoronix.com/news/Linux-CBD-CXL-Block-Device), [phoronix, 2025/01/07, CXL Block Device "CBD" Looking Very Promising For The Linux Kernel In 2025](https://www.phoronix.com/news/CXL-Block-Device-Linux-v3) | v1 ☐☑✓ | [LORE v1,0/7](https://lore.kernel.org/all/20240422071606.52637-1-dongsheng.yang@easystack.cn)
*-*-*-*-*-*-*-*
[LORE v3,0/8](https://lore.kernel.org/all/20250107103024.326986-1-dongsheng.yang@linux.dev) |
## 6.4 CPU IDLE(C-state)
@@ -1387,7 +1387,9 @@ AMD-pstate 驱动程序利用 ITMT 体系结构提供的功能和数据结构,
| 2023/08/15 | Meng Li | [amd-pstate preferred core](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=dfddf34a3f0d45483f5b3e46c2e7bda173796f1b) | [AMD Pstate Preferred Core](https://lore.kernel.org/all/20230815061546.3556083-1-li.meng@amd.com) 以及 [AMD P-State Preferred Core Submitted For Linux 6.9 While Intel Meteor Lake Gets Tuned](https://www.phoronix.com/news/AMD-P-State-Preferred-Core-69) | v2 ☐☑✓ 6.9-rc1 | [LORE v2,0/7](https://lore.kernel.org/all/20230815061546.3556083-1-li.meng@amd.com)
*-*-*-*-*-*-*-*
[LORE v13,0/7](https://lore.kernel.org/all/20240112092531.789841-1-li.meng@amd.com)
*-*-*-*-*-*-*-*
[LORE v14,0/7](https://lore.kernel.org/lkml/20240119090502.3869695-1-li.meng@amd.com) |
| 2024/03/18 | Perry Yuan | [AMD Pstate Driver Core Performance Boost](https://lore.kernel.org/all/cover.1710754236.git.perry.yuan@amd.com) | 该补丁集系列为 AMD pstate 驱动程序增加了核心性能提升 (core performance boost) 功能, 包括被动, 引导和主动模式支持. 用户可以使用新的 sysfs 条目: "/sys/devices/system/cpu/amd_pstate/cpb_boost" 更改核心频率 boost 控制. 由于与支持所有模式的新 cpb_boost 的功能冲突, 传统的 boost 接口已被删除. 参见 [AMD Posts Updated Linux Patches For P-State Core Performance Boost](https://www.phoronix.com/news/AMD-Core-Performance-Boost-6). [AMD Core Performance Boost For Linux Getting Per-CPU Core Controls](https://www.phoronix.com/news/AMD-Core-Perf-Boost-Per-CPU), [AMD P-State Core Performance Boost To Be Merged For Linux 6.11](https://www.phoronix.com/news/AMD-Core-Perf-Boost-Linux-6.11). | v6 ☐☑✓ | [LORE v6,0/6](https://lore.kernel.org/all/cover.1710754236.git.perry.yuan@amd.com)
*-*-*-*-*-*-*-*
[AMD Pstate Driver Core Performance Boost](https://lore.kernel.org/linux-pm/cover.1714989803.git.perry.yuan@amd.com) |
| 2024/03/08 | Sibi Sankar | [cpufreq: scmi: Add boost frequency support](https://lore.kernel.org/all/20240308104410.385631-1-quic_sibis@quicinc.com) | [ARM SCMI CPUFreq Driver Enabling Boost Support By Default With Linux 6.9](https://www.phoronix.com/news/ARM-SCMI-CPUFreq-Boost-Linux-69). | v3 ☐☑✓ | [LORE v3,0/2](https://lore.kernel.org/all/20240308104410.385631-1-quic_sibis@quicinc.com)
*-*-*-*-*-*-*-*
[LORE v4,0/2](https://www.phoronix.com/news/Linux-69-RAM-Bandwidth-Throttle) |
-| 2024/12/23 | K Prateek Nayak | [x86, sched: Dynamic ITMT core ranking support and some yak shaving](https://lore.kernel.org/all/20241223043407.1611-1-kprateek.nayak@amd.com) | 该补丁系列旨在为 Linux 内核的 x86 架构和调度程序) 添加动态 ITMT(Intel Turbo Boost Max Technology) 核心排名支持, 并进行了一些优化调整. 以下是补丁的主要内容:
1. 转换 "sysctl_sched_itmt_enabled" 到布尔值: 将原先的系统控制参数转换为更简洁的布尔值形式.
2. 使用 guard() 保护 itmt_update_mutex: 增强代码的安全性, 确保在多线程环境下对共享资源的访问更加安全.
3. 将 "sched_itmt_enabled" 系统控制移至 debugfs: 使得启用或禁用此功能更加灵活, 用户可以通过 debugfs 接口来操作.
4. 直接使用 cpu_smt_flags 替代 x86_smt_flags: 简化了相关代码，提高了维护性.
5. 无条件地在 PKG 域中使用 x86_sched_itmt_flags: 确保在处理包 (package) 级别的调度时，能够更好地利用 ITMT 技术.
6. 避免在负载均衡期间不必要地计算 NUMA 平衡统计信息: 提高负载均衡效率, 减少不必要的计算开销.
7. 避免在负载均衡期间不必要地计算过载状态: 进一步优化负载均衡过程，避免冗余计算.
8. 解缓存 asym_prefer_cpu 并在 update_sd_lb_stats() 中查找它: 这个修改被标记为 RFC(Request for Comments), 因为它虽然可以在一些场景下减少开销，但增加了代码复杂度.
9. 此外, 这个补丁是之前针对 Preferred Core 系统的修复尝试的精神继承者. 它还考虑到了如何正确处理空闲 CPU 的状态, 以避免因阻塞平均值导致的误判为空闲 CPU 过载的问题. 参见 [phoronix, 2025/01/15, Linux 6.14 To Bring An Important Improvement For AMD Preferred Core](https://www.phoronix.com/news/AMD-Preferred-Core-Better-6.14) | v2 ☐☑✓ | [LORE v2,0/8](https://lore.kernel.org/all/20241223043407.1611-1-kprateek.nayak@amd.com) |
+| 2024/12/23 | K Prateek Nayak | [x86, sched: Dynamic ITMT core ranking support and some yak shaving](https://lore.kernel.org/all/20241223043407.1611-1-kprateek.nayak@amd.com) | 该补丁系列旨在为 Linux 内核的 x86 架构和调度程序) 添加动态 ITMT(Intel Turbo Boost Max Technology) 核心排名支持, 并进行了一些优化调整. 以下是补丁的主要内容:
1. 转换 "sysctl_sched_itmt_enabled" 到布尔值: 将原先的系统控制参数转换为更简洁的布尔值形式.
2. 使用 guard() 保护 itmt_update_mutex: 增强代码的安全性, 确保在多线程环境下对共享资源的访问更加安全.
3. 将 "sched_itmt_enabled" 系统控制移至 debugfs: 使得启用或禁用此功能更加灵活, 用户可以通过 debugfs 接口来操作.
4. 直接使用 cpu_smt_flags 替代 x86_smt_flags: 简化了相关代码，提高了维护性.
5. 无条件地在 PKG 域中使用 x86_sched_itmt_flags: 确保在处理包 (package) 级别的调度时，能够更好地利用 ITMT 技术.
6. 避免在负载均衡期间不必要地计算 NUMA 平衡统计信息: 提高负载均衡效率, 减少不必要的计算开销.
7. 避免在负载均衡期间不必要地计算过载状态: 进一步优化负载均衡过程，避免冗余计算.
8. 解缓存 asym_prefer_cpu 并在 update_sd_lb_stats() 中查找它: 这个修改被标记为 RFC(Request for Comments), 因为它虽然可以在一些场景下减少开销，但增加了代码复杂度.
9. 此外, 这个补丁是之前针对 Preferred Core 系统的修复尝试的精神继承者. 它还考虑到了如何正确处理空闲 CPU 的状态, 以避免因阻塞平均值导致的误判为空闲 CPU 过载的问题. 参见 [phoronix, 2025/01/15, Linux 6.14 To Bring An Important Improvement For AMD Preferred Core](https://www.phoronix.com/news/AMD-Preferred-Core-Better-6.14) | v2 ☐☑✓ | [LORE RFC,0/8](https://lore.kernel.org/lkml/20241211185552.4553-1-kprateek.nayak@amd.com/)
*-*-*-*-*-*-*-*
[LORE v2,0/8](https://lore.kernel.org/all/20241223043407.1611-1-kprateek.nayak@amd.com) |
+| 2025/04/09 | K Prateek Nayak | [cpufreq/amd-pstate: Enable ITMT support after initializing core rankings](https://lore.kernel.org/all/20250409030004.23008-1-kprateek.nayak@amd.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250409030004.23008-1-kprateek.nayak@amd.com) |
+| 2025/04/09 | K Prateek Nayak | [sched/fair: Dynamic asym priority support](https://lore.kernel.org/all/20250409053446.23367-1-kprateek.nayak@amd.com) | 支持首选核心排名的AMD处理器子集可以在运行时更改这些排名, 以使负载平衡偏向具有更高频率/更大缓存的 CPU. | v2 ☐☑✓ | [LORE v2,0/4](https://lore.kernel.org/all/20250409053446.23367-1-kprateek.nayak@amd.com) |
#### 6.12.2.3 Dynamic EPP & Raw EPP Feature
@@ -1440,7 +1442,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 | [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 | [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) |
+| 2025/01/31 | Pierre-Eric Pelloux-Prayer | [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)
*-*-*-*-*-*-*-*
[LORE v8,0/10](https://lore.kernel.org/all/20250320095818.40622-1-pierre-eric.pelloux-prayer@amd.com) |
| 2024/11/28 | Raag Jadav | [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) |
diff --git a/study/kernel/00-DESCRIPTION/BPF.md b/study/kernel/00-DESCRIPTION/BPF.md
index 4a3bdfa..558e1cc 100644
--- a/study/kernel/00-DESCRIPTION/BPF.md
+++ b/study/kernel/00-DESCRIPTION/BPF.md
@@ -633,6 +633,8 @@ Wasmtime 完全开源, 使用 Rust 编程语言, 是的, 并且符合 WASI 标
[Wasmer 4.4 Released To Continue Pushing Universal Apps With WebAssembly](https://www.phoronix.com/news/Wasmer-4.4-Released)
[Wasmer 6.0 Wires Up Support For Multiple Heterogeneous Backends](https://www.phoronix.com/news/Wasmer-6.0-Alpha-1)
+[phoronix, 2025/03/26, Microsoft Announces Open-Source "Hyperlight Wasm" Project](https://www.phoronix.com/news/Microsoft-Hyperlight-Wasm)
+
# 10 云原生
-------
diff --git a/study/kernel/00-DESCRIPTION/DEBUGGING.md b/study/kernel/00-DESCRIPTION/DEBUGGING.md
index 6e08491..0b56e70 100644
--- a/study/kernel/00-DESCRIPTION/DEBUGGING.md
+++ b/study/kernel/00-DESCRIPTION/DEBUGGING.md
@@ -552,6 +552,7 @@ bperf 试图通过允许多个 "周期" 或 "指令" 的 perf_event (在不同
| 2024/07/18 | Athira Rajeev | [Add data type profiling support for powerpc](https://lore.kernel.org/all/20240718084358.72242-1-atrajeev@linux.vnet.ibm.com) | 这个补丁集的主要目的是为 PowerPC 架构添加数据类型剖析(data type profiling)的支持. 之前由 Namhyung Kim 提交的一系列补丁已经为 perf 工具引入了数据类型剖析的基本支持. 这些补丁使 perf 能够关联性能监控单元(PMU)的样本到它们所引用的数据类型, 利用 DWARF 调试信息来实现这一点. 目前, 这种支持已经在 x86 架构上可用, 可以通过 perf report 或 perf annotate 命令来查看数据类型信息.
1. PowerPC 指令表更新: 添加了一个 PowerPC 指令助记符表, 用于将负载/存储指令与移动操作关联起来, 从而识别指令是否涉及内存访问.
2. 获取寄存器编号和偏移量: 为了从给定的指令中获取寄存器编号和访问偏移量, 代码使用了 struct arch 中的 objump 字段. 为 PowerPC 添加了相应的条目.
3. 获取寄存器编号函数: 实现了一个 get_arch_regnum 函数, 可以从寄存器名称字符串中返回寄存器编号. 解析原始指令为了更准确地解析 PowerPC 指令.
补丁集采取了以下步骤使用原始指令: 补丁集支持直接使用原始指令而非解析后的指令名称. 这样可以通过宏来提取指令的操作码和寄存器字段.
示例: 例如, 使用 --show-raw-insn 选项时, objdump 会给出原始指令的十六进制表示, 如 "38 01 81 e8", 这对应于 "ld r4,312(r1)" 指令.
避免重复使用 objdump: 补丁集避免了重复使用 objdump 来读取原始指令, 而是直接从动态共享对象 (DSO) 中读取二进制代码.
补丁集作者提供了测试结果, 其中展示了使用 perf annotate --data-type --insn-stat 命令的结果. 结果显示有大约 43.7% 的指令被正确解析, 而 56.3% 的指令未能成功解析. 作者指出还有大约 25% 的未知指令没有得到处理. | v8 ☐☑✓ | [2024/03/09, LORE v1, 0/3](https://lore.kernel.org/all/20240309072513.9418-1-atrajeev@linux.vnet.ibm.com)
*-*-*-*-*-*-*-*
[2024/05/06, LORE v2, 0/9](https://lore.kernel.org/all/20240506121906.76639-1-atrajeev@linux.vnet.ibm.com)
*-*-*-*-*-*-*-*
[2024/07/13, LORE 07, 00/18](https://lore.kernel.org/linux-perf-users/20240713165529.59298-1-atrajeev@linux.vnet.ibm.com)
*-*-*-*-*-*-*-*
[2024/07/18, LORE v8, 00/15](https://lore.kernel.org/all/20240718084358.72242-1-atrajeev@linux.vnet.ibm.com) |
| 2024/07/31 | Namhyung Kim | [perf mem: Basic support for data type profiling](https://lore.kernel.org/all/20240731235505.710436-1-namhyung@kernel.org) | 为 perf 添加对数据类型剖析的基本支持.当使用 perf mem report 命令时, 可以显示关于内存访问的数据类型信息. 补丁添加了一些方便的选项来查看这些信息, 例如 `-T` 和 `-s mem` 选项. 显示了如何按内存层级(如 L1 缓存命中、RAM 访问等)和数据类型(如结构体、整数等)对内存访问进行分类. 通过这些更改, 开发人员可以更详细地了解应用程序或内核模块在运行时如何使用不同类型的内存, 并有助于识别潜在的性能瓶颈. | v1 ☐☑✓ | [2024/07/31, LORE v1,0/6](https://lore.kernel.org/all/20240731235505.710436-1-namhyung@kernel.org) |
| 2024/07/25 | Namhyung Kim | [perf annotate: Cache debuginfo for data type profiling](https://lore.kernel.org/all/20240726015723.1329937-1-namhyung@kernel.org) | TODO | v2 ☐☑✓ | [2024/07/26, LORE](https://lore.kernel.org/all/20240726015723.1329937-1-namhyung@kernel.org)
*-*-*-*-*-*-*-*
[2024/08/05, LORE v3](https://lore.kernel.org/all/20240805234648.1453689-1-namhyung@kernel.org/) |
+| 2025/04/02 | Zecheng Li | [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.11 能量统计
@@ -562,17 +563,29 @@ bperf 试图通过允许多个 "周期" 或 "指令" 的 perf_event (在不同
| 2024/11/15 | Dhananjay Ugwekar | [Add RAPL core energy counter support for AMD CPUs](https://lore.kernel.org/all/20241115060805.447565-1-Dhananjay.Ugwekar@amd.com) | 这组补丁的主要目的是为 AMD CPU 添加对 RAPL(Running Average Power Limit)核心能耗计数器的支持.
当前的 "energy-cores" 事件在 power PMU 中聚合了包级别的能耗数据, 而 AMD CPU 的核心能耗 RAPL 计数器具有核心范围(即每个核心单独记录能耗). 由于这两种事件的作用范围不同, 之前尝试将核心事件添加到 power PMU 中的努力失败了. 因此, 需要一个新的核心范围 PMU 来收集这些新的 "energy-core" 事件. 参见 phoronix 报道 [phoronix, 2024/12/02, AMD Per-Core Energy Counter Support Slated For Linux 6.14](https://www.phoronix.com/news/AMD-Per-Core-Energy-Linux-6.14). | v7 ☐☑✓ | [LORE v7,0/10](https://lore.kernel.org/all/20241115060805.447565-1-Dhananjay.Ugwekar@amd.com) |
-## 11.12 perf other
+## 11.12 perf sched
+-------
+
+
+| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:---:|:----:|:---:|:----:|:---------:|:----:|
+| 2025/02/03 | Dmitry Vyukov | [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 | [perf sched: Introduce stats tool](https://lore.kernel.org/all/20241122084452.1064968-1-swapnil.sapkal@amd.com) | 目标是为 perf sched 引入一个新的统计工具 perf sched stats, 用于更高效地分析调度器行为, 尤其是在长时间运行或调度密集型工作负载下.
1. 问题" 现有的 perf sched record 工具虽然功能强大, 但在长时间运行或调度密集型工作负载下, 会产生大量数据(例如在高核心数服务器上运行 hackbench 时, 生成的 perf.data 文件可能达到 56GB), 并且解析和写入这些数据需要很长时间(约 137 分钟), 这使得其在实际使用中变得不切实际.
2. 目标: 通过引入 perf sched stats 工具, 提供一种更轻量级的解决方案. 该工具通过在工作负载运行前后对 `/proc/schedstat` 文件进行快照, 几乎不对工作负载运行产生干扰, 并且解析和保存数据的时间非常短, 生成的 perf.data 文件也更小.
3. 实现了 `perf sched stats record/report/diff` 子命令.
报告格式: perf sched stats report 会输出详细的调度统计信息, 包括 CPU 调度统计、负载均衡统计、任务唤醒统计等. 报告中还包括字段描述、总运行时间、CPU 调度统计、负载均衡统计等.
差分报告: perf sched stats diff 可以比较两次运行之间的差异, 显示字段的变化百分比和平均 jiffies 间隔.
实时模式: 实时模式：perf sched stats 支持实时模式, 类似于 perf stat, 可以实时输出调度统计信息. | v2 ☐☑✓ | [LORE v2,0/6](https://lore.kernel.org/all/20241122084452.1064968-1-swapnil.sapkal@amd.com)
*-*-*-*-*-*-*-*
[LORE v3,0/8](https://lore.kernel.org/all/20250311120230.61774-1-swapnil.sapkal@amd.com) |
+
+
+
+## 11.13 perf other
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2023/03/01 | Wyes Karny | [Enable Core RAPL for AMD](https://lore.kernel.org/all/20230301181449.14647-1-wyes.karny@amd.com) | 这组补丁的主要目的是在 AMD CPU 上启用核心级别的 RAPL(Running Average Power Limit)能耗计数器支持, 并修复了之前版本中发现的问题. | v2 ☐☑✓ | [LORE v2,0/2](https://lore.kernel.org/all/20230301181449.14647-1-wyes.karny@amd.com) |
-| 2021/07/20 | kan.liang@linux.intel.com | [perf: Save PMU specific data in task_struct](https://lore.kernel.org/all/1626788420-121610-1-git-send-email-kan.liang@linux.intel.com) | 某些特定于 PMU 的数据必须在上下文切换期间保存 / 恢复, 例如 LBR 调用堆栈数据. 目前, 数据保存在事件上下文结构中, 但仅针对每个流程的事件. 对于系统范围的事件, 由于上下文切换后缺少 LBR 调用堆栈数据, 与按进程模式相比, LBR 调用栈总是更短. | v6 ☐☑✓ | [LORE v2,1/2](https://lore.kernel.org/lkml/20230301181449.14647-1-wyes.karny@amd.com/)
*-*-*-*-*-*-*-*
[LORE v6,0/6](https://lore.kernel.org/all/1626788420-121610-1-git-send-email-kan.liang@linux.intel.com) |
+| 2021/07/20 | kan.liang@linux.intel.com | [perf: Save PMU specific data in task_struct](https://lore.kernel.org/all/1626788420-121610-1-git-send-email-kan.liang@linux.intel.com) | 某些特定于 PMU 的数据必须在上下文切换期间保存 / 恢复, 例如 LBR 调用堆栈数据. 目前, 数据保存在事件上下文结构中, 但仅针对每个流程的事件. 对于系统范围的事件, 由于上下文切换后缺少 LBR 调用堆栈数据, 与按进程模式相比, LBR 调用栈总是更短. | v6 ☐☑✓ | [LORE v2,1/2](https://lore.kernel.org/lkml/20230301181449.14647-1-wyes.karny@amd.com/)
*-*-*-*-*-*-*-*
[LORE v6,0/6](https://lore.kernel.org/all/1626788420-121610-1-git-send-email-kan.liang@linux.intel.com)|
*-*-*-*-*-*-*-*
[2025/03/14, LORE v10,0/7](https://lore.kernel.org/all/20250314172700.438923-1-kan.liang@linux.intel.com) |
+ |
-## 11.13 WindowsPerf
+## 11.14 WindowsPerf
-------
[技术分享 | 发布WindowsPerf：用于Windows on Arm的开源性能分析工具](https://mp.weixin.qq.com/s?__biz=MzIwOTYyMjQzOQ==&mid=2247507803&idx=1&sn=16ad97e99a0cb77bad2d9e460a166e85&chksm=97739b93a0041285052512b86886f5b613cf8bb2924f3a8d7b3007325e780c66f70beb7d2037&scene=27)
@@ -687,6 +700,7 @@ Canonical 的工程师一直在探索利用 Profile Guided Optimizations(PGO)
其他相关
[Unified LTO Bitcode Front-End Comes Together For LLV](https://www.phoronix.com/news/LLVM-Unified-LTO-Front-End).
+[phoronix, 2025/01/06, NVIDIA Working On "-flto-partition=locality" GCC Option To Boost Performance For Some CPU Workloads](https://www.phoronix.com/news/NVIDIA-GCC-flto-locality).
### 13.2.3 BOLT'ing
-------
@@ -874,6 +888,8 @@ Mesa CI 开始使用 Mold 作为其 x86_64 和 AArch64 上的默认链接器,
[Mold 2.35 Released With Big Endian ARM64 Support](https://www.phoronix.com/news/Mold-2.35-Released)
+[phoronix, 2025/01/09, Mold 2.36 Linker Brings More Optimizations & Compatibility Improvements](https://www.phoronix.com/news/Mold-2.36-Released)
+
[Mold Linker Performance Remains Very Compelling In 2024 Over GNU Gold/ld, LLVM lld](https://www.phoronix.com/news/Mold-Linker-2024-Performance).
Mold 链接器中添加了一个新的 "--separate-debug-file" 选项, 以实现"更快"的性能. 将包含调试信息的 Clang 链接可以下降到不到半秒, 而目前只有六秒半. [Mold Linker Gains New Option To Deliver "Massively Faster" Performance](https://www.phoronix.com/news/Mold-Separate-Debug-File).
@@ -1261,6 +1277,7 @@ Fedora 尝试优化 systemd 开机以及重启的时间, 参见 phoronix 报道
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2022/06/16 | Daniel Bristot de Oliveira | [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)
*-*-*-*-*-*-*-*
[LORE v9,00/16](https://lore.kernel.org/all/cover.1659052063.git.bristot@kernel.org) |
| 2022/11/11 | Daniel Bristot de Oliveira | [verification/rv: Add rv tool](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=afc70ccb962861e068e04c6089827493f5160a0a) | (用户空间)运行时验证工具 rv. 该工具旨在成为内核 rv 监视器的接口, 以及用户空间控制监视器. 该工具接收命令作为第一个参数
1. list 列出所有可用的监视器
2. mon 运行给定的监视器
每个监视器都是工具内的一个独立软件, 可以有自己的参数. | v2 ☐☑✓ 6.2-rc1 | [LORE v2,0/3](https://lore.kernel.org/all/cover.1668180100.git.bristot@kernel.org) |
+| 2025/03/05 | Gabriele Monaco | [rv: Add scheduler specification monitors](https://lore.kernel.org/all/20250305140406.350227-1-gmonaco@redhat.com) | 主要目的是向 Linux 内核添加调度器规范监视器(scheduler specification monitors). 以下是该系列补丁的一些关键点:
1. 引入调度器跟踪点: 为 RV(Runtime Verification) 任务模型添加了与调度相关的跟踪点(tracepoints).
2. 支持嵌套监视器: 通过在 sysfs 监控文件夹中创建一个名为 sched 的监控器来实现对其他监控器的支持. 这个 sched 监控器本身是一个空容器, 用于容纳其他监控器. 控制这个 sched 监控器(启用、禁用、设置反应器)可以同时控制所有嵌套的监控器.
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) |
# 21 新语言支持
@@ -1320,6 +1337,7 @@ Fedora 尝试优化 systemd 开机以及重启的时间, 参见 phoronix 报道
[A 2024 Discussion Whether To Convert The Linux Kernel From C To Modern C++](https://www.phoronix.com/news/CPP-Linux-Kernel-2024-Discuss)
+[phoronix, 2024/12/28, A "Safe C++" Being Explored Using The New ClangIR](https://www.phoronix.com/news/RFC-Safe-CXX-Using-ClangIR), 参见 [[RFC] A ClangIR based Safe C++](https://discourse.llvm.org/t/rfc-a-clangir-based-safe-c/83245)
# 22 kallsyms
-------
diff --git a/study/kernel/00-DESCRIPTION/LIVE_PATCH.md b/study/kernel/00-DESCRIPTION/LIVE_PATCH.md
index 5b94f61..a9a1822 100644
--- a/study/kernel/00-DESCRIPTION/LIVE_PATCH.md
+++ b/study/kernel/00-DESCRIPTION/LIVE_PATCH.md
@@ -447,6 +447,8 @@ kpatch 的实现一直是根据内核的进展而演进的, 对 JUMP_LABEL 的
| 2015/05/28 | Li Bin | [livepatch: add support on arm64](https://lore.kernel.org/patchwork/cover/947588) | NA | RFC ☐ 5.14-rc1 | [PatchWork RFC,0/5](https://lore.kernel.org/patchwork/cover/947588), [LKML](https://lkml.org/lkml/2015/5/28/54)
*-*-*-*-*-*-*-*
[libin2015/livepatch-for-arm64](https://github.com/libin2015/livepatch-for-arm64)
*-*-*-*-*-*-*-*
[gcc/arm64: support -mfentry feature for arm64](https://gcc.gnu.org/legacy-ml/gcc-patches/2016-03/msg00755.html) |
| 2019/02/08 | Torsten Duwe | [arm64: implement live patching](https://lore.kernel.org/patchwork/cover/1003832) | NA | RFC ☐ 5.14-rc1 | [PatchWork RFC,1/1](https://lore.kernel.org/patchwork/cover/1003832)
*-*-*-*-*-*-*-*
[PatchWork v8,0/5 arm64: ftrace with regs](https://lore.kernel.org/patchwork/cover/1039969)
*-*-*-*-*-*-*-*
[gcc/arm64: add -fpatchable-function-entry=N,M option](https://patchwork.ozlabs.org/project/gcc/list/?submitter=66400) |
| 2021/06/07 | Suraj Jitindar Singh | [arm64: implement live patching](https://lore.kernel.org/patchwork/cover/1441385) | NA | RFC ☐ 5.14-rc1 | [PatchWork RFC,1/1](https://lore.kernel.org/patchwork/cover/1441385) |
+| 2025/03/20 | Song Liu | [arm64: livepatch: Enable livepatch without sframe](https://lore.kernel.org/all/20250320171559.3423224-1-song@kernel.org) | TODO | v3 ☐☑✓ | [LORE v3,0/2](https://lore.kernel.org/all/20250320171559.3423224-1-song@kernel.org) |
+| 2023/02/02 | madvenka@linux.microsoft.com | [arm64: livepatch: Use ORC for dynamic frame pointer validation](https://lore.kernel.org/all/20230202074036.507249-1-madvenka@linux.microsoft.com) | 参见 [ARM64 Livepatch based on SFrame](https://lore.kernel.org/lkml/20240927074141.71195-1-wnliu@google.com/) | v3 ☐☑✓ | [LORE v3,0/22](https://lore.kernel.org/all/20230202074036.507249-1-madvenka@linux.microsoft.com) |
## 6.2 PPC64
diff --git a/study/kernel/00-DESCRIPTION/LOCKING.md b/study/kernel/00-DESCRIPTION/LOCKING.md
index 66cf0dd..6e36b73 100644
--- a/study/kernel/00-DESCRIPTION/LOCKING.md
+++ b/study/kernel/00-DESCRIPTION/LOCKING.md
@@ -491,6 +491,7 @@ Proxy Execution 是一种通用形式的优先级继承机制, 它旨在解决
| 2024/05/06 | John Stultz | [Preparatory changes for Proxy Execution](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=af0c8b2bf67b25756f27644936e74fd9a6273bd2) | Proxy Execution 是一种通用的优先级继承机制的实现方法, 用于解决优先级反转问题和其他类似的问题. 这些预备补丁的目的是为后续更复杂的 Proxy Execution 相关补丁打下基础.
在发送第 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)
*-*-*-*-*-*-*-*
[2024/04/01, LORE v9,0/7](https://lore.kernel.org/all/20240401234439.834544-1-jstultz@google.com)
*-*-*-*-*-*-*-*
[LORE v10,0/7](https://lore.kernel.org/all/20240507045450.895430-1-jstultz@google.com)
*-*-*-*-*-*-*-*
[2024/07/09, LORE v11,0/7](https://lore.kernel.org/all/20240709203213.799070-1-jstultz@google.com)
*-*-*-*-*-*-*-*
[2024/08/13, LORE v12,0/7](https://lore.kernel.org/all/20240813235736.1744280-1-jstultz@google.com)
*-*-*-*-*-*-*-*
[2024/08/29, RESEND, LORE v12,0/7](https://lore.kernel.org/all/20240829225212.6042-1-jstultz@google.com)
*-*-*-*-*-*-*-*
[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 | [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 中引入有趣事件的跟踪事件:
1. sched_pe_enque_sleeping_task: 一个任务在睡眠任务(互斥体所有者)的等待队列中排队.
2. sched_pe_cross_mote_cpu: 依赖链跨远程 cpu.
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 | [Single CPU Proxy Execution (v13)](https://lore.kernel.org/all/20241106025656.2326794-1-jstultz@google.com) | 这组补丁的主要目的是实现单 CPU 代理执行(Single CPU Proxy Execution)机制, 这是一种通用形式的优先级继承(priority inheritance)方法, 旨在解决某些特定场景下的调度问题.
1. 实现单 CPU 代理执行机制, 支持作为构建和运行时选项.
2. 重新设计互斥锁的 blocked_on 结构, 以便更好地支持代理执行.
3. 处理代理执行带来的假设变化, 确保调度器的正确性.
4. 实现初始逻辑, 使锁持有者可以在同一 CPU 上代替等待任务运行.
通过这些改动, 调度器在处理某些特定场景下的优先级继承问题时更加高效和灵活, 提高了系统的整体性能和响应速度. 参见 [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)
*-*-*-*-*-*-*-*
[2024/11/25, LORE v14,0/7](https://lore.kernel.org/all/20241125195204.2374458-1-jstultz@google.com) |
+| 2025/03/12 | John Stultz | [Single RunQueue Proxy Execution](https://lore.kernel.org/all/20250312221147.1865364-1-jstultz@google.com) | 单运行队列(RunQueue)代理执行(Proxy Execution)的 V15 版本, 这是一种通用的优先级继承机制.
1. 问题: 在多核系统中, 当一个高优先级任务被低优先级任务阻塞时, 传统的优先级继承机制可能无法有效解决优先级反转问题, 尤其是在涉及多个运行队列(RunQueue)时.
2. 目标: 通过引入代理执行机制, 允许高优先级任务在等待锁时, 将执行权"代理"给其他任务, 从而减少高优先级任务的等待时间, 并提高系统的响应能力.
3. 核心思想: 当一个任务被阻塞时, 如果锁的持有者和等待者在同一个运行队列上, 那么可以将执行权"代理"给锁的持有者, 从而避免高优先级任务长时间等待. | v15 ☐☑✓ | [2025/03/12, LORE v15,0/7](https://lore.kernel.org/all/20250312221147.1865364-1-jstultz@google.com)
*-*-*-*-*-*-*-*
[2025/04/12, LORE v16, 0/7](https://lore.kernel.org/all/20250412060258.3844594-1-jstultz@google.com/) |
# 12 深入理解并行编程
diff --git a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md
index c1738a6..f76ff54 100644
--- a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md
+++ b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md
@@ -747,6 +747,7 @@ MTE 实现了锁和密钥访问内存. 这样在内存访问期间, 可以在内
| 2017/12/06 | Will Deacon | [arm64: Unmap the kernel whilst running in userspace (KAISER)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=6aef0fdd35ead88cd651391dcc03562938a7612c) | TODO | v2 ☐☑✓ v4.16-rc1 | [2017/11/30, LORE v2,0/18](https://lore.kernel.org/all/1512059986-21325-1-git-send-email-will.deacon@arm.com)
*-*-*-*-*-*-*-*
[2017/12/06, LORE v3,0/20](https://lore.kernel.org/all/1512563739-25239-1-git-send-email-will.deacon@arm.com)
*-*-*-*-*-*-*-*
[arm64 meltdown patches](https://lore.kernel.org/all/20180403110923.43575-1-mark.rutland@arm.com) |
| 2019/05/13 | Alexandre Chartre | [KVM Address Space Isolation](https://lore.kernel.org/all/1557758315-12667-1-git-send-email-alexandre.chartre@oracle.com) | [Generalized address-space isolation](https://lwn.net/Articles/886494) | v1 ☐☑✓ | [2019/05/13, LORE v1,0/27](https://lore.kernel.org/all/1557758315-12667-1-git-send-email-alexandre.chartre@oracle.com)
*-*-*-*-*-*-*-*
[2019/07/11, LORE v2,00/27](https://lore.kernel.org/lkml/1562855138-19507-1-git-send-email-alexandre.chartre@oracle.com)
*-*-*-*-*-*-*-*
[2020/02/26, LORE v3,0/7](https://lore.kernel.org/lkml/1582734120-26757-1-git-send-email-alexandre.chartre@oracle.com) |
| 2022/02/22 | Junaid Shahid | [Address Space Isolation for KVM](https://lore.kernel.org/all/20220223052223.1202152-1-junaids@google.com) | 该补丁系列是 KVM 地址空间隔离端到端实施的概念验证 RFC. 它与 Alexandre Chartre 的高级设计, 但底层实现有所不同. 其中还包括一些内存管理变更, 以帮助区分敏感和非敏感内存, 并将非敏感内存映射到 ASI 受限地址空间. 本 RFC 旨在展示 KVM 的完整 ASI 实现, 而不一定是对最终可能合并的内容的直接建议. 最终合并的直接建议. 尤其是, 这些补丁尚未在 ASI 的基础上实现 KPTI, 尽管该框架的通用性足以支持 KPTI. 同样, 这些补丁也不包括非敏感数据结构注释, 这些数据结构在我们的测试工作负载执行过程中不会被频繁访问. 工作负载, 但该框架的设计可以轻松添加新的非敏感型内存注释. 参见 LWN 报道 [Generalized address-space isolation](https://lwn.net/Articles/886494) 以及 [LWN, 2024/05/21, LSFMMBPF-2024, Another try for address-space isolation](https://lwn.net/Articles/974390). | v1 ☐☑✓ | [LORE v1,0/47](https://lore.kernel.org/all/20220223052223.1202152-1-junaids@google.com) |
+| 2025/01/10 | Brendan Jackman | [Address Space Isolation (ASI)](https://lore.kernel.org/all/20250110-asi-rfc-v2-v2-0-8419288bc805@google.com) | [phoronix, 2025/01/10, Experimental Linux Address Space Isolation "ASI" v2 Patches: I/O Throughput Lower By 70%](https://www.phoronix.com/news/Google-Linux-ASI-v2-RFC-Patches) | v2 ☐☑✓ | [LORE v2,0/29](https://lore.kernel.org/all/20250110-asi-rfc-v2-v2-0-8419288bc805@google.com) |
diff --git a/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md b/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md
index 8b6c29f..83113f9 100644
--- a/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md
+++ b/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md
@@ -122,6 +122,7 @@
|:---:|:-------:|
| 2022 | [为了忘却的纪念——2022 Linux 内核十大技术革新功能](https://blog.csdn.net/csdnnews/article/details/128731761) |
| 2023 | [熠熠生辉 | 2023 年 Linux 内核十大技术革新功能](https://blog.csdn.net/csdnnews/article/details/135493424) |
+| 2024 | [2024年Linux内核十大技术革新盘点｜年终盘点](https://blog.csdn.net/csdnnews/article/details/145127830)
*-*-*-*-*-*-*-*
[phoronix, 2025/01/01, The Most Popular Linux & Open-Source News Of 2024](https://www.phoronix.com/news/Linux-Open-Source-News-2024)
# 6 业界会议
-------
diff --git a/study/kernel/00-DESCRIPTION/SCHEDULER.md b/study/kernel/00-DESCRIPTION/SCHEDULER.md
index 664a30f..d7a5cef 100644
--- a/study/kernel/00-DESCRIPTION/SCHEDULER.md
+++ b/study/kernel/00-DESCRIPTION/SCHEDULER.md
@@ -336,7 +336,9 @@ SCHED_IDLE 跟 SCHED_BATCH 一样, 是 CFS 中的一个策略, SCHED\_IDLE 的
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:---:|:-----------:|:---:|
| 2019/6/26 | Viresh Kumar | [sched/fair: Fallback to sched-idle CPU in absence of idle CPUs](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=3c29e651e16dd3b3179cfb2d055ee9538e37515c) | CFS SCHED_NORMAL 进程在选核的时候, 之前优先选择 IDLE 的 CPU, 现在在没有 IDLE 的 CPU 可选的时候, 也倾向于选择只有 SCHED_IDLE 的进程在运行的 CPU | v3 ☑ [5.4-rc1](https://kernelnewbies.org/Linux_5.4#Core_.28various.29) | [LWN](https://lwn.net/Articles/805317), [PatchWork](https://lore.kernel.org/patchwork/cover/1094197), [lkml](https://lkml.org/lkml/2019/6/26/16)
*-*-*-*-*-*-*-*
[LORE v3,0/2](https://lore.kernel.org/all/cover.1561523542.git.viresh.kumar@linaro.org) |
-| 2019/10/24 | NA | [sched/fair: Make sched-idle cpu selection consistent throughout](https://lore.kernel.org/patchwork/patch/1143783) | 重构了 SCHED_IDLE 时的选核逻辑, 所有的选核流程都将 avaliable_idle_cpu 和 sched_idle_cpu 同等对待 | v1 ☑ 5.4-rc1 | [PatchWork](https://lore.kernel.org/patchwork/patch/1143783) |
+| 2019/10/24 | Abel Wu | [sched/fair: Make sched-idle cpu selection consistent throughout](https://lore.kernel.org/patchwork/patch/1143783) | 重构了 SCHED_IDLE 时的选核逻辑, 所有的选核流程都将 avaliable_idle_cpu 和 sched_idle_cpu 同等对待 | v1 ☑ 5.4-rc1 | [PatchWork](https://lore.kernel.org/patchwork/patch/1143783) |
+| 2025/03/10 | Abel Wu | [Prioritize idle cpus over SCHED_IDLE ones](https://lore.kernel.org/all/20250310074044.3656-1-wuyun.abel@bytedance.com) | `17346452b25b ("sched/fair: Make sched-idle CPU selection consistent")` 中SCHED_IDLE CPU 与空闲 CPU 享有同等或更多的优先权. 在 select_task_rq_fair() 的快速和慢速路径中, 空闲的 CPU 和 SCHED_IDLE CPU 享有同等优先权. 这在扁平化的 cgroup 层次结构(例如, 所有任务都在根 cgroup 内运行)中运行良好, 但在更深的层次结构(例如, 所有任务都在根 cgroup 内运行)中可能并不理想. 在更深的层次结构中, SCHED_IDLE 在不同父节点的实体之间没有任何意义. 由于负载较低的 CPU 可能更有能力为新唤醒的任务提供服务, 这也适用于 SCHED_IDLE CPU, 即负载较低的 SCHED_IDLE CPU 可能更容易、更快地抢占先机, 因此在选择 SCHED_IDLE CPU 时, 让我们至少在慢速路径中不对其进行特殊处理.
在 SIS 中尝试同样的方法, 即选择负载较少的 CPU, 并摆脱模棱两可的 sched_idle_cpu() | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20250310074044.3656-1-wuyun.abel@bytedance.com) |
+
#### 1.1.5.3 sched-idle Load Balancing
-------
@@ -504,6 +506,7 @@ SCHED_DEADLINE server 最终于 v6.12 合入, Linux 6.12 调度的 Merge Reques
| 2023/06/08 | Daniel Bristot de Oliveira | [sched/deadline: Introduce deadline servers](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=63ba8422f876e32ee564ea95da9a7313b13ff0a1) | 如果具有较高优先级的任务 (例如 SCHED_FIFO) 独占 CPU, 则低优先级任务 (例如, SCHED_OTHER) 可能会出现饥饿. RT Throttling 是不久前引入的一种 (主要是调试) 对策, 可以用来为低优先级任务 (通常是后台类型的工作, 例如工作队列、计时器等) 保留一些 CPU 时间. 然而, 它也有自己的问题 (请参阅文档), 并且即使不需要运行优先级较低的活动, 也会无条件地限制 FIFO 任务, 这会产生不希望的影响 (也有一些机制可以解决这个问题, 但同样也有其自身的问题). 引入截止日期服务器, 为饥饿条件下的低优先级任务需求提供服务. 最后期限服务器是通过扩展 SCHED_Deadline 实现来构建的, 以允许两级调度 (即, deadline 实体成为低优先级调度实体的容器). | v3 ☐☑✓ v6.8-rc1 | [LORE v1,00/13](https://lore.kernel.org/all/20190726145409.947503076@infradead.org)
*-*-*-*-*-*-*-*
[LORE v2,0/6](https://lore.kernel.org/all/20200807095051.385985-1-juri.lelli@redhat.com)
*-*-*-*-*-*-*-*
[LORE v3,0/6](https://lore.kernel.org/all/cover.1686239016.git.bristot@kernel.org)
*-*-*-*-*-*-*-*
[LORE v5,0/7](https://lore.kernel.org/all/cover.1699095159.git.bristot@kernel.org)
*-*-*-*-*-*-*-*
[LORE v6,0/6](https://lore.kernel.org/all/cover.1712337227.git.bristot@kernel.org) |
| 2024/03/12 | Joel Fernandes (Google) | [Fair scheduling deadline server fixes](https://lore.kernel.org/all/20240313012451.1693807-1-joel@joelfernandes.org) | 截止日期服务器 [SCHED_DEADLINE server infrastructure](https://lore.kernel.org/all/cover.1699095159.git.bristot@kernel.org) 允许 RT 任务在系统上安全运行, 而不是由于 RT 节流, 浪费了 RT 任务可能无法在空闲系统上执行的 CPU. 以下是我们在测试 ChromeOS 的截止日期服务器时发现的修补程序. 当我发现我的单元测试正在崩溃时, 它像滚雪球一样从 10 个补丁增加到 15 个补丁, 然后我们也看到了与 dl_timer 相关的领域中的一些崩溃! 所有这些都是固定的. 在其他几个修复程序中, 还有一个对核心调度的修复程序. 感谢您的全面审查. 我把所有的补丁都放在 Daniel 和 Peter 的补丁之上, 因为我会让他们把它压缩掉, 并适当地归因于贡献者. | v2 ☐☑✓ | [LORE 00/10](https://lore.kernel.org/all/20240216183108.1564958-1-joel@joelfernandes.org)
*-*-*-*-*-*-*-*
[LORE v2,0/15](https://lore.kernel.org/all/20240313012451.1693807-1-joel@joelfernandes.org) |
| 2023/06/08 | Daniel Bristot de Oliveira | [SCHED_DEADLINE server infrastructure](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=cea5a3472ac43f18590e1bd6b842f808347a810c) | 使用 deadline 服务器为公平任务提供服务. 此补丁集添加并使能了一个 fair_server deadline 实体, 它充当了 CFS 调度实体的容器, 可用于解决优先级较高时的饥饿问题. | v3 ☐☑✓ v6.12-rc1 | [LORE v6,0/6](https://lore.kernel.org/all/cover.1712337227.git.bristot@kernel.org)
*-*-*-*-*-*-*-*
[2024/05/27, LORE v9,0/9](https://lore.kernel.org/all/cover.1716811043.git.bristot@kernel.org) |
+| 2025/03/14 | Joel Fernandes | [Add a deadline server for sched_ext tasks](https://lore.kernel.org/all/20250315022158.2354454-1-joelagnelf@nvidia.com) | sched_ext 任务因 RT 占用而处于饥饿状态, 尤其是在 RT 节流被 deadline 服务器取代后, 它只能促进 CFS 任务的运行. 社区中的一些用户曾报告过 RT 拖延 sched_ext 任务的问题. 因此, 应同时添加一个 sched_ext 截止日期服务器, 这样 sched_ext 任务也会得到提升, 而不会陷入饥饿状态.
我们还提供了一个 kselftest 来验证饥饿问题是否已得到解决. | v1 ☐☑✓ | [LORE v1,0/8](https://lore.kernel.org/all/20250315022158.2354454-1-joelagnelf@nvidia.com) |
## 1.4 其他一些调度类的尝试
@@ -857,7 +860,9 @@ Chang 的 patch set 采用了与之前不同的方法: 允许 cgroup 将一些
| 2022/12/12 | Peng Zhang | [sched: Throttling through task work for cfs bandwidth](https://lore.kernel.org/all/20221212061321.36422-1-zhangpeng.00@bytedance.com) | 若任务占用资源并在内核空间中被限制, 则可能会导致阻塞, 从而造成或者加剧优先级翻转的问题. 这组补丁试图通过在任务返回到用户模式时使用 task_work 来限制任务来解决此问题.
这个补丁使用 task_work 在任务返回到用户空间时将 throttle 的任务出队, 然后在 unthrottle 时再将其入列. 当前能正常工作, 但目前的实现并没有考虑到所有的细节, 比如竞争条件、负载跟踪等. 作者认为这种解决方案的最大缺点是, 在解锁过程中可能有太多的任务需要排队, 从而导致巨大的开销和延迟. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20221212061321.36422-1-zhangpeng.00@bytedance.com) |
20220526103929.14976-1-zhouchengming@bytedance.com) |
| 2023/10/30 | Valentin Schneider | [sched/fair: Make the BW replenish timer expire in hardirq context for PREEMPT_RT](https://lore.kernel.org/all/20231030145104.4107573-1-vschneid@redhat.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20231030145104.4107573-1-vschneid@redhat.com) |
-| 2024/02/02 | Valentin Schneider | [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)
*-*-*-*-*-*-*-*
[2024/02/02, LORE v2,0/5](https://lore.kernel.org/all/20240202080920.3337862-1-vschneid@redhat.com) |
+| 2024/02/02 | Valentin Schneider | [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)
*-*-*-*-*-*-*-*
[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/03/17 | Aaron Lu | [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) 的续作.
1. 核心思想: 当一个任务的 CFS 配额耗尽时, 不是立即将其节流, 而是延迟到任务退出到用户空间时再进行节流. 这样可以避免任务在内核空间中被阻塞, 从而减少任务挂起的风险.
实现方式: 在 CFS 节流路径中, 为每个任务添加一个任务工作(task work), 以便在任务返回用户空间时执行节流操作.在任务返回用户空间时, 任务工作会将任务从运行队列中移除, 并将其添加到 CFS 运行队列的 limbo 列表中, 以便后续恢复.
在 CFS 解除节流路径中, 将 limbo 列表中的任务重新加入运行队列. | v1 ☐☑✓ | [LORE v1,0/7](https://lore.kernel.org/all/20250313072030.1032893-1-ziqianlu@bytedance.com) |
+| 2025/02/20 | K Prateek Nayak | [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) |
### 2.1.4 leaf_cfs_rq
@@ -2008,7 +2013,7 @@ CPU 负载均衡器在不同的域之间进行平衡, 以分散负载, 并努力
|:-----:|:---:|:---:|:----:|:---------:|:----:|
| 2012/01/09 | Peter Zijlstra | [sched: Remove stale power aware scheduling remnants and dysfunctional](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8e7fbcbc22c1) | TODO | v1 ☐☑✓ | [LORE](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8e7fbcbc22c1) |
-### 4.3.4 load_balance vs wake_affine
+#### 4.3.3.5 load_balance vs wake_affine
-------
Mel Gorman 深耕与解决 load_balance 以及 wake_affine 流程中一些不合理的行为.
@@ -2023,13 +2028,17 @@ Mel Gorman 深耕与解决 load_balance 以及 wake_affine 流程中一些不合
-### 4.3.4 update_blocked_averages
+
+### 4.3.4 Reduce the LoadBalancing overhead
+-------
+
+#### 4.3.4.1 update_blocked_averages
-------
此外 update_blocked_averages 也是内核调度器一个非常耗时的操作.
-#### 4.3.4.1 前世的 update_shares, 今生的 update_blocked_averages
+##### 4.3.4.1.1 前世的 update_shares, 今生的 update_blocked_averages
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
@@ -2041,7 +2050,7 @@ Mel Gorman 深耕与解决 load_balance 以及 wake_affine 流程中一些不合
-#### 4.3.4.2 optimize update_blocked_averages to O(nr_cgroups)
+##### 4.3.4.1.2 optimize update_blocked_averages to O(nr_cgroups)
-------
@@ -2067,7 +2076,21 @@ update_blocked_averages() 在多个场景都被发现成为非常严重的性能
| 2019/02/06 | Vincent Guittot | [sched/fair: Fix O(nr_cgroups) in load balance path]()](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=039ae8bcf7a5f4476f4487e6bf816885fb3fb617) | 优化 update_blocked_averages 的负载 | v1 ☑✓ 5.1-rc1 | [LORE 0/2](https://lore.kernel.org/lkml/1549469662-13614-1-git-send-email-vincent.guittot@linaro.org) |
-### 4.3.5 active load_balance
+#### 4.3.4.2 Propagate load balancing stats
+-------
+
+
+| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:---:|:----:|:---:|:----:|:---------:|:----:|
+| 2025/03/13 | K Prateek Nayak | [sched/fair: Propagate load balancing stats up the sched domain hierarchy](https://lore.kernel.org/all/20250313093746.6760-1-kprateek.nayak@amd.com) | 通过在调度域(sched domain)层次结构中传播负载均衡统计信息来提高效率并减少负载均衡的开销. 以下是补丁的主要内容和目标:
1. 问题: 在多核处理器系统中, 负载均衡操作可能占用大量时间, 尤其是在包含大量 CPU 的调度域中. 这种开销可能导致调度延迟增加，影响系统的性能和响应能力.
2. 现状: 目前的调度器在进行负载均衡时, 每个调度域都会独立计算负载统计信息, 而这些信息在不同调度域之间没有共享. 这导致了重复计算和较高的开销.
3. 目标: 通过在调度域层次结构中传播负载均衡统计信息, 减少重复计算, 提高负载均衡的效率, 并减少负载均衡的抖动(jitter).
2. 主要功能和实现:
2.1 统计信息传播: 在每个调度组(sched group)中引入一个指向更高层次调度域共享结构(sd->shared)的引用(sg->shared). 通过这个引用, 可以在较低层次的调度域中收集的负载均衡统计信息被传播到更高层次的调度域中.
实现方式: 引入 sg_lb_stats 对象, 用于在 sg->shared 中聚合负载均衡统计信息.
在 update_sg_lb_stats() 函数中, 检查 sg_lb_stats 的有效性, 并在需要时更新统计信息.
在 update_sd_lb_stats() 函数中, 从所有遍历的调度组中聚合统计信息, 并更新更高层次调度域的统计信息
2.2 优化负载均衡, 减少重复计算: 通过在调度域层次结构中传播统计信息, 避免了在不同调度域中重复计算相同的负载均衡统计信息. 提高效率: 通过减少重复计算, 降低了负载均衡操作的总体开销, 从而提高了系统的调度效率.
减少抖动: 通过减少负载均衡操作的开销, 降低了负载均衡抖动, 提高了系统的稳定性. | v1 ☐☑✓ | [LORE v1,0/8](https://lore.kernel.org/all/20250313093746.6760-1-kprateek.nayak@amd.com) |
+
+
+
+### 4.3.5 Proactive Load Balancing/Migration
+-------
+
+
+#### 4.3.5.1 active load_balance
-------
@@ -2081,8 +2104,26 @@ update_blocked_averages() 在多个场景都被发现成为非常严重的性能
| 2021/06/02 | Yafang Shao | [sched, fair: try to prevent migration thread from preempting non-cfs task](https://lore.kernel.org/patchwork/patch/1440172) | 规避问题 [a race between active_load_balance and sched_switch](https://lkml.org/lkml/2021/6/14/204) | v1 ☐ | [PatchWork v1 old](https://lore.kernel.org/patchwork/patch/1440172), [PatchWork v1](https://lore.kernel.org/patchwork/patch/1446860) |
| 2021/11/04 | Yafang Shao | [sched: Introduce cfs_migration](https://lore.kernel.org/all/20211104145713.4419-1-laoar.shao@gmail.com) | 实现了 per-cpu 的 FIFO 进程 cfs_migration 替代原来的 migration stopper 进程, 在 CFS active load balance 迁移当前进程时使用, 这样如果当前进程已经切换到 RT 进程就不会进行抢占. 从而解决该问题. | RFC ☐ | [LORE 0/4](https://lore.kernel.org/all/20211104145713.4419-1-laoar.shao@gmail.com) |
+#### 4.3.5.2 Push Task Mechanism
+-------
-### 4.3.6 Cache Aware Load-Balancing
+
+
+| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:----:|:----:|:---:|:---:|:----------:|:----:|
+| 2024/08/30 | Vincent Guittot | [5/7, sched/fair: Add push task mechanism for EAS](https://lore.kernel.org/lkml/20250302210539.1563190-6-vincent.guittot@linaro.org/) | [sched/fair: Rework EAS to handle more cases](https://lore.kernel.org/all/20240830130309.2141697-1-vincent.guittot@linaro.org) 中 Patch 5 [`[PATCH 5/7 v5]` sched/fair: Add push task mechanism for EAS](https://lore.kernel.org/all/20250302210539.1563190-1-vincent.guittot@linaro.org) 提议 EAS 在 MISFIT 时使用 push_fair_task() 来进行主动的任务迁移. | v1 ☐☑✓ | [LORE v1,0/5](https://lore.kernel.org/all/20240830130309.2141697-1-vincent.guittot@linaro.org) |
+| 2025/04/09 | K Prateek Nayak | [using the push task mechanism for idle and newidle balance](https://lore.kernel.org/all/20250409111539.23791-1-kprateek.nayak@amd.com) | 在 OSPM'25 上, 不少开发者建议使用推送任务机制来进行 idle balance 和 newidle balance. 借鉴了 [sched/fair: Rework EAS to handle more cases](https://lore.kernel.org/all/20240830130309.2141697-1-vincent.guittot@linaro.org) 的思路, 实现了一套统一的 CFS 任务推送框架, 并已针对 !EAS 场景进行了实现.
1. 该系列实现了 [Valentin 的想法](https://lore.kernel.org/lkml/xhsmh1putoxbz.mognet@vschneid-thinkpadt14sgen2i.remote.csb), 即在存在可推送任务的情况下, CPU 会将自身设置为每个 LLC 的"过载掩码(overloaded mask)".
2. NUMA 间的新空闲平衡机制对此做了优化, 会先遍历本地 LLC 上 overloaded mask 中的 CPU 集合, 然后遍历同一 NUMA 节点中其他 LLC 上 overloaded mask 中的 CPU 集合, 目的是将单个任务拉向自身, 而非执行全面的负载均衡.
3. 这实现了 [David Vernet 的 SAHRED_RUNQ 原型](https://lore.kernel.org/lkml/20231212003141.216236-1-void@manifault.com/) 中的一些想法, 不过, 与每个 LLC/每个分片使用一个单独的 SHARED_RUNQ 不同, 这里过载掩码用作指示符, 表明每个 CPU 的 rq 中包含可迁移到即将空闲的 CPU 的可推送任务. 这样做的代价是维护过载的 cpumask, 但避免了为每个 SHARED_RUNQ 设置锁.
4. 推送回调函数本身已进行了修改, 会尝试将可推送任务列表中的任务推送到"nohz.idle_cpus_mask"掩码中的某个 CPU 上, 从而减轻空闲平衡的负载. | v1 ☐☑✓ | [LORE v1,0/5](https://lore.kernel.org/all/20250409111539.23791-1-kprateek.nayak@amd.com) |
+
+
+## 4.3.6 Migrations Rate Limits
+-------
+
+| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:----:|:----:|:---:|:---:|:----------:|:----:|
+| 2023/04/11 | Mathieu Desnoyers | [sched: Rate limit migrations](https://lore.kernel.org/all/20230411214116.361016-1-mathieu.desnoyers@efficios.com) | 将每个任务的迁移限制为每 SCHED_MIGRATION_WINDOW_NS(10ms) 窗口 SCHED_MIGRATION_LIMIT(32) 次. 具体的迁移计数和窗口大小可以通过 `kernel/sched/sched.h` 中的以下定义进行更改. | v1 ☐☑✓ | [LORE v1,0/1](https://lore.kernel.org/all/20230411214116.361016-1-mathieu.desnoyers@efficios.com) |
+
+
+### 4.3.7 Cache Aware Load-Balancing
-------
@@ -2090,6 +2131,49 @@ update_blocked_averages() 在多个场景都被发现成为非常严重的性能
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2025/03/25 | Peter Zijlstra | [sched: Cache aware load-balancing](https://lore.kernel.org/all/20250325120952.GJ36322@noisy.programming.kicks-ass.net) | 这个补丁旨在实现调度器中的缓存感知负载均衡功能. 以下是该补丁的主要内容和目标:
1. 缓存亲和性建模: 补丁尝试对缓存亲和性进行建模, 特别是针对 LLC(Last Level Cache) 层面. 虽然目前主要关注于 LLC, 但理论上也可以扩展到处理 L2 等其他缓存域的情况.
2. 选择最佳 CPU: 它计算在同一个 LLC 内的最近运行时间最长的 CPU, 并在唤醒路径中使用这个 CPU 来引导任务分配, 同时在 task_hot() 函数中限制从这个 CPU 迁移任务, 以保持缓存亲和性.
3. 潜在的扩展能力: 补丁中提到一个 XXX 标记, 表明未来可能需要考虑如何在一个节点内找到最佳的 LLC(与 NUMA_BALANCING 的交互), 这意味着该补丁有进一步发展的空间.
这个补丁的目标是通过改进 Linux 内核的调度器, 使其能够更加智能地考虑缓存的影响, 从而提高系统性能。具体来说, 就是通过优化任务到 CPU 的分配策略来减少由于频繁跨缓存域迁移导致的性能损失. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250325120952.GJ36322@noisy.programming.kicks-ass.net) |
+### 4.3.8 Predict load based
+-------
+
+
+如果我们能够准确预测任务的未来负载, 那么我们就能在调度器上优化很多东西. 因此该补丁的工作是根据条件概率预测未来一段时间后的负载, 从而优化负载平衡、唤醒抢占、CPU 频率调整或其他任务.
+
+作者的想法是根据入队时的负载来预测出队时的负载. 该算法基于条件概率:
+
+`p(A|B) = p(AB)/p(B)`.
+
+要做到这一点, 我们需要在任务进入或离开运行队列(rq)时计算其负载量
+
+如果需要详细统计则需要使用一个二维数组来记录:
+
+`record_load_array[入队时负载 load1][出队时负载 load2] = count`
+
+在入队时，可以通过入队时负载 load1 预测出最有可能的出队时的负载 load2, 其中:
+
+`record_load_array[入队时负载 load1][出队时负载 load2] = max(record_load_array[入队时负载 load1]) ≤ 1024`
+
+最大负载为 1024, 这需要 1024 × 1024 × 8 位 = 1MB 的空间.
+
+考虑到每个任务都将维护这样一个二维数组, 其成本是难以接受的, 而且鉴于实际场景的复杂性, 用这个数组准确预测负载的可能性或许很小.
+
+因此作者做了两项优化:
+
+1. 第一项优化是将负载归一化到 0 至 1024(se->avg.load_avg 的最大值与其权重相关), 然后向右偏移 LOAD_GRAN_SHIFT(4), 这样它就代表了 16 的范围.
+
+例如, 如果负载为 893，那么 `893 >> 4 = 55`, `55 << 4 = 880`, 所以这意味着负载从 880 到 `896 = 880 + (1<<4)``.
+
+对于一个普通进程, se_weight = 1024, 每 1ms 的负载变化约为 `1024 * 1000 / 47742 = 21` ~~<16~~. 理论上, 统计误差不会超过 1 毫秒.
+
+2. 第二个优化是使用 Boyer-Moore 多数投票算法, 来记录最大可能的出队负载. 请参阅 record_predict_load_data() 的实现.
+
+通过这两项优化, 每个 record_load_array 只需要 128 字节的内存. 加上其他一些数据结构, 总共需要 176 字节的内存.
+
+根据实验, hackbench 场景负载预测的准确率约为 50% 至 70%.
+
+| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:---:|:----:|:---:|:----:|:---------:|:----:|
+| 2025/02/21 | zihan zhou <15645113830zzh@gmail.com> | [sched: Predict load based on conditional probability](https://lore.kernel.org/all/20250221084437.31284-1-15645113830zzh@gmail.com) | 如果我们能够准确预测任务的未来负载, 那么我们就能在调度器上优化很多东西. 因此该补丁的工作是根据条件概率预测未来一段时间后的负载, 从而优化负载平衡、唤醒抢占、CPU 频率调整或其他任务. | v1 ☐☑✓ | [LORE v1,0/4](https://lore.kernel.org/all/20250221084437.31284-1-15645113830zzh@gmail.com) |
+
+
## 4.4 Idle Balance
-------
@@ -2683,6 +2767,8 @@ Peter 将 sched/numa 的整体思路上也做了不断的调整和改动, 也开
| 2021/10/27 | Gang Li | [sched/numa: add per-process numa_balancing](https://lkml.org/lkml/2021/10/27/517) | 这个补丁在 prctl 中添加了一个新的 api PR_NUMA_BALANCING 来控制当个进程参与和禁止 numa_balancing. 在执行 numa_balancing 时, 大量的页面错误会导致性能损失. 因此, 那些关心最坏情况下性能的进程需要禁用 numa_balancing. 相反, 另一些则允许暂时的性能损失以换取更高的平均性能, 因此启用 numa 平衡对它们来说更好. 但是当前 numa balancing 只能由 `/proc/sys/kernel/numa_balancing` 全局控制. 因此这个特性希望禁用 / 启用每个进程的 numa_balancing. 在 mm_struct 下添加 numa_balancing. 然后在 task_tick_numa 中使用来控制. mm ->numa_balancing 仅在全局 numa_balancing 启用时有效. 当全局 numa_balancing 被禁用时, mm->numa_blancing 不会改变, 当你想要获得进程 numa_balancing 状态时, 你总是会得到 0, 并且当你使用 prctl set 它时, 内核将返回 err. | v1 ☐ | [LKML](https://lkml.org/lkml/2021/10/27/517)
*-*-*-*-*-*-*-*
[LORE v1,0/1](https://lore.kernel.org/r/20220224075227.27127-1-ligang.bdlg@bytedance.com)
*-*-*-*-*-*-*-*
[2022/09/29 LORE v4](https://lore.kernel.org/all/20220929064359.46932-1-ligang.bdlg@bytedance.com)
*-*-*-*-*-*-*-*
[2022/10/27 LORE v5,0/2](https://lore.kernel.org/all/20221027025302.45766-1-ligang.bdlg@bytedance.com)
*-*-*-*-*-*-*-*
[2023/04/13 LORE v6,0/2](https://lore.kernel.org/all/20230412140701.58337-1-ligang.bdlg@bytedance.com) |
| 2014/05/14 | Rik van Riel | [sched/numa: Allow task switch if load imbalance improves](https://linuxplumbersconf.org/event/4/contributions/480) | 目前 NUMA 平衡代码只允许在 NUMA 节点上的负载处于平衡状态时在 NUMA 节点之间移动任务. 当负载开始不平衡时, 它就崩溃了. 因此这个补丁引入 load_too_imbalanced() 来判定, 如果不平衡较小, 或者新的不平衡小于原来的不平衡, 则允许在 NUMA 节点之间移动任务. | v1 ☑ 3.16-rc1 | [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e63da03639cc9e6e83b62e7ef8ffdbb92421416a) |
| 2018/09/21 | Srikar Dronamraju | [sched/numa: Avoid task migration for small NUMA improvement](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6fd98e775f24fd41520928d345f5db3ff52bb35d) | 如果 NUMAC 层次的任务迁移带来的改进非常小 (小于 SMALLIMP), 那么应该尽量避免任务迁移. 否则可能会带来 pingpong(进程来回迁移颠簸), 甚至 cache-miss 引起的性能下降. | v1 ☑ 4.19-rc7 | [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6fd98e775f24fd41520928d345f5db3ff52bb35d) |
+| 2025/02/25 | Chen Yu | [sched/numa: Introduce per cgroup numa balance control](https://lore.kernel.org/all/cover.1740483690.git.yu.c.chen@intel.com) | TODO | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/cover.1740483690.git.yu.c.chen@intel.com) |
+
### 4.6.3 Scan Period Rate
-------
@@ -3079,11 +3165,11 @@ v3.13 实现 NUMA Balancing 执行 Task Placement 的过程中, task_numa_find_c
最早的时候, task_numa_migrate() 进行迁移决策的时候, 如果 numa_preferred_nid 上没有剩余 capacity, 就会跳过使用 task_numa_find_cpu() 从 numa_preferred_nid 上选择 dest_cpu/dest_task 的操作, 选择遍历系统中的其他 NUMA nodes 来查找 best_cpu(), 参照 [sched/numa: Favor placing a task on the preferred node](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2c8a50aa873a7e1d6cc0913362051ff9912dc6ca) 和 [sched/numa: Fix placement of workloads spread across multiple nodes](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e1dda8a797b59d7ec4b17e393152ec3273a552d5). 这直接造成了在完全过载的系统上工作负载 ** 无法进行 NUMA 聚合 ** 的问题.
-因此 v3.17 Rik van Riel 通过 [sched/numa: Ensure task_numa_migrate() checks the preferred node](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a43455a1d572daf7b730fe12eb747d1e17411365) 修复了问题. 移除了 task_numa_migrate() 中 has_free_capacity, 如果 numa_preferred_nid 上没有足够的 free_capacity, 也应该通过 task_numa_find_cpu() 选出一个 CPU 把进程迁移到 numa_preferred_nid 上. 通过即使首选节点完全繁忙时, 也依旧在其上寻找 best_cpu 来解决问题. 这种方法可以明显加快繁忙系统上任务的 NUMA 聚合. 作者测试在 4 节点系统上将 "perf bench numa mem-P4-T20-m-0-P1000" 从 15 分钟内不收敛改为在 10-20 秒内收敛. 当然可想可知, 这种策略暴力且直接, 但是又会 ** 造成 NUMA 过度聚合的问题 **, 工作负载集中在几个 NUMA 节点上, 而不是适当地分布在整个系统中, 导致系统可用内存带宽和可用 CPU 缓存减少, 从而导致可预测的性能问题.
+因此 v3.17 Rik van Riel 通过 [sched/numa: Ensure task_numa_migrate() checks the preferred node](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a43455a1d572daf7b730fe12eb747d1e17411365) 修复了问题. 移除了 task_numa_migrate() 中 has_free_capacity, 如果 numa_preferred_nid 上没有足够的 free_capacity, 也应该通过 task_numa_find_cpu() 选出一个 CPU 把进程迁移到 numa_preferred_nid 上. 通过即使首选节点完全繁忙时, 也依旧在其上寻找 best_cpu 来解决问题. 这种方法可以明显加快繁忙系统上任务的 NUMA 聚合. 作者测试在 4 节点系统上将 "perf bench numa mem-P4-T20-m-0-P1000" 从 15 分钟内不收敛改为在 10-20 秒内收敛. 当然可想可知, 这种策略暴力且直接, 但是又会 **造成 NUMA 过度聚合的问题**, 工作负载集中在几个 NUMA 节点上, 而不是适当地分布在整个系统中, 导致系统可用内存带宽和可用 CPU 缓存减少, 从而导致可预测的性能问题.
接着 Rik van Riel 继续对 NUMA 聚合进行了优化, 进一步加快了其聚合速度, 参见 [sched,numa: improve NUMA convergence times](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=a22b4b012340b988dbe7a58461d6fcc582f34aa0). 在 [load_too_imbalanced()](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0132c3e1777ceabc24c7d209b7cbe78c28c03c09) 中 [增加了 capacity 感知](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=28a21745190a0ca613cab817bfe3dc65373158bf), 并进一步扩大了 [其使用场景](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0132c3e1777ceabc24c7d209b7cbe78c28c03c09). 如果单纯迁移任务所能带来的改善 moveimp(Move Improve) 比交换带来的收益 env->best_imp 要高, 则倾向于进行迁移而不是交换, 此时会通过 [load_too_imbalanced() 决策是否允许迁移](https://elixir.bootlin.com/linux/v3.17/source/kernel/sched/fair.c#L1236), 注意此时有意设置改善的收益评分 imp 比 moveimp 略小, 即 imp = moveimp - 1, 这样 IDLE 的 CPU 仍然可以在后续的比较中胜出.
-而彼时 v3.16 刚引入 load_too_imbalance(), 这个允许在两个不均衡的 NUMA NODE 进行 NUMA Balancing Mirgarion. 在 task_numa_compare() 时只计算当前正在运行的任务, 但是如果页面被其他任务锁定, NUMA Hinting Faults 可能会导致任务阻塞. 这可能导致一个大型单一实例工作负载 (如 SPECjbb2005) 的所有线程迁移到同一个 NUMA 节点. 因为有时它们都在相同的几个页面上触发 NUMA Hinting Faults, 但是由于页面被 LOCKED 了, 所以每次只有持有页面的线程仍然可以运行, 然后该线程会被迁移到其首选的 NUMA 节点, 而由于其他进程都被 BLOCKED 了, 此时迁移并不会加剧不平衡. 最终造成所有的线程都依次被迁移到同一个节点上, 这种 NUMA 过度聚合的情况下有必要采取必要的手段 ** 阻止 NUMA 过度向同一节点聚合 **. v4.1 [commit 095bebf61a46 ("sched,numa: do not move past the balance point if unbalanced")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=095bebf61a460ad7f6a45bb17ddbf3a9df2b4397) 在 load_too_imbalanced() 中引入 move_load 流量限制, 通过对迁移负载 move_load 流量进行校验尝试解决 v3.16 可能引入的 NUMA 过度聚合的问题. 通过检查 NUMA Balancing Migration 的 [净移动的方向和流量 [move_load](https://elixir.bootlin.com/linux/v4.1/source/kernel/sched/fair.c#L1243), 并拒绝 NUMA 移动, 如果它会导致系统移动超过平衡点. 在不平衡状态下, 只有使我们更接近平衡点的动作才被允许. 但是这种改动只能单点规避问题, 阻止任务向同一个 NUMA 节点中过度聚合. 类似的问题依旧有很多. 另外任务的分散程度不可控, 这个修改策略在一些期望聚合场景下, 可能会进一步 ** 阻止 NUMA 聚合 **, 造成任务过于分散, 而在一些期望均衡 (分散) 的场景下, 可能又显得稍微有点集中.
+而彼时 v3.16 刚引入 load_too_imbalance(), 这个允许在两个不均衡的 NUMA NODE 进行 NUMA Balancing Mirgarion. 在 task_numa_compare() 时只计算当前正在运行的任务, 但是如果页面被其他任务锁定, NUMA Hinting Faults 可能会导致任务阻塞. 这可能导致一个大型单一实例工作负载 (如 SPECjbb2005) 的所有线程迁移到同一个 NUMA 节点. 因为有时它们都在相同的几个页面上触发 NUMA Hinting Faults, 但是由于页面被 LOCKED 了, 所以每次只有持有页面的线程仍然可以运行, 然后该线程会被迁移到其首选的 NUMA 节点, 而由于其他进程都被 BLOCKED 了, 此时迁移并不会加剧不平衡. 最终造成所有的线程都依次被迁移到同一个节点上, 这种 NUMA 过度聚合的情况下有必要采取必要的手段 **阻止 NUMA 过度向同一节点聚合**. v4.1 [commit 095bebf61a46 ("sched,numa: do not move past the balance point if unbalanced")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=095bebf61a460ad7f6a45bb17ddbf3a9df2b4397) 在 load_too_imbalanced() 中引入 move_load 流量限制, 通过对迁移负载 move_load 流量进行校验尝试解决 v3.16 可能引入的 NUMA 过度聚合的问题. 通过检查 NUMA Balancing Migration 的 [净移动的方向和流量 [move_load](https://elixir.bootlin.com/linux/v4.1/source/kernel/sched/fair.c#L1243), 并拒绝 NUMA 移动, 如果它会导致系统移动超过平衡点. 在不平衡状态下, 只有使我们更接近平衡点的动作才被允许. 但是这种改动只能单点规避问题, 阻止任务向同一个 NUMA 节点中过度聚合. 类似的问题依旧有很多. 另外任务的分散程度不可控, 这个修改策略在一些期望聚合场景下, 可能会进一步 **阻止 NUMA 聚合**, 造成任务过于分散, 而在一些期望均衡 (分散) 的场景下, 可能又显得稍微有点集中.
很快 v4.2 期间就发现上述这种粗暴的方式在系统负载没有过载的情况下又引入了性能回归, 特定工作负载集中在几个 NUMA 节点上, 而不是在整个系统中适当地分散. 这会导致可用内存带宽和可用 CPU 缓存的减少, 从而造成性能下降. 很明显, 造成这样的根本原因是 Load Balance 和 NUMA Balacning 之间的冲突和相互作用, 其中 Load Balance 关注的的短期负载与 NUMA Balacning 期望的基于的长期负载的统计不同. 因此如果过度聚合, 不合适. 如果分散, 那么分散到什么样的程度才比较合适的呢? v4.2 的 [numa,sched: resolve conflict between load balancing and NUMA balancing](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=6f9aad0bc37286c0441b57f0ba8cffee50715426) 中 [sched/numa: Only consider less busy nodes as numa balancing destinations](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6f9aad0bc37286c0441b57f0ba8cffee50715426) 尝试对此问题进行了修复, 尝试在 numa_preferred_nid 过载时, 通过考虑一个负载较轻的节点作为 NUMA Balacning 的目的地, 来弥补 Load Balance 和 NUMA Balacning 之间的冲突, 而不管任务是试图移动到首选节点, 还是转移到另一个节点. 这个补丁又重新引入了对 numa_preferred_nid 节点 numa_has_capacity() 的检查, 显然也解决了 v3.17 [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a43455a1d572daf7b730fe12eb747d1e17411365) 所引入的那个无法聚合的问题, 当时就是因为去掉了 numa_preferred_nid 的 capacity 的检查后, 造成 过载后线程永远不会迁移到它所使用内存的附近. 有了这种看起来很棒的机制, 那自然就对迁移负载 move_load 流量校验的规避方式进行了回退 [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e4991b240c622f0441c21f4869e13209abc08c5e). Jirka 在几个系统上运行了许多性能测试: 单实例 SpecJBB 2005 在 4 节点系统上的性能提高了 7-15%, 在每个 SOCKET 上拥有更多 CPU 的系统上有更高的增益. 多实例情况下, 性能也没有下降.
@@ -3465,6 +3551,7 @@ v4.13 引入 NUMA WAKE AFFINE 的时候测试发现, CPU 的空闲造成了 NAS
### 4.6.6 硬件辅助 NUMA FAULT
-------
+
| 论文 | 描述 | 实现 |
|:---:|:----:|:---:|
| [Traffic management: a holistic approach to memory placement on NUMA systems, ASPLOS 2013](https://dl.acm.org/doi/10.1145/2451116.2451157)| Carrefour 方案, 通过 AMD IBS 采样内存访问信息, 优化页面迁移. 减少不必要的迁移. | [Carrefour](https://github.com/Carrefour) |
@@ -3473,6 +3560,7 @@ v4.13 引入 NUMA WAKE AFFINE 的时候测试发现, CPU 的空闲造成了 NAS
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:---:|:----------:|:----:|
| 2023/02/08 | Bharata B Rao | [Memory access profiler(IBS) driven NUMA balancing](https://lore.kernel.org/all/20230208073533.715-1-bharata@amd.com) | 一些硬件平台可以提供有关内存访问的信息, 这些信息可用于在 NUMA 系统上进行最佳页面和任务放置. AMD 处理器有一个称为基于指令的采样 (IBS) 的硬件设施, 可用于收集与指令获取和执行活动相关的特定度量. 此工具可用于基于统计采样执行内存访问分析. 这组补丁实现了基于硬件获得的访问信息进行驱动 NUMA 平衡. 这样, 就不再需要周期性地扫描地址空间并引入 NUMA FAULT 来构建任务到页面的访问关联. 因此, 这里采用的方法是用硬件提供的访问信息替换地址空间扫描加提示错误. 从硬件获得的访问样本作为 NUMA FAULT 的等价信息被反馈到 NUMA BALANCING. NUMA BALANCING 逻辑的其余部分 (收集 / 聚合共享 / 私有 / 本地 / 远程故障并根据故障执行页面 / 任务迁移) 将保留, 但访问替换故障除外. [知乎-PMU 驱动的 NUMA Balancing](https://zhuanlan.zhihu.com/p/697689798). | v1 ☐☑✓ | [LORE v1,0/5](https://lore.kernel.org/all/20230208073533.715-1-bharata@amd.com) |
+| 2024/06/05 | 左泽(Ze Zuo) | [Memory access profiler(SPE) driven NUMA balancing](https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/PZI4KS7UGRNWTA27BZDOGMVXX26RDGCD) | 基于 ARM64 SPE 实现 PMU 辅助的 NUMA Balancing, 参见 [`openeuler/kernel/pulls/8642`](https://gitee.com/openeuler/kernel/pulls/8642) | v1 ☐☑✓ | [2024/06/03, LORE 00/10](https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/BEKEHPWCGSQS47RC76CZUESWWYWLDBHV)
*-*-*-*-*-*-*-*
[2024/06/03, LORE v3,00/10](https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/LEAQFPJHEPIGH6V4R5IJDP62DPG72RIX)
*-*-*-*-*-*-*-*
[2024/06/05, LORE v8,0/5](https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/BEKEHPWCGSQS47RC76CZUESWWYWLDBHV)
*-*-*-*-*-*-*-*
[2024/06/05, LORE v9,0/5](https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/PZI4KS7UGRNWTA27BZDOGMVXX26RDGCD/) |
### 4.6.7 学术研究
@@ -3954,12 +4042,7 @@ Oracle 数据库具有类似的虚拟化功能, 称为 Oracle Multitenant, 其
|:----:|:----:|:---:|:---:|:----------:|:----:|
| 2015/03/18 | Steven Rostedt | [sched/rt: Use IPI to trigger RT task push migration instead of pulling](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=b6366f048e0caff28af5335b7af2031266e1b06b) | 引入 RT_PUSH_IPI sched features, IPI 被发送到过载的 CPU 以进行被动的任务 PUSH. 在尝试触发 PULL 操作时, 默认不再执行 PULL, 而是依次通过 IPI 通知过载的 CPU(rtp_mask) PUSH 主动将任务出来.
1. 通常只向第一个过载的 CPU 发送一个 IPI. 它尝试推送它可以执行的任何任务, 然后查找下一个可以推送到 lowest CPU 的过载 CPU. 当所有过载的 CPU(其具有优先级大于 lowest CPU 的 pushable 任务) 被覆盖时, IPI 停止.
2. 如果 lowest CPU 再次降低其优先级, 则设置一个标志, 告知 IPI 遍历在源 CPU 之后重新启动第一个 RT 过载 CPU.
当 RT_PUSH_IPI 未启用时, 将实现获取 rq 锁并由 PULL CPU 主动从过载的 CPU PULL 任务出来执行的旧流程. 这用来解决极端场景下的 RQ 锁竞争问题. 通过将非过载 (比如空闲) 的 CPU 主动 PULL 的操作, 替换为过载任务被动串行的 PUSH 的操作, 减缓 RQ 锁冲突. | v5 ☑✓ 4.1-rc1 | [LORE](https://lore.kernel.org/all/20150318144946.2f3cc982@gandalf.local.home) |
-## 4.10 其他 Load Balancing 优化
--------
-| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
-|:----:|:----:|:---:|:---:|:----------:|:----:|
-| 2023/04/11 | Mathieu Desnoyers | [sched: Rate limit migrations](https://lore.kernel.org/all/20230411214116.361016-1-mathieu.desnoyers@efficios.com) | 将每个任务的迁移限制为每 SCHED_MIGRATION_WINDOW_NS(10ms) 窗口 SCHED_MIGRATION_LIMIT(32) 次. 具体的迁移计数和窗口大小可以通过 `kernel/sched/sched.h` 中的以下定义进行更改. | v1 ☐☑✓ | [LORE v1,0/1](https://lore.kernel.org/all/20230411214116.361016-1-mathieu.desnoyers@efficios.com) |
# 5 select_task_rq
@@ -4522,7 +4605,8 @@ Donnefort 称: 边距删除使内核能够充分利用能量模型, 任务更有
| 2021/05/04 | Pierre Gondois | [sched/fair: find_energy_efficient_cpu() enhancements](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=619e090c8e409e09bd3e8edcd5a73d83f689890c) | 防止 find_energy_efficient_cpu() 出现下溢. | v3 ☑✓ 5.14-rc1 | [LORE v3,0/2](https://lore.kernel.org/all/20210504090743.9688-1-Pierre.Gondois@arm.com) |
| 2021/12/20 | Vincent Donnefort | [Fix stuck overutilized](https://lkml.kernel.org/lkml/20211220114323.22811-1-vincent.donnefort@arm.com) | NA | v1 ☐ | [LORE 0/3](https://lkml.kernel.org/lkml/20211220114323.22811-1-vincent.donnefort@arm.com) |
| 2022/10/06 | Pierre Gondois | [sched/fair: feec() improvement](https://lore.kernel.org/all/20221006081052.3862167-1-pierre.gondois@arm.com) | TODO | v2 ☐☑✓ | [LORE v2,0/1](https://lore.kernel.org/all/20221006081052.3862167-1-pierre.gondois@arm.com) |
-| 2024/08/30 | Vincent Guittot | [sched/fair: Rework EAS to handle more cases](https://lore.kernel.org/all/20240830130309.2141697-1-vincent.guittot@linaro.org) | 该补丁集的主要目的是改进 Energy Aware Scheduler (EAS) 的实现, 以更好地处理某些特定情况, 并修复已知的一些局限性, 特别是与 uclamp(利用率钳位)特性相关的场景.
现有问题: 当前的 EAS 实现存在一些局限性, 在引入 uclamp 等新特性后变得更加明显. 例如, 任务可能会堆积在同一个 CPU 上, 或者被卡在错误的 CPU 上无法迁移, 导致调度效率下降.
目标: 通过一系列改动, 确保 EAS 能够更灵活地应对不同类型的负载和调度需求, 特别是在异构多核处理器(如大小核架构)上优化性能和功耗.
具体改动:
1. 修正 CPU 过载分类问题: [Patch 1](https://lore.kernel.org/all/20240830130309.2141697-2-vincent.guittot@linaro.org) 修复了当 CPU 被限制到较低的计算容量时, 可能被错误地分类为过载的问题. 由于 group_overloaded 的优先级高于 group_misfit, 这种错误分类可能导致周期性负载均衡器无法正确选择合适的 CPU 来放置任务. 通过修正这一问题, 可以将该组选为最繁忙的组, 而不是具有不匹配任务的组, 从而防止负载均衡选择将 MISFIT 的任务拉到错误的 CPU 上, 从而可以避免不必要的负载均衡操作, 提高调度精度.
2. 创建新的 EM 接口; Patch 2 引入了一个新的能量模型(EM, Energy Model)接口, 该接口将在后续补丁中用于改进任务放置逻辑.
优化任务放置策略: [Patch 3](https://lore.kernel.org/all/20240830130309.2141697-4-vincent.guittot@linaro.org) 改进了 feec() 任务放置策略, 首先在 PD 中寻找成本最低的 CPU, 然后在这些 CPU 之间寻找性能最高的 CPU. feec() 当前策略总是在 PD 中寻找具有最高备用容量的 CPU, 并假设它将是能效 PoV 中最好的 CPU, 因为它需要最小的 OPP 增加. 虽然一般来说这是正确的, 但此策略也会过滤其他一些 CPU, 这些 CPU 由于使用相同的 OPP, 效率更高. 事实上, 我们真正关心的是选择新的 OPP 来处理唤醒任务的成本. 在许多情况下, 多个 CPU 将终止向上选择相同的 OPP, 从而使用相同的能源成本. 在这些情况下, 我们可以使用其他指标来选择相同能源成本的最佳 CPU. 这个补丁就重写 feec(), 在选择目标 CPU 时不仅考虑空闲容量最高的 CPU, 还会评估其他因素, 如运行的任务数量等. 这有助于找到真正最优的放置位置, 而不仅仅是基于单一标准.
Patch 4 即使系统 overutilized, 也要继续通过 feec() 寻找能效最优的 CPU. 否则, 回退到调度器的默认性能和传播模式(performance and spread mode). 在测试中发现当工作队列的任务醒来进行短暂的后台工作(如vmstat更新)时, 系统可能会在短时间内过度使用, overutilized 时继续使用 feec() 寻找节能的 CPU 从而防止破坏任务的 power packing.
Patch 5: 继续对 EAS 进行优化, 解决更多特定场景下的问题, 确保调度器能够在各种情况下都表现出色. | v1 ☐☑✓ | [LORE v1,0/5](https://lore.kernel.org/all/20240830130309.2141697-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[LORE v2,0/7](https://lore.kernel.org/all/20241217160720.2397239-1-vincent.guittot@linaro.org) |
+| 2024/08/30 | Vincent Guittot | [sched/fair: Rework EAS to handle more cases](https://lore.kernel.org/all/20240830130309.2141697-1-vincent.guittot@linaro.org) | 该补丁集的主要目的是改进 Energy Aware Scheduler (EAS) 的实现, 以更好地处理某些特定情况, 并修复已知的一些局限性, 特别是与 uclamp(利用率钳位)特性相关的场景.
现有问题: 当前的 EAS 实现存在一些局限性, 在引入 uclamp 等新特性后变得更加明显. 例如, 任务可能会堆积在同一个 CPU 上, 或者被卡在错误的 CPU 上无法迁移, 导致调度效率下降.
目标: 通过一系列改动, 确保 EAS 能够更灵活地应对不同类型的负载和调度需求, 特别是在异构多核处理器(如大小核架构)上优化性能和功耗.
具体改动:
1. 修正 CPU 过载分类问题: [Patch 1](https://lore.kernel.org/all/20240830130309.2141697-2-vincent.guittot@linaro.org) 修复了当 CPU 被限制到较低的计算容量时, 可能被错误地分类为过载的问题. 由于 group_overloaded 的优先级高于 group_misfit, 这种错误分类可能导致周期性负载均衡器无法正确选择合适的 CPU 来放置任务. 通过修正这一问题, 可以将该组选为最繁忙的组, 而不是具有不匹配任务的组, 从而防止负载均衡选择将 MISFIT 的任务拉到错误的 CPU 上, 从而可以避免不必要的负载均衡操作, 提高调度精度.
2. 创建新的 EM 接口; Patch 2 引入了一个新的能量模型(EM, Energy Model)接口, 该接口将在后续补丁中用于改进任务放置逻辑.
优化任务放置策略: [Patch 3](https://lore.kernel.org/all/20240830130309.2141697-4-vincent.guittot@linaro.org) 改进了 feec() 任务放置策略, 首先在 PD 中寻找成本最低的 CPU, 然后在这些 CPU 之间寻找性能最高的 CPU. feec() 当前策略总是在 PD 中寻找具有最高备用容量的 CPU, 并假设它将是能效 PoV 中最好的 CPU, 因为它需要最小的 OPP 增加. 虽然一般来说这是正确的, 但此策略也会过滤其他一些 CPU, 这些 CPU 由于使用相同的 OPP, 效率更高. 事实上, 我们真正关心的是选择新的 OPP 来处理唤醒任务的成本. 在许多情况下, 多个 CPU 将终止向上选择相同的 OPP, 从而使用相同的能源成本. 在这些情况下, 我们可以使用其他指标来选择相同能源成本的最佳 CPU. 这个补丁就重写 feec(), 在选择目标 CPU 时不仅考虑空闲容量最高的 CPU, 还会评估其他因素, 如运行的任务数量等. 这有助于找到真正最优的放置位置, 而不仅仅是基于单一标准.
Patch 4 即使系统 overutilized, 也要继续通过 feec() 寻找能效最优的 CPU. 否则, 回退到调度器的默认性能和传播模式(performance and spread mode). 在测试中发现当工作队列的任务醒来进行短暂的后台工作(如vmstat更新)时, 系统可能会在短时间内过度使用, overutilized 时继续使用 feec() 寻找节能的 CPU 从而防止破坏任务的 power packing.
Patch 5: 继续对 EAS 进行优化, 解决更多特定场景下的问题, 确保调度器能够在各种情况下都表现出色. | v1 ☐☑✓ | [LORE v1,0/5](https://lore.kernel.org/all/20240830130309.2141697-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2024/12/17, LORE v2,0/7](https://lore.kernel.org/all/20241217160720.2397239-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2025/03/02, LORE v4,0/7](https://lore.kernel.org/all/20250302161321.1476139-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2025/03/02, LORE v5,0/7](https://lore.kernel.org/all/20250302210539.1563190-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2025/03/14, LORE v6,0/7](https://lore.kernel.org/all/20250314163614.1356125-1-vincent.guittot@linaro.org) |
+ |
@@ -4940,7 +5024,7 @@ EAS 基于唤醒事件来有效地将任务放置在系统上, 同样 MISFIT PLA
2. 国内 openharmony 的 Linux 内核也移植了此特性 check_for_migration @ [sched: optimization for Enery Aware Scheduling(EAS)](https://gitee.com/openharmony/kernel_linux_5.10/commit/1da88e1abe6064106efd395e4b54138f7d52d244).
-3. [sched/fair: Rework EAS to handle more cases](https://lore.kernel.org/all/20240830130309.2141697-1-vincent.guittot@linaro.org) 中 Patch 5, 也实现了类似的功能. ① task_tick_fair() 中通过 check_misfit_cpu() 如果发现当前任务是 MSFIT 的, 则通过 feec() 寻找一个能效最优的 CPU, 并使用 active_load_balance_cpu_stop() 进行 ACTIVE MIGRATION. ② 仿照 rt_rq, 引入 PUSH 机制. 在 cfs_rq 中引入 pushable_tasks 队列. 入队时对所有当前 CFS_RQ 上 MISFIT 的任务进行标记, 将这些任务插入 pushable_tasks. set_next_entity 时则通过 `queue_balance_callback(rq, &per_cpu(fair_push_head, rq->cpu), push_fair_tasks)` 主动将 MISFIT 的任务 PUSH 到 FIT 的 CPU 上.
+3. [sched/fair: Rework EAS to handle more cases](https://lore.kernel.org/all/20240830130309.2141697-1-vincent.guittot@linaro.org) 中 Patch 5 [`[PATCH 5/7 v5]` sched/fair: Add push task mechanism for EAS](https://lore.kernel.org/all/20250302210539.1563190-1-vincent.guittot@linaro.org), 也实现了类似的功能. ① task_tick_fair() 中通过 check_misfit_cpu() 如果发现当前任务是 MSFIT 的, 则通过 feec() 寻找一个能效最优的 CPU, 并使用 active_load_balance_cpu_stop() 进行 ACTIVE MIGRATION. ② 仿照 rt_rq, 引入 PUSH 机制. 在 cfs_rq 中引入 pushable_tasks 队列. 入队时对所有当前 CFS_RQ 上 MISFIT 的任务进行标记, 将这些任务插入 pushable_tasks. set_next_entity 时则通过 `queue_balance_callback(rq, &per_cpu(fair_push_head, rq->cpu), push_fair_tasks)` 主动将 MISFIT 的任务 PUSH 到 FIT 的 CPU 上.
#### 7.2.4.4 Capacity Aware Sched Class
@@ -5569,12 +5653,13 @@ schedtune 与 uclamp 都是由 ARM 公司的 Patrick Bellasi 主导开发.
|:-----:|:----:|:----:|:----:|:------------:|:----:|
| 2019/06/21 | Patrick Bellasi | [Add utilization clamping support](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=af24bde8df2029f067dc46aff0393c8f18ff6e2f) | TASK util clamp(Android schedtune 的主线替代方案, 只合入了前 11 个补丁. 实现任务的 UCLAMP, 每次进程出入队的时候, 会通过 uclamp_rq_inc_id()/uclamp_rq_dec_id() 更新 RQ 的 UCLAMP MIN/MAX. 然后 UCLAMP_MIN 和 UCLAMP_MAX 通过 uclamp_task_util 影响任务的 util, 从而影响其选核, 通过 uclamp_rq_util_with() 影响 RQ 的 util, 从而最终影响调频. | v10 ☑✓ 5.3-rc1 | [LORE v10,0/16](https://lore.kernel.org/all/20190621084217.8167-1-patrick.bellasi@arm.com) |
| 2019/08/22 | Patrick Bellasi | [Add utilization clamping support (CGroups API)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=0413d7f33e60751570fd6c179546bde2f7d82dcb) | TASK util clamp(Android schedtune 的主线替代方案) | v14 ☑✓ 5.4-rc1 | [LORE v14,0/6](https://lore.kernel.org/all/20190822132811.31294-1-patrick.bellasi@arm.com) |
-| 2024/02/01 | Hongyan Xia | [uclamp sum aggregation](https://lore.kernel.org/all/cover.1706792708.git.hongyan.xia2@arm.com) | 本系列通过跟踪任务和 cfs_rq 中的 util_ag_uclip 信号来解决 UCLAMP 的一系列问题. 在任务级别, p->se.avg.util_ag_uclip 基本上是跟踪正常的 util_avg, 但在其 uclamp 最小值和最大值内被箝住. rq->cfs.avg.util_avg_uclamp 是所有钳制值的总和, 这暗示了该 rq 应该运行的频率和利用率. 该建议与虚拟机工作负载的 util_cuest 系列有一些相似之处, 因为它为请求它的任务带来了所需的性能, 而不是为任务份额不可预测的 rq 带来了所期望的性能. 当然这同样会改变 UCLAMP 的预期行为. | v2 ☐☑✓ | [LORE v2,0/7](https://lore.kernel.org/all/cover.1706792708.git.hongyan.xia2@arm.com) |
+| 2024/02/01 | Hongyan Xia | [uclamp sum aggregation](https://lore.kernel.org/all/cover.1706792708.git.hongyan.xia2@arm.com) | 本系列通过跟踪任务和 cfs_rq 中的 util_ag_uclip 信号来解决 UCLAMP 的一系列问题. 在任务级别, p->se.avg.util_ag_uclip 基本上是跟踪正常的 util_avg, 但在其 uclamp 最小值和最大值内被箝住. rq->cfs.avg.util_avg_uclamp 是所有钳制值的总和, 这暗示了该 rq 应该运行的频率和利用率. 该建议与虚拟机工作负载的 util_cuest 系列有一些相似之处, 因为它为请求它的任务带来了所需的性能, 而不是为任务份额不可预测的 rq 带来了所期望的性能. 当然这同样会改变 UCLAMP 的预期行为. | v2 ☐☑✓ | [LORE v2,0/7](https://lore.kernel.org/all/cover.1706792708.git.hongyan.xia2@arm.com)
*-*-*-*-*-*-*-*
[2024/06/24, LORE, 0/7](https://lore.kernel.org/all/cover.1719223916.git.hongyan.xia2@arm.com)
*-*-*-*-*-*-*-*
[2024/05/07, LORE v3,0/7](https://lore.kernel.org/all/cover.1715082714.git.hongyan.xia2@arm.com/)
*-*-*-*-*-*-*-*
[2025/03/04, LORE v2,0/8](https://lore.kernel.org/all/cover.1741091349.git.hongyan.xia2@arm.com/) |
| 2023/11/22 | Vincent Guittot | [Rework interface between scheduler and schedutil governor](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=f12560779f9d734446508f3df17f5632e9aaa2c8) | 这个补丁集的目标是重新设计 Linux 内核中调度器 (scheduler) 与 schedutil 频率调节器 (governor) 之间的接口, 以提供更多的信息给后者, 从而让频率调节更加精确和高效. 在新的设计中, 调度器 (特别是 EAS) 不再需要猜测 governor 想要应用的余量 (headroom), 而是直接请求目标频率. 同时, governor 直接接收实际的利用率和新的最小、最大边界值, 以此选择目标频率, 不再需要处理调度器内部的细节, 包括了两个修改:
1. 在估计目标频率时考虑 ulamp 提示, 重新设计调度程序和 schedutil 治理器之间的接口 effective_cpu_util(), 以便将所有信息传递给 cpufreq schedutil. 使它能够根据实际的 CPU 利用率和 UCLAMP 边界 MIN/MAX 来选择目标频率, 而不是依赖调度器的利用率信号和 uclamp 性能提示的混合计算, 这种方法可能会导致信息丢失和不准确的假设.
2. I/O 等待提升的重构: 补丁改变了 iowait boost 的处理方式, 使其不再依赖于 uclamp_rq_util_with() 函数, 该函数原本用于将 I/O 等待提升限制在 uclamp(用户级 CPU 限制)范围之内. 取而代之的是, 补丁使用了在 sugov_get_util() 函数中已经计算出的 max 值来上限 iowait boost. | v4 ☐☑✓ v6.8-rc1 | [LORE v4,0/2](https://lore.kernel.org/all/20231122133904.446032-1-vincent.guittot@linaro.org) |
| 2021/12/16 | Qais Yousef | [uclamp_max vs schedutil fixes](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=d37aee9018e68b0d356195caefbb651910e0bbfa) | 解决 uclamp_max 与 schedutil 交互问题的两个补丁, 在使用 `sugov_update_single_{freq, perf}()` 的系统上, uclamp_max 功能由于 busy 过滤器的存在而变得无效. 该过滤器会在没有空闲时间的情况下忽略频率改变的请求, 而这在使用 uclamp 的系统上并不成立. 同样地, 被 uclamp_max 限制的 I/O 密集型任务仍能获得更高的频率, 因为 sugov_iowait_apply() 不会使用 uclamp_rq_util_with() 来钳制提升.
Yousef 提出的两个补丁解决了上述两个问题:
第一个补丁是关于在 uclamp 正在使用时忽略 “忙碌” 过滤器, 确保即使在系统繁忙时也能响应频率调整的请求.
第二个补丁修复了 I/O 等待提升逃逸 uclamp 限制的问题, 确保被 uclamp_max 约束的任务不会因 I/O 等待提升而获得超出限制的频率. | v1 ☐☑✓ v5.18-rc1 | [LORE v1,0/2](https://lore.kernel.org/all/20211216225320.2957053-1-qais.yousef@arm.com) |
+| 2025/02/27 | Hongyan Xia | [sched/uclamp: Let each sched_class handle uclamp](https://lore.kernel.org/all/84441660bef0a5e67fd09dc3787178d0276dad31.1740664400.git.hongyan.xia2@arm.com) | 在解决延迟 dequeue 问题的同时, uclamp 与 cpufreq 不同步, 尤其是在 enqueue_task() 中.
例如, 当带有 uclamp_min 的任务通过 enqueue_task() 并更新 cpufreq 时, 其 uclamp_min 甚至不会在 cpufreq 更新中被考虑. 只有在 enqueue 之后, uclamp_min 才会被添加到 rq buckets, 而 cpufreq 只会在下一次更新时接收它. 这与旧版本的行为截然不同, 旧版本中的 uclamp 值会在 enqueue 时立即生效. 更糟糕的是，像 fair.c 这样的子类会在使用率发生变化时发布 cpufreq 更新. 如果一段时间内利用率没有变化, 新的 uclamp 值就会进一步延迟.
因此, 让每个 sched_class 在自己的类中处理 uclamp, 以防延迟 dequeue 需要进一步调整或未来可能出现类似的变化, 并确保 uclamp 在 enqueue 时立即生效. 在 fair.c 中, 我们重新使用了 util_est 的防护逻辑. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/84441660bef0a5e67fd09dc3787178d0276dad31.1740664400.git.hongyan.xia2@arm.com) |
-### 7.5.1 Utilization Clamping 对 task_util 以及 cpu_freq 的影响
+### 7.5.2 Utilization Clamping 对 task_util 以及 cpu_freq 的影响
-------
@@ -5766,6 +5851,7 @@ CONFIG_SCHED_CORE_CTL 的方案, 不光通过 do_isolation_work_cpu_stop() 支
| 2024/02/12 | Ankur Arora | [PREEMPT_AUTO: support lazy rescheduling](https://lore.kernel.org/all/20240213055554.1802415-1-ankur.a.arora@oracle.com) | 本系列增加了一个新的调度模型 PREEMPT_AUTO, 它与 PREEMPT_DYNAMIC 一样, 允许在无 / 自愿 / 完全抢占模型之间进行动态切换. 然而, 与 PREEMPT_DYNAMIC 不同, 它不依赖于自愿模型的显式抢占点. 该系列基于托马斯在 [1](https://lore.kernel.org/lkml/87cyyfxd4k.ffs@tglx)、[2](https://lore.kernel.org/lkml/87led2wdj0.ffs@tglx) 和他的 [PoC](https://lore.kernel.org/lkml/87jzshhexi.ffs@tglx) 中概述的原始提议. 早期的 RFC 版本位于 [Make the kernel preemptible](https://lore.kernel.org/all/20231107215742.363031-1-ankur.a.arora@oracle.com).
PREEMPT_AUTO 的工作原理是始终启用 CONFIG_PREEMPTION(从而启用 PREEMPT_COUNT). 这意味着调度器总是可以安全地抢占. 这与 CONFIG_PREEMPT 相同. 有了这一点, 下一步是使重新调度策略取决于所选的调度模型. 目前, 调度程序使用一个需要重新调度的位(TIF_NEED_RESCHED) 来声明需要重新调度. PREEMPT_AUTO 通过添加一个额外的需求补救位 TIF_NEED_RESCHED_LAZY. | v1 ☐☑✓ | [LORE v1,0/30](https://lore.kernel.org/all/20240213055554.1802415-1-ankur.a.arora@oracle.com)
*-*-*-*-*-*-*-*
[LORE v2,00/35](https://lore.kernel.org/all/20240528003521.979836-1-ankur.a.arora@oracle.com) |
| 2024/10/07 | Peter Zijlstra | [sched: Lazy preemption muck](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=7c70cb94d29cd325fabe4a818c18613e3b9919a1) | 这组补丁的主要目的是为调度器添加懒惰抢占(lazy preemption)功能 CONFIG_PREEMPT_LAZY, 该模型通过将抢占请求延迟到 tick 边界来优化公平类抢占, 同时作为 RR/FIFO/DEADLINE 类的完全抢占. 懒惰抢占是一种优化技术, 旨在减少不必要的上下文切换, 提高系统的性能和响应时间. 引入 TIF_NEED_RESCHED_LAZY 标志, 用于标记任务需要懒惰抢占. 实现懒惰抢占模型, 允许任务在适当的时候进行抢占, 而不是立即进行. 处理懒惰抢占模式下的高延迟警告, 帮助调试和优化系统性能. 为 RCU 添加懒惰抢占支持, 确保在不同配置下的正确性和稳定性. 参见 [phoronix, 2024/11/06, Lazy Preemption "PREEMPT_LAZY" Slated To Land In Linux 6.13](https://www.phoronix.com/news/Linux-6.13-Lazy-Preemption) 和 [phoronix, 2024/11/19, Lazy Preemption Merged Along With Other Scheduler Improvements For Linux 6.13](https://www.phoronix.com/news/Linux-6.13-Sched-Lazy-Preempt). | v1 ☐☑✓ | [LORE v1,0/5](https://lore.kernel.org/all/20241007074609.447006177@infradead.org) |
| 2024/10/09 | Ankur Arora | [Lazy preemption bits](https://lore.kernel.org/all/20241009165411.3426937-1-ankur.a.arora@oracle.com) | 这组补丁的主要目的是为 Linux 内核添加 RCU(Read-Copy-Update)和调度器相关的懒惰抢占(Lazy preemption)功能. 懒惰抢占是一种优化技术, 旨在减少不必要的上下文切换, 提高系统的性能和响应时间. 包括 7 个补丁, 主要目标是: 为 RCU 添加懒惰抢占支持. 为调度器添加一些遗留的懒惰抢占功能, 解决与懒惰抢占相关的各种问题，如高延迟警告、配置限制等.
具体改动1. 添加 RCU 懒惰抢占支持: 限制 PREEMPT_RCU 配置, 以确保懒惰抢占的正确性.
2. 修复 rcu_all_qs() 的头文件保护, 以防止重复定义.
3. 处理 PREEMPT_RCU=n 且 PREEMPT_COUNT=y 时的静止状态
4. 将 PREEMPT_AUTO 重命名为 PREEMPT_LAZY, 以更好地反映其功能. | v1 ☐☑✓ | [LORE v1,0/7](https://lore.kernel.org/all/20241009165411.3426937-1-ankur.a.arora@oracle.com) |
+| 2025/03/14 | Sebastian Andrzej Siewior | [preempt: Add a generic function to return the preemption string.](https://lore.kernel.org/all/20250314160810.2373416-1-bigeasy@linutronix.de) | 主要目的是向 Linux 内核添加调度器规范监视器(scheduler specification monitors). 以下是该系列补丁的一些关键点:
1. 引入调度器跟踪点: 为 RV(Runtime Verification) 任务模型添加了与调度相关的跟踪点(tracepoints).
2. 支持嵌套监视器: 通过在 sysfs 监控文件夹中创建一个名为 sched 的监控器来实现对其他监控器的支持. 这个 sched 监控器本身是一个空容器, 用于容纳其他监控器. 控制这个 sched 监控器(启用、禁用、设置反应器)可以同时控制所有嵌套的监控器.
3. 新增多种监控器: 增加了每任务(per-task)和每 CPU(per-cpu)监控器, 如 snroc, scpd, snep, sncid 等. 添加了 sco 和 tss 每 CPU 监控器. 该系列补丁旨在使 Linux 内核能够更好地支持运行时验证, 特别是针对调度器的行为进行更细致的监控和验证. 这包括但不限于提高对不同调度策略和抢占模式下行为的理解, 以及帮助开发者更容易地发现和调试与调度相关的问题. 此外, 它还使得能够区分不同的预抢占禁用情况成为可能, 这对于确保系统的实时性和响应性至关重要. | v4 ☐☑✓ | [LORE v4,0/9](https://lore.kernel.org/all/20250314160810.2373416-1-bigeasy@linutronix.de) |
## 8.2 NO_HZ
@@ -6460,7 +6546,6 @@ $deadline_{se} = vruntime_{se} + slice \times \frac{weight_0}{weight_{se}}$
| 2024/05/24 | Chunxin Zang | [sched/fair: Reschedule the cfs_rq when current is ineligible](https://lore.kernel.org/all/20240524134011.270861-1-spring.cxz@gmail.com) | 作者发现有些任务运行了足够长的时间, 已经成为非法任务, 但它们仍未释放 CPU. 这会增加其他进程的调度延迟. 因此, 作者尝试在 wakeup_preempt 和 entity_tick 中检查当前进程, 如果是非法进程, 则重新调度该 cfs 队列. 当启用 RUN_TO_PARITY 时, 这一修改可以将调度延迟减少约 30%. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240524134011.270861-1-spring.cxz@gmail.com) |
| 2024/02/28 | Tobias Huschle | [sched/eevdf: sched feature to dismiss lag on wakeup](https://lore.kernel.org/all/20240228161018.14253-1-huschle@linux.ibm.com) | 旨在任务被唤醒时忽略其之前的延迟(lag).
背景: 之前的CFS(Completely Fair Scheduler)调度器通过在任务唤醒时从其虚拟运行时间(vruntime)中减去一定值, 增加了任务立即获得运行时间的机会. 这种特性被某些组件, 如 vhost, 用来确保特定的 kworker 在被唤醒后能够立即被调度执行. 然而, EEVDF 调度器目前并不支持这种行为.
问题: 在EEVDF调度器中, 如果一个被唤醒的实体带有之前执行的负延迟, 它将不得不等待当前时间片结束, 这可能会对期望立即执行的进程的性能产生负面影响.
提议的解决方案: Tobias 提出了实现 用于重新加入实体, 该策略忽略之前执行的延迟, 并允许被唤醒的任务立即运行(如果EEVDF没有认为其他实体更值得调度).
实现细节: 为了确保被唤醒的任务能够实际运行, vruntime 额外减去了 1. 这虽然不是严格按照之前讨论的策略来实现的, 但可以保证上述场景的预期行为. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240228161018.14253-1-huschle@linux.ibm.com) |
| 2024/10/31 | Tianchen Ding | [sched/eevdf: Force propagating min_slice of cfs_rq when a task changing slice](https://lore.kernel.org/all/20241031094822.30531-1-dtcccc@linux.alibaba.com) | 这组补丁的主要目的是为调度器的 eevdf(Enhanced Earliest Deadline First)调度类引入一个 cgroup 接口, 以便更好地控制和管理任务的切片(slice). | v2 ☐☑✓ | [LORE](https://lore.kernel.org/all/20241031094822.30531-1-dtcccc@linux.alibaba.com) |
-| 2024/11/13 | Prakash Sangappa | [Scheduler time slice extension](https://lore.kernel.org/all/20241113000126.967713-1-prakash.sangappa@oracle.com) | 这组补丁的主要目的是为 Linux 内核调度器引入一个机制, 允许用户线程请求额外的执行时间, 以完成关键区段的执行, 从而提高性能.
1. 引入每线程的用户-内核共享结构:
引入一个每线程的用户-内核共享结构, 该结构在用户空间和内核之间共享, 允许用户线程设置标志请求额外的执行时间, 内核可以访问并处理这些请求.
2. 实现调度器时间扩展机制: 实现调度器时间扩展机制, 允许用户线程请求额外的 50 微秒执行时间. 内核会启动一个定时器, 在定时器到期时抢占线程, 如果线程仍在运行.
3. 指示是否授予调度器抢占延迟请求: 在共享结构中添加标志, 指示内核是否授予了用户线程的抢占延迟请求. 用户线程可以通过检查这些标志来确定请求是否被授予.
4. 添加调度器抢占延迟授予统计信息: 添加统计信息，记录调度器授予的抢占延迟请求次数，以便进行性能分析和调试. | v1 ☐☑✓ | [LORE v1,0/4](https://lore.kernel.org/all/20241113000126.967713-1-prakash.sangappa@oracle.com) |
| 2024/10/31 | Tianchen Ding | [sched/eevdf: Introduce a cgroup interface for slice(PART1)](https://lore.kernel.org/all/20241028063313.8039-1-dtcccc@linux.alibaba.com) | TODO | v2 ☐☑✓ | [LORE](https://lore.kernel.org/all/20241028063313.8039-1-dtcccc@linux.alibaba.com) |
| 2025/02/08 | zihan zhou <15645113830zzh@gmail.com> | [sched: Reduce the default slice to avoid tasks getting an extra tick](https://lore.kernel.org/all/20250208074821.11832-1-15645113830zzh@gmail.com) | 该补丁旨在改进 Linux 内核调度器的精度, 具体来说是通过减少默认的时间片 (slice) 大小来避免任务获取额外的时钟周期(tick), 从而让调度更加精确.
主要内容包括
1. 时间片调整: 原有的默认时间片值为 0.75 毫秒乘以(1 + ilog(ncpus)). 这意味着对于不同的 CPU 数量有不同的默认时间片值. 将默认时间片从 0.75 毫秒调整为 0.70 毫秒例如, 对于 1 个 CPU, 默认时间片变为 0.70 毫秒; 对于多达 3 个 CPU, 默认时间片变为 1.40 毫秒; 多达 7 个 CPU 则为 2.10 毫秒; 8 个或更多 CPU 则是 2.8 毫秒.
调试相关更新: 通过 debugfs 更新 sysctl_sched_base_slice(系统控制参数, 用于设置调度器的基础时间片), 限制其值, 并更新 normalized_sysctl_sched_base_slice. 这样可以更好地控制和管理时间片相关参数, 提高调度的稳定性和可靠性
3. 解决的问题: 在 HZ=1000 且拥有 8 个或更多 CPU 的情况下, 尽管时钟周期的准确性已经足够好, 但由于时钟事件的精度和配置项(CONFIG_IRQ_TIME_ACCOUNTING/CONFIG_PARAVIRT_TIME_ACCOUNTING)的影响, 仍然存在任务会获得额外的时钟周期的问题. 这导致任务可能会运行比预期多出大约 1 毫秒的时间, 因为它们只能等待到下一个时钟周期才认为达到了其截止时间. | v3 ☐☑✓ | [LORE v3,0/2](https://lore.kernel.org/all/20250208074821.11832-1-15645113830zzh@gmail.com) |
@@ -6493,6 +6578,13 @@ EEVDF 的基础实现中, 具有较短时间片的任务将具有更早的虚拟
+### 8.9.6 Scheduler time slice extension
+-------
+
+| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:-----:|:----:|:----:|:----:|:------------:|:----:|
+| 2024/11/13 | Prakash Sangappa | [Scheduler time slice extension](https://lore.kernel.org/all/20241113000126.967713-1-prakash.sangappa@oracle.com) | 这组补丁的主要目的是为 Linux 内核调度器引入一个机制, 允许用户线程请求额外的执行时间, 以完成关键区段的执行, 从而提高性能.
1. 引入每线程的用户-内核共享结构:
引入一个每线程的用户-内核共享结构, 该结构在用户空间和内核之间共享, 允许用户线程设置标志请求额外的执行时间, 内核可以访问并处理这些请求.
2. 实现调度器时间扩展机制: 实现调度器时间扩展机制, 允许用户线程请求额外的 50 微秒执行时间. 内核会启动一个定时器, 在定时器到期时抢占线程, 如果线程仍在运行.
3. 指示是否授予调度器抢占延迟请求: 在共享结构中添加标志, 指示内核是否授予了用户线程的抢占延迟请求. 用户线程可以通过检查这些标志来确定请求是否被授予.
4. 添加调度器抢占延迟授予统计信息: 添加统计信息，记录调度器授予的抢占延迟请求次数，以便进行性能分析和调试. | v1 ☐☑✓ | [2024/11/13, LORE v1,0/4](https://lore.kernel.org/all/20241113000126.967713-1-prakash.sangappa@oracle.com)
*-*-*-*-*-*-*-*
[2025/02/15, LORE v1,0/2](https://lore.kernel.org/all/20250215005414.224409-1-prakash.sangappa@oracle.com) |
+| 2025/01/31 | Steven Rostedt | [sched: Extended Scheduler Time Slice](https://lore.kernel.org/all/20250131225837.972218232@goodmis.org) | 这是为了改进 user space implemented spin locks 或任务处于任何关键临界区. 它还可以扩展到虚拟机及 guest spin locks. 当任务在用户态处于关键临界区的时候, 要求调度器引入一个机制, 允许用户线程请求额外的执行时间, 以完成关键区段的执行, 从而提高性能.
这与 PREEMPT_LAZY 配合使用, 任务可以通过 rseq 结构告诉内核, 它正处于一个关键部分(如持有一个 user space spin locks)将很快离开, 并要求内核在此刻不要抢先执行.
这将在 struct rseq 中添加一个名为 cr_counter 的新字段, 其工作原理是, 在进入临界区段之前, 用户空间线程会将 cr_counter 增加 2. 如果任务时间耗尽且 NEED_RESCHED_LAZY 被设置, 那么在返回用户空间的途中, 内核将允许用户空间继续运行. 目前, 内核会让用户空间多运行一个 tick. 当内核允许线程有一些延长时间时, 它将设置 rseq cr_counter 的第 0 位, 以通知用户线程它获得了延长时间, 并应在离开临界区后立即调用系统调用.
当用户线程离开临界区段时, 它会将计数器递减 2. 如果计数器等于 1, 那么它就知道内核 就知道内核延长了它的时间片, 然后它将调用系统调用, 让内核调度它. 如果设置了 NEED_RESCHED, 那么 rseq 将被忽略, 内核将进行调度. 测试用例 [code/extend-sched.c](https://rostedt.org/code/extend-sched.c). | v1 ☐☑✓ | [LORE POC(https://lore.kernel.org/all/20231025054219.1acaa3dd@gandalf.local.home)
*-*-*-*-*-*-*-*
[LORE v1,0/2](https://lore.kernel.org/all/20250131225837.972218232@goodmis.org) |
## 8.10 混部场景
@@ -6816,6 +6908,7 @@ ANDROID 8 实现了 BINDER 对实时优先级传递的支持. 但是经过测试
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2017/10/26 | Martijn Coenen | [ANDROID: binder: RT priority inheritance](https://lore.kernel.org/all/20171026140750.119265-1-maco@android.com) | binder 支持 RT 优先级传递. | v3 ☐☑✓ | [LORE 00/13](https://lore.kernel.org/all/20170825093335.100892-1-maco@android.com)
*-*-*-*-*-*-*-*
[LORE v2,00/13](https://lore.kernel.org/all/20170831080430.118765-1-maco@android.com)
*-*-*-*-*-*-*-*
[LORE v3,0/6](https://lore.kernel.org/all/20171026140750.119265-1-maco@android.com) |
+| 2024/12/10 | Carlos Llamas | [binder: faster page installations](https://lore.kernel.org/all/20241210143114.661252-1-cmllamas@google.com) | [phoronix, 2024/12/27, Performance Improvements To Google's Binder Queued Ahead Of Linux 6.14](https://www.phoronix.com/news/Binder-Faster-Page-Installation) | v7 ☐☑✓ | [LORE v7,0/9](https://lore.kernel.org/all/20241210143114.661252-1-cmllamas@google.com) |
# 11 其他
@@ -7003,6 +7096,7 @@ LSFMMBPF 2024 上对 sched_ext 进行了讨论 [LWN, 2024/05/23, LSFMMBPF-2024,
| 2024/07/19 | Carlos Bilbao | [docs: scheduler: Start documenting the EEVDF scheduler](https://lore.kernel.org/all/20240720002207.444286-1-carlos.bilbao.osdev@gmail.com) | Carlos Bilbao 在更新 CFS(Completely Fair Scheduler) 文档的过程中意识到, 目前还没有指向 EEVDF 文档的资料, 因此他开始了这项工作. | v3 ☐☑✓ | [LORE v3,0/1](https://lore.kernel.org/all/20240720002207.444286-1-carlos.bilbao.osdev@gmail.com) |
| 2024/08/26 | Tejun Heo | [sched_ext: Add cgroup support](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=a4103eacc2ab408bb65e9902f0857b219fb489de) | TODO | v2 ☐☑✓ v6.12-rc1 | [2024/08/08, LORE v1, 0/7](https://lore.kernel.org/all/20240808002550.731248-1-tj@kernel.org)
*-*-*-*-*-*-*-*
[2024/08/26, LORE v2, 0/5](https://lore.kernel.org/all/20240826225822.791578-1-tj@kernel.org) |
| 2024/09/03 | Tejun Heo | [sched_ext: Apply pick_next_task() updates and remove switch_class()](https://lore.kernel.org/all/20240904080326.1132275-1-tj@kernel.org) | 这个补丁系列针对 Linux 内核调度器(scheduler)的扩展(sched_ext)进行了更新, 以适应内核主分支中对 pick_next_task() 函数的更新, 并移除了 switch_class() 函数. 以下是补丁系列的主要工作内容:
1. 更新 pick_next_task(): 补丁系列替换了 pick_next_task_scx() 函数, 引入了新的 pick_task_scx() 函数. 新函数不需要当前任务已经被排入队列, 并且能够不依赖于当前任务的状态来确定是选择当前任务还是本地直接队列(DSQ)顶部的任务. 统一常规和核心调度器的任务选择路径: 通过这次更新, 常规和基于核心的调度器的任务选择路径被统一, 简化了代码结构.
2. 移除 switch_class(): 在更新后, sched_class->switch_class() 不再被使用, 并从代码中移除. 这意味着调度器扩展不再需要这个接口.
3. 对 BPF 调度器的影响: 这次更改对基于 BPF(Berkeley Packet Filter)的调度器造成了两个微妙的 API 变化, 但这些变化是期望的, 并且现有的所有调度器都应该能够适应这些变化. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240904080326.1132275-1-tj@kernel.org) |
+| 2025/04/05 | Andrea Righi | [sched_ext: Enhance built-in idle selection with allowed CPUs](https://lore.kernel.org/all/20250405134041.13778-1-arighi@nvidia.com) | 许多 scx 调度程序实现了自己的硬性或软性亲和性规则, 以支持拓扑特性, 例如异构架构(例如 big.LITTLE、P 核/E 核), 或者根据特定属性对任务进行分类(例如，仅在 CPU 的子集上运行某些任务). 目前, 尚无机制能够将内置的空闲 CPU 选择策略应用于任意的 CPU 子集. 因此, 调度器通常会实现自己的空闲 CPU 选择策略, 这些策略通常彼此相似, 从而导致了大量的代码重复. 为解决此问题, 扩展内置的空闲 CPU 选择策略, 引入 allowed CPUs 概念.
基于这一概念, BPF 调度器可以将内置的空闲 CPU 选择策略应用于允许的 CPU 子集, 从而在使用内置策略的拓扑优化的同时实现自己的硬/软亲和性规则, 避免了不同调度器之间的代码重复.
为实现此功能, 引入一个新的辅助 kfunc 函数 scx_bpf_select_cpu_and(), 该函数接受一个允许的 CPU 集合的 cpumask: `s32 scx_bpf_select_cpu_and(struct task_struct *p, s32 prev_cpu, u64 wake_flags, const struct cpumask *cpus_allowed, u64 flags);`
在使用 virtme-ng 模拟的 4 插槽/每个插槽 4 核的系统上, 运行经过修改的 scx_bpfland 版本, 该版本使用新的辅助函数 scx_bpf_select_cpu_and() 并将允许域设置为 0xff00 时的负载分布情况, 通过 scx_bpf_select_cpu_dfl() 函数, 任务将在所有可用的 CPU 上均匀分布. | v7 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250405134041.13778-1-arighi@nvidia.com) |
##### 11.2.2.1.2 WAKE/LLC/NUMA 感知与支持
@@ -7014,6 +7108,8 @@ LSFMMBPF 2024 上对 sched_ext 进行了讨论 [LWN, 2024/05/23, LSFMMBPF-2024,
| 2024/10/23 | Andrea Righi | [sched_ext: Introduce LLC awareness to the default idle selection policy](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=dfa4ed29b18c5f26cd311b0da7f049dbb2a2b33b) | 主要目的是为 sched_ext 调度扩展模块中的默认空闲 CPU 选择策略引入 LLC(Last Level Cache) 意识. 这使得使用内置策略的调度器在具有多个 LLC 的系统中(如 NUMA 系统或基于芯片的架构)做出更明智的空闲 CPU 选择决策, 使得任务能够更好地保持在相同的 LLC 域内, 有效改善缓存局部性, 从而提高性能. LLC 意识目前仅应用于那些可以在系统中所有 CPU 上运行的任务. 如果任务的亲和性 (affinity) 被用户空间修改, 那么用户空间需要负责选择合适的优化调度域. 通过这些改动, sched_ext 调度器在处理多 LLC 系统时, 能够更有效地管理缓存资源, 进而提高整体的系统性能. 参见 phoronix 报道 [phoronix, 2024/10/28, Sched_ext Scheduler Idle Selection Being Extended For LLC & NUMA Awareness](https://www.phoronix.com/news/sched_ext-NUMA-Awareness) 和 [phoronix, 2024/11/22, Sched_Ext Changes Merged For Linux 6.13 With LLC & NUMA Awareness](https://www.phoronix.com/news/Linux-6.13-Sched_Ext). | v3 ☐☑✓ v6.13-rc1 | [LORE](https://lore.kernel.org/all/20241022234718.63258-1-arighi@nvidia.com) |
| 2024/10/27 | Andrea Righi | [sched_ext: Introduce NUMA awareness to the default idle selection policy](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=860a45219bce09d9ebac883cfcf9b5b0b8a8a999) | 为 sched_ext 模块引入了 NUMA 意识, 使其在选择空闲 CPU 时优先考虑同一 NUMA 节点内的 CPU. 类似于之前对 LLC(Last Level Cache)意识的支持. 其目的是在选择空闲 CPU 时优先考虑同一 NUMA 节点内的 CPU, 以优化性能和减少跨节点的通信延迟. 扩展内置的空闲 CPU 选择策略, 使其也优先考虑同一 NUMA 节点内的 CPU, 始终优先考虑来自完全空闲的 SMT 内核的 CPU. 如果可能，请选择相同的 CPU, 选择同一 LLC 域内的 CPU, 选择同一 NUMA 节点中的 CPU. 目前的逻辑仅试图让任务在同一 NUMA 节点内运行. 如果节点内的所有 CPU 都忙m 则随机选择下一个 NUMA 节点. 未来可以考虑改进 NUMA 节点的选择逻辑, 以考虑从当前 CPU 到目标 NUMA 节点的距离. 参见 phoronix 报道 [phoronix, 2024/10/28, Sched_ext Scheduler Idle Selection Being Extended For LLC & NUMA Awareness](https://www.phoronix.com/news/sched_ext-NUMA-Awareness) 和 [phoronix, 2024/11/22, Sched_Ext Changes Merged For Linux 6.13 With LLC & NUMA Awareness](https://www.phoronix.com/news/Linux-6.13-Sched_Ext).. | v3 ☐☑✓ v6.13-rc1 | [2024/10/27, LORE v4](https://lore.kernel.org/all/20241027174953.49655-1-arighi@nvidia.com)
*-*-*-*-*-*-*-*
[2024/10/25, LORE v5](https://lore.kernel.org/all/20241029101618.318812-1-arighi@nvidia.com) |
| 2024/11/08 | Andrea Righi | [sched_ext: Do not enable LLC/NUMA optimizations when domains overlap](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=f6ce6b949304bc7a54dbfea98402080c42bbc9a4) | 该补丁的主要目的是在 LLC(Last Level Cache)和 NUMA 域完全重叠时, 避免启用冗余的优化, 以提高调度器扩展策略的效率. 当 LLC 和 NUMA 域完全重叠时, 同时启用这两个域的优化是多余的, 因为这会导致两次在相同的域内搜索空闲 CPU. 此外, 如果所有在线 CPU 都在一个单一的 LLC 域内, 那么 LLC 优化也是不必要的. 因此, 此补丁通过检测重叠的域, 并仅在必要时启用拓扑优化来解决这个问题. | v3 ☐☑✓ v6.13-rc1 | [LORE](https://lore.kernel.org/all/20241108000136.184909-1-arighi@nvidia.com) |
+| 2025/02/26 | Andrea Righi | [selftests/sched_ext: Add NUMA-aware scheduler test](https://lore.kernel.org/all/20250226065057.151976-1-arighi@nvidia.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250226065057.151976-1-arighi@nvidia.com) |
+
##### 11.2.2.1.3 sched_ext per-node 数据拆分
-------
@@ -7027,6 +7123,12 @@ LSFMMBPF 2024 上对 sched_ext 进行了讨论 [LWN, 2024/05/23, LSFMMBPF-2024,
| 2024/09/24 | Tejun Heo | [sched_ext: Split %SCX_DSQ_GLOBAL per-node](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=6f34d8d382d64e7d8e77f5a9ddfd06f4c04937b0) | 这组补丁的主要目的是解决在 BPF 调度器的绕过模式 (bypass mode) 中出现的活锁(livelock)问题. 具体来说, 它将全局调度队列(DSQ)按 NUMA 节点拆分, 以减少跨节点的缓存行访问和调度, 从而提高系统的稳定性和性能. | v1 ☐☑✓ v6.13-rc1 | [LORE](https://lore.kernel.org/all/20240925000622.1972325-1-tj@kernel.org) |
| 2024/11/05 | Tejun Heo | [sched_ext: Avoid live-locking bypass mode switching](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=efe231d9debf6db812bebb262407c95b21cdb8a2) | TODO | v1 ☐☑✓ v6.13-rc1 | [LORE v1,0/2](https://lore.kernel.org/all/ZyqSm4B4NuzuHEbp@slm.duckdns.org) |
+##### 11.2.2.1.4 sched_ext debug
+-------
+
+| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:----:|:----:|:---:|:----:|:---------:|:----:|
+| 2025/03/04 | Changwoo Min | [sched_ext: Add trace point to sched_ext core events](https://lore.kernel.org/all/20250304104900.154618-1-changwoo@igalia.com) | TODO | v4 ☐☑✓ | [LORE v4,0/2](https://lore.kernel.org/all/20250304104900.154618-1-changwoo@igalia.com) |
#### 11.2.2.2 Google 的 ghOSt
@@ -7271,8 +7373,10 @@ ARM & Linaro 的内核团队针对 Android/linux 等做了大量的调度的优
|:----:|:----:|:---:|:---:|:----------:|:----:|
| 2014/04/16 | Alex Shi | [remove cpu_load idx](https://lore.kernel.org/patchwork/cover/456546) | 调度中使用 cpu_load 来做负载比较时非常错误的, 因此移除他们. | v5 ☐ | [PatchWork](https://lore.kernel.org/patchwork/cover/456546) |
| 2017/09/29 | Peter Zijlstra | [sched: Rework task state printing](https://lore.kernel.org/patchwork/cover/834387) | 重构进程状态的打印方式 | v1 ☑ 4.14-rc3 |[PatchWork](https://lore.kernel.org/patchwork/cover/834387) |
-| 2021/01/06 | Vincent Guittot | [sched: Remove per rq load array](https://lore.kernel.org/patchwork/cover/1079333) | 自 LB_BIAS 被禁用之后, 调度器只使用 rq->cpu_load[0] 作为 cpu 负载值, 因此 cpu_load 这个数组的其他之其实没意义了, 直接去掉了. 注意这对 load_balance 的调优是有一定影响的, 之前 sched_domain 中可以通过 sysctl 接口修改比较负载使用的 index, 这些 index 对应的 cpu_load 数组的下标. 干掉了这个数组, 那么这些 sysctl 也就没必要了 | v2 ☑ 5.10-rc1 | [PatchWork](https://lore.kernel.org/patchwork/cover/1079333) |
-| 2021/04/12 | Peter Zijlstra | [sched: Clean up SCHED_DEBUG](https://lore.kernel.org/patchwork/cover/1402660) | 目前内核有 sysctl, procfs 和 debugfs SCHED_DEBUG 接口, 比较混乱.
1. 将 CONFIG_LATENCYTOP 以及 sched_schedstats 和 NUMA balance 的 sysctl 开关都不再依赖于 CONFIG_SCHED_DEBUG
2. 将 [所有接口信息都转移到 debugfs 中](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d27e9ae2f244805bbdc730d85fba28685d2471e5).
3. 添加 ALT_PERIOD 和 BASE_SLICE feature. 考虑 cgroup 的情况, 添加了 ALT_PERIOD 计算__sched_period 实际实际的 h_nr_running, 添加 BASE_SLICE 保证进程的 sched_slice 至少达到 sysctl_sched_min_granularity]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c2de3f054a59f15e01804b75a04355c48de628c) | v2 ☑ 5.13-rc1 | [PatchWork](https://lore.kernel.org/patchwork/cover/1402660), [LKML](https://lkml.org/lkml/2021/3/26/395), [LORE](https://lore.kernel.org/all/20210412101421.609526370@infradead.org) |
+| 2021/01/06 | Vincent Guittot | [sched: Remove per rq load array](https://lore.kernel.org/patchwork/cover/1079333) | 自 LB_BIAS 被禁用之后, 调度器只使用 rq->cpu_load[0] 作为 cpu 负载值, 因此 cpu_load 这个数组的其他之其实没意义了, 直接去掉了. 注意这对 load_balance 的调优是有一定影响的, 之前 sched_domain 中可以通过 sysctl 接口修改比较负载使用的 index, 这些 index 对应的 cpu_load 数组的下标. 干掉了这个数组, 那么这些 sysctl 也就没必要了 | v2 ☑ 5.10-rc1 | [PatchWork](https://lore.kernel.org/patchwork/cover/1079333)|
+| 2021/04/12 | Peter Zijlstra | [sched: Clean up SCHED_DEBUG](https://lore.kernel.org/patchwork/cover/1402660) | 目前内核有 sysctl, procfs 和 debugfs SCHED_DEBUG 接口, 比较混乱.
1. 将 CONFIG_LATENCYTOP 以及 sched_schedstats 和 NUMA balance 的 sysctl 开关都不再依赖于 CONFIG_SCHED_DEBUG
2. 将 [所有接口信息都转移到 debugfs 中](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d27e9ae2f244805bbdc730d85fba28685d2471e5).
3. 添加 ALT_PERIOD 和 BASE_SLICE feature. 考虑 cgroup 的情况, 添加了 ALT_PERIOD 计算__sched_period 实际实际的 h_nr_running, 添加 BASE_SLICE, [保证进程的 sched_slice 要至少达到 `sysctl_sched_min_granularity`]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c2de3f054a59f15e01804b75a04355c48de628c) | v2 ☑ 5.13-rc1 | [PatchWork](https://lore.kernel.org/patchwork/cover/1402660), [LKML](https://lkml.org/lkml/2021/3/26/395), [LORE](https://lore.kernel.org/all/20210412101421.609526370@infradead.org)|
+| 2025/04/02 | Chen Yu | [sched/numa: Add statistics of numa balance task migration and swap](https://lore.kernel.org/all/20250402010611.3204674-1-yu.c.chen@intel.com) | 增加对 NUMA Balancing 任务迁移和交换的统计信息.
1. 问题: 在启用了 NUMA 平衡的系统中, 任务可能会因为 NUMA 平衡机制而迁移到其他 CPU 或与其他任务交换位置. 然而, 内核目前只提供了 NUMA 页面迁移的统计信息, 而没有提供任务迁移和交换的统计信息.
2. 目标: 通过增加任务迁移和交换的统计信息, 帮助系统管理员和开发者更好地理解和优化 NUMA 平衡机制.
3. 新增字段: numa_task_migrated: 记录任务迁移的次数, numa_task_swapped: 记录任务交换的次数. 这些统计信息将显示在 `/sys/fs/cgroup/{GROUP}/memory.stat` 和 `/proc/{PID}/sched` 中. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250402010611.3204674-1-yu.c.chen@intel.com) |
+
## 12.4 tools & benchmark
-------
diff --git a/study/kernel/00-DESCRIPTION/TODO.md b/study/kernel/00-DESCRIPTION/TODO.md
index bb58010..ac09793 100644
--- a/study/kernel/00-DESCRIPTION/TODO.md
+++ b/study/kernel/00-DESCRIPTION/TODO.md
@@ -631,7 +631,7 @@ cba6167f0adb
| 2024/03/25 | Shrikanth Hegde | [sched/fair: Simplify continue_balancing for newidle](https://lore.kernel.org/all/20240325153926.274284-1-sshegde@linux.ibm.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240325153926.274284-1-sshegde@linux.ibm.com) |
| 2021/11/12 | Vincent Guittot | [avoid spurious blocked load update](https://lore.kernel.org/all/20211112095857.7016-1-vincent.guittot@linaro.org) | TODO | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20211112095857.7016-1-vincent.guittot@linaro.org) |
| 2024/03/27 | Bharata B Rao | [Hot page promotion optimization for large address space](https://lore.kernel.org/all/20240327160237.2355-1-bharata@amd.com) | TODO | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20240327160237.2355-1-bharata@amd.com) |
-| 2024/05/06 | Qais Yousef | [sched: Consolidate cpufreq updates](https://lore.kernel.org/all/20240505233103.168766-1-qyousef@layalina.io) | TODO | v2 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240505233103.168766-1-qyousef@layalina.io) |
+| 2024/05/06 | Qais Yousef | [sched: Consolidate cpufreq updates](https://lore.kernel.org/all/20240505233103.168766-1-qyousef@layalina.io) | TODO | v2 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240505233103.168766-1-qyousef@layalina.io)
*-*-*-*-*-*-*-*
[LORE v8](https://lore.kernel.org/all/20250209235204.110989-1-qyousef@layalina.io) |
| 2024/03/28 | mingyang.cui | [sched/fair: Fix forked task check in vruntime_normalized](https://lore.kernel.org/all/20240328062757.29803-1-mingyang.cui@horizon.ai) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240328062757.29803-1-mingyang.cui@horizon.ai) |
| 2024/04/02 | Tio Zhang | [sched: make softirq cputime accounting separately in irqtime](https://lore.kernel.org/all/20240402112415.GA17946@didi-ThinkCentre-M930t-N000) | 我们现在在延迟统计中只能获得 IRQ/SOFTIRQ 的总延迟, 但单独获得 SOFTIRQ 延迟和 IRQ 延迟将有助于用户以更方便的方式减少此类延迟. 对于 IRQ 延迟, 我们可以调整 IRQ-CPU 相关性或使用线程 IRQ. 对于 SOFTIRQ 延迟, 我们可以调整 rps/xps 或使用 NAPI 的内核线程. 因此, 这个补丁集试图使 SOFTIRQ 延迟在延迟统计中可观察到, 并在 taskstats 中可用. 补丁集同步更新了 `tools/accounting/getdelays.c` 同样为了向后兼容性, 我们不想改变原始 IRQ/SOFTIRQ 延迟的含义, 相反, 我们可以通过原始 IRQ/OFTIRQ 的延迟减去该补丁添加的 SOFTIREQ 延迟来获得真实的 IRQ(中断) 延迟. | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20240402112415.GA17946@didi-ThinkCentre-M930t-N000) |
| 2024/03/29 | Chunxin Zang | [sched/fair: Reset vlag in dequeue when PLAGE_LAG is disabled](https://lore.kernel.org/all/20240329091933.340739-1-spring.cxz@gmail.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240329091933.340739-1-spring.cxz@gmail.com) |
@@ -809,19 +809,17 @@ https://lore.kernel.org/all/20240830130309.2141697-1-vincent.guittot@linaro.org/
| 2024/11/09 | Tejun Heo | [sched_ext: Rename dispatch and consume kfuncs](https://lore.kernel.org/all/20241109194853.580310-1-tj@kernel.org) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20241109194853.580310-1-tj@kernel.org) |
| 2024/11/19 | K Prateek Nayak | [sched/fair: Idle load balancer fixes for fallouts from IPI optimization to TIF_POLLING CPUs](https://lore.kernel.org/all/20241119054432.6405-1-kprateek.nayak@amd.com) | TODO | v5 ☐☑✓ | [LORE v5,0/4](https://lore.kernel.org/all/20241119054432.6405-1-kprateek.nayak@amd.com) |
| 2024/11/29 | Rafael J. Wysocki | [cpufreq: intel_pstate: Enable EAS on hybrid platforms without SMT](https://lore.kernel.org/all/5861970.DvuYhMxLoT@rjwysocki.net) | TODO | v21 ☐☑✓ | [LORE v21,0/9](https://lore.kernel.org/all/5861970.DvuYhMxLoT@rjwysocki.net) |
-| 2024/11/22 | Swapnil Sapkal | [perf sched: Introduce stats tool](https://lore.kernel.org/all/20241122084452.1064968-1-swapnil.sapkal@amd.com) | TODO | v2 ☐☑✓ | [LORE v2,0/6](https://lore.kernel.org/all/20241122084452.1064968-1-swapnil.sapkal@amd.com) |
| 2025/01/09 | Changwoo Min | [sched_ext: Support high-performance monotonically non-decreasing clock](https://lore.kernel.org/all/20250109131456.7055-1-changwoo@igalia.com) | TODO | v8 ☐☑✓ | [LORE v8,0/6](https://lore.kernel.org/all/20250109131456.7055-1-changwoo@igalia.com) |
| 2024/12/02 | Vincent Guittot | [sched/fair: Fix statistics with delayed dequeue](https://lore.kernel.org/all/20241202174606.4074512-1-vincent.guittot@linaro.org) | TODO | v3 ☐☑✓ | [LORE v3,0/11](https://lore.kernel.org/all/20241202174606.4074512-1-vincent.guittot@linaro.org) |
-| 2024/12/23 | K Prateek Nayak | [x86, sched: Dynamic ITMT core ranking support and some yak shaving](https://lore.kernel.org/all/20241223043407.1611-1-kprateek.nayak@amd.com) | TODO | v2 ☐☑✓ | [LORE v2,0/8](https://lore.kernel.org/all/20241223043407.1611-1-kprateek.nayak@amd.com) |
| 2024/12/12 | Vineeth Pillai (Google) | [sched/dlserver: flag to represent active status of dlserver](https://lore.kernel.org/all/20241213032244.877029-1-vineeth@bitbyteword.org) | TODO | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20241213032244.877029-1-vineeth@bitbyteword.org) |
| 2024/12/20 | Swapnil Sapkal | [Fixes and improvements in /proc/schedstat](https://lore.kernel.org/all/20241220063224.17767-1-swapnil.sapkal@amd.com) | TODO | v2 ☐☑✓ | [LORE v2,0/6](https://lore.kernel.org/all/20241220063224.17767-1-swapnil.sapkal@amd.com) |
| 2025/01/13 | Chuyi Zhou | [Take the scheduling domain into account in numa balancin](https://lore.kernel.org/all/20250113073050.2811925-1-zhouchuyi@bytedance.com) | TODO | v3 ☐☑✓ | [LORE v3,0/3](https://lore.kernel.org/all/20250113073050.2811925-1-zhouchuyi@bytedance.com) |
| 2025/01/06 | wujing | [sched/fair: Correct CPU selection from isolated domain](https://lore.kernel.org/all/tencent_160A5B6C838FD9A915A67E67914350EB1806@qq.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/tencent_160A5B6C838FD9A915A67E67914350EB1806@qq.com)|
| 2025/01/04 | Andrea Righi | [sched_ext: idle: small CPU iteration refactoring](https://lore.kernel.org/all/20250104090009.331193-1-arighi@nvidia.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250104090009.331193-1-arighi@nvidia.com) |
| 2025/01/08 | Honglei Wang | [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ý | [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) |
+| 2024/12/16 | Michal Koutný | [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)
*-*-*-*-*-*-*-*
[LORE v1,0/9](https://lore.kernel.org/all/20250210151239.50055-1-mkoutny@suse.com)
*-*-*-*-*-*-*-*
[LORE v2,00/10](https://lore.kernel.org/all/20250310170442.504716-1-mkoutny@suse.com/) |
| 2025/01/14 | Florian Schmaus | [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 | [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) |
+| 2024/12/04 | Tobias Huschle | [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)
*-*-*-*-*-*-*-*
[LORE v2,0/3](https://lore.kernel.org/all/20250217113252.21796-1-huschle@linux.ibm.com) |
| 2025/01/13 | I Hsin Cheng | [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 | [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 | [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) |
@@ -829,13 +827,18 @@ https://lore.kernel.org/all/20240830130309.2141697-1-vincent.guittot@linaro.org/
| 2025/01/26 | Changwoo Min | [sched_ext: Implement core event counters](https://lore.kernel.org/all/20250126101614.232388-1-changwoo@igalia.com) | TODO | v2 ☐☑✓ | [LORE v2,0/11](https://lore.kernel.org/all/20250126101614.232388-1-changwoo@igalia.com) |
| 2025/01/25 | Andrea Righi | [sched_ext: Move built-in idle CPU selection policy to a separate file](https://lore.kernel.org/all/20250125213911.283318-1-arighi@nvidia.com) | TODO | v2 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250125213911.283318-1-arighi@nvidia.com) |
| 2024/12/19 | Pierre Gondois | [sched/fair: Decrease util_est in presence of idle time](https://lore.kernel.org/all/20241219091207.2001051-1-pierre.gondois@arm.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20241219091207.2001051-1-pierre.gondois@arm.com) |
-| 2025/01/16 | Phil Auld | [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/12/23 | Hao Jia | [sched/core: Prioritize migrating eligible tasks in sched_balance_rq()](https://lore.kernel.org/all/20241223091446.90208-1-jiahao.kernel@gmail.com) | TODO | v2 ☐☑✓ | [LORE](https://lore.kernel.org/all/20241223091446.90208-1-jiahao.kernel@gmail.com) |
| 2025/02/04 | Changwoo Min | [sched_ext: Implement core event counters](https://lore.kernel.org/all/20250204052057.67776-1-changwoo@igalia.com) | TODO | v4 ☐☑✓ | [LORE v4,0/7](https://lore.kernel.org/all/20250204052057.67776-1-changwoo@igalia.com) |
| 2025/01/29 | Christian Loehle | [sched/debug: Print slice length for fair tasks](https://lore.kernel.org/all/453349b1-1637-42f5-a7b2-2385392b5956@arm.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/453349b1-1637-42f5-a7b2-2385392b5956@arm.com) |
| 2025/01/28 | Fernand Sieber | [sched: Add core cookie update tracepoint](https://lore.kernel.org/all/20250128113410.263994-1-sieberf@amazon.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250128113410.263994-1-sieberf@amazon.com) |
+| 2025/01/29 | Christian Loehle | [sched/debug: Print slice length for fair tasks](https://lore.kernel.org/all/453349b1-1637-42f5-a7b2-2385392b5956@arm.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/453349b1-1637-42f5-a7b2-2385392b5956@arm.com) |
+| 2025/02/07 | Changwoo Min | [sched_ext: Add a core event and update scx schedulers](https://lore.kernel.org/all/20250207031338.393045-1-changwoo@igalia.com) | TODO | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20250207031338.393045-1-changwoo@igalia.com) |
+| 2025/01/21 | zihan zhou <15645113830zzh@gmail.com> | [sched: Cancel the slice protection of the idle entity](https://lore.kernel.org/all/20250121030628.113497-1-15645113830zzh@gmail.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250121030628.113497-1-15645113830zzh@gmail.com) |
+| 2025/02/21 | Abel Wu | [Fix SCHED_IDLE behavior on wakeup preemption](https://lore.kernel.org/all/20250221111226.64455-1-wuyun.abel@bytedance.com) | TODO | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20250221111226.64455-1-wuyun.abel@bytedance.com) |
+| 2025/02/07 | Tejun Heo | [sched_ext: Event counter updates](https://lore.kernel.org/all/20250208084229.1274399-1-tj@kernel.org) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250208084229.1274399-1-tj@kernel.org) |
+| 2025/02/20 | Jemmy Wong | [sched: Refine scheduler naming for clarity and specificity](https://lore.kernel.org/all/20250219182020.393006-1-jemmywong512@gmail.com) | TODO | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20250219182020.393006-1-jemmywong512@gmail.com) |
+Event counter updates
[成大资工 - WIKI](https://wiki.csie.ncku.edu.tw/User/OscarShiang)
@@ -854,6 +857,30 @@ https://www.phoronix.com/news/Schedutil-30p-Speedometer-Boost
[Linux 6.14 Resource Control To Allow Total Memory Bandwidth Monitoring](https://www.phoronix.com/news/Linux-6.14-resctrl-Total-RAM-BW)
-[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)
+
+成坚 410881199005133515
+王盼盼 410881199101013601
+范小香 410827195708153524
+成梽 33010820200707137X
+
+https://www.phoronix.com/news/cpufreq_ext-RFC#google_vignette
+
+
+
+
+
+
+
+用例范围
+https://xarjbochz9n.feishu.cn/wiki/I03BwQQMDi5fMSkLRc0cW5iJnAf?open_in_browser=true
+
+
+整理好的所有164条测试样例。
+https://xarjbochz9n.feishu.cn/wiki/WBX8wziSMiVBxFkKNVXcGjEsnqb?from=from_copylink
+
+
+
+
+在 OSPM'25 上, 不少开发者建议使用推送任务机制来进行 idle balance 和 newidle balance. 借鉴了 [sched/fair: Rework EAS to handle more cases](https://lore.kernel.org/all/20240830130309.2141697-1-vincent.guittot@linaro.org) 的思路, 实现了一套统一的 CFS 任务推送框架, 并已针对 !EAS 场景进行了实现.
1. 该系列实现了 [Valentin 的想法](https://lore.kernel.org/lkml/xhsmh1putoxbz.mognet@vschneid-thinkpadt14sgen2i.remote.csb), 即在存在可推送任务的情况下, CPU 会将自身设置为每个 LLC 的"过载掩码(overloaded mask)".
2. NUMA 间的新空闲平衡机制对此做了优化, 会先遍历本地 LLC 上 overloaded mask 中的 CPU 集合, 然后遍历同一 NUMA 节点中其他 LLC 上 overloaded mask 中的 CPU 集合, 目的是将单个任务拉向自身, 而非执行全面的负载均衡.
3. 这实现了 [David Vernet 的 SAHRED_RUNQ 原型](https://lore.kernel.org/lkml/20231212003141.216236-1-void@manifault.com/) 中的一些想法, 不过, 与每个 LLC/每个分片使用一个单独的 SHARED_RUNQ 不同, 这里过载掩码用作指示符, 表明每个 CPU 的 rq 中包含可迁移到即将空闲的 CPU 的可推送任务. 这样做的代价是维护过载的 cpumask, 但避免了为每个 SHARED_RUNQ 设置锁.
4. 推送回调函数本身已进行了修改, 会尝试将可推送任务列表中的任务推送到"nohz.idle_cpus_mask"掩码中的某个 CPU 上, 从而减轻空闲平衡的负载.
diff --git a/study/kernel/00-DESCRIPTION/TOOLS.md b/study/kernel/00-DESCRIPTION/TOOLS.md
index 290519d..5c3904a 100644
--- a/study/kernel/00-DESCRIPTION/TOOLS.md
+++ b/study/kernel/00-DESCRIPTION/TOOLS.md
@@ -112,6 +112,10 @@ Intel 发布的 ControlFlag 用机器学习来发现代码中的错误, 支持 C
[phoronix, 2024/10/23, Gentoo Linux Touts DTrace 2.0 Support](https://www.phoronix.com/news/Gentoo-Linux-DTrace-2.0), [DTrace 2.0 for Gentoo](https://www.gentoo.org/news/2024/10/23/DTrace-for-Gentoo.html), [DTrace-WIKI](https://wiki.gentoo.org/wiki/DTrace)
+* kLLDB
+
+[djolertrk/kLLDB](https://github.com/djolertrk/kLLDB)
+
## 2.2 call kernel func from userspace
-------