From 64571fc2da300b8d3140b546e6548117b8e09746 Mon Sep 17 00:00:00 2001 From: Cheng Jian Date: Mon, 14 Oct 2024 09:56:33 +0800 Subject: [PATCH] description/open_source: update phoronix vs LWN to date 20240915 --- study/kernel/00-DESCRIPTION/AI.md | 4 +- study/kernel/00-DESCRIPTION/ARCH.md | 30 ++++++++++-- study/kernel/00-DESCRIPTION/BPF.md | 2 + study/kernel/00-DESCRIPTION/DEBUGGING.md | 34 ++++++++++++- study/kernel/00-DESCRIPTION/LIVE_PATCH.md | 1 + study/kernel/00-DESCRIPTION/LOCKING.md | 6 ++- study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md | 8 ++-- study/kernel/00-DESCRIPTION/OPEN_SOURCE.md | 2 +- study/kernel/00-DESCRIPTION/SCHEDULER.md | 48 ++++++++++++++----- study/kernel/00-DESCRIPTION/TEST.md | 35 ++++++++++++++ study/kernel/00-DESCRIPTION/TODO.md | 29 +++++++++-- study/kernel/00-DESCRIPTION/run.sh | 8 ++++ 12 files changed, 180 insertions(+), 27 deletions(-) create mode 100644 study/kernel/00-DESCRIPTION/TEST.md create mode 100644 study/kernel/00-DESCRIPTION/run.sh diff --git a/study/kernel/00-DESCRIPTION/AI.md b/study/kernel/00-DESCRIPTION/AI.md index f43741a..7324fa2 100644 --- a/study/kernel/00-DESCRIPTION/AI.md +++ b/study/kernel/00-DESCRIPTION/AI.md @@ -243,7 +243,7 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad | 4 | [BertViz](https://github.com/jessevig/bertviz) | Jessevig | 使用交互式的方式, 可视化 Transformer 语言模型 (如 BERT, GPT2) 的注意力机制, 可在 Jupyter 或 Colab 中运行, 通过简单的 Python API 支持大多数 Hugging Face 预训练模型 (如 BERT, GPT2, T5 等), BertViz 扩展了 Llion Jones 的 Tensor2Tensor 可视化工具, 提供了头视图, 模型视图, 神经元视图等多个不同的可视化方式, 每个视图都提供了一个独特的视角来了解注意力机制. 参见 [2019/04/11, Human-Computer Interaction (cs.HC), Visualizing Attention in Transformer-Based Language Representation Models](https://arxiv.org/abs/1904.02679). | | 5 | [LLM Visualization](https://github.com/bbycroft/llm-viz | bbycroft | 将 Transformer 原理的详细细节通过交互可视化的方式一步步显示出来, 详细的展示了每一步的数学原理, 模型的网格结构, 参数构造的运行过程, 可以精确到每一步观察大模型运行的运算以及数据的变化. 作者的 [仓库 bbycroft/llm-viz](https://github.com/bbycroft/llm-viz) 以及 [在线演示地址 bbycroft.net/llm](https://bbycroft.net/llm), [@HansChanX](https://x.com/HansChanX) LLM 可视化演的中文翻译版本: [仓库 czhixin/llm-viz-cn](https://github.com/czhixin/llm-viz-cn) 以及 [示](https://llm-viz-cn.iiiai.com/llm). 其他 [Vaaaas/llm-viz-CN](https://github.com/Vaaaas/llm-viz-CN), 知乎报道 [矩阵模拟！Transformer 大模型 3D 可视化，GPT-3、Nano-GPT 每一层清晰可见](https://zhuanlan.zhihu.com/p/670287271) | | 6 | [Machine-Learning-Tokyo/Interactive_Tools](https://github.com/Machine-Learning-Tokyo/Interactive_Tools) | 这个项目收集了各种用于机器学习、深度学习和数学的交互式工具. | - +| 7 | [hahnyuan/LLM-Viewer](https://github.com/hahnyuan/LLM-Viewer) | 一个可视化语言与学习模型 LLMs 并分析在不同硬件平台上性能的工具. 可以进行网络级分析, 考虑峰值内存消耗和总推理时间成本等因素. 使用 LLM-Viewer, 可以获取 LLM 推理和性能优化的宝贵见解. 可以在 Web 浏览器或者命令行(CLI) 工具中使用. 在线体验地址 [LLM-Viewer Web](http://llm-viewer.com). 参见论文 [LLM Inference Unveiled: Survey and Roofline Model Insights](https://arxiv.org/abs/2402.16363). | # 5 基础理论 ------- @@ -281,7 +281,7 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad | 时间 | 分类 | Survey | 作者 | GitHub | 描述 | |:---:|:----:|:------:|:---:|:------:|:----:| | 2024/03/01 | 综述 | [NiuTrans/ABigSurveyOfLLMs](https://github.com/NiuTrans/ABigSurveyOfLLMs) | [NiuTrans](https://github.com/NiuTrans/ABigSurveyOfLLMs) | [NiuTrans](https://github.com/NiuTrans/ABigSurveyOfLLMs) | 一个关于大语言模型的综合性调研集合, 包含 150 多篇关于 LLM 的调研论文. 这些调研涵盖了 LLM 的各个方面, 包含通用调研, Transformer, 对齐, 提示学习, 上下文学习, 推理链, 提示工程, 数据, 评估, 社会问题, 安全性, 幻觉, 属性, 高效 LLM, 学习方法, 多模态 LLM, 基于知识的 LLM, 检索增强型 LLM, 知识编辑, LLM 扩展, LLM 与工具, LLM 与交互, 长序列 LLM, 以及 LLM 在教育, 法律, 医疗, 游戏, NLP 任务, 软件工程, 推荐系统, 图谱等领域的应用. | -| 2021/09/23 | 综述 | [metame-ai/awesome-llm-plaza](https://github.com/metame-ai/awesome-llm-plaza) | [metame-ai](https://github.com/metame-ai/awesome-llm-plaza) | [awesome-llm-plaza](https://github.com/metame-ai/awesome-llm-plaza) | NA | +| 2024/09/23 | 综述 | [metame-ai/awesome-llm-plaza](https://github.com/metame-ai/awesome-llm-plaza) | [metame-ai](https://github.com/metame-ai/awesome-llm-plaza) | [awesome-llm-plaza](https://github.com/metame-ai/awesome-llm-plaza) | NA | | 2024/01/16 | 多模态 | [A Survey of Resource-efficient LLM and Multimodal Foundation Models](https://arxiv.org/abs/2401.08092) | Mengwei Xu | [UbiquitousLearning](https://github.com/UbiquitousLearning/Efficient_Foundation_Model_Survey) | 一篇关于资源高效的大模型和多模态基础模型的综述论文. 论文涵盖了算法和系统两个方面的创新, 包括了高校的模型架构, 训练算法, 推理算法和模型压缩等内容. | | 2024/04/18 | 效率提升 | [The Efficiency Spectrum of Large Language Models: An Algorithmic Survey](https://arxiv.org/abs/2312.00678) | Tianyu Ding | [tding1](https://github.com/tding1/Efficient-LLM-Survey) | 一篇关于提供大语言模型效率的综合性调查论文, 全面回顾了旨在提高 LLM 效率的算法, 涵盖了扩展定律, 数据利用, 架构创新, 训练和调优策略以及推理计划等. | | 2024/05/23 | LLMs | [Efficient Large Language Models: A Survey](https://arxiv.org/abs/2312.03863) | Zhongwei Wan | [AIoT-MLSys-Lab](https://github.com/AIoT-MLSys-Lab/Efficient-LLMs-Survey) | 本文对高效 LLMs 研究的发展进行了系统而全面的回顾, 并将文献整理成由三个主要类别组成的分类法, 从模型中心、数据中心和框架中心的角度涵盖了不同但相互关联的高效 LLMs 主题, 并且从以模型为中心和以数据为中心的角度, 回顾了 LLMs 的算法层面和系统层面的高效技术. 详细介绍了每个分类下的具体技术, 如: 量化, 剪枝, 知识蒸馏, 数据选择, 提示工程等
1. [知乎--黄浴--高效大语言模型：综述](https://zhuanlan.zhihu.com/p/671710012)
2. [知乎--磐石--大模型高效推理 I 推理技术框架总结](https://zhuanlan.zhihu.com/p/696850285)
3. [知乎--享享学AI--大模型LLM微调技术方法汇总！](https://zhuanlan.zhihu.com/p/673675939) | diff --git a/study/kernel/00-DESCRIPTION/ARCH.md b/study/kernel/00-DESCRIPTION/ARCH.md index 2459a9d..1ca0b5f 100644 --- a/study/kernel/00-DESCRIPTION/ARCH.md +++ b/study/kernel/00-DESCRIPTION/ARCH.md @@ -197,7 +197,7 @@ Intel Architecture Day 2021, 官宣了自己的服务于终端和桌面场景的 | 2021/12/16 | Srinivas Pandruvada | [cpufreq: intel_pstate: Update EPP for AlderLake mobile](https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.17-P-State-ADL-Mobile) | 修正 AlderLake 的 EPP. | v1 ☑ 5.17-rc1 | [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b6e6f8beec98ba7541213c506fe908517fdc52b8) | | 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=64a0c5de40d3648a2fc5ff58348c1ff973976da1) | 这个补丁集是为调度器提供基于英特尔硬件的 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). | 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/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) | @@ -307,8 +307,10 @@ hfi_update_work_fn 英特尔低功耗模式守护程序 LPMD, 用于优化 Linux 下现代酷睿混合 CPU 的主动空闲电源, 这些 CPU 具有 E 和 P 内核的组合. Intel LPMD 支持多种低功耗状态, 可以根据 EPP/EPB/ITMT 设置、IRQ 迁移和任务迁移定义多种状态. 还可以根据不同的利用率阈值选择不同的低功耗状态. 根据检测到的 CPU 拓扑或用户配置文件选择最节能的 CPU. 根据系统利用率等信息, 将在适用时将系统置于低功耗模式, 比如使用最节能的 E 核, 并在不需要时禁用 P 的内核. -2024/06/12 LPMD 发布 0.0.4, 增强了其硬件反馈接口 (HFI) 监视器, 支持对来自被禁止的 CPU 的提示进行 HFI 监视, 支持多种低功耗状态, 支持工作负载类型提示, 并支持在低功耗模式转换期间更改能效偏好(EPP). 参见 ) - 报道 [Intel Low Power Mode Daemon v0.0.4 Released To Optimize Hybrid CPUs On Linux](https://www.phoronix.com/news/Intel-LPMD-Low-Power-0.0.4). +2024/06/12 LPMD 发布 v0.0.4, 增强了其硬件反馈接口 (HFI) 监视器, 支持对来自被禁止的 CPU 的提示进行 HFI 监视, 支持多种低功耗状态, 支持工作负载类型提示, 并支持在低功耗模式转换期间更改能效偏好(EPP). 参见 phoronix 报道 [phoronix, 2024/06/12, Intel Low Power Mode Daemon v0.0.4 Released To Optimize Hybrid CPUs On Linux](https://www.phoronix.com/news/Intel-LPMD-Low-Power-0.0.4) + + +2024/09/24 LPMD 发布 v0.0.7, 更改之一是新的 "--ignore-platform-check" 选项, 允许覆盖平台检查, 以便守护程序在未经验证的硬件平台上启动. 此新版本中还有 Autotool 构建系统改进和各种修复. 参见 phoronix 报道 [phoronix, 2024/09/24, Intel's LPMD "Low Power Mode Daemon" Now Identifies As The "Energy Optimizer"](https://www.phoronix.com/news/Intel-LPMD-v0.0.7). #### 1.4.1.5 编译器支持 @@ -346,7 +348,7 @@ AMD 关于大小核的专利 [US20210173715A1: METHOD OF TASK TRANSITION BETWEEN [效仿 Arm, AMD 也在做大小核芯片](https://mp.weixin.qq.com/s/ckDRWep-ih287wIsjddRrw). -[AMD “big.LITTLE” aka heterogeneous computing in Ryzen 8000 series](https://videocardz.com/newz/amd-patents-a-task-transition-method-between-big-and-little-processors). +[AMD "big.LITTLE" aka heterogeneous computing in Ryzen 8000 series](https://videocardz.com/newz/amd-patents-a-task-transition-method-between-big-and-little-processors). [AMD reportedly working on its heterogeneous CPU design](https://technosports.co.in/2021/06/14/amd-reportedly-working-on-its-heterogeneous-cpu-design). @@ -355,6 +357,7 @@ AMD 关于大小核的专利 [US20210173715A1: METHOD OF TASK TRANSITION BETWEEN | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:---:|:----:|:---:|:----:|:---------:|:----:| | 2024/05/07 | Perry Yuan | [AMD Pstate Driver Fixes and Improvements](https://lore.kernel.org/all/cover.1715065568.git.perry.yuan@amd.com) | 参见 phoronix 报道 [AMD Posts Patches For Improving Heterogeneous Core Type CPUs On Linux](https://www.phoronix.com/news/AMD-Heterogeneous-P-State-Linux) 和 [AMD P-State Linux Patches Updated For Heterogeneous CPUs](https://www.phoronix.com/news/AMD-P-State-Hetero-v3), [Testing The AMD Heterogeneous Core Topology Linux Patches On Ryzen AI 300 Series](https://www.phoronix.com/news/Ryzen-AI-Heterogeneous-Core-Top). | v1 ☐☑✓ | [2024/05/07, LORE v1,0/11](https://lore.kernel.org/all/cover.1715065568.git.perry.yuan@amd.com)
*-*-*-*-*-*-*-*
[2024/06/11, LORE v3,0/10](https://lore.kernel.org/all/cover.1718095377.git.perry.yuan@amd.com) | +| 2024/10/03 | Mario Limonciello | [Detect max performance values for heterogeneous AMD designs](https://lore.kernel.org/all/20241003213759.3038862-1-superm1@kernel.org) | [New AMD Linux Patches Aim To Further Boost Performance For Heterogeneous CPU Designs](https://www.phoronix.com/news/AMD-Linux-Hetero-Max-Detect). | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20241003213759.3038862-1-superm1@kernel.org) | ### 1.4.3 ARM big.LITTLE & DynamIQ @@ -726,6 +729,19 @@ TLB entry shootdown 常常或多或少的带来一些性能问题. | 2023/05/09 | Kristina Martsenko | [arm64: Support for Armv8.8 memcpy instructions in userspace](https://lore.kernel.org/all/20230509142235.3284028-1-kristina.martsenko@arm.com) | Armv8.8 扩展添加了执行 memcpy()、memset() 和 memmove() 等操作 (FEAT_MOPS). 这个补丁集增加了对的支持使用用户空间中的新指令. | v8 ☐☑✓ | [LORE v8,0/11](https://lore.kernel.org/all/20230509142235.3284028-1-kristina.martsenko@arm.com) | | 2023/09/15 | Kristina Martsenko | [KVM: arm64: Support for Arm v8.8 memcpy instructions in KVM guests](https://lore.kernel.org/all/20230915124840.474888-1-kristina.martsenko@arm.com) | TODO | v8 ☐☑✓ | [LORE v8,0/3](https://lore.kernel.org/all/20230915124840.474888-1-kristina.martsenko@arm.com) | + +### 2.3.5 GLIBC 优化 +------- + + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:----:|:---------:|:----:| +| 2024/09/09 | Wilco Dijkstra | [AArch64: Optimize memset](https://sourceware.org/git/?p=glibc.git;a=commit;h=cec3aef32412779e207f825db0d057ebb4628ae8) | 这个补丁通过 AArch64 的 GNU C 库中 memset 进行优化, 使得 memset 性能提高 ~24%. 通过避免分支和使用重叠的 store 来改进小型 memset. 对超过 128 字节的副本使用 DC ZVA. 删除 64 和 128 以外的 ZVA 大小的不必要代码. 在 Neoverse N1 上, 随机 memset 基准测试的性能提高了 24%. 参见 [phoronix, 2024/09/10, GNU C Library Tuning For AArch64 Helps Memset Performance By ~24%](https://www.phoronix.com/news/Glibc-AArch64-memset-Optimize). | v1 ☐☑✓ | [COMMIT](https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=cec3aef32412779e207f825db0d057ebb4628ae8) | + + + + + ## 2.4 pseudo-NMI ------- @@ -1169,6 +1185,10 @@ Rosetta 是一个转译过程, 允许用户在 Apple Silicon 上运行包含 x86 [FEX 2407](https://fex-emu.com/FEX-2406) 于 2024/07/04 发布, 实现了 AVX/AVX2 的支持. 为了在 ARM 上实现高效的 AVX 仿真, 需要 256 位 SVE. 对于其他硬件, 256 位指令被分解为两个 128 位指令. 这条路径不太理想, 但至少允许支持 AVX 的软件运行. 参见 phoronix 报道 [FEX 2407 Emulator For x86_64 Binaries On ARM Now Handles AVX/AVX2](https://www.phoronix.com/news/FEX-Emulator-2407). +[FEX 2408](https://fex-emu.com/FEX-2408) 提供了更好的 x87 浮点性能, 用于增强在此模拟器上运行的旧游戏. 参见 [phoronix, 2024/08/13, FEX 2408 Emulator For x86_64 Binaries On AArch64 Teases More Performance](https://www.phoronix.com/news/FEX-2408-Released). + +Fedora 42 通过 FEX 支持了 64 位 ARM64 的机器上的直接无缝运行 x86/x86_64 程序, 参见 [phoronix, 2024/09/12, Fedora 42 On 64-bit ARM Might Make It Seamless To Run x86/x86_64 Programs](https://www.phoronix.com/news/Fedora-42-FEX-AArch64-Proposal). + ### 6.7.3 Box64 ------- @@ -1302,6 +1322,8 @@ openEuler 提供了 [openEuler/prefetch_tuning](https://gitee.com/openeuler/pref [AMD P-State Preferred Core Support Coming With Linux 6.9](https://www.phoronix.com/news/Linux-6.9-AMD-P-State-Preferred) +[AMD Preferred Core Fix Lands Ahead Of Linux 6.11-rc6](https://www.phoronix.com/news/AMD-PM-Linux-6.11-rc6) + 磁芯频率受半导体工艺变化的影响. 并非所有内核都能够达到最大频率, 具体取决于基础架构限制. 因此, AMD 重新定义了硬件最大频率的概念. 这意味着一小部分内核可以达到最大频率. 为了找到给定场景的最佳进程调度策略, 操作系统需要通过 CPPC 接口的最高性能功能寄存器来了解平台通知的核心排序. diff --git a/study/kernel/00-DESCRIPTION/BPF.md b/study/kernel/00-DESCRIPTION/BPF.md index c68455b..c65e081 100644 --- a/study/kernel/00-DESCRIPTION/BPF.md +++ b/study/kernel/00-DESCRIPTION/BPF.md @@ -625,6 +625,8 @@ Wasmtime 完全开源, 使用 Rust 编程语言, 是的, 并且符合 WASI 标 [WASM 原生时代已经到来 | 解读 WebAssembly 的 2022](https://csdnnews.blog.csdn.net/article/details/128739217) [Wasmer 4.3 Released: WebAssembly Runtime 25% Faster On Cold Startups](https://www.phoronix.com/news/Wasmer-4.3-Released) +[Wasmer 4.4 Released To Continue Pushing Universal Apps With WebAssembly](https://www.phoronix.com/news/Wasmer-4.4-Released) + # 10 云原生 ------- diff --git a/study/kernel/00-DESCRIPTION/DEBUGGING.md b/study/kernel/00-DESCRIPTION/DEBUGGING.md index 71212e0..3fe3619 100644 --- a/study/kernel/00-DESCRIPTION/DEBUGGING.md +++ b/study/kernel/00-DESCRIPTION/DEBUGGING.md @@ -77,6 +77,9 @@ blogexcerpt: FZF 是目前最快的模糊搜索工具. 使用 golang 编写. 结 虽然不省略帧指针对性能有已知的影响, 因此之前各发行版都默认不开启栈帧, 但是 2022 年各大发行版, Fedora/Ubuntu 24.04 LTS 等均启用了帧指针以实现更好的调试 / 分析. 为了两全其美, 2024 年 Red Hat 开发 eu-stracktrace 作为一种新的分析方法, 而无需依赖帧指针. 参见 phoronix 报道 [phoronix, 2024/06/11, Red Hat Developing"eu-stacktrace"For Profiling Without Frame Pointers](https://www.phoronix.com/news/Red-Hat-eu-stacktrace), [redhat 博客 --Get system-wide profiles of binaries without frame pointers](https://developers.redhat.com/articles/2024/06/11/get-system-wide-profiles-binaries-without-frame-pointers#), 以及 [elfutils, eu-stacktrace development branch](https://sourceware.org/cgit/elfutils/tree/README.eu-stacktrace?h=users/serhei/eu-stacktrace). +随后在 Canonical 决定在 Ubuntu 24.04 LTS 中默认启用帧指针之后, 他们最终添加了许多性能工具以默认随 Ubuntu 24.04 LTS 一起提供, 对于 Ubuntu 24.10, 一个后期的变化是添加了另一个默认安装在 Ubuntu 桌面上的工具: Sysprof. 参见 [phoronix, 2024/09/10, Ubuntu 24.10 Desktop To Ship With Sysprof Profiler Pre-Installed](https://www.phoronix.com/news/Ubuntu-24.10-Sysprof-Default). + + # 2 unikernel ------- @@ -264,9 +267,13 @@ $reclaim = current\_mem \times reclaim\_ratio \times max(0,1 – \frac{psi_some} [What became of getrandom() in the vDSO](https://lwn.net/Articles/983186) +[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) + | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:---:|:----:|:---:|:----:|:---------:|:----:| | 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) | +| 2024/09/03 | Adhemerval Zanella | [arm64: vDSO: Wire up getrandom() vDSO implementation](https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git/commit/?id=88272e1f28dca9372e89887d3fb41402fd7ceb3d) | [phoronix, 2024/09/05, getrandom() vDSO Coming To More Architectures With Linux 6.12](https://www.phoronix.com/news/getrandom-vDSO-More-CPU-Ports). | v1 ☐☑✓ v6.11-rc1 | [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git/commit/?id=88272e1f28dca9372e89887d3fb41402fd7ceb3d) | +| 2024/09/03 | Adhemerval Zanella | [LoongArch: vDSO: Wire up getrandom() vDSO implementation](https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git/commit/?id=88272e1f28dca9372e89887d3fb41402fd7ceb3d). | TODO | v1 ☐☑✓ v6.11-rc1 | [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git/commit/?id=88272e1f28dca9372e89887d3fb41402fd7ceb3d) | # 9 PRINTK @@ -518,12 +525,29 @@ bperf 试图通过允许多个 "周期" 或 "指令" 的 perf_event (在不同 | 2021/03/16 | Song Liu | [perf-stat: share hardware PMCs with BPF](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7fac83aaf2eecc9e7e7b72da694c49bb4ce7fdfc) | TODO | v2 ☐☑✓ 5.13-rc1 | [LORE](https://lore.kernel.org/all/20210312020257.197137-1-songliubraving@fb.com)
*-*-*-*-*-*-*-*
[LORE v2,0/3](https://lore.kernel.org/all/20210316211837.910506-1-songliubraving@fb.com)| | 2021/06/25 | Namhyung Kim | [perf stat: Enable BPF counters with --for-each-cgroup](https://lore.kernel.org/all/20210625071826.608504-1-namhyung@kernel.org) | bperf 被添加到使用 BPF 来计算各种性能事件目的, 对其扩展 cgroup 的支持. 与其他 bperf 不同, 它不与其他进程共享事件, 但它可以减少 perf 会话中每个被监视的 GROUP 组的不必要事件 (以及多路复用的开销). 当 `for-each-cgroup` 与 `BPF -counters` 一起使用时, 它将在每个 cpu 内部打开 cgroup-switches 事件, 并附加新的 BPF 程序来读取给定的 perf_events 并聚合 cgroups 的结果. 只有当 task 切换到另一个 group 组中的 task 时才会调用它. | v4 ☐☑✓ | [LORE v4,0/4](https://lore.kernel.org/all/20210625071826.608504-1-namhyung@kernel.org)
*-*-*-*-*-*-*-*
[LORE v5](https://lore.kernel.org/all/20210701211227.1403788-1-namhyung@kernel.org)| -## 11.10 perf other + +## 11.10 data type profiling ------- +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:---:|:----:|:---:|:----:|:---------:|:----:| +| 2023/12/12 | Namhyung Kim | [perf tools: Introduce data type profiling](https://lore.kernel.org/all/20231213001323.718046-1-namhyung@kernel.org) | 这个功能可以关联性能监控单元 (PMU) 样本到它们引用的数据类型, 使用 DWARF 调试信息实现. 这个过程不需要对目标程序进行任何修改. 基本思想是使用 DWARF 位置表达式来确定变量的内存访问. 如果有一个样本在某条指令上, 可以使用 DWARF 调试信息来确定这条指令访问的是哪个变量以及它的类型. 使用方法: 使用 perf mem record 命令来收集精确的内存访问样本, 然后使用 perf report 或 perf annotate 来查看结果. 结果可以通过新添加的排序键 'type' 和 'typeoff' 来展示数据类型和字段的名称. 参见 LWN 报道 [LWN, 2023/12/21, Data-type profiling for perf](https://lwn.net/Articles/955709) | v3 ☐☑✓ | [2023/12/12, LORE v3,0/17](https://lore.kernel.org/all/20231213001323.718046-1-namhyung@kernel.org) | +| 2024/07/18 | Athira Rajeev | [Add data type profiling support for powerpc](https://lore.kernel.org/all/20240718084358.72242-1-atrajeev@linux.vnet.ibm.com) | 这个补丁集的主要目的是为 PowerPC 架构添加数据类型剖析(data type profiling)的支持. 之前由 Namhyung Kim 提交的一系列补丁已经为 perf 工具引入了数据类型剖析的基本支持. 这些补丁使 perf 能够关联性能监控单元(PMU)的样本到它们所引用的数据类型, 利用 DWARF 调试信息来实现这一点. 目前, 这种支持已经在 x86 架构上可用, 可以通过 perf report 或 perf annotate 命令来查看数据类型信息.
1. PowerPC 指令表更新: 添加了一个 PowerPC 指令助记符表, 用于将负载/存储指令与移动操作关联起来, 从而识别指令是否涉及内存访问.
2. 获取寄存器编号和偏移量: 为了从给定的指令中获取寄存器编号和访问偏移量, 代码使用了 struct arch 中的 objump 字段. 为 PowerPC 添加了相应的条目.
3. 获取寄存器编号函数: 实现了一个 get_arch_regnum 函数, 可以从寄存器名称字符串中返回寄存器编号. 解析原始指令为了更准确地解析 PowerPC 指令.
补丁集采取了以下步骤使用原始指令: 补丁集支持直接使用原始指令而非解析后的指令名称. 这样可以通过宏来提取指令的操作码和寄存器字段.
示例: 例如, 使用 --show-raw-insn 选项时, objdump 会给出原始指令的十六进制表示, 如 "38 01 81 e8", 这对应于 "ld r4,312(r1)" 指令.
避免重复使用 objdump: 补丁集避免了重复使用 objdump 来读取原始指令, 而是直接从动态共享对象 (DSO) 中读取二进制代码.
补丁集作者提供了测试结果, 其中展示了使用 perf annotate --data-type --insn-stat 命令的结果. 结果显示有大约 43.7% 的指令被正确解析, 而 56.3% 的指令未能成功解析. 作者指出还有大约 25% 的未知指令没有得到处理. | v8 ☐☑✓ | [2024/03/09, LORE v1, 0/3](https://lore.kernel.org/all/20240309072513.9418-1-atrajeev@linux.vnet.ibm.com)
*-*-*-*-*-*-*-*
[2024/05/06, LORE v2, 0/9](https://lore.kernel.org/all/20240506121906.76639-1-atrajeev@linux.vnet.ibm.com)
*-*-*-*-*-*-*-*
[2024/07/13, LORE 07, 00/18](https://lore.kernel.org/linux-perf-users/20240713165529.59298-1-atrajeev@linux.vnet.ibm.com)
*-*-*-*-*-*-*-*
[2024/07/18, LORE v8, 00/15](https://lore.kernel.org/all/20240718084358.72242-1-atrajeev@linux.vnet.ibm.com) | +| 2024/07/31 | Namhyung Kim | [perf mem: Basic support for data type profiling](https://lore.kernel.org/all/20240731235505.710436-1-namhyung@kernel.org) | 为 perf 添加对数据类型剖析的基本支持.当使用 perf mem report 命令时, 可以显示关于内存访问的数据类型信息. 补丁添加了一些方便的选项来查看这些信息, 例如 `-T` 和 `-s mem` 选项. 显示了如何按内存层级(如 L1 缓存命中、RAM 访问等)和数据类型(如结构体、整数等)对内存访问进行分类. 通过这些更改, 开发人员可以更详细地了解应用程序或内核模块在运行时如何使用不同类型的内存, 并有助于识别潜在的性能瓶颈. | v1 ☐☑✓ | [2024/07/31, LORE v1,0/6](https://lore.kernel.org/all/20240731235505.710436-1-namhyung@kernel.org) | +| 2024/07/25 | Namhyung Kim | [perf annotate: Cache debuginfo for data type profiling](https://lore.kernel.org/all/20240726015723.1329937-1-namhyung@kernel.org) | TODO | v2 ☐☑✓ | [2024/07/26, LORE](https://lore.kernel.org/all/20240726015723.1329937-1-namhyung@kernel.org)
*-*-*-*-*-*-*-*
[2024/08/05, LORE v3](https://lore.kernel.org/all/20240805234648.1453689-1-namhyung@kernel.org/) | + + + +## 11.11 perf other +------- + + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:---:|:----:|:---:|:----:|:---------:|:----:| | 2021/07/20 | kan.liang@linux.intel.com | [perf: Save PMU specific data in task_struct](https://lore.kernel.org/all/1626788420-121610-1-git-send-email-kan.liang@linux.intel.com) | 某些特定于 PMU 的数据必须在上下文切换期间保存 / 恢复, 例如 LBR 调用堆栈数据. 目前, 数据保存在事件上下文结构中, 但仅针对每个流程的事件. 对于系统范围的事件, 由于上下文切换后缺少 LBR 调用堆栈数据, 与按进程模式相比, LBR 调用栈总是更短. | v6 ☐☑✓ | [LORE v6,0/6](https://lore.kernel.org/all/1626788420-121610-1-git-send-email-kan.liang@linux.intel.com) | -## 11.11 WindowsPerf + +## 11.12 WindowsPerf ------- [技术分享 | 发布WindowsPerf：用于Windows on Arm的开源性能分析工具](https://mp.weixin.qq.com/s?__biz=MzIwOTYyMjQzOQ==&mid=2247507803&idx=1&sn=16ad97e99a0cb77bad2d9e460a166e85&chksm=97739b93a0041285052512b86886f5b613cf8bb2924f3a8d7b3007325e780c66f70beb7d2037&scene=27) @@ -592,6 +616,11 @@ bperf 试图通过允许多个 "周期" 或 "指令" 的 perf_event (在不同 [Experiences in Profile-Guided Operating System Kernel Optimization](https://yaoguopku.github.io/papers/Yuan-ApSys-14.pdf) +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:---:|:----:|:---:|:----:|:---------:|:----:| +| 2024/07/28 | Rong Xu | [Add AutoFDO and Propeller support for Clang build](https://lore.kernel.org/all/20240728203001.2551083-1-xur@google.com) | 此补丁系列旨在将 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). | v1 ☐☑✓ | [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) | + + ### 13.2.2 LTO(Link Time Optimization) ------- @@ -1182,6 +1211,7 @@ Fedora 尝试优化 systemd 开机以及重启的时间, 参见 phoronix 报道 | 2024/07/24 | Miguel Ojeda | [Rust: support `CPU_MITIGATIONS` and enable `objtool`](https://lore.kernel.org/all/20240724161501.1319115-1-ojeda@kernel.org) | 关于在 Rust 内核代码中实现各种 CPU 安全缓解措施的最新补丁, 作为其中的一部分, 同时为 Rust 启用了 objtool 支持. 重点是根据编译器的 Retpolines、Rethunk 和直线推测 (SLS) 处理来传递相关的编译器标志以构建 Rust 代码. 通过这些补丁, 适当的标志将被传递给 Rust 编译器, 以便在需要编译器端操作的安全缓解措施中提供足够的保护. | v2 ☐☑✓ |[LORE v2,0/6](https://lore.kernel.org/all/20240724161501.1319115-1-ojeda@kernel.org) | 几乎每一个 Linux 内核周期都会引入新的补丁, 这些补丁通常会提升内核支持的 Rust 语言版本, 以便达到一个合适的最低版本要求. Miguel Ojeda 发布的这组组补丁, 旨在使 Rust 内核代码能够支持多个版本的 Rust 编译器("rustc"), 然后只需要指定一个安全的最低 Rust 版本要求. 参见 [The Linux Kernel Matures To Having A Minimum Rust Toolchain Version](https://www.phoronix.com/news/Linux-Patches-Multiple-Rust-Ver). | v1 ☐☑✓ | [LORE v1,0/13](https://lore.kernel.org/all/20240701183625.665574-1-ojeda@kernel.org) | | 2024/08/05 | Danilo Krummrich | [Generic `Allocator` support for Rust](https://lore.kernel.org/all/20240805152004.5039-1-dakr@kernel.org) | 这个补丁系列是关于为 Rust 语言在 Linux 内核中添加通用的内核分配器(Allocator)支持. 以下是补丁系列的主要变更和目的:
1. 添加通用内核分配器支持: 目前主线上, Rust 在 Linux 内核中的内存分配仅限于 kmalloc. 这个补丁系列扩展了这一功能, 允许使用更多的内存分配器以及分配策略.
2. 自定义 Allocator trait: 为了避免向内核添加不稳定的 Rust 特性, 补丁系列没有扩展 Rust 的 alloc crate 中的 Allocator trait, 也没有扩展 BoxExt 和 VecExt 扩展. 而是引入了特定的 Allocator trait, 并由 Kmalloc、Vmalloc 和 KVmalloc 分配器实现, 这些分配器也是在这个系列中实现的.
3. 定义内核专用类型, 移除对 alloc crate 的依赖:: 为了使用新的分配器, 补丁系列添加了自定义的 `Box` 和 `Vec` 类型(其中 A 是特定的分配器), 这些类型依赖于特定的分配器. | v1 ☐☑✓ | [2024/08/05, LORE v4,00/28](https://lore.kernel.org/all/20240805152004.5039-1-dakr@kernel.org) | +| 2024/09/03 | Jiaxun Yang | [rust: Initial MIPS support](https://lore.kernel.org/all/20240903-mips-rust-v1-0-0fdf0b2fd58f@flygoat.com) | [New Patches Bring Rust Linux Kernel Support To MIPS](https://www.phoronix.com/news/Rust-Linux-Kernel-MIPS-Patches) | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20240903-mips-rust-v1-0-0fdf0b2fd58f@flygoat.com) | diff --git a/study/kernel/00-DESCRIPTION/LIVE_PATCH.md b/study/kernel/00-DESCRIPTION/LIVE_PATCH.md index 91fbbb5..4ba57e0 100644 --- a/study/kernel/00-DESCRIPTION/LIVE_PATCH.md +++ b/study/kernel/00-DESCRIPTION/LIVE_PATCH.md @@ -444,4 +444,5 @@ kpatch 的实现一直是根据内核的进展而演进的, 对 JUMP_LABEL 的 | 2016/02/10 | Li Bin | [livepatch: patch creation tooling proposal](https://lore.kernel.org/all/cover.1477578530.git.jpoimboe@redhat.com) | Kpatch-Build | RFC ☐ 4.0-rc1 | [GitHub](https://github.com/dynup/kpatch) | | 2016/02/10 | Jiri Slaby | [announcing LLpatch: arch-independent live-patch creation](https://lore.kernel.org/all/CABFpvm2o+d0e-dfmCx7H6=8i3QQS_xyGFt4i3zn8G=Myr_miag@mail.gmail.com) | Google 提供的新的用户空间实时补丁创建工具, LLpatch, 与 kpatch 构建并行, 但不需要它的特定于 arch 的代码来进行 ELF 分析和操作. 基于 LLVM-diff 可以访问比 kpatch 的 create-diff- -object 能够从 elf 级别的差异中推断出的更多信息. | RFC ☐ 5.14-rc1 | [GitHub](https://github.com/google/LLpatch) | | 2023/03/06 | Joe Lawrence | [livepatch: klp-convert tool](https://lore.kernel.org/all/20230306140824.3858543-1-joe.lawrence@redhat.com) | livepatches 可能会使用不包含在其自身作用域中的符号, 并且, 正因为如此, 最终可能会编译为只在模块加载期间解决的重定位. 然而, 当引用的符号没有导出时, 解决这个重定位问题需要关于保存符号的对象 (vmlinux 或模块) 及其在对象中的位置的信息, 因为一个对象可能包含多个具有相同名称的符号. 提供这些信息必须根据 `Documentation/livepatch/module-self-format.txt` 中指定的内容进行. 目前, 还没有一种简单的方法可以在最终的 livepatch elf 对象中嵌入所需的信息. klp-convert 以两种不同的形式解决了这个问题: 1. 依靠在内核编译期间构建的符号映射来自动推断重定位目标符号, 并且, 当这种推断不可能时.
2. 通过使用 elf 对象中的注释将重定位相应地转换为规范, 使其能够由 livepatch 加载器处理. 鉴于以上所述, 添加对符号形式的符号映射的支持 `.klp` 文件; 添加 klp 转换工具; 将 klp 转换工具集成到 kbuild 中; 使 livepatch 模块在内核编译管道中可识别; 添加数据结构和宏, 使用户能够注释 livepatch 源代码; 使 modpost stage 与 livepatches 兼容; 参见 [Understand and review klp-convert patchset](https://hackweek.opensuse.org/22/projects/understand-and-review-klp-convert-patchset), [klp-convert and livepatch relocations, LPC-2019](https://lpc.events/event/4/contributions/507/attachments/316/533/LPC2019.pdf). | v7 ☐☑✓ | [LORE v7,0/10](https://lore.kernel.org/all/20230306140824.3858543-1-joe.lawrence@redhat.com), [SUSE/klp-convert](https://github.com/SUSE/klp-convert), [joe-lawrence/linux](https://github.com/joe-lawrence/linux/tree/klp-convert-v5) | +| 2024/09/02 | Josh Poimboeuf | [objtool, livepatch: Livepatch module generation](https://lore.kernel.org/all/cover.1725334260.git.jpoimboe@kernel.org) | 引入一种新的构建 Livepatch 模块的工具: klp-build. 使用一个新的 objtool klp 子命令, 通过源代码补丁作为输入来生成 Livepatch 模块. 与现有的 kpatch-build 相比
klp-build
1. 设计更简单, 代码量减少了约 3000 行, 利用 objtool 的控制流图(CFG)功能来创建用于检测函数变化的校验和, 解决了__LINE__偏移变化的问题, 这得益于 adjust-patch-lines 脚本.
2. 利用现有工具: 通过使用现有的 objtool 功能, klp-build 能够检测函数变化, 从而简化了 Livepatch 模块的生成过程.
3. klp-build 能够运行在 vmlinux.o 上, 与 IBT 和 LTO 等后期链接功能兼容.使用方法: `scripts/livepatch/klp-build /path/to/my.patch`, 如果成功, 将在当前目录下创建补丁模块(livepatch.ko). | v1 ☐☑✓ | [LORE v1,0/31](https://lore.kernel.org/all/cover.1725334260.git.jpoimboe@kernel.org) | diff --git a/study/kernel/00-DESCRIPTION/LOCKING.md b/study/kernel/00-DESCRIPTION/LOCKING.md index 656132c..a1023d1 100644 --- a/study/kernel/00-DESCRIPTION/LOCKING.md +++ b/study/kernel/00-DESCRIPTION/LOCKING.md @@ -296,6 +296,8 @@ percpu rw 信号量是一种新的读写信号量设计, 针对读取锁定进 [Recent RCU changes](https://lwn.net/Articles/894379) +[The RCU API, 2024 edition](https://lwn.net/Articles/988638) + | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2019/06/01 | "Joel Fernandes (Google)" | [Harden list_for_each_entry_rcu() and family](https://lore.kernel.org/patchwork/cover/1082845) | 本系列增加了一个新的内部函数rcu_read_lock_any_held(), 该函数在调用这些宏时检查reader节是否处于活动状态. 如果不存在reader section, 那么list_for_each_entry_rcu()的可选第四个参数可以是一个被计算的lockdep表达式(类似于rcu_dereference_check()的工作方式). . | RFC ☑ 5.4-rc1 | [PatchWork RFC,0/6](https://lore.kernel.org/patchwork/cover/1082845) | @@ -473,7 +475,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://lore.kernel.org/all/20240507045450.895430-1-jstultz@google.com) | Proxy Execution 是一种通用的优先级继承机制的实现方法, 用于解决优先级反转问题和其他类似的问题. 这些预备补丁的目的是为后续更复杂的 Proxy Execution 相关补丁打下基础.
在发送第 7 版 Proxy Execution 补丁集时, John Stultz 收到了反馈, 指出补丁集变得过于庞大难以审查. 因此, 根据 Qais Yousef 的建议, 他决定将补丁集分为两部分：一部分是预备性的更改, 另一部分是更复杂的功能实现. | v10 ☐☑✓ | [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/05/06 | John Stultz | [Preparatory changes for Proxy Execution](https://lore.kernel.org/all/20240507045450.895430-1-jstultz@google.com) | Proxy Execution 是一种通用的优先级继承机制的实现方法, 用于解决优先级反转问题和其他类似的问题. 这些预备补丁的目的是为后续更复杂的 Proxy Execution 相关补丁打下基础.
在发送第 7 版 Proxy Execution 补丁集时, John Stultz 收到了反馈, 指出补丁集变得过于庞大难以审查. 因此, 根据 Qais Yousef 的建议, 他决定将补丁集分为两部分：一部分是预备性的更改, 另一部分是更复杂的功能实现. | v10 ☐☑✓ | [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/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) | @@ -506,6 +508,8 @@ Paul McKenney's parallel programming book, [LWN](https://lwn.net/Articles/421425 | [taskflow/taskflow](https://github.com/taskflow/taskflow) | Function Flow 并行化业界标杆, 犹他大学开发, 支持异构. [官网](https://taskflow.github.io). 论文
1. [Taskflow: A Lightweight Parallel and Heterogeneous Task Graph Computing System, TPDS 2021](https://taskflow.github.io/papers/tpds21-taskflow.pdf)
2. [Late Breaking Results: Efficient Timing Propagation with Simultaneous Structural and Pipeline Parallelisms, DAC 2022](https://tsung-wei-huang.github.io/papers/dac2022.pdf)
3. [Pipeflow: An Efficient Task-Parallel Pipeline Programming Framework using Modern C++, HPDC 2022](https://arxiv.org/abs/2202.00717)
4. [From RTL to CUDA: A GPU Acceleration Flow for RTL Simulation with Batch Stimulus, ICPP 2022](https://icpp22.gitlabpages.inria.fr/prog/) | | [ChunelFeng/CGraph](https://github.com/ChunelFeng/CGraph) | ChunelFeng 的图化调度并行框架, 轻量, 快捷, 暂不支持异构 | | [AthrunArthur/functionflow](https://github.com/AthrunArthur/functionflow) | 基于 C++11 的 FunctionFlow 并行编程库. | +| [symphony09/ograph](https://github.com/symphony09/ograph) | OGraph 是一个用 Go 实现的图流程执行框架. 可以通过构建Pipeline(流水线), 来控制依赖元素依次顺序执行、非依赖元素并发执行的调度功能. 此外, OGraph 还提供了丰富的重试, 超时限制. 执行追踪等开箱即用的特征. OGraph 受启发于另一个 C++项目 CGraph. 但 OGraph 并不等于 Go 版本的 CGraph. 和 CGraph 一样, OGraph 也提供基本的构图和调度执行能力, 但有以下几点关键不同:
1. 用 Go 实现, 使用协程而非线程进行调度, 更轻量灵活
2. 支持通过 Wrapper 来自定义循环、执行条件判断、错误处理等逻辑, 并可以随意组合
3. 支持导出图结构, 再在别处导入执行
4. 灵活的虚节点设置, 用以简化依赖关系, 以及延迟到运行时决定实际执行的节点. 实现多态. | +| [google-ai-edge/mediapipe](https://github.com/google-ai-edge/mediapipe) | ### 12.2.2 WorkQueue diff --git a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md index 890c70e..a66079c 100644 --- a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md +++ b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md @@ -810,11 +810,10 @@ github 地址: [Mitosis Project](https://github.com/mitosis-project), [linux 内 | 2021 | [Fast Local Page-Tables for Virtualized NUMA Servers with vMitosis; April, 2021; asplos21_vmitosis.pdf](https://research.vmware.com/files/attachments/0/0/0/0/1/3/8/asplos21_vmitosis.pdf)
[Fast Local Page-Tables for Virtualized NUMA Servers with vMitosis; April, 2021; vmitosis_ext_abstract.pdf](https://research.vmware.com/files/attachments/0/0/0/0/1/3/1/vmitosis_ext_abstract.pdf) | - ## 1.x 其他页面页表相关 ------- -【】（） + | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| @@ -5674,8 +5673,10 @@ mcpage 有成本. 除了 THP 没有带来 TLB 的好处之外, 与 4K 基本页 |:---:|:----:|:---:|:----:|:---------:|:----:| | 2024/03/11 | Maíra Canal | [drm/v3d: Enable Super Pages](https://lore.kernel.org/all/20240311100959.205545-1-mcanal@igalia.com) | [Raspberry Pi V3D Graphics Driver Preps For Super Pages To Boost Performance](https://www.phoronix.com/news/Raspberry-Pi-V3D-Super-Pages) | v3 ☐☑✓ | [LORE v3,0/5](https://lore.kernel.org/all/20240311100959.205545-1-mcanal@igalia.com) | +## 7.5 PAGE_SIZE +------- - +[AmpereOne Performance On Linux 6.11 Kernel, 4K vs. 64K Page Size Comparison](https://www.phoronix.com/review/ampereone-64k-linux611) # 8 进程虚拟地址空间(VMA) ------- @@ -7273,6 +7274,7 @@ KFENCE 的灵感来自于 [GWP-ASan](http://llvm.org/docs/GwpAsan.html), 这是 |:----:|:----:|:---:|:----:|:---------:|:----:| | 2021/08/05 | Mel Gorman | [Protect vmstats on PREEMPT_RT](https://lore.kernel.org/patchwork/patch/1472709) | NA | v2 ☐ | [PatchWork 0/1,v2](https://patchwork.kernel.org/project/linux-mm/cover/20210723100034.13353-1-mgorman@techsingularity.net) | | 2021/12/22 | Shakeel Butt | [memcg: add per-memcg vmalloc stat](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4e5aa1f4c2b489bc6f3ab5ca54747b18a847289d) | NA | v1 ☑✓ 5.17-rc1 | [PatchWork v1](https://patchwork.kernel.org/project/linux-mm/patch/20211221215336.1922823-1-shakeelb@google.com)
*-*-*-*-*-*-*-*
[PatchWork v2](https://patchwork.kernel.org/project/linux-mm/patch/20211222052457.1960701-1-shakeelb@google.com) | +| 2024/07/30 | Pasha Tatashin | [Kernel stack usage histogram](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=fbe76a6557a83af5ef3819fd7b7ffd0a5d3b4e51) | 这个补丁集的目标是为 Linux 内核提供一个内核栈使用情况的直方图统计. 参见 [phoronix, 2024/09/24, Linux 6.12 Adds A Kernel Stack Usage Histogram To Help With Optimizations](https://www.phoronix.com/news/Linux-Kernel-Stack-Histogram). | v5 ☐☑✓ v6.12-rc1 | [2024/05/30, LORE v3](https://lore.kernel.org/all/20240530170259.852088-1-pasha.tatashin@soleen.com)
*-*-*-*-*-*-*-*
[2024/07/18, LORE v4](https://lore.kernel.org/all/20240718202611.1695164-1-pasha.tatashin@soleen.com)
*-*-*-*-*-*-*-*
[2024/07/30, LORE v5,0/3](https://lore.kernel.org/all/20240730150158.832783-1-pasha.tatashin@soleen.com) | ### 13.4.6 meminfo diff --git a/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md b/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md index 275413e..4c72052 100644 --- a/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md +++ b/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md @@ -111,7 +111,7 @@ | 6.8 | [The first half of the 6.8 merge window](https://lwn.net/Articles/957188), [The rest of the 6.8 merge window](https://lwn.net/Articles/958178) | NA | NA | | 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/) | NA | NA | +| 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 | 年终盘点 diff --git a/study/kernel/00-DESCRIPTION/SCHEDULER.md b/study/kernel/00-DESCRIPTION/SCHEDULER.md index 317dc6c..0da3098 100644 --- a/study/kernel/00-DESCRIPTION/SCHEDULER.md +++ b/study/kernel/00-DESCRIPTION/SCHEDULER.md @@ -502,7 +502,7 @@ RT_RUNTIME_SHARE 这个机制本身是为了解决不同 CPU 上, 以及不同 |:----:|:----:|:---:|:----:|:---------:|:----:| | 2023/06/08 | Daniel Bristot de Oliveira | [sched/deadline: Introduce deadline servers](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=63ba8422f876e32ee564ea95da9a7313b13ff0a1) | 如果具有较高优先级的任务 (例如 SCHED_FIFO) 独占 CPU, 则低优先级任务 (例如, SCHED_OTHER) 可能会出现饥饿. RT Throttling 是不久前引入的一种 (主要是调试) 对策, 可以用来为低优先级任务 (通常是后台类型的工作, 例如工作队列、计时器等) 保留一些 CPU 时间. 然而, 它也有自己的问题 (请参阅文档), 并且即使不需要运行优先级较低的活动, 也会无条件地限制 FIFO 任务, 这会产生不希望的影响 (也有一些机制可以解决这个问题, 但同样也有其自身的问题). 引入截止日期服务器, 为饥饿条件下的低优先级任务需求提供服务. 最后期限服务器是通过扩展 SCHED_Deadline 实现来构建的, 以允许两级调度 (即, deadline 实体成为低优先级调度实体的容器). | v3 ☐☑✓ v6.8-rc1 | [LORE v1,00/13](https://lore.kernel.org/all/20190726145409.947503076@infradead.org)
*-*-*-*-*-*-*-*
[LORE v2,0/6](https://lore.kernel.org/all/20200807095051.385985-1-juri.lelli@redhat.com)
*-*-*-*-*-*-*-*
[LORE v3,0/6](https://lore.kernel.org/all/cover.1686239016.git.bristot@kernel.org)
*-*-*-*-*-*-*-*
[LORE v5,0/7](https://lore.kernel.org/all/cover.1699095159.git.bristot@kernel.org)
*-*-*-*-*-*-*-*
[LORE v6,0/6](https://lore.kernel.org/all/cover.1712337227.git.bristot@kernel.org) | | 2024/03/12 | Joel Fernandes (Google) | [Fair scheduling deadline server fixes](https://lore.kernel.org/all/20240313012451.1693807-1-joel@joelfernandes.org) | 截止日期服务器 [SCHED_DEADLINE server infrastructure](https://lore.kernel.org/all/cover.1699095159.git.bristot@kernel.org) 允许 RT 任务在系统上安全运行, 而不是由于 RT 节流, 浪费了 RT 任务可能无法在空闲系统上执行的 CPU. 以下是我们在测试 ChromeOS 的截止日期服务器时发现的修补程序. 当我发现我的单元测试正在崩溃时, 它像滚雪球一样从 10 个补丁增加到 15 个补丁, 然后我们也看到了与 dl_timer 相关的领域中的一些崩溃! 所有这些都是固定的. 在其他几个修复程序中, 还有一个对核心调度的修复程序. 感谢您的全面审查. 我把所有的补丁都放在 Daniel 和 Peter 的补丁之上, 因为我会让他们把它压缩掉, 并适当地归因于贡献者. | v2 ☐☑✓ | [LORE 00/10](https://lore.kernel.org/all/20240216183108.1564958-1-joel@joelfernandes.org)
*-*-*-*-*-*-*-*
[LORE v2,0/15](https://lore.kernel.org/all/20240313012451.1693807-1-joel@joelfernandes.org) | -| 2023/06/08 | Daniel Bristot de Oliveira | [SCHED_DEADLINE server infrastructure](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=63ba8422f876e32ee564ea95da9a7313b13ff0a1) | 使用 deadline 服务器为公平任务提供服务. 此补丁集添加并使能了一个 fair_server deadline 实体, 它充当了 CFS 调度实体的容器, 可用于解决优先级较高时的饥饿问题. | v3 ☐☑✓ v6.8-rc1 | [LORE v6,0/6](https://lore.kernel.org/all/cover.1712337227.git.bristot@kernel.org)
*-*-*-*-*-*-*-*
[2024/05/27, LORE v9,0/9](https://lore.kernel.org/all/cover.1716811043.git.bristot@kernel.org) | +| 2023/06/08 | Daniel Bristot de Oliveira | [SCHED_DEADLINE server infrastructure](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=5f6bd380c7bdbe10f7b4e8ddcceed60ce0714c6d) | 使用 deadline 服务器为公平任务提供服务. 此补丁集添加并使能了一个 fair_server deadline 实体, 它充当了 CFS 调度实体的容器, 可用于解决优先级较高时的饥饿问题. | v3 ☐☑✓ v6.12-rc1 | [LORE v6,0/6](https://lore.kernel.org/all/cover.1712337227.git.bristot@kernel.org)
*-*-*-*-*-*-*-*
[2024/05/27, LORE v9,0/9](https://lore.kernel.org/all/cover.1716811043.git.bristot@kernel.org) | ## 1.4 其他一些调度类的尝试 @@ -4507,7 +4507,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) | @@ -5376,13 +5376,18 @@ CPUFreq 驱动是处理和平台相关的逻辑, Governor 中实现了具体的 #### 7.3.3.3 schedutil iowait_boost ------- + + | 时间 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----------:|:---:| | 2016/08/01 | Rafael J. Wysocki | [cpufreq / sched: cpufreq_update_util() flags and iowait boosting](https://lore.kernel.org/all/3752826.3sXAQIvcIA@vostro.rjw.lan) | TODO | v1 ☐☑✓ | [LORE v1,0/7](https://lore.kernel.org/all/3752826.3sXAQIvcIA@vostro.rjw.lan) | | 2016/09/03 | Rafael J. Wysocki | [cpufreq / sched: iowait boost in intel_pstate and schedutil](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=21ca6d2c52f8ca8638129c1dfc489d0b0ae68532) | TODO | v1 ☐☑✓ | [LORE v1,0/4](https://lore.kernel.org/all/2730042.XLMy9dAKI1@vostro.rjw.lan)
*-*-*-*-*-*-*-*
[cpufreq / sched: iowait boost in intel_pstate and schedutil](https://lore.kernel.org/all/21371892.ALJNnHKoBY@vostro.rjw.lan) | TODO | v1 ☐☑✓ v4.9-rc1 | [LORE v1,0/3](https://lore.kernel.org/all/21371892.ALJNnHKoBY@vostro.rjw.lan) | - | 2018/05/22 | Patrick Bellasi | [Fix and cleanup iowait boost](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=fd7d5287fd65df054bdade3e52ceb645cb411e72) | TODO | v4 ☐☑✓ v4.18-rc1 | [LORE v4,0/2](https://lore.kernel.org/all/20180522110754.20832-1-patrick.bellasi@arm.com) | -| 2024/03/04 | Christian Loehle | [Introduce per-task io utilization boost](https://lore.kernel.org/all/20240304201625.100619-1-christian.loehle@arm.com) | TODO | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20240304201625.100619-1-christian.loehle@arm.com) | +| 2024/03/04 | Christian Loehle | [Introduce per-task io utilization boost](https://lore.kernel.org/all/20240304201625.100619-1-christian.loehle@arm.com) | 引入每个任务的 I/O 利用率提升(io utilization boost), 以改善 Linux 内核调度器(schedutil)和英特尔 P-state(intel_pstate)驱动的 I/O 等待提升功能. | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20240304201625.100619-1-christian.loehle@arm.com) | +| 2024/09/11 | Jens Axboe | [io_uring: gate iowait schedule on having pending requests](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7b72d661f1f2f950ab8c12de7e2bc48bdac8ed69) | 问题描述: 之前的一个提交使得所有 cqring(completion queue ring) 的等待都被标记为 iowait(I/O 等待), 这是为了提高有待处理 I/O 的短时间调度的性能. 然而, 对于那些有专门的收割线程(reaper thread)只等待 ring 上的事件的使用场景, 这会导致一个核心被错误地标记为 "忙"" 且有 100% 的 iowait, 尽管实际上并没有进行 I/O 操作.
解决方案: 为了避免这种情况, 补丁提出了一种方法, 即仅当等待的任务有待处理的请求时, 才将当前任务标记为处于 iowait 状态. 这通过引入一个新的函数 current_pending_io() 来检查当前任务是否有挂起的请求, 并相应地设置 current->in_iowait 标志.
影响: 这个改动可以减少对用户的误导, 因为它更准确地反映了任务的实际状态. 对于那些使用专门的收割线程的应用, 它们不会错误地显示高 iowait, 从而更清楚地表明系统资源的使用情况. 参见 [LWN, 2024/09/10, The trouble with iowait](https://lwn.net/Articles/989272). | v1 ☐☑✓ v6.5-rc4 | [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7b72d661f1f2f950ab8c12de7e2bc48bdac8ed69) | +| 2024/08/19 | Jens Axboe | [Split iowait into two states](https://lore.kernel.org/all/20240819154259.215504-1-axboe@kernel.dk) | 参见 [LWN, 2024/09/10, The trouble with iowait](https://lwn.net/Articles/989272). | v6 ☐☑✓ | [LORE v6,0/4](https://lore.kernel.org/all/20240819154259.215504-1-axboe@kernel.dk) | +| 2024/08/19 | Jens Axboe | [Split iowait into two states](https://lore.kernel.org/all/20240819154259.215504-1-axboe@kernel.dk) | 这组补丁集将 in_iowait 分为两个状态, 以便可以分别控制它们. 第一种状态是"任务正在睡眠等待 I/O", 并希望在睡眠和唤醒延迟方面获得 cpufreq 的好处. 第二种状态是上述状态, 并且也会计入 iowait 统计数据中. 补丁 1~3 是准备补丁, 它们更改了 task_struct->nr_iowait 的类型, 并添加了帮助程序来操作 iowait 计数. 补丁 4 执行了实际的状态拆分. 参见 [LWN, 2024/09/10, The trouble with iowait](https://lwn.net/Articles/989272). | v6 ☐☑✓ | [LORE v6,0/4](https://lore.kernel.org/all/20240819154259.215504-1-axboe@kernel.dk) | +| 2024/09/05 | Christian Loehle | [cpufreq: cpuidle: Remove iowait behaviour](https://lore.kernel.org/all/20240905092645.2885200-1-christian.loehle@arm.com) | 从 Linux 内核的 cpufreq(CPU 频率调节)和 cpuidle(CPU 空闲)管理中移除基于 iowait(I/O 等待)的行为.
问题描述: 当前内核中存在一些基于 iowait 的启发式方法, 这些方法长期以来似乎难以改进. 随着 I/O 工作负载的变化, 这些启发式方法可以被移除, 而只影响基准测试. iowait 的定义本身很模糊, 它在内核代码中被广泛使用. 传统上它只用于块设备 I/O, 但内核代码中存在许多反例.
1. cpuidle 问题: 在 cpuidle 管理器中, 使用 iowait 任务的数量来确定 CPU 的交互性需求. 依赖于 iowait 进行 cpuidle 管理存在多个问题, 包括: 没有保证 iowait 任务会在相同的 CPU 上被唤醒. iowait 状态并不能说明空闲持续时间. iowait 状态并不总是意味着性能会受到延迟增加的影响.
2. cpufreq 问题: cpufreq 管理器长期以来基于 iowait 行为进行调节, 但这种方法存在问题, 如: 对于异步或多线程 I/O, 假设因为设备空闲而错过了块设备吞吐量是不正确的, 假设等待 I/O 的任务将来会发送 I/O 请求.
性能影响: 补丁系列提供了在不同平台上, 使用带和不带 iowait 提升的调度实用程序(schedutil)进行的性能测试结果. 测试表明, 大多数真实世界的 I/O 工作负载不会受到 io 利用率问题的影响. 参见 [LWN, 2024/09/10, The trouble with iowait](https://lwn.net/Articles/989272). | v1 ☐☑✓ | [LORE v1,0/8](https://lore.kernel.org/all/20240905092645.2885200-1-christian.loehle@arm.com) | @@ -5891,7 +5896,7 @@ CPU 的周期性调度, 和基于时间片的调度, 是要基于时钟中断来 然而, 对于调度时间粒度为微秒 (10^-6) 级别的精度来说, 这每秒 1000 次的粒度就显得太粗糙了． -2.6.25 引入了所谓的 ** 高清嘀哒 (High Resolution Tick)**, 以提供更精确的调度时钟中断．这个功能是基于 ** 高精度时钟 (High Resolution Timer) 框架 **, 这个框架让内核支持可以提供纳秒级别的精度的硬件时钟 (将会在时钟子系统里讲). +2.6.25 引入了所谓的 **高清嘀哒 (High Resolution Tick)**, 以提供更精确的调度时钟中断．这个功能是基于 **高精度时钟 (High Resolution Timer) 框架**, 这个框架让内核支持可以提供纳秒级别的精度的硬件时钟 (将会在时钟子系统里讲). ## 8.6 混乱的 RT 优先级 (RT 进程优先级管控) @@ -5975,6 +5980,7 @@ PREEMPT-RT PATCH 的核心思想是最小化内核中不可抢占部分的代码 | 2019/07/17 | Thomas Gleixner | [Kconfig: Introduce CONFIG_PREEMPT_RT](https://lore.kernel.org/all/alpine.DEB.2.21.1907172200190.1778@nanos.tec.linutronix.de) | 在抢占菜单中添加一个新条目 PREEMPT_RT, 以支持内核的实时支持. 该选项仅在体系结构支持时启用. 它选择抢占, 因为 RT 特性依赖于它. 为了实现将现有的 PREEMPT 选项重命名为 `PREEMPT_LL`, 该选项也会选择 PREEMPT. 没有功能上的改变. | v2 ☐☑✓ | [LORE v2,0/1](https://lore.kernel.org/all/alpine.DEB.2.21.1907172200190.1778@nanos.tec.linutronix.de) | | 2019/7/15 | Thomas Gleixner | [locking, sched: The PREEMPT-RT locking infrastructure](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=026659b9774e4c586baeb457557fcfc4e0ad144b) | PREEMPT_RT 的基础支持, 完成了锁语义的转换. 在支持 PREEMPT-RT 的内核中, 以下锁被基于 RT Mutex 的变体替换: mutex, ww_mutex, rw_semaphore, spinlock, rwlock. 但是 semaphores 没有被修改, 因为它并不严格提供 owner 的语义. raw_spinlocks 也没有被修改, 因为它被用在保护调度器、定时器和硬件访问中的低级别操作中. | v1 ☑ 5.3-rc1 | [LORE v5,00/72](https://lore.kernel.org/all/20210815203225.710392609@linutronix.de)
*-*-*-*-*-*-*-*
[LKML](https://lkml.org/lkml/2019/7/15/1386) | | 2022/12/19 | Krzysztof Kozlowski | [PM: Fixes for Realtime systems](https://lore.kernel.org/all/20221219151503.385816-1-krzysztof.kozlowski@linaro.org) | TODO | v2 ☐☑✓ | [LORE v2,0/5](https://lore.kernel.org/all/20221219151503.385816-1-krzysztof.kozlowski@linaro.org) | +| 2024/09/06 | Sebastian Andrzej Siewior | [Allow to enable PREEMPT_RT.](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=2638e4e6b18233d7ec54edb953f253ae9515bac2) | 允许在 x86、ARM64 和 RISC-V 架构上启用 PREEMPT_RT 选项. PREEMPT_RT 功能仅剩的最后一个障碍是围绕[非阻塞控制台/原子控制台支持](https://www.phoronix.com/news/Printk-Rework-v2-Linux) 的, 这项工作也已经计划合入 v6.12 了, 因此 PREEMPT_RT 可以正常打开了. 参见 [phoronix, 2024/09/06, Linux Very Close To Enabling Real-Time "PREEMPT_RT" Support](https://www.phoronix.com/news/Linux-PREEMPT_RT-Close-Patches) 和 [LWN, 2024/09/06, The realtime preemption end game — for real this time](https://lwn.net/Articles/989212), [phoronix, 2024/09/20, Real-Time "PREEMPT_RT" Support Merged For Linux 6.12](https://www.phoronix.com/news/Linux-6.12-Does-Real-Time). | v1 ☐☑✓ v6.12-rc1 | [LORE v1,0/3](https://lore.kernel.org/all/20240906111841.562402-1-bigeasy@linutronix.de) | ### 8.7.1 Migrate disable support && kmap_local @@ -6721,7 +6727,7 @@ Linux [v5.1-rc1](https://kernelnewbies.org/Linux_5.1#Safe_signal_delivery_in_pre 4. 最后 server 从内核态返回到用户态, 这个过程伴随着内核栈到用户态栈的切换. -而 IOS 的 IPC 则通过 Continuation 实现了 stack handoff 机制, 降低了 IPC 的单次开销. +而 IOS 的 IPC 则通过 Continuation 实现了 stack handoff 机制, 降低了 IPC 的单次开销. 参见 [Advanced Synchronization in Mac OS X: Extending Unix to SMP and Real-Time](https://www.usenix.org/legacy/publications/library/proceedings/bsdcon02/full_papers/gerbarg/gerbarg_html/index.html). 1. client 通过系统调用进入内核, 内核栈切换成 client 的内核栈. @@ -6891,7 +6897,8 @@ Roman Gushchin 在邮件列表发起了 BPF 对调度器的潜在应用的讨论 作者在 [github--sched-ext/scx](https://github.com/sched-ext/scx)提供了 sched_ext 的工具集和开发套件, 并提供了一些基于 c/rust 的用户态调度程序. 以及一个用户态服务用来管理这些用户态调度程序. 参见 LWN 报道 [Improving performance with SCHED_EXT and IOCost](https://lwn.net/Articles/966618). -2024 年 01 月, Ubuntu/Canonical 的工程师 Andrea Righi, 在 X(Twitter) 上发文谈到, 他利用圣诞假期通过 sched_ext 实现并基于 eBPF 技术、能够在运行时加载的 Rust 调度器具有很大的潜力和希望. 在某些负载(例如游戏)下性能甚至可以超越 Linux 内核默认的 EEVDF 调度器. [Righi: Writing a scheduler for Linux in Rust that runs in user-space](https://arighi.blogspot.com/2024/02/writing-scheduler-for-linux-in-rust.html), 参见 LWN 报道 [Righi: Writing a scheduler for Linux in Rust that runs in user-space](https://lwn.net/Articles/962897), phoronix 的报道 [Rust-Written Linux Scheduler Showing Promising Results For Gaming Performance](https://www.phoronix.com/news/Rust-Linux-Scheduler-Experiment) 和 [Ubuntu Blog Talks Up Rust Schedulers, Potential For Micro-Kernel Design Future](https://www.phoronix.com/news/Ubuntu-Rust-Scheduler-Micro), 以及 Ubuntu blog [Crafting new Linux schedulers with sched-ext, Rust and Ubuntu](https://ubuntu.com//blog/crafting-new-linux-schedulers-with-sched-ext-rust-and-ubuntu). +2024 年 01 月, Ubuntu/Canonical 的工程师 Andrea Righi, 在 X(Twitter) 上发文谈到, 他利用圣诞假期通过 sched_ext 实现了能够在运行时加载的 Rust 调度器 scx_rustland, 他在自己的博客中展示了这个调度器的巨大潜力和希望, 在某些负载(例如游戏)下性能甚至可以超越 Linux 内核默认的 EEVDF 调度器. [Righi: Writing a scheduler for Linux in Rust that runs in user-space](https://arighi.blogspot.com/2024/02/writing-scheduler-for-linux-in-rust.html), 参见 LWN 报道 [Righi: Writing a scheduler for Linux in Rust that runs in user-space](https://lwn.net/Articles/962897), phoronix 的报道 [Rust-Written Linux Scheduler Showing Promising Results For Gaming Performance](https://www.phoronix.com/news/Rust-Linux-Scheduler-Experiment) 和 [Ubuntu Blog Talks Up Rust Schedulers, Potential For Micro-Kernel Design Future](https://www.phoronix.com/news/Ubuntu-Rust-Scheduler-Micro), 以及 Ubuntu blog [Crafting new Linux schedulers with sched-ext, Rust and Ubuntu](https://ubuntu.com//blog/crafting-new-linux-schedulers-with-sched-ext-rust-and-ubuntu). scx_rustland 调度器的瓶颈是内核和用户空间之间通信的开销. 为了解决这个问题, 同年 8 月份, Andrea Righi 在 eBPF 中完全实现了 scx_rustland, 讲新的调度器命名为 scx_bpfland. scx_bpfland 调度器采用与 scx_rustland 相同的逻辑, 但没有内核/用户空间的通信开销. Andrea 已经运行了一些基准测试, 新的 bpfland 代码显示出非常有希望的结果. PostgreSQL 快 30~39%, FFmpeg 快几个百分点, nginx 快 8% 左右, 等等. 参见 [phoronix, 2024/08/10, Reimplementing A Linux Rust Scheduler In eBPF Shows Very Promising Results](https://www.phoronix.com/news/Linux-Rust-Sched-To-eBPF) 以及作者博客 [blog, 2024/08/10, Reimplementing my Linux Rust Scheduler In eBPF](https://arighi.blogspot.com/2024/08/re-implementing-my-linux-rust-scheduler.html). +. Changwoo Min 和 Igalia 昨天在北美开源峰会上发表了关于为 Linux 游戏优化内核调度器的演讲, [Optimizing Scheduler for Linux Gaming - Changwoo Min, Igalia](https://ossna2024.sched.com/event/1aBOT/optimizing-scheduler-for-linux-gaming-changwoo-min-igalia?iframe=no&w=100%&sidebar=yes&bg=no), 提出延迟关键感知虚拟截止时间(LAVD) 调度器. 这个[使用 Rust 基于 sched_ext 编写](https://crates.io/crates/scx_lavd/versions)的基于截止日期的调度器已经显示出可喜的结果. 在 Igalia 在基于 Linux 6.9-rc1的内核上进行的测试中, LAVD调度器在平均FPS和1%的低帧速率下都显示出与EEVDF更好或相似的性能. 参见 phoronix 报道 [Rust-Written LAVD Kernel Scheduler Shows Promising Results For Linux Gaming](https://www.phoronix.com/news/LAVD-Scheduler-Linux-Gaming). @@ -6903,19 +6910,38 @@ LSFMMBPF 2024 上对 sched_ext 进行了讨论 [LWN, 2024/05/23, LSFMMBPF-2024, 尽管其他内核开发人员也提出了一些反对意见, 但是 Linus Torvalds 作为 Linux 内核的终身 "BDFL"(仁慈的独裁者), 认为 sched_ext V6 的代码已经准备好了, 在 Linux 内核主线更能体现其价值, 不应该拖延 sched_ext 的合入. 因此 Linus Torvalds 在邮件列表 [Re: [PATCHSET v6] sched: Implement BPF extensible scheduler class](https://lore.kernel.org/lkml/CAHk-=wg8APE61e5Ddq5mwH55Eh0ZLDV4Tr+c6_gFS7g2AxnuHQ@mail.gmail.com) 宣布他打算合并 Linux 6.11 的 sched_ext 补丁. 参见 phoronix 报道 [phoronix, 2024/06/11, Linus Torvalds Throws Down The Hammer: Extensible Scheduler "sched_ext" In Linux 6.11](https://www.phoronix.com/news/Linux-6.11-Extensible-Scheduler) 和 LWN 报道 [LWN, 2024/06/11, Extensible scheduler class to be merged for 6.11](https://lwn.net/Articles/978007) 以及 [Linus 强势拍板合入: BPF 赋能调度器终成正果](https://mp.weixin.qq.com/s/dWPWuDtxQBM9Z_GXwKe0kQ). -因此, 按照要求, 早在 2024/07/15, Linux 6.11 合并窗口一打开, Tejun Heo 就提交了 sched_ext 的 Pull Request [sched_ext: Initial pull request for v6.11](https://lore.kernel.org/lkml/ZpWjbCQPtuUcvo8r@slm.duckdns.org/). sched_ext 已经演变成近 14k 行新代码, 包括测试和相关基础设施. 但是 Reviewer 指出不少代码需要改进, Qais Yousef 更是提出了一些担忧, 因此最终 6.11-rc1 发布的时候, sched_ext 并没有被合并. 参见 [phoronix, 2024/07/28, Linus Torvalds Doesn't Merge sched_ext For The Linux 6.11 Merge Window](https://www.phoronix.com/news/Linux-6.11-No-sched_ext). +按照要求, 早在 2024/07/15, Linux 6.11 合并窗口一打开, Tejun Heo 就提交了 sched_ext 的 Pull Request [sched_ext: Initial pull request for v6.11](https://lore.kernel.org/lkml/ZpWjbCQPtuUcvo8r@slm.duckdns.org/). sched_ext 已经演变成近 14k 行新代码, 包括测试和相关基础设施. 但是 Reviewer 指出不少代码需要改进, Qais Yousef 更是提出了一些担忧, 因此因为种种技术问题, 最终 6.11-rc1 发布的时候, sched_ext 并没有被合并. 参见 [phoronix, 2024/07/28, Linus Torvalds Doesn't Merge sched_ext For The Linux 6.11 Merge Window](https://www.phoronix.com/news/Linux-6.11-No-sched_ext). + +虽然 v6.11 没有合入 sched_ext, 但是社区关于 sched_ext 的讨论却持续高涨, 邮件列表中一直在讨论如何解决已有的问题, 以便 sched_ext 在即将到来的内核周期中进行合并. 由此产生的工作包括 Peter Zijlstra 的新内核补丁系列, 以更好地为sched_ext做准备. 参见 [phoronix, 2024/08/14, New Linux Kernel Patches Better Prepare For sched_ext](https://www.phoronix.com/news/Linux-sched_ext-Prep) 以及 [phoronix, 2024/08/18, It's Looking Like sched_ext Will Try Again To Land For Linux 6.12](https://www.phoronix.com/news/sched_ext-Ahead-Of-Linux-6.12). + +越来越多的发行版主动将 sched_ext 合入自己的版本中, [phoronix, 2024/10/03, Fedora's Kernel Build Now Enabling Sched_Ext Support](https://www.phoronix.com/news/Fedora-Enables-Sched_Ext). + +最终 sched_ext 于 v6.12 合入主线, 参见 [Merge tag 'sched_ext-for-6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=88264981f2082248e892a706b2c5004650faac54). 参见 [phoronix, 2024/09/21, Sched_ext Merged For Linux 6.12 - Scheduling Policies As BPF Programs](https://www.phoronix.com/news/Linux-6.12-Lands-sched-ext) 和 [phoronix, 2024/09/21, Oracle's UEK-Next Moves To Linux 6.10, Patches In sched_ext](https://www.phoronix.com/news/Oracle-UEK-Next-Linux-6.10) + +在 LPC 2024, 不断增长和活跃的 sched_ext 社区举行了第一次分会 [Sched-Ext: The BPF extensible scheduler class MC](https://lpc.events/event/18/sessions/192/#20240918); sched_ext 在 Scheduler 中掀起了新的创新设计. 参见 [LWN, 20240926, Sched_ext at LPC 2024](https://lwn.net/Articles/991205). Sched_ext 消除了调度程序开发领域的许多进入壁垒, 这将使越来越多的开发人员尝试自己的想法, 并在社区贡献他们感兴趣的发展方向. 一个新的社区正在迅速形成, 它似乎很可能会想出一些新颖的(有时是疯狂的)CPU 调度方法. 这将是未来几年值得关注的有趣领域. + | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2021/09/15 | Roman Gushchin | [Scheduler BPF](https://www.phoronix.com/scan.php?page=news_item&px=Linux-BPF-Scheduler) | NA | RFC ☐ | [PatchWork rfc,0/6](https://patchwork.kernel.org/project/netdevbpf/cover/20210916162451.709260-1-guro@fb.com)
*-*-*-*-*-*-*-*
[LPC 2021](https://linuxplumbersconf.org/event/11/contributions/954)
*-*-*-*-*-*-*-*
[LKML](https://lkml.org/lkml/2021/9/16/1049), [LWN](https://lwn.net/Articles/869433), [LWN](https://lwn.net/Articles/873244) | -| 2022/11/29 | Tejun Heo | [sched: Implement BPF extensible scheduler class](https://lore.kernel.org/all/20221130082313.3241517-1-tj@kernel.org) | 随后 FaceBook 进一步扩展, 引入 sched_ext 模块, 使用 eBPF 对调度器进行可编程重构. [Experimental Patches Allow eBPF To Extend The Linux Kernel's Scheduler](https://www.phoronix.com/news/RFC-eBPF-Linux-Scheduler), [The BPF extensible scheduler class](https://lwn.net/Articles/916291), [The extensible scheduler class](https://lwn.net/Articles/922405/), [Patches Updated For Hooking eBPF Programs Into The Linux Kernel Scheduler](https://www.phoronix.com/news/Linux-Scheduler-eBPF-v2-sched). 以及 [Extensible scheduler class rejected](https://lwn.net/Articles/939332) | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20221130082313.3241517-1-tj@kernel.org)
*-*-*-*-*-*-*-*
[LORE v2,00/30](https://lore.kernel.org/lkml/20230128001639.3510083-1-tj@kernel.org)
*-*-*-*-*-*-*-*
[2023/11/11, LORE v5](https://lore.kernel.org/all/20231111024835.2164816-1-tj@kernel.org)
*-*-*-*-*-*-*-*
[2024/05/11, LORE v6,00/39](https://lore.kernel.org/all/20240501151312.635565-1-tj@kernel.org)
*-*-*-*-*-*-*-*
[2024/06/18, LORE v7,00/30](https://lore.kernel.org/all/20240618212056.2833381-1-tj@kernel.org) | +| 2022/11/29 | Tejun Heo | [sched: Implement BPF extensible scheduler class](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=513ed0c7ccc103c2ff668154854ec410729a3170) | 随后 FaceBook 进一步扩展, 引入 sched_ext 模块, 使用 eBPF 对调度器进行可编程重构. [Experimental Patches Allow eBPF To Extend The Linux Kernel's Scheduler](https://www.phoronix.com/news/RFC-eBPF-Linux-Scheduler), [The BPF extensible scheduler class](https://lwn.net/Articles/916291), [The extensible scheduler class](https://lwn.net/Articles/922405/), [Patches Updated For Hooking eBPF Programs Into The Linux Kernel Scheduler](https://www.phoronix.com/news/Linux-Scheduler-eBPF-v2-sched). 以及 [Extensible scheduler class rejected](https://lwn.net/Articles/939332) | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20221130082313.3241517-1-tj@kernel.org)
*-*-*-*-*-*-*-*
[LORE v2,00/30](https://lore.kernel.org/lkml/20230128001639.3510083-1-tj@kernel.org)
*-*-*-*-*-*-*-*
[2023/11/11, LORE v5](https://lore.kernel.org/all/20231111024835.2164816-1-tj@kernel.org)
*-*-*-*-*-*-*-*
[2024/05/11, LORE v6,00/39](https://lore.kernel.org/all/20240501151312.635565-1-tj@kernel.org)
*-*-*-*-*-*-*-*
[2024/06/18, LORE v7,00/30](https://lore.kernel.org/all/20240618212056.2833381-1-tj@kernel.org) | | 2024/07/08 | Hongyan Xia | [sched/ext: Add BPF function to fetch rq](https://lore.kernel.org/all/7359b5cd17d56837bc15f4883b21837163c51d37.1720441953.git.hongyan.xia2@arm.com) | rq 包含许多有用的字段, 可用于执行自定义调度程序. 例如, 可以使用各种时钟信号(如 clock_task 和 clock_pelt)来跟踪负载. 它还包含其他 sched_classes 中的统计信息, 这些信息对于在 ext 中驱动调度决策非常有用. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/7359b5cd17d56837bc15f4883b21837163c51d37.1720441953.git.hongyan.xia2@arm.com) | | 2024/06/18 | Tejun Heo | [sched_ext: Integrate with schedutil](https://lore.kernel.org/all/20240619031250.2936087-1-tj@kernel.org) | sched_ext 目前没有与 schedutil 集成. 当 schedutil 作为调频 GOVERNOR 时, 频率不受控制. 本补丁集将 sched_ext 与 schedutil 集成, 以便 BPF 调度程序 调度器时可以控制 CPU 频率. 实现 sugov_get_util() 更新, 以添加 BPF 调度器提供的利用率. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240619031250.2936087-1-tj@kernel.org) | -| 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/07/10 | K Prateek Nayak | [sched/core: Fixes and enhancements around spurious need_resched() and idle load balancing](https://lore.kernel.org/all/20240710090210.41856-1-kprateek.nayak@amd.com) | TODO | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20240710090210.41856-1-kprateek.nayak@amd.com) | | 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/14 | Peter Zijlstra | [sched: Prepare for sched_ext](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=b2d70222dbf2a2ff7a972a685d249a5d75afa87f) | 为了适应 sched_ext 的需求, 这个补丁集进行了一些必要的重构
1. 重新排列了公平的 pick_task() 函数, 使它们的状态不变, 以便在选择 (和取消排队/出队) 延迟任务后可以轻松重新启动.2. 它需要在上下文切换时拥有下一个任务的最终回调, 以便判断切换是否会离开调度类 (sched_class). [sched: Use set_next_task(.first) where required](https://lore.kernel.org/lkml/20240813224015.614146342@infradead.org/)

3. 调整 put_prev_task() 的位置: 将 (最终)put_prev_task() 推到 pick_task() 之后. 这样在最终的回调中可以确保拥有下一个任务. [sched: Rework pick_next_task()](https://lore.kernel.org/lkml/20240813224016.051225657@infradead.org). 参见 [phoronix, 2024/08/14, New Linux Kernel Patches Better Prepare For sched_ext](https://www.phoronix.com/news/Linux-sched_ext-Prep) | v1 ☐☑✓ v6.12-rc1 | [LORE v1,0/9](https://lore.kernel.org/all/20240813222548.049744955@infradead.org) | +| 2024/08/26 | Tejun Heo | [sched_ext: Add cgroup support](https://lore.kernel.org/all/20240826225822.791578-1-tj@kernel.org) | TODO | v2 ☐☑✓ | [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/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) | + #### 11.2.2.2 Google 的 ghOSt diff --git a/study/kernel/00-DESCRIPTION/TEST.md b/study/kernel/00-DESCRIPTION/TEST.md new file mode 100644 index 0000000..789e3ef --- /dev/null +++ b/study/kernel/00-DESCRIPTION/TEST.md @@ -0,0 +1,35 @@ +这个补丁是由 Athira Rajeev 提交的, 标题为 "[PATCH V8 00/15] Add data type profiling support for powerpc". 这个补丁集(总共包含15个补丁)的主要目的是为 PowerPC 架构添加数据类型剖析(data type profiling)的支持. + +补丁集背景 +在补丁集中提到, 之前由 Namhyung Kim 提交的一系列补丁已经为 perf 工具引入了数据类型剖析的基本支持. 这些补丁使 perf 能够关联性能监控单元(PMU)的样本到它们所引用的数据类型, 利用 DWARF 调试信息来实现这一点. 目前, 这种支持已经在 x86 架构上可用, 可以通过 perf report 或 perf annotate 命令来查看数据类型信息. + +补丁集内容 +Athira Rajeev 的补丁集旨在为 PowerPC 架构添加类似的支持. 以下是该补丁集的主要更改点: + +PowerPC 指令表更新: 添加了一个 PowerPC 指令助记符表, 用于将负载/存储指令与移动操作关联起来, 从而识别指令是否涉及内存访问. +获取寄存器编号和偏移量: 为了从给定的指令中获取寄存器编号和访问偏移量, 代码使用了 struct arch 中的 objump 字段. 为 PowerPC 添加了相应的条目. +获取寄存器编号函数: 实现了一个 get_arch_regnum 函数, 可以从寄存器名称字符串中返回寄存器编号. +解析原始指令 +为了更准确地解析 PowerPC 指令, 补丁集采取了以下步骤: + +使用原始指令: 补丁集支持直接使用原始指令而非解析后的指令名称. 这样可以通过宏来提取指令的操作码和寄存器字段. +示例: 例如, 使用 --show-raw-insn 选项时, objdump 会给出原始指令的十六进制表示, 如 "38 01 81 e8", 这对应于 "ld r4,312(r1)" 指令. +避免重复使用 objdump: 补丁集避免了重复使用 objdump 来读取原始指令, 而是直接从动态共享对象 (DSO) 中读取二进制代码. +具体补丁概述 +Patch 4: 添加了支持捕捉和解析 PowerPC 原始指令的功能, 使用 dso__data_read_offset 实用程序. +Patch 5: 添加了 disasm_line__parse 函数来解析 PowerPC 的原始指令. +Patch 6: 更新了寄存器提取函数的参数, 以支持 PowerPC 上的原始指令. +Patch 7: 更新了 ins__find 函数来携带原始指令, 并为 PowerPC 添加了内存指令的解析回调. +Patch 8: 支持识别具有操作码 31 的 PowerPC 内存指令. +Patch 9: 添加更多指令来支持 PowerPC 上的指令跟踪. +Patch 10 和 11: 处理 PowerPC 上的指令跟踪. +Patch 12、13 和 14: 添加支持使用 libcapstone 库在 PowerPC 上解析指令. +Patch 15: 处理 perf annotate 的 insn-stat 选项. +测试结果 +补丁集作者提供了测试结果, 其中展示了使用 perf annotate --data-type --insn-stat 命令的结果. 结果显示有大约 43.7% 的指令被正确解析, 而 56.3% 的指令未能成功解析. 作者指出还有大约 25% 的未知指令没有得到处理. + +后续计划 +作者提到这个补丁集还没有在 PowerPC32 架构上进行过测试. 下一步的增强计划包括处理剩余的未知指令, 并覆盖 PowerPC32 的变化, 具体取决于测试的结果. 此外, 关于全局寄存器的支持将会在解决完 Namhyung Kim 的评论后发布后续补丁. + +总结 +这个补丁集为 PowerPC 架构添加了数据类型剖析的支持, 并且引入了一系列技术来更准确地解析 PowerPC 指令, 以便更好地理解内存访问行为. diff --git a/study/kernel/00-DESCRIPTION/TODO.md b/study/kernel/00-DESCRIPTION/TODO.md index 475dd7a..b99ba3f 100644 --- a/study/kernel/00-DESCRIPTION/TODO.md +++ b/study/kernel/00-DESCRIPTION/TODO.md @@ -661,6 +661,8 @@ cba6167f0adb [A capability set for user namespaces](https://lwn.net/Articles/978846) [A look inside the BPF verifier](https://lwn.net/Articles/982077) [CRIB: checkpoint/restore in BPF](https://lwn.net/Articles/984313) +[Modernizing BPF for the next 10 years](https://lwn.net/Articles/977013/) +[HIVE: A Hardware-assisted Isolated Execution Environment for eBPF on AArch64](https://www.usenix.org/conference/usenixsecurity24/presentation/zhang-peihua) [Direct-to-device networking](https://lwn.net/Articles/979549) @@ -764,10 +766,31 @@ HUAWEI P10 Plus, Vicky, Android 7.0, EMUI 5.1 - [New Power Sequencing Driver Subsystem Merged For Linux 6.11](https://www.phoronix.com/news/Linux-6.11-Power-Sequencing) -这个补丁系列是关于为 Rust 语言在 Linux 内核中添加通用的内核分配器(Allocator)支持. 以下是补丁系列的主要变更和目的:
1. 添加通用内核分配器支持: 目前主线上, Rust 在 Linux 内核中的内存分配仅限于 kmalloc. 这个补丁系列扩展了这一功能, 允许使用更多的内存分配器以及分配策略.
2. 自定义 Allocator trait: 为了避免向内核添加不稳定的 Rust 特性, 补丁系列没有扩展 Rust 的 alloc crate 中的 Allocator trait, 也没有扩展 BoxExt 和 VecExt 扩展. 而是引入了特定的 Allocator trait, 并由 Kmalloc、Vmalloc 和 KVmalloc 分配器实现, 这些分配器也是在这个系列中实现的. 为了使用新的分配器, 补丁系列添加了自定义的 `Box` 和 `Vec`` 类型(其中 A 是特定的分配器), 这些类型依赖于特定的分配器.
3. 移除对 alloc crate 的依赖: 通过这个系列的更改, 内核构建完全移除了对 Rust 的 alloc crate 的依赖. -定义内核专用类型: 定义了内核专用的 Box 和 Vec 类型, . \ No newline at end of file + + + + +[Ghidra Software Reverse Engineering Framework](https://github.com/NationalSecurityAgency/ghidra) + + + +| 2024/08/26 | NeilBrown | [block: change wait on bd_claiming to use a var_waitqueue, not a bit_waitqueue](https://lore.kernel.org/all/20240826063659.15327-2-neilb@suse.de) | TODO | v1 ☐☑✓ | [LORE v1,0/7](https://lore.kernel.org/all/20240826063659.15327-2-neilb@suse.de) | + + + +https://lore.kernel.org/all/20240830130309.2141697-1-vincent.guittot@linaro.org/ + + + +[](https://www.phoronix.com/news/AMD-Linux-Hetero-Max-Detect) + + +| 编号 | 调度器 | 语言 | 用途 | +|:---:|:-----:|:----:|:---:| +| 1 | scx_lavd | 程序专注于交互性, 具体来说, 就是始终如一地从游戏中获得更高的帧速率. | +| 2 | scx_rustland | RUST | 将调度事件转发到用户空间, 在那里做出决策. 还包含 scx_rusty 用于复杂 CPU 拓扑上的负载平衡, 以及, 一个 scx_layered 分区计划程序. | +| 3 | diff --git a/study/kernel/00-DESCRIPTION/run.sh b/study/kernel/00-DESCRIPTION/run.sh new file mode 100644 index 0000000..04f9f21 --- /dev/null +++ b/study/kernel/00-DESCRIPTION/run.sh @@ -0,0 +1,8 @@ +#!/bin/bash + +sed -i 's/（/(/g' ./$1 +sed -i 's/）/)/g' ./$1 +sed -i 's/，/, /g' ./$1 +sed -i 's/。/. /g' ./$1 +sed -i 's/：/: /g' ./$1 +sed -i 's/；/; /g' ./$1