diff --git a/study/ai/AIOS.MD b/study/ai/AIOS.MD new file mode 100644 index 0000000..22e53e6 --- /dev/null +++ b/study/ai/AIOS.MD @@ -0,0 +1,104 @@ +--- + +title: AI +date: 2021-02-15 00:32 +author: gatieme +tags: + - linux + - tools +categories: + - 技术积累 +thumbnail: +blogexcerpt: 虚拟化 & KVM 子系统 + +--- + +
+ +本作品采用 知识共享署名 - 非商业性使用 - 相同方式共享 4.0 国际许可协议 进行许可, 转载请注明出处, 谢谢合作 + + 知识共享许可协议 + +因本人技术水平和知识面有限, 内容如有纰漏或者需要修正的地方, 欢迎大家指正, 鄙人在此谢谢啦 + +** 转载请务必注明出处, 谢谢, 不胜感激 ** + +
+ +| 日期 | 作者 | GitHub| CSDN | BLOG | +| ------- |:-------:|:-------:|:-------:|:-------:| +| 2021-02-15 | [成坚 - gatieme](https://kernel.blog.csdn.net) | [`AderXCoding/system/tools/fzf`](https://github.com/gatieme/AderXCoding/tree/master/system/tools/fzf) | [使用模糊搜索神器 FZF 来提升办公体验](https://blog.csdn.net/gatieme/article/details/113828826) | [Using FZF to Improve Productivit](https://oskernellab.com/2021/02/15/2021/0215-0001-Using_FZF_to_Improve_Productivity)| + + +
+ +2 ** AI OS ** +===================== + + + + +**-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*　重要功能和时间点　-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*** + + + + + +下文将按此目录分析 Linux 内核中 MM 的重要功能和引入版本: + + + + +**-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 正文 -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*** + + +# 1 场景 +------- + +华擎的 AI QuickSet WSL 旨在通过 WSL 下的自动 ROCm 设置以及安装/配置流行的 AI 软件包以在 WSL+ROCm 下加速执行, 从而轻松"在 Windows 上运行 Linux AI 应用程序". 参见 [phoronix, 2025/09/15, ASRock AI Quickset WSL Aims To Make It Easier Running ROCm + AI Linux Apps On Windows](https://www.phoronix.com/news/ASRock-AI-QuickSet-WSL) + + +[知乎--机器之心--跟不上、读不完？上万篇顶会论文，这个工具一键分析](https://zhuanlan.zhihu.com/p/1968619277394346770) + +## 1.1 AI4OS +------- + + +[Learning-directed operating system (LDOS)](https://ldos.utexas.edu) 是德克萨斯大学奥斯汀分校的一个研究项目, 专注于开发基于机器学习的下一代作系统, 以提高效率和性能. 该项目旨在通过将机器学习驱动的方法集成到核心系统组件中, 通过"从头开始的范式"彻底改变作系统设计. 这包括优化资源分配、调度和拥塞控制机制，以动态适应不同的工作负载. +2025 年, LDOS 团队发表了两篇论文: "Canopy: Property-Driven Learning for Congestion Control" 探索了使用机器学习根据网络属性动态调整拥塞控制策略, "Large Language Models as Realistic Microservice Trace Generators" 应用 LLM 生成用于测试微服务的真实流量跟踪, 提高模拟模型的准确性. + + +| 日期 | 概要 | 论文 / 链接 | 团队 | 描述 | +|:---:|:----:|----------:|:----:|:----:| +| 2024/07 | 自动化故障定位、修复和分析 | [A Unified Debugging Approach via LLM-Based Multi-Agent Synergy](https://arxiv.org/abs/2404.17153) | NA | 大型语言模型 (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 有可能克服现有方法的过度拟合问题. | +| 2024/07 | AI 辅助 Linux 补丁测试 | [Testing AI-enhanced reviews for Linux patches](https://lwn.net/Articles/987319) | NA | 在 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) | +| 2025/09 || AI 辅助调度器 | [Towards Agentic OS: An LLM Agent Framework for Linux Schedulers](https://arxiv.org/abs/2509.01245) | 加州大学圣塔克鲁兹分校、上海科技大学等 | 内核的调度策略无法理解特定于应用程序的需求, 从而导致性能不佳. 实现介绍了 SchedCP 框架, 它使完全自主的 LLM 代理能够在没有人工参与的情况下安全高效地优化 Linux 调度器. 核心思想是, 挑战不仅在于应用更好的 LLM, 还在于构建一个解耦的控制平面, 将 AI 的语义推理角色("优化什么")与系统的执行角色("如何观察和行动")分开. SchedCP 作为模型上下文协议(MCP) 服务器实现, 提供了一个稳定的接口, 其中包含三个关键服务: 工作负载分析引擎、不断发展的调度器策略存储库和执行验证器, 用于验证所有 AI 生成的代码, 并在部署前通过静态和动态分析进行配置. sched-agent 是一个多 AGENT 系统, 可以自主分析工作负载, 合成自定义 eBPF 调度策略, 并通过 `sched_ext` 部署它们. 实现评估, 与朴素的代理方法相比, SchedCP 实现了高达 1.79 倍的性能提升和 13 倍的成本降低, 同时保持了较高的成功率. 通过弥合语义差距, SchedCP 使专家级系统优化民主化, 并代表着朝着创建真正自我优化、应用程序感知的作系统迈出的一步. 开源代码 [eunomia-bpf/schedcp](https://github.com/eunomia-bpf/schedCP). | +| 2025/07 | AI 辅助调度 Load Balancing | [LWN 2025/07/01, Improved load balancing with machine learning](https://lwn.net/Articles/1027096 | Free5GC | Ching-Chun("Jim") Huang 展示了其将 (本地) 机器学习应用于在复杂系统上调度器负载均衡的工作成果, [Improve Load Balancing with Machine Learning Techniques based on sched_ext Framework](https://static.sched.com/hosted_files/ossna2025/d2/Improve-Load-Balancing-With-Machine-Learning-Techniques-based-on-sched_ext.pdf). Free5GC 开发人员研究通过机器学习来改进调度器的负载均衡. 在此类系统上进行调度需要考虑许多输入维度; 此外, 调度程序还必须考虑每个任务的优先级、其 CPU 要求、到目前为止的虚拟运行时间以及最近的 CPU 使用模式. 必须考虑每个 CPU 上的负载, 以及 NUMA 距离、缓存共享和工作频率. 当然, 还有特定于工作负载的因素. 基于 scx_rusty 来尝试考虑所有这些参数并决定何时应该将任务从一个 CPU 移动到另一个 CPU. 它最初以数据收集模式运行, 查看迁移决策及其结果; 然后, 这些决策用于训练模型(在用户空间中), 该模型随后存储在 BPF 映射中. 然后, 调度程序可以在内核内使用此模型来做出负载平衡决策. 这些决策的结果会不断被测量并报告回用户空间, 从而随着时间的推移更新模型. 在使用最重要的内核编译基准测试的测试中, 该调度器的编译时间比 EEVDF 调度器缩短了 10%, 任务迁移的数量减少了 77%. Huang 总结了机器学习在这种情况下起作用的原因: 在这种复杂的环境中进行调度是一个模式识别问题, 而神经网络擅长这项任务. 调度程序能够平衡相互竞争的目标, 并自动针对新的架构和工作负载进行自我重新训练. 调度程序能够为每个迁移决策考虑 15 个单独的参数, 并根据结果调整其模型. [2025 Open Source Summit North America](https://events.linuxfoundation.org/open-source-summit-north-america), 参见 LWN 报道 [LWN 2025/07/01, Improved load balancing with machine learning](https://lwn.net/Articles/1027096), 代码 [scx_rusty](https://github.com/vax-r/scx/tree/scx_rusty_MLLB). | +| 2025/03 | AI 辅助 CPU/GPU 调频 | [An Intelligent Scheduling Approach on Mobile OS for Optimizing UI Smoothness and Power](https://dl.acm.org/doi/full/10.1145/3674910) | 提出了 MobiRL 一种基于强化学习的调度器, 用于智能地调整移动系统中的 CPU/GPU 频率, 以准确满足用户需求. MobiRL监测移动系统状态, 并通过执行 CPU/GPU 频率调整操作自主学习以优化用户界面的流畅度和功耗. 在最新交付的智能手机上的实验结果表明, MobiRL 在真实设备上的表现优于广泛使用的商业调度器——分别降低了 4.1% 的掉帧率和 42.8% 的功耗. 此外, 与使用 Q 学习进行 CPU 频率调度的研究相比, MobiRL 实现了最高 2.5% 的掉帧率降低, 并分别减少了 32.6% 的功耗. | +| 2025/03/25 | AI 辅助 CPU/GPU/DDR 调频 | [CRAVE: Analyzing Cross-Resource Interaction to Improve Energy Efficiency in Systems-on-Chip](https://dl.acm.org/doi/10.1145/3689031.3717498) | 提出了 CRAVE, 它利用学习到的设计特性来控制动态电压和频率调节. 在设计阶段, CRAVE 通过在三个主要移动系统组件(CPU内核、GPU和内存)的频率设置多元空间中采样, 为系统级芯片(SoC)确定最优的 DVFS 设置. 在运行时, CRAVE 以类似于当今操作系统内核中内置的现有简单调速器的方式监控资源利用率, 然后应用之前学习到的最优设置. 在两个真实的移动平台上实现了CRAVE: ODROID-XU4 和 NVIDIA Jetson TX2. 与最佳的内置 Linux 调速器相比, CRAVE 在 TX2 上将性能提高了20%, 同时能耗降低了 16%, 在 XU4 上也取得了类似的提升. 此外, 与最先进的应用驱动调速器相比, CRAVE 也表现出了一定的优势, 性能提高了 16%, 能耗节省了10%. | +| 2025/07/11 | AI 生成操作系统交互界面 | | [NeuralOS: Towards Simulating Operating Systems via Neural Generative Models](https://arxiv.org/abs/2507.08800) | 滑铁卢大学 | 名为 NeuralOS 的创新性神经框架. 其核心目标是利用深度生成模型, 完全模拟一个操作系统的图形用户界面(GUI). 不同于传统依赖预编程内核和应用程序的操作系统, NeuralOS 通过一个深度神经网络, 直接根据用户的输入(如鼠标移动、点击和键盘事件)来预测并生成屏幕的下一帧图像.
核心贡献可以概括为以下几点:
1. 提出新范式: 首次尝试将整个操作系统 GUI 交互过程建模为一个端到端的生成问题, 为实现完全自适应、个性化的未来人机交互界面提供了概念验证(Proof-of-Concept).
2. 设计创新架构: 提出了一种受传统操作系统启发的模块化架构, 该架构由一个负责追踪系统状态的循环神经网络(RNN)"内核"和一个负责生成屏幕图像的扩散模型"渲染器"组成, 有效处理了动态交互中的长期依赖和高保真视觉生成.
3. 开发有效训练策略: 设计了一套复杂的多阶段训练流程, 包括 RNN 预训练、联合训练、计划采样和课程学习等, 成功解决了直接训练生成式交互模型时遇到的梯度消失、渲染器忽略控制信号和误差累积等关键挑战.
4. 构建大规模数据集: 通过结合 AI Agent 的智能探索和随机探索, 建立了一个大规模、多样化的 Ubuntu XFCE 桌面交互数据集, 为训练此类复杂的交互模型奠定了基础. 参见 [知乎--周舒畅--远程桌面蒸馏成RNN+扩散模型：NeuralOS: Towards Simulating Operating Systems via Neural Generative Models](https://zhuanlan.zhihu.com/p/1928592949131863847) | +| 2025/10/21 | AI 实现补丁管理，实现补丁管理效率倍级提升| openEuler | [基于 openEuler Intelligence打造补丁管理智能体，实现补丁管理效率倍级提升](https://mp.weixin.qq.com/s/SwRTuH6iDISfD3QucNeOzw) | openEuler Intelligence 服务引擎, 实现操作系统级的 Agent 智能体与 MCP 工具管理, 提供全局、高效、低噪的智能服务框架. | + +## 1.2 OS4AI +------- + +| 日期 | 概要 | 论文 / 链接 | 团队 | 描述 | +|:---:|:----:|----------:|:----:|:----:| +| 2025/09 | AgentOS | [LLM as OS, Agents as Apps: Envisioning AIOS, Agents and the AIOS-Agent Ecosystem](https://arxiv.org/abs/2312.03815) | NA | 本文设想了一个革命性的 AIOS-Agent 生态系统, 其中大型语言模型 (LLM) 充当 (人工) 智能操作系统 (IOS, 或 AIOS)——一个 "有灵魂" 的操作系统. 在此基础上, 开发了各种 LLM 基于 AI 代理的应用程序 (Agents, 或 AAP), 丰富了 AIOS-Agent 生态系统, 标志着传统 OS-APP 生态系统的范式转变. 作者设想 LLM 其影响将不仅限于人工智能应用层面, 相反, 它将彻底改变计算机系统、架构、软件和编程语言的设计和实现, 其特点是几个主要概念: LLM 操作系统 (系统级)、代理即应用程序 (应用程序级)、自然语言作为编程接口 (用户级) 和工具即设备 / 库 (硬件 / 中间件级). 我们首先介绍传统操作系统的架构. 然后, 我们通过 "LLMas OS(LLMOS)" 正式化 AIOS 的概念框架, 将 AIOS 与传统操作系统进行类比: LLM 将上下文窗口比作操作系统内核, 将上下文窗口比作内存, 将外部存储比作文件系统, 将硬件工具比作外围设备, 将软件工具比作编程库, 将用户提示比作用户命令. 随后, 我们引入了新的 AIOS-Agent 生态系统, 用户可以使用自然语言轻松编程 Agent 应用程序 (AAP), 使软件开发民主化, 这与传统的 OS-APP 生态系统不同. 在此之后, 我们将探索代理应用程序的多样化范围. 我们深入研究了单智能体和多智能体系统, 以及人机交互. 最后, 借鉴传统 OS-APP 生态的洞察, 提出了 AIOS-Agent 生态演进的路线图. 该路线图旨在指导未来的研究和开发, 建议 AIOS 及其代理应用程序的系统性进展. | +| 2025/08 | 用于可扩展的 MoE(混合专家)LLM 推理的高性能框架 | [Expert Kit: A Distributed, Expert-Centric Framework for MoE LLM Inference](https://gitee.com/openeuler/expert-kit) | openEuler | openEuler 提供的 专家工具包 (EK) 是一个用于可扩展的 MoE(混合专家)LLM 推理的高性能框架. EK 的愿景是在商用网络(例如 PCIe、TCP、RDMA) 上的异构硬件 (例如 CPU 和 GPU) 上提供专家并行性 (EP)的高效基础, 从而实现轻松部署和细粒度的专家级扩展. | +| 2025/09 | decode 阶段自适应选择 CPU 核 | [MNN-AECS: Energy Optimization for LLM Decoding on Mobile Devices via Adaptive Core Selection](https://arxiv.org/abs/2506.19884) | NA | 分析显示, 受内存限制的 LLM 解码阶段在能耗中占主导地位, 然而, 大多数现有工作都集中在加速预填充阶段, 忽视了能效问题. 引入了自适应能效核心选择(AECS), 并将其集成到 MNN 中, 创建了能效版本 MNN-AECS, 这是首个无需 root 权限或操作系统修改即可实现能效 LLM 解码的引擎级系统解决方案. MNN-AECS 旨在通过动态选择低功耗 CPU 核, 在保持解码速度在可接受的减速阈值内的同时, 降低 LLM 解码的能耗. 作者在 5 款安卓设备和 2 款 iOS 设备上, 对 5 种不同规模的流行 LLM 进行了 MNN-AECS 评估. 与原始 MNN 相比, MNN-AECS 在所有 7 款设备和 4 个数据集上的平均能耗降低了 23%, 且速度没有减慢. 与其他引擎(包括 llama.cpp、executorch、mllm 和 MediaPipe)相比, MNN-AECS 平均能节省 39% 至 78% 的能耗, 并实现 12% 至 363% 的速度提升. | +| 2025/10 | Xsched 异构调度 | [支持 NPU 算力切分](https://gitee.com/openeuler/kernel/issues/IC5EHB) | openEuler | 基于 ARM64 + 910B 实现的 NPU 卡支持算力时分抢占特性, 支持 NPU share、带宽管控等特性.
算力时分抢占: 通过 AI 任务的算力抽象, 构建异构时分调度机制, 实现异构多任务毫秒级抢占, 多推理单卡调度抢占小于 10 毫秒;
+算力带宽管控: 基于算力带宽标准化语义, 构建任务级的算力管控分配机制, 实现算力隔离与共享, 提升吞吐. | +| 2025/10 | GPU eBPF profiling | NA | NA | |[知乎--云微--GPU可观测性差距：为什么我们需要GPU上的eBPF](https://zhuanlan.zhihu.com/p/1962141761364301211), [迈向可编程观测：在GPU Kernel中构建类eBPF风格的性能探针](https://developer.aliyun.com/article/1681315), [Neutrino: Fine-grained GPU Kernel Profiling via Programmable Probing, OSDI '25](https://github.com/open-neutrino/neutrino) | + + +
+ +* 本作品 / 博文 ([AderStep - 紫夜阑珊 - 青伶巷草 Copyright ©2013-2017](http://blog.csdn.net/gatieme) ), 由 [成坚 (gatieme)](http://blog.csdn.net/gatieme) 创作. + +* 采用 知识共享许可协议 知识共享署名 - 非商业性使用 - 相同方式共享 4.0 国际许可协议 进行许可. 欢迎转载、使用、重新发布, 但务必保留文章署名 [成坚 gatieme](http://blog.csdn.net/gatieme) (包含链接: http://blog.csdn.net/gatieme), 不得用于商业目的. + +* 基于本文修改后的作品务必以相同的许可发布. 如有任何疑问, 请与我联系. + +* ** 转载请务必注明出处, 谢谢, 不胜感激 ** +
diff --git a/study/kernel/00-DESCRIPTION/ARCH.md b/study/kernel/00-DESCRIPTION/ARCH.md index 8490034..3910230 100644 --- a/study/kernel/00-DESCRIPTION/ARCH.md +++ b/study/kernel/00-DESCRIPTION/ARCH.md @@ -1472,7 +1472,7 @@ AMD-pstate 驱动程序利用 ITMT 体系结构提供的功能和数据结构, | 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,00/10](https://lore.kernel.org/all/20250320095818.40622-1-pierre-eric.pelloux-prayer@amd.com)
*-*-*-*-*-*-*-*
[LORE v9, 00/10](https://lore.kernel.org/all/20250424083834.15518-1-pierre-eric.pelloux-prayer@amd.com)
*-*-*-*-*-*-*-*
[LORE v11, 00/10](https://lore.kernel.org/all/20250526125505.2360-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) | - +| 2026/01/04 | HongleiHuang-amd | [New AMD Linux Driver Patches Posted For Batch Userptr Allocation Support](https://www.phoronix.com/news/AMDKFD-Batch-Userptr-Allocation) | AMDKFD 内核计算驱动最近正在开发的一项新功能是支持批处理用户指针"userptr"分配. 有了这个新的用户空间 API, 将可以支持分配多个非连续的 CPU 虚拟地址范围, 这些地址映射到一个连续的 GPU 虚拟地址. 参加 [](https://www.phoronix.com/news/AMDKFD-Batch-Userptr-Allocation) | NA | [libhsakmt: Add batch userptr range registration API](https://github.com/ROCm/rocm-systems/commit/ac21716e5d6f68ec524e50eeef10d1d6ad7eae86) |
diff --git a/study/kernel/00-DESCRIPTION/BPF.md b/study/kernel/00-DESCRIPTION/BPF.md index 6a4e7d9..2edb17f 100644 --- a/study/kernel/00-DESCRIPTION/BPF.md +++ b/study/kernel/00-DESCRIPTION/BPF.md @@ -638,6 +638,13 @@ Wasmtime 完全开源, 使用 Rust 编程语言, 是的, 并且符合 WASI 标 [phoronix, 2025/03/26, Microsoft Announces Open-Source "Hyperlight Wasm" Project](https://www.phoronix.com/news/Microsoft-Hyperlight-Wasm) +## 9.2 Wasm-Linux +------- + +[LKML, 2025/11/01, Port of Linux to WebAssembly](https://lwn.net/ml/all/618f3602-03aa-46a8-b2d4-3c9798c4cd2b@icemanor.se), [linux-wasm](https://joelseverin.github.io/linux-wasm) + +[phoronix, 2025/12/01, Linux Kernel Ported To WebAssembly - Demo Lets You Run It In Your Web Browser](https://www.phoronix.com/news/Linux-Kernel-WebAssembly), [Linux/Wasm Page](https://joelseverin.github.io/linux-wasm), [Github, joelseverin/linux-wasm](https://github.com/joelseverin/linux-wasm/tree/master/patches) + # 10 云原生 ------- diff --git a/study/kernel/00-DESCRIPTION/DEBUGGING.md b/study/kernel/00-DESCRIPTION/DEBUGGING.md index 34240e7..4e7a04e 100644 --- a/study/kernel/00-DESCRIPTION/DEBUGGING.md +++ b/study/kernel/00-DESCRIPTION/DEBUGGING.md @@ -1360,6 +1360,14 @@ Fedora 尝试优化 systemd 开机以及重启的时间, 参见 phoronix 报道 | 2025/03/13 | Rahul Rameshbabu | [Initial work for Rust abstraction for HID device driver development](https://lore.kernel.org/all/20250313160220.6410-2-sergeantsagara@protonmail.com) | [phoronix, 2025/03/16, Linux Kernel's Rust Support Being Expanded To HID Drivers](https://www.phoronix.com/news/Linux-Rust-HID-Drivers-Patches) | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20250313160220.6410-2-sergeantsagara@protonmail.com)| | 2025/09/21 | [rust_binder: add Rust Binder driver](https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/commit/?h=char-misc-next&id=eafedbc7c050c44744fbdf80bdf3315e860b7513) | [phoronix, 2023/12/02, Google Rewriting Android's Binder In Rust With Promising Results](https://www.phoronix.com/news/Google-Linux-Binder-In-Rust), [phoronix, 2025/09/21, Linux 6.18 Expected To Land Google's Rust Binder Driver](https://www.phoronix.com/news/Rust-Binder-For-Linux-6.18) | + +### 21.1.2 Rex +------- + + +弗吉尼亚理工大学和伊利诺伊大学厄巴纳-香槟分校的研究人员在 2025 年 12 月于东京举办的 Linux Plumbers Conference 2025 上介绍了 Rex [LPC-2025, Rex and its integration with Rust-for-Linux](https://lpc.events/event/19/contributions/2190/). Rex 旨在为"安全且可用"的基于 Rust 的内核扩展而设计, 这些扩展可以替代 eBPF 程序, 用于扩展 Linux 内核功能. 参见 [phoronix, 2025/12/22, Rex: Proposed Safe Rust Kernel Extensions For The Linux Kernel, In Place Of eBPF](https://www.phoronix.com/news/Linux-Kernel-Rust-Rex), 代码可以参见 [github, RES](https://github.com/rex-rs/rex). + + ## 22.2 C++ ------- diff --git a/study/kernel/00-DESCRIPTION/LIVE_PATCH.md b/study/kernel/00-DESCRIPTION/LIVE_PATCH.md index b6e018e..18a96d6 100644 --- a/study/kernel/00-DESCRIPTION/LIVE_PATCH.md +++ b/study/kernel/00-DESCRIPTION/LIVE_PATCH.md @@ -478,4 +478,4 @@ kpatch 的实现一直是根据内核的进展而演进的, 对 JUMP_LABEL 的 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:---:|:----:|:---:|:----:|:---------:|:----:| -| 2025/03/20 | Pasha Tatashin | [Live Update Orchestrator](https://lore.kernel.org/all/20250320024011.2995837-1-pasha.tatashin@soleen.com) | LUO 旨在最小化停机时间的情况下, 促进实时内核更新. 它特别适用于云计算环境, 允许在不完全中断运行中的虚拟机的情况下进行管理程序更新, 通过在内核重启期间保持选定设备的运行状态来实现.
具体来说, 这个补丁系列包括三个部分:
1. Live Update Orchestrator (LUO): 这是一个新的内核子系统, 主要功能是协调内核的实时更新过程. 它包含一个状态机, 用于跟踪实时更新的进度, 并提供了一个回调 API, 让其他内核子系统可以参与到更新过程中来. 这些子系统包括 KVM、IOMMU、中断处理等.
2. 设备层基础设施 (dev_liveupdate): 引入了 dev_liveupdate 基础设施, 作为 LUO 的一部分使用, 支持设备的实时更新.
3. x86 架构支持: 在 x86 架构上启用了对 live update 的支持, 使该技术能够在基于 x86 的系统中应用.
总的来说, 这些补丁的目标是在内核升级时减少服务中断时间, 特别是对于云服务提供商而言, 这可以帮助他们在不影响客户业务连续性的前提下, 执行必要的维护和安全更新. 参见 [phoronix, 2025/03/20, Google Developing "Live Update Orchestrator" As New Means Of Live Linux Kernel Updates](https://www.phoronix.com/news/Google-Live-Update-Orchestrator) | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20250320024011.2995837-1-pasha.tatashin@soleen.com), [Linux 内核黑科技！Google 提出 LUO 挑战传统升级方式](https://mp.weixin.qq.com/s/RJAruIju_44U8oi8yTYTzw). | \ No newline at end of file +| 2025/03/20 | Pasha Tatashin | [Live Update Orchestrator](https://lore.kernel.org/all/20250320024011.2995837-1-pasha.tatashin@soleen.com) | LUO 旨在最小化停机时间的情况下, 促进实时内核更新. 它特别适用于云计算环境, 允许在不完全中断运行中的虚拟机的情况下进行管理程序更新, 通过在内核重启期间保持选定设备的运行状态来实现.
具体来说, 这个补丁系列包括三个部分:
1. Live Update Orchestrator (LUO): 这是一个新的内核子系统, 主要功能是协调内核的实时更新过程. 它包含一个状态机, 用于跟踪实时更新的进度, 并提供了一个回调 API, 让其他内核子系统可以参与到更新过程中来. 这些子系统包括 KVM、IOMMU、中断处理等.
2. 设备层基础设施 (dev_liveupdate): 引入了 dev_liveupdate 基础设施, 作为 LUO 的一部分使用, 支持设备的实时更新.
3. x86 架构支持: 在 x86 架构上启用了对 live update 的支持, 使该技术能够在基于 x86 的系统中应用.
总的来说, 这些补丁的目标是在内核升级时减少服务中断时间, 特别是对于云服务提供商而言, 这可以帮助他们在不影响客户业务连续性的前提下, 执行必要的维护和安全更新. 参见 [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), [phoronix, 2025/12/08, Live Update Orchestrator "LUO" Merged For Linux 6.19](https://www.phoronix.com/news/Linux-6.19-Live-Update-LUO), [Linux 内核黑科技！Google 提出 LUO 挑战传统升级方式](https://mp.weixin.qq.com/s/RJAruIju_44U8oi8yTYTzw). | | v1 ☐☑✓ | [2025/03/20, LORE v1,0/3](https://lore.kernel.org/all/20250320024011.2995837-1-pasha.tatashin@soleen.com)
*-*-*-*-*-*-*-*
[2025/11/25, LORE v8, 00/18](https://lore.kernel.org/all/20251125165850.3389713-1-pasha.tatashin@soleen.com) | \ No newline at end of file diff --git a/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md b/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md index 259d538..9e309c1 100644 --- a/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md +++ b/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md @@ -124,7 +124,8 @@ |:---:|:-------:| | 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) +| 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) | +| 2025 | [phoronix, 2025/12/27, Linux Kernel Highlights For 2025: Schedulers, Rust & Torvalds' Commentary](https://www.phoronix.com/news/Linux-Kernel-Highlights-2025) | # 6 业界会议 ------- diff --git a/study/kernel/00-DESCRIPTION/SCHEDULER.md b/study/kernel/00-DESCRIPTION/SCHEDULER.md index b36c29e..44d089d 100644 --- a/study/kernel/00-DESCRIPTION/SCHEDULER.md +++ b/study/kernel/00-DESCRIPTION/SCHEDULER.md @@ -69,6 +69,7 @@ git log --oneline v5.15...v5.16 | grep -E "Merge tag | Linux" | grep -E "sched| | 6.5 | NA | [Linux 6.5 To Enhance Load Balancing For Intel Hybrid CPUs](https://www.phoronix.com/news/Linux-6.5-Intel-Hybrid-Sched), [Scheduler changes for v6.5](https://lore.kernel.org/lkml/ZJq3HtUKZp2uMWLu@gmail.com) | | 6.10 | NA | [Linux 6.10 Scheduler Changes Bring More Refinements](https://phoronix.com/news/Linux-6.10-Scheduler), [[GIT PULL] Scheduler changes for v6.10](https://lore.kernel.org/lkml/ZkG0nxxBPB%2F03Q%2Fl@gmail.com) | | 6.14 | NA | [Many Scheduler Improvements Ready To Better Enhance The Linux 6.14 Kernel](https://www.phoronix.com/news/Linux-6.14-Scheduler) | +| 6.19 | NA | [phoronix, 2025/12/02, Optimized NUMA Distances For Intel GNR & CWF, Other Scheduler Improvements In Linux 6.19](https://www.phoronix.com/news/Linux-6.19-Scheduler) cgit 上查看 sched 所有的 log 信息 : @@ -679,6 +680,7 @@ coscheduling 协同调度是为了解决云服务场景, 为不同用户提供 | 2024/03/07 | Cruz Zhao | [introduce CPUTIME_FORCEIDLE_TASK and add](https://lore.kernel.org/all/20240307101945.11280-1-CruzZhao@linux.alibaba.com) | 由于 core sched 使用 rq_clock() 作为时钟源来计算 forceidle 时间, irq 时间将被计入 forceidle. 然而, 在某些情况下, forceidle sum 将比 exec 运行时大得多, 例如, 我们观察到调用 futex_wake() 的任务的 forceidle 时间比 exec 运行时大 50%, 这令人困惑. 我们使用 rq_clock_TASK() 作为时钟源, 引入 cpustat[CPUTIME_FORCEIDLE_TASK] 来计算 SMT 兄弟被强制空闲时任务实际运行的时间. | v2 ☐☑✓ | [2024/02/19, LORE](https://lore.kernel.org/all/20240219084134.10673-1-CruzZhao@linux.alibaba.com)
*-*-*-*-*-*-*-*
[2024/03/07, LORE v2,0/3](https://lore.kernel.org/all/20240307101945.11280-1-CruzZhao@linux.alibaba.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/09/22 | Fernand Sieber | [sched/fair: Core sched wake up path improvements](https://lore.kernel.org/all/cover.1758543008.git.sieberf@amazon.com) | 该邮件由 Fernand Sieber 提交, 包含 4 个补丁, 旨在改进 Linux 调度器( fair scheduler) 的唤醒路径, 提升任务调度效率, 减少不必要的空闲( force idle) . 主要改进点包括:
1. 修复慢路径中错误的 cookie 匹配逻辑, 避免误判空闲核心;
2. 在未找到匹配 cookie时优化回退逻辑, 提升调度准确性;
3. 快路径中增加 cookie 检查, 防止唤醒空闲 CPU;
4. 在选择空闲任务时增强对 cookie 的考量, 提升任务放置效率. | v1 ☐☑✓ | [2025/09/22, LORE v1, 0/4](https://lore.kernel.org/all/cover.1758543008.git.sieberf@amazon.com) | +| 2025/11/28 | Fernand Sieber | [sched/core: Push tasks on force idle](https://lore.kernel.org/all/20251128131954.324423-1-sieberf@amazon.com) | 旨在优化 CPU 进入 force idle 状态时的任务处理逻辑. 当前逻辑中, 若 CPU 无法从其他 CPU "偷取" 匹配 cookie 的任务, 则只能依赖新空闲平衡(new idle balance), 但其无法保证获取到匹配的任务, 导致调度效率下降.
为此, 补丁新增 `forceidle_push_tasks` 函数, 在 force idle 阶段尝试将当前 CPU 上可运行的任务推送到更合适的 CPU 上, 提升调度效率.
测试基于 64 核系统, 运行 8 个虚拟机, 其中 7 个运行压力测试, 1 个运行硬件延迟追踪器. 结果显示, 该补丁将平均" 噪声" 从 1. 20% 降低至 0. 66%, 降幅达 45%. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20251128131954.324423-1-sieberf@amazon.com) | #### 1.5.4.3 SMT 驱离 (SMT expeller) 技术 @@ -887,7 +889,7 @@ Chang 的 patch set 采用了与之前不同的方法: 允许 cgroup 将一些 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| -| 2025/06/05 | Yuri Andriaccio | [Hierarchical Constant Bandwidth Server](https://lore.kernel.org/all/20250605071412.139240-1-yurand2000@gmail.com) | 介绍了一个实现分层常量带宽服务器 (HCBS) 的补丁集 RFC, 旨在替代现有的 `RT_GROUP_SCHED` 机制, 使其更具鲁棒性和理论基础. 该补丁集已在 OSPM25 会议上展示, 相关机制详见[LWN 文章](https://lwn.net/Articles/1021332).
补丁内容包括代码重构、单层与多层调度支持、cgroup v2 支持, 并移除了 cgroup v1 的相关代码. 通过为每个 CPU 创建本地运行队列和 dl_server, 实现对 SCHED_FIFO/SCHED_RR 任务的带宽预留, 用户可通过 cgroup 接口配置 `rt_period_us` 和 `rt_runtime_us`.
测试代码已提供, 支持在 QEMU 或完整发行版中运行, 验证调度器的功能与时序保障. 作者表示后续将提交支持任务迁移、每 CPU 独立带宽、容量感知调度等特性.
该补丁集目前以打基础为主, 邀请社区反馈以指导后续开发. | v1 ☐☑✓ | [2025/06/05, LORE v1, 0/9](https://lore.kernel.org/all/20250605071412.139240-1-yurand2000@gmail.com)
*-*-*-*-*-*-*-*
[2025/07/31, LORE RFC v2, 00/25](https://lore.kernel.org/all/20250731105543.40832-1-yurand2000@gmail.com)
*-*-*-*-*-*-*-*
[2025/09/29, LORE v3, 00/24](https://lore.kernel.org/all/20250929092221.10947-1-yurand2000@gmail.com) | +| 2025/06/05 | Yuri Andriaccio | [Hierarchical Constant Bandwidth Server](https://lore.kernel.org/all/20250605071412.139240-1-yurand2000@gmail.com) | 介绍了一个实现分层常量带宽服务器 (HCBS) 的补丁集 RFC, 旨在替代现有的 `RT_GROUP_SCHED` 机制, 使其更具鲁棒性和理论基础. 该补丁集已在 OSPM25 会议上展示, 相关机制详见[LWN 文章](https://lwn.net/Articles/1021332).
补丁内容包括代码重构、单层与多层调度支持、cgroup v2 支持, 并移除了 cgroup v1 的相关代码. 通过为每个 CPU 创建本地运行队列和 dl_server, 实现对 SCHED_FIFO/SCHED_RR 任务的带宽预留, 用户可通过 cgroup 接口配置 `rt_period_us` 和 `rt_runtime_us`.
测试代码已提供, 支持在 QEMU 或完整发行版中运行, 验证调度器的功能与时序保障. 作者表示后续将提交支持任务迁移、每 CPU 独立带宽、容量感知调度等特性.
该补丁集目前以打基础为主, 邀请社区反馈以指导后续开发. | v1 ☐☑✓ | [2025/06/05, LORE v1, 0/9](https://lore.kernel.org/all/20250605071412.139240-1-yurand2000@gmail.com)
*-*-*-*-*-*-*-*
[2025/07/31, LORE RFC v2, 00/25](https://lore.kernel.org/all/20250731105543.40832-1-yurand2000@gmail.com)
*-*-*-*-*-*-*-*
[2025/09/29, LORE v3, 00/24](https://lore.kernel.org/all/20250929092221.10947-1-yurand2000@gmail.com)
*-*-*-*-*-*-*-*
[2025/12/01, LORE v4, 00/28](https://lore.kernel.org/all/20251201124205.11169-1-yurand2000@gmail.com) | | 2025/07/07 | Pan Deng | [sched/rt: mitigate root_domain cache line contention](https://lore.kernel.org/all/cover.1751852370.git.pan.deng@intel.com) | 这组补丁旨在缓解在云环境中运行多实例 FFmpeg 任务时, 因实时任务调度引发的 `root_domain` 缓存行争用问题. 测试环境为 2 路、240 核、480 线程的机器, 运行 60 个 FFmpeg 实例, 每个绑定 4 个物理核. 性能分析显示, 约 20% 的 CPU 周期消耗在内核调度函数, 主要由于 `root_domain` 和 `cpupri` 结构的缓存行争用.
补丁内容包括:
1. 优化 `cpupri_vec` 布局, 分离 `count` 和 `mask` 字段, 减少缓存行争用.
2. 重构 `root_domain` 结构, 合理重排字段以降低争用.
3. 将 `rto_count` 拆分为每个 NUMA 节点计数器.
4. 将 `cpupri_vec-> mask` 拆分为每个 NUMA 节点的位图.
实测结果显示, 各补丁带来了 3. 8%~11% 的 FPS 提升, 内核 CPU 使用率降至 11%~18. 7%, 缓存行争用显著下降. | v1 ☐☑✓ | [2025/07/07, LORE v1, 0/4](https://lore.kernel.org/all/cover.1751852370.git.pan.deng@intel.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) | [phoronix, 2025/05/27, Linux 6.16 Lands "rt_group_sched" Option, Faster Core Offlining & Scheduler Improvements](https://www.phoronix.com/news/Linux-6.16-Scheduler) | 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/) | @@ -2131,6 +2133,9 @@ update_blocked_averages() 在多个场景都被发现成为非常严重的性能 | 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) | | 2023/12/11 | David Vernet | [sched: Implement shared runqueue in fair.c](https://lore.kernel.org/all/20231212003141.216236-1-void@manifault.com) | 调度器必须不断地在工作保护和避免代价高昂的迁移之间取得平衡, 迁移会因为缓存局部性降低而损害性能. 系统的拓扑结构使问题进一步复杂化. 在同一个 LLC 上的核心之间迁移任务可能比将任务保留在 CPU 本地更理想, 而在 LLC 或 NUMA 节点之间迁移任务可能会使平衡向另一个方向倾斜. 考虑到这一点, 虽然 CFS 基本上是一个节省工作的调度器, 但在某些情况下, 调度器会选择将任务保留在 CPU 本地, 而将其迁移到空闲核心可能是更优的选择. 内核提供了 migration_cost_ns, wakeup_granularity_ns 等参数鼓励调度器尽可能节省工作, 同时也为了保持任务运行相对较长的时间片, 以避免上下文切换的开销. 总的来说, 这些旋钮提供了实质性的性能优势; 从而使吞吐量提高了大约 20%. 然而, 值得注意的是, 这种改进并不是在机器完全饱和的情况下实现的. 也就是说, 即使有了这些参数, 我们注意到即使主机过度使用, CPU 仍然处于空闲状态. 作者这个补丁集中提出的 "共享 wakequeue"(swqueue)特性. swqueue 背后的想法很简单: 它使调度器能够通过将唤醒任务放置到每个 LLC FIFO 队列中来积极地节省工作, 该队列可以由 LLC FIFO 队列中的另一个核心拉出, 然后可以在空闲之前将其拉出. | v4 ☐☑✓ | [2023/06/13, LORE RFC, 0/7](https://lore.kernel.org/lkml/20230613052004.2836135-1-void@manifault.com)
*-*-*-*-*-*-*-*
[2023/07/10, LORE v2,0/7](https://lore.kernel.org/lkml/20230710200342.358255-1-void@manifault.com)
*-*-*-*-*-*-*-*
[2023/08/09, LORE v3,0/7](https://lore.kernel.org/all/20230809221218.163894-1-void@manifault.com)
*-*-*-*-*-*-*-*
[2023/12/11, LORE v4,0/8](https://lore.kernel.org/all/20231212003141.216236-1-void@manifault.com) | | 2025/06/26 | Shrikanth Hegde | [cpu avoid state and push task mechanism](https://lore.kernel.org/all/20250625191108.1646208-1-sshegde@linux.ibm.com) | 提出 "CPU Avoid" 机制, 旨在优化虚拟化环境中因 vCPU 数量超过 pCPU 导致频繁上下文切换的问题. 其核心思想是标记某些 vCPU 为 "avoid" 状态, 调度器应尽量避免将任务分配到这些 CPU, 从而减少因抢占带来的性能开销.
补丁内容包括: 引入 `cpu_avoid_mask`、添加 sysfs 接口、支持 RT 调度类、使用静态密钥减少性能影响, 并修正了 v1 中的问题.
待解决问题包括: IRQ 处理是否需适配、任务绑定到 avoid CPU 的处理方式、对其他调度类(如 SCHED_DL) 的支持、性能测试、push/pull 任务逻辑整合及 `cpu_avoid_mask` 的同步机制. | v2 ☐☑✓ | [2025/05/23, LORE RFC, 0/5](https://lore.kernel.org/all/20250523181448.3777233-1-sshegde@linux.ibm.com)
*-*-*-*-*-*-*-*
[2025/06/26, LORE v2, 0/9](https://lore.kernel.org/all/20250625191108.1646208-1-sshegde@linux.ibm.com) | +| 2010/05/17 | Suresh Siddha | [sched: change nohz idle load balancing logic to push model](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=83cd4fe27ad8446619b2e030b171b858501de87d) | 现有的 nohz 空闲负载平衡逻辑使用 PULL 模式, 在部分 CPU 空闲的系统上指定一个空闲的 CPU 来做负载均衡 (balancer CPU), 并且该平衡器 CPU 不进入 NO_HZ 模式. 通过周期性的 TICK, 平衡器在 NO_HZ 模式下代表所有 CPU 进行空闲平衡. 另一种选择是使用 PUSH 模式, 在这种模式下, 所有空闲 CPU 都可以进入 NO_HZ 模式, 任何忙碌的 CPU 都可以 kick 一个空闲 CPU, 以代表一组空闲 CPU 处理 idle balancing. 这个补丁就将 NOHZ Idle Balance 切换到了 PUSH 模式. | RFC ☑ 2.6.36-rc1 | [LORE v1,0/2](https://lore.kernel.org/all/20090617182649.604970000@intel.com)
*-*-*-*-*-*-*-*
[LORE 0/7](https://lore.kernel.org/all/20100517184027.862696498@sbs-t61.sc.intel.com), [LORE](https://lore.kernel.org/all/1273886490-15627-1-git-send-email-venki@google.com)
*-*-*-*-*-*-*-*
[COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=83cd4fe27ad8446619b2e030b171b858501de87d) | +| 2025/09/04 | K Prateek Nayak | [sched/fair: Distributed nohz idle CPU tracking for idle load balancing](https://lore.kernel.org/all/20250904041516.3046-1-kprateek.nayak@amd.com) | 旨在改进 Linux 调度器中 nohz idle CPU 的跟踪机制, 以支持更高效的空闲负载均衡. 目前的全局 cpumask 和 idle 状态跟踪机制在频繁访问时存在性能瓶颈, 补丁将跟踪机制分布化, 基于 sd_llc_shared 拓扑结构维护每个 LLC 的 idle 状态和 cpumask.
主要改进包括:
- 实现 per-LLC 的 nohz 跟踪和全局" nohz_shared_list" 管理;
- 减少原子操作, 仅在 idle 状态边界变化时更新全局计数;
- 支持热插拔和 cpuset 的状态修正;
- 逐步替代现有全局变量 "nohz. idle_cpus_mask" 和 "nohz. nr_cpus".
性能测试显示, 在部分场景下调度性能有所提升, 但部分测试中也出现延迟上升等回归问题, 作者指出这可能与运行环境噪声有关.

总结: 本 RFC 提出了一种分布式 nohz idle 跟踪机制, 旨在减少全局竞争, 提升调度性能, 适用于未来基于 push 的负载均衡机制. | v1 ☐☑✓ | [2025/09/04, LORE v1, 0/19](https://lore.kernel.org/all/20250904041516.3046-1-kprateek.nayak@amd.com) | +| 2025/12/08 | K Prateek Nayak | [sched/fair: Push-based load balancing](https://lore.kernel.org/all/20251208083602.31898-1-kprateek.nayak@amd.com) | 旨在改进 Linux 调度器的负载均衡机制, 解决以下三个主要问题:
1. **忙时负载均衡不均**: 当前总是由组中第一个 CPU 承担负载均衡任务, 导致负载不均.
2. **nohz 全局变量扩展性差**: 全局变量在大规模系统中存在性能瓶颈.
3. **周期性负载均衡延迟高**: 在大型、扁平调度域结构中, 任务等待时间长, 尾延迟高.
**主要改进包括: **
- **忙平衡 CPU 轮换机制**: 在调度组中轮换负责忙平衡的 CPU, 减少单点负载.
- **nohz 本地化优化**: 将 idle CPU 掩码嵌入调度域层次结构, 减少全局原子操作.
- **[实验性] 推送式负载均衡**: 主动将任务推送到空闲 CPU, 提升性能但可能引入微基准测试回归.
- **[实验性] 优化 NUMA 内部新空闲平衡**: 改进新空闲负载均衡路径, 但存在锁竞争和性能波动.

**基准测试显示: **
在部分场景(如 deathstarbench) 中性能提升明显, 但部分微基准( 如 hackbench、tbench) 有小幅下降. 实验性功能仍需进一步优化与评估.

该工作将在 **LPC' 25** 的调度器与实时系统分会上讨论. | v2 ☐☑✓ | [2025/12/08, LORE v2, 0/29](https://lore.kernel.org/all/20251208083602.31898-1-kprateek.nayak@amd.com) | ### 4.3.6 Migrations Rate Limits @@ -2148,7 +2153,8 @@ 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 ☐☑✓ | [2025/03/25, LORE](https://lore.kernel.org/all/20250325120952.GJ36322@noisy.programming.kicks-ass.net) | -| 2025/04/21 | Chen Yu | [sched: Introduce Cache aware scheduling](https://lore.kernel.org/all/cover.1745199017.git.yu.c.chen@intel.com) | 该邮件由 Chen Yu 提交, 提出并更新了 "Cache-aware scheduling" (缓存感知调度) 的 RFC 补丁集(共 5 个补丁) , 旨在提升系统性能. 该调度机制通过将资源共享的进程集中调度到同一缓存域中, 提高缓存局部性, 减少缓存缺失. 补丁集修复了前一版本中的问题, 优化了任务迁移逻辑, 避免在缓存域过载时的性能下降, 并新增 ftrace 事件以辅助性能分析. 参见 [phoronix, 2025/04/21, Intel Posts Newest Code For Cache Aware Scheduling On Linux](https://www.phoronix.com/news/Linux-RFC-Cache-Aware-Sched), [lwn, 2025/04/29, Cache awareness for the CPU scheduler](https://lwn.net/Articles/1018334), [phoronix, 2025/06/18, Cache-Aware Scheduling For Linux Refined - Better AMD & Intel CPU Performance](https://www.phoronix.com/news/Linux-Cache-Aware-Sched-v3), [phoronix, 2025/10/13, Updated Intel Patches For Cache Aware Scheduling Net A 44% Win For AMD EPYC](https://www.phoronix.com/news/Cache-Aware-Scheduling-Go), [phoronix, 2025/10/17, New Linux Kernel Patches From Intel Delivering +18% Database Performance](https://www.phoronix.com/news/Linux-MM-CID-Faster-DBs), [phoronix, 2025/10/23, Linux's Proposed Cache Aware Scheduling Benchmarks Show Big Potential On AMD EPYC Turin](https://www.phoronix.com/review/cache-aware-scheduling-amd-turin). | v1 ☐☑✓ | [2025/04/21, LORE v1, 0/5](https://lore.kernel.org/all/cover.1745199017.git.yu.c.chen@intel.com)
*-*-*-*-*-*-*-*
[2025/06/18, LORE v3, 00/20](https://lore.kernel.org/all/cover.1750268218.git.tim.c.chen@linux.intel.com)
*-*-*-*-*-*-*-*
[2025/08/09, LORE v4, 00/28](https://lore.kernel.org/all/cover.1754712565.git.tim.c.chen@linux.intel.com)
*-*-*-*-*-*-*-*
[2025/10/11, LORE v5, 00/19](https://lore.kernel.org/all/cover.1760206683.git.tim.c.chen@linux.intel.com) | +| 2025/04/21 | Chen Yu | [sched: Introduce Cache aware scheduling](https://lore.kernel.org/all/cover.1745199017.git.yu.c.chen@intel.com) | 该邮件由 Chen Yu 提交, 提出并更新了 "Cache-aware scheduling" (缓存感知调度) 的 RFC 补丁集(共 5 个补丁) , 旨在提升系统性能. 该调度机制通过将资源共享的进程集中调度到同一缓存域中, 提高缓存局部性, 减少缓存缺失. 补丁集修复了前一版本中的问题, 优化了任务迁移逻辑, 避免在缓存域过载时的性能下降, 并新增 ftrace 事件以辅助性能分析. 参见 [phoronix, 2025/04/21, Intel Posts Newest Code For Cache Aware Scheduling On Linux](https://www.phoronix.com/news/Linux-RFC-Cache-Aware-Sched), [lwn, 2025/04/29, Cache awareness for the CPU scheduler](https://lwn.net/Articles/1018334), [phoronix, 2025/06/18, Cache-Aware Scheduling For Linux Refined - Better AMD & Intel CPU Performance](https://www.phoronix.com/news/Linux-Cache-Aware-Sched-v3), [phoronix, 2025/10/13, Updated Intel Patches For Cache Aware Scheduling Net A 44% Win For AMD EPYC](https://www.phoronix.com/news/Cache-Aware-Scheduling-Go), [phoronix, 2025/10/17, New Linux Kernel Patches From Intel Delivering +18% Database Performance](https://www.phoronix.com/news/Linux-MM-CID-Faster-DBs), [phoronix, 2025/10/23, Linux's Proposed Cache Aware Scheduling Benchmarks Show Big Potential On AMD EPYC Turin](https://www.phoronix.com/review/cache-aware-scheduling-amd-turin). | v1 ☐☑✓ | [2025/04/21, LORE v1, 0/5](https://lore.kernel.org/all/cover.1745199017.git.yu.c.chen@intel.com)
*-*-*-*-*-*-*-*
[2025/06/18, LORE v3, 00/20](https://lore.kernel.org/all/cover.1750268218.git.tim.c.chen@linux.intel.com)
*-*-*-*-*-*-*-*
[2025/08/09, LORE v4, 00/28](https://lore.kernel.org/all/cover.1754712565.git.tim.c.chen@linux.intel.com) | +| 2025/12/03 | Tim Chen | [Cache aware scheduling](https://lore.kernel.org/all/cover.1764801860.git.tim.c.chen@linux.intel.com) | 旨在引入**缓存感知调度( cache-aware scheduling) **基础设施, 目标是将共享数据的任务调度到同一**末级缓存( LLC) 域**, 以提升缓存局部性, 减少缓存一致性开销, 提高数据访问效率.
补丁主要改进包括:
- **LLC ID 连续化**, 便于统计和索引;
- **优先 NUMA 平衡**, 在 NUMA 与缓存调度策略冲突时以 NUMA 为准;
- **动态调整 LLC 统计结构大小**;
- **引入 per-LLC 统计与任务偏好机制**, 用于调度决策;
- **支持用户配置缓存调度参数**;
- **优化负载均衡中任务迁移策略**, 优先迁移偏好 LLC 的任务;
- **新增调试与统计功能**( 如 ftrace、proc 显示等) .未来计划包括:

- 支持跨进程任务分组;
- 引入可配置的缓存调度策略( 如通过 prctl) ;
- 支持 NUMA 组、waker/wakee 关系等场景.

补丁已获得初步反馈, 部分建议将作为后续改进. 参见 [phoronix, 2025/12/16, Intel's Cache Aware Scheduling Presentation At LPC 2025](https://www.phoronix.com/news/Cache-Aware-Scheduling-2025) | v2 ☐☑✓ | [2025/10/11, LORE v2, 00/19](https://lore.kernel.org/all/cover.1760206683.git.tim.c.chen@linux.intel.com)
*-*-*-*-*-*-*-*
[2025/12/03, LORE v2, 0/23](https://lore.kernel.org/all/cover.1764801860.git.tim.c.chen@linux.intel.com) | ### 4.3.8 Predict load based ------- @@ -2244,7 +2250,7 @@ idle balance 中执行 update_blocked_average 是很费时费力的, 可以做 |:----:|:----:|:---:|:---:|:----------:|:----:| | 2021/10/19 | Vincent Guittot | [Improve newidle lb cost tracking and early abort](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=8ea9183db4ad8afbcb7089a77c23eaf965b0cacd) | 通过考虑更新阻塞负载 update_blocked_averages() 所花费的时间, 在没有机会运行至少一个负载平衡循环的情况下完全跳过负载平衡循环. 因此在 newidle_balance() 中, 当 this_rq 的第一个 sd 满足 `this_rq->avg_idle max_newidle_lb_cost` 时, 认为执行 update_blocked_averages() 是非常昂贵且没有收益的, 只会增加开销. 因此在 newidle_balance() 中尽早检查条件, 尽可能跳过 update_blocked_averages() 的执行. | v3 ☑ [5.16-rc1](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9a7e0a90a454) | [2021/10/4 LKML v1](https://lkml.org/lkml/2021/10/4/1188)
*-*-*-*-*-*-*-*
[2021/10/04 PatchWork](https://lore.kernel.org/lkml/20211004171451.24090-1-vincent.guittot@linaro.org), [LKML](https://lkml.org/lkml/2021/10/4/1188)
*-*-*-*-*-*-*-*
[LKML v3,0/5](https://lkml.org/lkml/2021/10/19/590), [LORE v3,0/5](https://lore.kernel.org/all/20211019123537.17146-1-vincent.guittot@linaro.org), [关键 COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d783c8dd112) | | 2025/06/26 | Chris Mason | [sched/fair: bump sd->max_newidle_lb_cost when newidle balance fails](https://lore.kernel.org/all/20250626144017.1510594-2-clm@fb.com) | 邮用于修复 COMMIT `c5b0a7eefc sched/fair: Remove sysctl_sched_migration_cost condition` 条件导致的性能回归问题.使用 `schbench` 工具进行测试, 每秒请求数(RPS)从 5.4M 下降到 3.4M, 问题表现为 `newidle balance` 操作次数增加了约 100 倍, 这些操作大多失败, 未能找到负载可迁移的 CPU. 工作线程约 20% 的时间花在 `newidle balance` 上.
因此本补丁尝试在 newidle balance 失败时增大其成本(`domain_cost`), 从而抑制其频繁触发. 同时对成本的上限进行限制, 防止其无限增长.
补丁修改了 `update_newidle_cost( ) ` 和 `sched_balance_newidle( ) ` 函数逻辑.
sched_balance_newidle()` 函数中, 原逻辑: 无论 newidle balance 是否成功，均使用实际耗时更新 `max_newidle_lb_cost`. 新逻辑: 如果没有拉取到任务(`pulled_task == false`), 则将该次 balance 的 cost 提升为当前最大 cost 的 1.5 倍. 这样做的目的是: 提升失败操作的成本感知, 使得调度器在未来更谨慎地触发 newidle balance. `update_newidle_cost()` 函数中, 原逻辑: 直接更新 `sd->max_newidle_lb_cost = cost;`, 新逻辑: 增加上限限制, 使用 `sysctl_sched_migration_cost + 200` 作为最大值. 避免成本无限增长. | v2 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250626144017.1510594-2-clm@fb.com) | -| 2025/11/07 | Peter Zijlstra | [sched: The newidle balance regression](https://lore.kernel.org/all/20251107160645.929564468@infradead.org) | 解决由提交 `155213a2aed4 ("sched/fair: Bump sd->max_newidle_lb_cost when newidle balance fails")` 引入的调度器 newidle balance 逻辑的性能退化问题, 重新引入 newidle balance 的"目标+随机"(NI_TARGET + NI_RANDOM)策略的比例型 proportional newidle balance, 提供一个更加合理和高效的 newidle balance 机制, 以提高系统整体的负载均衡效果与性能.
为了控制 newidle 平衡的开销, 调度器维护了一个 `sd->max_newidle_lb_cost` 指标, 表示执行 newidle balance 的平均代价. 当 newidle balance 没有成功迁移任务时, 该值会增加, 从而降低后续触发 newidle 的频率. 这是 COMMIT `155213a2aed4` 的初衷. 然而, 这一改动导致了: 在某些负载下 newidle balance 过于保守, 错失负载均衡机会. 性能退化, 尤其是在需要快速响应负载变化的场景. Patch 1-2: Revert 回退到更早的 newidle 行为(NI_TARGET), 移除了 newidle balance 失败时对 domain_cost 的放大处理. 恢复使用实际测量值更新 max_newidle_lb_cost, 删除了 sysctl_sched_migration_cost 的上限限制, 着回到了 newidle 仅尝试迁移到目标调度组(target group)的方式, 该行为在旧版本中表现良好, 避免了不必要的平衡请求. Patch 3-4: 引入 proportional newidle balance, 在目标组失败后, 以一定概率尝试其他调度组(NI_RANDOM), 类似于 NI_TARGET + NI_RANDOM 的组合策略. | v1 ☐☑✓ | [2025/11/07, LORE v1, 0/4](https://lore.kernel.org/all/20251107160645.929564468@infradead.org) | +| 2025/11/07 | Peter Zijlstra | [sched: The newidle balance regression](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=33cf66d88306663d16e4759e9d24766b0aaa2e17) | 解决由提交 `155213a2aed4 ("sched/fair: Bump sd->max_newidle_lb_cost when newidle balance fails")` 引入的调度器 newidle balance 逻辑的性能退化问题, 重新引入 newidle balance 的"目标+随机"(NI_TARGET + NI_RANDOM)策略的比例型 proportional newidle balance, 提供一个更加合理和高效的 newidle balance 机制, 以提高系统整体的负载均衡效果与性能.
为了控制 newidle 平衡的开销, 调度器维护了一个 `sd->max_newidle_lb_cost` 指标, 表示执行 newidle balance 的平均代价. 当 newidle balance 没有成功迁移任务时, 该值会增加, 从而降低后续触发 newidle 的频率. 这是 COMMIT `155213a2aed4` 的初衷. 然而, 这一改动导致了: 在某些负载下 newidle balance 过于保守, 错失负载均衡机会. 性能退化, 尤其是在需要快速响应负载变化的场景. Patch 1-2: Revert 回退到更早的 newidle 行为(NI_TARGET), 移除了 newidle balance 失败时对 domain_cost 的放大处理. 恢复使用实际测量值更新 max_newidle_lb_cost, 删除了 sysctl_sched_migration_cost 的上限限制, 着回到了 newidle 仅尝试迁移到目标调度组(target group)的方式, 该行为在旧版本中表现良好, 避免了不必要的平衡请求. Patch 3-4: 引入 proportional newidle balance, 在目标组失败后, 以一定概率尝试其他调度组(NI_RANDOM), 类似于 NI_TARGET + NI_RANDOM 的组合策略. | v1 ☐☑✓ v6.19-rc1 | [2025/11/07, LORE v1, 0/4](https://lore.kernel.org/all/20251107160645.929564468@infradead.org) | ### 4.4.3 Task Stealing From LLC @@ -4278,6 +4284,8 @@ y = (1 - \frac{pct^{2}}{10000^{2}} \times x^{2}) \times llc\_weight | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:----:|:---:|:----------:|:---:| | 2021/06/15 | Peter Zijlstra | [sched/fair: Age the average idle time](https://lore.kernel.org/patchwork/patch/1446838) | Peter Zijlstra [RFC select_idle_sibling rework 00/11](https://lore.kernel.org/lkml/20180530143105.977759909@infradead.org) 的其中 [一个补丁](https://lore.kernel.org/lkml/20180530142236.667774973@infradead.org), 被 Mel Gorman 重写后合入主线.
当前, select_idle_cpu() 中限制 CPU 遍历层数的比例方案借用的是 CPU 平均空闲等待时间 rq->avg_idle, 这在时间上是有挑战的. 当 CPU 完全不空闲时, rq->avg_idle 将不具代表性. 为了解决这个问题, 引入一个单独的平均空闲时间 wake_avg_idle 并对它进行定期的老化.
1. 总的目标是不要花比 CPU 空闲时间更多的时间来扫描空闲 CPU. 否则性能不会有任何改观. 这意味着我们需要考虑连续空闲期间所有唤醒的成本. 为了跟踪这一点, 扫描成本从估计的平均空闲时间中减去.
2. 这个补丁的影响与具有完全繁忙或过载域的工作负载有关. 如果没有补丁, 可能会由于 CPU 未达到空闲状态, 导致扫描深度过高. 当域几乎完全繁忙或过载时, 这个补丁则有明显作用, 此时搜索可能会失败, 但空闲不会老化, 因为 cpu 处于活动状态, 所以搜索深度太大而无用. 当有空闲 cpu 时, 它可能会显示回归, 而深度搜索是有益的. 这个 tbench 结果在一个 2 插槽宽井机部分说明了这个问题. | v1 ☑ v5.13-rc6 | [LORE v2](https://lore.kernel.org/all/20210615111611.GH30378@techsingularity.net), [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=94aafc3ee31dc199d1078ffac9edd976b7f47b3d) | +| 2025/12/09 | Huang Shijie | [sched: update the rq->avg_idle when a task is moved to an idle CPU](https://lore.kernel.org/all/20251209094508.570049-1-shijie@os.amperecomputing.com) | 用于在任务被迁移到空闲 CPU( 如 fork/clone、execve 等场景) 时更新 `rq-> avg_idle`, 并结束 CPU 的空闲状态( 将 `rq-> idle_stamp` 设为 0), 以提升调度器对 CPU 空闲时间的评估准确性.

此前, 仅在唤醒时更新 `rq-> avg_idle`, 未覆盖任务迁移导致 CPU 被唤醒的情况. 该补丁集在 enqueue_task 中调用 `update_rq_avg_idle( ) `, 确保任务入队时更新空闲统计信息. | v6 ☐☑✓ | [2025/12/09, LORE v6, 0/2](https://lore.kernel.org/all/20251209094508.570049-1-shijie@os.amperecomputing.com) | + ### 5.3.6 分级搜索 ------- @@ -6592,6 +6600,9 @@ $deadline_{se} = vruntime_{se} + slice \times \frac{weight_0}{weight_{se}}$ ### 8.9.3 EEVDF 如何 PICK 任务 ------- +#### 8.9.3.1 vlag 优化 +------- + [commit 147f3efaa241 ("sched/fair: Implement an EEVDF-like scheduling policy")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=147f3efaa24182a21706bca15eab2f3f4630b5fe) [commit 650cad561cce ("sched/eevdf: Also update slice on placement")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=650cad561cce04b62a8c8e0446b685ef171bc3bb) @@ -6601,7 +6612,22 @@ $deadline_{se} = vruntime_{se} + slice \times \frac{weight_0}{weight_{se}}$ | 2025/04/18 | Vincent Guittot | [sched/fair: Increase max lag clamping](https://lore.kernel.org/all/20250418151225.3006867-1-vincent.guittot@linaro.org) | 这个补丁旨在修正 `sched_entity` 的滞后(lag) 限制问题. 当前 lag 上限为 `TICK_NSEC` 或任务时间片的两倍, 但该限制在任务设置了较大自定义时间片(如 100ms) 时显得不足, 导致其他任务可能在等待时积累正 lag, 从而在出队时被不当地截断.
补丁将 lag 的上限改为统一使用系统允许的最大时间片(`SCHED_SLICE_MAX`) , 并定义了最小时间片(`SCHED_SLICE_MIN`) 用于约束设置. 此举确保了调度公平性, 避免因 lag 截断造成信息丢失.
代码修改包括更新 `update_entity_lag() ` 中的 lag 限制逻辑, 并在 `__setparam_fair() ` 中使用统一的宏定义. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250418151225.3006867-1-vincent.guittot@linaro.org) | | 2025/06/13 | Vincent Guittot | [sched/fair: Manage lag and run to parity with different slices](https://lore.kernel.org/all/20250613140514.2781138-1-vincent.guittot@linaro.org) | 旨在改进 Linux 调度器(sched/fair) 中任务 lag 的管理和公平性机制. 核心内容包括:
补丁 2: 基于 Peter Zijlstra 的建议, 通过追踪入队任务的最大 slice 来限制出队任务的 lag.
补丁 3: 修改当前任务 slice 的保护机制, 考虑短 slice 任务等待运行的情况.
补丁 4: 扩展 slice 保护机制至 NO_RUN_TO_PARITY 场景, 确保定期设置 resched, 且运行任务至少运行 0. 7ms, 除非触发 PREEMPT_SHORT. | v1 ☐☑✓ | [2025/06/13, LORE v1, 0/4](https://lore.kernel.org/all/20250613140514.2781138-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2025/07/04, LORE v2, 0/6](https://lore.kernel.org/all/20250704143612.998419-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2025/07/08, LORE v3, 0/6](https://lore.kernel.org/all/20250708165630.1948751-1-vincent.guittot@linaro.org) | | 2025/06/19 | Huang Shijie | [sched/fair: set the se->vlag strictly following the paper](https://lore.kernel.org/all/20250619031942.25474-1-shijie@os.amperecomputing.com) | 修正 `se-> vlag` 的计算逻辑, 使其严格符合论文中的规定: `-r_max 为此, 补丁引入了 `limit_hi`、`limit_lo` 和 `r_max` 变量, 分别表示上限、下限与最大延迟基准值, 从而实现更精确的 `vlag` 限制. 修改后, `vlag` 被正确限制在 `[-limit_lo, limit_hi] ` 范围内.
该修改提升了调度器公平性计算的准确性, 并通过了相关测试. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250619031942.25474-1-shijie@os.amperecomputing.com) | -| 2025/07/14 | Mel Gorman | [sched/fair: Enable scheduler feature NEXT_BUDDY](https://lore.kernel.org/all/20250714134429.19624-2-mgorman@techsingularity.net) | 这组补丁旨在重新启用并改进 CFS 中的 NEXT_BUDDY 调度特性, 以更好地契合 EEVDF 调度策略目标. 新增 PREEMPT_BUDDY 策略判断逻辑, 并调整唤醒抢占流程. 此改进有助于提高缓存亲和性和响应速度.
1. 补丁 1 启用了 NEXT_BUDDY 功能, 该功能曾在早期内核版本中因公平性问题被禁用.
2. 补丁 2 对其进行了重新实现, 使其在任务唤醒时基于 deadline 和 eligibility 做出调度决策.
补丁对同步唤醒(WF_SYNC) 和其他类型唤醒分别处理: 前者视作建议而非硬性规则, 后者在 wakee deadline 更早且可运行时触发抢占.
测试结果显示, 在 dbench4 中吞吐量和执行时间均有提升, 特别是在高并发场景下; 公平性表现有波动但仍可接受. hackbench 测试结果显示影响较小, 大部分中性或轻微下降. 整体目标是在不影响其他负载的前提下提升特定应用场景的性能. | v1 ☐☑✓ | [2025/07/14, LORE v1, 0/2](https://lore.kernel.org/all/20250714134429.19624-2-mgorman@techsingularity.net) | + + +#### 8.9.3.2 NEXT_BUDDY 优化 +------- + +NEXT_BUDDY 功能强化了唤醒抢占权, 鼓励最后一次唤醒更早被安排, 前提是唤醒者/唤醒者共享缓存热数据. 在 CFS 中, 它与 LAST_BUDDY 配合, 假设任务对仍共享数据, 但也依赖 START_DEBIT 和精确的 WAKEUP_PREEMPTION 实现以获得良好结果. NEXT_BUDDY 自 COMMIT 0ec9fab3d186 ("sched: Improve latencies and throughput") 后被禁用, 因为这是关于 wakees 的截止日期和资格的具体时间点决定. + +LAST_BUDDY 在提交 5e963f2bd465 ("sched/fair: Commit to EEVDF") 中被移除. 提到了 vruntime 传播, 且 NEXT_BUDDY 本质上不能严格遵守 EEVDF 原则. 虽然未明确说明 LAST_BUDDY 被移除的原因, 但普遍认为很难在尊重 EEVDF 目标的前提下判断 LAST_BUDDY 应有的正确且有效的行为. NEXT_BUDDY 仍然会选择更早的截止日期, 但 LAST_BUDDY 可以选择不符合条件的任务. + + +随后 v6.19 版本, NEXT_BUDDY 被重新启用, 并对齐了 EEVDF 的策略. 参见 [COMMIT e837456fdca8 ("sched/fair: Reimplement NEXT_BUDDY to align with EEVDF goals")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e837456fdca81899a3c8e47b3fd39e30eae6e291). + + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:---:|:----:|:---:|:----:|:---------:|:----:| +| 2025/07/14 | Mel Gorman | [sched/fair: Enable scheduler feature NEXT_BUDDY](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=e837456fdca81899a3c8e47b3fd39e30eae6e291) | 这组补丁旨在重新启用并改进 CFS 中的 NEXT_BUDDY 调度特性, 以更好地契合 EEVDF 调度策略目标. 新增 PREEMPT_BUDDY 策略判断逻辑, 并调整唤醒抢占流程. 此改进有助于提高缓存亲和性和响应速度.
1. 补丁 1 启用了 NEXT_BUDDY 功能, 该功能曾在早期内核版本中因公平性问题被禁用.
2. 补丁 2 对其进行了重新实现, 使其在任务唤醒时基于 deadline 和 eligibility 做出调度决策.
补丁对同步唤醒(WF_SYNC) 和其他类型唤醒分别处理: 前者视作建议而非硬性规则, 后者在 wakee deadline 更早且可运行时触发抢占.
测试结果显示, 在 dbench4 中吞吐量和执行时间均有提升, 特别是在高并发场景下; 公平性表现有波动但仍可接受. hackbench 测试结果显示影响较小, 大部分中性或轻微下降. 整体目标是在不影响其他负载的前提下提升特定应用场景的性能. 参见 [phoronix, 2025/12/02, Optimized NUMA Distances For Intel GNR & CWF, Other Scheduler Improvements In Linux 6.19](https://www.phoronix.com/news/Linux-6.19-Scheduler) | v1 ☐☑✓ v6.19-rc1 | [2025/07/14, LORE v1, 0/2](https://lore.kernel.org/all/20250714134429.19624-2-mgorman@techsingularity.net)
*-*-*-*-*-*-*-*
[2025/11/12, LORE v5, 0/2](https://lore.kernel.org/all/20251112122521.1331238-1-mgorman@techsingularity.net) | ### 8.9.4 EEVDF 如何处理睡眠唤醒的任务 @@ -6662,7 +6688,7 @@ EEVDF 的基础实现中, 具有较短时间片的任务将具有更早的虚拟 |:-----:|:----:|:----:|:----:|:------------:|:----:| | 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/04/18, LORE v2, 0/3](https://lore.kernel.org/all/20250418193410.2010058-1-prakash.sangappa@oracle.com)
*-*-*-*-*-*-*-*
[2025/05/02, LORE v3, 0/4](https://lore.kernel.org/all/20250502015955.3146733-1-prakash.sangappa@oracle.com)
*-*-*-*-*-*-*-*
[2025/05/13, LORE v4, 0/6](https://lore.kernel.org/all/20250513214554.4160454-1-prakash.sangappa@oracle.com)
*-*-*-*-*-*-*-*
[2025/06/03, LORE v5, 0/6](https://lore.kernel.org/all/lore.kernel.org/all/20250603233654.1838967-1-prakash.sangappa@oracle.com)
*-*-*-*-*-*-*-*
[2025/07/01, LORE v6, 0/7](https://lore.kernel.org/all/20250701003749.50525-1-prakash.sangappa@oracle.com)
*-*-*-*-*-*-*-*
[2025/07/24, LORE v7, 00/11](https://lore.kernel.org/all/all/20250724161625.2360309-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 ☐☑✓ | [2023/10/25, LORE POC(https://lore.kernel.org/all/20231025054219.1acaa3dd@gandalf.local.home)
*-*-*-*-*-*-*-*
[2025/01/31, LORE v1,0/2](https://lore.kernel.org/all/20250131225837.972218232@goodmis.org) | -| 2025/09/09 | Thomas Gleixner | [rseq: Implement time slice extension mechanism](https://lore.kernel.org/all/20250908225709.144709889@linutronix.de) | 基于 RSEQ 机制实现的时间片扩展(time slice extension)方案, 旨在通过减少用户态关键代码段被抢占的可能性, 提升系统在高并发场景下的响应性能. 该机制利用 RSEQ 的用户空间 ABI 新增两个标志位(REQUEST 和 GRANTED), 由用户空间在进入关键区时设置 REQUEST, 若在未退出临界区前被中断, 由内核决定是否授予时间片扩展, 并在合适时机通知用户空间调用 `rseq_slice_yield( ) ` 主动让出 CPU. 邮件还指出该实现避免了对调度器 hrtick 定时器的干扰, 并与 RSEQ 的用户态返回流程紧密结合. 此外, 邮件包含新系统调用、文档说明及自测代码, 相关代码可在[指定 Git 分支](git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git rseq/slice)获取. ThomasGleixner 强调该机制在 PREEMPT_LAZY 模式下更适用, 对完全可抢占内核效果有限. [关联 Patchset](https://lore.kernel.org/all/20250908212737.353775467@linutronix.de) | v1 ☐☑✓ | [2025/09/09, LORE v1, 0/12](https://lore.kernel.org/all/20250908225709.144709889@linutronix.de) | +| 2025/09/09 | Thomas Gleixner | [rseq: Implement time slice extension mechanism](https://lore.kernel.org/all/20250908225709.144709889@linutronix.de) | 基于 RSEQ 机制实现的时间片扩展(time slice extension)方案, 旨在通过减少用户态关键代码段被抢占的可能性, 提升系统在高并发场景下的响应性能. 该机制利用 RSEQ 的用户空间 ABI 新增两个标志位(REQUEST 和 GRANTED), 由用户空间在进入关键区时设置 REQUEST, 若在未退出临界区前被中断, 由内核决定是否授予时间片扩展, 并在合适时机通知用户空间调用 `rseq_slice_yield( ) ` 主动让出 CPU. 邮件还指出该实现避免了对调度器 hrtick 定时器的干扰, 并与 RSEQ 的用户态返回流程紧密结合. 此外, 邮件包含新系统调用、文档说明及自测代码, 相关代码可在[指定 Git 分支](git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git rseq/slice)获取. ThomasGleixner 强调该机制在 PREEMPT_LAZY 模式下更适用, 对完全可抢占内核效果有限. [关联 Patchset](https://lore.kernel.org/all/20250908212737.353775467@linutronix.de) | v1 ☐☑✓ | [2025/09/09, LORE v1, 0/12](https://lore.kernel.org/all/20250908225709.144709889@linutronix.de)
*-*-*-*-*-*-*-*
[2025/11/28, LORE v5, 00/11](https://lore.kernel.org/all/20251128225931.959481199@linutronix.de)
*-*-*-*-*-*-*-*
[2025/12/01, LORE v5, 0/11](https://lore.kernel.org/all/20251128225931.959481199@linutronix.de) | ### 8.9.7 EEVDF DEBUG @@ -7149,7 +7175,7 @@ Roman Gushchin 在邮件列表发起了 BPF 对调度器的潜在应用的讨论 2024 年 01 月, Ubuntu/Canonical 的工程师 Andrea Righi(随后离职去了 NVIDIA), 在 X(Twitter) 上发文谈到, 他利用圣诞假期通过 sched_ext 实现了能够在运行时加载的 Rust 调度器 scx_rustland, 他在自己的博客中展示了这个调度器的巨大潜力和希望, 在某些负载 (例如游戏) 下性能甚至可以超越 Linux 内核默认的 EEVDF 调度器. [Righi: Writing a scheduler for Linux in Rust that runs in user-space](https://arighi.blogspot.com/2024/02/writing-scheduler-for-linux-in-rust.html), 参见 LWN 报道 [Righi: Writing a scheduler for Linux in Rust that runs in user-space](https://lwn.net/Articles/962897), phoronix 的报道 [Rust-Written Linux Scheduler Showing Promising Results For Gaming Performance](https://www.phoronix.com/news/Rust-Linux-Scheduler-Experiment) 和 [Ubuntu Blog Talks Up Rust Schedulers, Potential For Micro-Kernel Design Future](https://www.phoronix.com/news/Ubuntu-Rust-Scheduler-Micro), 以及 Ubuntu blog [Crafting new Linux schedulers with sched-ext, Rust and Ubuntu](https://ubuntu.com//blog/crafting-new-linux-schedulers-with-sched-ext-rust-and-ubuntu). scx_rustland 调度器的瓶颈是内核和用户空间之间通信的开销. 为了解决这个问题, 同年 8 月份, Andrea Righi 在 eBPF 中完全实现了 scx_rustland, 讲新的调度器命名为 scx_bpfland. scx_bpfland 调度器采用与 scx_rustland 相同的逻辑, 但没有内核 / 用户空间的通信开销. Andrea 已经运行了一些基准测试, 新的 bpfland 代码显示出非常有希望的结果. PostgreSQL 快 30~39%, FFmpeg 快几个百分点, nginx 快 8% 左右, 等等. 参见 [phoronix, 2024/08/10, Reimplementing A Linux Rust Scheduler In eBPF Shows Very Promising Results](https://www.phoronix.com/news/Linux-Rust-Sched-To-eBPF) 以及作者博客 [blog, 2024/08/10, Reimplementing my Linux Rust Scheduler In eBPF](https://arighi.blogspot.com/2024/08/re-implementing-my-linux-rust-scheduler.html). -Changwoo Min 和 Igalia 在北美开源峰会上发表了关于为 Linux 游戏优化内核调度器的演讲, [Optimizing Scheduler for Linux Gaming - Changwoo Min, Igalia](https://ossna2024.sched.com/event/1aBOT/optimizing-scheduler-for-linux-gaming-changwoo-min-igalia?iframe=no&w=100%&sidebar=yes&bg=no), 提出延迟关键感知虚拟截止时间 (LAVD) 调度器. 这个[使用 Rust 基于 sched_ext 编写](https://crates.io/crates/scx_lavd/versions) 的基于 EDF 的调度器已经显示出可喜的结果. 在 Igalia 在基于 Linux 6.9-rc1 的内核上进行的测试中, LAVD 调度器在平均 FPS 和 1% 的低帧速率下都显示出与 EEVDF 更好或相似的性能. 参见 phoronix 报道 [Rust-Written LAVD Kernel Scheduler Shows Promising Results For Linux Gaming](https://www.phoronix.com/news/LAVD-Scheduler-Linux-Gaming). +Changwoo Min 和 Igalia 在北美开源峰会上发表了关于为 Linux 游戏优化内核调度器的演讲, [Optimizing Scheduler for Linux Gaming - Changwoo Min, Igalia](https://ossna2024.sched.com/event/1aBOT/optimizing-scheduler-for-linux-gaming-changwoo-min-igalia?iframe=no&w=100%&sidebar=yes&bg=no), 提出延迟关键感知虚拟截止时间 (LAVD) 调度器. 这个[使用 Rust 基于 sched_ext 编写](https://crates.io/crates/scx_lavd/versions) 的基于 EDF 的调度器已经显示出可喜的结果. 在 Igalia 在基于 Linux 6.9-rc1 的内核上进行的测试中, LAVD 调度器在平均 FPS 和 1% 的低帧速率下都显示出与 EEVDF 更好或相似的性能. 参见 phoronix 报道 [Rust-Written LAVD Kernel Scheduler Shows Promising Results For Linux Gaming](https://www.phoronix.com/news/LAVD-Scheduler-Linux-Gaming). 时间来到 2025 年, Meta 发现除了在掌机上表现良好, SCX-LAVD 在大型服务器上也能很好地运行. Meta 工程师在 2025 年 LPC 上的演讲实际上题为 [How do we make a Steamdeck scheduler work on large servers](https://lpc.events/event/19/contributions/2099). 在 Meta, 他们探索 SCX_LAVD 作为服务器的默认调度器, 适用于多种硬件和不需要专用调度器的场景. [Meta Is Using The Linux Scheduler Designed For Valve's Steam Deck On Its Servers](https://www.phoronix.com/news/Meta-SCX-LAVD-Steam-Deck-Server) 随后作者发布了 sched_ext 的 v6 版本 [Another push for sched_ext](https://lwn.net/Articles/972710), BPF 的工具集 `sched_ext/ravg[_impl].BPF.h` 和 `ravg.read.rs.h` 中的运行平均实现来跟踪负载度量. 以前, 用户空间部分迭代所有任务来计算负载度量并做出 LB 决策. 现在, 高级 LB 决策是通过简单地读取每个域的负载平均值来做出的, 而 Picking 迁移目标任务只访问推送域中固定数量的最近活动任务的负载度量. 这大大减少了 CPU 开销, 并使 rust 的可扩展性大大提高. @@ -7171,7 +7197,7 @@ LSFMMBPF 2024 上对 sched_ext 进行了讨论 [LWN, 2024/05/23, LSFMMBPF-2024, 2025 年伊始, NVIDIA 工程师 Andrea Righi 在比利时布鲁塞尔举行的 FOSDEM 上围绕 sched_ext 及其打开的大门进行了两场演讲. Righi 的其中一场演讲是关于 sched_ext 在 Linux 游戏中的使用. 特别是，sched_ext 的性能优势可以在游戏时提高性能. 参见 [FOSDEM, 2025/02/01, Level up your linux gaming: how sched_ext can save your fps](https://fosdem.org/2025/schedule/event/fosdem-2025-4618-level-up-your-linux-gaming-how-schedext-can-save-your-fps). 另外一场演讲是 [Linux 内核调度程序的 Rust 化(在用户空间中), FOSDEM, 2025/02/02, Rust-ifying the Linux kernel scheduler (in user space)](https://fosdem.org/2025/schedule/event/fosdem-2025-4620-rust-ifying-the-linux-kernel-scheduler-in-user-space-). 主要是关于使用 Rust 编程语言通过 scx_rustland 开发 eBPF sched_ext 程序的. Righi 在那里指出, Rust 本身并不能使调度变得快速, 而且 scx_rustland 通常不是一个更好的调度器, 但 Rust 中的调度器可以实现更快的实验和更轻松的开发, 以及更好地与其他用户空间组件集成. 随后 phoronix 对此演讲进行了报道 [phoronix, 2025/02/05, NVIDIA Engineer Talks Up sched_ext Linux Scheduler Possibilities At FOSDEM](https://www.phoronix.com/news/NVIDIA-Talks-Up-Sched-Ext). - +经历了 2025 年一年的蓬勃发展, Andrea Righi 在 LPC-2025 发表主题演讲 [LPC-2025, 2025/12/12, sched_ext: current status and future plans](https://lpc.events/event/19/contributions/2035), 对 schd_ext 的 2025 的成功进行了总结, 其中 Andrea Righi 起到了关键作用, 并推动了 Linux 上新的 CPU 调度器创新, 未来计划包括分层调度器、改进内置的 sched_ext 调度器、可组合调度器、用 Rust 重新实现部分 C 代码、GPU 感知、节能抽象以及 BPF 热路径优化. 参见 [phoronix, 2025/12/23, Linux's sched_ext Has Plans For GPU Awareness, Energy-Aware Abstractions](https://www.phoronix.com/news/sched-ext-future-plans-2026) | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | @@ -7232,7 +7258,7 @@ LSFMMBPF 2024 上对 sched_ext 进行了讨论 [LWN, 2024/05/23, LSFMMBPF-2024, | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:---:|:----:|:---:|:----:|:---------:|:----:| -| 2025/11/09 | Tejun Heo | [sched_ext: Improve bypass mode scalability](https://lore.kernel.org/all/20251109183112.2412147-1-tj@kernel.org) | 旨在提升 Linux 调度扩展(sched_ext) 的 bypass 模式在大规模系统上的可扩展性. 主要解决两个问题:
1. **减少 DSQ 锁竞争**: 原 bypass 模式使用每 NUMA 节点的全局 DSQ, 但在任务绑定到特定小 CPU 子集时, 仍可能导致严重扫描开销和锁竞争.
补丁改用每 CPU 的 DSQ, 并在调度中止时立即退出调度与迁移操作, 避免陷入长循环. 同时引入 hardlockup 检测作为安全机制.

2. **防止任务集中导致 RCU 挂起**: 使用每 CPU DSQ 时, 若 BPF 调度器导致任务集中在少数 CPU 上, 将导致队列无法及时处理. 补丁加入基于定时器的负载均衡机制, 将任务在 NUMA 节点内部重新分发, 并缩短 bypass 模式下的时间片以提升响应速度.

测试表明, 该补丁集在 192 核 AMD EPYC 机器上能有效应对极端场景, 显著提升系统稳定性与调度器退出效率. 附带的 `scx_cpu0` 示例调度器用于验证任务集中情况下的表现. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20251109183112.2412147-1-tj@kernel.org) | +| 2025/11/09 | Tejun Heo | [sched_ext: Improve bypass mode scalability](https://lore.kernel.org/all/20251109183112.2412147-1-tj@kernel.org) | 旨在提升 Linux 调度扩展(sched_ext) 的 bypass 模式在大规模系统上的可扩展性. 主要解决两个问题:
1. **减少 DSQ 锁竞争**: 原 bypass 模式使用每 NUMA 节点的全局 DSQ, 但在任务绑定到特定小 CPU 子集时, 仍可能导致严重扫描开销和锁竞争.
补丁改用每 CPU 的 DSQ, 并在调度中止时立即退出调度与迁移操作, 避免陷入长循环. 同时引入 hardlockup 检测作为安全机制.

2. **防止任务集中导致 RCU 挂起**: 使用每 CPU DSQ 时, 若 BPF 调度器导致任务集中在少数 CPU 上, 将导致队列无法及时处理. 补丁加入基于定时器的负载均衡机制, 将任务在 NUMA 节点内部重新分发, 并缩短 bypass 模式下的时间片以提升响应速度.

测试表明, 该补丁集在 192 核 AMD EPYC 机器上能有效应对极端场景, 显著提升系统稳定性与调度器退出效率. 附带的 `scx_cpu0` 示例调度器用于验证任务集中情况下的表现. [phoronix, 2025/12/03, Sched_EXT With Linux 6.19 Improves Recovering For Misbehaving eBPF Schedulers](https://www.phoronix.com/news/Linux-6.19-sched-ext) | v1 ☐☑✓ | [2025/11/09, LORE](https://lore.kernel.org/all/20251109183112.2412147-1-tj@kernel.org)
*-*-*-*-*-*-*-*
[2025/11/10, LORE v2, 00/14](https://lore.kernel.org/all/20251110205636.405592-1-tj@kernel.org) | @@ -7261,6 +7287,7 @@ LSFMMBPF 2024 上对 sched_ext 进行了讨论 [LWN, 2024/05/23, LSFMMBPF-2024, | 3 | NA | | 4 | [scx_packet](https://free5gc.org/blog/20250509/20250509) | RUST | [Free5GC](https://free5gc.org/) 项目试验的 scx_packet 调度程序. 它使用了一种相对简单的算法: 系统中的一半 CPU 保留给延迟敏感的网络处理任务, 而另一半则交给 CPU 绑定的一般处理. 但这个调度程序对所有网络流量一视同仁——语音通话、网页浏览和流媒体都流向同一个 CPU. 这可能会导致语音数据被阻止在下载流量之后, 并且紧急呼叫与社交媒体活动具有相同的优先级. 随着工作负载的转移, 这种方法还导致一些 CPU 过载, 而另一些 CPU 则处于空闲状态. 最后, 某些数据包需要比其他数据包更多的处理; 应单独安排对 CPU 密集型数据包的处理. | | 5 | [scx_rusty](https://github.com/vax-r/scx/tree/scx_rusty_MLLB) | RUST | Ching-Chun("Jim") Huang 展示了其将 (本地) 机器学习应用于在复杂系统上调度器负载均衡的工作成果, [Improve Load Balancing with Machine Learning Techniques based on sched_ext Framework](https://static.sched.com/hosted_files/ossna2025/d2/Improve-Load-Balancing-With-Machine-Learning-Techniques-based-on-sched_ext.pdf). Free5GC 开发人员研究通过机器学习来改进调度器的负载均衡. 在此类系统上进行调度需要考虑许多输入维度; 此外, 调度程序还必须考虑每个任务的优先级、其 CPU 要求、到目前为止的虚拟运行时间以及最近的 CPU 使用模式. 必须考虑每个 CPU 上的负载, 以及 NUMA 距离、缓存共享和工作频率. 当然, 还有特定于工作负载的因素. 基于 scx_rusty 来尝试考虑所有这些参数并决定何时应该将任务从一个 CPU 移动到另一个 CPU. 它最初以数据收集模式运行, 查看迁移决策及其结果; 然后, 这些决策用于训练模型(在用户空间中), 该模型随后存储在 BPF 映射中. 然后, 调度程序可以在内核内使用此模型来做出负载平衡决策. 这些决策的结果会不断被测量并报告回用户空间, 从而随着时间的推移更新模型. 在使用最重要的内核编译基准测试的测试中, 该调度器的编译时间比 EEVDF 调度器缩短了 10%, 任务迁移的数量减少了 77%. Huang 总结了机器学习在这种情况下起作用的原因: 在这种复杂的环境中进行调度是一个模式识别问题, 而神经网络擅长这项任务. 调度程序能够平衡相互竞争的目标, 并自动针对新的架构和工作负载进行自我重新训练. 调度程序能够为每个迁移决策考虑 15 个单独的参数, 并根据结果调整其模型. [2025 Open Source Summit North America](https://events.linuxfoundation.org/open-source-summit-north-america), 参见 LWN 报道 [LWN 2025/07/01, Improved load balancing with machine learning](https://lwn.net/Articles/1027096). | +| 6 | [BPF-CCX](https://lpc.events/event/19/contributions/2034) | 谷歌的 BPF CCX 调度器依赖于每个 CCX 的运行队列和异步分箱打包算法, 动态分配和管理线程组的软亲和性, 类似于 soft affinity. 谷歌的重点是确保更好的虚拟机调度, 但这种调度工作同样适用于其他工作负载. 参见 [phoronix, 2025/12/22, Google Taps More Performance Out Of AMD Zen CPUs With BPF-CCX Scheduling](https://www.phoronix.com/news/Google-AMD-BPF-CCX) 以及 [LPC-2025, 2025/12/12, Taming the Chiplet: High Performance CCX scheduling via BPF](https://lpc.events/event/19/contributions/2034) | ### 11.2.2 Google 的 ghOSt ------- @@ -7606,6 +7633,14 @@ ECRTS 2020(32nd Euromicro Conference on Real-Time Systems) 上 Daniel 等人发 | 2025/10/18 | Muhammad Usama Anjum | [PM: Hibernate: Add hibernation cancellation support](https://lore.kernel.org/all/20251018142114.897445-1-usama.anjum@collabora.com) | 旨在支持在休眠过程中取消操作. 当前, 系统休眠需 15-20 秒, 期间无法中断, 影响用户体验. 作者 Muhammad Usama Anjum 提出通过检测电源键中断, 在休眠过程中允许用户中止该流程. 补丁共 4 个, 包括导出休眠状态函数、处理 ACPI 按钮事件、忽略休眠期间的电源键事件, 以及清除挂起标志. 测试表明, 修改后可在休眠中安全取消操作. [phoronix, 2025/10/20, Patches Posted To Allow Hibernation Cancellation On Linux](https://www.phoronix.com/news/Linux-Hibernation-Cancellation) | v1 ☐☑✓ | [2025/10/18, LORE v1, 0/4](https://lore.kernel.org/all/20251018142114.897445-1-usama.anjum@collabora.com) | +### 12.5.3 PM QOS +------- + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:---:|:----:|:---:|:----:|:---------:|:----:| +| 2025/11/25 | Ulf Hansson | [PM: QoS: Introduce a CPU system wakeup QoS limit for s2idle](https://lore.kernel.org/all/20251125112650.329269-1-ulf.hansson@linaro.org) | 邮件提出了一项针对 Linux 内核的补丁系列, 旨在为 s2idle 状态引入 CPU 系统唤醒延迟的 QoS(服务质量) 限制机制. 当前系统在进入低功耗状态时总是选择最深的节能状态, 可能不满足某些对唤醒延迟有严格要求的场景. 为此, Ulf Hansson 提供了一个用户空间接口, 允许设置 CPU 唤醒延迟上限, 从而在选择低功耗状态时兼顾能效与延迟约束. 补丁系列共 6 个, 涉及 PM domain、cpuidle、调度器等核心模块, 并附带文档说明. 此机制适用于需要控制系统唤醒延迟的平台, 如嵌入式或实时系统. | v4 ☐☑✓ | [2025/11/25, LORE v4, 0/6](https://lore.kernel.org/all/20251125112650.329269-1-ulf.hansson@linaro.org) | + + # 13 其他 ------- diff --git a/study/kernel/00-DESCRIPTION/TODO.md b/study/kernel/00-DESCRIPTION/TODO.md index 6f237b1..b4fa37d 100644 --- a/study/kernel/00-DESCRIPTION/TODO.md +++ b/study/kernel/00-DESCRIPTION/TODO.md @@ -944,10 +944,12 @@ git fetch --unshallow | 2025/09/18 | Marco Elver | [Compiler-Based Capability- and Locking-Analysis](https://lore.kernel.org/all/20250918140451.1289454-1-elver@google.com) | 一项基于编译器的"能力分析" (Capability Analysis) 与"锁分析" (Locking Analysis) 功能, 旨在通过 Clang 的静态分析能力, 在编译期检测 Linux 内核中同步机制(如锁、RCU、信号量等) 使用的合规性. 关键点包括:
采用 Clang 的 Capability System 特性, 扩展 C 语言以支持能力注解, 确保锁等资源的获取与释放符合预期.
分析机制独立于运行时工具(如 Lockdep、KCSAN), 无性能开销, 提前发现潜在并发问题.
支持多种同步原语, 包括 spinlock、mutex、rwlock、seqlock、RCU 等.
目标是提升内核并发安全性, 同时降低静态分析误报与维护成本. | v3 ☐☑✓ | [2025/09/18, LORE v3, 0/35](https://lore.kernel.org/all/20250918140451.1289454-1-elver@google.com) | - - - -使用 `schbench` 工具进行测试, 每秒请求数(RPS)从 5.4M 下降到 3.4M, 问题表现为 `newidle balance` 操作次数增加了约 100 倍, 这些操作大多失败, 未能找到负载可迁移的 CPU. 工作线程约 20% 的时间花在 `newidle balance` 上. 因此本补丁尝试在 newidle balance 失败时增大其成本(`domain_cost`), 从而抑制其频繁触发. 同时对成本的上限进行限制, 防止其无限增长. sched_balance_newidle()` 函数中, 原逻辑: 无论 newidle balance 是否成功，均使用实际耗时更新 `max_newidle_lb_cost`. 新逻辑: 如果没有拉取到任务(`pulled_task == false`), 则将该次 balance 的 cost 提升为当前最大 cost 的 1.5 倍. 这样做的目的是: 提升失败操作的成本感知, 使得调度器在未来更谨慎地触发 newidle balance. `update_newidle_cost()` 函数中, 原逻辑: 直接更新 `sd->max_newidle_lb_cost = cost;`, 新逻辑: 增加上限限制, 使用 `sysctl_sched_migration_cost + 200` 作为最大值. 避免成本无限增长 +| 2025/12/04 | Srikar Dronamraju | [Steal time based dynamic CPU resource management](https://lore.kernel.org/all/20251204175405.1511340-1-srikar@linux.ibm.com) | 邮件提出了一种基于 steal time( 虚拟化中被其他虚拟机占用的时间) 的动态 CPU 资源管理机制, 旨在优化 PowerVM Shared LPARs 环境下的调度效率. 通过监控 steal time 来判断系统是否过载或欠载, 并据此动态调整 CPU 容量和可用性, 引导调度器减少资源争用,提升整体性能.

实验数据显示, 在非竞争( nonoise) 和竞争( noise) 场景下, 使用该补丁集后使用的 CPU 核心数减少, 同时缓存缺失、上下文切换、指令执行等指标平均降低约 3 倍, 性能有所提升. 尽管在某些线程数下存在性能回归, 但整体资源利用更高效.

补丁集共 17 个, 涉及调度器、PowerPC 架构及 pseries 平台的多处修改, 支持软下线/上线 CPU、动态调整拓扑和容量、调试接口等功能. 作者欢迎社区反馈, 并指出未来可扩展支持其他架构或其他提示机制. | v1 ☐☑✓ | [2025/12/04, LORE v1, 0/17](https://lore.kernel.org/all/20251204175405.1511340-1-srikar@linux.ibm.com) | + + + + +