description/open_source: update phoronix vs LWN to date 20241101

2026-08-18 00:58:21 +08:00 · 2024-12-08 17:48:29 +08:00
parent bf4e1988d9
commit 3e71b3767c
9 changed files with 153 additions and 27 deletions
@@ -167,6 +167,8 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad

 [29 种本地部署大模型和调用的工具平台分类与总结](https://blog.csdn.net/l35633/article/details/138379452)

+[phoronix, 2024/12/07, Llamafile 0.8.17 Brings New Web UI For This Easy-To-Distribute AI LLM Framework](https://www.phoronix.com/news/Llamafile-7-Released)
+
 | 编号 | 推理框架 | 团队 | 介绍 |
 |:---:|:-------:|:---:|:---:|
 | 1 | [vLLM](https://github.com/vllm-project/vllm) | UC Berkeley | vLLM 是一个开源的大模型推理加速框架, 通过 PagedAttention 高效地管理 attention 中缓存的张量, 实现了比 HuggingFace Transformers 高 14-24 倍的吞吐量. PagedAttention 是 vLLM 的核心技术, 它解决了 LLM 服务中内存的瓶颈问题. 传统的注意力算法在自回归解码过程中, 需要将所有输入 Token 的注意力键和值张量存储在 GPU 内存中, 以生成下一个 Token. 这些缓存的键和值张量通常被称为 KV 缓存. [vLLM(二) 架构概览](https://zhuanlan.zhihu.com/p/681716326) |
@@ -190,8 +192,19 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad



+### 4.2.1 KV Cache 压缩
+-------

+[SnapKV: LLM在生成内容之前就知道您在寻找什么](https://blog.csdn.net/qq_36931982/article/details/139118015)

+[MiniCache 和 PyramidInfer 等 6 种优化 LLM KV Cache 的最新工作](https://www.51cto.com/aigc/913.html)
+
+[PyramidKV学习资料汇总 - 动态KV缓存压缩技术](https://blog.csdn.net/m0_56734068/article/details/142382328)
+
+[大模型推理加速：KV Cache Sparsity(稀疏化)方法](https://zhuanlan.zhihu.com/p/701580870)
+
+[聊聊大模型推理中的 KVCache 之异构缓存](https://zhuanlan.zhihu.com/p/714288577)
+[聊聊大模型推理中的 KVCache 压缩](https://zhuanlan.zhihu.com/p/708946312)


 # 5 分析工具
@@ -202,7 +215,7 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad
 |  1  | [Interactive Tools for machine learning, deep learning, and math](https://github.com/Machine-Learning-Tokyo/Interactive_Tools) | 用于机器学习、深度学习和数学运算的交互式工具. |
 |  2  | [Visual Guides to understand the basics of Large Language Models](https://towardsdatascience.com/visual-guides-to-understand-the-basics-of-large-language-models-0715701bdd20) | 一系列工具与文章的汇编, 直观易懂地解读复杂的 AI 概念. 译文 [深入浅出：大语言模型的视觉解析 [译]](https://baoyu.io/translations/llm/visual-guides-to-understand-the-basics-of-large-language-models). |

-## 5.1  Tokenizer
+## 5.1 Tokenizer
 -------

 ### 5.1.1 Token 计算器
@@ -294,8 +307,9 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad
 | 2024/01/16 | 多模态 | [A Survey of Resource-efficient LLM and Multimodal Foundation Models](https://arxiv.org/abs/2401.08092) | Mengwei Xu | [UbiquitousLearning](https://github.com/UbiquitousLearning/Efficient_Foundation_Model_Survey) | 一篇关于资源高效的大模型和多模态基础模型的综述论文. 论文涵盖了算法和系统两个方面的创新, 包括了高校的模型架构, 训练算法, 推理算法和模型压缩等内容. |
 | 2024/04/18 | 效率提升 | [The Efficiency Spectrum of Large Language Models: An Algorithmic Survey](https://arxiv.org/abs/2312.00678) | Tianyu Ding | [tding1](https://github.com/tding1/Efficient-LLM-Survey) | 一篇关于提供大语言模型效率的综合性调查论文, 全面回顾了旨在提高 LLM 效率的算法, 涵盖了扩展定律, 数据利用, 架构创新, 训练和调优策略以及推理计划等. |
 | 2024/05/23 | LLMs | [Efficient Large Language Models: A Survey](https://arxiv.org/abs/2312.03863) | Zhongwei Wan | [AIoT-MLSys-Lab](https://github.com/AIoT-MLSys-Lab/Efficient-LLMs-Survey) | 本文对高效 LLMs 研究的发展进行了系统而全面的回顾, 并将文献整理成由三个主要类别组成的分类法, 从模型中心、数据中心和框架中心的角度涵盖了不同但相互关联的高效 LLMs 主题, 并且从以模型为中心和以数据为中心的角度, 回顾了 LLMs 的算法层面和系统层面的高效技术. 详细介绍了每个分类下的具体技术, 如: 量化, 剪枝, 知识蒸馏, 数据选择, 提示工程等<br>1. [知乎--黄浴--高效大语言模型：综述](https://zhuanlan.zhihu.com/p/671710012)<br>2. [知乎--磐石--大模型高效推理 I 推理技术框架总结](https://zhuanlan.zhihu.com/p/696850285)<br>3. [知乎--享享学AI--大模型LLM微调技术方法汇总！](https://zhuanlan.zhihu.com/p/673675939) |
-| [A Survey on Efficient Inference for Large Language Models](https://arxiv.org/abs/2404.14294) | NA | []() | 1. [如何加速大模型推理？万字综述全面解析大语言模型高效推理技术 ](https://www.sohu.com/a/790365299_121119001)<br>2. [知乎--罗清雨--大语言模型高效推理综述](https://zhuanlan.zhihu.com/p/707685591)
-[Comprehensive Study on Performance Evaluation and Optimization of Model Compression: Bridging Traditional Deep Learning and Large Language Models](https://arxiv.org/abs/2407.15904)
+| 2024/04/22 | 综述 | [A Survey on Efficient Inference for Large Language Models](https://arxiv.org/abs/2404.14294) | Zixuan Zhou | 1. [如何加速大模型推理？万字综述全面解析大语言模型高效推理技术 ](https://www.sohu.com/a/790365299_121119001)<br>2. [知乎--罗清雨--大语言模型高效推理综述](https://zhuanlan.zhihu.com/p/707685591) |
+| 2023/06/23 | 多模态 | [A Survey on Multimodal Large Language Models](https://arxiv.org/abs/2306.13549) | Shukang Yin | [BradyFU](https://github.com/BradyFU/Awesome-Multimodal-Large-Language-Models) | 本综述中主要介绍了多模态幻觉、多模态上下文学习(Multimodal InContext Learning，M-ICL)、多模态思维链(Multimodal Chain of Thought，M-CoT)和 LLM 辅助的视觉推理(LLM-Aided Visual Reasoning，LAVR)等. |
+| 2024/07/26 | [Comprehensive Study on Performance Evaluation and Optimization of Model Compression: Bridging Traditional Deep Learning and Large Language Models](https://arxiv.org/abs/2407.15904) | Aayush Saxena |
 [Mobile Edge Intelligence for Large Language Models: A Contemporary Survey](https://arxiv.org/abs/2407.18921)
 [Edge Intelligence: Architectures, Challenges, and Applications](https://arxiv.org/abs/2003.12172)
 [A Survey on Model Compression for Large Language Models](https://arxiv.org/abs/2308.07633)
@@ -322,7 +336,7 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad
 |:---:|:----:|:------:|:---:|:------:|:----:|
 | 2024/09/23 | 日常论文精选 | [metame-ai/awesome-llm-plaza](https://github.com/metame-ai/awesome-llm-plaza) | [metame-ai](https://github.com/metame-ai/awesome-llm-plaza) | [awesome-llm-plaza](https://github.com/metame-ai/awesome-llm-plaza) | 日常论文精选 |
 | 2024/10/25 | 日常论文精选 | [xianshang33/llm-paper-daily](https://github.com/xianshang33/llm-paper-daily) | [xianshang33](https://github.com/xianshang33/llm-paper-daily) | [xianshang33/llm-paper-daily](https://github.com/xianshang33/llm-paper-daily) | 日常论文精选 |
-
+| 2024/11/25 | 日常论文速递 | NA | NA | [叶子的技术碎碎念-每周AI论文速递](http://leafw.cn) | NA |



@@ -316,6 +316,8 @@ hfi_update_work_fn
 | 2024/06/12 | v0.0.4 | 增强了其硬件反馈接口 (HFI) 监视器, 支持对来自被禁止的 CPU 的提示进行 HFI 监视, 支持多种低功耗状态, 支持工作负载类型提示, 并支持在低功耗模式转换期间更改能效偏好(EPP). | [phoronix, 2024/06/12, Intel Low Power Mode Daemon v0.0.4 Released To Optimize Hybrid CPUs On Linux](https://www.phoronix.com/news/Intel-LPMD-Low-Power-0.0.4). |
 | 2024/09/24 | v0.0.7 | 更改之一是新的 "--ignore-platform-check" 选项, 允许覆盖平台检查, 以便守护程序在未经验证的硬件平台上启动. 此新版本中还有 Autotool 构建系统改进和各种修复. | [phoronix, 2024/09/24, Intel's LPMD "Low Power Mode Daemon" Now Identifies As The "Energy Optimizer"](https://www.phoronix.com/news/Intel-LPMD-v0.0.7). |
 | 2024/10/16 | v0.0.8 | 引入工作负载类型代理支持, 支持特定于型号/SKU 的配置文件、英特尔 Meteor Lake P 配置文件和其他更改, 添加对 AC/DC 状态的检测, 还原时遵循电源配置文件守护程序默认 EPP, 引入 MeteorLake-P 平台特定的配置文件. | [phoronix, 2024/10/16, Intel Low Power Mode Daemon v0.0.8 Brings New Features](https://www.phoronix.com/news/Intel-Low-Power-LPMD-0.0.8) |
+| 2024/10/15 | Yicong Yang <yangyicong@huawei.com> | [Support SMT control on arm64](https://lore.kernel.org/all/20241015021841.35713-1-yangyicong@huawei.com) | TODO | v6 ☐☑✓ | [LORE v6,0/4](https://lore.kernel.org/all/20241015021841.35713-1-yangyicong@huawei.com) |
+

 #### 1.4.1.5 编译器支持
 -------
@@ -362,6 +364,8 @@ AMD 关于大小核的专利 [US20210173715A1: METHOD OF TASK TRANSITION BETWEEN
 |:---:|:----:|:---:|:----:|:---------:|:----:|
 | 2024/05/07 | Perry Yuan <perry.yuan@amd.com> | [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)<br>*-*-*-*-*-*-*-* <br>[2024/06/11, LORE v3,0/10](https://lore.kernel.org/all/cover.1718095377.git.perry.yuan@amd.com) |
 | 2024/10/03 | Mario Limonciello <superm1@kernel.org> | [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) |
+| 2024/10/25 | Mario Limonciello <mario.limonciello@amd.com> | [x86 Heterogeneous design identification](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=3eef25ab0d89cb1e55699a4d242c5afe17dbbd07) | AMD 异构设计中使用异构核心拓扑来识别提升系数(boost numerator). AMD 的异构设计包括两种类型的内核: 性能内核(Performance Cores) 和 效率内核(Efficiency Cores). 每种内核类型有不同的最高性能值, 这些值由平台配置, 驱动程序（如 amd_pstate）需要识别内核类型, 以便正确设置提升系数, 从而计算最大频率.<br>具体改动<br>1. 识别异构核心: 使用 X86_FEATURE_AMD_HETEROGENEOUS_CORES 特性来识别系统是否支持异构核心. 这通过读取 CPUID 叶子 Fn_0x80000026 来实现.<br>2. 设置提升系数: 对于性能内核, 使用固定的缩放因子 196. 对于效率内核, 使用 CPUID 报告的最高性能值作为缩放因子. 参见 phoronix 报道 [phoronix, 2024/11/03, AMD Heterogeneous CPU Design Topology Patches Coming For Linux 6.13](https://www.phoronix.com/news/AMD-Hetero-Topo-Linux-6.13) | v4 ☐☑✓ v6.13-rc1 | [LORE v4,0/5](https://lore.kernel.org/all/20241025171459.1093-1-mario.limonciello@amd.com) |
+


 ### 1.4.3 ARM big.LITTLE & DynamIQ
@@ -633,6 +637,7 @@ TLB entry shootdown 常常或多或少的带来一些性能问题.
 | 2020/02/23 | Andrea Arcangeli <aarcange@redhat.com> | [arm64: tlb: skip tlbi broadcast v2](https://lore.kernel.org/all/20200223192520.20808-1-aarcange@redhat.com) |20200223192520.20808-1-aarcange@redhat.com | v1 ☐ | [LORE](https://lore.kernel.org/all/20200223192520.20808-1-aarcange@redhat.com) |
 | 2022/09/13 | Joe Damato <jdamato@fastly.com> | [mm: Track per-task tlb events](https://lore.kernel.org/all/1663120270-2673-1-git-send-email-jdamato@fastly.com) | 通过检查 `/proc/interrupts`, 可以在每个 CPU 的基础上测量 TLB shootdown 事件. 如果 CONFIG_DEBUG_TLBFLUSH 被启用, 关于 TLB 事件的进一步信息可以从 `/proc/vmstat` 中获取, 但是这些信息是系统范围的. 这些信息是有用的, 但是在一个有许多任务的繁忙系统上, 很难消除 TLB shootdown 事件的来源的模糊性. 这组补丁跟踪每个任务的这些信息可以使开发人员修复或调整用户空间分配器, 以减少 IPI 的数量并提高应用程序性能. 为 task_struct 和 signal_struct 添加了两个新字段, 以帮助跟踪 TLB 事件:<br>1. ngtlbflush: 生成 TLB flush 的数量.<br>2. nrtlbflush: 收到 TLB flush 的数量.<br> 这些统计数据被导出到 `/proc/[pid]/stat` 中, 与类似的指标 (如 min_flt 和 maj_flt) 一起进行分析. | v1 ☐☑✓ | [LORE v1,0/1](https://lore.kernel.org/all/1663120270-2673-1-git-send-email-jdamato@fastly.com) |
 | 2023/03/12 | Yair Podemsky <ypodemsk@redhat.com> | [send tlb_remove_table_smp_sync IPI only to necessary CPUs](https://lore.kernel.org/all/20230312080945.14171-1-ypodemsk@redhat.com) | 目前, tlb_remove_table_smp_sync() 将 IPI 被不分青红皂白地发送到所有 CPU, 这会导致不必要的工作和延迟, 在实时用例和隔离的 CPU 中尤为值得注意, 此补丁将限制此 IPI 仅发送到引用受影响 mm 的 cpu, 并且当前在内核空间中.  | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20230312080945.14171-1-ypodemsk@redhat.com)<br>*-*-*-*-*-*-*-* <br>[LORE v1,0/3](https://lore.kernel.org/r/20230404134224.137038-1-ypodemsk@redhat.com)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/2](https://lore.kernel.org/r/20230620144618.125703-1-ypodemsk@redhat.com) |
+| 2024/05/31 | Byungchul Park <byungchul@sk.com> | [LUF(Lazy Unmap Flush) reducing tlb numbers over 90%](https://lore.kernel.org/all/20240531092001.30428-1-byungchul@sk.com) | 这组补丁的主要目的是实现一种名为 LUF(Lazy Unmap Flush)的机制, 以大幅减少 TLB(Translation Lookaside Buffer)刷新的数量, 特别是在处理内存迁移时.  实现 LUF 机制, 延迟 TLB 刷新直到实际需要, 从而减少 TLB 射杀的次数; 优化内存迁移过程中的性能, 特别是在处理大量内存页时; 为 x86、ARM64 和 RISC-V 架构提供支持; 添加自测试用例, 确保 LUF 机制的正确性和有效性; 通过这些改动, 内存管理和性能得到了显著提升, 特别是在处理内存迁移和 TLB shootdown 时. | v11 ☐☑✓ | [LORE v11,0/12](https://lore.kernel.org/all/20240531092001.30428-1-byungchul@sk.com) |


 > 注: x86 由于没有 tlb IS 方案, 因此只能采用 IPI 的方式来完成 TLB shootdown.
@@ -1202,6 +1207,17 @@ 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).


+### 6.7.4 Loongson Binary Translation Slated(LBT)
+-------
+
+Loongson 二进制翻译(LBT) 旨在通帮助加速和更高效地处理 LoongArch 上的 ARM / x86 / MIPS 二进制翻译. Loongson Binary Translation(LBT) 是 LoongArch ISA 的一部分, 目前有 x86、ARM 和 MIPS 的扩展. 这种加速二进制转换的方法公开了四个额外的暂存寄存器、x86/ARM eflags 和一个 x87 FPU 堆栈指针. 通过这个 Linux 内核端的补丁, 支持保存/恢复这些暂存寄存器以供 LBT 使用、异常处理和维护 sigcontext.
+
+
+| 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:-----:|:----:|:----:|:----:|:------------:|:----:|
+| 2024/11/09 |  Qi Hu <huqi@loongson.cn> | [LoongArch: Add Loongson Binary Translation (LBT) extension support](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd3c5798484aa9a08302a844d7a75a2ee3b53d05)| 参见 [phoronix, 2023/07/25, Loongson Binary Translation Slated For Linux 6.6 - Helping MIPS / x86 / ARM On LoongArch](https://www.phoronix.com/news/LoongArch-LBT-Linux-6.6) 以及 [phoronix, 2024/09/13, LoongArch KVM To Speed-Up ARM/x86 Binary Translation](https://www.phoronix.com/news/Linux-6.12-LoongArch-KVM). | v ☐☑✓ | [LORE](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd3c5798484aa9a08302a844d7a75a2ee3b53d05)|
+
+

 ## 6.8 原子操作
 -------
@@ -1376,6 +1392,19 @@ AMD-pstate 驱动程序利用 ITMT 体系结构提供的功能和数据结构,
 -------


+
+
+# 7 GPU
+-------
+
+
+| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:---:|:----:|:---:|:----:|:---------:|:----:|
+| 2023/08/29 | Yogesh Mohan Marmithu | [user queue patches for review](https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29010) | AMD RadeonSI 驱动程序的用户队列允许将作业直接提交到 GPU 硬件, 而无需使用 ioctl 命令通过 AMDGPU 内核驱动程序提交作业, 这可以通过直接向 GPU 硬件提交作业来避免因一些内核驱动程的开销所造成的延迟. 参见 [AMD User Queue Mesa Support Merged For Linux - Submitting Work Directly To The GPU](https://www.phoronix.com/news/Mesa-25.0-AMDGPU-User-Queue) | v5 ☐☑✓ | [LORE v5,0/8](https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29010) |
+| 2024/12/01 | Yonatan Maman <ymaman@nvidia.com> | [GPU Direct RDMA (P2P DMA) for Device Private Pages](https://lore.kernel.org/all/20241201103659.420677-1-ymaman@nvidia.com) | 参见 phoronix 报道 [phoronix, 2024/12/01, NVIDIA's New Linux Patches For GPU Direct RDMA For Device-Private Pages](https://www.phoronix.com/news/NVIDIA-Linux-P2P-DMA-RDMA-Priv) | v1 ☐☑✓ | [LORE v1,0/5](https://lore.kernel.org/all/20241201103659.420677-1-ymaman@nvidia.com) |
+
+
+
 <br>

 *   本作品 / 博文 ([AderStep - 紫夜阑珊 - 青伶巷草 Copyright ©2013-2017](http://blog.csdn.net/gatieme) ), 由 [成坚(gatieme)](http://blog.csdn.net/gatieme) 创作.
@@ -324,6 +324,7 @@ Google 的 Joel Fernandes 等发现 RCU 并没有很好的节能, 在 Android
 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
 |:---:|:----:|:---:|:----:|:---------:|:----:|
 | 2024/10/25 | Peter Zijlstra <peterz@infradead.org> | [futex: The remaining futex2 bits](https://lore.kernel.org/all/20241025090347.244183920@infradead.org) | [FUTEX2 NUMA & Small Futexes Revived For Linux](https://www.phoronix.com/news/FUTEX2-NUMA-Small-Futex). | v1 ☐☑✓ | [LORE v1,0/6](https://lore.kernel.org/all/20241025090347.244183920@infradead.org) |
+| 2024/11/22 | Linus Torvalds <torvalds@linux-foundation.org> | [futex: improve user space accesses](https://lore.kernel.org/all/20241122193305.7316-1-torvalds@linux-foundation.org) | 参见 phoronix 报道 [phoronix, 2024/11/26, Linus Torvalds Improves Futex Code To Improve User-Space Accesses](https://www.phoronix.com/news/Linux-6.13-Torvalds-Futex) | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20241122193305.7316-1-torvalds@linux-foundation.org)|



@@ -484,8 +485,9 @@ Proxy Execution 是一种通用形式的优先级继承机制, 它旨在解决
 | 2022/10/03 | Connor O'Brien <connoro@google.com> | [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)<br>*-*-*-*-*-*-*-* <br>[2023/03/20 LORE v2,0/12](https://lore.kernel.org/all/20230320233720.3488453-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2023/04/11 LORE v3,00/14](https://lore.kernel.org/all/20230411042511.1606592-1-jstultz@google.com) |
 | 2023/06/01 | John Stultz <jstultz@google.com> | [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 <jstultz@google.com> | [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 <jstultz@google.com> | [Preparatory changes for Proxy Execution](https://lore.kernel.org/all/20240507045450.895430-1-jstultz@google.com) | Proxy Execution 是一种通用的优先级继承机制的实现方法, 用于解决优先级反转问题和其他类似的问题. 这些预备补丁的目的是为后续更复杂的 Proxy Execution 相关补丁打下基础.<br>在发送第 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)<br>*-*-*-*-*-*-*-* <br>[2024/04/01, LORE v9,0/7](https://lore.kernel.org/all/20240401234439.834544-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[LORE v10,0/7](https://lore.kernel.org/all/20240507045450.895430-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/07/09, LORE v11,0/7](https://lore.kernel.org/all/20240709203213.799070-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/08/13, LORE v12,0/7](https://lore.kernel.org/all/20240813235736.1744280-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/08/29, RESEND, LORE v12,0/7](https://lore.kernel.org/all/20240829225212.6042-1-jstultz@google.com) |
+| 2024/05/06 | John Stultz <jstultz@google.com> | [Preparatory changes for Proxy Execution](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=af0c8b2bf67b25756f27644936e74fd9a6273bd2) | Proxy Execution 是一种通用的优先级继承机制的实现方法, 用于解决优先级反转问题和其他类似的问题. 这些预备补丁的目的是为后续更复杂的 Proxy Execution 相关补丁打下基础.<br>在发送第 7 版 Proxy Execution 补丁集时, John Stultz 收到了反馈, 指出补丁集变得过于庞大难以审查. 因此, 根据 Qais Yousef 的建议, 他决定将补丁集分为两部分：一部分是预备性的更改, 另一部分是更复杂的功能实现. 参见 [phoronix, 2024/10/18, Linux 6.13 Poised To Land Prep Patches Working Toward Proxy Execution](https://www.phoronix.com/news/Linux-6.13-Prep-For-Proxy-Exec#google_vignette). | v10 ☐☑✓ v6.13-rc1 | [2024/02/24, LORE v8,0/7](https://lore.kernel.org/all/20240224001153.2584030-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/04/01, LORE v9,0/7](https://lore.kernel.org/all/20240401234439.834544-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[LORE v10,0/7](https://lore.kernel.org/all/20240507045450.895430-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/07/09, LORE v11,0/7](https://lore.kernel.org/all/20240709203213.799070-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/08/13, LORE v12,0/7](https://lore.kernel.org/all/20240813235736.1744280-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/08/29, RESEND, LORE v12,0/7](https://lore.kernel.org/all/20240829225212.6042-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/10/09, RESEND x3, LORE v12,0/7](https://lore.kernel.org/all/20241009235352.1614323-1-jstultz@google.com) |
 | 2024/02/02 | Metin Kaya <metin.kaya@arm.com> | [sched: Add trace events for Proxy Execution (PE)](https://lore.kernel.org/all/20240202083338.1328060-1-metin.kaya@arm.com) | 添加 `sched_[start，finish]_task_selection` 跟踪事件以测量 PE 补丁在任务选择中的延迟. 此外, 在 PE 中引入有趣事件的跟踪事件:<br>1. sched_pe_enque_sleeping_task: 一个任务在睡眠任务(互斥体所有者)的等待队列中排队.<br>2. sched_pe_cross_mote_cpu: 依赖链跨远程 cpu.<br>3. sched_pe_task_is_migration: 互斥所有者任务迁移. 可以通过以下命令测试新的跟踪事件: `perf record -e sched:sched_start_task_selection -e sched:sched_finish_task_selection -e sched:sched_pe_enque_sleeping_task -e sched:sched_pe_cross_mote_cpu -e sched:sched_pe_task_is_migration`. 此补丁基于 John 的 [Proxy Execution v7 补丁系列](https://lore.kernel.org/linux-kernel/CANDhNCrHd+5twWVNqBAhVLfhMhkiO0KjxXBmwVgaCD4kAyFyWw@mail.gmail.com). | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240202083338.1328060-1-metin.kaya@arm.com) |
+| 2024/11/05 | John Stultz <jstultz@google.com> | [Single CPU Proxy Execution (v13)](https://lore.kernel.org/all/20241106025656.2326794-1-jstultz@google.com) | 这组补丁的主要目的是实现单 CPU 代理执行(Single CPU Proxy Execution)机制, 这是一种通用形式的优先级继承(priority inheritance)方法, 旨在解决某些特定场景下的调度问题.<br>1. 实现单 CPU 代理执行机制, 支持作为构建和运行时选项.<br>2. 重新设计互斥锁的 blocked_on 结构, 以便更好地支持代理执行.<br>3. 处理代理执行带来的假设变化, 确保调度器的正确性.<br>4. 实现初始逻辑, 使锁持有者可以在同一 CPU 上代替等待任务运行.<br>通过这些改动, 调度器在处理某些特定场景下的优先级继承问题时更加高效和灵活, 提高了系统的整体性能和响应速度. 参见 [Paper](https://static.lwn.net/images/conf/rtlws11/papers/proc/p38.pdf) | v13 ☐☑✓ | [LORE v13,0/7](https://lore.kernel.org/all/20241106025656.2326794-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/11/25, LORE v14,0/7](https://lore.kernel.org/all/20241125195204.2374458-1-jstultz@google.com) |


 # 12 深入理解并行编程
@@ -257,6 +257,11 @@ Linux 一开始是在一台 i386 上的机器开发的, i386 的硬件页表是

 有个硬件机构叫 TLB, 用来缓存页表查寻结果, 根据程序局部性, 即将访问的数据或代码很可能与刚访问过的在一个页面, 有了 TLB 缓存, 页表查找很多时候就大大加快了. 但是, 内核在切换进程时, 需要切换页表, 同时 TLB 缓存也失效了, 需要冲刷掉. 内核引入的一个优化是, 当切换到内核线程时, 由于内核线程不使用用户态空间, 因此切换用户态的页表是不必要, 自然也不需要冲刷 TLB. 所以引入了 Lazy-TLB 模式, 以提高效率. 关于细节, 可参考[kernel 3.10 内核源码分析 --TLB 相关 --TLB 概念、flush、TLB lazy 模式](https://www.cnblogs.com/sky-heaven/p/5133747.html)

+| 时间  | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:----:|:----:|:---:|:----:|:---------:|:----:|
+| 2024/05/31 | Byungchul Park <byungchul@sk.com> | [LUF(Lazy Unmap Flush) reducing tlb numbers over 90%](https://lore.kernel.org/all/20240531092001.30428-1-byungchul@sk.com) | 这组补丁的主要目的是实现一种名为 LUF(Lazy Unmap Flush)的机制, 以大幅减少 TLB(Translation Lookaside Buffer)刷新的数量, 特别是在处理内存迁移时.  实现 LUF 机制, 延迟 TLB 刷新直到实际需要, 从而减少 TLB 射杀的次数; 优化内存迁移过程中的性能, 特别是在处理大量内存页时; 为 x86、ARM64 和 RISC-V 架构提供支持; 添加自测试用例, 确保 LUF 机制的正确性和有效性; 通过这些改动, 内存管理和性能得到了显著提升, 特别是在处理内存迁移和 TLB shootdown 时. | v11 ☐☑✓ | [LORE v11,0/12](https://lore.kernel.org/all/20240531092001.30428-1-byungchul@sk.com) |
+
+

 ### 1.3.2 avoid unnecessary TLB flushes
 -------
@@ -755,6 +760,14 @@ MTE 实现了锁和密钥访问内存. 这样在内存访问期间, 可以在内
 | 2024/10/01 | Mark Brown <broonie@kernel.org> | [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 <lorenzo.stoakes@oracle.com> | [implement lightweight guard pages](https://lore.kernel.org/all/cover.1729196871.git.lorenzo.stoakes@oracle.com) | 用户空间库函数(如分配器和线程实现)通常需要内存区域充当'保护页'——当访问这些映射时, 会导致向访问进程发送致命信号.<br>当前实现这些的方法是通过 PROT_NONE mmap() 映射, 它提供了所需的语义, 但每个此类区域都会产生 VMA 的开销. 对于大量进程和线程, 这可能会迅速增加并导致严重的内存损失. 它还具有阻止可能被允许的合并的额外问题. 这个系列实现了不同的方法 - Vlasimil Babka 提出的方法, 将它们放在映射所需范围的页表中, 而不是不是在 VMA 层定位保护页. 对此代码的原型版本的早期测试表明，内存映射调用的速度提高了 5 倍(结合使用 process_madvise())，并且在完全空闲的 Android 系统和未优化代码上减少了 13% 的 VMA.<br>1. 引入 PTE 标记： 使用 PTE 标记(PTE markers)来实现守护页机制, 而不是传统的 PROT_NONE 映射. 添加了一个新的 PTE 标记 PTE_MARKER_GUARD, 用于表示守护页.<br>2. 扩展通用页面遍历机制: 扩展通用页面遍历机制, 允许安装 PTE(页面表项), 但仅限于内存管理逻辑, 以防止滥用.<br>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) |
+
+


 ## 1.9 page attributes
@@ -64,8 +64,15 @@ blogexcerpt: 虚拟化 & KVM 子系统
 | 2023/06/06 | Thomas Gleixner <tglx@linutronix.de> | [posix-timers: Cure inconsistencies and the SIG_IGN mess](https://lore.kernel.org/all/20230606132949.068951363@linutronix.de) | TODO | v1 ☐☑✓ | [LORE v1,0/45](https://lore.kernel.org/all/20230606132949.068951363@linutronix.de)<br>*-*-*-*-*-*-*-* <br>[LORE v2,00/50](https://lore.kernel.org/lkml/20240410164558.316665885@linutronix.de) |


+[hrtimers: Consolidate hrtimer initialization - Part 1](https://lore.kernel.org/all/20241031-hrtimer_setup_p1_v2-v2-0-23400656575a@linutronix.de)

-
+| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:---:|:----:|:---:|:----:|:---------:|:----:|
+| 2024/10/28 | Nam Cao <namcao@linutronix.de> | [hrtimers: Switch to new hrtimer interface functions (1/5)](https://lore.kernel.org/all/cover.1729864615.git.namcao@linutronix.de) | TODO | v1 ☐☑✓ | [LORE v1,0/21](https://lore.kernel.org/all/cover.1729864615.git.namcao@linutronix.de) |
+| 2024/10/28 | Nam Cao <namcao@linutronix.de> | [hrtimers: Switch to new hrtimer interface functions (2/5)](https://lore.kernel.org/all/cover.1729864823.git.namcao@linutronix.de) | TODO | v1 ☐☑✓ | [LORE v1,0/31](https://lore.kernel.org/all/cover.1729864823.git.namcao@linutronix.de) |
+| 2024/10/28 | Nam Cao <namcao@linutronix.de> | [hrtimers: Switch to new hrtimer interface functions (3/5)](https://lore.kernel.org/all/cover.1729865232.git.namcao@linutronix.de) | TODO | v1 ☐☑✓ | [LORE v1,0/24](https://lore.kernel.org/all/cover.1729865232.git.namcao@linutronix.de) |
+| 2024/10/28 | Nam Cao <namcao@linutronix.de> | [hrtimers: Switch to new hrtimer interface functions (4/5)](https://lore.kernel.org/all/cover.1729865485.git.namcao@linutronix.de) | TODO | v1 ☐☑✓ | [LORE v1,0/44](https://lore.kernel.org/all/cover.1729865485.git.namcao@linutronix.de) |
+| 2024/10/28 | Nam Cao <namcao@linutronix.de> | [hrtimers: Switch to new hrtimer interface functions (5/5)](https://lore.kernel.org/all/cover.1729865740.git.namcao@linutronix.de) | TODO | v1 ☐☑✓ | [LORE v1,0/12](https://lore.kernel.org/all/cover.1729865740.git.namcao@linutronix.de) |



@@ -795,5 +795,11 @@ https://lore.kernel.org/all/20240830130309.2141697-1-vincent.guittot@linaro.org/
 |  3  |


+| 2024/10/31 | Tianchen Ding <dtcccc@linux.alibaba.com> | [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) |

-主要目的是为 sched_ext 调度扩展模块中的默认空闲 CPU 选择策略引入 LLC(Last Level Cache) 意识. 这使得使用内置策略的调度器在具有多个 LLC 的系统中(如 NUMA 系统或基于芯片的架构)做出更明智的空闲 CPU 选择决策, 使得任务能够更好地保持在相同的 LLC 域内, 有效改善缓存局部性, 从而提高性能. LLC 意识目前仅应用于那些可以在系统中所有 CPU 上运行的任务. 如果任务的亲和性 (affinity) 被用户空间修改, 那么用户空间需要负责选择合适的优化调度域. 通过这些改动, sched_ext 调度器在处理多 LLC 系统时, 能够更有效地管理缓存资源， 进而提高整体的系统性能.
+
+
+
+这组补丁的主要目的是让 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() 回调，并且整个物理内存映射在直接映射中。
+具体改动
@@ -104,7 +104,9 @@ Intel 发布的 ControlFlag 用机器学习来发现代码中的错误, 支持 C

 *  Dtrace

-[Oracle Releases DTrace 2.0.0-1.14 For Linux Systems](https://www.phoronix.com/news/D-Trace-2.0.0-1.14)
+[phoronix, 2024/04/08, Oracle Releases DTrace 2.0.0-1.14 For Linux Systems](https://www.phoronix.com/news/D-Trace-2.0.0-1.14)
+
+[phoronix, 2024/10/23, Gentoo Linux Touts DTrace 2.0 Support](https://www.phoronix.com/news/Gentoo-Linux-DTrace-2.0), [DTrace 2.0 for Gentoo](https://www.gentoo.org/news/2024/10/23/DTrace-for-Gentoo.html), [DTrace-WIKI](https://wiki.gentoo.org/wiki/DTrace)


 ## 2.2 call kernel func from userspace