From dc0d7200607a59c1dba630e4d8fbad82269dbe90 Mon Sep 17 00:00:00 2001 From: Cheng Jian Date: Sat, 25 Jan 2025 18:19:15 +0800 Subject: [PATCH] description/open_source: update phoronix vs LWN to date 20241115 --- study/kernel/00-DESCRIPTION/AI.md | 60 +++++++++++++++++- study/kernel/00-DESCRIPTION/ARCH.md | 16 +++-- study/kernel/00-DESCRIPTION/BPF.md | 4 +- study/kernel/00-DESCRIPTION/DEBUGGING.md | 29 ++++++++- study/kernel/00-DESCRIPTION/LOCKING.md | 7 ++- study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md | 43 +++++++++---- study/kernel/00-DESCRIPTION/OPEN_SOURCE.md | 3 + study/kernel/00-DESCRIPTION/SCHEDULER.md | 61 +++++++++++++++---- study/kernel/00-DESCRIPTION/TEST.md | 6 +- study/kernel/00-DESCRIPTION/TODO.md | 11 +--- study/kernel/00-DESCRIPTION/VIRT.md | 8 +++ 11 files changed, 201 insertions(+), 47 deletions(-) diff --git a/study/kernel/00-DESCRIPTION/AI.md b/study/kernel/00-DESCRIPTION/AI.md index 393d773..f6e3026 100644 --- a/study/kernel/00-DESCRIPTION/AI.md +++ b/study/kernel/00-DESCRIPTION/AI.md @@ -133,6 +133,19 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad [群魔乱舞：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) + +[OLMoE](https://github.com/allenai/OLMoE) + +### 2.2.2 稀疏化训练 +------- + +[【ICDE 2022】阿里发布稀疏模型训练框架HybridBackend，单位成本下训练吞吐提升至5倍](https://blog.csdn.net/weixin_48534929/article/details/124661176) + ## 2.3 模型压缩和量化 ------- @@ -188,9 +201,11 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad ------- -[LLM推理加速技术简介](https://zhuanlan.zhihu.com/p/691360124) +[知乎--LLM推理加速技术简介](https://zhuanlan.zhihu.com/p/691360124) +[bilibili--如何将大模型与小模型结合？这8种常用策略必看！附17篇案例论文和代码](https://www.bilibili.com/opus/887920175625535524) +[知乎--刀刀宁聊大模型推理--笔记：学习推理加速半年之总结与迷思](https://zhuanlan.zhihu.com/p/704938096) ### 4.2.1 KV Cache 压缩 ------- @@ -207,6 +222,44 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad [聊聊大模型推理中的 KVCache 压缩](https://zhuanlan.zhihu.com/p/708946312) +### 4.2.2 稀疏感知推理加速 +------- + +[论文笔记：DejaVu、LLM in Flash、PowerInfer](https://zhuanlan.zhihu.com/p/675585887) + +[苹果极致LLM端侧方案：LLM in a flash](https://zhuanlan.zhihu.com/p/673775476) + +### 4.2.3 首 Token 时延优化 +------- + +[[Prefill优化][万字]🔥原理&图解vLLM Automatic Prefix Cache(RadixAttention): 首Token时延优化](https://zhuanlan.zhihu.com/p/693556044) + +### 4.2.4 投机执行 +------- + +[论文导读 | 投机解码加速模型推理](https://zhuanlan.zhihu.com/p/698333087) + +[大模型推理妙招—投机采样(Speculative Decoding)](https://zhuanlan.zhihu.com/p/651359908) + +[最全LLM自投机算法汇总](https://zhuanlan.zhihu.com/p/706111755) + +[LLM推理提速2.8倍，CMU清华姚班校友提出「投机式推理」引擎SpecInfer，小模型撬动大模型高效推理](https://www.jiqizhixin.com/articles/2023-05-30-3) + + +## 4.3 算子库 +------- + + +PaddlePaddle/Anakin + +Tencent/ncnn + +Tencent/FeatherCNN + +dmlc/tvm + +ARM-software/ComputeLibrary + # 5 分析工具 ------- @@ -292,6 +345,11 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad | [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 架构 | +| [浅显易懂地介绍 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 | ## 6.2 Survey diff --git a/study/kernel/00-DESCRIPTION/ARCH.md b/study/kernel/00-DESCRIPTION/ARCH.md index 6ee1460..eb559b1 100644 --- a/study/kernel/00-DESCRIPTION/ARCH.md +++ b/study/kernel/00-DESCRIPTION/ARCH.md @@ -62,7 +62,7 @@ blogexcerpt: 虚拟化 & KVM 子系统 ## 1.1 架构新特性 ------- -### 1.1.1 split lock detect +### 1.1.1 split lock detect/Bus Lock Trap ------- | 日期 | LWN | 翻译 | @@ -104,7 +104,7 @@ v5.7 引入了拆分锁检测的支持, 这依赖于 x86_64 intel CPU 遇到拆 | 2021/04/19 | Fenghua Yu | [x86/bus_lock: Set rate limit for bus lock](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=d28397eaf4c27947a1ffc720d42e8b3a33ae1e2a) | 通过限制总线锁的速率而不是杀死进程来缓解拆分锁带来的问题. | v1 ☑✓ 5.14-rc1 | [Patchwork 0/4](https://lore.kernel.org/all/20210419214958.4035512-1-fenghua.yu@intel.com) | | 2022/03/10 | Tony Luck | [Make life miserable for split lockers](https://lore.kernel.org/all/20220310204854.31752-1-tony.luck@intel.com) | 通过强制用户空间对拆分锁进行顺序访问. 在解决问题的同时, 也确保了在这些条件下整体系统性能更好. 参见 [Linux 5.19 To"Make Life Miserable"In Slowing Down Bad Behaving Split-Lock Apps](https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.19-Split-Lock). | v2 ☐☑✓ | [LORE v2,0/2](https://lore.kernel.org/all/20220310204854.31752-1-tony.luck@intel.com) | | 2022/10/24 | Guilherme G. Piccoli | [x86/split_lock: Add sysctl to control the misery mode](https://lore.kernel.org/all/20221024200254.635256-1-gpiccoli@igalia.com) | Splitlock Detector 机制通过人为限制触发了 Splitlock 锁的软件的性能, 从而保证整机的吞吐量和性能. 然后推动触发了对应软件整改和优化自己的代码, 但是一些专用软件特别是闭源软件改起来相对麻烦, 比如 Linux 上 window 游戏等. 这引发了这些 window 游戏性能的大幅度下降, 参见 [Linux Adding New Control Since Its Splitlock Detector Is Wrecking Some Steam Play Games](https://www.phoronix.com/news/Linux-Splitlock-Hurts-Gaming). 现在为 Linux 6.2 添加了一个新的 sysctl 可调参数 "split_lock_reduce", 以便轻松禁用 "痛苦模式" 行为. 当将 split_lock_reduce 设置为 0 时, 只会在内核锁中出现警告, 而不会带来循序存取损失. 默认情况下, 故意的性能降低模式仍然处于活动状态, 但是我们可能会看到 SteamOS 之类的操作系统自动关闭 split_lock_reduce 可调参数. 也有可能我们会看到这个自动调整喜欢野性的游戏模式. 由于它是一个 sysctl 选项, 现在在运行时管理起来比在启动时不得不为内核使用劈开锁检测选项更容易, 但是内核开发人员到目前为止还想保持默认的 “糟糕性能” 模式, 以激励用户空间软件围绕减少劈开锁进行改进. | v3 ☐☑✓ | [LORE](https://lore.kernel.org/all/20221024200254.635256-1-gpiccoli@igalia.com) | -| 2024/04/29 | Ravi Bangoria | [x86/cpu: Add Bus Lock Detect support for AMD](https://lore.kernel.org/all/20240429060643.211-1-ravi.bangoria@amd.com) | [AMD Prepares Linux For"Bus Lock Trap"Feature On Upcoming CPUs](https://www.phoronix.com/news/AMD-Bus-Lock-Trap-Detect-Linux). | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20240429060643.211-1-ravi.bangoria@amd.com) | +| 2024/08/02 | Ravi Bangoria | [x86/cpu: Add Bus Lock Detect support for AMD](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=408eb7417a92c5354c7be34f7425b305dfe30ad9) | [AMD Prepares Linux For"Bus Lock Trap"Feature On Upcoming CPUs](https://www.phoronix.com/news/AMD-Bus-Lock-Trap-Detect-Linux), [AMD Bus Lock Detect Positioned Ahead Of Linux 6.12](https://www.phoronix.com/news/AMD-Bus-Lock-Detect-Coming) 和 [phoronix, 2024/11/22, AMD Bus Lock Trap Support Merged For Linux 6.13](https://www.phoronix.com/news/AMD-Bus-Lock-Trap-Linux-6.13). | v1 ☐☑✓ v6.13-rc1 | [2024/04/29, LORE v1,0/3](https://lore.kernel.org/all/20240429060643.211-1-ravi.bangoria@amd.com)
*-*-*-*-*-*-*-*
[2024/08/02, LORE V4,0/4](https://lore.kernel.org/all/20240808062937.1149-1-ravi.bangoria@amd.com) | ### 1.1.2 Sub-Page Write Protection @@ -198,6 +198,7 @@ Intel Architecture Day 2021, 官宣了自己的服务于终端和桌面场景的 | 2022/04/15 | Zhang Rui | [intel_idle: add AlderLake support](https://lore.kernel.org/all/20220415093951.2677170-1-rui.zhang@intel.com) | 参见 [phoronix 报道](https://www.phoronix.com/scan.php?page=news_item&px=Intel-Idle-Alder-Lake) | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20220415093951.2677170-1-rui.zhang@intel.com) | | 2022/10/24 | Rafael J. Wysocki | [cpufreq: intel_pstate: Make HWP calibration work on all hybrid platforms](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=f5c8cf2a4992dd929fa0c2f25c09ee69b8dcbce1) | 修复硬件 P-State(HWP) 校准程序在 Intel 混合 CPU 平台的一些问题.
1. 以前进行这项工作的尝试是基于使用 CPPC, 但事实证明, CPPC 信息对于此目的来说不够可靠, 唯一的方法是对 P 核和 E 核使用硬编码的比例因子(幸运的是, 这与非混合情况下相同). 幸运的是, 迄今为止, P-core 的相同缩放因子适用于所有混合平台. 这个补丁集的第一个补丁通过避免在一个 CPU 上读取的 MSR 值将用于另一个 CPU 的性能扩展的情况, 确保所有 CPU 都将使用来自 MSR 的正确信息. 第二个补丁完善了 hybrid_get_cpu_scaling() 的实现, 用已知的缩放因子作为 cpu->pstate.scaling. | v1 ☑✓ 6.1-rc3 | [LORE v1,0/2](https://lore.kernel.org/all/2258064.ElGaqSPkdT@kreacher) | | 2024/04/25 | Rafael J. Wysocki | [x86/intel_pstate: Set asymmetric CPU capacity on hybrid systems](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=929ebc93ccaa8d183a2ba9f1cf769d1bfb847cca) | 这个补丁集是为调度器提供基于英特尔硬件的 x86 混合系统上的非对称 CPU 容量信息. 不对称的 CPU 容量信息在混合系统中很重要, 因为它允许以一致的方式计算系统中所有 CPU 的任务利用率, 而不管它们的容量如何. 这反过来又允许 schedutil-cpufreq 调控器在任务在不同容量的 CPU 之间迁移的情况下一致地设置 CPU 性能级别. 它还应该有助于改善混合系统上的任务布局和负载平衡决策, 这是 EAS 的关键. intel_pstate 使用 MSR_HWP_CAPABILITIES 的 HWP_HIGHEST_PERF 值，通过之前引入的 arch_set_cpu_capacity() 在没有 SMT 的混合系统上设置不对称的 CPU 容量信息. 如果给定系统是混合和非 SMT, 则在初始化所有在线 CPU 并找到具有最大 HWP_HIGHEST_PERF 值的 CPU 后, 新代码将禁用调度器中的 ITMT 支持 (因为它可能会妨碍调度器中的非对称 CPU 容量代码, 该代码通过设置非对称 CPU 容量自动启用). 接下来, 它通过将其 HWP_HIGHEST_PERF 和 SCHED_CAPACITY_SCALE 的乘积除以最大 HWP_HIGHEST_PERF 来计算每个(在线)CPU 的容量. 参见 phoronix 报道 [New Intel P-State Linux Driver Patches To Better Handle Hybrid Core CPUs](https://phoronix.com/news/Intel-P-State-Asymmetic-Hybrid), [Intel P-State Patches Further Tune Linux For Better Scheduling On Hybrid CPUs](https://www.phoronix.com/news/Intel-P-State-Asymmetric-Cap), [New Intel Linux Patches Continue Working To Improve Hybrid CPU Task Placement](https://www.phoronix.com/news/Intel-Linux-Mid-2024-Hybrid), [Linux 6.12 To Enhance The Hybrid P/E Core Experience On Intel Lunar Lake](https://www.phoronix.com/news/Linux-6.12-Hybrid-No-SMT-Cap). | v1 ☐☑✓ v6.11-rc1 | [2024/04/25, LORE v1,0/3](https://lore.kernel.org/all/7663799.EvYhyI6sBW@kreacher)
*-*-*-*-*-*-*-*
[2024/08/02, LORE v1,0/3](https://lore.kernel.org/all/4908113.GXAFRqVoOG@rjwysocki.net)
*-*-*-*-*-*-*-*
[2024/08/25, LORE v1,0/3](https://lore.kernel.org/all/7663799.EvYhyI6sBW@kreacher)
*-*-*-*-*-*-*-*
[2024/08/12, LORE, v2,0/3](https://lore.kernel.org/all/4941491.31r3eYUQgx@rjwysocki.net)
*-*-*-*-*-*-*-*
[2024/08/28, LORE v3,0/2](https://lore.kernel.org/all/3310447.aeNJFYEL58@rjwysocki.net) | +| 2024/11/08 | Rafael J. Wysocki | [cpufreq: intel_pstate: Enable EAS on hybrid platforms without SMT](https://lore.kernel.org/all/3607404.iIbC2pHGDl@rjwysocki.net) | 参见 [phoronix, 2024/12/11, Intel Adapting Energy Aware Scheduling "EAS" To P-State Driver For Lunar Lake](https://www.phoronix.com/news/Intel-P-State-EAS-Experimental), [phoronix, 2024/12/14, Intel P-State Energy Aware Scheduling Patches Updated For Lunar Lake](https://www.phoronix.com/news/Intel-P-State-EAS-Lunar-Lake). | v1 ☐☑✓ | [2024/11/08, LORE v1,0/6](https://lore.kernel.org/all/3607404.iIbC2pHGDl@rjwysocki.net)
*-*-*-*-*-*-*-*
[2024/11/08, LORE v21,0/9](https://lore.kernel.org/linux-pm/5861970.DvuYhMxLoT@rjwysocki.net) | @@ -270,7 +271,7 @@ phoronix 上所有关于 HFI 相关的报道 [phoronix, Hardware Feedback Interf | 2024/01/31 | Stanislaw Gruszka | [thermal/netlink/intel_hfi: Enable HFI feature only when required](https://lore.kernel.org/all/20240131120535.933424-1-stanislaw.gruszka@linux.intel.com) | 该补丁集仅在有用户空间实体侦听热网络链接事件时才启用 HFI. 引入了一个 netlink 通知, 它与 netlink_has_listners()检查一起, 允许驱动程序根据实际用户空间消费者的存在发送 netlink 多播事件. 此功能通过允许在不需要时禁用功能来优化资源使用. 然后在 intel_hif 驱动程序中实现通知机制, 用于动态禁用硬件反馈接口 (HFI). 通过实现 netlink 通知回调, 驱动程序现在可以根据实际需求启用或禁用 HFI, 特别是当用户空间应用程序(如英特尔速度选择或英特尔低功耗守护进程) 利用与性能和能效功能相关的事件时. 在有 Intel HFI 但没有安装用户空间组件的机器上, 我们可以节省大量的 CPU 周期. | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20240131120535.933424-1-stanislaw.gruszka@linux.intel.com) | | 2024/02/02 | Ricardo Neri | [thermal: intel: hfi: Prework for the virtualization of HFI](https://lore.kernel.org/all/20240203040515.23947-1-ricardo.neri-calderon@linux.intel.com) | 用于 [支持 IPC 类任务的调度](https://lore.kernel.org/all/20230613042422.5344-1-ricardo.neri-calderon@linux.intel.com) 的基础
1. 重新组织 HFI 驱动程序的部分, 以便于实现虚拟 HFI 表.
2. 引入了 ITD 类的概念并启用了 ITD.
3. 增加了对重置当前任务的 ITD 分类历史的支持, 以便在上下文切换期间使用. HFI 的虚拟化要求在系统中无条件启用 HFI 和 ITD. 这与 Stanislaw 的补丁集 [thermal/netlink/intel_hfi: Enable HFI feature only when required](https://lore.kernel.org/all/20240131120535.933424-1-stanislaw.gruszka@linux.intel.com) 存在冲突. | v1 ☐☑✓ | [LORE v1,0/9](https://lore.kernel.org/all/20240203040515.23947-1-ricardo.neri-calderon@linux.intel.com) | | 2024/02/23 | Stanislaw Gruszka | [thermal/netlink/intel_hfi: Enable HFI feature only when required](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=b33f3d2677b8ddd7a3aba2b02497422a1d2c2a01) | 英特尔 HFI 驱动程序可以在需要时启用它, 从而 "节省大量 CPU 周期". 仅在有用户空间使用者处于活动状态时启用它. 如果英特尔 Speed Select 或英特尔低功耗守护程序正在运行, 英特尔 HFI 接口将被激活, 但如果不是, 它将被禁用, 从而显然可以节省大量 CPU 资源. 参见 phoronix 报道 [英特尔 HFI 驱动程序可以“节省大量 CPU 周期”，只需在需要时才启用自身](https://www.phoronix.com/news/Intel-HFI-Enable-Disable) 以及 [phoronix, 2024/04/01, Intel HFI Driver Will Quit Wasting CPU Cycles With Linux 6.10](https://www.phoronix.com/news/Intel-HFI-Efficient-Linux-6.10) | v4 ☐☑✓ v6.10-rc1 | [LORE v4,0/3](https://lore.kernel.org/all/20240223155942.60813-1-stanislaw.gruszka@linux.intel.com) | -| 2024/10/10 | Mario Limonciello | [Add support for AMD hardware feedback interface](https://lore.kernel.org/all/20241010193705.10362-1-mario.limonciello@amd.com) | AMD 异构内核设计和硬件反馈接口 (HFI) 为调度程序提供行为分类和动态更新的排名表, 供调度程序在为任务选择内核时使用. 这用于向操作系统指示基于工作负载的启发式反馈, 以便做出计划决策.1.
实时线程特征分类功能: 新增 X86_FEATURE_WORKLOAD_CLASS "工作负载分类" 功能. 线程在运行时硬件根据特征将其分类为 3 个类型(0 到 2), 这些类表示可能受益于特殊调度行为的线程性能/功耗特征. 实时线程分类功能由操作系统使用, 用于通知计划程序应将线程放置在何处以获得最佳性能或能效.
2. 排名表: 线程分类有助于从排名表中选择 CPU, 该表从两个维度描述了每个分类的效率和性能排名. 排名表提供的排名数据是 0 到 255 之间的数字, 其中性能值越高表示性能能力越高, 效率越高表示效率越高. 所有 CPU 内核都分为不同的类 ID. 在每个类排名中, 核心可能具有不同的排名值. 因此, 从每个分类 ID 中选取允许调度程序选择最佳核心, 同时将线程分类到指定的工作负载类中. 内核排名表提供了 PCCT 子空间类型 4 共享内存, 其中包括内存基址和长度. 参见 [phoronix, 2024/08/24, AMD Developing New Heterogeneous CPU Core Driver For Linux Systems](https://www.phoronix.com/news/AMD-Heterogeneous-Core-Driver), [phoronix, 2024/10/11, AMD Hardware Feedback Interface "HFI" Driver Updated For Heterogeneous CPUs](https://www.phoronix.com/news/AMD-HFI-Linux-Driver-v2) | v2 ☐☑✓ | [2024/08/27, LORE, 00/10](https://lore.kernel.org/platform-driver-x86/cover.1724748733.git.perry.yuan@amd.com/)
*-*-*-*-*-*-*-*
[2024/10/10, LORE v2,0/13](https://lore.kernel.org/all/20241010193705.10362-1-mario.limonciello@amd.com) | +| 2024/10/10 | Mario Limonciello | [Add support for AMD hardware feedback interface](https://lore.kernel.org/all/20241010193705.10362-1-mario.limonciello@amd.com) | AMD 异构内核设计和硬件反馈接口 (HFI) 为调度程序提供行为分类和动态更新的排名表, 供调度程序在为任务选择内核时使用. 这用于向操作系统指示基于工作负载的启发式反馈, 以便做出计划决策.1.
实时线程特征分类功能: 新增 X86_FEATURE_WORKLOAD_CLASS "工作负载分类" 功能. 线程在运行时硬件根据特征将其分类为 3 个类型(0 到 2), 这些类表示可能受益于特殊调度行为的线程性能/功耗特征. 实时线程分类功能由操作系统使用, 用于通知计划程序应将线程放置在何处以获得最佳性能或能效.
2. 排名表: 线程分类有助于从排名表中选择 CPU, 该表从两个维度描述了每个分类的效率和性能排名. 排名表提供的排名数据是 0 到 255 之间的数字, 其中性能值越高表示性能能力越高, 效率越高表示效率越高. 所有 CPU 内核都分为不同的类 ID. 在每个类排名中, 核心可能具有不同的排名值. 因此, 从每个分类 ID 中选取允许调度程序选择最佳核心, 同时将线程分类到指定的工作负载类中. 内核排名表提供了 PCCT 子空间类型 4 共享内存, 其中包括内存基址和长度. 参见 [phoronix, 2024/08/24, AMD Developing New Heterogeneous CPU Core Driver For Linux Systems](https://www.phoronix.com/news/AMD-Heterogeneous-Core-Driver), [phoronix, 2024/10/11, AMD Hardware Feedback Interface "HFI" Driver Updated For Heterogeneous CPUs](https://www.phoronix.com/news/AMD-HFI-Linux-Driver-v2), [phoronix, 2024/12/07, AMD Hardware Feedback Interface "HFI" Patches Updated For The Linux Kernel](https://www.phoronix.com/news/AMD-HFI-v7-Linux) | v2 ☐☑✓ | [2024/08/27, LORE, 00/10](https://lore.kernel.org/platform-driver-x86/cover.1724748733.git.perry.yuan@amd.com/)
*-*-*-*-*-*-*-*
[2024/10/10, LORE v2,0/13](https://lore.kernel.org/all/20241010193705.10362-1-mario.limonciello@amd.com)
*-*-*-*-*-*-*-*
[2024/11/30, LORE v7,00/12](https://lore.kernel.org/lkml/20241130140703.557-1-mario.limonciello@amd.com) | @@ -479,9 +480,11 @@ SGX 旨在以硬件安全为强制性保障, 不依赖于固件和软件的安 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| -| 2021/11/10 | Brijesh Singh | [Add AMD Secure Nested Paging (SEV-SNP) Guest Support](https://patchwork.kernel.org/project/linux-mm/cover/20211110220731.2396491-1-brijesh.singh@amd.com) | Guest 支持 AMD SEV SNP. | v7 ☐ | [Patchwork v7,00/45](https://patchwork.kernel.org/project/linux-mm/cover/20211110220731.2396491-1-brijesh.singh@amd.com)
*-*-*-*-*-*-*-*
[LORE v13,00/26](https://lore.kernel.org/lkml/20240418194133.1452059-1-michael.roth@amd.com) | +| 2021/11/10 | Brijesh Singh | [Add AMD Secure Nested Paging (SEV-SNP) Guest Support](https://patchwork.kernel.org/project/linux-mm/cover/20211110220731.2396491-1-brijesh.singh@amd.com) | Guest 支持 AMD SEV SNP. | v7 ☐ | [Patchwork v7,00/45](https://patchwork.kernel.org/project/linux-mm/cover/20211110220731.2396491-1-brijesh.singh@amd.com)
*-*-*-*-*-*-*-*
[LORE v13,00/26](https://lore.kernel.org/lkml/20240418194133.1452059-1-michael.roth@amd.com) | | 2024/06/05 | Tom Lendacky | [Provide SEV-SNP support for running under an SVSM](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=99ef9f59847cab1f9091cd4b9d7efbee0ae4fc86) | 这个补丁集的主要目标是为 Linux 提供在 Secure Virtualization Service Module(SVSM)下运行的支持, 使得 Linux 可以在较低的虚拟机特权级别 (VMPL) 上执行.
通过在较低的 VMPL 上运行 Linux, SVSM 可以被用作提供服务的角色, 例如虚拟 TPM(Trusted Platform Module), 这些服务可以为 SEV-SNP Confidential VM(CVM)内的 Linux 提供, 而不必信任来自 Hypervisor 的服务. SEV-SNP 是 AMD 的一种安全虚拟化技术, 它提供了隔离和保护虚拟机的能力.
目前, Linux 客人通常期望在最高的 VMPL(即 VMPL0)运行, 但某些 SEV-SNP 相关的操作需要这个最高权限级别的 VMPL. 特别地, PVALIDATE 指令和 RMPADJUST 指令在设置页面的 VMSA 属性时需要 VMPL0 的权限 (在启动 APs 时使用).
如果 Linux 要在一个较低的 VMPL(例如 VMPL2) 上运行, 那么它必须通过一个运行在 VMPL0 上的 SVSM 来进行那些它不再能自己执行的操作. Linux 与 SVSM 的交互和使用方式在 SVSM 规范 [1] 和 GHCB(Guest Handle Callback)规范 [2] 中有详细记录. 这个补丁系列引入了在 SVSM 下运行 Linux 的支持, 主要包括以下几方面:
1. 检测 SVSM 的存在, 当不在 VMPL0 运行时, 调用 SVSM 来执行那些受限于当前 VMPL 的页面操作
2. 引入了对 GHCB 的支持, 允许在非 VMPL0 的 VM 中执行 RMPADJUST 和 PVALIDATE 指令
3. 改进了对 AP 启动的支持
4. 更新了对 SEV-SNP 初始化序列的处理
5. 改进了对 VMSA 和 SEV-SNP 安全性的支持
这个补丁系列涉及了对内核中多个模块的修改, 以确保 Linux 能够安全地在 SVSM 环境下运行, 并充分利用 SEV-SNP 提供的安全特性. 补丁系列还包含对配置选项的更新, 以及对用户空间 API 的改进, 以方便用户空间应用能够识别和利用 SVSM 的存在. [AMD Advances Confidential Computing In Linux 6.11 With SEV-SNP + SVSM Guest Support](https://www.phoronix.com/news/AMD-SEV-SNP-SVSM-Linux-6.11) | v5 ☐☑✓ v6.1-rc1 | [LORE v5,0/13](https://lore.kernel.org/all/cover.1717600736.git.thomas.lendacky@amd.com) | | 2022/09/29 | Quan Nguyen | [Add Ampere's Altra SMPro MFD and its child drivers](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=4e6104b1e70020ad500f0fab7238898dd2ea2a38) | [Hardware Monitoring Driver Updates Land In Linux 6.2](https://www.phoronix.com/news/Linux-6.2-HWMON) 和 [Hardware Monitoring Improvements Submitted For Linux 6.11](https://www.phoronix.com/news/Linux-6.11-HWMON). | v9 ☐☑✓ 6.2 | [LORE v9,0/9](https://lore.kernel.org/all/20220929094321.770125-1-quan@os.amperecomputing.com) | +| 2024/12/02 | Tom Lendacky | [Provide support for RMPREAD and a segmented RMP](https://lore.kernel.org/all/cover.1733172653.git.thomas.lendacky@amd.com) | 参见 phoronix 报道 [phoronix, 2024/12/16, Linux 6.14 Looks To Support AMD's Zen 5 RMPREAD Instruction & Segmented RMP Mode](https://www.phoronix.com/news/Linux-6.14-AMD-RMPREAD) | v6 ☐☑✓ | [LORE v6,0/8](https://lore.kernel.org/all/cover.1733172653.git.thomas.lendacky@amd.com) | + ## 1.9 Software Defined Silicon ------- @@ -1206,6 +1209,7 @@ Box64 v0.3 现在作为此用户空间 x86_64 模拟器的最新功能版本提 [Box64 v0.3 Brings Support For Emulating x86_64 Binaries With AVX/AVX2 On ARM](https://www.phoronix.com/news/Box64-0.3-Released). +[Box64 v0.3.2 Emulator Adds Box32 Option, Introduces Native Flags & More](https://www.phoronix.com/news/Box64-0.3.2-Released) ### 6.7.4 Loongson Binary Translation Slated(LBT) ------- @@ -1308,6 +1312,7 @@ openEuler 提供了 [openEuler/prefetch_tuning](https://gitee.com/openeuler/pref | 2023/02/01 | Srinivas Pandruvada | [Add TPMI support](https://lore.kernel.org/all/20230202010738.2186174-1-srinivas.pandruvada@linux.intel.com) | Intel Topology Aware Register and PM Capsule Interface | v1 ☐☑✓ | [LORE v1,0/7](https://lore.kernel.org/all/20230202010738.2186174-1-srinivas.pandruvada@linux.intel.com) | | 2019/05/27 | Rafael J. Wysocki | [PM / arch: x86: MSR_IA32_ENERGY_PERF_BIAS handling fixes and sysfs i/f](https://lore.kernel.org/all/3844875.YPkTDDlcrF@kreacher) | Performance and Energy Bias Hint (EPB). | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/1637073.gl2OfxWTjI@aspire.rjw.lan) | | 2023/08/07 | Jason Andryuk | [Intel Hardware P-States (HWP) support](https://lore.kernel.org/all/20230807185119.98333-1-jandryuk@gmail.com) | TODO | v8 ☐☑✓ | [LORE v8,0/15](https://lore.kernel.org/all/20230807185119.98333-1-jandryuk@gmail.com) | +| 2024/08/21 | Tero Kristo | [platform/x86: Add support for Intel uncore ELC feature](https://lore.kernel.org/all/20240821131321.824326-1-tero.kristo@linux.intel.com) | 这组补丁的主要目的是为 Intel 的非核心(uncore)驱动添加对 ELC(Efficiency Latency Control)特性的支持, 该特性可以在较新的 SoC(系统级芯片)上找到, 并允许更精细地调整效率与延迟之间的权衡, 特别是在非核心频率缩放方面. ELC 特性旨在通过控制非核心频率来优化性能和功耗. 具体来说, 它提供了在效率(更低的功耗)和响应时间(更低的延迟)之间进行权衡的能力. 此补丁集将 ELC 支持集成到现有的 Intel uncore 驱动中, 以便更好地管理这些硬件特性. 参见 [phoronix, 2024/08/21, Intel Uncore Linux Driver Prepares ELC "Efficiency Latency Control" Feature](https://www.phoronix.com/news/Intel-Uncore-Efficiency-ELC) | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20240821131321.824326-1-tero.kristo@linux.intel.com) | ### 6.12.2 AMD @@ -1382,7 +1387,7 @@ AMD-pstate 驱动程序利用 ITMT 体系结构提供的功能和数据结构, | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:---:|:----:|:---:|:----:|:---------:|:----:| -| 2023/08/29 | Tony Luck | [Add support for Sub-NUMA cluster (SNC) systems](https://lore.kernel.org/all/20230829234426.64421-1-tony.luck@intel.com) | Add support for Sub-NUMA cluster (SNC) systems](https://lore.kernel.org/all/20240528222006.58283-1-tony.luck@intel.com) | 英特尔推出了一个大型的 Linux 内核补丁系列, 以改进 Sub-NUMA 集群 "SNC" 支持, 使其在现代英特尔硬件上与英特尔资源总监技术(RDT) 配合良好. SNC 将 CPU 内核 / 缓存 / 内存拆分为多个 NUMA 域有助于提高 NUMA 感知工作负载的性能. 参见 phoronix 报道 [Intel Fixing Up Sub-NUMA Clustering For Linux So That It Behaves With RDT](https://www.phoronix.com/news/Intel-SNT-RDT-Fixing-Up) 和 [Intel Sub-NUMA Clustering Will Stop Clashing With Resource Director On Linux 6.11+](https://www.phoronix.com/news/Intel-SNC-RDT-Behaves-Linux-611). | v5 ☐☑✓ | [LORE v5,0/8](https://lore.kernel.org/all/20230829234426.64421-1-tony.luck@intel.com)
*-*-*-*-*-*-*-*
[LORE v19,0/20](https://lore.kernel.org/all/20240528222006.58283-1-tony.luck@intel.com) | +| 2023/08/29 | Tony Luck | [Add support for Sub-NUMA cluster (SNC) systems](https://lore.kernel.org/all/20230829234426.64421-1-tony.luck@intel.com) | Add support for Sub-NUMA cluster (SNC) systems](https://lore.kernel.org/all/20240528222006.58283-1-tony.luck@intel.com) | 英特尔推出了一个大型的 Linux 内核补丁系列, 以改进 Sub-NUMA 集群 "SNC" 支持, 使其在现代英特尔硬件上与英特尔资源总监技术(RDT) 配合良好. SNC 将 CPU 内核 / 缓存 / 内存拆分为多个 NUMA 域有助于提高 NUMA 感知工作负载的性能. 参见 phoronix 报道 [Intel Fixing Up Sub-NUMA Clustering For Linux So That It Behaves With RDT](https://www.phoronix.com/news/Intel-SNT-RDT-Fixing-Up), [phoronix, 2024/11/19, Intel Sub-NUMA Clustering Will Stop Clashing With Resource Director On Linux 6.11+](https://www.phoronix.com/news/Intel-SNC-RDT-Behaves-Linux-611) 和 [phoronix, 2024/11/19, Intel SNC6 Sub-NUMA Clustering Support With Linux 6.13](https://www.phoronix.com/news/Intel-SNC6-For-Linux-6.13). | v5 ☐☑✓ | [LORE v5,0/8](https://lore.kernel.org/all/20230829234426.64421-1-tony.luck@intel.com)
*-*-*-*-*-*-*-*
[LORE v19,0/20](https://lore.kernel.org/all/20240528222006.58283-1-tony.luck@intel.com) | | 2023/12/07 | Tony Luck | [x86/resctrl: mba_MBps enhancements](https://lore.kernel.org/all/20231207195613.153980-1-tony.luck@intel.com) | TODO | v6 ☐☑✓ | [LORE v6,0/3](https://lore.kernel.org/all/20231207195613.153980-1-tony.luck@intel.com) | | 2024/02/13 | James Morse | [x86/resctrl: monitored closid+rmid together, separate arch/fs locking](https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/log/?id=fb700810d30b9eb333a7bf447012e1158e35c62f) | [Improved Memory Bandwidth Throttling Behavior For Linux 6.9](https://www.phoronix.com/news/Linux-69-RAM-Bandwidth-Throttle) | v9 ☐☑✓ 6.9-rc1 | [LORE v9,0/24](https://lore.kernel.org/all/20240213184438.16675-1-james.morse@arm.com) | | 2024/03/21 | James Morse | [x86/resctrl: Move the resctrl filesystem code to /fs/resctrl](https://lore.kernel.org/all/20240321165106.31602-1-james.morse@arm.com) | TODO | v1 ☐☑✓ | [LORE v1,0/31](https://lore.kernel.org/all/20240321165106.31602-1-james.morse@arm.com) | @@ -1397,6 +1402,7 @@ AMD-pstate 驱动程序利用 ITMT 体系结构提供的功能和数据结构, # 7 GPU ------- +[phoronix, 2024/12/11, How AMD Is Taking Standard C/C++ Code To Run Directly On GPUs](https://www.phoronix.com/news/AMD-Standard-C-Code-GPUs) | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:---:|:----:|:---:|:----:|:---------:|:----:| diff --git a/study/kernel/00-DESCRIPTION/BPF.md b/study/kernel/00-DESCRIPTION/BPF.md index 74568bf..2c3d346 100644 --- a/study/kernel/00-DESCRIPTION/BPF.md +++ b/study/kernel/00-DESCRIPTION/BPF.md @@ -441,7 +441,7 @@ raw_tracepoint 相比 tracepoint | 2021/06/19 | Alan Maguire | [libbpf: BTF dumper support for typed data](https://lore.kernel.org/patchwork/cover/1448989) | 引入 btf_dump__dump_type_data, 可以用来输出结构体的信息. | v5 ☐ | [PatchWork v5,bpf-next,0/3](https://lore.kernel.org/patchwork/cover/1448989) | -## 3.1 5 function call +## 3.1 function call ------- [Calling kernel functions from BPF](https://lwn.net/Articles/856005) @@ -654,7 +654,7 @@ Wasmtime 完全开源, 使用 Rust 编程语言, 是的, 并且符合 WASI 标 | [apache/skywalking-rover](https://github.com/apache/skywalking-rover) | | | [GroundCover](https://github.com/groundcover-com) | [GroundCover](https://www.groundcover.com) 轻松、大规模地监控 K8s 应用 | | [Exein-io/pulsar](https://github.com/Exein-io/pulsar) | [Tracing the Linux kernel using Exein Pulsar: a 5 Minute Tutorial](https://blog.exein.io/pulsar-tutorial) -| [ebpf-for-windows](https://github.com/microsoft/ebpf-for-windows) | [eBPF programming on Windows](https://blog.subcom.tech/ebpf-programming-on-windows). | +| [ebpf-for-windows](https://github.com/microsoft/ebpf-for-windows) | [eBPF programming on Windows](https://blog.subcom.tech/ebpf-programming-on-windows)
*-*-*-*-*-*-*-*
[eBPF Is Coming for Windows](https://thenewstack.io/ebpf-is-coming-for-windows). | | [redcanaryco/ebpfmon](https://github.com/redcanaryco/ebpfmon) | [eBPFmon: A new tool for exploring and interacting with eBPF applications](https://redcanary.com/blog/ebpfmon) | | [TrailOfBits](https://github.com/trailofbits) | [Trail of Bits 开发了一套开源库, 旨在简化 eBPF 应用程序的创建和部署. 这些库有助于高效的进程和网络事件监控、函数跟踪、内核调试符号解析和 eBPF 代码生成. 参见 [Use our suite of eBPF libraries](https://blog.trailofbits.com/2023/08/09/use-our-suite-of-ebpf-libraries). | | [Netflix/bpftop](https://github.com/Netflix/bpftop) | [bpftop blog](https://netflixtechblog.com/announcing-bpftop-streamlining-ebpf-performance-optimization-6a727c1ae2e5) diff --git a/study/kernel/00-DESCRIPTION/DEBUGGING.md b/study/kernel/00-DESCRIPTION/DEBUGGING.md index 9ef697c..9b61122 100644 --- a/study/kernel/00-DESCRIPTION/DEBUGGING.md +++ b/study/kernel/00-DESCRIPTION/DEBUGGING.md @@ -137,6 +137,9 @@ https://lwn.net/Articles/422487/ # 4 KDUMP ------- +## 4.1 KDUMP +------- + | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| @@ -144,9 +147,16 @@ https://lwn.net/Articles/422487/ | 2022/08/28 | Baoquan He | [arm64, kdump: enforce to take 4G as the crashkernel low memory end](https://patchwork.kernel.org/project/linux-mm/cover/20220828005545.94389-1-bhe@redhat.com/) | 671768 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/20220828005545.94389-1-bhe@redhat.com) | | 2024/03/05 | Steven Rostedt | [tracing: Persistent traces across a reboot or crash](https://lore.kernel.org/all/20240306015910.766510873@goodmis.org) | [Experimental Linux Patches Allow Kernel Tracing To Work Past Reboots/Crashes](https://www.phoronix.com/news/Linux-Tracing-Post-Reboots). | v1 ☐☑✓ | [LORE v1,0/8](https://lore.kernel.org/all/20240306015910.766510873@goodmis.org) | - [crash extension modules](https://crash-utility.github.io/extensions.html) +## 4.2 QR Code +------- + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:---:|:----:|:---:|:----:|:---------:|:----:| +| 2024/08/22 | Jocelyn Falempe | [drm/panic: Add a QR code panic screen](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=cb5164ac43d0fc37ac6b45cabbc4d244068289ef) | 参见 phoronix 报道 [phoronix, 2024/08/29, Linux 6.12 To Optionally Display A QR Code During Kernel Panics](https://www.phoronix.com/news/Linux-6.12-DRM-Panic-QR-Code). | v7 ☐☑✓ v6.12-rc1 | [LORE v7,0/4](https://lore.kernel.org/all/20240822073852.562286-1-jfalempe@redhat.com) | + + # 5 REFCOUNT ------- @@ -272,6 +282,8 @@ $reclaim = current\_mem \times reclaim\_ratio \times max(0,1 – \frac{psi_some} [phoronix, 2024/09/23, vDSO getrandom() Ported To Five More CPU Architectures With Linux 6.12](https://www.phoronix.com/news/Linux-6.12-Random) +[phoronix, 2024/11/13, GNU C Library Merges Support for getrandom vDSO](https://www.phoronix.com/news/glibc-getrandom-vDSO-Merged), [glic, linux: Add support for getrandom vDSO](https://sourceware.org/git/?p=glibc.git;a=commit;h=461cab1de747f3842f27a5d24977d78d561d45f9) + | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:---:|:----:|:---:|:----:|:---------:|:----:| | 2022/07/29 | Jason A. Donenfeld | [random: implement getrandom() in vDSO](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=ad8070cb1b4bd40aa19a5e3f7c24d7f62c71b382) | TODO | v1 ☐☑✓ v6.11-rc1 | [LORE](https://lore.kernel.org/all/20220729145525.1729066-1-Jason@zx2c4.com)
*-*-*-*-*-*-*-*
[2023/01/01 LORE v14,0/7](https://lore.kernel.org/all/20230101162910.710293-1-Jason@zx2c4.com) | @@ -608,6 +620,8 @@ bperf 试图通过允许多个 "周期" 或 "指令" 的 perf_event (在不同 ### 13.2.1 PGO ------- +[LLVM Instrumentation 程序探测](https://zhuanlan.zhihu.com/p/514796016) + 2020 年 GNU Tools Cauldron 大会受到了疫情影响取消, 在 8 月份的 LPC2020 会议上, 组委会特别增加了一个 GNU Tools 分会场来讨论工具链相关的议题. 来自微软的 Ian Bearman 展示了他的团队使用 Profile Guided Optimization(PGO) 和 Link-time Optimization(LTO) 来优化 Linux 内核取得的一些成果. 参见 [Exploring Profile Guided Optimization of the Linux Kernel](https://lpc.events/event/7/contributions/771/), [微软技术团队：用这种方式编译 Linux，可直接改善系统性能](https://zhuanlan.zhihu.com/p/235032245)[Profile-guided optimization for the kernel](https://lwn.net/Articles/830300) @@ -626,6 +640,8 @@ bperf 试图通过允许多个 "周期" 或 "指令" 的 perf_event (在不同 [Experiences in Profile-Guided Operating System Kernel Optimization](https://yaoguopku.github.io/papers/Yuan-ApSys-14.pdf) +Canonical 的工程师一直在探索利用 Profile Guided Optimizations(PGO) 来提升系统的性能, 并得到了 5-7% 的性能提升. 对于 Linux 发行版来说, Profile Guided Optimizations 和相关的基于配置文件的优化在总体上要困难得多, 因为需要代表实际使用的准确配置文件. 如果没有准确的配置文件，PGO 和相关技术(如 AutoFDO)对编译器做出智能优化决策的用处就不大. Sergio Durigan Junior 最近一直在探索 RISC-V 的 PGO 优化, 同时使用 QEMU 仿真并从 AMD Ryzen 硬件运行. Sergio 探索了使用 QEMU 在 RISC-V-on-x86_64 仿真环境中构建 OpenSSL、GDB、Emacs 和 Python 的 PGO 性能优势, 因为这就是 RISC-V 包的 Ubuntu 构建场的设置方式. 基于 perf 的配置文件生成基于 QEMU 流程本身, 并了解使用 PGO 可以带来什么样的构建速度改进. 参见 phoronix 报道 [phoronix， 2024/11/18, Ubuntu Praises 5~7% PGO Compiler Optimization Performance Benefits](https://www.phoronix.com/news/Ubuntu-PGO-Praises-Performance) + | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:---:|:----:|:---:|:----:|:---------:|:----:| | 2024/07/28 | Rong Xu | [Add AutoFDO and Propeller support for Clang build](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=dbefa1f31a91670c9e7dac9b559625336206466f) | 此补丁系列旨在将 AutoFDO 和 Propeller 支持集成到 Linux 内核中. AutoFDO 是一种按配置优化技术, 它利用硬件采样来增强二进制性能. 与基于仪器的 FDO(iFDO) 不同, AutoFDO 提供了用户友好且简单的申请流程. 虽然 iFDO 通常会产生卓越的配置文件质量和性能, 但作者的研究结果表明, AutoFDO 实现了显着的有效性, 使性能接近基准应用的 iHDO.
Propeller 是一种配置文件引导的链路后优化器, 可提高使用 LLVM 编译的大规模应用程序的性能. 它通过基于额外一轮运行时配置文件重新链接二进制文件来运行, 从而实现在编译时无法实现的精确优化. 与 AutoFDO 类似, Propeller 也利用硬件采样来收集配置文件并应用链接后优化, 以提高基准测试的性能, 使其高于 AutoFDO.
数据表明m使用 AutoFDO 和 Propeller 后，性能有了显著提高，在微基准测试中提高了 10%，在大型仓库规模基准测试中提高了 5%。这为将它们作为上游内核中的受支持功能提供了强有力的理由. [phoronix, 2024/07/30, Google's AutoFDO & Propeller For The Linux Kernel Helps With Up To 5~10% Faster Performance](https://www.phoronix.com/news/AutoFDO-Propeller-Kernel), [phoronix, 2024/10/03, Google Updates Patches For AutoFDO+Propeller Optimized Linux Kernel](https://www.phoronix.com/news/Linux-AutoFDO-Prop-v2), [phoronix, 2024/11/30, Clang AutoFDO & Propeller Optimization Support Sent In For Linux 6.13: 5~10% More Performance](https://www.phoronix.com/news/Kbuild-Clang-AutoFDO-Linux-6.13) 和 [phoronix, 2024/11/30, Clang AutoFDO + Propeller Optimization Support Merged For Linux 6.13](https://www.phoronix.com/news/AutoFDO-Propeller-Linux-6.13). | v1 ☐☑✓ v6.13-rc1 | [2024/07/28, LORE v1,0/6](https://lore.kernel.org/all/20240728203001.2551083-1-xur@google.com)
*-*-*-*-*-*-*-*
[2024/10/02, LORE v2,0/6](https://lore.kernel.org/all/20241002233409.2857999-1-xur@google.com)
*-*-*-*-*-*-*-*
[2024/10/10, LORE v3,0/6](https://lore.kernel.org/all/20241010192400.451187-1-xur@google.com) | @@ -850,11 +866,12 @@ Mesa CI 开始使用 Mold 作为其 x86_64 和 AArch64 上的默认链接器, [Mold 2.0 High Speed Linker Released: Moves From AGPL To MIT License](https://www.phoronix.com/news/Mold-2.0-Linker). +[Mold 2.35 Released With Big Endian ARM64 Support](https://www.phoronix.com/news/Mold-2.35-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). - Rui Ueyama 是 Mold 高性能链接器的首席开发人员, 以前是 LLVM LLD 链接器的负责人, 他在开发 Mold 链接器时, 发现 Linux 内核的某些区域成为链接器的瓶颈, 于是在社区写了一篇详细的邮件 [Wislist for Linux from the mold linker's POV](https://lore.kernel.org/lkml/CACKH++baPUaoQQhL0+qcc_DzX7kGcmAOizgfaCQ8gG=oBKDDYw@mail.gmail.com), 重点介绍了 Linux 内核中观察到的一些性能瓶颈. 并希望社区各领域开发人员可以进行优化. 参见 phoronix 报道 [phoronix, 2024/11/28, Linux Kernel Performance Bottlenecks Spotted By Mold Developer](https://www.phoronix.com/news/Linux-Kernel-Bottlenecks-Mold). ### 13.8.2 dynamic linking @@ -1098,6 +1115,14 @@ User Events 于 [5.18-rc1](https://kernelnewbies.org/Linux_5.18#User_events) 合 | 2023/03/28 | Beau Belgrave | [tracing/user_events: Remote write ABI](https://lore.kernel.org/all/20230328235219.203-1-beaub@linux.microsoft.com) | 之前的 API 使用起来并不方便, 因此进行了重构. 参见 [User trace events, one year later](https://lwn.net/Articles/927595). 当前正在使用一个需要 mmap() 的共享页面. 删除共享页面实现并移动到用户注册地址实现. 在这个新模型中, 从用户程序注册事件期间指定了 3 个新值. 第一个是启用或禁用事件时要更新的地址. 第二个是要设置 / 清除的位, 以反映正在启用的事件. 第三个是指定地址的值的大小. 这允许在用户程序中使用本地 32/64 位值来支持内核跟踪程序和用户跟踪程序. 例如, 当事件启用时, 为内核跟踪程序设置第 31 位允许用户跟踪程序使用其他位作为引用计数或其他标志. 内核端原子地更新位, 用户程序也需要原子地更新这些值. 用户提供的地址必须在自然边界上对齐, 这允许单页检查, 并防止奇怪的行为, 如跨 2 页而不是单页的启用值. 当遇到页面错误时, 它们将通过工作队列异步完成. 如果页面错误返回, 则再次尝试写更新. 如果页面不能故障进入, 那么我们将登录并等待下一次事件被启用 / 禁用. 这是为了防止由于不良用户进程在注册地址后取消映射或更改保护值而导致的无限循环. | v10 ☐☑✓ | [LORE v10,0/12](https://lore.kernel.org/all/20230328235219.203-1-beaub@linux.microsoft.com)| +## 14.9 function graph +------- + + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:----:|:---------:|:----:| +| 2024/09/14 | Donglin Peng | [function_graph: Support recording and printing the function return address](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=21e92806d39c68af2accd1fb238c2daecfcf9fbd) | [公众号-dolinux-巧用function graph的trace输出格式](https://mp.weixin.qq.com/s/QHDl9GazamSpaQWkx5mV7w). | v2 ☐☑✓ v6.13-rc1 | [LORE](https://lore.kernel.org/all/20240915032912.1118397-1-dolinux.peng@gmail.com) | + # 15 kptr_restrict ------- diff --git a/study/kernel/00-DESCRIPTION/LOCKING.md b/study/kernel/00-DESCRIPTION/LOCKING.md index 7e80eb9..61fe360 100644 --- a/study/kernel/00-DESCRIPTION/LOCKING.md +++ b/study/kernel/00-DESCRIPTION/LOCKING.md @@ -320,6 +320,9 @@ Google 的 Joel Fernandes 等发现 RCU 并没有很好的节能, 在 Android [内核工匠-futex问答](https://blog.csdn.net/feelabclihu/article/details/127020166) +[性能打磨手记：记一段 Futex 机制的内核优化之旅](https://kernel.meizu.com/2024/03/15/Futex机制的内核优化) + +[FUTEX_SWAP补丁分析-SwitchTo 如何大幅度提升切换性能？](https://blog.csdn.net/21cnbao/article/details/118980971) | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:---:|:----:|:---:|:----:|:---------:|:----:| @@ -485,7 +488,7 @@ Proxy Execution 是一种通用形式的优先级继承机制, 它旨在解决 | 2022/10/03 | Connor O'Brien | [Reviving the Proxy Execution Series](https://lore.kernel.org/all/20221003214501.2050087-1-connoro@google.com) | TODO | v1 ☐☑✓ | [2022/10/03 LORE v1,0/11](https://lore.kernel.org/all/20221003214501.2050087-1-connoro@google.com)
*-*-*-*-*-*-*-*
[2023/03/20 LORE v2,0/12](https://lore.kernel.org/all/20230320233720.3488453-1-jstultz@google.com)
*-*-*-*-*-*-*-*
[2023/04/11 LORE v3,00/14](https://lore.kernel.org/all/20230411042511.1606592-1-jstultz@google.com) | | 2023/06/01 | John Stultz | [Generalized Priority Inheritance via Proxy Execution](https://lore.kernel.org/all/20230601055846.2349566-1-jstultz@google.com) | TODO | v3 ☐☑✓ | [LORE v4,0/13](https://lore.kernel.org/all/20230601055846.2349566-1-jstultz@google.com) | | 2023/12/19 | John Stultz | [Proxy Execution: A generalized form of Priority Inheritance v7](https://lore.kernel.org/all/20231220001856.3710363-1-jstultz@google.com) | TODO | v7 ☐☑✓ | [2023/12/19, LORE v7,0/23](https://lore.kernel.org/all/20231220001856.3710363-1-jstultz@google.com) | -| 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#google_vignette). | 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/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) | @@ -540,6 +543,8 @@ SCaLE 21x 上 Alison Chaiken 关于 WorkQueue 的讨论, 参见 [Diagnosing work | 2024/02/16 | Tejun Heo | [workqueue: Implement disable/enable_work()](https://lore.kernel.org/all/20240216180559.208276-1-tj@kernel.org) | [Linux 6.9 Sees Invasive & Significant Changes To Workqueues](https://www.phoronix.com/news/Linux-6.9-Workqueue). | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240216180559.208276-1-tj@kernel.org) | | 2024/01/29 | Tejun Heo | [workqueue: Introduce struct wq_node_nr_active](https://lore.kernel.org/all/Zbfq8egWUfYgkOsa@slm.duckdns.org) | TODO | v4 ☐☑✓ | [LORE v4,0/10](https://lore.kernel.org/all/Zbfq8egWUfYgkOsa@slm.duckdns.org) | | 2024/06/22 | Leonardo Bras | [Introduce QPW for per-cpu operations](https://lore.kernel.org/all/20240622035815.569665-1-leobras@redhat.com) | 提出一种 QPW(Queue PerCPU Work) 作为在 PREEMPT_RT 内核中处理每个 CPU 操作的更好方法, 以取代工作队列 WorkQueue.
目前使用 PREEMPT_RT=y, local_locks() 变成了每个 CPU 的自旋锁. 在这种情况下, 不需要在远程 CPU 上调度工作, 尝试获取远程 CPU 的每个 CPU 自旋锁并在本地运行所需的工作应该是安全的, 主要的代价是在每个局部函数中执行 un/locking.
引入 queue_percpu_work_on() API, 在非 PREEMPT_RT 内核上的现有 local_locks 和 WorkQueue 的行为进行包装. 但对于 PREEMPT_RT 的内核, QPW 将锁定 CPU 的每个 CPU 结构并在本地执行工作. 参见 [Red Hat Proposes Queue PerCPU Work "QPW" For Better Handling Per-CPU Work On RT Linux](https://www.phoronix.com/news/Linux-Queue-Per-CPU-Work-QPW). | v1 ☐☑✓ | [LORE v1,0/4](https://lore.kernel.org/all/20240622035815.569665-1-leobras@redhat.com) | +| 2024/09/23 | Chen Ridong | [add dedicated wq for cgroup bpf and adjust WQ_MAX_ACTIVE](https://lore.kernel.org/all/20240923114352.4001560-1-chenridong@huaweicloud.com) | 这组补丁的主要目的是为 cgroup BPF 销毁操作添加一个专用的工作队列(workqueue), 并调整 WQ_MAX_ACTIVE 的默认值从 512 增加到 2048. 该补丁集旨在解决现有系统工作队列(system_wq)在处理大量 cgroup BPF 销毁请求时可能被饱和的问题, 并通过引入专用工作队列来提高性能和可靠性. 此外, 还增加了 WQ_MAX_ACTIVE 的默认值以支持更多的并发任务. 参见 [phoronix, 2024/11/18, Linux 6.13 Quadrupling Workqueue Concurrency Limit](https://www.phoronix.com/news/Linux-6.13-Workqueues) | v5 ☐☑✓ | [LORE v5,0/3](https://lore.kernel.org/all/20240923114352.4001560-1-chenridong@huaweicloud.com)
*-*-*-*-*-*-*-*
[部分合入 COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=581434654e01ec79dd02c21448ac84e2ce2d1a64) | +| 2024/12/11 | Frederic Weisbecker | [kthread: Introduce preferred affinity v6](https://lore.kernel.org/all/20241211154035.75565-1-frederic@kernel.org) | 该补丁集的主要目的是引入内核线程(kthread)的首选亲和性(preferred affinity)机制, 以增强内核线程调度的灵活性和性能. 当前, 内核线程的 CPU 亲和性是静态设定的, 无法动态调整. 这限制了某些应用场景中对 CPU 资源的有效利用. 通过引入首选亲和性机制, 允许内核线程在启动时指定一个或多个偏好的 CPU, 并且当这些 CPU 空闲时优先运行在这些 CPU 上. 如果偏好的 CPU 不可用, 则内核线程仍可以在其他 CPU 上运行, 但会尽量回到首选的 CPU 上继续执行. 通过引入首选亲和性机制, 可以显著改善特定应用场景下的调度效率和资源利用率, 尤其是在 NUMA 系统或多核处理器上. 例如, 在网络处理、实时任务调度等场景中, 可以让关键任务尽可能地运行在其偏好的 CPU 上, 从而减少跨节点访问内存带来的延迟, 提高整体系统性能. | v6 ☐☑✓ | [LORE v6,0/19](https://lore.kernel.org/all/20241211154035.75565-1-frederic@kernel.org) | # 13 Windows NT Synchronization Primitive Driver diff --git a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md index a67f652..84531c0 100644 --- a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md +++ b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md @@ -752,20 +752,12 @@ MTE 实现了锁和密钥访问内存. 这样在内存访问期间, 可以在内 | 2023/07/14 | GONG, Ruiqi | [Randomized slab caches for kmalloc()](https://lore.kernel.org/all/20230714064422.3305234-1-gongruiqi@huaweicloud.com) | TODO | v5 ☐☑✓ | [LORE](https://lore.kernel.org/all/20230714064422.3305234-1-gongruiqi@huaweicloud.com) | | 2024/03/05 | Kees Cook | [slab: Introduce dedicated bucket allocator](https://lore.kernel.org/all/20240305100933.it.923-kees@kernel.org) | [Hardening the kernel against heap-spraying attacks](https://lwn.net/Articles/965837) | v2 ☐☑✓ | [LORE v2,0/9](https://lore.kernel.org/all/20240305100933.it.923-kees@kernel.org) | -### 1.8.7 GCS(Guarded Control Stack) -------- - -| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | -|:---:|:----:|:---:|:----:|:---------:|:----:| -| 2024/10/01 | Mark Brown | [arm64/gcs: Provide support for GCS in userspace](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=bb9ae1a66c85eeb626864efd812c62026e126ec0) | [phoronix, 2024/10/08, Arm's Guarded Control Stack "GCS" Support Looks Like It Will Be Ready For Linux 6.13](https://www.phoronix.com/news/Arm-GCS-Prep-Linux-6.13) | v13 ☐☑✓ | [LORE v13,0/40](https://lore.kernel.org/all/20241001-arm64-gcs-v13-0-222b78d87eee@kernel.org) | - - ### 1.8.8 Lightweight Guard Pages ------- | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:---:|:----:|:---:|:----:|:---------:|:----:| -| 2024/10/17 | Lorenzo Stoakes | [implement lightweight guard pages](https://lore.kernel.org/all/cover.1729196871.git.lorenzo.stoakes@oracle.com) | 用户空间库函数(如分配器和线程实现)通常需要内存区域充当'保护页'——当访问这些映射时, 会导致向访问进程发送致命信号.
当前实现这些的方法是通过 PROT_NONE mmap() 映射, 它提供了所需的语义, 但每个此类区域都会产生 VMA 的开销. 对于大量进程和线程, 这可能会迅速增加并导致严重的内存损失. 它还具有阻止可能被允许的合并的额外问题. 这个系列实现了不同的方法 - Vlasimil Babka 提出的方法, 将它们放在映射所需范围的页表中, 而不是不是在 VMA 层定位保护页. 对此代码的原型版本的早期测试表明，内存映射调用的速度提高了 5 倍(结合使用 process_madvise())，并且在完全空闲的 Android 系统和未优化代码上减少了 13% 的 VMA.
1. 引入 PTE 标记： 使用 PTE 标记(PTE markers)来实现守护页机制, 而不是传统的 PROT_NONE 映射. 添加了一个新的 PTE 标记 PTE_MARKER_GUARD, 用于表示守护页.
2. 扩展通用页面遍历机制: 扩展通用页面遍历机制, 允许安装 PTE(页面表项), 但仅限于内存管理逻辑, 以防止滥用.
3. 确保内存管理操作不会移除守护页标记: 确保 MADV_DONTNEED 等操作不会移除守护页标记. 确保 fork 操作不会移除守护页标记, 除非指定了 VM_WIPEONFORK. [phoronix, 2024/10/20, Lightweight Guard Pages For Linux Showing 5x Speed-Up For Memory Mapping Invocations](https://www.phoronix.com/news/Linux-Lightweight-Guard-Pages) | v1 ☐☑✓ | [LORE v1,0/4](https://lore.kernel.org/all/cover.1729196871.git.lorenzo.stoakes@oracle.com) | +| 2024/10/17 | Lorenzo Stoakes | [implement lightweight guard pages](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=876320d71f515407b81eb08a1d019f19f34907d7) | 用户空间库函数(如分配器和线程实现)通常需要内存区域充当'保护页'——当访问这些映射时, 会导致向访问进程发送致命信号.
当前实现这些的方法是通过 PROT_NONE mmap() 映射, 它提供了所需的语义, 但每个此类区域都会产生 VMA 的开销. 对于大量进程和线程, 这可能会迅速增加并导致严重的内存损失. 它还具有阻止可能被允许的合并的额外问题. 这个系列实现了不同的方法 - Vlasimil Babka 提出的方法, 将它们放在映射所需范围的页表中, 而不是不是在 VMA 层定位保护页. 对此代码的原型版本的早期测试表明，内存映射调用的速度提高了 5 倍(结合使用 process_madvise())，并且在完全空闲的 Android 系统和未优化代码上减少了 13% 的 VMA.
1. 引入 PTE 标记： 使用 PTE 标记(PTE markers)来实现守护页机制, 而不是传统的 PROT_NONE 映射. 添加了一个新的 PTE 标记 PTE_MARKER_GUARD, 用于表示守护页.
2. 扩展通用页面遍历机制: 扩展通用页面遍历机制, 允许安装 PTE(页面表项), 但仅限于内存管理逻辑, 以防止滥用.
3. 确保内存管理操作不会移除守护页标记: 确保 MADV_DONTNEED 等操作不会移除守护页标记. 确保 fork 操作不会移除守护页标记, 除非指定了 VM_WIPEONFORK. [phoronix, 2024/10/20, Lightweight Guard Pages For Linux Showing 5x Speed-Up For Memory Mapping Invocations](https://www.phoronix.com/news/Linux-Lightweight-Guard-Pages) 和 [phoronix, 2024/11/20, Linux 6.13 "MM" Patches Bring Some Enticing Performance Optimizations](https://www.phoronix.com/news/Linux-6.13-MM-Patches) | v1 ☐☑✓ v6.13-rc1 | [LORE v1,0/4](https://lore.kernel.org/all/cover.1729196871.git.lorenzo.stoakes@oracle.com) | @@ -1883,6 +1875,7 @@ SLUB 在解决了上述的问题之上, 提供与 SLAB 完全一样的接口, | 2021/10/12 | Vlastimil Babka | [mm, slub: change percpu partial accounting from objects to pages](https://patchwork.kernel.org/project/linux-mm/patch/20211012134651.11258-1-vbabka@suse.cz) | NA | v3 ☑ 2.6.22-rc1 | [PatchWork v6](https://lore.kernel.org/patchwork/patch/262225) | | 2022/11/21 | Vlastimil Babka | [Introduce CONFIG_SLUB_TINY and deprecate SLOB](https://patchwork.kernel.org/project/linux-mm/cover/20221121171202.22080-1-vbabka@suse.cz/)| 697743 | v1 ☐☑ | [LORE v1,0/12](https://lore.kernel.org/r/20221121171202.22080-1-vbabka@suse.cz) | | 2023/08/08 | Vlastimil Babka | [SLUB percpu array caches and maple tree nodes](https://patchwork.kernel.org/project/linux-mm/cover/20230808095342.12637-7-vbabka@suse.cz/) | 773975 | v1 ☐☑ | [LORE v1,0/5](https://lore.kernel.org/r/20230808095342.12637-7-vbabka@suse.cz)
*-*-*-*-*-*-*-*
[LORE v2,0/7](https://lore.kernel.org/r/20230810163627.6206-9-vbabka@suse.cz) | +| 2024/10/01 | Christoph Lameter | [SLUB: Add support for per object memory policies](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=f7c80fad6c2b64cf73361772dbd30493879e85f4) | 该补丁的主要目的是在 ARM 架构上增强 SLUB(Small Low-overhead User-friendly Buffer)分配器对 NUMA(Non-Uniform Memory Access)内存策略的支持, 特别是在基于嵌入式设备的新 NUMA 互连技术下, 确保每个 slab 对象能够根据内存策略进行精确放置.
SLAB 和 SLUB 内存策略差异: 旧的 SLAB 分配器支持按每个分配基础设置内存策略. SLUB 分配器则是在页框/大页级别应用内存策略, 以避免在关键代码路径中检查内存策略, 从而提高 kmalloc 等函数的性能.
2. 现有问题: 在 Intel、AMD 和 PowerPC 上, 由于互连技术成熟, 即使小对象未最优放置, 也能通过智能缓存最小化延迟. 然而, 在 ARM 架构中, 新的 NUMA 互连技术更多基于嵌入式设备, 标准构建模块/网格上的远程内容缓存效果不佳. 因此, ARM 架构需要每个 slab 对象根据内存策略单独放置.
引入新的内核参数 slab_strict_numa: 当设置此参数时, 激活一个静态分支，使分配器热路径评估当前的内存分配策略. 每个对象将被正确放置, 尽管这会增加额外的处理开销, 但 SLUB 不再依赖页面分配器在大页级别应用内存策略.
在 Ampere Altra 2P 系统(ARM Neoverse N1 处理器)上运行 memcached 时, 由于准确放置了小内核对象, 性能提升了 3.6%. 参见 [phoronix, 2024/11/27, Linux 6.13 Adding "slab_strict_numa" SLAB Option For Helping ARM Performance](https://www.phoronix.com/news/Linux-6.13-SLAB-Strict-NUMA) | v3 ☐☑✓ v6.13-rc1 | [LORE](https://lore.kernel.org/all/20241001-strict_numa-v3-1-ee31405056ee@gentwo.org) | @@ -2402,11 +2395,11 @@ v2.6.24 实现迁移类型 MIGRATETYPE 的时候, 在从伙伴系统中内存分 **2.6.35(2010 年 8 月发布)** -2.2 中讲到页面迁移类型(聚类), 它把相当可移动性的页面聚集在一起: 可移动的在一起, 可回收的在一起, 不可移动的也在一起. ** 它作为去碎片化的基础.** 然后, 利用 ** 成块回收 **, 在回收时, 把可回收的一起回收, 把可移动的一起移动, 从而能空出大量连续物理页面. 这个 ** 作为去碎片化的策略.** +2.2 中讲到页面迁移类型(聚类), 它把相当可移动性的页面聚集在一起: 可移动的在一起, 可回收的在一起, 不可移动的也在一起. **它作为去碎片化的基础**. 然后, 利用 **成块回收**, 在回收时, 把可回收的一起回收, 把可移动的一起移动, 从而能空出大量连续物理页面. 这个 **作为去碎片化的策略**. -2.6.35 里, Mel Gorman 又实现了一种新的 ** 去碎片化的策略 ** 叫[** 内存紧致化或者内存规整 **](https://lwn.net/Articles/368869). 不同于 ** 成块回收 ** 回收相临页面, ** 内存规整 ** 则是更彻底, 它在回收页面时被触发, 它会在一个 zone 里扫描, 把已分配的页记录下来, 然后把所有这些页移动到 zone 的一端, 这样这把一个可能已经七零八落的 zone 给紧致化成一段完全未分配的区间和一段已经分配的区间, 这样就又腾出大块连续的物理页面了. +2.6.35 里, Mel Gorman 又实现了一种新的 ** 去碎片化的策略 ** 叫[ 内存紧致化或者内存规整](https://lwn.net/Articles/368869). 不同于 ** 成块回收 ** 回收相临页面, ** 内存规整 ** 则是更彻底, 它在回收页面时被触发, 它会在一个 zone 里扫描, 把已分配的页记录下来, 然后把所有这些页移动到 zone 的一端, 这样这把一个可能已经七零八落的 zone 给紧致化成一段完全未分配的区间和一段已经分配的区间, 这样就又腾出大块连续的物理页面了. 它后来替代了成块回收, 使得后者在 3.5 中被移除. @@ -3451,7 +3444,7 @@ LRU 组织形式的变更和 LRU lock 的变更是无法割裂开的. 每次 LRU 3. 对于匿名页, 当第一次被读入时, 将置于 active list 链表尾(对匿名页的优待是因为替换它出去要写入交换设备, 不能直接丢弃, 代价更大); 如果它被再次访问, 就把它提升到 active list 链表头. -4. 在需要换页时, MM 会从 active 链表尾开始扫描, 把足够量页面降级到 inactive 链表头, 同样, 默认文件缓存页会受到优待(用户可通过 **_swappiness_** 这个用户接口设置权重). +4. 在需要换页时, MM 会从 active 链表尾开始扫描, 把足够量页面降级到 inactive 链表头, 同样, 默认文件缓存页会受到优待(用户可通过 `_swappiness_` 这个用户接口设置权重). 如上, 上述两个链表按照使用的热度构成了四个层级: @@ -3563,6 +3556,7 @@ hakavlad 提供了简单的 shell 脚本和 oneshot systemd 服务 [hakavlad/mg- | 2023/01/18 | T.J. Alumbaugh | [mm: multi-gen LRU: improve](https://patchwork.kernel.org/project/linux-mm/cover/20230118001827.1040870-1-talumbau@google.com/) | 712983 | v1 ☐☑ | [LORE v1,0/7](https://lore.kernel.org/r/20230118001827.1040870-1-talumbau@google.com) | | 2023/02/13 | Yu Zhao | [[mm-unstable,v1] mm: multi-gen LRU: avoid futile retries](https://patchwork.kernel.org/project/linux-mm/patch/20230213075322.1416966-1-yuzhao@google.com/) | 721184 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20230213075322.1416966-1-yuzhao@google.com) | | 2023/07/25 | Kairui Song | [Refault distance checking for MGLRU](https://patchwork.kernel.org/project/linux-mm/cover/20230725185733.43929-1-ryncsn@gmail.com/) | 769444 | v1 ☐☑ | [LORE v1,0/4](https://lore.kernel.org/r/20230725185733.43929-1-ryncsn@gmail.com) | +| 2024/12/05 | Yu Zhao | [mm/mglru: performance optimizations](https://lore.kernel.org/all/20241206003126.1338283-1-yuzhao@google.com) | 这组补丁的主要目的是优化内存管理子系统中的多代 LRU(MGLRU)算法, 以提升某些特定测试用例的性能表现.
该补丁集旨在通过改进 MGLRU 的工作集清理、去激活、老化反馈、类型选择、重试检测和工作集保护机制, 来优化内存管理的行为, 特别是在客户端和服务器设备上的 Android、FIO、memcached、多个虚拟机(VMs)和 MongoDB 等负载场景中表现出色. 参见 [phoronix, 2024/12/06, MGLRU Sees New Performance Optimizations For Linux](https://www.phoronix.com/news/MGLRU-New-Performance-Opts) | v2 ☐☑✓ | [LORE v2,0/6](https://lore.kernel.org/all/20241206003126.1338283-1-yuzhao@google.com) | ### 4.2.8 工作集大小的探测(Better LRU list balancing) @@ -5207,6 +5201,7 @@ hugetlb 的使用依赖于用户主动预留并使用, 适用于用户明确需 | 2020/09/28 | Zi Yan | [1GB PUD THP support on x86_64](https://lkml.org/lkml/2020/9/28/973) | X86_64 支持 PUD 级别 (1G) 的匿名大页 | RFC,v2 ☐ | [2020/09/02 PatchWork RFC,00/16](https://patchwork.kernel.org/project/linux-mm/cover/20200902180628.4052244-1-zi.yan@sent.com)
*-*-*-*-*-*-*-*
[2020/09/28 PatchWork v2 00/30](https://patchwork.kernel.org/project/linux-mm/cover/20200928175428.4110504-1-zi.yan@sent.com) | | 2021/05/10 | Muchun Song | [Overhaul multi-page lookups for THP](https://lore.kernel.org/patchwork/patch/1337675) | 提升大量页面查找时的效率 | v4 ☑ [5.12-rc1](https://kernelnewbies.org/Linux_5.12#Memory_management) | [PatchWork RFC](https://patchwork.kernel.org/project/linux-mm/cover/20201112212641.27837-1-willy@infradead.org) | | 2021/05/10 | Ankur Arora | [Use uncached stores while clearing huge pages](https://patchwork.kernel.org/project/linux-mm/cover/20211020170305.376118-1-ankur.a.arora@oracle.com) | 本系列增加了对大页的非缓存页面清除的支持. [清除大页内存](https://patchwork.kernel.org/project/linux-mm/patch/20211020170305.376118-11-ankur.a.arora@oracle.com)时, 使用基于 [MOVNTI 指令](https://www.felixcloutier.com/x86/movnti) 的 [uncached clear page 接口](https://patchwork.kernel.org/project/linux-mm/patch/20211020170305.376118-4-ankur.a.arora@oracle.com).
其动机是加快大型预分配虚拟机的创建, 并支持巨大的页面.
支持非缓存页面清除有两种帮助:
1. 对于小于 LLC 大小的数据块, 未缓存的存储通常比缓存的存储慢, 而对于较大的数据块, 则更快. 2. 避免用无用的零替换潜在有用的缓存行.
性能测试: 虚拟机创建 (对于预分配 2MB 后台页面的虚拟机) 在运行时有了显著的改进. | v2 ☐ | [PatchWork v2,00/14](https://patchwork.kernel.org/project/linux-mm/cover/20211020170305.376118-1-ankur.a.arora@oracle.com) | +| 2024/10/24 | Vlastimil Babka | [mm, mmap: limit THP aligment of anonymous mappings to PMD-aligned sizes](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d4148aeab412432bf928f311eca8a2ba52bb05df) | 该补丁的主要目的是修正由于匿名映射(anonymous mappings)在特定条件下对齐到透明大页(THP, Transparent Huge Pages)边界而导致的性能退化问题. 通过这些改动, 匿名映射的行为变得更加合理, 特别是在处理不同大小的内存分配时, 能够在保持性能的同时避免不必要的性能损失. 补丁背景: 自从提交 efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries") 引入后, 当使用 mmap() 映射匿名内存且没有指定具体的地址提示时, 如果映射大小至少为 PMD_SIZE, 则会将其对齐到 PMD 边界, 以使它可以受益于 THP 支持.
发现的问题: 然而, 这一改动导致某些工作负载显著退化. 例如, 在 SPEC 基准测试中, cactusBSSN 测试用例出现了高达 600% 的性能下降. 原因是该基准测试创建了许多 4632KB 大小的映射, 这些映射原本可以合并成一个大的 THP 区域, 但现在却被分割成了多个区域, 每个区域都对齐到 PMD 边界, 并且之间有空隙. 这种布局导致了 TLB 或缓存别名问题, 从而影响了内存访问模式, 最终导致性能下降.
为了修复这个问题, 同时仍然尝试从 THP 友好的匿名映射对齐中获益, 补丁添加了一个条件: 只有当映射的大小是 PMD size 的倍数时, 才会将匿名映射对齐到 PMD 边界. 对于许多非标准大小的映射(如 cactusBSSN 创建的那些), 它们将不再被强制对齐, 并且会自然地合并在一起, 而不是分散成多个带有间隙的区域.
性能改进: 通过这项修改, 那些创建了许多非 PMD 对齐大小映射的工作负载(如 cactusBSSN 和 darktable)应该能够恢复其预期的性能表现, 避免因不必要的内存对齐而引起的性能损失.这个补丁的主要工作是: 修复了由于匿名映射对齐到 THP 边界而导致的性能退化问题. 通过限制 THP 对齐的应用场景, 确保只有在映射大小为 PMD size 的倍数时才进行对齐, 从而避免不必要的内存布局碎片化. 恢复了受影响工作负载(如 cactusBSSN 和 darktable)的预期性能表现. 参见 phoronix 报道 [phoronix, 2024/11/08, Intel Spots A 3888.9% Performance Improvement In The Linux Kernel From One Line Of Code](https://www.phoronix.com/news/Intel-Linux-3888.9-Performance) | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20241024151228.101841-2-vbabka@suse.cz) | THP 虽然实现了, 但是依旧存在着不少问题. 在 LSFMM 2015 进行了讨论, 参见 [Improving huge page handling](https://lwn.net/Articles/636162) @@ -5701,6 +5696,9 @@ mcpage 有成本. 除了 THP 没有带来 TLB 的好处之外, 与 4K 基本页 [Google Making Progress On 16KB Page Size For Android](https://www.phoronix.com/news/Android-16KB-Page-Size-Progress) +[phoronix, 2024/12/05, Linux Patches Would Allow RISC-V To Use A 64K Page Size](https://www.phoronix.com/news/Linux-RFC-v2-64K-Risc-V-PS) + + # 8 进程虚拟地址空间(VMA) ------- @@ -7560,6 +7558,13 @@ CSDN 宣传博客 [内存不超过 5M, datop 在识别冷热内存及跨 numa | 2021/12/09 | Xin Hao | [`#85` Introduce Data Access MONitor (DAMON)](https://gitee.com/anolis/cloud-kernel/pulls/85/commits) | 支持 NUMA 的能力, 同时改进了 tracepoint, 方便 dattop 解析. | [openanolis, devel-5.10, PR #85](https://gitee.com/anolis/cloud-kernel/pulls/85/commits) | [GITEE,PR](https://gitee.com/anolis/cloud-kernel/pulls/85/commits) | +## 13.7 Page Detective +------- + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:----:|:---------:|:----:| +| 2024/11/16 | Pasha Tatashin | [Page Detective](https://lore.kernel.org/all/20241116175922.3265872-1-pasha.tatashin@soleen.com) | 参见 [Google Engineer Proposes "Page Detective" As New Kernel Debugging Tool](https://www.phoronix.com/news/Linux-Page-Detective-RFC) | v1 ☐☑✓ | [LORE v1,0/6](https://lore.kernel.org/all/20241116175922.3265872-1-pasha.tatashin@soleen.com) | + # 14 杂项 ------- @@ -7801,13 +7806,25 @@ OS 判断如果是在用户态触发这个硬件内存错误时, 处理方式是 ### 14.7.4 Shadow stacks ------- +#### 14.7.4.1 Shadow stacks +------- + | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:-----:|:----:|:----:|:----:|:------------:|:----:| | 2022/01/30 | Edgecombe, Rick P | [Shadow stacks for userspace](https://patchwork.kernel.org/project/linux-mm/cover/20220130211838.8382-1-rick.p.edgecombe@intel.com) | [User-space shadow stacks (maybe) for 6.4](https://lwn.net/Articles/926649), [Intel Shadow Stack Finally Merged For Linux 6.6](https://www.phoronix.com/news/Intel-Shadow-Stack-Linux-6.6). | v1 ☐☑ | [PatchWork v1,0/35](https://lore.kernel.org/r/20220130211838.8382-1-rick.p.edgecombe@intel.com)
*-*-*-*-*-*-*-*
[LORE v2,0/39](https://lore.kernel.org/r/20220929222936.14584-1-rick.p.edgecombe@intel.com)
*-*-*-*-*-*-*-*
[LORE v3,0/37](https://lore.kernel.org/r/20221104223604.29615-1-rick.p.edgecombe@intel.com)
*-*-*-*-*-*-*-*
[LORE v4,0/39](https://lore.kernel.org/r/20221203003606.6838-1-rick.p.edgecombe@intel.com)
*-*-*-*-*-*-*-*
[LORE v5,0/39](https://lore.kernel.org/r/20230119212317.8324-1-rick.p.edgecombe@intel.com)
*-*-*-*-*-*-*-*
[LORE v6,0/41](https://lore.kernel.org/r/20230218211433.26859-1-rick.p.edgecombe@intel.com)
*-*-*-*-*-*-*-*
[LORE v7,0/41](https://lore.kernel.org/r/20230227222957.24501-1-rick.p.edgecombe@intel.com)
*-*-*-*-*-*-*-*
[LORE v8,0/40](https://lore.kernel.org/r/20230319001535.23210-1-rick.p.edgecombe@intel.com) | -| 2023/07/16 | Mark Brown | [arm64/gcs: Provide support for GCS in userspace](https://lore.kernel.org/all/20230716-arm64-gcs-v1-0-bf567f93bba6@kernel.org) | 影子堆栈的 64 位 Arm 实现称为"受保护的控制堆栈"("guarded control stack/GCS), 参见 LWN 报道 [Shadow stacks for 64-bit Arm systems](https://lwn.net/Articles/940403). | v1 ☐☑✓ | [LORE v1,0/35](https://lore.kernel.org/all/20230716-arm64-gcs-v1-0-bf567f93bba6@kernel.org)
*-*-*-*-*-*-*-*
[LORE v3,0/36](https://lore.kernel.org/all/20230731-arm64-gcs-v3-0-cddf9f980d98@kernel.org)
*-*-*-*-*-*-*-*
[LORE v4,0/36](https://lore.kernel.org/r/20230807-arm64-gcs-v4-0-68cfa37f9069@kernel.org) | | 2024/03/15 | H.J. Lu | [x86/shstk: Enable shadow stack for x32](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2883f01ec37dd8668e7222dfdb5980c86fdfe277) | [Linux Enabling Shadow Stack Support For x32](https://www.phoronix.com/news/Linux-x32-Shadow-Stacks) | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240315140433.1966543-1-hjl.tools@gmail.com) | +#### 14.7.4.2 GCS(Guarded Control Stack) +------- + +GCC 通过 "-mbranch-protection=gcs" 选项, 支持生成 Arm Guarded Control Stack 兼容的代码. 此分支保护选项与早期 Arm 处理器也可以设置为 Branch Target Identification "BTI" 的选项相同. 参见 phoronix 报道 [phoronix, 2024/11/15, GCC 15 Adds Option For Arm Guarded Control Stack "GCS" Code Generation](https://www.phoronix.com/news/GCC-15-Arm-GCS-Code-Generation). + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:---:|:----:|:---:|:----:|:---------:|:----:| +| 2024/10/01 | Mark Brown | [arm64/gcs: Provide support for GCS in userspace](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=bb9ae1a66c85eeb626864efd812c62026e126ec0) | 影子堆栈的 64 位 Arm 实现称为"受保护的控制堆栈"("guarded control stack/GCS), 参见 LWN 报道 [Shadow stacks for 64-bit Arm systems](https://lwn.net/Articles/940403) 和 [phoronix, 2024/10/08, Arm's Guarded Control Stack "GCS" Support Looks Like It Will Be Ready For Linux 6.13](https://www.phoronix.com/news/Arm-GCS-Prep-Linux-6.13) | v13 ☐☑✓ | [LORE v1,0/35](https://lore.kernel.org/all/20230716-arm64-gcs-v1-0-bf567f93bba6@kernel.org)
*-*-*-*-*-*-*-*
[LORE v3,0/36](https://lore.kernel.org/all/20230731-arm64-gcs-v3-0-cddf9f980d98@kernel.org)
*-*-*-*-*-*-*-*
[LORE v4,0/36](https://lore.kernel.org/r/20230807-arm64-gcs-v4-0-68cfa37f9069@kernel.org)
*-*-*-*-*-*-*-*
[LORE v13,0/40](https://lore.kernel.org/all/20241001-arm64-gcs-v13-0-222b78d87eee@kernel.org) | + + ## 14.8 页面迁移 ------- diff --git a/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md b/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md index 4c72052..cdb6827 100644 --- a/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md +++ b/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md @@ -112,6 +112,9 @@ | 6.9 | [The first half of the 6.9 merge window](https://lwn.net/Articles/965141), [Kernel prepatch 6.9-rc1](https://lwn.net/Articles/966525), [The rest of the 6.9 merge window](https://lwn.net/Articles/965541) | NA | NA | | 6.10 | [The first half of the 6.10 merge window](https://lwn.net/Articles/973687)
*-*-*-*-*-*-*-*
[The rest of the 6.10 merge window](https://lwn.net/Articles/974869)
*-*-*-*-*-*-*-*
[Kernel prepatch 6.10-rc2](https://lwn.net/Articles/976498). | NA | [Linux 6.10-rc1 Kernel Released With Many New Features](https://www.phoronix.com/news/Linux-6.10-rc1), [Linux 6.10-rc5 Released With This Kernel Cycle Looking Good So Far](https://www.phoronix.com/news/Linux-6.10-rc5) | | 6.11 | [The first half of the 6.11 merge window](https://lwn.net/Articles/982034), [LWN, 2024/07/28, Kernel prepatch 6.11-rc1](https://lwn.net/Articles/983760), [LWN, 2024/07/29, The rest of the 6.11 merge window](https://lwn.net/Articles/982605), [LWN, 2024/08/11, Kernel prepatch 6.11-rc3](https://lwn.net/Articles/985233) | NA | NA | +| 6.12 | NA | NA | [phoronix, 2024/11/17, Linux 6.12 Released With Real-Time Capabilities, Sched_Ext, More AMD RDNA4 & More](https://www.phoronix.com/news/Linux-6.12-Released) | +| 6.13 | NA | MA | [phoronix, 2024/12/06, Linux 6.13 Features: AutoFDO+Propeller Optimizations, Many AMD Additions & SDUC + NVMe 2.1 Support](https://www.phoronix.com/review/linux-613-features) | + 年终盘点 diff --git a/study/kernel/00-DESCRIPTION/SCHEDULER.md b/study/kernel/00-DESCRIPTION/SCHEDULER.md index 1982a02..9c9a214 100644 --- a/study/kernel/00-DESCRIPTION/SCHEDULER.md +++ b/study/kernel/00-DESCRIPTION/SCHEDULER.md @@ -4248,6 +4248,7 @@ y = (1 - \frac{pct^{2}}{10000^{2}} \times x^{2}) \times llc\_weight | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:---:|:----------:|:----:| | 2017/01/19 | Peter Zijlstra | [sched/core: Optimize pick_next_task() for idle_sched_class](https://lkml.org/lkml/2017/1/19/687) | NA | | v1 ☑ 4.11-rc1 | [PatchWork](https://lore.kernel.org/patchwork/patch/755854), [LKML](https://lkml.org/lkml/2017/1/19/687), [commit](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49ee576809d837442624ac18804b07943267cd57) | +| 2024/11/08 | Rik van Riel | [x86,tlb: context switch optimizations](https://lore.kernel.org/all/20241109003727.3958374-1-riel@surriel.com) | 这组补丁的主要目的是优化 x86 架构下的 TLB(Translation Lookaside Buffer)上下文切换过程, 以减少 CPU 时间消耗并提高系统性能. 该补丁集旨在解决 switch_mm_irqs_off 函数中的两个热点问题, 这些问题在某些工作负载下会占用大量的 CPU 时间, 尤其是在 Web 服务器等高并发场景中. 具体来说, 这两个热点分别是:
1. 频繁的 mm_cpumask 操作: 在上下文切换时，频繁地原子清除和设置当前 CPU 在 prev 和 next 的 mm_cpumask 中, 导致了大量的缓存行争用.
2. 不必要的 cpumask_test_cpu 检查: 在 switch_mm_irqs_off 函数的 prev == next 分支中有一个 WARN_ON_ONCE 调用, 其中包含了一个 cpumask_test_cpu 检查, 这个检查从未触发过, 但仍然占用了大量时间. 参见 [phoronix, 2024/11/09, New Patches Aim To Optimize Context Switching With Two Improvements](https://www.phoronix.com/news/Linux-2024-Optimize-Ctx-Switch) | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20241109003727.3958374-1-riel@surriel.com) | # 7 调度与节能 @@ -4511,7 +4512,7 @@ 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) | TODO | v1 ☐☑✓ | [LORE v1,0/5](https://lore.kernel.org/all/20240830130309.2141697-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) | @@ -4553,7 +4554,9 @@ c27c56105dca ANDROID: Add find_best_target to minimise energy calculation overhe ##### 7.2.3.6.1 sched domain overutilized ------- -EAS 按照能效进行选核等操作也是有一定开销的, 因此调度器 更倾向于在系统负载不高仍有余力时使用 EAS 按照能效进行调度, 而当系统负载已经很高时, 不再使用 EAS, 而是回退到原生 SMP NICE 的情况. 这就需要一种标记系统是否过载的方法. +EAS 按照能效进行选核等操作也是有一定开销的, 因此调度器 更倾向于在系统负载不高仍有余力时使用 EAS 按照能效进行调度, 而当系统负载已经很高时, 不再使用 EAS, 而是回退到原生 SMP NICE 的情况(也被称为 性能和传播模式 performance and spread mode). + +这就需要一种标记系统是否过载的方法. [commit 2802bf3cd936 ("sched/fair: Add over-utilization/tipping point indicator")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2802bf3cd936fe2c8033a696d375a4d9d3974de4) 引入了 root-domain 的 overutilized, 当一个 CPU 的利用率 (util_avg) 超过一定阈值 (默认为 80%) 的时, 就认为当前 CPU 过载了, 同时也会认为整个系统也是过载的. @@ -4564,7 +4567,7 @@ EAS 按照能效进行选核等操作也是有一定开销的, 因此调度器 EAS 原生的 overutilized 机制非常保守, 一旦发现某个 CPU 出现了 cpu_overutilized(), 则会直接反映到 root_domain 上, 即任务整个系统都是过载的, 从而禁用 EAS, 并使能 CFS Load Balancing. 这样本来一些 CPU 或者 sched_domain 本身能从能效感知策略中获益的, 现在无法再获得任何收益. -因此不少厂商都会基于主线的策略进行优化. Linaro 为 ANDROID/AOSP 贡献了 [ANDROID: sched: Per-Sched-domain over utilization](https://git.codelinaro.org/clo/la/kernel/msm-4.14/-/commit/0dca2fc973a98de742d6df894135f04cacabb6b5) 机制, 将原来保守的 root_domain->overutilized 引入到 SD_SHARE_PKG_RESOURCES 级别. 从而一个 CPU 过载时不再会直接影响整个系统 (root_domain), 而是只影响单个 sched_domain. +因此不少厂商都会基于主线的策略进行优化. Linaro 为 ANDROID/AOSP 贡献了 [ANDROID: sched: Per-Sched-domain over utilization](https://git.codelinaro.org/clo/la/kernel/msm-4.14/-/commit/0dca2fc973a98de742d6df894135f04cacabb6b5) 机制, 将原来保守的 root_domain->overutilized 引入到 SD_SHARE_PKG_RESOURCES 级别. 从而一个 CPU 过载时不再会直接影响整个系统 (root_domain), 而是只影响单个 sched_domain. 这种策略合入 AOSP, 并被被 ANDROID 厂商普遍回合或者采纳. 1. 当 CPU 过载时, CPU 所在调度域将被标记为过载. @@ -4578,6 +4581,8 @@ EAS 原生的 overutilized 机制非常保守, 一旦发现某个 CPU 出现了 | 2021/05/04 | Thara Gopinath | [ANDROID: sched: Per-Sched-domain over utilization](https://github.com/aosp-mirror/kernel_common/commit/addef37808728c719d8c095a75bcf81befdacdaf) | per sched-domain 级别的 utilization. | v3 ☐☑✓ | [LORE](https://github.com/aosp-mirror/kernel_common/commit/addef37808728c719d8c095a75bcf81befdacdaf) | | 2024/03/07 | Shrikanth Hegde | [sched/fair: Limit access to overutilized](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log?id=4d0a63e5b841c759c9a306aff158420421ef016f) | 当在大型系统 (240 核心, SMT8) 上运行 ISV 工作负载时, 从性能配置文件中可以观察到, newidle_balance 和 enque_task_fair 正在消耗更多的周期. 通过 perf 热点分析, 大部分时间都花在了访问 root domain 的 rd->overutilized 字段上. 通过对 `stress-ng --wait` 进行一些更改, 模拟了类似的 perf 配置文件. newidle_balance 和 enqueue_task_fair 的消耗都接近 5-7%. EAS(能量感知调度器)引入 overutilized 机制是为了决策是否进行负载平衡. rd->overutilized 同时被多个 CPU 访问会导致缓存失效. 非 EAS 平台不需要更新 rd->overutilized. 另外由于 rd->overutilized 和 rd->overload 在同一 Cache Line, 因此也存在伪共享的可能. 补丁 1 [sched/fair: Add EAS checks before updating overutilized](https://lore.kernel.org/all/20240307085725.444486-2-sshegde@linux.ibm.com) 这有助于减少上述问题. 带上这个补丁后, ISV 工作负载中的问题也得到了解决, 吞吐量也得到了提高. 补丁 2 和 3 代码重构, 使用 helper 函数 is_rd_overutilized() , 而不再直接访问 rd->overutilized 字段. 因为观察到的大多数模式都是 eas && !overutilzed. | v6 ☐☑✓ v6.10-rc1 | [LORE](https://lore.kernel.org/all/20240326152616.380999-1-sshegde@linux.ibm.com)
*-*-*-*-*-*-*-*
[LORE v6,0/3](https://lore.kernel.org/all/20240307085725.444486-1-sshegde@linux.ibm.com) | | 2024/03/25 | Shrikanth Hegde | [sched: Minor changes for rd->overload access](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log?id=4d0a63e5b841c759c9a306aff158420421ef016f) | 当在大型系统中运行工作负载时, 可以观察到对 rd->overload 的访问需要时间.
1. 补丁 1, 更新之前最好检查一下值, 因为值更改的频率较低.
补丁 2, 只有在必要时才会进行修补程序更新. CPU 总线流量有所减少. 工作负载性能没有显著提高. Qais 建议最好使用 helper 函数来访问 rd->overload. | v3 ☐☑✓ v6.10-rc1 | [LORE v3,0/2](https://lore.kernel.org/all/20240325054505.201995-1-sshegde@linux.ibm.com) | +| 2024/08/30 | Vincent Guittot | [4/5, sched/fair: Use EAS also when overutilized](https://lore.kernel.org/all/20240830130309.2141697-5-vincent.guittot@linaro.org/) | overutilized 时继续使用 feec() 寻找节能的 CPU 从而防止破坏任务的 power packing. 在测试中发现当工作队列的任务醒来进行短暂的后台工作(如vmstat更新)时, 系统可能会在短时间内过度使用, 因此 [sched/fair: Rework EAS to handle more cases](https://lore.kernel.org/all/20240830130309.2141697-1-vincent.guittot@linaro.org) 中 Patch 4, 尝试修改系统 overutilized, 也要继续通过 feec() 寻找能效最优的 CPU. 当 feec() 实在找不到合适的 CPU 时, 才回退到调度器的默认性能和传播模式(performance and spread mode). | v1 ☐☑✓ | [LORE v1,0/5](https://lore.kernel.org/all/20240830130309.2141697-1-vincent.guittot@linaro.org) | + ##### 7.2.3.6.2 sched group energy @@ -4864,7 +4869,7 @@ v5.13-rc1 [commit 4aed8aa41524 ("sched/fair: Introduce a CPU capacity comparison * Migrate 'misfit' tasks on asymmetric capacity systems -在 AMP(asymmetric CPU capacity systems) 系统上, 负载密集的任务最终可能会使用不适合其计算需求的 CPU. 在这种情况下, "不匹配的" 任务应该及时迁移到具有更高 capacity 的 CPU 上, 以确保更好的吞吐量. v4.20 [sched/fair: Migrate'misfit'tasks on asymmetric capacity systems](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=9c63e84db29bcf584040931ad97c2edd11e35f6c) 来使得负载均衡支持 Misfit Task. +在 AMP(asymmetric CPU capacity systems) 系统上, 负载密集的任务最终可能会使用不适合其计算需求的 CPU. 在这种情况下, "不匹配的" 任务应该及时迁移到具有更高 capacity 的 CPU 上, 以确保更好的吞吐量. v4.20 [sched/fair: Migrate'misfit'tasks on asymmetric capacity systems](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=9c63e84db29bcf584040931ad97c2edd11e35f6c) 来使得**负载均衡支持 Misfit Task**. 引入了 [group_misfit_task](https://elixir.bootlin.com/linux/v4.20/source/kernel/sched/fair.c#L7868) 表示这种场景. Misfit Balancing 只在每 CPU 容量较低的源组和计算容量较高的目标组之间有意义. 否则, 将忽略 misfit. group_misfit_task 具有 [最低优先级](https://elixir.bootlin.com/linux/v4.20/source/kernel/sched/fair.c#L6964), 因此任何由于 [过载造成的不平衡 group_overloaded](https://elixir.bootlin.com/linux/v4.20/source/kernel/sched/fair.c#L6966) 都将首先处理. Misfit 的不平衡值记录在 [rq->misfit_task_load](https://elixir.bootlin.com/linux/v4.20/source/kernel/sched/fair.c#L3724), 并在 update_sd_lb_stats() -=> update_sg_lb_stats() 时更新到 [struct sg_lb_stats 的 group_misfit_task_load](https://elixir.bootlin.com/linux/v4.20/source/kernel/sched/fair.c#L7947) 中. @@ -4890,6 +4895,8 @@ Misfit Task 对调度器 ** 负载均衡 ** 做了如下改造, 参见 [commit c | 2023/02/01 | Vincent Guittot | [unlink misfit task from cpu overutilized](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log?id=a2e90611b9f425adbbfcdaa5b5e49958ddf6f61b) | uclamp_min 造成的任务 misfit 并不意味着 cpu overutilized, 因为这仅仅是 uclamp_min 的约束, 具有小 util_avg 的任务可能不适合所在高 capacity 的 cpu. 允许 `task_fits_cpu()/asym_fits_cpu()/cpu_overutilized() -=> util_filts_cpu()` 返回 -1 来反映 CPU 不适合指定任务只是因为 uclamp_min, 所以我们可以使用这个状态来采取额外的操作, 以选择与 uclamp_min 匹配的最佳 CPU. 当 util_filts_cpu() 返回 -1 时, 不再认为 CPU 是 overutilized 的, 因此 select_idle_capacity() 和 find_energy_efficient_cpu() 将继续寻找一种可能的性能更好的 CPU, 它用 capacity_orig_of() - thermal_load_avg 代替容量反转检测来检测容量反转. | v5 ☐☑✓ | [LORE v5,0/2](https://lore.kernel.org/all/20230201143628.270912-1-vincent.guittot@linaro.org) | | 2023/12/09 | Qais Yousef | [sched: Generalize misfit load balance](https://lore.kernel.org/all/20231209011759.398021-1-qyousef@layalina.io) | 当前的 misfit 实现被认为是 MISFIT_PERF, 这意味着我们需要将任务移动到更好的 CPU 以满足其性能要求. 对于被 UCLAMP_MAX 所限制的(大)任务, 引入 MISFIT_POWER, 需要找到一个更好的位置来控制它对 POWER 的影响. 并且当我们有了一个 API 来注释延迟敏感任务, 预计将需要 MISFIT_LATENCY 负载均衡来帮助处理超额订阅情况, 以帮助更好地分配延迟敏感任务, 以帮助减少其唤醒延迟. | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20231209011759.398021-1-qyousef@layalina.io) | + + * Misfit vs NO_HZ [sched/fair: Kick nohz balance if rq->misfit_task_load](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5fbdfae5221a5208ed8e7653fc1c4b31de420f74) @@ -4910,6 +4917,20 @@ Misfit Task 对调度器 ** 负载均衡 ** 做了如下改造, 参见 [commit c | 2023/08/20 | Qais Yousef | [sched/fair: Check a task has a fitting cpu when updating misfit](https://lore.kernel.org/all/20230820203429.568884-1-qyousef@layalina.io) | 如果一个 MISFIT 的任务与 affinity 并不是所有 CPU, 我们需要验证 CPU 是否适合它, 否则, 负载均衡器将不断触发, 导致 balance_interval 不必要地增加, 最终导致真正的不平衡需要很长时间才能解决, 因为这是不可能的不平衡状况. 在 Android 系统上这种现象非常普遍, 因为后台任务通常被限制在小核上. 同样, 如果我们不能适应最大的核心, 那么触发不匹配是毫无意义的, 因为这是我们在这个系统上所能得到的最好的结果. 为了加快搜索速度, 不要调用 task_fits_cpu(), 它会为同一任务重复调用 uclamp_eff_value(), 改为调用 util_filts_cpu(). 只有当我们看到一个 CPU 的 CAPACITY LEVEL 高于通过的 cpu_of(rq) 时, 才能这样做. | v1 ☐☑✓ | [2023/08/20, LORE](https://lore.kernel.org/all/20230820203429.568884-1-qyousef@layalina.io)
*-*-*-*-*-*-*-*
[2023/12/12, LORE v2](https://lore.kernel.org/lkml/20231212154056.626978-1-qyousef@layalina.io) | | 2024/03/24 | Qais Yousef | [sched: Don't trigger misfit if affinity is restricted](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=58eeb2d79b542c678c46e245dba6b66936368a99) | 讨论了如何处理热插拔操作, 以消除容量水平并导致不必要的 LB 再次触发. 我选择现在不处理它, 早期版本 [sched/fair: Check a task has a fitting cpu when updating misfit](https://lore.kernel.org/lkml/20230820203429.568884-1-qyousef@layalina.io) 中提供了一个有效的补丁, 但是作者并不像继续推动这种实现. 补丁 4 将确保 balance_interval 和 nr_failed 不会因不必要的 MISFIT 而不必要地进行增长. 6.9 合并窗口后, 动态能量模型系列将被合并, 这可能导致 CPU 的容量在运行时发生变化. 这意味着发布后续补丁来处理这种情况, 以确保在 EM 更新后最大允许容量是正确的. | v8 ☐☑✓ v6.10-rc1 | [2023/12/31, LORE v3,0/2](https://lore.kernel.org/lkml/20231231175218.510721-1-qyousef@layalina.io)
*-*-*-*-*-*-*-*
[2024/01/05, LORE v4,0/2](https://lore.kernel.org/lkml/20240105222014.1025040-1-qyousef@layalina.io)
*-*-*-*-*-*-*-*
[2024/02/05, LORE v5,0/2](https://lore.kernel.org/lkml/20240205021123.2225933-1-qyousef@layalina.io)[2024/02/20, LORE v6,0/4](https://lore.kernel.org/lkml/20240220225622.2626569-1-qyousef@layalina.io)
*-*-*-*-*-*-*-*
[2024/03/24, LORE v8,0/4](https://lore.kernel.org/all/20240324004552.999936-1-qyousef@layalina.io) | +* Proactive Misfit Migration + +EAS 基于唤醒事件来有效地将任务放置在系统上, 同样 MISFIT PLACEMENT/MIGRATION 借助 EAS 的框架, 也是完成依赖于 WAKUP 和 Load Balance (进行 MISFIT 任务的迁移), 因此对一些时延敏感型任务来说总是不及时. + +在某些情况下, 任务将不再有唤醒事件或唤醒速度太慢, 而 Load Balance 的时延明显更高于 WAKEUP. 对于这种情况, 我们可以利用被放回就绪队列中的任务来检查是否应该将其迁移到另一个 CPU 上. 当任务是 CPU 上唯一运行的任务时, 可以在 TICK 中将检查任务是否卡在该 CPU 上(MISFIT), 是否应迁移到另一个 CPU 上. + +当然唤醒事件仍然是迁移任务的主要方式, 但我们现以通过检查任务的利用率是否大于最大可用计算容量(最大 CPU 容量或 uclamp 最大设置)来检测任务在 CPU 上 MISFIT 的情况. + + +1. QCOM 在自己 MSM 的内核(早期 EAS 版本, EAS 合入主线后, 高通使用 vendor-hook) 中引入了 [check_for_migration()](https://git.codelinaro.org/clo/la/kernel/msm-4.19/-/commit/7ebdf76d85e1050f06b52db476d0ef34bd060cbd) 在 TICK 中直接检查任务如果已经 MISFIT 了, 则直接进行强制迁移. 这个优化也被国内很多 ANDROID 厂商沿用. + +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 上. #### 7.2.4.4 Capacity Aware Sched Class @@ -5725,7 +5746,7 @@ CONFIG_SCHED_CORE_CTL 的方案, 不光通过 do_isolation_work_cpu_stop() 支 |:---:|:----:|:---:|:----:|:---------:|:----:| | 2023/11/07 | Ankur Arora | [Make the kernel preemptible](https://lore.kernel.org/all/20231107215742.363031-1-ankur.a.arora@oracle.com) | [New Set Of 86 Patches Overhaul The Linux Kernel's Preemption Model](https://www.phoronix.com/news/Overhaul-Linux-Preemptible-RFC) | v1 ☐☑✓ | [LORE v1,0/86](https://lore.kernel.org/all/20231107215742.363031-1-ankur.a.arora@oracle.com) | | 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)功能. 懒惰抢占是一种优化技术, 旨在减少不必要的上下文切换, 提高系统的性能和响应时间. 引入 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). | v1 ☐☑✓ | [LORE v1,0/5](https://lore.kernel.org/all/20241007074609.447006177@infradead.org) | +| 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) | @@ -6421,6 +6442,7 @@ $deadline_{se} = vruntime_{se} + slice \times \frac{weight_0}{weight_{se}}$ | 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) | 滞后计算仅与可运行的任务相关; 休眠很久的任务实际上并没有错过它的虚拟运行时间(因为它没有), 所以它不会累积巨大的滞后值. 但是, EEVDF 调度器实现的时候, 在任务进入睡眠状态时会保留任务的当前滞后值, 并在任务唤醒时从该值开始. 因此, 如果一个任务在它进入睡眠状态之前已经超出了它的分配范围, 那么当它醒来时, 它将为此付出代价. @@ -6902,6 +6924,9 @@ BPF 钩子 (它已经成功地用于各种内核子系统) 为外部代码 (安 #### 11.2.2.1 sched_ext: Facebook 的尝试 ------- +##### 11.2.2.1.1 引入 sched_ext +------- + [当 BPF 邂逅 CPU 调度器](https://www.ebpf.top/post/cfs_scheduler_bpf) [foxhoundsk 的博客 Scheduler BPF](https://hackmd.io/@foxhoundsk/sched-bpf) @@ -6952,16 +6977,29 @@ 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) | -| 2024/10/18 | Andrea Righi | [sched_ext: improve WAKE_SYNC behavior for default idle CPU selection](https://lore.kernel.org/all/20241018094033.160188-1-andrea.righi@linux.dev) | 这个补丁的主要目的是改进 sched_ext 模块在处理 WAKE_SYNC 唤醒行为时的默认空闲 CPU 选择逻辑. 在 sched_ext 模块的默认空闲 CPU 选择逻辑中, 当处理 WF_SYNC 唤醒时, 通常会尝试将任务迁移到唤醒者所在的 CPU. 这是因为唤醒者通常会在唤醒任务后释放 CPU. 然而，有时保留任务在其原来的 CPU 上可能更有利, 尤其是在唤醒者所在的 CPU 与其原 CPU 之间有缓存亲缘关系的情况下. | v1 ☐☑✓ | [2024/10/18, LORE](https://lore.kernel.org/all/20241018094033.160188-1-andrea.righi@linux.dev)
*-*-*-*-*-*-*-*
[2024/10/18, LORE v2](https://lore.kernel.org/all/20241018180951.599625-1-andrea.righi@linux.dev) | -| 2024/10/23 | Andrea Righi | [sched_ext: Introduce LLC awareness to the default idle selection policy](https://lore.kernel.org/all/20241022234718.63258-1-arighi@nvidia.com) | 主要目的是为 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). | v3 ☐☑✓ | [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://lore.kernel.org/all/20241027174953.49655-1-arighi@nvidia.com) | 为 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). | v3 ☐☑✓ | [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://lore.kernel.org/all/20241108000136.184909-1-arighi@nvidia.com) | 该补丁的主要目的是在 LLC(Last Level Cache)和 NUMA 域完全重叠时, 避免启用冗余的优化, 以提高调度器扩展策略的效率. 当 LLC 和 NUMA 域完全重叠时, 同时启用这两个域的优化是多余的, 因为这会导致两次在相同的域内搜索空闲 CPU. 此外, 如果所有在线 CPU 都在一个单一的 LLC 域内, 那么 LLC 优化也是不必要的. 因此, 此补丁通过检测重叠的域, 并仅在必要时启用拓扑优化来解决这个问题. | v3 ☐☑✓ | [LORE](https://lore.kernel.org/all/20241108000136.184909-1-arighi@nvidia.com) | + + +##### 11.2.2.1.2 WAKE/LLC/NUMA 感知与支持 +------- + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:----:|:---------:|:----:| +| 2024/10/18 | Andrea Righi | [sched_ext: improve WAKE_SYNC behavior for default idle CPU selection](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=21b8964826c4da3cc8ed89308f8838cfd221429f) | 这个补丁的主要目的是改进 sched_ext 模块在处理 WAKE_SYNC 唤醒行为时的默认空闲 CPU 选择逻辑. 在 sched_ext 模块的默认空闲 CPU 选择逻辑中, 当处理 WF_SYNC 唤醒时, 通常会尝试将任务迁移到唤醒者所在的 CPU. 这是因为唤醒者通常会在唤醒任务后释放 CPU. 然而，有时保留任务在其原来的 CPU 上可能更有利, 尤其是在唤醒者所在的 CPU 与其原 CPU 之间有缓存亲缘关系的情况下. | v1 ☐☑✓ v6.13-rc1 | [2024/10/18, LORE](https://lore.kernel.org/all/20241018094033.160188-1-andrea.righi@linux.dev)
*-*-*-*-*-*-*-*
[2024/10/18, LORE v2](https://lore.kernel.org/all/20241018180951.599625-1-andrea.righi@linux.dev) | +| 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) | + +##### 11.2.2.1.3 sched_ext per-node 数据拆分 +------- + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:----:|:---------:|:----:| | 2024/11/26 | Andrea Righi | [sched_ext: split global idle cpumask into per-NUMA cpumasks](https://lore.kernel.org/all/20241126101259.52077-1-arighi@nvidia.com) | 这组补丁的主要目的是将全局的空闲 CPU 掩码(idle cpumask)拆分为每个 NUMA 节点的空闲 CPU 掩码, 以提高在大型 NUMA 系统上的可扩展性和性能.
1. 引入新的节点掩码遍历宏 `for_each_node_mask_from` 和 `for_each_node_state_from`, 以便更方便地遍历特定节点状态的节点.
2. 将全局的空闲 CPU 掩码拆分为每个 NUMA 节点的空闲 CPU 掩码, 以提高在大型 NUMA 系统上的可扩展性和性能.
通过这些改动, 系统在处理大量任务和高竞争情况下的性能和稳定性得到了显著提升, 特别是对于 NUMA 系统, 减少了跨节点的缓存行访问, 提高了系统的整体效率. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20241126101259.52077-1-arighi@nvidia.com) | | 2024/07/09 | Tejun Heo | [sched_ext: Implement DSQ iterator](https://lore.kernel.org/all/20240709004041.1111039-1-tj@kernel.org) | 目的是为调度器扩展 (sched_ext) 实现 DSQ(Distribution Skilled Queue) 迭代器. DSQs 在消费路径中是不透明的, eBPF 调度器没有办法知道哪些任务正在被考虑以及哪个任务被选中. 这个补丁集合添加了 BPF DSQ 迭代器，以便 BPF 调度器在使用 DSQs. | v5 ☐☑✓ | [LORE v5](https://lore.kernel.org/all/20240709004041.1111039-1-tj@kernel.org) | | 2024/07/10 | Tejun Heo | [sched_ext: Allow SCX_DSQ_LOCAL_ON for direct dispatches](https://lore.kernel.org/all/20240711011434.1421572-1-tj@kernel.org) | 主要目的是改进调度器扩展 (sched_ext) 以允许在直接调度时使用 SCX_DSQ_LOCAL_ON. 在 ops.dispatch()中, 可以使用 SCX_DSQ_LOCAL_ON 将任务调度到任何 CPU 的本地 DSQ(分布技能队列). 但在 ops.select_cpu() 和 ops.enqueue() 中的直接调度不允许这样做. 这是因为将任务调度到远程 CPU 的本地 DSQ 需要同时锁定任务的当前 rq 和新 rq, 而这种双重锁定不能直接从 ops.enqueue()完成. 这个 API 的缺失迫使调度器使用不直接或非最优的工作方式, 例如在这些情况下跳过直接调度. | v2 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240709212137.1199269-1-tj@kernel.org)
*-*-*-*-*-*-*-*
[LORE](https://lore.kernel.org/all/20240711011434.1421572-1-tj@kernel.org) | | 2024/08/30 | Tejun Heo | [sched_ext: Implement `scx_bpf_dispatch[_vtime]_from_dsq()`](https://lore.kernel.org/all/20240830110415.116090-1-tj@kernel.org) | 这个补丁集通过增加 `scx_bpf_dispatch[_vtime]_from_dsq()` 函数, 提升了 Linux 内核调度器在处理延迟队列 (Delayed Scheduling Queues, DSQ) 时的灵活性. 这项改动使得开发者能够在更广泛的上下文中灵活地控制任务的调度, 特别是在不持有 rq 锁的情况下. 这对于需要高度定制化调度策略的场景特别有用, 例如在使用 BPF 程序进行复杂调度逻辑的实现时, 允许将任务从一个队列移动到另一个队列以优化资源使用或响应特定的系统状态变化. 背景: 在当前的内核调度器中, 一旦一个任务被放入 DSQ(延迟调度队列), 可以对该任务执行的操作是有限的. 内置的本地和全局 DSQ 中的任务会被自动执行, 除了从队列中移除之外, 唯一能对用户 DSQ 中的任务进行的操作就是通过 scx_bpf_consume() 将第一个任务移到调度的本地 DSQ 中. 这种操作的局限性有时会造成不便, 并且已经收到了多个功能请求来改善这一情况. 这个补丁集实现了一个新的函数 `scx_bpf_dispatch[_vtime]_from_dsq()`, 可以在 DSQ 迭代期间调用, 并且可以将任务移动到任何 DSQ 中, 包括本地 DSQ、全局 DSQ 和用户 DSQ. 这个函数可以在 ops.dispatch() 以及其他不持有 rq 锁的 BPF 上下文中调用, 包括 BPF 定时器和系统调用 (SYSCALL) 程序. 主要功能点:
1. 增加调度灵活性: 新函数 `scx_bpf_dispatch[_vtime]_from_dsq()` 允许在 DSQ 迭代过程中将任务从一个 DSQ 移动到另一个 DSQ, 提供了更多的灵活性.
2. 适用范围广泛: 可以在多种 BPF 上下文中调用, 包括 BPF 定时器和系统调用程序, 增强了调度策略的可编程性和适应性.
3. 不持有 rq 锁: 这些函数可以在不持有 rq 锁的情况下调用, 这意味着它们可以在更广泛的上下文中使用, 提高了调度的灵活性. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240830110415.116090-1-tj@kernel.org) | -| 2024/09/24 | Tejun Heo | [sched_ext: Split %SCX_DSQ_GLOBAL per-node](https://lore.kernel.org/all/20240925000622.1972325-1-tj@kernel.org) | 这组补丁的主要目的是解决在 BPF 调度器的绕过模式 (bypass mode) 中出现的活锁(livelock)问题. 具体来说, 它将全局调度队列(DSQ)按 NUMA 节点拆分, 以减少跨节点的缓存行访问和调度, 从而提高系统的稳定性和性能. | v1 ☐☑✓ | [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://lore.kernel.org/all/ZyqSm4B4NuzuHEbp@slm.duckdns.org) | TODO | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/ZyqSm4B4NuzuHEbp@slm.duckdns.org) | +| 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) | @@ -7136,6 +7174,7 @@ YouTuBe 上 ASPLOS'23 关于 Plugsched 的介绍 [ASPLOS'23 - Session 7C - Effic |:----:|:----:|:---:|:----:|:---------:|:----:| | 2021/08/03 | Peter Oskolkov | [thread_info: use helpers to snapshot thread flags](https://lwn.net/Articles/722293) | 引入 read_ti_thread_flags() 规范对 thread_info 中 flag 的访问. 其中默认使用了 READ_ONCE. 防止开发者忘记了这样做. | v4 ☐ | [PatchWork v4,00/10](https://lore.kernel.org/patchwork/cover/1471548) | | 2023/03/30 | Mathieu Desnoyers | [sched: Introduce per-mm/cpu concurrency id state](https://lore.kernel.org/all/20230330230911.228720-1-mathieu.desnoyers@efficios.com) | 跟踪每个 mm/cpu 当前分配的 mm_cid, 而不是立即释放它们. 这消除了在多线程场景 (多个进程, 每个进程有多个线程) 中, 在属于不同内存空间的线程之间来回切换上下文时的大多数原子操作. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20230330230911.228720-1-mathieu.desnoyers@efficios.com) | +| 2024/10/09 | Mathieu Desnoyers | [sched: Improve cache locality of RSEQ concurrency IDs for intermittent workloads](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=7e019dcc470f27066c98697e43d930df8d54bd9c) | 参见 phoronix 报道 [phoronix, 2024/10/10, Restartable Sequences "RSEQ" Seeing Up To 16.7x Speedup With Newest Linux Patch](https://www.phoronix.com/news/RSEQ-Cache-Local-Speedup) | v2 ☐☑✓ v6.13-rc1 | [LORE v2,0/1](https://lore.kernel.org/all/20241009135007.2084357-1-mathieu.desnoyers@efficios.com) | diff --git a/study/kernel/00-DESCRIPTION/TEST.md b/study/kernel/00-DESCRIPTION/TEST.md index 10b059c..168a862 100644 --- a/study/kernel/00-DESCRIPTION/TEST.md +++ b/study/kernel/00-DESCRIPTION/TEST.md @@ -1,6 +1,4 @@ -AMD 异构内核设计和硬件反馈接口 (HFI) 为调度程序提供行为分类和动态更新的排名表, 供调度程序在为任务选择内核时使用. -线程在运行时被分类为枚举类. 目前, 该驱动程序支持 3 个类(0 到 2). 这些类表示可能受益于特殊调度行为的线程性能/功耗特征. 实时线程分类由操作系统使用, 用于通知计划程序应将线程放置在何处以获得最佳性能或能效. -线程分类有助于从排名表中选择 CPU, 该表从两个维度描述了每个分类的效率和性能排名. -排名表提供的排名数据是 0 到 255 之间的数字, 其中性能值越高表示性能能力越高, 效率越高表示效率越高. 所有 CPU 内核都分为不同的类 ID. 在每个类排名中, 核心可能具有不同的排名值. 因此, 从每个分类 ID 中选取允许调度程序选择最佳核心, 同时将线程分类到指定的工作负载类中. 内核排名表提供了 PCCT 子空间类型 4 共享内存, 其中包括内存基址和长度. +该补丁集的主要目的是改进 Energy Aware Scheduler (EAS) 的实现, 以更好地处理某些特定情况, 并修复已知的一些局限性, 特别是与 uclamp(利用率钳位)特性相关的场景.
现有问题: 当前的 EAS 实现存在一些局限性, 在引入 uclamp 等新特性后变得更加明显. 例如, 任务可能会堆积在同一个 CPU 上, 或者被卡在错误的 CPU 上无法迁移, 导致调度效率下降.
目标: 通过一系列改动, 确保 EAS 能够更灵活地应对不同类型的负载和调度需求, 特别是在异构多核处理器(如大小核架构)上优化性能和功耗.
具体改动:
1. 修正 CPU 过载分类问题: Patch 1 修复了当 CPU 被限制到较低的计算容量时, 可能被错误地分类为过载的问题. 这种错误分类可能导致周期性负载均衡器无法正确选择合适的 CPU 来放置任务. 通过修正这一问题, 可以避免不必要的负载均衡操作, 提高调度精度.
2. 创建新的 EM 接口; Patch 2 引入了一个新的能量模型(EM, Energy Model)接口, 该接口将在后续补丁中用于改进任务放置逻辑.
优化任务放置策略: Patch 3: 改进了任务放置策略, 使得在选择目标 CPU 时不仅考虑空闲容量最高的 CPU, 还会评估其他因素, 如运行的任务数量等. 这有助于找到真正最优的放置位置, 而不仅仅是基于单一标准.
进一步优化: Patch 4 和 Patch 5: 继续对 EAS 进行优化, 解决更多特定场景下的问题, 确保调度器能够在各种情况下都表现出色. + diff --git a/study/kernel/00-DESCRIPTION/TODO.md b/study/kernel/00-DESCRIPTION/TODO.md index 7bc674a..ed703f7 100644 --- a/study/kernel/00-DESCRIPTION/TODO.md +++ b/study/kernel/00-DESCRIPTION/TODO.md @@ -795,11 +795,6 @@ https://lore.kernel.org/all/20240830130309.2141697-1-vincent.guittot@linaro.org/ | 3 | -| 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) | TODO | v2 ☐☑✓ | [LORE](https://lore.kernel.org/all/20241031094822.30531-1-dtcccc@linux.alibaba.com) | - - - - -这组补丁的主要目的是让 x86 架构下的模块使用大页(large pages)来分配可执行内存(ROX pages), 以提高性能和减少 TLB(Translation Lookaside Buffer)的压力. 为 x86 架构引入对大页(通常是 2MB 或 4KB 的页面)的支持, 用于模块的文本段(代码段)分配. 修复与 kmemleak 交互的问题，并改进了与 CFI（Control Flow Integrity）配置的兼容性. -添加了一个新的 Kconfig 选项 ARCH_HAS_EXECMEM_ROX，确保架构实现 execmem_fill_trapping_insns() 回调，并且整个物理内存映射在直接映射中。 -具体改动 +即使系统 overutilized, 也要继续通过 feec() 寻找能效最优的 CPU. 否则, 回退到调度器的默认性能和传播模式(performance and spread mode). +当工作队列的工作人员醒来进行短暂的后台工作（如vmstat更新）时，系统可能会在短时间内过度使用。 +继续寻找节能的CPU将防止破坏任务的电源包装。 \ No newline at end of file diff --git a/study/kernel/00-DESCRIPTION/VIRT.md b/study/kernel/00-DESCRIPTION/VIRT.md index 77cbe68..24c6a3f 100644 --- a/study/kernel/00-DESCRIPTION/VIRT.md +++ b/study/kernel/00-DESCRIPTION/VIRT.md @@ -256,6 +256,14 @@ Anbox 使用 Linux 命名空间 (user, pid, uts, net, mount, ipc) 在容器中 | 2024/02/15 | Mihai Carabas | [Enable haltpoll for arm64](https://lore.kernel.org/all/1707982910-27680-1-git-send-email-mihai.carabas@oracle.com) | 这个补丁集允许在arm64上使用haltpoll-governer. 通过减少IPC延迟. openEuler 有类似的方案, 参见 [最佳实践](https://docs.openeuler.org/zh/docs/20.09/docs/Virtualization/最佳实践.html#halt-polling) 以及 [漫话Linux之“躺平”: IDLE 子系统](https://mp.weixin.qq.com/s?__biz=Mzg2OTc0ODAzMw==&mid=2247502695&idx=1&sn=60f6132f5f4f1d0f515cad74e83b3c63&source=41). | v4 ☐☑✓ | [LORE](https://lore.kernel.org/all/1707982910-27680-1-git-send-email-mihai.carabas@oracle.com) | +# 13 能效 +------- + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:---:|:----:|:---:|:----:|:---------:|:----:| +| 2023/03/30 | David Dai | [Improve VM DVFS and task placement behavior](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=4fd06a5358e0d888d1bf23d274971ea7d1f45aad) | 这组补丁的主要目的是改善虚拟机(VM)中的动态电压频率调节(DVFS)和任务调度行为, 使其表现接近于直接在主机上运行. 旨在解决虚拟机中工作负载的任务调度和 DVFS 行为不如直接在主机上运行时那么理想的问题. 具体来说, 当工作负载在虚拟机中运行时, 其任务调度和频率调节策略不如直接在主机上运行时有效, 导致性能和功耗表现不佳. 通过改进这些方面, 可以显著提升虚拟环境中工作负载的性能和能效.
1. 准确的负载跟踪: 让虚拟机内核能够更准确地跟踪主机 CPU 的架构类型、频率等信息, 以进行更精确的负载评估.
2. 共享 vCPU 运行队列利用率信息: 将虚拟 CPU(vCPU)的运行队列利用率信息共享给主机, 主机能够更好地了解虚拟机内部的工作负载情况, 并据此调整调度策略.
3. 频率调节优化(改进 DVFS 行为): 确保虚拟机中的工作负载能够享受到与主机相同级别的频率调节优化, 从而提高性能和能效.
参见 [LPC 2022 演讲 "CPUfreq/sched and VM guest workload problems](https://lpc.events/event/16/contributions/1195), 以及 phoronix 报道 [phoronix, 2024/11/24, Virtual CPUFreq Driver Coming With Linux 6.13 For Better Power/Performance Within VMs](https://www.phoronix.com/news/Linux-6.13-Virtual-CPUFreq) 和 [phoronix, 2023/03/31, Google Posts KVM-CPUFreq Driver To Dramatically Boost VM Performance, Power Efficiency](https://www.phoronix.com/news/KVM-CPUFreq-RFC-Patches). | v1 ☐☑✓ v6.13-rc1 | [2023/03/30, LORE v1,0/6](https://lore.kernel.org/all/20230330224348.1006691-1-davidai@google.com)
*-*-*-*-*-*-*-*
[2023/03/30, LORE v2,0/6](https://lore.kernel.org/all/20230331014356.1033759-1-davidai@google.com)
*-*-*-*-*-*-*-*
[2023/07/31, LORE v3,0/2](https://lore.kernel.org/all/20230731174613.4133167-1-davidai@google.com)
*-*-*-*-*-*-*-*
[2023/11/10, LORE v4,0/2](https://lore.kernel.org/all/20231111014933.1934562-1-davidai@google.com)
*-*-*-*-*-*-*-*
[2024/01/26, LORE v5,0/2](https://lore.kernel.org/all/20240127004321.1902477-1-davidai@google.com)
*-*-*-*-*-*-*-*
[2024/05/20, LORE V6,0/2](https://lore.kernel.org/all/20240521043102.2786284-1-davidai@google.com)
*-*-*-*-*-*-*-*
[2024/09/18, LORE v7,0/2](https://lore.kernel.org/all/20240919000837.1004642-1-davidai@google.com) | + +
* 本作品 / 博文 ([AderStep - 紫夜阑珊 - 青伶巷草 Copyright ©2013-2017](http://blog.csdn.net/gatieme) ), 由 [成坚 (gatieme)](http://blog.csdn.net/gatieme) 创作.