diff --git a/study/arch/MicroArchitecture/README.md b/study/arch/MicroArchitecture/README.md
index 7800c9a..0b568e9 100644
--- a/study/arch/MicroArchitecture/README.md
+++ b/study/arch/MicroArchitecture/README.md
@@ -60,6 +60,43 @@ Rentable Unit 根据任务调度 P 核和 E 核, 确保所有核心都处于活
它会尝试预测任务在 P/E 核上的完成时间然后试图分割任务以更小粒度跨核调度, 调度会更复杂, 上下文切换会更多, 优化目标可能会倾向吞吐量所以 P 核上高优任务延迟可能会被影响: P 核高优任务可能分一部分扔去 E 核, 而 E 核低优任务可能分一部分拿来 P 核跑.
+
+# 2 ON-DEMAND MEMORY ALLOCATION
+-------
+
+
+Apple [专利号-WO2021US19353-Apple-ON-DEMAND MEMORY ALLOCATION](https://xueshu.baidu.com/usercenter/paper/show?paperid=102r0eg05d3q02p0mh7c0v60eu667084) 公开了与动态分配和映射私有内存的请求电路的技术方案. 这种硬件电路可以接收私有地址并将该私有地址转换为虚拟地址. 在一些实施例中, 私有存储器分配电路被配置成生成页表信息, 如果页表信息尚未设置, 则映射所请求的私有内存页. 在各种实施例中, 这可以有利地允许动态私有内存分配, 例如, 有效地为具有不同类型工作负载的图形着色器分配内存. 与传统技术相比, 公开的页表信息缓存技术可以提高性能. 此外, 公开的实施例可以促进跨设备(例如图形处理器)的内存整合.
+
+
+
+# 3 一些微架构的探索
+-------
+
+[The Forward Slice Core Microarchitecture](https://dl.acm.org/doi/10.1145/3410463.3414629)
+
+[RL-CoPref: a reinforcement learning-based coordinated prefetching controller for multiple prefetchers](https://link.springer.com/article/10.1007/s11227-024-05938-9)
+
+提出一个新的微架构 morphcore, 结合乱序执行和高度线程化 SMT, 以便在单个内核中执行 SMT 顺序执行执行. [MorphCore：一种高效节能且高并行性性能和高吞吐量的线程级并行TLP的微架构](https://zhuanlan.zhihu.com/p/45692673) 全面描述需要实现 morphcore 的微体系结构和模式之间切换的策略.
+
+
+关于 flow computing,
+[知乎 - 三姨君 - 号称提升 100 倍的 CPU 设计，真相究竟是什么](https://zhuanlan.zhihu.com/p/703697115)
+[知乎 - 毕杰 EETOP 创始人 - 初创公司爆炸性声明：可将任何 CPU 架构性能提升 100 倍！自称 CPU 2.0 时代即将到来！](https://zhuanlan.zhihu.com/p/703140692)
+[知乎 - 降伏其芯 - 解密初创公司 flow computing CPU 架构性能提升 100 倍背后的技术原理](https://zhuanlan.zhihu.com/p/703736037)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
* 本作品/博文 ( [AderStep-紫夜阑珊-青伶巷草 Copyright ©2013-2017](http://blog.csdn.net/gatieme) ), 由 [成坚(gatieme)](http://blog.csdn.net/gatieme) 创作.
diff --git a/study/arch/pipeline/0001-history/README.md b/study/arch/pipeline/0001-history/README.md
index 3825ccd..8c67274 100644
--- a/study/arch/pipeline/0001-history/README.md
+++ b/study/arch/pipeline/0001-history/README.md
@@ -280,7 +280,8 @@ XOR a, b
| 22 | [8086架构/流水线及其优化](https://stkeke.blog.csdn.net/article/details/85230687) | NA |
| 23 | [Intel X86-64 处理器架构演进](https://zhuanlan.zhihu.com/p/515658946) | NA |
| 24 | [TALK 笔记-处理器体系结构, 历史及演进](https://www.douban.com/note/797605944) | NA |
-| 25 | [微电之窗 | 详谈CPU处理器架构演进 (Intel)](https://mp.weixin.qq.com/s?__biz=Mzg3MTIyMTU3OA==&mid=2247509982&idx=2&sn=84a1fd3c140b147a53dee7a7e3329017) |
+| 25 | [微电之窗 | 详谈CPU处理器架构演进 (Intel)](https://mp.weixin.qq.com/s?__biz=Mzg3MTIyMTU3OA==&mid=2247509982&idx=2&sn=84a1fd3c140b147a53dee7a7e3329017) | NA |
+
diff --git a/study/kernel/00-DESCRIPTION/ARCH.md b/study/kernel/00-DESCRIPTION/ARCH.md
index ca00e07..fa998cb 100644
--- a/study/kernel/00-DESCRIPTION/ARCH.md
+++ b/study/kernel/00-DESCRIPTION/ARCH.md
@@ -183,6 +183,8 @@ Intel Architecture Day 2021, 官宣了自己的服务于终端和桌面场景的
| 2021/05/27 | Kan Liang | [perf: Support perf-mem/perf-c2c for AlderLake](https://lkml.org/lkml/2021/4/5/775) | perf 支持 Hybrid CPU(内核态). | v2 ☑ 5.14-rc1 | [LKML v1 0/8](https://lkml.org/lkml/2021/4/5/775), [LKML v2 0/8](https://lkml.org/lkml/2021/5/27/191) |
| 2023/02/13 | Zhao Liu | [Introduce hybrid CPU topology](https://lore.kernel.org/all/20230213095035.158240-1-zhao1.liu@linux.intel.com) | 在 QEMU 中引入混合拓扑, 依赖于 QEMU 支持 [Support smp.clusters for x86](https://lists.gnu.org/archive/html/qemu-devel/2023-02/msg03184.html) | v1 ☐☑✓ | [LORE v1,0/52](https://lore.kernel.org/all/20230213095035.158240-1-zhao1.liu@linux.intel.com) |
| 2023/11/30 | Zhao Liu | [qom-topo: Abstract Everything about CPU Topology](https://lore.kernel.org/all/20231130144203.2307629-1-zhao1.liu@linux.intel.com) | 关于混合拓扑支持 [Introduce hybrid CPU topology](https://lore.kernel.org/all/20230213095035.158240-1-zhao1.liu@linux.intel.com) 之后的最新尝试, 使用现代 QOM 方法来定义 CPU 拓扑, 基于这种方式, 通过 cli 定义混合拓扑. 列出了详细的 Reference. | v1 ☐☑✓ | [LORE v1,0/41](https://lore.kernel.org/all/20231130144203.2307629-1-zhao1.liu@linux.intel.com) |
+| 2024/06/17 | Pawan Gupta | [Add CPU-type to topology](https://lore.kernel.org/all/20240617-add-cpu-type-v1-0-b88998c01e76@linux.intel.com) | 这个 patchset 新增了对 CPU 类型(英特尔 CPUID.1A.EAX[31-24])的支持, 以区分共享相同系列/型号/步进的 P+E、P-only、E-only 混合变体. CPU-type 的用例之一是 CPU 漏洞的受影响 CPU 表, 现在可以使用 CPU-type 过滤不受影响的变体.
补丁 1 在 CPU 拓扑结构中添加了 cpu-type, 并引入了 topology_cpu_type() 来获取 CPU-type.
补丁 2-4 将 get_this_hybrid_cpu_type() 替换为 topology_cpu_type() 的用法.
补丁 5-7 更新 CPU 匹配基础架构, 以使用 CPU-type.
补丁 8 清理了受影响的 CPU 列表.
补丁 9 使用 CPU-type 从 RFDS 受影响列表中排除仅 P 的部件. 参见 phoronix 报道 [Linux To Incorporate Intel CPU Hybrid Topology For Determining Vulnerabilities/Mitigations](https://www.phoronix.com/news/Intel-Hybrid-Topology-Mitigate). | v1 ☐☑✓ | [LORE v1,0/9](https://lore.kernel.org/all/20240617-add-cpu-type-v1-0-b88998c01e76@linux.intel.com) |
+
#### 1.4.1.2 P-State(HWP)
@@ -195,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://lore.kernel.org/all/7663799.EvYhyI6sBW@kreacher) | 这个补丁集是为调度器提供基于英特尔硬件的 x86 混合系统上的非对称 CPU 容量信息. 不对称的 CPU 容量信息在混合系统中很重要, 因为它允许以一致的方式计算系统中所有 CPU 的任务利用率, 而不管它们的容量如何. 这反过来又允许 schedutil-cpufreq 调控器在任务在不同容量的 CPU 之间迁移的情况下一致地设置 CPU 性能级别. 它还应该有助于改善混合系统上的任务布局和负载平衡决策, 这是 EAS 的关键. 根据补丁 [3/3] 的更改日志, 有问题的信息来自 MSR_HWP_CAPABILITIES 寄存器, 并由 intel_postate 驱动程序提供给调度器. Patch[2/3]引入了所需的拱形基础设施 (以每 CPU 容量变量的形式), Patch[1/3] 是初步的代码调整. 补丁 [2/3] 所做的更改非常简单, 这就是为什么这个系列被作为 RFC 发送的原因. 也就是说, 它增加了非混合系统和混合系统的开销, 这可能被认为是令人反感的, 尽管开销的增加可以说并不显著. 内存开销是每个 CPU 的一个无符号长变量, 它不是很多 IMV, 还有每个 arch_scale_cpu_capacity()调用站点的额外内存访问开销, 但我并不认为这会引起注意. 在任何情况下, 都可以避免额外的开销, 但代价是使代码变得更复杂(例如, 额外的每 CPU 内存只能在混合系统上动态分配, 必要时可以使用静态分支来访问它). 参见 phoronix 报道 [New Intel P-State Linux Driver Patches To Better Handle Hybrid Core CPUs](https://phoronix.com/news/Intel-P-State-Asymmetic-Hybrid). | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/7663799.EvYhyI6sBW@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 的关键. 根据补丁 [3/3] 的更改日志, 有问题的信息来自 MSR_HWP_CAPABILITIES 寄存器, 并由 intel_postate 驱动程序提供给调度器. Patch[2/3]引入了所需的拱形基础设施 (以每 CPU 容量变量的形式), Patch[1/3] 是初步的代码调整. 补丁 [2/3] 所做的更改非常简单, 这就是为什么这个系列被作为 RFC 发送的原因. 也就是说, 它增加了非混合系统和混合系统的开销, 这可能被认为是令人反感的, 尽管开销的增加可以说并不显著. 内存开销是每个 CPU 的一个无符号长变量, 它不是很多 IMV, 还有每个 arch_scale_cpu_capacity()调用站点的额外内存访问开销, 但我并不认为这会引起注意. 在任何情况下, 都可以避免额外的开销, 但代价是使代码变得更复杂(例如, 额外的每 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). | v1 ☐☑✓ v6.11-rc1 | [LORE v1,0/3](https://lore.kernel.org/all/7663799.EvYhyI6sBW@kreacher) |
@@ -1110,7 +1112,7 @@ https://blogs.vmware.com/vsphere/2021/10/introducing-project-capitola.html
| 2024/04/10 | Zayd Qumsieh | [tso: aarch64: Expose TSO for virtualized linux on Apple Silicon](https://lore.kernel.org/all/20240410211652.16640-1-zayd_qumsieh@apple.com) | x86 CPU 使用 TSO 内存模型. Apple Silicon CPU 能够选择性地使用 TSO 内存模型. 这可以通过设置 ACTLR 来完成. TSOEN 位为 1. 此功能对 x86 仿真器非常有用, 因为它消除了仿真器插入内存屏障以遵守的需要. 通过 TSO 存储器模型. 此补丁系列将添加 ACTLR. TSOEN 支持 Apple Silicon 机器上的虚拟化 linux. 用户空间将能够使用 prctl 将 CPU 的内存模型从默认的 ARM64 内存模型更改为 TSO 内存模型. 可以使用一个简单的测试来确定 TSO 内存模型是否正在使用中. 这必须在 Apple Silicon MacOS Sonoma 14.4 版或更高版本上完成, 因为早期版本不支持修改 TSOEN 位. 用例程序参见 [TSOEnabler](https://github.com/saagarjha/TSOEnabler/blob/master/testtso/main.c), 如果 TSO 正在使用, 此程序将无限期挂起, 如果不使用, 则几乎立即崩溃. 参见 LWN 报道 [Support for the TSO memory model on Arm CPUs](https://lwn.net/Articles/970907) | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20240410211652.16640-1-zayd_qumsieh@apple.com) |
-### 6.5.3 Concurrent Code Verification
+### 6.5.3 Concurrent Verification
-------
@@ -1145,10 +1147,23 @@ Rosetta 是一个转译过程, 允许用户在 Apple Silicon 上运行包含 x86
[macOS 13 Adding Ability To Use Rosetta In ARM Linux VMs For Speedy x86_64 Linux Binaries](https://www.phoronix.com/scan.php?page=news_item&px=macOS-13-Rosetta-Linux-Binaries)
-### 6.7.2 FEX 2406
+### 6.7.2 FEX
-------
-FEX 是在 ARM64/AArch64 Linux 上开发用户模式 x86/x86_64 二进制仿真的开源项目之一. FEX 2406 于 2024/6/13 发布新版本, 附带了许多[即时 JIT 优化](https://fex-emu.com/FEX-2406)、大大改进的寄存器分配器以及各种其他性能优化, 带来了 2% 到 12% 的性能提升. FEX 2406 还增加了对 32 位 OpenGL thunking 的支持, 作为提高其 x86 32 位游戏/应用程序兼容性的一部分. [FEX 2406 Brings JIT Optimizations For Running x86_64 Binaries On AArch64](https://www.phoronix.com/news/FEX-2406-Released).
+[FEX](https://fex-emu.com) 是在 ARM64/AArch64 Linux 上开发用户模式 x86/x86_64 二进制仿真的开源项目之一.
+
+
+[FEX 2406](https://fex-emu.com/FEX-2406) 于 2024/6/13 发布新版本, 附带了许多[即时 JIT 优化](https://fex-emu.com/FEX-2406)、大大改进的寄存器分配器以及各种其他性能优化, 带来了 2% 到 12% 的性能提升. FEX 2406 还增加了对 32 位 OpenGL thunking 的支持, 作为提高其 x86 32 位游戏/应用程序兼容性的一部分. [FEX 2406 Brings JIT Optimizations For Running x86_64 Binaries On AArch64](https://www.phoronix.com/news/FEX-2406-Released).
+
+[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).
+
+
+### 6.7.3 Box64
+-------
+
+Box64 v0.3 现在作为此用户空间 x86_64 模拟器的最新功能版本提供, 适用于 AArch64(ARM64) 主机上的 Linux 二进制文件. Box64 是该领域几个很有前途的项目之一, 它能够在 ARM64 下快速运行 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).
@@ -1239,6 +1254,9 @@ openEuler 提供了 [openEuler/prefetch_tuning](https://gitee.com/openeuler/pref
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2023/02/01 | Srinivas Pandruvada | [Add TPMI support](https://lore.kernel.org/all/20230202010738.2186174-1-srinivas.pandruvada@linux.intel.com) | Intel Topology Aware Register and PM Capsule Interface | v1 ☐☑✓ | [LORE v1,0/7](https://lore.kernel.org/all/20230202010738.2186174-1-srinivas.pandruvada@linux.intel.com) |
+| 2019/05/27 | Rafael J. Wysocki | [PM / arch: x86: MSR_IA32_ENERGY_PERF_BIAS handling fixes and sysfs i/f](https://lore.kernel.org/all/3844875.YPkTDDlcrF@kreacher) | Performance and Energy Bias Hint (EPB). | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/1637073.gl2OfxWTjI@aspire.rjw.lan) |
+| 2023/08/07 | Jason Andryuk | [Intel Hardware P-States (HWP) support](https://lore.kernel.org/all/20230807185119.98333-1-jandryuk@gmail.com) | TODO | v8 ☐☑✓ | [LORE v8,0/15](https://lore.kernel.org/all/20230807185119.98333-1-jandryuk@gmail.com) |
+
### 6.12.2 AMD
-------
@@ -1287,7 +1305,7 @@ AMD-pstate 驱动程序利用 ITMT 体系结构提供的功能和数据结构,
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2023/08/15 | Meng Li | [amd-pstate preferred core](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=dfddf34a3f0d45483f5b3e46c2e7bda173796f1b) | [AMD Pstate Preferred Core](https://lore.kernel.org/all/20230815061546.3556083-1-li.meng@amd.com) 以及 [AMD P-State Preferred Core Submitted For Linux 6.9 While Intel Meteor Lake Gets Tuned](https://www.phoronix.com/news/AMD-P-State-Preferred-Core-69) | v2 ☐☑✓ 6.9-rc1 | [LORE v2,0/7](https://lore.kernel.org/all/20230815061546.3556083-1-li.meng@amd.com)
*-*-*-*-*-*-*-*
[LORE v13,0/7](https://lore.kernel.org/all/20240112092531.789841-1-li.meng@amd.com)
*-*-*-*-*-*-*-*
[LORE v14,0/7](https://lore.kernel.org/lkml/20240119090502.3869695-1-li.meng@amd.com) |
-| 2024/03/18 | Perry Yuan | [AMD Pstate Driver Core Performance Boost](https://lore.kernel.org/all/cover.1710754236.git.perry.yuan@amd.com) | 该补丁集系列为 AMD pstate 驱动程序增加了核心性能提升 (core performance boost) 功能, 包括被动, 引导和主动模式支持. 用户可以使用新的 sysfs 条目: "/sys/devices/system/cpu/amd_pstate/cpb_boost" 更改核心频率 boost 控制. 由于与支持所有模式的新 cpb_boost 的功能冲突, 传统的 boost 接口已被删除. 参见 [AMD Posts Updated Linux Patches For P-State Core Performance Boost](https://www.phoronix.com/news/AMD-Core-Performance-Boost-6). [AMD Core Performance Boost For Linux Getting Per-CPU Core Controls](https://www.phoronix.com/news/AMD-Core-Perf-Boost-Per-CPU) | v6 ☐☑✓ | [LORE v6,0/6](https://lore.kernel.org/all/cover.1710754236.git.perry.yuan@amd.com)
*-*-*-*-*-*-*-*
[AMD Pstate Driver Core Performance Boost](https://lore.kernel.org/linux-pm/cover.1714989803.git.perry.yuan@amd.com) |
+| 2024/03/18 | Perry Yuan | [AMD Pstate Driver Core Performance Boost](https://lore.kernel.org/all/cover.1710754236.git.perry.yuan@amd.com) | 该补丁集系列为 AMD pstate 驱动程序增加了核心性能提升 (core performance boost) 功能, 包括被动, 引导和主动模式支持. 用户可以使用新的 sysfs 条目: "/sys/devices/system/cpu/amd_pstate/cpb_boost" 更改核心频率 boost 控制. 由于与支持所有模式的新 cpb_boost 的功能冲突, 传统的 boost 接口已被删除. 参见 [AMD Posts Updated Linux Patches For P-State Core Performance Boost](https://www.phoronix.com/news/AMD-Core-Performance-Boost-6). [AMD Core Performance Boost For Linux Getting Per-CPU Core Controls](https://www.phoronix.com/news/AMD-Core-Perf-Boost-Per-CPU), [AMD P-State Core Performance Boost To Be Merged For Linux 6.11](https://www.phoronix.com/news/AMD-Core-Perf-Boost-Linux-6.11). | v6 ☐☑✓ | [LORE v6,0/6](https://lore.kernel.org/all/cover.1710754236.git.perry.yuan@amd.com)
*-*-*-*-*-*-*-*
[AMD Pstate Driver Core Performance Boost](https://lore.kernel.org/linux-pm/cover.1714989803.git.perry.yuan@amd.com) |
| 2024/03/08 | Sibi Sankar | [cpufreq: scmi: Add boost frequency support](https://lore.kernel.org/all/20240308104410.385631-1-quic_sibis@quicinc.com) | [ARM SCMI CPUFreq Driver Enabling Boost Support By Default With Linux 6.9](https://www.phoronix.com/news/ARM-SCMI-CPUFreq-Boost-Linux-69). | v3 ☐☑✓ | [LORE v3,0/2](https://lore.kernel.org/all/20240308104410.385631-1-quic_sibis@quicinc.com)
*-*-*-*-*-*-*-*
[LORE v4,0/2](https://www.phoronix.com/news/Linux-69-RAM-Bandwidth-Throttle) |
diff --git a/study/kernel/00-DESCRIPTION/DEBUGGING.md b/study/kernel/00-DESCRIPTION/DEBUGGING.md
index a0f5dc0..32e29b4 100644
--- a/study/kernel/00-DESCRIPTION/DEBUGGING.md
+++ b/study/kernel/00-DESCRIPTION/DEBUGGING.md
@@ -68,14 +68,14 @@ blogexcerpt: FZF 是目前最快的模糊搜索工具. 使用 golang 编写. 结
[内核栈回溯原理应用](https://www.cnblogs.com/mysky007/p/12539754.
-[Android中基于DWARF的stack unwind实现原理](https://blog.csdn.net/feelabclihu/article/details/137703180)
+[Android 中基于 DWARF 的 stack unwind 实现原理](https://blog.csdn.net/feelabclihu/article/details/137703180)
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2018/11/23 | Shile Zhang | [Speed booting by sorting ORC unwind tables at build time](https://lore.kernel.org/patchwork/cover/1162315) | ORC unwind 有两个表, .orc_unwind_ip 和. orc_unwind 二分搜索需要排序. 在构建时对其进行排序可以节省更多 CPU 周期有助于加快内核引导. 添加 ORC 表排序在一个独立的线程有助于避免更多的链接. | RFC v6 ☐ | [PatchWork v6](https://lore.kernel.org/patchwork/cover/1162315) |
| 2021/08/12 | Shile Zhang | [arm64: Reorganize the unwinder and implement stack trace reliability checks](https://lwn.net/Articles/866194) | 使所有堆栈遍历函数都使用 arch_stack_walk().
目前, ARM64 代码中有多个函数使用 start_backtrace() 和 unwind_frame() 遍历堆栈. 将它们全部转换为使用 arch_stack_walk(). 这使得维护更容易. | RFC v8 ☐ | [PatchWork RFC,v8,0/4](https://patchwork.kernel.org/project/linux-arm-kernel/cover/20210812190603.25326-1-madvenka@linux.microsoft.com) |
-虽然不省略帧指针对性能有已知的影响, 因此之前各发行版都默认不开启栈帧, 但是 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).
+虽然不省略帧指针对性能有已知的影响, 因此之前各发行版都默认不开启栈帧, 但是 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).
# 2 unikernel
-------
@@ -92,7 +92,7 @@ Unikernel 是一种专门的操作系统, 其中应用程序直接与内核链
| 2015/04/16 | Toshiyuki Maeda | [Kernel Mode Linux : Execute user processes in kernel mode](http://web.yl.is.s.u-tokyo.ac.jp/~tosh/kml) | 内核直接执行用户态程序. | v1 ☐ [4.0](http://web.yl.is.s.u-tokyo.ac.jp/~tosh/kml/kml/for4.x) | [Patch](https://github.com/sonicyang/KML) |
| 2018/11/23 | Hsuan-Chi Kuo | [Lupine: Linux in Unikernel Clothes](https://github.com/hckuo/Lupine-Linux) | 通过内核配置和 (KML) 间接清除系统调用的影响, 从而使得 Linux 的性能达到持平甚至优于 unikernel 的性能. | ☐ | [Github](https://github.com/hckuo/Lupine-Linux), [159_kuo_slides.pdf](https://www.eurosys2020.org/wp-content/uploads/2020/04/slides/159_kuo_slides.pdf) |
| 2022/10/03 | Ali Raza | [Unikernel Linux (UKL)](https://lore.kernel.org/all/20221003222133.20948-1-aliraza@bu.edu) | 参见 [Experimental Patches Adapt Linux For A Unikernel Design](https://www.phoronix.com/news/Linux-Unikernel-RFC). | v1 ☐☑✓ | [LORE v1,0/10](https://lore.kernel.org/all/20221003222133.20948-1-aliraza@bu.edu), [Github](https://github.com/unikernelLinux/ukl) |
-| 2024/02/07 | Huaiyu Yan | [ndss2024_LDR: Secure and Efficient Linux Driver Runtime for Embedded TEE Systems](https://zhuanlan.zhihu.com/p/681195447) | 复用现有 LINUX 驱动, 在嵌入式TEE系统下更高效的 LKM runtime. | ☐ | [ndss-paper](https://www.ndss-symposium.org/ndss-paper/ldr-secure-and-efficient-linux-driver-runtime-for-embedded-tee-systems), [github, SparkYHY/Linux-Driver-Runtime](https://github.com/SparkYHY/Linux-Driver-Runtime) |
+| 2024/02/07 | Huaiyu Yan | [ndss2024_LDR: Secure and Efficient Linux Driver Runtime for Embedded TEE Systems](https://zhuanlan.zhihu.com/p/681195447) | 复用现有 LINUX 驱动, 在嵌入式 TEE 系统下更高效的 LKM runtime. | ☐ | [ndss-paper](https://www.ndss-symposium.org/ndss-paper/ldr-secure-and-efficient-linux-driver-runtime-for-embedded-tee-systems), [github, SparkYHY/Linux-Driver-Runtime](https://github.com/SparkYHY/Linux-Driver-Runtime) |
# 3 RONX
-------
@@ -247,6 +247,7 @@ $reclaim = current\_mem \times reclaim\_ratio \times max(0,1 – \frac{psi_some}
[Why getpid() is not implemented in x86_64's vdso?](https://stackoverflow.com/questions/65454115/why-getpid-is-not-implemented-in-x86-64s-vdso)
+[getrandom() In The vDSO Aims For Linux 6.11 To Provide Faster Yet Secure User-Space RNG](https://www.phoronix.com/news/getrandom-vDSO-RNG-Linux-6.11)
## 8.2 getrandom vDSO
-------
@@ -325,7 +326,7 @@ $reclaim = current\_mem \times reclaim\_ratio \times max(0,1 – \frac{psi_some}
| 2022/02/07 | John Ogness | [implement threaded console printing](https://lore.kernel.org/all/20220207194323.273637-1-john.ogness@linutronix.de) | 参见 phoronix 报道 [Linux Gets Patches For Threaded Console Printing](https://www.phoronix.com/scan.php?page=news_item&px=Linux-Threaded-Console-Print) 和 [Patches Updated For Linux To Enjoy Consoles Running At Full-Speed](https://www.phoronix.com/scan.php?page=news_item&px=Printk-v3-Consoles-Full-Speed) | v1 ☐ | [LORE v1,0/13](https://lore.kernel.org/all/20220207194323.273637-1-john.ogness@linutronix.de) |
| 2023/03/02 | John Ogness | [threaded/atomic console support](https://lore.kernel.org/all/87wn3zsz5x.fsf@jogness.linutronix.de) | TODO | v1 ☐☑✓ | [LORE v1,0/18](https://lore.kernel.org/all/87wn3zsz5x.fsf@jogness.linutronix.de) |
| 2024/02/18 | John Ogness | [wire up write_atomic() printing](https://lore.kernel.org/all/20240218185726.1994771-1-john.ogness@linutronix.de) | TODO | v2 ☐☑✓ | [LORE v2,0/26](https://lore.kernel.org/all/20240218185726.1994771-1-john.ogness@linutronix.de) |
-| 2024/06/04 | John Ogness | [add threaded printing + the rest](https://lore.kernel.org/all/20240603232453.33992-1-john.ogness@linutronix.de) | [Updated Printk Rework Patches - Necessary Step For Mainlining Linux Real-Time "RT"](https://www.phoronix.com/news/Printk-Rework-v2-Linux) | v2 ☐☑✓ | [LORE v2,0/18](https://lore.kernel.org/all/20240603232453.33992-1-john.ogness@linutronix.de) |
+| 2024/06/04 | John Ogness | [add threaded printing + the rest](https://lore.kernel.org/all/20240603232453.33992-1-john.ogness@linutronix.de) | [Updated Printk Rework Patches - Necessary Step For Mainlining Linux Real-Time"RT"](https://www.phoronix.com/news/Printk-Rework-v2-Linux) | v2 ☐☑✓ | [LORE v2,0/18](https://lore.kernel.org/all/20240603232453.33992-1-john.ogness@linutronix.de) |
| 2022/09/11 | Thomas Gleixner | [printk: A new approach - WIP](https://lore.kernel.org/all/20220910221947.171557773@linutronix.de) | | v1 ☐☑✓ | [LORE v1,0/29](https://lore.kernel.org/all/20220910221947.171557773@linutronix.de) |
| 2023/09/16 | John Ogness | [provide nbcon base](https://lore.kernel.org/all/20230916192007.608398-1-john.ogness@linutronix.de) | [NBCON Console Patches Updated For Eventually Unblocking Real-Time Linux Kernel](https://www.phoronix.com/news/Linux-NCON-Consoles-v5) | v5 ☐☑✓ | [LORE v5,0/8](https://lore.kernel.org/all/20230916192007.608398-1-john.ogness@linutronix.de) |
@@ -618,18 +619,19 @@ bperf 试图通过允许多个 "周期" 或 "指令" 的 perf_event (在不同
几年来, Facebook 的工程师们一直在研究 [BOLT](https://www.phoronix.com/scan.php?page=news_item&px=Facebook-BOLT-Optimize-Binaries), 以此加速 Linux/ELF 二进制文件.
-BOLT 是一个二进制优化和布局工具, 它是一个 Facebook 孵化器项目, 用于加速 Linux x86-64/AArch64 ELF 二进制文件. 这个工具能够分析和重新排布的可执行程序, 以产生比编译器的 LTO 和 PGO 优化所能实现的更快的性能. 2022 年 1 月, [BOLT Merged Into LLVM To Optimize Binaries For Faster Performance](https://www.phoronix.com/news/LLVM-Lands-BOLT). 允许优化二进制文件的布局, 作为链接后的步骤, 以提高性能. 与配置文件引导优化 (PGO) 一样, BOLT 首先需要分析步骤来生成性能记录以反馈优化过程, 但收益可能很大.
+BOLT 是一个二进制优化和布局工具, 它是一个 Meta(Facebook) 孵化器项目, 用于加速 Linux x86-64/AArch64 ELF 二进制文件. 这个工具能够分析和重新排布的可执行程序, 以产生比编译器的 LTO 和 PGO 优化所能实现的更快的性能. 2022 年 1 月, [BOLT Merged Into LLVM To Optimize Binaries For Faster Performance](https://www.phoronix.com/news/LLVM-Lands-BOLT). 允许优化二进制文件的布局, 作为链接后的步骤, 以提高性能. 与配置文件引导优化 (PGO) 一样, BOLT 首先需要分析步骤来生成性能记录以反馈优化过程, 但收益可能很大.
-facebook 在 LPC-2021 公布了其 [最新基于 BOLT 优化 Linux 内核的进展](https://www.phoronix.com/news/Facebook-BOLTing-The-Kernel), 这项工作与允许 Linux 内核的配置文件引导优化(PGO) 的挑战类似, 与现有的 BOLT 专注于仅优化 ELF 应用程序可执行性相比, BOLT'ing 的 Linux 内核在正确分析 / 采样内核和相关优化工作负载、内核的大规模代码基数、模块与内核代码等方面面临着类似的复杂障碍. 从公布的信息上看效果不错, 在 PGO + LTO 编译器优化的基础之上仍然带来了两位数的提升(double digit speedups"). 这些提速是通过优化可执行工具的代码布局来实现更高效的硬件页面使用和指令缓存. 参见 [slides](https://linuxplumbersconf.org/event/11/contributions/974/attachments/923/1793/Optimizing%20Linux%20Kernel%20with%20BOLT.pdf).
+Meta(Facebook) 在 LPC-2021 公布了其 [最新基于 BOLT 优化 Linux 内核的进展](https://www.phoronix.com/news/Facebook-BOLTing-The-Kernel), 这项工作与允许 Linux 内核的配置文件引导优化(PGO) 的挑战类似, 与现有的 BOLT 专注于仅优化 ELF 应用程序可执行性相比, BOLT'ing 的 Linux 内核在正确分析 / 采样内核和相关优化工作负载、内核的大规模代码基数、模块与内核代码等方面面临着类似的复杂障碍. 从公布的信息上看效果不错, 在 PGO + LTO 编译器优化的基础之上仍然带来了两位数的提升(double digit speedups"). 这些提速是通过优化可执行工具的代码布局来实现更高效的硬件页面使用和指令缓存. 参见 [LPC 2021, Optimizing Linux Kernel with BOLT, slides](https://linuxplumbersconf.org/event/11/contributions/974/attachments/923/1793/Optimizing%20Linux%20Kernel%20with%20BOLT.pdf).
BOLT 之前代码在 [github 开源](https://github.com/facebookincubator/BOLT), 随后在 2022 合并到[主线 LLVM](https://github.com/llvm/llvm-project/tree/main/bolt), 参见 [BOLT Close To Merging Into LLVM For Optimizing Performance Of Binaries](https://www.phoronix.com/scan.php?page=news_item&px=BOLT-Inches-To-LLVM). 并默认情况下在 Linux x86_64 和 AArch64 测试版本中被打开, [LLVM's BOLT Flipped On By Default For Linux x86/AArch64 Test Releases](https://www.phoronix.com/news/LLVM-BOLT-Default-Test-Releases).
-Facebook 一直致力于 BOLT 的 Linux 内核以获得更高的性能, [Meta Continues Working On BOLT'ing The Linux Kernel For Greater Performance](https://www.phoronix.com/news/LLVM-BOLT-Linux-Kernel-2024), 经过 2 年的努力, 这项工作终于于 2024 年 2 合入 LLVM 主线. 参见 [BOLT: Add writing support for Linux kernel ORC #80950](https://github.com/llvm/llvm-project/pull/80950).
+Meta(Facebook) 一直致力于 BOLT 的 Linux 内核以获得更高的性能, [Meta Continues Working On BOLT'ing The Linux Kernel For Greater Performance](https://www.phoronix.com/news/LLVM-BOLT-Linux-Kernel-2024), 经过 2 年的努力, 这项工作终于于 2024 年 2 合入 LLVM 主线. 参见 [BOLT: Add writing support for Linux kernel ORC #80950](https://github.com/llvm/llvm-project/pull/80950). BOLT 合入 LLVM 以来, Meta(Facebook) 一直在围绕 BOLT 内核进行工作, 2024/07/03 发布了一份关于执行 BOLT 优化的 Linux 内核构建的[公共指南 Optimizing Linux Kernel with BOLT](https://github.com/llvm/llvm-project/blob/main/bolt/docs/OptimizingLinux.md), 预期系统性能提高大约 5%, 参见 phoronix 报道 [Meta Sees ~5% Performance Gains To Optimizing The Linux Kernel With BOLT](https://www.phoronix.com/news/Linux-BOLT-5p-Performance).
LLVM BOLT 优化 GNOME 的 Pango 净改进 ~6%, 参见 phoronix 报道 [LLVM BOLT Optimizations Net ~6% Improvement For GNOME's Pango](https://www.phoronix.com/news/LLVM-BOLT-Faster-Pango).
ARM 的编译器工程师利用 BOLT 来创建二进制分析工具, 以审查安全强化选项的正确性. 该工具旨在验证堆栈保护器、堆栈冲突保护、分支保护、控制流保护等功能. 二进制分析工具将验证整个程序的强化功能, 并且比今天使用的有限安全强化测试要详细得多. 参见 phoronix 报道 [LLVM's BOLT Being Adapted To Analyze Security Hardening Of Binaries](https://www.phoronix.com/news/LLVM-BOLT-Security-Hardening).
+
### 13.2.4 Propeller
-------
@@ -812,6 +814,8 @@ Intel 编译器随后也切到 LLVM 框架, 参见 [Intel Fully Embracing LLVM F
| 2022/10/17 | Masahiro Yamada | [Remove Intel compiler support](https://lore.kernel.org/all/20221016182349.49308-1-masahiroy@kernel.org) | TODO | v3 ☐☑✓ | [LORE](https://lore.kernel.org/all/20221016182349.49308-1-masahiroy@kernel.org) |
+一个编译器以及交叉编译器的集合网站: [mirrors.edge.kernel.org](https://mirrors.edge.kernel.org/pub/tools).
+
## 13.10 编译选项
-------
@@ -1128,8 +1132,9 @@ Fedora 尝试优化 systemd 开机以及重启的时间, 参见 phoronix 报道
| 2024/02/27 | Daniel Almeida | [Rewrite the VP9 codec library in Rust](https://lore.kernel.org/all/20240227215146.46487-1-daniel.almeida@collabora.com) | Collabora 的 Daniel Almeida 发布了 Linux 内核的 Video 4 Linux 2 (V4L2) 子系统中 VP9 编解码器库代码的重写. 在使用 Rust 而不是现有的 C 代码时, 这应该会产生更好的内存安全性, 并更好地抵御现有代码中的潜在问题. 参见 phoronix 报道 [Linux's V4L2 VP9 Codec Kernel Code Rewritten In Rust For Better Memory Safety](https://www.phoronix.com/news/VP9-Linux-Kernel-Rust-V4L2-RFC). | v1 ☐☑✓ | [LORE v1,0/1](https://lore.kernel.org/all/20240227215146.46487-1-daniel.almeida@collabora.com) |
| 2024/03/27 | Wedson Almeida Filho | [In-place module initialisation](https://lore.kernel.org/all/20240327032337.188938-1-wedsonaf@gmail.com) | [Microsoft Engineer Sends Rust Linux Kernel Patches For In-Place Module Initialization](https://www.phoronix.com/news/Linux-Rust-In-Place-Module-Init) | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20240327032337.188938-1-wedsonaf@gmail.com) |
| 2024/03/22 | Boqun Feng | [Memory model and atomic API in Rust](https://lore.kernel.org/all/20240322233838.868874-1-boqun.feng@gmail.com) | [A memory model for Rust code in the kernel](https://lwn.net/Articles/967049). | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20240322233838.868874-1-boqun.feng@gmail.com) |
-| 2024/05/14 | Wedson Almeida Filho | [Rust abstractions for VFS](https://lore.kernel.org/all/20240514131711.379322-1-wedsonaf@gmail.com) | 参见 phoronix 报道 [Microsoft Engineer Ports EXT2 File-System Driver To Rust](https://www.phoronix.com/news/Rust-VFS-Linux-V2-Now-With-EXT2). | v2 ☐☑✓ | [LORE v2,0/30](https://lore.kernel.org/all/20240514131711.379322-1-wedsonaf@gmail.com) |
-| 2024/05/20 | Danilo Krummrich | [DRM Rust abstractions and Nova](https://lore.kernel.org/all/20240520172059.181256-1-dakr@redhat.com) | [RFC Patches Posted For Rust-Written NVIDIA "Nova" GPU Driver](https://www.phoronix.com/news/RFC-Rust-Nova-NVIDIA-Driver). | v1 ☐☑✓ | [LORE v1,0/8](https://lore.kernel.org/all/20240520172059.181256-1-dakr@redhat.com) |
+| 2024/05/14 | Wedson Almeida Filho | [Rust abstractions for VFS](https://lore.kernel.org/all/20240514131711.379322-1-wedsonaf@gmail.com) | 参见 phoronix 报道 [Microsoft Engineer Ports EXT2 File-System Driver To Rust](https://www.phoronix.com/news/Rust-VFS-Linux-V2-Now-With-EXT2) 以及 [Rust for filesystems](https://lwn.net/Articles/978738). | v2 ☐☑✓ | [LORE v2,0/30](https://lore.kernel.org/all/20240514131711.379322-1-wedsonaf@gmail.com) |
+| 2024/05/20 | Danilo Krummrich | [DRM Rust abstractions and Nova](https://lore.kernel.org/all/20240520172059.181256-1-dakr@redhat.com) | [RFC Patches Posted For Rust-Written NVIDIA"Nova"GPU Driver](https://www.phoronix.com/news/RFC-Rust-Nova-NVIDIA-Driver). | v1 ☐☑✓ | [LORE v1,0/8](https://lore.kernel.org/all/20240520172059.181256-1-dakr@redhat.com) |
+
## 22.2 C++
@@ -1150,8 +1155,10 @@ Fedora 尝试优化 systemd 开机以及重启的时间, 参见 phoronix 报道
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2022/09/27 | Oracle | [bpftune For BPF-Based](https://lore.kernel.org/all/20220927131518.30000-1-ojeda@kernel.org) | [Oracle Developing"bpftune"For BPF-Based, Automatic Tuning Of Linux Systems](https://www.phoronix.com/news/Oracle-bpftune)
*-*-*-*-*-*-*-*
[https://blogs.oracle.com/linux/post/introducing-bpftune](https://blogs.oracle.com/linux/post/introducing-bpftune)
*-*-*-*-*-*-*-*
[bpftune - Using Reinforcement Learning in BPF](https://blogs.oracle.com/linux/post/bpftune-using-reinforcement-learning-in-bpf) | v10 ☐☑✓ | [GitHub](https://github.com/oracle-samples/bpftune) |
-| 2022/09/27 | Atune | NA | NA | NA | NA |
+| 2022/09/27 | openEuler | Atune | A-Tune 是一款基于 AI 的操作系统性能调优引擎。A-Tune 利用 AI 技术, 使操作系统 "懂" 业务, 简化 IT 系统调优工作的同时，让应用程序发挥出色性能. | NA | [Gitee/openeuler/A-Tune](https://gitee.com/openeuler/A-Tune) |
+| 2022/09/27 | openEuler | [native-turbo](https://gitee.com/openeuler/native-turbo) | Native-Turbo 是操作系统原生性能加速框架; 通过微架构优化和软硬件协同等技术, 提升大型应用性能; Native-Turbo 包含微架构优化技术, 基础库优化, 系统调用优化, 中断聚合, 软硬件协同等技术; 其中微架构优化技术主要有: 动态库拼接, exec 原生大页, 消除 PLT 跳转, 热点 Section 在线重排等. | NA | [Gitee/openeuler/native-turbo](https://gitee.com/openeuler/native-turbo) |
| 2022/09/27 | Ktune | NA | NA | NA | NA |
+| 2020/01/01 | RedHat | [tuned](https://github.com/redhat-performance/tuned) | NA | NA | [GitHub/redhat-performance/tuned](https://github.com/redhat-performance/tuned), [Fedora 41 To Replace Power-Profiles-Daemon With "Tuned"](https://www.phoronix.com/news/Fedora-41-Goes-Tuned-PPD) |
# 24 ELF
-------
diff --git a/study/kernel/00-DESCRIPTION/LOCKING.md b/study/kernel/00-DESCRIPTION/LOCKING.md
index 336c242..ce8be35 100644
--- a/study/kernel/00-DESCRIPTION/LOCKING.md
+++ b/study/kernel/00-DESCRIPTION/LOCKING.md
@@ -450,8 +450,8 @@ Peter Zijlstra 在 [RT-Summit 2017](https://wiki.linuxfoundation.org/realtime/ev
| 2020/12/18 | ValenƟn Schneider | [Looking forward on proxy execution](https://lpc.events/event/7/contributions/758) | TODO | v1 ☐☑✓ | [GitLab, linux-arm RFC v3,00/08](https://gitlab.arm.com/linux-arm/linux-vs/-/tree/mainline/sched/proxy-rfc-v3/) |
| 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/02/24, LORE v8,0/7](https://lore.kernel.org/all/20240224001153.2584030-1-jstultz@google.com)
*-*-*-*-*-*-*-*
[20240401, LORE v9,0/7](https://lore.kernel.org/all/20240401234439.834544-1-jstultz@google.com) |
-| 2024/05/06 | John Stultz | [Preparatory changes for Proxy Execution v10](https://lore.kernel.org/all/20240507045450.895430-1-jstultz@google.com) | TODO | v10 ☐☑✓ | [LORE v10,0/7](https://lore.kernel.org/all/20240507045450.895430-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/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) |
+| 2024/05/06 | John Stultz | [Preparatory changes for Proxy Execution v10/v11](https://lore.kernel.org/all/20240507045450.895430-1-jstultz@google.com) | TODO | v10 ☐☑✓ | [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/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) |
@@ -502,6 +502,7 @@ SCaLE 21x 上 Alison Chaiken 关于 WorkQueue 的讨论, 参见 [Diagnosing work
| 2023/05/18 | Tejun Heo | [workqueue: Improve unbound workqueue execution locality](https://lore.kernel.org/all/20230519001709.2563-1-tj@kernel.org) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20230519001709.2563-1-tj@kernel.org) |
| 2024/02/16 | Tejun Heo | [workqueue: Implement disable/enable_work()](https://lore.kernel.org/all/20240216180559.208276-1-tj@kernel.org) | [Linux 6.9 Sees Invasive & Significant Changes To Workqueues](https://www.phoronix.com/news/Linux-6.9-Workqueue). | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240216180559.208276-1-tj@kernel.org) |
| 2024/01/29 | Tejun Heo | [workqueue: Introduce struct wq_node_nr_active](https://lore.kernel.org/all/Zbfq8egWUfYgkOsa@slm.duckdns.org) | TODO | v4 ☐☑✓ | [LORE v4,0/10](https://lore.kernel.org/all/Zbfq8egWUfYgkOsa@slm.duckdns.org) |
+| 2024/06/22 | Leonardo Bras | [Introduce QPW for per-cpu operations](https://lore.kernel.org/all/20240622035815.569665-1-leobras@redhat.com) | 提出一种 QPW(Queue PerCPU Work) 作为在 PREEMPT_RT 内核中处理每个 CPU 操作的更好方法, 以取代工作队列 WorkQueue.
目前使用 PREEMPT_RT=y, local_locks() 变成了每个 CPU 的自旋锁. 在这种情况下, 不需要在远程 CPU 上调度工作, 尝试获取远程 CPU 的每个 CPU 自旋锁并在本地运行所需的工作应该是安全的, 主要的代价是在每个局部函数中执行 un/locking.
引入 queue_percpu_work_on() API, 在非 PREEMPT_RT 内核上的现有 local_locks 和 WorkQueue 的行为进行包装. 但对于 PREEMPT_RT 的内核, QPW 将锁定 CPU 的每个 CPU 结构并在本地执行工作. 参见 [Red Hat Proposes Queue PerCPU Work "QPW" For Better Handling Per-CPU Work On RT Linux](https://www.phoronix.com/news/Linux-Queue-Per-CPU-Work-QPW). | v1 ☐☑✓ | [LORE v1,0/4](https://lore.kernel.org/all/20240622035815.569665-1-leobras@redhat.com) |
# 13 Windows NT Synchronization Primitive Driver
diff --git a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md
index d5cf971..2576c06 100644
--- a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md
+++ b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md
@@ -219,6 +219,9 @@ Linux 一开始是在一台 i386 上的机器开发的, i386 的硬件页表是
关于四级页表演进的细节, 可看我以前文章: [Linux 内核 4 级页表的演进](https://link.zhihu.com/?target=http%3A//larmbr.com/2014/01/19/the-evolution-of-4-level-page-talbe-in-linux)
+
+自从英特尔开始为 Linux 内核提供 5 级分页支持以来, 已经过去了将近十年, 以允许更大的虚拟和物理地址空间以及扩展的内存大小. 2017 年, Linux 4.12 中上游了 5 级分页内核侧位, 自 2019 年起在 Linux 5.5 中默认启用. 一段时间以来, 英特尔 CPU(自 Ice Lake 以来)也支持 5 级分页, 自 Zen 4 以来也支持 AMD CPU. Linux 内核可能会无条件地启用对 x86_64 内核构建的 5 级分页支持. 参见 phoronix 报道 [Linux Looking To Make 5-Level Paging Support Unconditional For x86_64 Kernel Builds](https://www.phoronix.com/news/Linux-Unconditional-5-Level-x86).
+
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2017/03/13 | "Kirill A. Shutemov" | [x86: 5-level paging enabling for v4.12, Part 1](https://lore.kernel.org/patchwork/patch/769534) | NA| v1 ☑ 4.12-rc1 | [PatchWork 0/6](https://lore.kernel.org/patchwork/patch/769534) |
@@ -4195,7 +4198,7 @@ Meta(原 Facebook) 博客 [Transparent memory offloading: more memory at a fract
* process_mrelease
-华为终端手机上实现了一个名为 [xreclaimer(Fast process memory reclaimer)](https://github.com/gatieme/MobileModels/blob/huawei/noh-mate40/mm/xreclaimer) 快速回收进程内存的方案, 在进程退出时快速回收.
+华为终端手机上实现了一个名为 [xreclaimer(Fast process memory reclaimer)](https://github.com/gatieme/MobileModels/blob/huawei/noh-mate40/mm/xreclaimer) 快速回收进程内存的方案, 在进程退出时快速回收. 通过 `/proc/sys/kernel/boost_sigkill_free` 动态开关.
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
@@ -4314,6 +4317,7 @@ swappiness 参数值可设置范围在 `0~100` 之间.
列表的相对值是通过查看我们已经旋转回活动列表而不是驱逐的页面的部分来确定的. %[0] 指定对匿名页 LRUs 施加多大压力, 而 %[1] 确定对文件 LRUs 施加多大压力. | v12 ☑ [2.6.28-rc1](https://kernelnewbies.org/Linux_2_6_28#Various_core) | [PatchWork v2](https://lore.kernel.org/patchwork/patch/118966), [关键 commit](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4f98a2fee8acdb4ac84545df98cccecfd130f8db) |
| 2021/07/27 | Rik van Riel | [mm: Enable suspend-only swap spaces](https://lore.kernel.org/patchwork/patch/1468228) | 引入一个新的 SWAP_FLAG_HIBERNATE_ONLY 添加一个交换区域, 但是不允许进行通用交换, 只能在 SUSPEND/HIBERNATE 时挂起到磁盘时使用. 目前不能在不启用特定区域的通用交换的情况下启用休眠, 对此的一种半变通方法是将对 swapon() 的调用延迟到尝试休眠之前, 然后在休眠完成之后调用 swapoff(). 这有点笨拙, 而且在保持交换脱离 hibernate 区域方面也不起作用. 目前 SWAP_FLAG_HIBERNATE_ONLY 设置的交换区域将不会出现在 SwapTotal 和 SwapFree 下的 /proc/meminfo 中, 因为它们不能作为常规交换使用, 但是这些区域仍然出现在 /proc/swap 中. | v4 ☐ | [PatchWork v4](https://lore.kernel.org/patchwork/patch/1468228) |
| 2022/02/17 | Peter Xu | [mm: Rework zap ptes on swap entries](https://patchwork.kernel.org/project/linux-mm/cover/20220217060746.71256-1-peterx@redhat.com/) | 615245 | v5 ☐☑ | [LORE v5,0/4](https://lore.kernel.org/r/20220217060746.71256-1-peterx@redhat.com) |
+| 2024/01/03 | Dan Schatzberg | [Add swappiness argument to memory.reclaim](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=49003d83c7dabf67036c4523d9907b16fde9cb24) | 向 `memory.reclaim` 添加 `swappiness=` 参数支持. 这实际上允许对交换行为进行更精细的控制，而不会覆盖全局交换设置.
允许主动回收器向 memory.reclaim 提交额外的 swappiness=[val] 参数. 这将覆盖该回收尝试的全局或每个 memcg 交换设置. 如果 `echo "2M swappiness=0" > /sys/fs/cgroup/memory.reclaim` 将在 Root CGROUP 上执行回收, 交换设置为 0(无交换), 而不考虑 `vm.swappiness` 设置. 用户空间主动回收器使用 memory.reclaim 接口来触发回收. memory.reclaim 接口不允许在主动回收期间以任何方式影响文件与匿名的平衡. 唯一的方法是调整 vm.swappiness 设置. 参见 phoronix 报道 [Linux 6.11 To Offer More Fine-Tuned Control Over Swappiness](https://www.phoronix.com/news/Linux-6.11-Fine-Swappiness). | v6 ☐☑✓ | [LORE v6,0/2](https://lore.kernel.org/all/20240103164841.2800183-1-schatzberg.dan@gmail.com) |
## 5.2 MEMCG Swap
diff --git a/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md b/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md
index f9ca89d..c0df56a 100644
--- a/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md
+++ b/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md
@@ -109,7 +109,7 @@
| 6.7 | NA | NA | NA |
| 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) |
+| 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) |
年终盘点
diff --git a/study/kernel/00-DESCRIPTION/README.md b/study/kernel/00-DESCRIPTION/README.md
index 98db496..306d205 100644
--- a/study/kernel/00-DESCRIPTION/README.md
+++ b/study/kernel/00-DESCRIPTION/README.md
@@ -296,6 +296,8 @@ Linux 内核特性演进史
[Linux 内核学习资料：200 + 篇经典内核文章，100 + 篇内核论文，50 + 内核项目，500 + 道内核面试题，80 + 内核讲解视频](https://github.com/0voice/linux_kernel_wiki)
+[新版图书--《操作系统：原理与实现》--银杏树](https://ipads.se.sjtu.edu.cn/ospi)
+
# 3 内容目录
-------
diff --git a/study/kernel/00-DESCRIPTION/SCHEDULER.md b/study/kernel/00-DESCRIPTION/SCHEDULER.md
index cbe4912..a0c2c28 100644
--- a/study/kernel/00-DESCRIPTION/SCHEDULER.md
+++ b/study/kernel/00-DESCRIPTION/SCHEDULER.md
@@ -357,6 +357,7 @@ SCHED_IDLE 跟 SCHED_BATCH 一样, 是 CFS 中的一个策略, SCHED\_IDLE 的
|:----:|:----:|:---:|:---:|:-----------:|:---:|
| 2021/08/20 | Josh Don |[cgroup SCHED_IDLE support/SCHED_IDLE extensions](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=304000390f88d049c85e9a0958ac5567f38816ee) | 1. cgroup [组支持 SCHED_IDLE](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=304000390f88)
2. RQ 上维护了 [idle_nr_running](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a480addecc0d) 的跟踪.
3. 引入 [`sysctl_sched_idle_min_granularity`](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=51ce83ed523b), 当 SCHED_IDLE 任务与正常任务竞争时适用, 表示 SCHED_IDLE 任务的最小抢占粒度. 这样在与普通实体竞争时, 通过对 SCHED_IDLE 的调度实体使用较小的、无伸缩性的最小抢占粒度 (由 sched_slice 计算). 可以减少普通调度实体切回来的延迟, 但代价是增加了 SCHED_IDLE 实体的上下文切换频率. 有效地减少了普通调度实体在与 SCHED_IDLE 调度实体竞争时的轮询延迟.
4. 在 place_entity() 中对于 `SCHED_IDLE` 实体唤醒时得到的补偿减少到 `sysctl_sched_min_granularity`. 因此, 唤醒的 SCHED_IDLE 实体将花费更长的时间来抢占正常实体. 此更改的好处是, 降低了新唤醒的 `SCHED_IDLE` 实体在阻塞之前抢占短期运行的普通调度实体的可能性. | v3 ☑ [5.15-rc1](https://kernelnewbies.org/LinuxChanges#Linux_5.15.cgroup_support_for_SCHED_IDLE) | [2021/06/08 v1](https://lore.kernel.org/lkml/20210608231132.32012-1-joshdon@google.com)
*-*-*-*-*-*-*-*
[2021/7/29 LKML v2 0/2](https://lkml.org/lkml/2021/7/29/1201)
*-*-*-*-*-*-*-*
[2021/08/20 LORE v3,0/4](https://lore.kernel.org/all/20210820010403.946838-1-joshdon@google.com)
*-*-*-*-*-*-*-*
[关键 commit](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=304000390f88d049c85e9a0958ac5567f38816ee) |
| 2022/10/27 | Chuyi Zhou | [sched/fair: favor non-idle group in tick preemption](https://lore.kernel.org/all/20221027081630.34081-1-zhouchuyi@bytedance.com) | [commit 304000390f88 ("sched: Cgroup SCHED_IDLE support")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=304000390f88d049c85e9a0958ac5567f38816ee) 在支持了 group 级别的 SCHED_IDLE 时, 在 check_preempt_wakeup() 路径下, 实现了 SCHED_IDLE 的感知, 总是 [倾向于抢占空闲的 group sched_entity 而不是非空闲 group sched_entity 组](https://elixir.bootlin.com/linux/v5.15/source/kernel/sched/fair.c#L7125), 反之不允许抢占. 但是 check_preempt_tick() 中却没有感知 SCHED_IDLE, 类似地非空闲的 sched_entity 相对于空闲 sched_entity 应该更具有竞争优势. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20221027081630.34081-1-zhouchuyi@bytedance.com) |
+| 2024/06/24 | Tianchen Ding | [sched/fair: Make SCHED_IDLE se be preempted in strict hierarchy](https://lore.kernel.org/all/20240624073900.10343-1-dtcccc@linux.alibaba.com) | 考虑如下分组配置情况, ROOT 分组下, 有一个 normal_group, 但是其中有一个 SCHED_IDLE 的任务 A, 还有一个 idle_cgroup, 其中有一个 SCHED_NORMAL 的任务 B. 正常情况下 A 应抢占 B. check_preempt_wakeup_fair() 将 cgroup se 和任务分开处理, 因此 B 会意外抢占 A 的位置. 仅通过 {p}se_is_idle 统一唤醒逻辑. 同时修正了一个关于 se_is_idle() 定义的 bug，当 !config_fair_group_sched. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240624073900.10343-1-dtcccc@linux.alibaba.com) |
#### 1.1.5.5 Idle Injection Framework
@@ -1023,6 +1024,7 @@ v3.8 合入了 [LWN-2013/01/29, Per-entity load tracking](https://lwn.net/Articl
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2012/08/23 | pjt@google.com | [sched: per-entity load-tracking](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=e9c84cb8d5f1b1ea6fcbe6190d51dc84b6975938) | PELT | v1 ☐☑✓ | [LORE v1,0/16](https://lore.kernel.org/all/20120823141422.444396696@google.com) |
| 2018/04/09 | Patrick Bellasi | [sched/fair: add support to tune PELT ramp/decay timings](https://lore.kernel.org/all/20180409165134.707-1-patrick.bellasi@arm.com) | 内核支持不同的 PELT 半衰期设置, 通过 CONFIG_PELT_HALFLIFE_32/CONFIG_PELT_HALFLIFE_16/CONFIG_PELT_HALFLIFE_8 选择. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20180409165134.707-1-patrick.bellasi@arm.com) |
+| 2019/01/16 | [sched/fair: update scale invariance of PELT](https://lore.kernel.org/patchwork/cover/1034952) | 内核支持不同的 PELT 半衰期设置 | v9 ☑ 5.1-rc1 | [v3](https://lore.kernel.org/lkml/1493389435-2525-1-git-send-email-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[v9](https://lore.kernel.org/lkml/1548257214-13745-1-git-send-email-vincent.guittot@linaro.org) |
| 2022/08/29 | Dietmar Eggemann | [sched/pelt: Change PELT halflife at runtime](https://lore.kernel.org/all/20220829055450.1703092-1-dietmar.eggemann@arm.com) | [sched/pelt: Introduce PELT multiplier](https://lore.kernel.org/all/20220829055450.1703092-1-dietmar.eggemann@arm.com) 允许系统运行时设置 PELT 的半衰期. 新的 sysctl sched_pelt_multiplier 允许用户将时钟乘数设置为 x1, x2 或 x4. 该时钟倍增器 (clock multiplier artificially) 加速 PELT 斜坡上升 / 下降, 它将影响 PELT 的半衰期 (x1 对应 32ms, x2 对应 16ms, x3 对应 8ms). | v1 ☐☑✓ | [LORE v1,1/1](https://lore.kernel.org/all/20220829055450.1703092-2-dietmar.eggemann@arm.com) |
| 扩展资料 | 描述 |
@@ -1447,6 +1449,7 @@ X86 下提供了一种 Fake Numa 的方式来模拟 NUMA 配置.
| 2011/01/19 | Jan Beulich | [x86: Unify"numa="command line option handling](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9032160275ba) | 使用 `numa=` 内核启动参数统一管理 NUMA 配置. | v1 ☐☑✓ | [LORE](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9032160275ba) |
| 2011/02/14 | Tejun Heo | [x86-64, NUMA: bring sanity to NUMA emulation](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=e23bba604433a202cd301a976454a90ea6b783ef) | TODO | v1 ☑✓ 2.6.39-rc1 | [LORE](https://lore.kernel.org/all/1297711715-3086-1-git-send-email-tj@kernel.org) |
| 2012/05/01 | Peter Zijlstra | [x86/numa: Allow specifying node_distance() for numa=fake](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=ad7687dde8780a0d618a3e3b5a62bb383696fc22) | TODO | v1 ☑✓ 3.5-rc1 | [LORE v1,0/5](https://lore.kernel.org/all/20120501181430.007891123@chello.nl) |
+| 2024/06/25 | Tvrtko Ursulin | [NUMA emulation for arm64](https://lore.kernel.org/all/20240625125803.38038-1-tursulin@igalia.com) | [UMA Emulation Yields "Significant Performance Uplift" To Raspberry Pi 5](https://www.phoronix.com/news/ARM64-NUMA-Emulation-RPi5). | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20240625125803.38038-1-tursulin@igalia.com) |
### 4.1.4 NUMA Distance
@@ -3835,10 +3838,11 @@ Chen Yu 新的思路是, 首先在 SMT 域中扫描一个空闲的同级节点.
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2023/02/03 | Chen Yu | [sched/fair: Introduce SIS_CURRENT to wake up short task on current CPU](https://lore.kernel.org/lkml/cover.1682661027.git.yu.c.chen@intel.com) | v7 之前 title [sched/fair: Wake short task on current CPU](https://lore.kernel.org/all/cover.1675361144.git.yu.c.chen@intel.com), 其主要目的是避免在不必要时出现过多的跨 CPU 唤醒. 频繁的跨 CPU 唤醒会对某些工作负载造成严重损害, 尤其是在高核心数系统上. 如果唤醒和唤醒都是短时任务, 则通过将唤醒置于唤醒 CPU 上来禁止跨 CPU 唤醒. 短时间的任务可能会成为高负载系统的麻烦制造者, 因为它会带来频繁的上下文切换. 因此, 此策略仅在系统繁忙时生效. 此外, 当仍有空闲 CPU 时, 禁止空闲 CPU 扫描是不合理的. 首先利用第一个补丁 [sched/fair: Record the average duration of a task](https://lore.kernel.org/all/155aa36ba14b8a1f8e6c3ccda7999125edfff990.1675361144.git.yu.c.chen@intel.com) 跟踪任务的平均运行时间 dur_avg, 从而更好地定义小任务. 然后选择本地 CPU 进行唤醒. 测试发现, Intel 2 x 56C/112T 平台的性能有了显著提高. 例如, 在某些情况下, 它将缩放 (1200+%), netperf(600+%). 商业 RDBMS 对 schbench、hacksbench、tbench 和 OLTP 工作负载没有明显影响. 参见 phoronix 报道 [Linux Performance Patches Revved To Avoid Too Many Unnecessary Cross-CPU Wake-ups](https://www.phoronix.com/news/Linux-Wake-Short-Task-CPU). | v5 ☐☑✓ | [LORE](https://lore.kernel.org/all/20220915165407.1776363-1-yu.c.chen@intel.com)
*-*-*-*-*-*-*-*
[LORE v2,0/2](https://lore.kernel.org/all/cover.1666531576.git.yu.c.chen@intel.com)
*-*-*-*-*-*-*-*
[LORE v5,0/2](https://lore.kernel.org/all/cover.1675361144.git.yu.c.chen@intel.com)
*-*-*-*-*-*-*-*
[LORE v6,0/2](https://lore.kernel.org/all/cover.1677069490.git.yu.c.chen@intel.com)
*-*-*-*-*-*-*-*
[LORE v7,0/2](https://lore.kernel.org/all/cover.1682060436.git.yu.c.chen@intel.com)
*-*-*-*-*-*-*-*
[LORE v8,0/2](https://lore.kernel.org/all/cover.1682661027.git.yu.c.chen@intel.com) |
-| 2023/03/27 | Aaron Lu | [sched/fair: Make tg->load_avg per node](https://lore.kernel.org/all/20230327053955.GA570404@ziqianlu-desk2) | 使用 sysbench 在一个 docker 实例中对 Postgres 进行基准测试, 并将 sysbench 的 nr_threads 设置为 nr_cpu 时, 可以观察到 update_cfs_group() 和 update_load_avg() 在一个 2sockets/112core/224cpu 的 Intel Sapphire Rapids 节点上显示了明显的 cpu 开销 (10% 和 7.8%), 而在另一个节点的 cpu 的热点通常较低 (4% 和 3%). 分析发现热点主要是访问 tg->load_avg, 其中 update_load_avg() 是写端, update_cfs_group() 是读端.
为什么只有一个节点的 CPU 有更大的开销, 原因是: task_group 是根据需要从 slab 分配的, 无论哪个 CPU 进行分配, 分配的 tg 将位于该节点上, 访问 tg->load_avg 将对同一节点上的 CPU 有更低的成本, 而对远程节点的 CPU 有更高的成本.
Tim Chen 告诉我, PeterZ 曾经提到过一种解决类似问题的方法, 即为每个节点设置一个计数器, 所以对 tg->load_avg 也做同样的事情.
优化后, 这两个节点上运行 5 分钟所看到的最坏的情况占比也才 2%.
针对这个工作负载有另外一个发现: 这个工作负载存在有很多唤醒时的任务迁移, 这就是为什么 update_load_avg() 和 update_cfs_group() 显示出明显的成本. 在 N 个实例中运行这个工作负载, 其中 N >= 2, sysbench 的 nr_threads 设置为 1/N nr_cpu, 在唤醒时间上的任务迁移大大减少, 上面提到的两个函数的开销也下降了很多. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20230327053955.GA570404@ziqianlu-desk2) |
+wojiush| 2023/03/27 | Aaron Lu | [sched/fair: Make tg->load_avg per node](https://lore.kernel.org/all/20230327053955.GA570404@ziqianlu-desk2) | 使用 sysbench 在一个 docker 实例中对 Postgres 进行基准测试, 并将 sysbench 的 nr_threads 设置为 nr_cpu 时, 可以观察到 update_cfs_group() 和 update_load_avg() 在一个 2sockets/112core/224cpu 的 Intel Sapphire Rapids 节点上显示了明显的 cpu 开销 (10% 和 7.8%), 而在另一个节点的 cpu 的热点通常较低 (4% 和 3%). 分析发现热点主要是访问 tg->load_avg, 其中 update_load_avg() 是写端, update_cfs_group() 是读端.
为什么只有一个节点的 CPU 有更大的开销, 原因是: task_group 是根据需要从 slab 分配的, 无论哪个 CPU 进行分配, 分配的 tg 将位于该节点上, 访问 tg->load_avg 将对同一节点上的 CPU 有更低的成本, 而对远程节点的 CPU 有更高的成本.
Tim Chen 告诉我, PeterZ 曾经提到过一种解决类似问题的方法, 即为每个节点设置一个计数器, 所以对 tg->load_avg 也做同样的事情.
优化后, 这两个节点上运行 5 分钟所看到的最坏的情况占比也才 2%.
针对这个工作负载有另外一个发现: 这个工作负载存在有很多唤醒时的任务迁移, 这就是为什么 update_load_avg() 和 update_cfs_group() 显示出明显的成本. 在 N 个实例中运行这个工作负载, 其中 N >= 2, sysbench 的 nr_threads 设置为 1/N nr_cpu, 在唤醒时间上的任务迁移大大减少, 上面提到的两个函数的开销也下降了很多. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20230327053955.GA570404@ziqianlu-desk2) |
| 2023/05/16 | Chen Yu | [sched/fair: Introduce SIS_PAIR to wakeup task on local idle core first](https://lore.kernel.org/all/20230516011159.4552-1-yu.c.chen@intel.com) | 在 SMT 域中扫描一个空闲的同级节点. 在之前的上下文切换周期中, 如果唤醒器和唤醒器相互唤醒, 则它们可能共享资源, 并且可以将唤醒器放在唤醒器旁边的空闲兄弟节点上, 以避免 C2C 开销. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20230516011159.4552-1-yu.c.chen@intel.com) |
| 2023/09/12 | Aaron Lu | [Reduce cost of accessing tg->load_avg](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=1528c661c24b407e92194426b0adbb43de859ce0) | [New Scheduler Optimization Can Help Out PostgreSQL & More On Sapphire Rapids](https://www.phoronix.com/news/Linux-Sched-Postgres-SPR) | v2 ☐☑✓ | [LORE v2,0/1](https://lore.kernel.org/all/20230912065808.2530-1-aaron.lu@intel.com) |
| 2023/11/21 | Chen Yu | [Introduce SIS_CACHE to choose previous CPU during task wakeup](https://lore.kernel.org/all/cover.1700548379.git.yu.c.chen@intel.com) | [Makes it easier for the wakee to choose previous CPU](https://lore.kernel.org/all/cover.1694397335.git.yu.c.chen@intel.com) 的新版本. 本系列旨在继续讨论如何使唤醒更容易地选择以前的 CPU. 当任务 p 被唤醒时, 调度程序会利用 select_idle_sbling() 为其查找空闲 CPU. 任务 P 的前一个 CPU 通常是首选, 因为它可以提高缓存的局部性. 然而, 在许多情况下, 前一个 CPU 已经被其他唤醒占用, 因此任务 P 必须找到另一个空闲 CPU. 禁止任务迁移可以使许多工作负载受益. 受 Mathieu 关于限制任务迁移率的建议 [sched/eevdf: Rate limit task migration](https://lore.kernel.org/lkml/20230905171105.1005672-2-mathieu.desnoyers@efficios.com) 的启发, 引入了 SIS_CACHE. 它考虑了任务的睡眠时间, 以便更好地安排任务. 根据任务的短暂睡眠历史, 将 P 的前一个 CPU 标记为缓存热. 稍后当 P 被唤醒时, 它可以在 select_idle_sbling() 中选择其上一个 CPU. 当其他任务被唤醒时, 跳过此缓存热空闲 CPU, 并在可能的情况下尝试下一个空闲 CPU. SIS_CACHE 的思想是优化空闲 CPU 扫描序列. 通过将高速缓存热 CPU 的扫描深度限制为 SIS_UTIL 扫描深度的 50%, 可以最大限度地减少额外的扫描时间. | v2 ☐☑✓ |[2023/09/11, LORE v1,0/2](https://lore.kernel.org/all/cover.1694397335.git.yu.c.chen@intel.com)
*-*-*-*-*-*-*-*
[LORE v2,0/3](https://lore.kernel.org/all/cover.1700548379.git.yu.c.chen@intel.com) |
+| 2023/09/11 | Chen Yu | [Makes it easier for the wakee to choose previous CPU](https://lore.kernel.org/all/cover.1694397335.git.yu.c.chen@intel.com) | 当任务 P 被唤醒时, 调度程序会利用 select_idle_sibling() 为其寻找空闲的 CPU. 因为它可以提高缓存的本地性. 但在很多情况下前一个 CPU 已被其他唤醒器占用, 因此 P 必须寻找另一个空闲的 CPU. 在保持调度器工作保护的同时, 引入任务迁移可以使许多工作负载受益. 受 Mathieu 关于限制任务迁移率 [sched/eevdf: Rate limit task migration](https://lore.kernel.org/lkml/20230905171105.1005672-1-mathieu.desnoyers@efficios.com) 的启发，本补丁考虑了任务的平均睡眠时间. 如果任务的睡眠时间较短, 则会将其上一个 CPU 标记为缓存热区, 并持续一小段时间. 在标记期间, 其他唤醒者不得使用该空闲 CPU, 直到超时为止. 之后, 如果该任务再次被唤醒, 它就会发现之前的 CPU 仍处于空闲状态, 并在 select_idle_sibling() 中选择它. | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/cover.1694397335.git.yu.c.chen@intel.com) |
### 4.7.5 sync wakeup
@@ -5243,6 +5247,19 @@ $Pdyn = C \times V^2 \times f = dynamic-power-coefficient \times V^2 \times f$
| 2015/11/17 | Punit Agrawal | [Platform support for thermal management on Junoe](https://lore.kernel.org/all/1447761983-12415-1-git-send-email-punit.agrawal@arm.com) | 该系列增加了对 ARM Juno 开发平台上热管理的支持. 添加了最基础的公共设施, 以支持注册与电源分配器热调控器一起工作的 CPU cooling device. | v5 ☐☑✓ | [LORE 0/9](https://lore.kernel.org/all/1437573763-6525-1-git-send-email-punit.agrawal@arm.com)
*-*-*-*-*-*-*-*
[LORE v2,00/10](https://lore.kernel.org/all/1438615378-14241-1-git-send-email-punit.agrawal@arm.com) |
| 2015/11/17 | Punit Agrawal | [Dynamic power model from device tree](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=2f7e8a175db72bdaf377235962fd85796edb3fbc) | 该补丁集为 CPU 构建单系数动态功率模型提供了支持. CPU 冷却设备使用该模型来提供功耗的估计, 并将分配的功率转换为性能上限.
[补丁 1](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3be3f8f36e7349006f19c8c8f0d686e98462a993) 扩展了 CPU DTS 节点, 增加可选的 dynamic-power-coefficient 字段用来提供动态功率系数, 该系数可用于为 CPU 创建动态功率模型. 当系统受到热管控时, 该模型用于限制设备的功耗 (使用 power_allocator 调控器).
补丁 2-3 扩展了 cpufreq-dt 和 arm_big_little CPUFREQ 驱动程序, 在提供动态系数的情况下注册 CPU cooling device. | v5 ☑✓ 4.5-rc1 | [LORE 0/9](https://lore.kernel.org/all/1437573763-6525-1-git-send-email-punit.agrawal@arm.com)
*-*-*-*-*-*-*-*
[LORE v2,00/10](https://lore.kernel.org/all/1438615378-14241-1-git-send-email-punit.agrawal@arm.com)
*-*-*-*-*-*-*-*
[LORE v3,0/3](https://lore.kernel.org/all/1447090163-13700-1-git-send-email-punit.agrawal@arm.com)
*-*-*-*-*-*-*-*
[LORE v4,0/3](https://lore.kernel.org/all/1447702225-13323-1-git-send-email-punit.agrawal@arm.com)
*-*-*-*-*-*-*-*
[LORE v5,0/3](https://lore.kernel.org/all/1447761983-12415-1-git-send-email-punit.agrawal@arm.com) |
+#### 7.2.6.5 Workload Hints
+-------
+
+
+> 数字线性电压调节器 DLVR 是 Meteor Lake 的一项功能(最初在 Raptor Lake 中发现, 但已禁用)作为附加电压调节器, 可以帮助降低处理器的功耗. 参见 phoronix 报道 [Linux Patches Posted For Intel Lunar Lake DLVR Support](https://www.phoronix.com/news/Intel-Lunar-Lake-DLVR-Linux).
+
+
+ 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:---:|:----:|:---:|:----:|:---------:|:----:|
+| 2024/06/19 | Srinivas Pandruvada | [Processor thermal interrupts for Lunar Lake](https://lore.kernel.org/all/20240619172109.497639-1-srinivas.pandruvada@linux.intel.com) | 用于处理器热中断的 Lunar Lake 补丁, 增加了对工作负载提示(WLT)的支持和对英特尔 int340x 驱动程序的电源底支持. 对 Lunar Lake 的热中断支持进行了全面检查, 热设备不再支持传统的 PCI 中断. 取而代之的是, MSI 源依赖于封装热、DDR 热、电源底和工作负载类型提示. 参见 phoronix 报道 [Intel Lunar Lake Workload Hints & Power Floor Patches Posted For Linux](https://www.phoronix.com/news/Intel-LunarLake-WLT-Power-Floor). | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20240619172109.497639-1-srinivas.pandruvada@linux.intel.com) |
+| 2023/08/28 | Srinivas Pandruvada | [thermal: processor_thermal: Suport workload hint](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=27801542b2b815dad2759b7b1f85858627671a3b) | [Linux 6.7 Adds Support For Intel Meteor Lake Workload Type Hints](https://www.phoronix.com/news/Linux-6.7-Power-Management) | v3 ☐☑✓ v6.7-rc1 | [LORE v3,0/7](https://lore.kernel.org/all/20230829002346.2104251-1-srinivas.pandruvada@linux.intel.com) |
+
+
### 7.2.7 OPP(Operating Performance Points)
-------
@@ -5367,7 +5384,6 @@ v4.4 [Compute capacity invariant load/utilization tracking](https://git.kernel.o
|:----:|:----:|:---:|:------:|:---:|
| 2012/8/23 | [consolidation of CPU capacity and usage](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=dfbca41f347997e57048a53755611c8e2d792924) | CPU 调频会导致 CPU capacity 的变化, 在支持 DVFS 的系统还用最大 capacity 计算负载是不合理的, 因此 PELT 需要感知 capacity 的变化, 即 FIE(Frequency Invariance Engine). [使得 sched entity usage tracking(即 running_avg_sum 与 running_avg 等) 感知 DVFS](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c1dc6b27dac883ee78392189c8e20e764d79bfa). 通过借助 scale_freq = arch_scale_freq_capacity(NULL, cpu) 来实现. | v10 ☑ 4.1 | [LORE v10,00/11](https://lore.kernel.org/all/1425052454-25797-1-git-send-email-vincent.guittot@linaro.org), [LKML](https://lkml.org/lkml/2015/2/27/309) |
| 2015/8/14 | [Compute capacity invariant load/utilization tracking](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=98d8fd8126676f7ba6e133e65b2ca4b17989d32c) | PELT 支持 Capacity Invariant Engine. PELT 只感知频率的变化是不够的, 同架构但是不同微架构 (比如 big.LITTLE 的小核和大核虽然都使用 ARM 架构, 但是是性能异构的) 的 CPU 即使处于相同频点下, 所能提供的计算能力 capacity 也是不同的. 因此 PELT 也需要感知对不同微架构 CPU capacity 的差异. 通过借助 scale_cpu = arch_scale_cpu_capacity(NULL, cpu) 来实现. | v1 ☑4.4 | [LWN](https://lwn.net/Articles/531853), [LORE 0/6](https://lore.kernel.org/patchwork/cover/590249), [LKML](https://lkml.org/lkml/2015/8/14/296) |
-| 2019/01/16 | [sched/fair: update scale invariance of PELT](https://lore.kernel.org/patchwork/cover/1034952) | v9 ☑ 5.1-rc1 | [v3](https://lore.kernel.org/patchwork/patch/784059)
*-*-*-*-*-*-*-*
[v9](https://lore.kernel.org/patchwork/cover/1034952) |
### 7.4.2 ARM64 FIE
@@ -5513,6 +5529,11 @@ v5.15 合入的 [Add support for 32-bit tasks on asymmetric AArch32 systems](htt
## 7.8 关联线程组 RTG
-------
+
+### 7.8.1 QCOM RTG(Related Thread Group)
+-------
+
+
RTG(Related Thread Group) 是高通为 ANDROID 提供的芯片解决方案中的一个调度关键特性, 提供了对一组线程进行 (精准) 资源供给 (大小核, 频率等) 的能力.
参见 [微信公众号 - 内核工匠 - 调度器分支之 RTG](https://mp.weixin.qq.com/s/SOAmKof5xiDJ-OFx7Zqh-g)
@@ -5531,6 +5552,15 @@ ANDROID 上很多实际应用场景, 比如说绘帧等, 往往是由多个线
3. Busy Hysteresis 优化: 通过预制的每一个 CPU 的 capactity 的阈值, 当 CPU 的负载大于这个阈值的时候, 会迟滞一定的时间, 不让 CPU 进入 LPM 模式 (low power mode). CPU IDLE 是进入 LPM, 分多个等级, 层级越高越省电, 但是相应的睡眠跟唤醒的时延越高. 因此当一个 CPU 的负载较重的时候, 即使可以短暂的进入 LPM 模式, 大概率也会很快因为有任务需要运行而退出, 并且对于处于 RTG 的关键业务来说, 唤醒的时延过长, 则实时性得不到保证. 绘帧等场景, 对时延要求极其敏感, 特别是对于 120MHZ 的刷新率来说, 稍有不慎, 就会造成丢帧.
+
+### 7.8.2 HUAWEI RTG
+-------
+
+
+
+
+
+
## 7.9 Core Control Isolation
------
@@ -6058,6 +6088,8 @@ PREEMPT-RT PATCH 的核心思想是最小化内核中不可抢占部分的代码
两年后, 2022 年, Vincent Guittot 在 Parth Shah 工作的基础上, 重提了 [Add latency_nice priority](https://lore.kernel.org/all/20220311161406.23497-1-vincent.guittot@linaro.org).
+[latency-nice优先级补丁源码分析](https://blog.csdn.net/qq_23662505/article/details/123977540)
+
* 唤醒抢占时考虑 latency_nice
调度路径上考虑 latency_nice 的优先唤醒和执行, 是通过修改 wakeup_preempt_entity() 感知 latency_nice 来完成的. wakeup_preempt_entity() 检查唤醒抢占的时候, 本身只比较两个进程的 vruntime, 现在进一步通过 wakeup_latency_gran() 比较两个进程的 latency_nice.
@@ -6102,6 +6134,7 @@ enqueue_task_fair()
| 2020/02/28 | Parth Shah | [Introduce per-task latency_nice for scheduler hints](https://lore.kernel.org/all/20200228090755.22829-1-parth@linux.ibm.com) | 20200228090755.22829-1-parth@linux.ibm.com | v5 ☐☑✓ | [LORE v4,0/4](https://lore.kernel.org/lkml/20200224085918.16955-1-parth@linux.ibm.com)
*-*-*-*-*-*-*-*
[LORE v5,0/4](https://lore.kernel.org/all/20200228090755.22829-1-parth@linux.ibm.com) |
| 2020/05/07 | Parth Shah | [IDLE gating in presence of latency-sensitive tasks](https://lore.kernel.org/all/20200507133723.18325-1-parth@linux.ibm.com) | 20200507133723.18325-1-parth@linux.ibm.com | v1 ☐☑✓ | [LORE v1,0/4](https://lore.kernel.org/all/20200507133723.18325-1-parth@linux.ibm.com) |
| 2022/09/16 | Vincent Guittot | [Add latency_nice priority](https://lore.kernel.org/all/20220311161406.23497-1-vincent.guittot@linaro.org) | 参见 [Improved response times with latency nice](https://lwn.net/Articles/887842). | v1 ☐☑✓ | [2022/03/11 LORE v1,0/6](https://lore.kernel.org/all/20220311161406.23497-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/05/12 LORE v2,0/7](https://lore.kernel.org/all/20220512163534.2572-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/09/09 LORE v3,0/8](https://lore.kernel.org/all/20220909130309.25458-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/09/16 LORE v4,0/8](https://lore.kernel.org/all/20220916080305.29574-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/09/25 LORE v5,0/8](https://lore.kernel.org/all/20220925143908.10846-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/10/28 LORE v6,0/9](https://lore.kernel.org/all/20221028073637.31195-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/10/28 LORE v7,0/9](https://lore.kernel.org/all/20221028093403.6673-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/11/10 LORE v8,0/9](https://lore.kernel.org/all/20221110175009.18458-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/11/15 LORE v9,0/9](https://lore.kernel.org/all/20221115171851.835-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2023/01/13 LORE v10,0/9](https://lore.kernel.org/all/20230113141234.260128-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2023/02/23 LORE v11,0/9](https://lore.kernel.org/all/20230223191041.577305-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2023/02/24 LORE v12,0/8](https://lore.kernel.org/all/20230224093454.956298-1-vincent.guittot@linaro.org) |
+| 2024/05/05 | fuyuanli | [sched: Introduce task_struct::latency_sensi_flag.](https://lore.kernel.org/all/20240505030615.GA5131@didi-ThinkCentre-M920t-N000) | 在 `local_bh_enable()->__local_bh_enable_ip()` 路径下, softirq 处理程序将在当前任务的上下文中执行. 但对于某些 对运行延迟敏感的任务, 我们希望它们不会花费额外的时间来执行 softirq. 额外时间来执行 softirq. 因此, 我们在 任务结构中引入了 latency_sensi_flag, 当设置为 1 时, 任务只会在 local_bh_enable_ip()中唤醒 softirq 守护进程.
在名为 A 和 B 的两台主机上进行了测试. 以最快速度同时向 B 中的一台服务器发送 udp 数据包. 数据包. 在 B 中, 这些数据流的 IRQ 被 flow 在 B 中, 这些数据流的 IRQ 被 flow director 绑定到 CPU 0, 因此 CPU 0 上总有一个被触发的 net_rx softirq. 在 B 中启动一个测试程序, 该程序也绑定到 CPU 0, 并在 B 中不断调用 sendto() 不断循环调用 sendto(). 使用 perf 采样, 结果显示 测试程序约 25% 的运行时间用于执行 sendto()中的 local_bh_enable(), 但在设置了 latency_sensi_flag为1后, 这一比例降至0.5%. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240505030615.GA5131@didi-ThinkCentre-M920t-N000) |
@@ -6538,6 +6571,19 @@ linux 下, reaper 线程用于释放已经执行结束的线程所占用的资
3. 否则, 父亲的祖先将成为孩子们的 reaper.
+#### 10.1.3.3 快杀
+-------
+
+Huawei CONFIG_BOOST_KILL 用来在进程接收到 `KILL -9` 信号时, 临时提高其优先级为 `NICE -20`, 并且将其绑定到中大核上, 通过 `/proc/sys/kernel/boost_killing` 进行动态开关. 参见 [hisi-4.1, complete_signal(), kernel/signal.](https://github.com/gatieme/MobileModels/blob/huawei/HISI-4.1.18-Vicky-Android_7.0-EMUI_5.1-hi3660_KIRIN960-P10_Plus/kernel/signal.c), [hisi-4.4, complete_signal(), kernel/signal.c](https://github.com/gatieme/MobileModels/blob/huawei/HISI-4.4.23-ALP-EMUI10-KIRIN970-MATE10/kernel/signal.c) 和 [hisi-4.14, complete_signal(), kernel/signal.c](https://github.com/gatieme/MobileModels/blob/huawei/HISI-4.14.116-NOH-HMOS2-baltimore_KIRIN9000E-MATE40/kernel/signal.c) .
+
+| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:---:|:----:|:---:|:----:|:---------:|:----:|
+| 2010/05/27 | Luis Claudio R. Goncalves | [oom-kill: give the dying task a higher priority](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=93b43fa55088fe977503a156d1097cc2055449a2) | 在一个负载很重的系统中, 我们观察到, 即使在 oom-killer 选择了一个即将消亡的任务, 但该任务可能需要很长时间才能消亡.
就在向所选任务发送 SIGKILL 之前, Oom-killer 会提高任务的优先级, 以便快速退出, 释放内存. | v1 ☐☑✓ v2.6.36-rc1 | [LORE](https://lore.kernel.org/all/20100527180431.GP13035@uudg.org) |
+
+
+| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:---:|:----:|:---:|:----:|:---------:|:----:|
+| 2015/11/27 | Michal Hocko | [mm, oom: introduce oom reaper](https://lore.kernel.org/all/1448640772-30147-1-git-send-email-mhocko@kernel.org) | OOM 受害者可能需要无限制的时间才能退出, 因为它可能被阻塞在不间断状态中, 等待某个事件(如锁), 而该事件被另一个在页面分配器中循环的任务阻塞.
本补丁通过引入一个专门的内核线程 (oom_reaper) 来降低此类锁定的发生概率, 该线程试图通过抢先获取 oom 受害者所拥有的匿名或已交换的内存来回收额外的内存, 并假设当其所有者被杀死并从用户空间踢出时, 将不再需要这些内存.
有一个值得注意的例外情况, 如果 OOM 受害者正在进行 coreump, 那么结果将是不完整的. 这被认为是一个合理的限制, 因为系统的整体健康比特定应用程序的可调试性更重要. 之所以选择内核线程, 是因为我们需要一种可靠的调用方式, 因此工作队列上下文并不合适, 因为所有工作进程都可能在忙(例如分配内存). | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/1448640772-30147-1-git-send-email-mhocko@kernel.org)[](https://lore.kernel.org/all/1458644426-22973-1-git-send-email-mhocko@kernel.org/) |
### 10.1.4 进程冻结与恢复
@@ -6594,11 +6640,10 @@ Linux [v5.1-rc1](https://kernelnewbies.org/Linux_5.1#Safe_signal_delivery_in_pre
| 2019/04/18 | Christian Brauner | [clone: add CLONE_PIDFD](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b3e5838252665ee4cfa76b82bdf1198dca81e5be) | 为 `clone(2)` 添加了一个 `CLONE_PIDFD` 标志, 它允许检索可用于上述目的的 pid 文件描述符. | v2 ☐☑✓ v5.2-rc1 | [LORE v2,0/5](https://lore.kernel.org/all/20190418101841.4476-1-christian@brauner.io) |
| 2024/02/13 | Christian Brauner | [Move pidfd to tiny pseudo fs](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=cb12fd8e0dabb9a1c8aef55a6a41e2c255fcdf4b) | 这将把 pidfds 从匿名 inode 基础架构转移到一个微小的伪文件系统. 参见 [LWN, 2024/05/31, One more pidfdfs surprise](https://lwn.net/Articles/976125). | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20240213-vfs-pidfd_fs-v1-0-f863f58cfce1@kernel.org) |
-
-## 10.3 IPC
+## 10.2 IPC
-------
-### 10.3.1 Continuation/Activation
+### 10.2.1 Continuation/Activation
-------
[User-level Real-Time Network System on Microkernel-based Operating Systems]()
@@ -6630,7 +6675,7 @@ Linux [v5.1-rc1](https://kernelnewbies.org/Linux_5.1#Safe_signal_delivery_in_pre
2. server 线程唤醒后直接借助 client 的内核栈执行, server 和 client 都使用了 client 的内核栈, 不需要再进行数据传递, 直接调用 server 的 Continuation 返回到用户态执行.
-### 10.3.2 Binder
+### 10.2.2 Binder
-------
@@ -6739,7 +6784,7 @@ Google 的 Peter Oskolkov 发布了 [最早的 RFC v0.1 补丁](https://lore.ker
|:----:|:---:|:----:|
| NSDI '19 | [Shinjuku: preemptive scheduling for µsecond-scale tail latency](https://dl.acm.org/doi/10.5555/3323234.3323264) | 最近提出的用于微秒级应用的数据平面(如 IX 和 ZygOS)使用非抢占式策略为内核调度请求. 在现实世界的许多应用场景中, 请求服务时间的分布具有高度分散性或较重的尾部, 它们允许短请求被阻塞在长请求之后, 从而导致较差的尾部延迟. Shinjuku 是一个单地址空间操作系统, 它利用硬件支持虚拟化, 在微秒级实现抢占. 这使得 Shinjuku 可以实施集中式调度策略, 每 5 微秒抢占一次请求, 并能很好地处理轻度和重度尾部请求服务时间分布. 论文中们证明, 与 IX 和 ZygOS 相比, Shinjuku 能在各种工作负载场景下显著改善尾端延迟和吞吐量. 在 RocksDB 服务器同时处理点查询和范围查询的情况下, Shinjuku 的吞吐量提高了 6.6 倍, 尾部延迟降低了 88%. |
| NA | [LibPreemptible: Enabling Fast, Adaptive, and Hardware-Assisted User-Space Scheduling](https://arxiv.org/abs/2308.02896) | [Towards Fast, Adaptive, and Hardware-Assisted User-Space Scheduling](https://arxiv.org/abs/2308.02896), 现代云应用很容易出现高尾部延迟, 因为它们的请求通常遵循高度分散的分布. 先前的工作提出了操作系统和系统级解决方案, 通过更好的调度来减少微秒级工作负载的尾部延迟. 遗憾的是, 现有的方法(如定制的数据平面操作系统)需要对操作系统进行重大修改, 在可扩展性方面受到限制, 或者无法充分发挥硬件提供的性能.
论文提出了 LibPreemptible, 一个灵活、轻量级、可扩展的抢占式用户级线程库. LibPreemptible 基于三项关键技术:
1. 快速、轻量级的硬件机制, 用于提供定时中断;
2. 通用的用户级调度接口
3. 用户应用程序接口, 用于表达适合其应用需求的自适应调度策略.
与之前最先进的调度系统 Shinjuku 相比, 论文提出的系统无需修改内核即可显著改善各种工作负载的尾部延迟和吞吐量. 还展示了 LibPreemptible 在不同调度策略下的灵活性, 适用于负载水平和特性各不相同的实际应用. |
-| NA | |
+| SOSP '21 | [Syrup: User-Defined Scheduling Across the Stack](https://dl.acm.org/doi/10.1145/3477132.3483548) | SOSP '21: Proceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles 的论文, Syrup 时基于 Ghost 和 eBPF 构建的用户态自定义调度框架, 可使不受信任的应用开发人员在这些系统层之间表达特定于应用的调度策略, 而不必为实现这些策略的底层系统机制所累. 应用程序开发人员使用 Syrup 编写调度策略, 将其作为输入(线程、网络数据包、网络连接)和执行器(内核、网络套接字、网卡队列)之间的一组匹配函数, 然后将其部署到各系统层, 而无需修改代码. Syrup 支持多租户, 因为多个位于同一地点的应用程序可以各自安全可靠地指定自定义策略. 我们介绍了几个使用 Syrup 的示例, 它们只需几行代码就能定义应用程序和特定工作负载的调度策略, 并将其部署到整个堆栈中, 与默认策略相比, 性能最多可提高 8 倍. 参见 [slides](https://systems-rg.github.io/slides/2022-07-08-syrup.pdf) |
| NSDI '19 |[Shenango: Achieving High CPU Efficiency for Latency-sensitive Datacenter Workloads](https://www.usenix.org/conference/nsdi19/presentation/ousterhout) | 数据中心应用需要微秒级的尾延迟和操作系统的高请求率, 而且大多数应用处理的负载在多个时间尺度上都有很大差异. 如何以 CPU 效率高的方式实现这些目标是一个尚未解决的问题. 由于当今内核的开销很大, 实现微秒级延迟的最佳解决方案是内核旁路联网, 即把 CPU 内核专门用于应用程序对网卡进行旋转轮询. 但这种方法会浪费 CPU: 即使在平均负荷不大的情况下, 也必须为峰值预期负荷分配足够的内核.
Shenango 可实现类似的延迟, 但 CPU 效率却高得多. 它能以非常精细的粒度（每 5 微秒）在各个应用之间重新分配内核, 从而使对延迟敏感的应用未使用的周期能被批处理应用有效利用. 实现如此快的重新分配率, 得益于: (1) 一种高效的算法, 该算法可检测应用程序何时可从更多内核中获益；(2) 一个名为 IOKernel 的特权组件, 该组件在专用内核上运行, 引导来自网卡的数据包, 并协调内核的重新分配. 在处理对延迟敏感的应用（如 memcached）时, 我们发现 Shenango 的尾部延迟和吞吐量可与最先进的内核旁路网络协议栈 ZygOS 相媲美, 但却能以线性方式将对延迟敏感的应用吞吐量换成批处理应用吞吐量, 从而大大提高了 CPU 效率. |
@@ -6781,6 +6826,7 @@ Roman Gushchin 在邮件列表发起了 BPF 对调度器的潜在应用的讨论
[Min: sched_ext: a BPF-extensible scheduler class (Part 1)](https://lwn.net/Articles/955481)
[sched_ext: a BPF-extensible scheduler class (Part 1)](https://blogs.igalia.com/changwoo/sched-ext-a-bpf-extensible-scheduler-class-part-1/)
+[sched_ext: scheduler architecture and interfaces (Part 2)](https://blogs.igalia.com/changwoo/sched-ext-scheduler-architecture-and-interfaces-part-2/)
作者在 [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).
@@ -6794,13 +6840,18 @@ LSFMMBPF 2024 上对 sched_ext 进行了讨论 [LWN, 2024/05/23, LSFMMBPF-2024,
[OPPO-内核工匠, 内核调度客制化利器: SCHED_EXT](https://blog.csdn.net/feelabclihu/article/details/139364772), [公众号发文](https://mp.weixin.qq.com/s/89PuLJDE4aE1c3cWG6ZL8g).
-尽管其他内核开发人员也提出了一些反对意见, 但是 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 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).
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 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)
*-*-*-*-*-*-*-*
[LORE v5](https://lore.kernel.org/all/20231111024835.2164816-1-tj@kernel.org)
*-*-*-*-*-*-*-*
[LORE v6,00/39](https://lore.kernel.org/all/20240501151312.635565-1-tj@kernel.org) |
+| 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) |
+| 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) | TODO | 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) | TODO | 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) |
#### 11.2.2.2 Google 的 ghOSt
@@ -6824,6 +6875,16 @@ LSFMMBPF 2024 上对 sched_ext 进行了讨论 [LWN, 2024/05/23, LSFMMBPF-2024,
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2024/04/03 | Vineeth Pillai (Google) | [Paravirt Scheduling (Dynamic vcpu priority management)](https://lore.kernel.org/all/20240403140116.3002809-1-vineeth@bitbyteword.org) | 双重调度是虚拟化主机的一个问题, 在这种情况下, 主机调度 VCPU 时不知道 VCPU 运行的是什么, 而客户机调度任务时不知道 VCPU 实际运行在哪里. 任务却不知道 VCPU 实际运行在哪里. 这会导致延迟、功耗、资源利用率等相关问题. 理想的解决方案是建立一个合作调度框架, 让客户机和主机共享调度相关信息, 并做出明智的调度决策, 以最佳方式处理工作负载. 作为第一步, 我们正在努力减少延迟 的延迟. 这一系列补丁旨在实施一个框架, 根据在 VCPU 上运行的工作负载的需求, 动态管理 VCPU 线程的优先级. 对延迟敏感的工作负载(nmi、irq、softirq、critical section、RT 任务等)将从主机获得提升, 以尽量减少延迟. 当主机掌握有关 VCPU 上将要运行的内容的足够信息时, 它可以主动提升 VCPU 线程, 例如: 注入中断. 在其他情况下, 如果 VCPU 尚未提升, 客户机可以请求提升. 在对延迟敏感的工作负载完成后, 客户机可随后请求取消提升. 如果需要, 客户机也可以请求提升. 共享内存区域用于交流调度信息, 客户机共享其对优先级提升的需求, 主机共享 VCPU 的提升状态. 客户机在需要提升时设置一个标志, 然后继续运行. 主机在下一次 VMEXIT 时读取该标志, 并提升 VCPU 线程. 取消提升是同步进行的, 这样当客户机不运行任何对延迟敏感的工作负载时, 主机工作负载就能与客户机公平竞争. [v1 RFC](https://lore.kernel.org/all/20231214024727.3503870-1-vineeth@bitbyteword.org) 于 2023 年 12 月发布. 主要分歧在于实施过程中, 补丁会在 kvm 和 kvm 中做出调度策略决定. 而 kvm 并不适合这样做. 建议将调度策略决策移出 kvm, 让 kvm 只处理调度策略决策所需的通知. 政策决策所需的通知. 本补丁系列是实现分层设计功能的迭代步骤 设计的迭代步骤, 在这种设计中, 策略可以作为内核内置程序、内核模块或 bpf 程序在 kvm 之外实现. 参见 LWN 报道 [LWN, 2024/05/22, LSFMMBPF-2024, Virtual machine scheduling with BPF](https://lwn.net/Articles/974363). | v2 ☐☑✓ | [2023/12/13, LORE v1,0/8](https://lore.kernel.org/all/20231214024727.3503870-1-vineeth@bitbyteword.org)
*-*-*-*-*-*-*-*
[2024/04/03, LORE v2,0/5](https://lore.kernel.org/all/20240403140116.3002809-1-vineeth@bitbyteword.org) |
+#### 11.2.2.4 openEuler 可编程调度(programmable base on bpf for scheduler)
+-------
+
+openEuler 5.10 内核集成了基于 eBPF 的可编程调度的功能, [issue: introduce scheduler BPF](https://gitee.com/openeuler/kernel/issues/I5F6X6), [Introduce programmable base on bpf for scheduler](https://gitee.com/openeuler/kernel/issues/I8OIT1), [pulls/4053, sched: basic infrastructure for scheduler bpf](https://gitee.com/openeuler/kernel/pulls/4053)
+
+#### 11.2.2.5
+-------
+
+[OPPO在CLK大会上公布可编程内核技术，引领安卓流畅体验升级](https://blog.csdn.net/feelabclihu/article/details/134194329)
+
### 11.2.3 Pluggable Scheduler Framework
-------
diff --git a/study/kernel/00-DESCRIPTION/TODO.md b/study/kernel/00-DESCRIPTION/TODO.md
index 5789cc6..5bc08fe 100644
--- a/study/kernel/00-DESCRIPTION/TODO.md
+++ b/study/kernel/00-DESCRIPTION/TODO.md
@@ -637,7 +637,6 @@ cba6167f0adb
| 2021/11/12 | Vincent Guittot | [avoid spurious blocked load update](https://lore.kernel.org/all/20211112095857.7016-1-vincent.guittot@linaro.org) | TODO | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20211112095857.7016-1-vincent.guittot@linaro.org) |
| 2024/03/27 | Bharata B Rao | [Hot page promotion optimization for large address space](https://lore.kernel.org/all/20240327160237.2355-1-bharata@amd.com) | TODO | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20240327160237.2355-1-bharata@amd.com) |
| 2024/05/06 | Qais Yousef | [sched: Consolidate cpufreq updates](https://lore.kernel.org/all/20240505233103.168766-1-qyousef@layalina.io) | TODO | v2 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240505233103.168766-1-qyousef@layalina.io) |
-| 2023/09/11 | Chen Yu | [Makes it easier for the wakee to choose previous CPU](https://lore.kernel.org/all/cover.1694397335.git.yu.c.chen@intel.com) | TODO | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/cover.1694397335.git.yu.c.chen@intel.com) |
| 2024/03/28 | mingyang.cui | [sched/fair: Fix forked task check in vruntime_normalized](https://lore.kernel.org/all/20240328062757.29803-1-mingyang.cui@horizon.ai) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240328062757.29803-1-mingyang.cui@horizon.ai) |
| 2024/04/02 | Tio Zhang | [sched: make softirq cputime accounting separately in irqtime](https://lore.kernel.org/all/20240402112415.GA17946@didi-ThinkCentre-M930t-N000) | 我们现在在延迟统计中只能获得 IRQ/SOFTIRQ 的总延迟, 但单独获得 SOFTIRQ 延迟和 IRQ 延迟将有助于用户以更方便的方式减少此类延迟. 对于 IRQ 延迟, 我们可以调整 IRQ-CPU 相关性或使用线程 IRQ.
对于 SOFTIRQ 延迟, 我们可以调整 rps/xps 或使用 NAPI 的内核线程. 因此, 这个补丁集试图使 SOFTIRQ 延迟在延迟统计中可观察到, 并在 taskstats 中可用. 补丁集同步更新了 `tools/accounting/getdelays.c` 同样为了向后兼容性, 我们不想改变原始 IRQ/SOFTIRQ 延迟的含义, 相反, 我们可以通过原始 IRQ/OFTIRQ 的延迟减去该补丁添加的 SOFTIREQ 延迟来获得真实的 IRQ(中断) 延迟. | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20240402112415.GA17946@didi-ThinkCentre-M930t-N000) |
@@ -658,6 +657,17 @@ cba6167f0adb
[Recent improvements to BPF's struct_ops mechanism](https://lwn.net/Articles/974848)
[An instruction-level BPF memory model](https://lwn.net/Articles/976071/)
[Comparing BPF performance between implementations](https://lwn.net/Articles/976317)
+[Securing BPF programs before and after verification](https://lwn.net/Articles/977394)
+[Simplifying the BPF verifier](https://lwn.net/Articles/977815)
+[Nested bottom-half locking for realtime kernels](https://lwn.net/Articles/978189)
+[Static keys for BPF](https://lwn.net/Articles/977993)
+[BPF tracing performance](https://lwn.net/Articles/978335)
+[Capturing stack traces asynchronously with BPF](https://lwn.net/Articles/978736)
+[Updates to pahole](https://lwn.net/Articles/978727)
+[Eliminating indirect calls for security modules](https://lwn.net/Articles/979683)
+[A capability set for user namespaces](https://lwn.net/Articles/978846)
+
+[OS2ATC-PPT](https://cloud.tsinghua.edu.cn/d/8e6c77ad1ad548acb909/)
[Wattch: a framework for architectural-level power analysis and optimizations](https://ieeexplore.ieee.org/document/854380)
@@ -677,6 +687,7 @@ cba6167f0adb
| 2024/02/26 | Lai Jiangshan | [KVM: x86/PVM: Introduce a new hypervisor](https://lore.kernel.org/all/20240226143630.33643-1-jiangshanlai@gmail.com) | TODO | v1 ☐☑✓ | [LORE v1,0/73](https://lore.kernel.org/all/20240226143630.33643-1-jiangshanlai@gmail.com) |
| 2020/05/04 | Alexandre Chartre | [ASI - Part I (ASI Infrastructure and PTI)](https://lore.kernel.org/all/20200504144939.11318-1-alexandre.chartre@oracle.com) | TODO | v4 ☐☑✓ | [LORE v4,0/7](https://lore.kernel.org/all/20200504144939.11318-1-alexandre.chartre@oracle.com) |
| 2024/02/14 | Ard Biesheuvel | [arm64: Add support for LPA2 and WXN at stage 1](https://lore.kernel.org/all/20240214122845.2033971-45-ardb+git@google.com) | TODO | v8 ☐☑✓ | [LORE v7,00/50](https://lore.kernel.org/all/20240123145258.1462979-52-ardb+git@google.com)
*-*-*-*-*-*-*-*
[LORE v8,0/43](https://lore.kernel.org/all/20240214122845.2033971-45-ardb+git@google.com) |
+| 2024/07/02 | Huisong Li | [power: introduce PM QoS interface](https://lore.kernel.org/all/20240702035010.4874-1-lihuisong@huawei.com) | TODO | v5 ☐☑✓ | [LORE v5,0/2](https://lore.kernel.org/all/20240702035010.4874-1-lihuisong@huawei.com) |
@@ -685,8 +696,10 @@ cba6167f0adb
[WeWe-RSS](https://help.railway.app/templates/we-we-rss-d75eade8)
-[免费部署wewe-rss服务](https://stupidjoey.net/posts/deploy_wewe_rss/)
-[一键部署属于自己的微信公众号RSS(wewe-rss)](https://foxistudy.com/posts/wewe-rss/)
+[免费部署 wewe-rss 服务](https://stupidjoey.net/posts/deploy_wewe_rss/)
+[一键部署属于自己的微信公众号 RSS(wewe-rss)](https://foxistudy.com/posts/wewe-rss/)
+
+[鄙人使用 huggingface 和 railway 搭建的公众号订阅](https://huggingface.co/spaces/gatieme/wewe-rss)
@@ -695,19 +708,6 @@ cba6167f0adb
-[专利号-WO2021US19353-Apple-ON-DEMAND MEMORY ALLOCATION](https://xueshu.baidu.com/usercenter/paper/show?paperid=102r0eg05d3q02p0mh7c0v60eu667084)
-
-公开了与动态分配和映射私有内存的请求电路的技术方案. 这种硬件电路可以接收私有地址并将该私有地址转换为虚拟地址. 在一些实施例中, 私有存储器分配电路被配置成生成页表信息, 如果页表信息尚未设置, 则映射所请求的私有内存页. 在各种实施例中，这可以有利地允许动态私有内存分配, 例如, 有效地为具有不同类型工作负载的图形着色器分配内存. 与传统技术相比, 公开的页表信息缓存技术可以提高性能. 此外, 公开的实施例可以促进跨设备(例如图形处理器)的内存整合.
-
-[The Forward Slice Core Microarchitecture](https://dl.acm.org/doi/10.1145/3410463.3414629)
-
-
-
-[RL-CoPref: a reinforcement learning-based coordinated prefetching controller for multiple prefetchers](https://link.springer.com/article/10.1007/s11227-024-05938-9)
-
-
-
-
@@ -719,19 +719,42 @@ cba6167f0adb
-[能量感知调度¶](https://www.kernel.org/doc/html/latest/translations/zh_CN/scheduler/sched-energy.html)
+[能量感知调度 ¶](https://www.kernel.org/doc/html/latest/translations/zh_CN/scheduler/sched-energy.html)
-[Capturing stack traces asynchronously with BPF](https://lwn.net/Articles/978736)
+[Amazon Exploring MM-Local Memory Allocations To Help With Current/Future Speculation Attacks](https://www.phoronix.com/news/Linux-MM-Local-Kernel-Allocs)
-| 编号 | 作者 | 工具 | 描述 | 链接 |
-|:---:|:-----:|:----:|:---:|:----:
-| 1 | paulmckrcu | [litmus](https://github.com/paulmckrcu/litmus) | Automatically generated litmus tests for validation LISA-language Linux-kernel memory models | [github/paulmckrcu/litmus](https://github.com/paulmckrcu/litmus) |
-| 2 | herd | [herd/herdtools7](https://github.com/herd/herdtools7) | 一个用于测试弱内存模型的工具套件. HERD7: 用于弱内存模型的通用模拟器, litmus7: 运行 litmus 测试(作为 Power、ARM、AArch64 或 X86 的汇编程序提供)来测试执行机器的内存模型, DIY7: 根据简明规范制作石蕊测试 | [官网](http://diy.inria.fr) |
-| 3 | Hernan Ponce de Leon 等 | [Dat3M](https://github.com/hernanponcedeleon/Dat3M) | Memory Model Aware Verification, Dartagnan is a tool to check state reachability under weak memory models. | [github/hernanponcedeleon/Dat3M](https://github.com/hernanponcedeleon/Dat3M) |
-| 4 | MPI-SWS(Max Planck Institute for Software Systems) | [GenMC](https://github.com/MPI-SWS/genmc) | A Model Checker for Weak Memory Models | [官网](https://plv.mpi-sws.org/genmc), [论文引用详情](https://ouci.dntb.gov.ua/en/works/4ryroeM7), [github/MPI-SWS/genmc](https://github.com/MPI-SWS/genmc) |
-| 5 | MPI-SWS(Max Planck Institute for Software Systems) | [Kater](https://github.com/MPI-SWS/kater) | Automating Weak Memory Model Metatheory and Consistency Checking | [MPI-SWS/kater](https://github.com/MPI-SWS/kater) |
-| 6 | NVlabs | [NVlabs/mixedproxy](https://github.com/NVlabs/mixedproxy) | Mixed-Proxy Extensions for the NVIDIA PTX Memory Consistency Model | [NVlabs/mixedproxy](https://github.com/NVlabs/mixedproxy) |
-| 7 | [Open, Safe and Scalable System Software Concurrency](https://github.com/open-s4c) | [vsyncer](https://github.com/open-s4c/vsyncer) | vsyncer: is a toolkit to verify and optimize concurrent C/C++ programs on WMMs, which employs state-of-the-art model checkers Dartagnan and GenMC. | [](https://github.com/open-s4c)
+update_curr_rt
+-=> trace_android_vh_sched_stat_runtime_rt(curr, delta_exec);
+ -=> register_trace_android_vh_sched_stat_runtime_rt(fbg_update_rt_util_hook, NULL);
+ -=> fbg_update_task_util(tsk, runtime, true);
+ -=> update_frame_group_util(tsk, runtime, wallclock, default_part, grp);
+ -=> sf_composition_update_cpufreq(tsk); // sf_composition_group
+ -=> default_group_update_cpufreq(); // game_frame_boost_group
+ -=> inputmethod_update_cpufreq(tsk); // default_frame_boost_group
+
+
+
+update_curr_{fair|rt}
+update_util_before_window_rollover
+fbg_android_rvh_cpufreq_transition //REGISTER_TRACE_RVH(trace_android_rvh_cpufreq_transition, cpufreq_transition_handler);
+
+-=> fbg_update_task_util
+
+
+
+
+[AMD's AOMP 19.0-2 Compiler Brings Zero-Copy For CPU-GPU Unified Shared Memory](https://www.phoronix.com/news/AMD-AOMP-19.0-2-Compiler)
+
+
+HUAWEI P10 Plus, Vicky, Android 7.0, EMUI 5.1
+
+| Model | Description | Open Source |
+|:-----:|:-----------:|:-----------:|
+| Vicky | HUAWEI P10 Plus, Vicky, Android 7.0, EMUI 5.1 | [LINK](https://download-c1.huawei.com/download/downloadCenter?downloadId=4217C26E864DD3F2F7EF57943CCF4179&version=B7B24D5019E86B029000B1F8D06787F5&siteCode=worldwide) |
+
+
+
+[issue: introduce scheduler BPF](https://gitee.com/openeuler/kernel/issues/I5F6X6), [Introduce programmable base on bpf for scheduler](https://gitee.com/openeuler/kernel/issues/I8OIT1), [pulls/4053, sched: basic infrastructure for scheduler bpf](https://gitee.com/openeuler/kernel/pulls/4053)
\ No newline at end of file
diff --git a/study/kernel/00-DESCRIPTION/VIRT.md b/study/kernel/00-DESCRIPTION/VIRT.md
index eec0d7c..9731b1b 100644
--- a/study/kernel/00-DESCRIPTION/VIRT.md
+++ b/study/kernel/00-DESCRIPTION/VIRT.md
@@ -244,6 +244,7 @@ Anbox 使用 Linux 命名空间 (user, pid, uts, net, mount, ipc) 在容器中
| 2023/04/24 | Elliot Berman | [Drivers for Gunyah hypervisor](https://lore.kernel.org/all/20230424231558.70911-1-quic_eberman@quicinc.com) | [Qualcomm Continues Working To Upstream Gunyah Hypervisor Support In Linux](https://www.phoronix.com/news/Qualcomm-Gunyah-Linux-v12) | v12 ☐☑✓ | [LORE v12,0/25](https://lore.kernel.org/all/20230424231558.70911-1-quic_eberman@quicinc.com) |
| 2023/05/12 | Yi-De Wu | [GenieZone hypervisor drivers](https://lore.kernel.org/all/20230512080405.12043-1-yi-de.wu@mediatek.com) | TODO | v3 ☐☑✓ | [LORE v1,0/6](https://lore.kernel.org/lkml/20230413090735.4182-1-yi-de.wu@mediatek.com)
*-*-*-*-*-*-*-*
[LORE v2,0/7](https://lore.kernel.org/lkml/20230428103622.18291-1-yi-de.wu@mediatek.com)
*-*-*-*-*-*-*-*
[LORE v3,0/7](https://lore.kernel.org/all/20230512080405.12043-1-yi-de.wu@mediatek.com) |
| 2024/02/26 | Lai Jiangshan | [KVM: x86/PVM: Introduce a new hypervisor](https://lore.kernel.org/all/20240226143630.33643-1-jiangshanlai@gmail.com) | [PVM Virtualization Framework Proposed For Linux - Built Atop The KVM Hypervisor](https://www.phoronix.com/news/PVM-Hypervisor-Linux-RFC) | v1 ☐☑✓ | [LORE v1,0/73](https://lore.kernel.org/all/20240226143630.33643-1-jiangshanlai@gmail.com) |
+| 2024/06/13 | Alexey Makhalov | [VMware hypercalls enhancements](https://lore.kernel.org/all/20240613191650.9913-1-alexey.makhalov@broadcom.com) | Broadcom 一直在开发适用于 Linux 内核的 VMware Hypercall API. 这个 PATCHSET 提供了 "vmware_hyperscall" 是一系列新的功能, 供 VMware 客户机代码和虚拟设备驱动程序以独立于体系结构的方式使用. 参见 phoronix 报道 [VMware Hypercall API To Likely Land In Linux 6.11](https://www.phoronix.com/news/VMware-Hypercall-API-Linux-6.11). | v11 ☐☑✓ | [LORE v11,0/8](https://lore.kernel.org/all/20240613191650.9913-1-alexey.makhalov@broadcom.com) |
# 12 HaltPolling