diff --git a/study/arch/SMT/README.md b/study/arch/SMT/README.md
index bc524d6..7800c9a 100644
--- a/study/arch/SMT/README.md
+++ b/study/arch/SMT/README.md
@@ -34,9 +34,31 @@ blogexcerpt: 虚拟化 & KVM 子系统
-# 1
+# 1 Rentable Units
+-------
+英特尔近日申请了一项新的技术专利 [METHODS AND APPARATUS TO SCHEDULE PARALLEL INSTRUCTIONS USING HYBRID CORES - Intel Corporation (freepatentsonline.com)](https://www.freepatentsonline.com/y2023/0168898.html), 介绍了跨混合架构的并行调度方案, 正式确认了 "Rentable Unit" 方案. 这项技术作为一个超线程 SMT 技术的继任者叫作, 相比较传统同步多线程(SMT)技术, 灵活性和可行性更高.
+
+| 编号 | 资料 | 描述 |
+|:---:|:----:|:---:|
+| 1 | [Intel 多线程秘密武器: 详解「Rentable Units」](https://mp.weixin.qq.com/s/sR9aKrkAlDTWLWVV7bJWxg) | 头发实验室公众号, 介绍 "Rentable Units" |
+| 2 | [英特尔专利曝光超线程技术继任者, 更灵活调度、高效处理任务](https://ngabbs.com/read.php?&tid=37385627) | 精英玩家俱乐部论坛对 "Rentable Units" 的介绍 |
+| 3 | [Intel 17th Gen CPUs to Get Rentable Units: Why Hyper-Threading is Going Away](https://www.hardwaretimes.com/intel-15th-gen-cpus-to-get-rentable-units-why-hyper-threading-is-going-away) | 介绍了 SMT 以及 "Rentable Unit" 的基本原理. |
+| 4 | [Intel Patent Reveals the ‘Rentable Unit’, Marking the End for Hyperthreading](https://appuals.com/intel-rentable-unit-patent) | 简单分析了下 "Rentable Unit" 的基本原理. |
+
+英特尔在 Alder Lake(第 12 代) 处理器上, 采用了大小核 (性能 + 效率) 的混合架构设计, 通过动态算法, 将复杂的任务交由性能核心 (P 核) 处理, 后台任务交由效率 (E 核) 处理. P 核启用了 SMT, 物理内核即使具有 2 个逻辑线程, 1 次也仅能执行 1 条指令, 无法并行工作. 英特尔为了克服并行性问题, 引入了 E 核, 而 "Rentable Unit" 就是超线程技术的继任者.
+
+"Rentable Unit" 工作原理如下:
+
+Rentable Unit 接收指令, 并根据指令的复杂性、可用资源和 CPU 结构对其进行划分.
+
+Rentable Unit 根据任务调度 P 核和 E 核, 确保所有核心都处于活跃状态.
+
+该原理就是确保没有核心处于闲置状态, 如果 P 核处于闲置状态下, 也可以处理 E 核的任务.
+
+它会尝试预测任务在 P/E 核上的完成时间然后试图分割任务以更小粒度跨核调度, 调度会更复杂, 上下文切换会更多, 优化目标可能会倾向吞吐量所以 P 核上高优任务延迟可能会被影响: P 核高优任务可能分一部分扔去 E 核, 而 E 核低优任务可能分一部分拿来 P 核跑.
+
diff --git a/study/kernel/00-DESCRIPTION/ARCH.md b/study/kernel/00-DESCRIPTION/ARCH.md
index 55ef98d..d1807eb 100644
--- a/study/kernel/00-DESCRIPTION/ARCH.md
+++ b/study/kernel/00-DESCRIPTION/ARCH.md
@@ -104,6 +104,7 @@ v5.7 引入了拆分锁检测的支持, 这依赖于 x86_64 intel CPU 遇到拆
| 2021/04/19 | Fenghua Yu | [x86/bus_lock: Set rate limit for bus lock](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=d28397eaf4c27947a1ffc720d42e8b3a33ae1e2a) | 通过限制总线锁的速率而不是杀死进程来缓解拆分锁带来的问题. | v1 ☑✓ 5.14-rc1 | [Patchwork 0/4](https://lore.kernel.org/all/20210419214958.4035512-1-fenghua.yu@intel.com) |
| 2022/03/10 | Tony Luck | [Make life miserable for split lockers](https://lore.kernel.org/all/20220310204854.31752-1-tony.luck@intel.com) | 通过强制用户空间对拆分锁进行顺序访问. 在解决问题的同时, 也确保了在这些条件下整体系统性能更好. 参见 [Linux 5.19 To"Make Life Miserable"In Slowing Down Bad Behaving Split-Lock Apps](https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.19-Split-Lock). | v2 ☐☑✓ | [LORE v2,0/2](https://lore.kernel.org/all/20220310204854.31752-1-tony.luck@intel.com) |
| 2022/10/24 | Guilherme G. Piccoli | [x86/split_lock: Add sysctl to control the misery mode](https://lore.kernel.org/all/20221024200254.635256-1-gpiccoli@igalia.com) | Splitlock Detector 机制通过人为限制触发了 Splitlock 锁的软件的性能, 从而保证整机的吞吐量和性能. 然后推动触发了对应软件整改和优化自己的代码, 但是一些专用软件特别是闭源软件改起来相对麻烦, 比如 Linux 上 window 游戏等. 这引发了这些 window 游戏性能的大幅度下降, 参见 [Linux Adding New Control Since Its Splitlock Detector Is Wrecking Some Steam Play Games](https://www.phoronix.com/news/Linux-Splitlock-Hurts-Gaming). 现在为 Linux 6.2 添加了一个新的 sysctl 可调参数 "split_lock_reduce", 以便轻松禁用 "痛苦模式" 行为. 当将 split_lock_reduce 设置为 0 时, 只会在内核锁中出现警告, 而不会带来循序存取损失. 默认情况下, 故意的性能降低模式仍然处于活动状态, 但是我们可能会看到 SteamOS 之类的操作系统自动关闭 split_lock_reduce 可调参数. 也有可能我们会看到这个自动调整喜欢野性的游戏模式. 由于它是一个 sysctl 选项, 现在在运行时管理起来比在启动时不得不为内核使用劈开锁检测选项更容易, 但是内核开发人员到目前为止还想保持默认的 “糟糕性能” 模式, 以激励用户空间软件围绕减少劈开锁进行改进. | v3 ☐☑✓ | [LORE](https://lore.kernel.org/all/20221024200254.635256-1-gpiccoli@igalia.com) |
+| 2024/04/29 | Ravi Bangoria | [x86/cpu: Add Bus Lock Detect support for AMD](https://lore.kernel.org/all/20240429060643.211-1-ravi.bangoria@amd.com) | [AMD Prepares Linux For "Bus Lock Trap" Feature On Upcoming CPUs](https://www.phoronix.com/news/AMD-Bus-Lock-Trap-Detect-Linux). | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20240429060643.211-1-ravi.bangoria@amd.com) |
### 1.1.2 Sub-Page Write Protection
@@ -193,6 +194,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) |
@@ -330,6 +332,9 @@ AMD 关于大小核的专利 [US20210173715A1: METHOD OF TASK TRANSITION BETWEEN
[Recently published patent hints at AMD hybrid CPU plans](https://m.hexus.net/tech/news/cpu/147956-recently-published-patent-hints-amd-hybrid-cpu-plans).
+| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:---:|:----:|:---:|:----:|:---------:|:----:|
+| 2024/05/07 | Perry Yuan | [AMD Pstate Driver Fixes and Improvements](https://lore.kernel.org/all/cover.1715065568.git.perry.yuan@amd.com) | 参见 phoronix 报道 [AMD Posts Patches For Improving Heterogeneous Core Type CPUs On Linux](https://www.phoronix.com/news/AMD-Heterogeneous-P-State-Linux). | v1 ☐☑✓ | [LORE v1,0/11](https://lore.kernel.org/all/cover.1715065568.git.perry.yuan@amd.com) |
### 1.4.3 ARM big.LITTLE & DynamIQ
-------
@@ -476,6 +481,15 @@ SGX 旨在以硬件安全为强制性保障, 不依赖于固件和软件的安
[Intel Continues Prepping The Linux Kernel For X86S](https://www.phoronix.com/news/Linux-6.9-More-X86S)
+## 1.12 CPUID Families Detect
+-------
+
+| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:---:|:----:|:---:|:----:|:---------:|:----:|
+| 2024/04/24 | Tony Luck | [New Intel CPUID families](https://lore.kernel.org/all/20240424181245.41141-1-tony.luck@intel.com) | 自 90 年代中期以来, 英特尔工程师一直在使用 P6 微架构的 "Family 6" 后, 重新设计了 Linux 的英特尔 CPU 模型处理, 并继续仅在新的微架构中修改模型 ID. 这是 Family 6 时代的终结, 因此有很多 Linux 补丁正在开发中, 以解决内核代码中的假设, 这些假设只检查 Intel CPU 的型号 ID, 而不是任何系列 ID 差异. 参见 phoronix 报道 [Rework For Intel CPU Model Handling To Land With Linux 6.10](https://www.phoronix.com/news/Intel-CPU-Models-Linux-6.10) 以及 [Intel "Family 6" CPU Era Coming To An End Soon: Code Suggests Cooper Forest & Adams Lake](https://lore.kernel.org/all/20240424181245.41141-1-tony.luck@intel.com). | v4 ☐☑✓ | [LORE v4,0/71](https://lore.kernel.org/all/20240424181245.41141-1-tony.luck@intel.com) |
+
+
+
# 2 ARM64
-------
@@ -691,6 +705,8 @@ TLB entry shootdown 常常或多或少的带来一些性能问题.
| 2019/01/31 | Julien Thierry | [arm64: provide pseudo NMI with GICv3](https://patchwork.kernel.org/project/linux-arm-kernel/cover/1548946743-38979-1-git-send-email-julien.thierry@arm.com) | ARM64 通过中断优先级实现(伪)NMI | v10 ☑ [5.1-rc1](https://kernelnewbies.org/Linux_5.1#ARM) | [Patchwork v10,00/25](https://patchwork.kernel.org/project/linux-arm-kernel/cover/1548946743-38979-1-git-send-email-julien.thierry@arm.com), [关键 commit](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bc3c03ccb4641fb940b27a0d369431876923a8fe) |
| 2019/06/11 | Julien Thierry | [arm64: IRQ priority masking and Pseudo-NMI fixes](https://patchwork.kernel.org/project/linux-arm-kernel/cover/1560245893-46998-1-git-send-email-julien.thierry@arm.com) | 修复伪 NMI 的诸多问题 | v4 ☑ 5.10-rc1 | [Patchwork v4,0/8](https://patchwork.kernel.org/project/linux-arm-kernel/cover/1560245893-46998-1-git-send-email-julien.thierry@arm.com) |
| 2019/07/17 | Julien Thierry | [arm_pmu: Use NMI for perf interrupt](https://patchwork.kernel.org/project/linux-arm-kernel/cover/1563351432-55652-1-git-send-email-julien.thierry@arm.com) | ARM64 perf 的中断通过伪 NMI 上报, 这样会使 perf 的热点采样更加精准. | v4 ☑ 5.10-rc1 | [Patchwork v4,0/9](https://patchwork.kernel.org/project/linux-arm-kernel/cover/1563351432-55652-1-git-send-email-julien.thierry@arm.com) |
+| 2024/04/03 | Jinjie Ruan via | [target/arm: Implement FEAT_NMI and FEAT_GICv3_NMI](https://lore.kernel.org/all/20240403101611.3204086-1-ruanjinjie@huawei.com) | 这个补丁集为 ARMv8 的 FEAT_NMI 和 FEAT_GICv3_NMI, 引入了对体系结构中一类新中断的支持, 可以使用它来提供类似NMI的功能. | v3 ☐☑✓ | [LORE v3,0/23](https://lore.kernel.org/all/20240403101611.3204086-1-ruanjinjie@huawei.com) |
+| 2024/04/15 | Liao Chang | [Rework the DAIF mask, unmask and track API](https://lore.kernel.org/all/20240415064758.3250209-1-liaochang1@huawei.com) | TODO | v3 ☐☑✓ | [LORE v2,0/9](https://lore.kernel.org/all/20240411064858.3232574-1-liaochang1@huawei.com)
*-*-*-*-*-*-*-*
[LORE v3,0/8](https://lore.kernel.org/all/20240415064758.3250209-1-liaochang1@huawei.com) |
## 2.5 PAN
@@ -866,9 +882,11 @@ SLS 被认为是 Spectre 漏洞的变体, 但二者的攻击范围略有不同,
[Linux Kernel Patched For Branch History Injection "BHI" Intel CPU Vulnerability](https://www.phoronix.com/news/Linux-BHI-Branch-History-Inject)
+
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:-----:|:----:|:----:|:----:|:------------:|:----:|
| 2024/04/05 | Josh Poimboeuf | [x86/bugs: Change commas to semicolons in 'spectre_v2' sysfs file](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=2bb69f5fc72183e1c62547d900f560d0e9334925) | TODO | v2 ☐☑✓ | [LORE](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2bb69f5fc72183e1c62547d900f560d0e9334925) |
+| 2024/04/19 | Josh Poimboeuf | [x86/bugs: more BHI fixes](https://lore.kernel.org/all/cover.1713559768.git.jpoimboe@kernel.org) | [Linux BHI Mitigation Being Tweaked Following 12% Database Performance Hit](https://www.phoronix.com/news/Linux-BHI-Fix-Server-Perf). | v1 ☐☑✓ | [LORE v1,0/5](https://lore.kernel.org/all/cover.1713559768.git.jpoimboe@kernel.org) |
## 4.X 安全框架层
@@ -1036,6 +1054,7 @@ https://blogs.vmware.com/vsphere/2021/10/introducing-project-capitola.html
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2024/03/24 | ira.weiny@intel.com | [DCD: Add support for Dynamic Capacity Devices (DCD)](https://lore.kernel.org/all/20240324-dcd-type2-upstream-v1-0-b7b00d623625@intel.com) | 动态容量设备 (DCD)(CXL 3.1 sec 9.13.3) 是一种 CXL 存储器设备, 它允许存储器容量动态变化, 而无需重置设备、重新配置 HDM 解码器或重新配置软件 DAX 区域. 动态容量最大的使用案例之一是允许主机在数据中心内动态共享内存, 而不增加每台主机连接的内存. 添加或删除内存的一般流程是让协调器协调内存的使用. 通常, 在这样的系统中有 5 个参与者, 即编排器、结构管理器、主机看到的设备、主机内核和主机用户. | v1 ☐☑✓ | [LORE v1,0/26](https://lore.kernel.org/all/20240324-dcd-type2-upstream-v1-0-b7b00d623625@intel.com) |
+| 2024/04/22 | Dongsheng Yang | [block: Introduce CBD (CXL Block Device)](https://lore.kernel.org/all/20240422071606.52637-1-dongsheng.yang@easystack.cn) | [CBD Proposed For The Linux Kernel: CXL Block Device](https://www.phoronix.com/news/Linux-CBD-CXL-Block-Device) | v1 ☐☑✓ | [LORE v1,0/7](https://lore.kernel.org/all/20240422071606.52637-1-dongsheng.yang@easystack.cn) |
## 6.4 CPU IDLE(C-state)
@@ -1071,7 +1090,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 正在使用, 此程序将无限期挂起, 如果不使用, 则几乎立即崩溃. | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20240410211652.16640-1-zayd_qumsieh@apple.com) |
+| 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.6 objtool
@@ -1202,6 +1221,7 @@ openEuler 提供了 [openEuler/prefetch_tuning](https://gitee.com/openeuler/pref
| 2022/03/25 | Mario Limonciello | [Improve usability for amd-pstate](https://lore.kernel.org/all/20220325054228.5247-1-mario.limonciello@amd.com) | TODO | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20220325054228.5247-1-mario.limonciello@amd.com)
*-*-*-*-*-*-*-*
[LORE v3,0/6](https://lore.kernel.org/linux-pm/20220414164801.1051-1-mario.limonciello@amd.com) |
| 2023/01/13 | Wyes Karny | [amd_pstate: Add guided autonomous mode support](https://lore.kernel.org/all/20230113052141.2874296-1-wyes.karny@amd.com) | [AMD Updates P-State"Guided Autonomous Mode"Support For Linux](https://www.phoronix.com/news/AMD-Guided-Auto-Mode-v2) | v2 ☐☑✓ | [LORE v2,0/6](https://lore.kernel.org/all/20230113052141.2874296-1-wyes.karny@amd.com) |
| 2024/01/30 | Perry Yuan | [enable x86_energy_perf_policy for AMD CPU](https://lore.kernel.org/all/cover.1706583551.git.perry.yuan@amd.com) | 对 AMD 处理器上 x86_energy_perf_policy 实用程序的支持, 这些处理器使用 CPPC(Collaborative Processor Performance Control) 接口进行频率缩放, 并使用 AMD_state 驱动程序模块. AMD 处理器已经支持各种能源性能偏好 EPP(Energy Performance Preference) 配置文件. 有了这个实用程序, 用户现在可以使用提供的命令在这些 EPP 配置文件之间无缝切换. 并使用此工具检查 CPPC 的功能. 此增强旨在提高 AMD 处理器的电源效率和性能管理, 为用户提供对系统能源性能行为的更多控制. 参见 [Linux's x86_energy_perf_policy Utility Being Extended To AMD CPUs](https://www.phoronix.com/news/AMD-x86_energy_perf_policy) | v1 ☐☑✓ | [LORE v1,0/8](https://lore.kernel.org/all/cover.1706583551.git.perry.yuan@amd.com) |
+| 2024/04/28 | Xiaojian Du | [x86/cpufeatures: Add AMD FAST CPPC feature flag](https://lore.kernel.org/all/20240428091133.592333-1-Xiaojian.Du@amd.com) | 一些 AMD Zen 4 处理器支持新功能 FAST CPPC, 由于内部架构增强, 该功能允许更快的 CPPC 循环. 这种更快循环的目标是在相同的功耗下获得更高的性能. 参见 phoronix 报道 [AMD Enabling "Fast CPPC" For Even Greater Linux Performance & Power Efficiency On Some CPUs](https://www.phoronix.com/news/AMD-Fast-CPPC-Linux-Patches). | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20240428091133.592333-1-Xiaojian.Du@amd.com) |
#### 6.12.2.2 AMD P-State Preferred Core
@@ -1228,7 +1248,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). | v6 ☐☑✓ | [LORE v6,0/6](https://lore.kernel.org/all/cover.1710754236.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) | 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/BPF.md b/study/kernel/00-DESCRIPTION/BPF.md
index faf7a84..8c0e4af 100644
--- a/study/kernel/00-DESCRIPTION/BPF.md
+++ b/study/kernel/00-DESCRIPTION/BPF.md
@@ -608,6 +608,8 @@ Wasmtime 完全开源, 使用 Rust 编程语言, 是的, 并且符合 WASI 标
[WASM 原生时代已经到来 | 解读 WebAssembly 的 2022](https://csdnnews.blog.csdn.net/article/details/128739217)
+[Wasmer 4.3 Released: WebAssembly Runtime 25% Faster On Cold Startups](https://www.phoronix.com/news/Wasmer-4.3-Released)
+
# 10 云原生
-------
diff --git a/study/kernel/00-DESCRIPTION/DEBUGGING.md b/study/kernel/00-DESCRIPTION/DEBUGGING.md
index c25e68c..05bda36 100644
--- a/study/kernel/00-DESCRIPTION/DEBUGGING.md
+++ b/study/kernel/00-DESCRIPTION/DEBUGGING.md
@@ -91,7 +91,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) |
# 3 RONX
-------
@@ -487,6 +487,7 @@ x86 和 arm64 都支持直接访问用户空间中的事件计数器. 访问序
| 2022/10/21 | Shang XiaoJing | [perf vendor events arm64: Fix incorrect Hisi hip08 L3 metrics](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=e9229d5b6254a75291536f582652c599957344d2) | TODO | v2 ☑✓ 6.1-rc3 | [LORE v2,0/3](https://lore.kernel.org/all/20221021105035.10000-1-shangxiaojing@huawei.com) |
| 2022/12/14 | Sandipan Das | [perf vendor events amd: Add Zen 4 events and metrics](https://lore.kernel.org/all/20221214082652.419965-1-sandipan.das@amd.com) | [Linux 6.2 Adds AMD Zen 4 Pipeline Utilization Data To Help Find Performance Bottlenecks](https://www.phoronix.com/news/LInux-6.2-AMD-Zen-4-Events) | v2 ☐☑✓ 6.2-rc1 | [LORE v2,0/4](https://lore.kernel.org/all/20221214082652.419965-1-sandipan.das@amd.com)|
| 2023/06/07 | kan.liang@linux.intel.com | [New metricgroup output in perf stat default mode](https://lore.kernel.org/all/20230607162700.3234712-1-kan.liang@linux.intel.com) | 在默认模式下, metricgroup 的当前输出包括事件和度量, 这是不必要的, 并且使输出难以读取. 此外, 由于度量中的事件不同, 不同的 ARCH(甚至不同代的 ARCH)可能具有不同的输出格式. 该补丁提出了一种新的输出格式, 只输出每个度量的值和度量组名称. 它可以在 ARCH 和各代之间带来干净一致的输出格式. | v1 ☐☑✓ | [LORE v1,0/8](https://lore.kernel.org/all/20230607162700.3234712-1-kan.liang@linux.intel.com) |
+| 2024/03/29 | weilin.wang@intel.com | [TPEBS counting mode support](https://lore.kernel.org/all/20240329191224.1046866-1-weilin.wang@intel.com) | TODO | v6 ☐☑✓ | [LORE v6,0/5](https://lore.kernel.org/all/20240329191224.1046866-1-weilin.wang@intel.com) |
@@ -828,7 +829,10 @@ Intel 编译器随后也切到 LLVM 框架, 参见 [Intel Fully Embracing LLVM F
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2022/10/19 | Jason A. Donenfeld | [kbuild: treat char as always unsigned](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3bc753c06dd02a3517c9b498e3846ebfc94ac3ee) | [Linux 6.2 Looks To Enable"-funsigned-char"To Better Deal With Buggy Code](https://www.phoronix.com/news/Linux-6.2-funsigned-char) | v2 ☐☑✓ | [LORE](https://lore.kernel.org/all/20221019203034.3795710-1-Jason@zx2c4.com) |
+#### 13.10.2 arch 相关编译选项
+-------
+[graysky2/kernel_compiler_patch](https://github.com/graysky2/kernel_compiler_patch) 此补丁通过添加更多可在以下位置访问的微架构选项, 为内核构建添加了额外的优化 / 调优.
## 13.11 Reduce Memory Usage
-------
@@ -1130,6 +1134,7 @@ 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) |
## 22.2 C++
@@ -1149,7 +1154,7 @@ 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)
*-*-*-*-*-*-*-*
[]() | v10 ☐☑✓ | [GitHub](https://github.com/oracle-samples/bpftune) |
+| 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 | Ktune | NA | NA | NA | NA |
diff --git a/study/kernel/00-DESCRIPTION/LOCKING.md b/study/kernel/00-DESCRIPTION/LOCKING.md
index b52ca7a..1e3aff1 100644
--- a/study/kernel/00-DESCRIPTION/LOCKING.md
+++ b/study/kernel/00-DESCRIPTION/LOCKING.md
@@ -450,7 +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 ☐☑✓ | [LORE v7,0/23](https://lore.kernel.org/all/20231220001856.3710363-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/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) |
# 12 深入理解并行编程
diff --git a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md
index 9c2b96c..d43db75 100644
--- a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md
+++ b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md
@@ -203,6 +203,8 @@ cgit 上查看 MM 所有的 log 信息 :
# 1 页表管理
-------
+[The state of the page in 2024](https://lwn.net/Articles/973565)
+
## 1.1 多级页表
-------
@@ -283,6 +285,7 @@ Linux 一开始是在一台 i386 上的机器开发的, i386 的硬件页表是
[带有"memory folios"的 Linux: 编译内核时性能提升了 7%](https://www.heikewan.com/item/27509944)
+[论好名字的重要性： Linux内核page到folio的变迁](https://blog.csdn.net/feelabclihu/article/details/131485936)
最终该特性与 5.16 合入, [Memory Folios Merged For Linux 5.16](https://www.phoronix.com/scan.php?page=news_item&px=Memory-Folios-Lands-Linux-5.16), 代码仓库 [willy/pagecache.git](http://git.infradead.org/users/willy/pagecache.git), 合入链接 [GIT,PULL Memory folios for v5.1](https://patchwork.kernel.org/project/linux-mm/patch/YX4RkYNNZtO9WL0L@casper.infradead.org), [Merge tag'folio-5.16'of git://git.infradead.org/users/willy/pagecache](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49f8275c7d9247cf1dd4440fc8162f784252c849)
@@ -793,6 +796,7 @@ github 地址: [Mitosis Project](https://github.com/mitosis-project), [linux 内
| 2020/04/28 | Matthew Wilcox | [Record the mm_struct in the page table pages](https://lore.kernel.org/patchwork/patch/1232723) | NA| v1 ☐ | [PatchWork 0/6](https://lore.kernel.org/patchwork/patch/1232723) |
| 2022/02/14 | David Hildenbrand | [mm: enforce pageblock_order < MAX_ORDER](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=b3d40a2b6d10c9d0424d2b398bf962fb6adad87e) | 20220214174132.219303-1-david@redhat.com | v1 ☑✓ 5.18-rc1 | [LORE v1,0/2](https://lore.kernel.org/all/20220214174132.219303-1-david@redhat.com) |
| 2024/04/10 | Li RongQing | [x86/cpu: Take NUMA node into account when allocating per-CPU cpumasks](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=e0a9ac192fd62322b932c6018db60217b3ad866d) | 由于大多数每个 CPU 的 cpumask 都是从它们自己的本地处理器内核访问的, 因此将它们本地分配给给定的 NUMA 节点是有意义的. 参见 phoronix 报道 [Linux 6.10 To Account For NUMA Node When Allocating Per-CPU Cpumasks](https://www.phoronix.com/news/Linux-Per-CPU-NUMA-Node-Cpumask). | v1 ☑✓ 5.18-rc1 | [LORE](https://lore.kernel.org/all/171272659069.10875.14275567183040175048.tip-bot2@tip-bot2) |
+| 2024/04/12 | Li RongQing | [x86/sev: take NUMA node into account when allocating memory for per-CPU variables](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=90167e96588df747c9b47a04ebac59b71e3b413f) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240412030130.49704-1-lirongqing@baidu.com) |
# 2 内存分配
@@ -1085,18 +1089,29 @@ build_zonelists() 的过程中, 如果[指定了 ZONELIST_ORDER_NODE](https://el
NUMA 系统中 CPU 访问不同节点的内存速度很有大的差别. 位于本地 NUMA 节点 (或附近节点) 上的内存比远程节点上的内存访问速度更快. 因此如果能通过策略去控制优先在哪些节点上内存分配, 能有效地提升业务的性能.
+#### 2.2.3.1 NUMA multi-preference mempolicy
+-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2010/05/04 | Miao Xie | [NUMA API](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=e1e71f9b6c8dd34be36573346ecbbb00f34a7a0a) | NA | v1 ☑✓ 2.6.7-rc1 | [LORE v1,0/2](https://lore.kernel.org/all/4BDFFCC8.4040205@cn.fujitsu.com) |
| 2010/05/04 | Miao Xie | [mempolicy: restructure rebinding-mempolicy functions](https://lore.kernel.org/all/4BDFFCC8.4040205@cn.fujitsu.com) | 4BDFFCC8.4040205@cn.fujitsu.com | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/4BDFFCC8.4040205@cn.fujitsu.com) |
| 2017/04/11 | Vlastimil Babka | [cpuset/mempolicies related fixes and cleanups](https://lore.kernel.org/all/20170411140609.3787-1-vbabka@suse.cz) | 20170411140609.3787-1-vbabka@suse.cz | v1 ☐☑✓ | [LORE v1,0/6](https://lore.kernel.org/all/20170411140609.3787-1-vbabka@suse.cz) |
-| 2021/03/17 | Feng Tang | [Introduced multi-preference mempolicy](https://lore.kernel.org/all/1615952410-36895-1-git-send-email-feng.tang@intel.com) | 1615952410-36895-1-git-send-email-feng.tang@intel.com | v4 ☐☑✓ | [LORE v4,0/13](https://lore.kernel.org/all/1615952410-36895-1-git-send-email-feng.tang@intel.com) |
-| 2021/08/03 | Feng Tang | [Introduce multi-preference mempolicy](https://lore.kernel.org/patchwork/patch/1471473) | 参见 LWN 报道 [NUMA policy and memory types](https://lwn.net/Articles/862707).
引入 MPOL_PREFERRED_MANY 的 policy, 该 mempolicy 模式可用于 set_mempolicy 或 mbind 接口.
1. 与 MPOL_PREFERRED 模式一样, 它允许应用程序为满足内存分配请求的节点设置首选项. 但是与 MPOL_PREFERRED 模式不同, 它需要一组节点.
2. 与 MPOL_BIND 接口一样, 它在一组节点上工作, 与 MPOL_BIND 不同, 如果首选节点不可用, 它不会导致 SIGSEGV 或调用 OOM killer. | v7 ☑ 5.15-rc1 | [LORE v4,00/13](https://lore.kernel.org/lkml/1615952410-36895-1-git-send-email-feng.tang@intel.com)
*-*-*-*-*-*-*-*
[LORE v7,0/5](https://patchwork.kernel.org/project/linux-mm/cover/1627970362-61305-1-git-send-email-feng.tang@intel.com), [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/tools/perf/builtin-record.c?id=a38a59fdfa10be55d08e4530923d950e739ac6a2) |
+| 2021/08/03 | Feng Tang | [Introduce multi-preference mempolicy](https://lore.kernel.org/patchwork/patch/1471473) | 参见 LWN 报道 [NUMA policy and memory types](https://lwn.net/Articles/862707).
引入 MPOL_PREFERRED_MANY 的 policy, 该 mempolicy 模式可用于 set_mempolicy 或 mbind 接口.
1. 与 MPOL_PREFERRED 模式一样, 它允许应用程序为满足内存分配请求的节点设置首选项. 但是与 MPOL_PREFERRED 模式不同, 它需要一组节点.
2. 与 MPOL_BIND 接口一样, 它在一组节点上工作, 与 MPOL_BIND 不同, 如果首选节点不可用, 它不会导致 SIGSEGV 或调用 OOM killer. | v7 ☑ 5.15-rc1 | [LORE v4,00/13](https://lore.kernel.org/all/1615952410-36895-1-git-send-email-feng.tang@intel.com)
*-*-*-*-*-*-*-*
[LORE v7,0/5](https://patchwork.kernel.org/project/linux-mm/cover/1627970362-61305-1-git-send-email-feng.tang@intel.com), [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/tools/perf/builtin-record.c?id=a38a59fdfa10be55d08e4530923d950e739ac6a2) |
| 2021/11/01 | "Aneesh Kumar K.V" | [mm: add new syscall set_mempolicy_home_node](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=21b084fdf2a49ca1634e8e360e9ab6f9ff0dee11) | 增加了 set_mempolicy_home_node() 来为用户空间的一段地址 [start, srart + len] 指定内存分配的主节点 home_node. 主节点 home_node 应与 MPOL_PREFERRED_MANY 或 MPOL_BIND 内存分配策略结合使用. 这些策略可以指定一组将用于新内存分配的节点, 但不能说明这些节点中的哪个节点 (如果有) 是首选节点. 如果设置了 home_node, 则分配内存时将优先在该节点上进行分配; 否则, 主节点 home_node 内存不足, 则将回退到有效策略允许的其他节点上分配, 首选最接近主节点的节点. 其目的是让应用程序能够更好地控制内存分配, 同时避免来自慢速节点的内存. 参见 LWN 报道 [Some upcoming memory-management patches](https://lwn.net/Articles/875587). | v1 ☑✓ 5.17-rc1 | [PatchWork v4,0/3](https://patchwork.kernel.org/project/linux-mm/cover/20211101050206.549050-1-aneesh.kumar@linux.ibm.com) |
| 2022/04/12 | Wei Yang | [mm/page_alloc: add same penalty is enough to get round-robin order](https://lore.kernel.org/all/20220412001319.7462-1-richard.weiyang@gmail.com) | 20220412001319.7462-1-richard.weiyang@gmail.com | v3 ☐☑✓ | [LORE](https://lore.kernel.org/all/20220412001319.7462-1-richard.weiyang@gmail.com) |
+#### 2.2.3.2 Weighted memory interleaving
+-------
+
+
+| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:----:|:----:|:---:|:----:|:---------:|:----:|
+| 2023/11/22 | Gregory Price | [mm/mempolicy: Make task->mempolicy externally modifiable via syscall and procfs](https://lore.kernel.org/all/20231122211200.31620-1-gregory.price@memverge.com) | 该补丁集允许其他特权进程修改当前任务的内存策略 task->mempolicy. 最终目标是使 mempolicy 更加灵活和可扩展, 例如添加交织权重 Weighted memory interleaving (由于热插拔事件, 可能需要在运行时更改). 通过对 mempolicy 进行外部修改, userland 守护进程可以对正在运行的任务进行运行时性能调整, 而无需使该软件具有 numa 意识. | v1 ☐☑✓ | [LORE v1,0/11](https://lore.kernel.org/all/20231122211200.31620-1-gregory.price@memverge.com) |
+| 2023/12/23 | Gregory Price | [mempolicy2, mbind2, and weighted interleave](https://lore.kernel.org/all/20231223181101.1954-1-gregory.price@memverge.com) | 参照 LWN 报道 [Weighted memory interleaving and new system calls](https://lwn.net/Articles/969379). | v5 ☐☑✓ | [LORE v5,0/11](https://lore.kernel.org/all/20231223181101.1954-1-gregory.price@memverge.com) |
+
+
### 2.2.4 内存水线
-------
@@ -4107,6 +4122,10 @@ Meta(原 Facebook) 博客 [Transparent memory offloading: more memory at a fract
[LSF/MM 2019](https://lwn.net/Articles/lsfmm2019) 期间, 主动回收 IDLE 页面的议题引起了开发者的关注. 通过对业务持续一段时间的页面使用进行监测, 回收掉那些不常用的或者没必要的页面, 在满足业务需求的前提下, 可以节省大量的内存. 这可能比启发式的 kswapd 更有效. 这包括两部分的内容:
+| 日期 | LWN | 翻译 |
+|:---:|:----:|:---:|
+| 2024/05/17 | [An update and future plans for DAMON](https://lwn.net/Articles/973702) | NA |
+
后来还有一些类似的特性也达到了很好的效果.
1. intel 在对 NVDIMM/PMEM 进行支持的时候, 为了将热页面尽量使用快速的内存设备, 而冷页面尽量使用慢速的内存设备. 因此实现了冷热页跟踪机制. 完善了 idle page tracking 功能, 实现 per process 的粒度上跟踪内存的冷热. 在 reclaim 时将冷的匿名页面迁移到 PMEM 上 (只能迁移匿名页). 同时利用一个 userspace 的 daemon 和 idle page tracking, 来将热内存(在 PMEM 上的) 迁移到 DRA M 中. [ept-idle](https://github.com/intel/memory-optimizer/tree/master/kernel_module).
@@ -4199,6 +4218,15 @@ PowerPC 体系结构 (POWER10) 支持热/冷页面跟踪功能(Hot/Cold page tra
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2023/05/10 | Yuanchu Xie | [mm: Working Set Reporting](https://lore.kernel.org/all/20230509185419.1088297-1-yuanchu@google.com) | balloon device 是在来宾虚拟机和主机之间共享内存的典型机制. 开发这种 [auto-ballon 能力](https://www.linux-kvm.org/page/Projects/auto-ballooning)的早期项目于 2013 年完成. 最近, 已经创建了额外的VIRTIO设备(VIRTIO -mem、VIRTIO -pmem), 为许多用例提供了[更多的工具](https://kvmforum2020.sched.com/event/eE4U/virtio-balloonpmemmem-managing-guest-memory-david-hildenbrand-michael-s-tsirkin-red-hat), 每种工具都有优点和缺点，它在多虚拟机场景中特别有用, 在这种场景中, 内存被过度使用, 并且随着系统上工作负载的变化, 需要动态更改虚拟机内存大小. balloon device 现在有许多特性来帮助在来宾和主机之间明智地共享内存资源 (例如, 免费页面提示、统计、免费页面报告). 对于在多虚拟机环境中负责优化内存资源的主控制器程序, 它必须使用这些工具来回答两个具体问题: 统一的工作集报告结构, 适用于服务器和客户端. 它涉及主机上的每个节点直方图、每个内存直方图和虚拟气球驱动程序扩展.
有两种使用工作集报告的方法: 事件驱动和查询. 主机控制器可以接收来自 reclaim 的通知, 它会生成一个报告, 或者控制器可以直接查询直方图.
1. 补丁 1 引入了工作集报告机制和主机接口. 补丁 2 扩展了带有工作集报告的虚拟 balloon 驱动程序.
最初的 RFC 以 MGLRU 为基础, 旨在作为讨论和改进的概念验证. tj 和作者的目标是支持活动 / 非活动 LRU 和来自用户空间的工作集估计. 作者正在编写演示脚本并获得一些数据. 参见 LWN 报道 [Memory overcommit in containerized environments](https://lwn.net/Articles/931658) 和 phoronix 报道 [Google's Working Set Reporting Feature Aims To Better Deal With Over-Committed VMs](https://www.phoronix.com/news/Working-Set-Reporting). | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20230509185419.1088297-1-yuanchu@google.com)
*-*-*-*-*-*-*-*
[LORE v2,0/6](https://lore.kernel.org/r/20230621180454.973862-1-yuanchu@google.com) |
+### 4.4.7 Working Set Control
+-------
+
+
+| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:---:|:----:|:---:|:----:|:---------:|:----:|
+| 2021/11/30 | Alexey Avramov | [mm/vmscan: add sysctl knobs for protecting the working set](https://lore.kernel.org/all/20211130201652.2218636d@mail.inbox.lv) | 内核没有提供在内存压力下保护工作集的方法. 用户空间的正常操作需要一定数量的匿名和干净的文件页面. 首先, 用户空间需要共享库和可执行二进制文件的缓存. 如果干净文件页面的数量低于一定的水平, 那么就会发生抖动甚至是动态锁. 该补丁提供了 sysctl, 用于在内存压力下保护工作集 (匿名和干净的文件页面). vm.anon_min_kbytes sysctl 旋钮提供匿名页面的**硬**保护. 当前节点上的匿名页面数量低于 vm.anon_min_kbytes 时, 在任何情况下都不会被回收. 这个 sysctl 可用于防止匿名内存不足时的过多交换抖动(例如, 当内存将被 zram 模块的压缩数据过度填充时). 缺省值由 CONFIG_ANON_MIN_KBYTES 定义 (建议在 Kconfig 中为 0). vm.clean_low_kbytes 旋钮提供尽最大努力保护干净的文件页面. 当前节点上的文件页面清理量小于 vm 时, 不会在内存压力下进行回收. 除非我们威胁要 OOM. 使用此旋钮保护干净的文件页面, 可以在交换时使用. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20211130201652.2218636d@mail.inbox.lv) |
+
+
# 5 Swappiness
-------
@@ -5111,7 +5139,9 @@ THP 虽然实现了, 但是依旧存在着不少问题. 在 LSFMM 2015 进行了
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2015/10/06 | Kirill A. Shutemov" | [THP refcounting redesign](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=ddc58f27f9ee) | NA | v12 ☑ 4.5-rc1 | [LWN RFC 00/10](https://lwn.net/Articles/601781)
*-*-*-*-*-*-*-*
[LORE RFC v2,00/19](https://lore.kernel.org/lkml/1415198994-15252-1-git-send-email-kirill.shutemov@linux.intel.com)
*-*-*-*-*-*-*-*
[LORE RFC v12,00/37](https://lore.kernel.org/lkml/1444145044-72349-1-git-send-email-kirill.shutemov@linux.intel.com) |
-| 2016/05/06 | Andrea Arcangeli | [mm: thp: mapcount updates](https://lore.kernel.org/all/1462547040-1737-1-git-send-email-aarcange@redhat.com) | NA | v1 ☑ 4.6 | [LORE 0/3](https://lore.kernel.org/all/1462547040-1737-1-git-send-email-aarcange@redhat.com), [关键 COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6d0a07edd17c) |
+| 2016/05/06 | Andrea Arcangeli | [mm: thp: mapcount updates](https://lore.kernel.org/all/1462547040-1737-1-git-send-email-aarcange@redhat.com) | NA | v1 ☑ 4.6 | [LORE 0/3](https://lore.kernel.org/all/1462547040-1737-1-git-send-email-aarcange@redhat.com), [关键 COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6d0a07edd17c)|
+| 2024/03/28 | Barry Song <21cnbao@gmail.com> | [mm: add per-order mTHP alloc_success and alloc_fail counters](https://lore.kernel.org/all/20240328095139.143374-1-21cnbao@gmail.com) | 由于缺乏对系统操作的可见性, 盲目地用 mTHP 分析系统变得具有挑战性. 呈现 mTHP 分配的成功率似乎是迫切需要的. 最近, 我在调试没有这些数据的性能改进和回归时遇到了很大的困难. 对开发者来说, 了解 mTHP 在现实世界场景中的真正有效性至关重要, 尤其是在具有碎片内存的系统中. 这个 PATCHSET 引入 alloc_success 和 alloc_fail 计数器, 实现了每个 ORDER 的 mTHP 计数器统计的框架. | v2 ☐☑✓ | [2024/03/26, LORE v1](https://lore.kernel.org/linux-mm/20240326030103.50678-1-21cnbao@gmail.com)
*-*-*-*-*-*-*-*
[2024/03/28, LORE v2](https://lore.kernel.org/all/20240328095139.143374-1-21cnbao@gmail.com) |
+
### 7.2.3 THP allocations latencies
-------
diff --git a/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md b/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md
index f030780..17c6192 100644
--- a/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md
+++ b/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md
@@ -108,7 +108,9 @@
| 6.6 | [The first half of the 6.6 merge window](https://lwn.net/Articles/942954), [The rest of the 6.6 merge window](https://lwn.net/Articles/943245) | NA | NA |
| 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)
+| 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) | NA | NA |
+
年终盘点
@@ -190,18 +192,19 @@ OSDI 的全称是 USENIX Symposium on Operating Systems Design and Implementatio
## 6.5 LSFMM
-------
-| 日期 | 链接 |
-|:---:|:----:|
-| 2022/05/02 ~ 2022/05/04 | [LSFMM-2022](https://lwn.net/Articles/893733) |
+| 日期 | 链接 | GOOGLE 文档 |
+|:---:|:----:|:-----------:|
+| 2022/05/02 ~ 2022/05/04 | [LSFMM-2022](https://lwn.net/Articles/893733) | NA |
+| NA | []() | [LSFMMBPF 2023 Schedule](https://docs.google.com/spreadsheets/d/1tIDYHgLhhcetoXtgyvcoM6YZWWHcVLdNYipBq2dH-_k/edit#gid=1622936535) |
-## 6.6 OSPM
+## 6.6 OSPM(Power Management and Scheduling in the Linux Kernel)
-------
-| 日期 | 官网 | 链接 |
-|:---:|:----:|:----:|
-| 2023/04/17-2023/04/19 | [5th OSPM Summit](https://retis.santannapisa.it/luca/ospm-summit/2023) | [LWN 汇总](https://lwn.net/Archives/ConferenceIndex/#OS-Directed_Power-Management_Summit-2023)
[LWN-Reports from OSPM 2023, part 1](https://lwn.net/Articles/934142)
[LWN-Reports from OSPM 2023, part 2](https://lwn.net/Articles/934459)
[LWN-Reports from OSPM 2023, part 3](https://lwn.net/Articles/935180) |
-
+| 日期 | 官网 | 链接 | GOOGLE 文档 |
+|:---:|:----:|:---:|:-----------:|
+| 2023/04/17-2023/04/19 | [5th OSPM Summit](https://retis.santannapisa.it/luca/ospm-summit/2023) | [LWN 汇总](https://lwn.net/Archives/ConferenceIndex/#OS-Directed_Power-Management_Summit-2023)
[LWN-Reports from OSPM 2023, part 1](https://lwn.net/Articles/934142)
[LWN-Reports from OSPM 2023, part 2](https://lwn.net/Articles/934459)
[LWN-Reports from OSPM 2023, part 3](https://lwn.net/Articles/935180) | [OSPM23 - topics - Google 云端硬盘](https://docs.google.com/spreadsheets/u/0/d/10AJFQporrCPH9Gn6-MaRotdfO4Hm4LG6dVAoDrQdj5A/htmlview?pli=1#gid=1185197977) |
+| 2024/05/30-2024/05/21 | [6th OSPM Summit](https://retis.sssup.it/ospm-summit/2024) | [LWN 汇总]()
[LORE](https://lore.kernel.org/all/ZbJHfiWnujLz2Pfm@localhost.localdomain) | [OSPM24 - topics - Google 云端硬盘](https://docs.google.com/spreadsheets/d/13lOYsbNWhQU7pNbyHI97fC7GT0Eu8aMbU9ATvPJfV0A/edit?usp=sharing) |
## 6.7 [KernelPodCast](https://kernelpodcast.org)
-------
@@ -211,6 +214,14 @@ OSDI 的全称是 USENIX Symposium on Operating Systems Design and Implementatio
[Power Management and Scheduling in the Linux Kernel V edition (OSPM-summit 2023)](https://lore.kernel.org/all/Y8lFkbJ6nluNdVYO@localhost.localdomain/)
+
+## 6.8 Linaro Forum for Arm Linux kernel
+-------
+
+
+[The first Linaro Forum for Arm Linux kernel topics](https://lwn.net/Articles/969031)
+
+
# 7 统计信息
-------
diff --git a/study/kernel/00-DESCRIPTION/SCHEDULER.md b/study/kernel/00-DESCRIPTION/SCHEDULER.md
index f8ba36e..b600d9d 100644
--- a/study/kernel/00-DESCRIPTION/SCHEDULER.md
+++ b/study/kernel/00-DESCRIPTION/SCHEDULER.md
@@ -158,7 +158,7 @@ O(n) 调度理解起来简单:
在每次进程切换时, 内核依次扫描就绪队列上的每一个进程, 计算每个进程的优先级, 再选择出优先级最高的进程来运行; 尽管这个算法理解简单, 但是它花费在选择优先级最高进程上的时间却不容忽视. 系统中可运行的进程越多, 花费的时间就越大, 时间复杂度为 O (n).
-### 1.1.1 O(1) 调度器
+### 1.1.2 O(1) 调度器
-------
2.6 时代开始支持 (2002 年引入).
@@ -175,7 +175,7 @@ O(n) 调度理解起来简单:
| 2002/02/11 | Ingo Molnar | [merge to the -K3 scheduler.](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=908920b1d370e7a5c301d14cfce10c310be19be3) | TODO | v1 ☑✓ 2.5.2 | [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e54bc75751cfb3c3eb5da7bdc900b8adcc2cda4) |
-### 1.1.2 夭折的 RSDL(The Rotating Staircase Deadline Scheduler) 调度器
+### 1.1.3 夭折的 RSDL(The Rotating Staircase Deadline Scheduler) 调度器
-------
**2007 年 4 月提出, 预期进入 2.6.22, 后夭折.**
@@ -183,24 +183,37 @@ O(n) 调度理解起来简单:
O(1) 调度器存在一个比较严重的问题: 复杂的交互进程识别启发式算法 - 为了识别交互性的和批处理型的两大类进程, 该启发式算法融入了睡眠时间作为考量的标准, 但对于一些特殊的情况, 经常判断不准, 而且是改完一种情况又发现一种情况.
-Con Kolivas (八卦: 这家伙白天是个麻醉医生) 为解决这个问题提出 **RSDL(The Rotating Staircase Deadline Scheduler)** 算法. 该算法的亮点是对公平概念的重新思考: ** 交互式 (A)** 和 ** 批量式 (B)** 进程应该是被完全公平对待的, 对于两个动态优先级完全一样的 A, B 进程, ** 它们应该被同等地对待, 至于它们是交互式与否 (交互式的应该被更快调度), 应该从他们对分配给他们的时间片的使用自然地表现出来, 而不是应该由调度器自作高明地根据他们的睡眠时间去猜测 **. 这个算法的核心是 **Rotating Staircase**, 是一种衰减式的优先级调整, 不同进程的时间片使用方式不同, 会让它们以不同的速率衰减 (在优先级队列数组中一级一级下降, 这是下楼梯这名字的由来), 从而自然地区分开来进程是交互式的 (间歇性的少量使用时间片) 和批量式的 (密集的使用时间片). 具体算法细节可看这篇文章: [The Rotating Staircase Deadline Scheduler [LWN.net]](https://link.zhihu.com/?target=https%3A//lwn.net/Articles/224865/)
+Con Kolivas (八卦: 这家伙白天是个麻醉医生) 为解决这个问题提出 **RSDL(The Rotating Staircase Deadline Scheduler)** 算法. 该算法的亮点是对公平概念的重新思考: ** 交互式 (A)** 和 ** 批量式 (B)** 进程应该是被完全公平对待的, 对于两个动态优先级完全一样的 A, B 进程, ** 它们应该被同等地对待, 至于它们是交互式与否 (交互式的应该被更快调度), 应该从他们对分配给他们的时间片的使用自然地表现出来, 而不是应该由调度器自作高明地根据他们的睡眠时间去猜测 **. 这个算法的核心是 **Rotating Staircase**, 是一种衰减式的优先级调整, 不同进程的时间片使用方式不同, 会让它们以不同的速率衰减 (在优先级队列数组中一级一级下降, 这是下楼梯这名字的由来), 从而自然地区分开来进程是交互式的 (间歇性的少量使用时间片) 和批量式的 (密集的使用时间片). 具体算法细节可看这篇文章: [The Rotating Staircase Deadline Scheduler [LWN.net]](https://link.zhihu.com/?target=https%3A//lwn.net/Articles/224865)
-[RSDL cpu scheduler v0.33](https://lore.kernel.org/lkml/200703232005.05839.kernel@kolivas.org)
+[2007/03/04, RSDL completely fair starvation free interactive cpu scheduler](https://lwn.net/Articles/224654)
-[debug rsdl 0.33](https://lore.kernel.org/lkml/200703241026.57143.kernel@kolivas.org)
+[2007/03/23, RSDL cpu scheduler v0.33](https://lore.kernel.org/lkml/200703232005.05839.kernel@kolivas.org)
-[[REPORT] cfs-v4 vs sd-0.44](https://lore.kernel.org/lkml/20070421121235.GA2044@1wt.eu)
+[2007/03/24, debug rsdl 0.33](https://lore.kernel.org/lkml/200703241026.57143.kernel@kolivas.org)
-[rsdl v46 report,numbers,comments](https://lore.kernel.org/lkml/20070424112601.56f5bfb6@reforged/)
+[2007/04/21, [REPORT] cfs-v4 vs sd-0.44](https://lore.kernel.org/lkml/20070421121235.GA2044@1wt.eu)
+
+[2007/04/24, rsdl v46 report,numbers,comments](https://lore.kernel.org/lkml/20070424112601.56f5bfb6@reforged/)
+
+[cheduler Situation](https://lore.kernel.org/all/cdc89fe60708030507r29283942mbb9947edbe04e23a@mail.gmail.com)
+
+### 1.1.4 nicksched
+-------
+
+[nicksched v33](https://lwn.net/Articles/229250)
### 1.1.3 完全公平的调度器 (CFS)
-------
+| 日期 | LWN | 翻译 |
+|:---:|:----:|:---:|
+| 2007/04/17 | [Schedulers: the plot thickens](https://lwn.net/Articles/230574) | [LWN 230574: 内核调度器替换方案的激烈竞争](https://tinylab.org/lwn-230574), [知乎--草莓熊麦昆的翻译](https://zhuanlan.zhihu.com/p/697235380) |
+
**2.6.23(2007 年 10 月发布)**
-Con Kolivas 的完全公平的想法启发了原 O(1) 调度器作者 Ingo Molnar, 他重新实现了一个新的调度器, 叫 CFS(Completely Fair Scheduler). 它从 RSDL/SD 中吸取了完全公平的思想, 不再跟踪进程的睡眠时间, 也不再企图区分交互式进程. 它将所有的进程都统一对待, 这就是公平的含义. CFS 的算法和实现都相当简单, 众多的测试表明其性能也非常优越.
+Con Kolivas 的完全公平的想法启发了原 O(1) 调度器作者 Ingo Molnar, 他重新实现了一个新的调度器, 叫 CFS(Completely Fair Scheduler). 它从 RSDL/SD 中吸取了完全公平的思想, 不再跟踪进程的睡眠时间, 也不再企图区分交互式进程. 它将所有的进程都统一对待, 这就是公平的含义. CFS 的算法和实现都相当简单, 众多的测试表明其性能也非常优越.参见 [2007/04/13, [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]](https://lwn.net/Articles/230501).
-> 新的 CFS 调度器的核心同样是 ** 完全公平性 **, 即平等地看待所有普通进程, 让它们自身行为彼此区分开来, 从而指导调度器进行下一个执行进程的选举.
+> 新的 CFS 调度器的核心同样是 完全公平性, 即平等地看待所有普通进程, 让它们自身行为彼此区分开来, 从而指导调度器进行下一个执行进程的选举.
不管是 O(n) 还是 O(1) 调度算法, 其基本思路都是通过一系列运行指标确定进程的优先级, 然后根据进程的优先级确定调度哪个进程, 而 CFS 则转换了一种思路, 它不计算优先级, 而是通过计算进程消耗的 CPU 时间 (标准化以后的虚拟 CPU 时间) 来确定谁来调度. 从而到达所谓的公平性.
@@ -461,11 +474,16 @@ RT_RUNTIME_SHARE 这个机制本身是为了解决不同 CPU 上, 以及不同
[1½ Topics: realtime throttling and user-space adaptive spinning](https://lwn.net/Articles/931789)
-[Deadline servers as a realtime throttling replacement](https://lwn.net/Articles/934415)
+| 日期 | LWN | 翻译 |
+|:---:|:----:|:---:|
+| 2013/01/29 | [Deadline servers as a realtime throttling replacement](https://lwn.net/Articles/934415) | [LinuxNews搬运工--LWN: 用 deadline server 来实现实时任务的限制!](https://blog.csdn.net/Linux_Everything/article/details/131388431), [知乎--草莓熊麦昆的翻译](https://zhuanlan.zhihu.com/p/697548424) |
+
+
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
-| 2023/06/08 | Daniel Bristot de Oliveira | [SCHED_DEADLINE server infrastructure](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=63ba8422f876e32ee564ea95da9a7313b13ff0a1) | 如果具有较高优先级的任务 (例如 SCHED_FIFO) 独占 CPU, 则低优先级任务 (例如, SCHED_OTHER) 可能会出现饥饿. RT Throttling 是不久前引入的一种 (主要是调试) 对策, 可以用来为低优先级任务 (通常是后台类型的工作, 例如工作队列、计时器等) 保留一些 CPU 时间. 然而, 它也有自己的问题 (请参阅文档), 并且即使不需要运行优先级较低的活动, 也会无条件地限制 FIFO 任务, 这会产生不希望的影响 (也有一些机制可以解决这个问题, 但同样也有其自身的问题). 引入截止日期服务器, 为饥饿条件下的低优先级任务需求提供服务. 最后期限服务器是通过扩展 SCHED_Deadline 实现来构建的, 以允许两级调度 (即, deadline 实体成为低优先级调度实体的容器). | v3 ☐☑✓ v6.8-rc1 | [LORE v1,00/13](https://lore.kernel.org/all/20190726145409.947503076@infradead.org)
*-*-*-*-*-*-*-*
[LORE v2,0/6](https://lore.kernel.org/all/20200807095051.385985-1-juri.lelli@redhat.com)
*-*-*-*-*-*-*-*
[LORE v3,0/6](https://lore.kernel.org/all/cover.1686239016.git.bristot@kernel.org)
*-*-*-*-*-*-*-*
[LORE v5,0/7](https://lore.kernel.org/all/cover.1699095159.git.bristot@kernel.org) |
+| 2023/06/08 | Daniel Bristot de Oliveira | [SCHED_DEADLINE server infrastructure](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=63ba8422f876e32ee564ea95da9a7313b13ff0a1) | 如果具有较高优先级的任务 (例如 SCHED_FIFO) 独占 CPU, 则低优先级任务 (例如, SCHED_OTHER) 可能会出现饥饿. RT Throttling 是不久前引入的一种 (主要是调试) 对策, 可以用来为低优先级任务 (通常是后台类型的工作, 例如工作队列、计时器等) 保留一些 CPU 时间. 然而, 它也有自己的问题 (请参阅文档), 并且即使不需要运行优先级较低的活动, 也会无条件地限制 FIFO 任务, 这会产生不希望的影响 (也有一些机制可以解决这个问题, 但同样也有其自身的问题). 引入截止日期服务器, 为饥饿条件下的低优先级任务需求提供服务. 最后期限服务器是通过扩展 SCHED_Deadline 实现来构建的, 以允许两级调度 (即, deadline 实体成为低优先级调度实体的容器). | v3 ☐☑✓ v6.8-rc1 | [LORE v1,00/13](https://lore.kernel.org/all/20190726145409.947503076@infradead.org)
*-*-*-*-*-*-*-*
[LORE v2,0/6](https://lore.kernel.org/all/20200807095051.385985-1-juri.lelli@redhat.com)
*-*-*-*-*-*-*-*
[LORE v3,0/6](https://lore.kernel.org/all/cover.1686239016.git.bristot@kernel.org)
*-*-*-*-*-*-*-*
[LORE v5,0/7](https://lore.kernel.org/all/cover.1699095159.git.bristot@kernel.org)
*-*-*-*-*-*-*-*
[LORE v6,0/6](https://lore.kernel.org/all/cover.1712337227.git.bristot@kernel.org) |
+| 2024/03/12 | Joel Fernandes (Google) | [Fair scheduling deadline server fixes](https://lore.kernel.org/all/20240313012451.1693807-1-joel@joelfernandes.org) | 截止日期服务器 [SCHED_DEADLINE server infrastructure](https://lore.kernel.org/all/cover.1699095159.git.bristot@kernel.org) 允许 RT 任务在系统上安全运行, 而不是由于 RT 节流, 浪费了 RT 任务可能无法在空闲系统上执行的 CPU. 以下是我们在测试 ChromeOS 的截止日期服务器时发现的修补程序. 当我发现我的单元测试正在崩溃时, 它像滚雪球一样从 10 个补丁增加到 15 个补丁, 然后我们也看到了与 dl_timer 相关的领域中的一些崩溃! 所有这些都是固定的. 在其他几个修复程序中, 还有一个对核心调度的修复程序. 感谢您的全面审查. 我把所有的补丁都放在 Daniel 和 Peter 的补丁之上, 因为我会让他们把它压缩掉, 并适当地归因于贡献者. | v2 ☐☑✓ | [LORE 00/10](https://lore.kernel.org/all/20240216183108.1564958-1-joel@joelfernandes.org)
*-*-*-*-*-*-*-*
[LORE v2,0/15](https://lore.kernel.org/all/20240313012451.1693807-1-joel@joelfernandes.org) |
## 1.4 其他一些调度类的尝试
@@ -631,6 +649,7 @@ coscheduling 协同调度是为了解决云服务场景, 为不同用户提供
| 2022/09/29 | Cruz Zhao | [sched/core: Optimize the process of picking the max prio task for the core](https://lore.kernel.org/all/1664435913-57227-1-git-send-email-CruzZhao@linux.alibaba.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/1664435913-57227-1-git-send-email-CruzZhao@linux.alibaba.com)
*-*-*-*-*-*-*-*
[LORE](https://lore.kernel.org/all/1664767168-30029-1-git-send-email-CruzZhao@linux.alibaba.com) |
| 2021/08/17 | Josh Don | [sched/core: Simplify core-wide task selection](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bc9ffef31bf59819c9fc032178534ff9ed7c4981) | 对于 Core Scheduling, 如果 cookie 不匹配, pick_next_task 将更新 "max" 任务 (因为在这种情况下, 新任务的优先级必须高于当前最大值). 然而, 如果我们找到一个具有匹配 cookie 且优先级高于 "max" 的任务, 却无法更新 "max". 这可能导致 SMT-X(X> 2) 机器上的额外迭代. Josh Don 尝试通过 [sched/core: fix pick_next_task'max'tracking](https://lore.kernel.org/all/20210818005615.138527-1-joshdon@google.com) 修复此问题. 最终经过讨论. Tao 建议采用两次任务选择来避免重试循环. 第一次遍历从所有 SMT 上查找 max, 找到其 max->core_cookie, 第二次遍历基于此 core_cookie 为每个 SMT CPU Thread pick_task, 它不仅避免了重试循环, 还使代码更简单. 同时修复了 Josh Don 发现的问题. | v1 ☑✓ 5.16-rc1 | [LORE](https://lore.kernel.org/all/YSS9+k1teA9oPEKl@hirez.programming.kicks-ass.net) |
| 2023/03/22 | Hao Jia | [sched/core: Avoid selecting the task that is throttled to run when core-sched enable](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=530bfad1d53d103f98cec66a3e491a36d397884d) | 当 `{rt, cfs}_rq` 或 `dl` 任务被节流时, 由于 cookie 任务不会从核心树中退出队列, 因此 sched_core_find() 和 sched_core_next() 可能返回 throttledtask, 这可能导致 throttledtask 在 CPU 上运行. 因此, 我们在 sched_core_find() 和 sched_core_next() 中添加检查, 以确保返回的是一个未受限制的可运行任务. | v1 ☐☑✓ 6.4-rc1 | [LORE](https://lore.kernel.org/all/167947694502.5837.16156353798978583164.tip-bot2@tip-bot2) |
+| 2024/03/07 | Cruz Zhao | [introduce CPUTIME_FORCEIDLE_TASK and add](https://lore.kernel.org/all/20240307101945.11280-1-CruzZhao@linux.alibaba.com) | 由于 core sched 使用 rq_clock() 作为时钟源来计算 forceidle 时间, irq 时间将被计入 forceidle. 然而, 在某些情况下, forceidle sum 将比 exec 运行时大得多, 例如, 我们观察到调用 futex_wake() 的任务的 forceidle 时间比 exec 运行时大 50%, 这令人困惑. 我们使用 rq_clock_TASK() 作为时钟源, 引入 cpustat[CPUTIME_FORCEIDLE_TASK] 来计算 SMT 兄弟被强制空闲时任务实际运行的时间. | v2 ☐☑✓ | [2024/02/19, LORE](https://lore.kernel.org/all/20240219084134.10673-1-CruzZhao@linux.alibaba.com)
*-*-*-*-*-*-*-*
[2024/03/07, LORE v2,0/3](https://lore.kernel.org/all/20240307101945.11280-1-CruzZhao@linux.alibaba.com) |
#### 1.5.4.3 SMT 驱离 (SMT expeller) 技术
@@ -744,7 +763,6 @@ CFS 用户反复在社区抱怨并行 kbuild 对桌面交互性有负面影响
| 2022/05/18 | Fam Zheng | [sched: Enable root level cgroup bandwidth control](https://lore.kernel.org/all/20220518100841.1497391-1-fam.zheng@bytedance.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20220518100841.1497391-1-fam.zheng@bytedance.com) |
| 2022/10/19 | Chuyi Zhou | [sched/fair: Add min_ratio for cfs bandwidth_control](https://lore.kernel.org/all/20221019031551.24312-1-zhouchuyi@bytedance.com) | 如果用户设置的配额 / 周期比过小, 在当前的 cfs 带宽控制机制下, 长时间持锁可能会导致任务被节流, 导致整个 [系统卡住](https://lore.kernel.org/lkml/5987be34-b527-4ff5-a17d-5f6f0dc94d6d@huawei.com). 为了防止上述情况的发生, 本补丁在 `procfs` 中增加了 `sysctl_sched_cfs_bandwidth_min_ratio`, 它表示用户可以设置的配额 / 周期的最小百分比. 默认值为 0, 用户可以设置配额和周期而不触发此约束. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20221019031551.24312-1-zhouchuyi@bytedance.com) |
| 2022/10/17 | Josh Don | [sched: async unthrottling for cfs bandwidth](https://lore.kernel.org/all/20221017234750.454419-1-joshdon@google.com) | CFS 带宽目前分配新的运行时, 并在 hrtimer 回调中取消 cfs_rq 的内联. 运行时分发是一个每个 CPU 的操作, 而取消节流是一个每个 cgroup 的操作, 因为需要 tg 遍历. 在拥有大量 CPU 和大型 cgroup 层次结构的机器上, CPU *cgroups 的工作可能在单个 hrtimer 回调中无法完成: 由于 IRQ 被禁用, 很容易发生 hard lockup. 具体来说, 我们发现在 256 个 CPU、O(1000) 个 cCGROUP 在层次结构中被限制以及高内存带宽使用的配置中存在可伸缩性问题. 要解决这个问题, 我们可以通过 CSD 异步取消 cfs_rq 的节流. 每个 CPU 负责自己进行节流, 从而在整个系统中更公平地划分总体工作, 并避免 hard lockup. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20221017234750.454419-1-joshdon@google.com)
*-*-*-*-*-*-*-*
[LORE v2](https://lore.kernel.org/all/20221026224449.214839-1-joshdon@google.com) |
-| 2022/12/12 | Peng Zhang | [sched: Throttling through task work for cfs bandwidth](https://lore.kernel.org/all/20221212061321.36422-1-zhangpeng.00@bytedance.com) | 若任务占用资源并在内核空间中被限制, 则可能会导致阻塞, 从而造成或者加剧优先级翻转的问题. 这组补丁试图通过在任务返回到用户模式时使用 task_work 来限制任务来解决此问题.
这个补丁使用 task_work 在任务返回到用户空间时将 throttle 的任务出队, 然后在 unthrottle 时再将其入列. 当前能正常工作, 但目前的实现并没有考虑到所有的细节, 比如竞争条件、负载跟踪等. 作者认为这种解决方案的最大缺点是, 在解锁过程中可能有太多的任务需要排队, 从而导致巨大的开销和延迟. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20221212061321.36422-1-zhangpeng.00@bytedance.com) |
| 2022/11/16 | Josh Don | [sched: async unthrottling for cfs bandwidth](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=8ad075c2eb1f6b4b33436144ea1ef2619f3b6398) | CFS 带宽当前分配新的运行时, 并在 hrtimer 回调中解除 cfs_rq 的 throttle 限制. 运行时分发是每个 CPU 的操作, 而解节流是每个组的操作, 因为需要执行 tg 遍历. 在具有大量 CPU 和大型 CGROUP 层次结构的机器上, 这种 CPU CGROUP 工作在单个 hrtimer 回调中可能做得太多: 由于 IRQ 被禁用, 可能很容易发生 Hard Lockup.
具体来说, 我们在 256 个 cpu 的配置中发现了这个可伸缩性问题, 层次结构中的 0(1000) 个 cgroups 被限制, 并且内存带宽使用率很高.
为了解决这个问题, 我们可以通过 CSD 异步地解除 cfs_rq 的限制. 每个 cpu 都负责解除自身的限制, 从而在整个系统中更公平地分配总工作, 并避免 Hard Lockup. | v3 ☐☑✓ 6.3-rc1 | [LORE](https://lore.kernel.org/all/20221117005418.3499691-1-joshdon@google.com) |
| 2023/02/24 | Shrikanth Hegde | [Interleave cfs bandwidth timers for improved single thread performance at low utilization](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=41abdba9374734b743019fc1cc05e3225c82ba6b) | CPU CFS 带宽控制器使用 hrtimer. 目前没有初始值设置. 因此, 所有周期计时器将在到期时对齐. 当有多个 CPU CGROUP 时, 就会发生这种情况. 如果在每个 CPU CGROUP 组的利用率较低且所有 CPU CGROUP 组的总利用率低于 50% 时交错使用计时器, 则可以实现性能增益. 如果计时器是交错的, 那么不受限制的 CGROUP 组可以自由运行, 而不需要许多上下文切换, 并且还可以从 SMT 折叠中受益. 这个提交在初始化每个 hrtimer 后添加一个随机偏移量. 这将导致在过期时交错使用计时器, 这有助于实现上述性能增益. | v3 ☐☑✓ 6.4-rc1 | [LORE](https://lore.kernel.org/all/20230223185153.1499710-1-sshegde@linux.vnet.ibm.com) |
@@ -809,12 +827,24 @@ Chang 的 patch set 采用了与之前不同的方法: 允许 cgroup 将一些
| 2022/05/18 | Fam Zheng | [sched: Enable root level cgroup bandwidth control](https://lore.kernel.org/all/20220518100841.1497391-1-fam.zheng@bytedance.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20220518100841.1497391-1-fam.zheng@bytedance.com) |
+#### 2.1.3.5 Defer CFS throttle to user entry
+-------
+
+
+| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:----:|:----:|:---:|:----:|:---------:|:----:|
+| 2022/12/12 | Peng Zhang | [sched: Throttling through task work for cfs bandwidth](https://lore.kernel.org/all/20221212061321.36422-1-zhangpeng.00@bytedance.com) | 若任务占用资源并在内核空间中被限制, 则可能会导致阻塞, 从而造成或者加剧优先级翻转的问题. 这组补丁试图通过在任务返回到用户模式时使用 task_work 来限制任务来解决此问题.
这个补丁使用 task_work 在任务返回到用户空间时将 throttle 的任务出队, 然后在 unthrottle 时再将其入列. 当前能正常工作, 但目前的实现并没有考虑到所有的细节, 比如竞争条件、负载跟踪等. 作者认为这种解决方案的最大缺点是, 在解锁过程中可能有太多的任务需要排队, 从而导致巨大的开销和延迟. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20221212061321.36422-1-zhangpeng.00@bytedance.com) |
+20220526103929.14976-1-zhouchengming@bytedance.com) |
+| 2023/10/30 | Valentin Schneider | [sched/fair: Make the BW replenish timer expire in hardirq context for PREEMPT_RT](https://lore.kernel.org/all/20231030145104.4107573-1-vschneid@redhat.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20231030145104.4107573-1-vschneid@redhat.com) |
+| 2024/02/02 | Valentin Schneider | [sched/fair: Defer CFS throttle to user entry](https://lore.kernel.org/all/20231130161245.3894682-1-vschneid@redhat.com) | Peter 之前再 [Re: [PATCH] sched/fair: Make the BW replenish timer expire in hardirq context for PREEMPT_RT](https://lore.kernel.org/all/20231031160120.GE15024@noisy.programming.kicks-ass.net) 提到 , 对 CFS 任务进行 BW throttle 的时候, 并不在更新运行时统计信息发现 cfs_rq 已经耗尽其配额时, 立即执行 throttle, 而是等待任务即将返回到用户空间时再进行 throttle, 这是非常安全的, 在 PREEMPT_RT 的内核上可以有效地防止内核态优先级翻转, 因为如果它在用户空间中，则无法持有任何内核内锁. | v1 ☐☑✓ | [2023/11/30, LORE v1,0/2](https://lore.kernel.org/all/20231130161245.3894682-1-vschneid@redhat.com)
*-*-*-*-*-*-*-*
[2024/02/02, LORE v2,0/5](https://lore.kernel.org/all/20240202080920.3337862-1-vschneid@redhat.com) |
+
+
### 2.1.4 leaf_cfs_rq
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
-| 2022/05/26 | Chengming Zhou | [sched/fair: optimize and simplify rq](https://lore.kernel.org/all/20220526103929.14976-1-zhouchengming@bytedance.com) | TODO | v3 ☐☑✓ | [LORE v3,0/2](https://lore.kernel.org/all/20220526103929.14976-1-zhouchengming@bytedance.com) |
+| 2022/05/26 | Chengming Zhou | [sched/fair: optimize and simplify rq](https://lore.kernel.org/all/20220526103929.14976-1-zhouchengming@bytedance.com) | TODO | v3 ☐☑✓ | [LORE v3,0/2](https://lore.kernel.org/all/
@@ -1553,13 +1583,12 @@ rebalance_domains()
### 4.3.1.3 新的命名方式
-------
-多年来, 我们已经发展出了一个丰富多彩的调度器负载平衡函数名称动物园——两者都遵循随机, 独特的模式, 以及获得不再准确的历史性误称. 我们有 "newidle_balance()" 来重新平衡新空闲的任务, 有 "rebalance_domains()" 用来重新平衡域. 我们有
-一个 find_idlest_cpu()函数, 其目的不再是查找空闲的 cpu, 以及一个 find_businest_queue()函数, 其目的不再是寻找最繁忙的运行队列. 因此 Ingo 发送了一组补丁集, 对负载均衡中不当的函数名进行了修正, 并沿着 sched_balance_*() 命名空间组织函数:
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:--------:|:----:|
-| 2024/03/08 | Ingo Molnar | [sched/balancing: Standardize the naming of scheduler load-balancing functions](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=686d148cbb5a1c2891914b8d11147d3c5556a29a) | TODO | v1 ☐☑✓ | [LORE v1,0/13](https://lore.kernel.org/all/20240308111819.1101550-1-mingo@kernel.org) |
+| 2024/03/08 | Ingo Molnar | [sched/balancing: Misc updates & cleanups](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=e492e1b0e0721f3929ef9d9708d029144b396dd7) | 修正 load_balancing 路径下部分数据结构以及变量的命名方式. | v1 ☐☑✓ | [LORE v4,00/10](https://lore.kernel.org/all/20240308105901.1096078-1-mingo@kernel.org) |
+| 2024/03/08 | Ingo Molnar | [sched/balancing: Standardize the naming of scheduler load-balancing functions](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log?id=b9e6e28663928cab836a19abbdec3d036a07db3b) | 多年来, 我们已经发展出了一个丰富多彩的调度器负载平衡函数名称动物园——两者都遵循随机, 独特的模式, 以及获得不再准确的历史性误称. 我们有 "newidle_balance()" 来重新平衡新空闲的任务, 有 "rebalance_domains()" 用来重新平衡域. 我们有一个 find_idlest_cpu()函数, 其目的不再是查找空闲的 cpu, 以及一个 find_businest_queue()函数, 其目的不再是寻找最繁忙的运行队列. 因此 Ingo 发送了一组补丁集, 对负载均衡中不当的函数名进行了修正, 并沿着 sched_balance_*() 命名空间组织函数. | v1 ☐☑✓ v6.10-rc1 | [LORE v1,0/13](https://lore.kernel.org/all/20240308111819.1101550-1-mingo@kernel.org) |
### 4.3.2 CFS Task Lists
@@ -1858,6 +1887,8 @@ static inline void calculate_imbalance(struct lb_env *env, struct sd_lb_stats *s
[LPC-2020 的议题](https://linuxplumbersconf.org/event/4/contributions/480).
+[Linux 5.5's Scheduler Sees A Load Balancing Rework For Better Perf But Risks Regressions](https://www.phoronix.com/news/Linux-5.5-Scheduler)
+
2019 年的 [Vincent Guittot](https://www.youtube.com/watch?v=cfv63BMnIug) 的 [LWN: Reworking CFS load balancing](https://lwn.net/Articles/793427) 是近几年特别有亮点的补丁.
博主个人一直是计算机先驱 "高德纳" 教授 "文学化编程" 思想的坚定追随者, 小米创始人雷军雷布斯先生也说 "写代码要有写诗一样的感觉". 这种代码才真的让人眼前一亮, 如沐春风. 这个就是我看到 [rework_load_balance 这组补丁](https://lore.kernel.org/patchwork/cover/1141687) 的感觉. 这组补丁通过重构 (CFS) load_balance 的逻辑, 将原来逻辑混乱的 load_balance 变成了内核中一抹亮丽的风景, 不光使得整个 load_balance 的框架更清晰, 可读性更好. 更带来了性能的提升.
@@ -2673,7 +2704,6 @@ commit [6e5fb223e89d ("mm: sched: numa: Implement constant, per task Working Set
| 2024/03/22 | Raghavendra K T | [A Summary of VMA scanning improvements explored](https://lore.kernel.org/all/cover.1710829750.git.raghavendra.kt@amd.com) | NUMA Balancing 改进的第一个版本, 参考了 Ingo 和 PeterZ 的建议. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/cover.1710829750.git.raghavendra.kt@amd.com) |
| 2023/05/03 | Raghavendra K T | [sched/numa: Disjoint set vma scan improvements](https://lore.kernel.org/all/cover.1683033105.git.raghavendra.kt@amd.com) | TODO | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/cover.1683033105.git.raghavendra.kt@amd.com) |
| 2023/08/29 | Raghavendra K T | [sched/numa: Enhance disjoint VMA scanning](https://lore.kernel.org/all/cover.1693287931.git.raghavendra.kt@amd.com) | 针对 NUMA 平衡增强 VMA 扫描的延续, 试图通过增强无条件 VMA 扫描逻辑来解决上述问题. | v1 ☐☑✓ | [LORE v1,0/6](https://lore.kernel.org/all/cover.1693287931.git.raghavendra.kt@amd.com) |
-| 2024/03/22 | Raghavendra K T | [A Summary of VMA scanning improvements explored](https://lore.kernel.org/all/cover.1710829750.git.raghavendra.kt@amd.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/cover.1710829750.git.raghavendra.kt@amd.com) |
### 4.6.4 NUMA Balancing Placement And Migration
@@ -3396,7 +3426,7 @@ v4.13 引入 NUMA WAKE AFFINE 的时候测试发现, CPU 的空闲造成了 NAS
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:---:|:----------:|:----:|
-| 2023/02/08 | Bharata B Rao | [Memory access profiler(IBS) driven NUMA balancing](https://lore.kernel.org/all/20230208073533.715-1-bharata@amd.com) | 一些硬件平台可以提供有关内存访问的信息, 这些信息可用于在 NUMA 系统上进行最佳页面和任务放置. AMD 处理器有一个称为基于指令的采样 (IBS) 的硬件设施, 可用于收集与指令获取和执行活动相关的特定度量. 此工具可用于基于统计采样执行内存访问分析. 这组补丁实现了基于硬件获得的访问信息进行驱动 NUMA 平衡. 这样, 就不再需要周期性地扫描地址空间并引入 NUMA FAULT 来构建任务到页面的访问关联. 因此, 这里采用的方法是用硬件提供的访问信息替换地址空间扫描加提示错误. 从硬件获得的访问样本作为 NUMA FAULT 的等价信息被反馈到 NUMA BALANCING. NUMA BALANCING 逻辑的其余部分 (收集 / 聚合共享 / 私有 / 本地 / 远程故障并根据故障执行页面 / 任务迁移) 将保留, 但访问替换故障除外. | v1 ☐☑✓ | [LORE v1,0/5](https://lore.kernel.org/all/20230208073533.715-1-bharata@amd.com) |
+| 2023/02/08 | Bharata B Rao | [Memory access profiler(IBS) driven NUMA balancing](https://lore.kernel.org/all/20230208073533.715-1-bharata@amd.com) | 一些硬件平台可以提供有关内存访问的信息, 这些信息可用于在 NUMA 系统上进行最佳页面和任务放置. AMD 处理器有一个称为基于指令的采样 (IBS) 的硬件设施, 可用于收集与指令获取和执行活动相关的特定度量. 此工具可用于基于统计采样执行内存访问分析. 这组补丁实现了基于硬件获得的访问信息进行驱动 NUMA 平衡. 这样, 就不再需要周期性地扫描地址空间并引入 NUMA FAULT 来构建任务到页面的访问关联. 因此, 这里采用的方法是用硬件提供的访问信息替换地址空间扫描加提示错误. 从硬件获得的访问样本作为 NUMA FAULT 的等价信息被反馈到 NUMA BALANCING. NUMA BALANCING 逻辑的其余部分 (收集 / 聚合共享 / 私有 / 本地 / 远程故障并根据故障执行页面 / 任务迁移) 将保留, 但访问替换故障除外. [知乎-PMU 驱动的 NUMA Balancing](https://zhuanlan.zhihu.com/p/697689798). | v1 ☐☑✓ | [LORE v1,0/5](https://lore.kernel.org/all/20230208073533.715-1-bharata@amd.com) |
### 4.6.7 学术研究
@@ -3790,6 +3820,7 @@ Chen Yu 新的思路是, 首先在 SMT 域中扫描一个空闲的同级节点.
| 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) |
### 4.7.5 sync wakeup
@@ -4315,10 +4346,11 @@ ARM EAS 支持的主页: [Energy Aware Scheduling (EAS)](https://developer.arm.c
[Energy Aware Scheduling (EAS) progress update](https://www.linaro.org/blog/energy-aware-scheduling-eas-progress-update)
+[Teaching the scheduler about power management](https://lwn.net/Articles/602479)
| static_key | 描述 | COMMIT |
|:----------:|:---:|:------:|
-| sched_asym_cpucapacity | Capacity Aware Scheduling 特性开关 | [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df054e8445a4011e3d693c2268129c0456108663) || sched_energy_present | EAS 的特性开关. | [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1f74de8798c93ce14801cc4e772603e51c841c33) |
+| sched_asym_cpucapacity | Capacity Aware Scheduling 特性开关 | [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df054e8445a4011e3d693c2268129c0456108663) | sched_energy_present | EAS 的特性开关. | [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1f74de8798c93ce14801cc4e772603e51c841c33) |
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:---:|:----------:|:----:|
@@ -4427,6 +4459,7 @@ Donnefort 称: 边距删除使内核能够充分利用能量模型, 任务更有
|:----:|:----:|:---:|:---:|:----------:|:----:|
| 2022/06/21 | Vincent Donnefort | [feec() energy margin removal](https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?id=b812fc9768e0048582c8e18d7b66559c1758dde1) | feec() 将迁移任务以节省能源, 前提是它至少节省了系统消耗的总能源的 6%. 这种保守的方法对于终端来说是一个问题, 在这个系统中, 许多小任务会在总体上产生巨大的负载: 很少有任务可以迁移到较小的 CPU, 这会浪费大量的能量. 与其试图确定另一个裕度, 不如尝试删除它. | v11 ☐☑✓ | [LORE v11,0/7](https://lore.kernel.org/all/20220621090414.433602-1-vdonnefort@google.com) |
| 2023/12/08 | Qais Yousef | [sched: cpufreq: Remove magic hardcoded numbers from margins](https://lore.kernel.org/all/20231208002342.367117-1-qyousef@layalina.io) | TODO | v2 ☐☑✓ | [LORE v1,0/7](https://lore.kernel.org/all/20230827233203.1315953-1-qyousef@layalina.io)
*-*-*-*-*-*-*-*
[LORE v2,0/8](https://lore.kernel.org/all/20231208002342.367117-1-qyousef@layalina.io) |
+| 2024/02/05 | Qais Yousef | [sched/fair: Remove hardcoded fits_capacity() margin](https://lore.kernel.org/all/20240205223344.2280519-1-qyousef@layalina.io) | 从 [LORE v2,0/8](https://lore.kernel.org/all/20231208002342.367117-1-qyousef@layalina.io) 中分离出来的一部分. 本系列仅关注 migration margin 和 fits_capacity(). 之前没有考虑不变性, 现在解决了这个问题. 补丁 1 和 2 添加了助手函数 approximate_util_avg() 和 approximate_runtime(), 用于在 time 和 util 之间进行转换. 补丁 3 的 COMMIT 详细介绍了补丁的思路. | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20240205223344.2280519-1-qyousef@layalina.io) |
#### 7.2.3.4 feec improvement
-------
@@ -4500,6 +4533,8 @@ EAS 原生的 overutilized 机制非常保守, 一旦发现某个 CPU 出现了
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2021/05/04 | Thara Gopinath | [ANDROID: sched: Per-Sched-domain over utilization](https://github.com/aosp-mirror/kernel_common/commit/addef37808728c719d8c095a75bcf81befdacdaf) | per sched-domain 级别的 utilization. | v3 ☐☑✓ | [LORE](https://github.com/aosp-mirror/kernel_common/commit/addef37808728c719d8c095a75bcf81befdacdaf) |
+| 2024/03/07 | Shrikanth Hegde | [sched/fair: Limit access to overutilized](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log?id=4d0a63e5b841c759c9a306aff158420421ef016f) | 当在大型系统 (240 核心, SMT8) 上运行 ISV 工作负载时, 从性能配置文件中可以观察到, newidle_balance 和 enque_task_fair 正在消耗更多的周期. 通过 perf 热点分析, 大部分时间都花在了访问 root domain 的 rd->overutilized 字段上. 通过对 `stress-ng --wait` 进行一些更改, 模拟了类似的 perf 配置文件. newidle_balance 和 enqueue_task_fair 的消耗都接近 5-7%. EAS(能量感知调度器)引入 overutilized 机制是为了决策是否进行负载平衡. rd->overutilized 同时被多个 CPU 访问会导致缓存失效. 非 EAS 平台不需要更新 rd->overutilized. 另外由于 rd->overutilized 和 rd->overload 在同一 Cache Line, 因此也存在伪共享的可能. 补丁 1 [sched/fair: Add EAS checks before updating overutilized](https://lore.kernel.org/all/20240307085725.444486-2-sshegde@linux.ibm.com) 这有助于减少上述问题. 带上这个补丁后, ISV 工作负载中的问题也得到了解决, 吞吐量也得到了提高. 补丁 2 和 3 代码重构, 使用 helper 函数 is_rd_overutilized() , 而不再直接访问 rd->overutilized 字段. 因为观察到的大多数模式都是 eas && !overutilzed. | v6 ☐☑✓ v6.10-rc1 | [LORE](https://lore.kernel.org/all/20240326152616.380999-1-sshegde@linux.ibm.com)
*-*-*-*-*-*-*-*
[LORE v6,0/3](https://lore.kernel.org/all/20240307085725.444486-1-sshegde@linux.ibm.com) |
+| 2024/03/25 | Shrikanth Hegde | [sched: Minor changes for rd->overload access](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log?id=4d0a63e5b841c759c9a306aff158420421ef016f) | 当在大型系统中运行工作负载时, 可以观察到对 rd->overload 的访问需要时间.
1. 补丁 1, 更新之前最好检查一下值, 因为值更改的频率较低.
补丁 2, 只有在必要时才会进行修补程序更新. CPU 总线流量有所减少. 工作负载性能没有显著提高. Qais 建议最好使用 helper 函数来访问 rd->overload. | v3 ☐☑✓ v6.10-rc1 | [LORE v3,0/2](https://lore.kernel.org/all/20240325054505.201995-1-sshegde@linux.ibm.com) |
* sched group energy
@@ -4798,8 +4833,6 @@ Misfit Task 对调度器 ** 负载均衡 ** 做了如下改造, 参见 [commit c
| 2023/02/01 | Vincent Guittot | [unlink misfit task from cpu overutilized](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log?id=a2e90611b9f425adbbfcdaa5b5e49958ddf6f61b) | uclamp_min 造成的任务 misfit 并不意味着 cpu overutilized, 因为这仅仅是 uclamp_min 的约束, 具有小 util_avg 的任务可能不适合所在高 capacity 的 cpu. 允许 `task_fits_cpu()/asym_fits_cpu()/cpu_overutilized() -=> util_filts_cpu()` 返回 -1 来反映 CPU 不适合指定任务只是因为 uclamp_min, 所以我们可以使用这个状态来采取额外的操作, 以选择与 uclamp_min 匹配的最佳 CPU. 当 util_filts_cpu() 返回 -1 时, 不再认为 CPU 是 overutilized 的, 因此 select_idle_capacity() 和 find_energy_efficient_cpu() 将继续寻找一种可能的性能更好的 CPU, 它用 capacity_orig_of() - thermal_load_avg 代替容量反转检测来检测容量反转. | v5 ☐☑✓ | [LORE v5,0/2](https://lore.kernel.org/all/20230201143628.270912-1-vincent.guittot@linaro.org) |
| 2023/12/09 | Qais Yousef | [sched: Generalize misfit load balance](https://lore.kernel.org/all/20231209011759.398021-1-qyousef@layalina.io) | 当前的 misfit 实现被认为是 MISFIT_PERF, 这意味着我们需要将任务移动到更好的 CPU 以满足其性能要求. 对于被 UCLAMP_MAX 所限制的(大)任务, 引入 MISFIT_POWER, 需要找到一个更好的位置来控制它对 POWER 的影响. 并且当我们有了一个 API 来注释延迟敏感任务, 预计将需要 MISFIT_LATENCY 负载均衡来帮助处理超额订阅情况, 以帮助更好地分配延迟敏感任务, 以帮助减少其唤醒延迟. | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20231209011759.398021-1-qyousef@layalina.io) |
-
-
* Misfit vs NO_HZ
[sched/fair: Kick nohz balance if rq->misfit_task_load](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5fbdfae5221a5208ed8e7653fc1c4b31de420f74)
@@ -4812,6 +4845,16 @@ Misfit Task 对调度器 ** 负载均衡 ** 做了如下改造, 参见 [commit c
| 2021/04/07 | Valentin Schneider | [sched/fair: load-balance vs capacity margins](https://lore.kernel.org/all/20210407220628.3798191-1-valentin.schneider@arm.com/) | misfit task load-balance tweaks 的补丁被拆分重构, 这个是 Part 1 | v3 ☐ 5.13-rc1 | [LORE v5,0/3](https://lore.kernel.org/all/20210407220628.3798191-1-valentin.schneider@arm.com) |
| 2021/04/16 | Valentin Schneider | [sched/fair: (The return of) misfit task load-balance tweaks](https://lore.kernel.org/patchwork/cover/1414181) | misfit task load-balance tweaks 的补丁被拆分重构, 这个是 Part 2 | v1 ☐ 5.10-rc4 | [PatchWork](https://lore.kernel.org/patchwork/cover/1414181) |
+
+* Check Affinity
+
+| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:---:|:----:|:---:|:----:|:---------:|:----:|
+| 2023/08/20 | Qais Yousef | [sched/fair: Check a task has a fitting cpu when updating misfit](https://lore.kernel.org/all/20230820203429.568884-1-qyousef@layalina.io) | 如果一个 MISFIT 的任务与 affinity 并不是所有 CPU, 我们需要验证 CPU 是否适合它, 否则, 负载均衡器将不断触发, 导致 balance_interval 不必要地增加, 最终导致真正的不平衡需要很长时间才能解决, 因为这是不可能的不平衡状况. 在 Android 系统上这种现象非常普遍, 因为后台任务通常被限制在小核上. 同样, 如果我们不能适应最大的核心, 那么触发不匹配是毫无意义的, 因为这是我们在这个系统上所能得到的最好的结果. 为了加快搜索速度, 不要调用 task_fits_cpu(), 它会为同一任务重复调用 uclamp_eff_value(), 改为调用 util_filts_cpu(). 只有当我们看到一个 CPU 的 CAPACITY LEVEL 高于通过的 cpu_of(rq) 时, 才能这样做. | v1 ☐☑✓ | [2023/08/20, LORE](https://lore.kernel.org/all/20230820203429.568884-1-qyousef@layalina.io)
*-*-*-*-*-*-*-*
[2023/12/12, LORE v2](https://lore.kernel.org/lkml/20231212154056.626978-1-qyousef@layalina.io) |
+| 2024/03/24 | Qais Yousef | [sched: Don't trigger misfit if affinity is restricted](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=58eeb2d79b542c678c46e245dba6b66936368a99) | 讨论了如何处理热插拔操作, 以消除容量水平并导致不必要的 LB 再次触发. 我选择现在不处理它, 早期版本 [sched/fair: Check a task has a fitting cpu when updating misfit](https://lore.kernel.org/lkml/20230820203429.568884-1-qyousef@layalina.io) 中提供了一个有效的补丁, 但是作者并不像继续推动这种实现. 补丁 4 将确保 balance_interval 和 nr_failed 不会因不必要的 MISFIT 而不必要地进行增长. 6.9 合并窗口后, 动态能量模型系列将被合并, 这可能导致 CPU 的容量在运行时发生变化. 这意味着发布后续补丁来处理这种情况, 以确保在 EM 更新后最大允许容量是正确的. | v8 ☐☑✓ v6.10-rc1 | [2023/12/31, LORE v3,0/2](https://lore.kernel.org/lkml/20231231175218.510721-1-qyousef@layalina.io)
*-*-*-*-*-*-*-*
[2024/01/05, LORE v4,0/2](https://lore.kernel.org/lkml/20240105222014.1025040-1-qyousef@layalina.io)
*-*-*-*-*-*-*-*
[2024/02/05, LORE v5,0/2](https://lore.kernel.org/lkml/20240205021123.2225933-1-qyousef@layalina.io)[2024/02/20, LORE v6,0/4](https://lore.kernel.org/lkml/20240220225622.2626569-1-qyousef@layalina.io)
*-*-*-*-*-*-*-*
[2024/03/24, LORE v8,0/4](https://lore.kernel.org/all/20240324004552.999936-1-qyousef@layalina.io) |
+
+
+
#### 7.2.4.4 Capacity Aware Sched Class
-------
@@ -5022,6 +5065,13 @@ EAS 合入的时候, 使用 map_util_freq() 将 util 按照 schedutil 的调频
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2021/06/14 | Lukasz Luba | [Add allowed CPU capacity knowledge to EAS](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=8f1b971b4750e83e8fbd2f91a9efd4a38ad0ae51) | TODO | v4 ☐☑✓ 5.14-rc1 | [LORE v4,0/3](https://lore.kernel.org/all/20210614185815.15136-1-lukasz.luba@arm.com) |
+尽管如此, 能效模型和 schedutil 之间依旧可能存在不匹配.
+
+| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:---:|:----:|:---:|:----:|:---------:|:----:|
+| 2023/12/11 | Vincent Guittot | [consolidate and cleanup CPU capacity](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=1f023007f5e782bda19ad9104830c404fd622c5d) | 整合调度器中如何使用最大 CAPACITY 以及我们如何计算某一利用率级别的频率的第一部分. 下一步将是在 CPU 的原始最大计算容量和永久应用上限(秒或更长时间)时当前可用的容量之间进行区分. 第一部分修复在计算利用率的频率时出现的一些不公平现象. `cpuinfo.max_freq` 可以在运行时更改, 这意味着该值可能与用于计算 CPU 容量的频率不同, 性能域的最后一项并不总是用于计算 CPU CAPACITY 的频点, 这可能导致目标频率与系统的其他部分(如时间表)不同, 并可能导致错误的能量估计. 新的 `get_capacity_ref_freq() -=> arch_scale_freq_ref()` 可用于返回一个固定且一致的频率参考, 该频率参考可在计算某个利用率级别的 CPU 频率时使用, 使用这个函数得到这个参考频率. | v7 ☐☑✓ v6.8-rc1 | [LORE v7,0/7](https://lore.kernel.org/all/20231211104855.558096-1-vincent.guittot@linaro.org) |
+| 2024/01/08 | Vincent Guittot | [Rework system pressure interface to the scheduler](https://lore.kernel.org/all/20240108134843.429769-1-vincent.guittot@linaro.org) | 整合调度器中如何使用最大 CAPACITY 以及我们如何计算某一利用率级别的频率的第二部分. 在 [consolidate and cleanup CPU capacity](https://lore.kernel.org/all/20231211104855.558096-1-vincent.guittot@linaro.org) 中对 CPU 容量进行了整合和清理之后, 这个补丁集重新研究了调度器如何获取 CPU 的压力. 我们需要考虑 cpufreq 在数十毫秒或更长时间内对 CPU 计算能力施加的所有压力, 而不仅仅是 cpufreq cooling 设备 HW mitigiations 延迟. 我们将施加在 CPU 容量上的压力分为两部分: 1. 一个来自 cpufreq 和 freq_qos, 2. 一个来自 HW 高频抑制.
下一步将添加一个专用接口, 用于长期限制 CPU 容量(即几秒钟或更长时间), 如 cpufreq-sysfs 的 scaling_max_freq. | v3 ☐☑✓ | [LORE v3,0/5](https://lore.kernel.org/all/20240108134843.429769-1-vincent.guittot@linaro.org) |
+
#### 7.2.5.4 Energy Model Management Framework 的改进与优化
-------
@@ -5240,7 +5290,15 @@ CPUFreq 驱动是处理和平台相关的逻辑, Governor 中实现了具体的
小米在邮件列表发布了 [Provide USF for the portable equipment.](https://lore.kernel.org/all/cover.1596612536.git.yangdongdong@xiaomi.com) 在启用 cpufreq 上的调整, 并按计划调整用户敏感系数. 它特别适用于在屏幕上显示更多电源保护和快速响应要求的移动设备.
-### 7.3.5 其他 governor
+
+### 7.3.5 CPU-DDR 联动调频
+-------
+
+| 日期 | 文档 | 描述 |
+|:---:|:---:|:----:|
+| 2023/06/07 | [JOSS: Joint Exploration of CPU-Memory DVFS and Task Scheduling for Energy Efficiency](https://arxiv.org/abs/2306.04615) | 提出了一种 CPU-MEMORY 联合调频的模型和调频策略. |
+
+### 7.3.6 其他 governor
-------
[Google's CPUFreq "Interactive" Governor Looks To Go Mainline](https://www.phoronix.com/news/CPUFreq-Interactive-Governor)
@@ -5530,6 +5588,7 @@ CONFIG_SCHED_CORE_CTL 的方案, 不光通过 do_isolation_work_cpu_stop() 支
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2023/11/07 | Ankur Arora | [Make the kernel preemptible](https://lore.kernel.org/all/20231107215742.363031-1-ankur.a.arora@oracle.com) | [New Set Of 86 Patches Overhaul The Linux Kernel's Preemption Model](https://www.phoronix.com/news/Overhaul-Linux-Preemptible-RFC) | v1 ☐☑✓ | [LORE v1,0/86](https://lore.kernel.org/all/20231107215742.363031-1-ankur.a.arora@oracle.com) |
+| 2024/02/12 | Ankur Arora | [PREEMPT_AUTO: support lazy rescheduling](https://lore.kernel.org/all/20240213055554.1802415-1-ankur.a.arora@oracle.com) | 本系列增加了一个新的调度模型 PREEMPT_AUTO, 它与 PREEMPT_DYNAMIC 一样，允许在无 / 自愿 / 完全抢占模型之间进行动态切换. 然而, 与 PREEMPT_DYNAMIC 不同, 它不依赖于自愿模型的显式抢占点. 该系列基于托马斯在 [1](https://lore.kernel.org/lkml/87cyyfxd4k.ffs@tglx)、[2](https://lore.kernel.org/lkml/87led2wdj0.ffs@tglx) 和他的 [PoC](https://lore.kernel.org/lkml/87jzshhexi.ffs@tglx) 中概述的原始提议. 早期的 RFC 版本位于 [Make the kernel preemptible](https://lore.kernel.org/all/20231107215742.363031-1-ankur.a.arora@oracle.com).
PREEMPT_AUTO 的工作原理是始终启用 CONFIG_PREEMPTION(从而启用 PREEMPT_COUNT). 这意味着调度器总是可以安全地抢占. 这与 CONFIG_PREEMPT 相同. 有了这一点, 下一步是使重新调度策略取决于所选的调度模型. 目前, 调度程序使用一个需要重新调度的位(TIF_NEED_RESCHED) 来声明需要重新调度. PREEMPT_AUTO 通过添加一个额外的需求补救位 TIF_NEED_RESCHED_LAZY. | v1 ☐☑✓ | [LORE v1,0/30](https://lore.kernel.org/all/20240213055554.1802415-1-ankur.a.arora@oracle.com) |
## 8.2 NO_HZ
@@ -5759,6 +5818,10 @@ Linux 内核会将大量 (并且在不断增加中) 工作放置在内核线程
## 8.7 [PREEMPT_RT](https://www.phoronix.com/search/PREEMPT_RT)
-------
+| 编号 | 文档 | 描述 |
+|:---:|:---:|:----:|
+| 1 | [The state of realtime and embedded Linux](https://lwn.net/Articles/970555) | 2024 [Open Source Summit North America](https://events.linuxfoundation.org/open-source-summit-north-america) 关于实时内核的讨论. |
+
标准的 Linux 内核中不可中断的系统调用、中断屏蔽等因素, 都会导致系统在时间上的不可预测性, 对硬实时限制没有保证. 目前, 针对 real-time Linux 的修改有两种成功的方案.
1. 直接修改 Linux 内核, 使其直接具有 real-time 能力; 其中有代表性的就是 PREEMPT-RT kernel.
@@ -6031,7 +6094,7 @@ enqueue_task_fair()
EEVDF 最终在 [v6.6-rc1 合入主线](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3ca9a836ff53db8eb76d559764c07fb3b015886a), EEVDF 取代了现有的 CFS 调度程序代码, 虽然最初可能会出现一些性能回归, 但开发人员将积极地解决这些问题. 参见 [EEVDF Scheduler Merged For Linux 6.6, Intel Hybrid Cluster Scheduling Re-Introduced](https://www.phoronix.com/news/Linux-6.6-EEVDF-Merged) 以及 [CGIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=d07f09a1f99cabbc86bc5c97d962eb8a466106b5).
-EEVDF 全称 "Earliest Eligible Virtual Deadline First" 调度算法, 它并不是什么新事物, 是在 1995 年由 Ion Stoica 和 Hussein Abdel-Wahab 在 1995 年的论文 [Earliest Eligible Virtual Deadline First A Flexible](https://people.eecs.berkeley.edu/~istoica/papers/eevdf-tr-95.pdf) 中描述过. 它的名字就暗示, 它是跟内核的 deadline scheduler 所使用的 Earliest Deadline First algorithm 很类似. 但是这里的差异是, EEVDF 不是一个 realtime 时调度程序, 所以工作方式不一样. 理解 EEVDF 需要掌握几个 (相对) 简单的概念.
+EEVDF 全称 "Earliest Eligible Virtual Deadline First" 调度算法, 它并不是什么新事物, 是在 1995 年由 Ion Stoica 和 Hussein Abdel-Wahab 在 1995 年的论文 [Earliest Eligible Virtual Deadline First A Flexible](https://people.eecs.berkeley.edu/~istoica/papers/eevdf-tr-95.pdf),[Earliest Eligible Virtual Deadline First : A Flexible and Accurate Mechanism for Proportional Share Resource Allocation, November 1995](https://dl.acm.org/doi/10.5555/890606) 中描述过. 它的名字就暗示, 它是跟内核的 deadline scheduler 所使用的 Earliest Deadline First algorithm 很类似. 但是这里的差异是, EEVDF 不是一个 realtime 时调度程序, 所以工作方式不一样. 理解 EEVDF 需要掌握几个 (相对) 简单的概念.
EEVDF 跟 CFS 一样, EEVDF 追求在任务之间公平使用 CPU 时间. 试图把可用的 CPU 时间公平地分配给正在争夺它的那些进程. 例如, 如果有五个进程试图在一个 CPU 上运行, 那么每个进程应该得到 20% 的可用时间. 每个进程的 nice 值可以用来调整其公平时间的计算结果, nice 值较低 (因此优先级较高) 的进程有权获得更多的 CPU 时间, 而牺牲那些具有较高 nice 值的进程. 这些内容都是以前就有的概念.
@@ -6053,13 +6116,24 @@ EEVDF 调度器希望平滑而自然地处理延迟关键型任务. 延迟关键
EEVDF 的核心理念就可以从它的名字中看出, 它将首先运行那些具有最早的 virtual deadline 的进程. 因此, 调度选择是结合了 fairness(用于计算合格时间的 lag 值) 以及每个进程当前有用的时间值来共同决定的.
+
+
+| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
+|:-----:|:----:|:----:|:----:|:------------:|:----:|
+| 2009/09/16 | Ingo Molnar | [sched: Implement a gentler fair-sleepers feature](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=51e0304ce6e55a6e59658558916b4f74da085ff0) | 引入 GENTLE_FAIR_SLEEPERS sched_feature 只给睡眠的线程 50% 的 vruntime 补偿优待, 这使它们能够更快地奔跑, 但不会让他们窃取过多的补偿. | v1 ☐☑✓ | [LORE](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=51e0304ce6e55a6e59658558916b4f74da085ff0) |
+| 2023/04/01 | Xi Wang | [Morphing CFS into FDL, The Fair Deadline Scheduling Class](https://lore.kernel.org/all/20230401230556.2781604-1-xii@google.com) | TODO | v1 ☐☑✓ | [LORE v1,0/1](https://lore.kernel.org/all/20230401230556.2781604-1-xii@google.com) |
+| 2023/03/28 | Peter Zijlstra | [sched: EEVDF using latency-nice](https://lore.kernel.org/all/20230328092622.062917921@infradead.org) | [EEVDF Scheduler Patches Updated For The Linux Kernel](https://www.phoronix.com/news/Linux-EEVDF-EO-March) | v1 ☐☑✓ | [LORE 00/10](https://lore.kernel.org/all/20230306132521.968182689@infradead.org)
*-*-*-*-*-*-*-*
[LORE v1,0/17](https://lore.kernel.org/all/20230328092622.062917921@infradead.org) |
+| 2023/07/19 | Peter Zijlstra | [sched: EEVDF and latency-nice and/or slice-attr](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=b41bbb33cf75d251a816768580819aec17be718d) | [Updated EEVDF Linux CPU Scheduler Patches Posted That Plan To Replace CFS](https://www.phoronix.com/news/EEVDF-Scheduler-Linux-EO-May) 以及 [EEVDF Scheduler May Be Ready For Landing With Linux 6.6](https://www.phoronix.com/news/Linux-6.6-EEVDF-Likely), [EEVDF Scheduler Merged For Linux 6.6, Intel Hybrid Cluster Scheduling Re-Introduced](https://www.phoronix.com/news/Linux-6.6-EEVDF-Merged) | v1 ☐☑✓ 6.6-rc1 | [LORE v1,0/15](https://lore.kernel.org/all/20230531115839.089944915@infradead.org), [CGIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=d07f09a1f99cabbc86bc5c97d962eb8a466106b5) |
+
+
#### 8.9.2.2 公式推导与实现
-------
系统中所有进程的滞后值 lag 的和为 0;
-$\sum \limits_{0}^{n}lag_{i} = \sum \limits_{0}^{n}w_{i} \times (V - v_{i}) = 0$
+$\sum \limits_{0}^{n}lag_{i} = \sum \limits_{0}^{n}S - s_i = \sum \limits_{0}^{n}w_{i} \times (V - v_{i}) = 0$
+[Completing the EEVDF scheduler](https://lwn.net/Articles/969062) 中举了一个例子讲述了进程滞后值 lag 的计算;
##### 8.9.2.2.1 V 与 cfs_rq 的 avg_vruntime
-------
@@ -6084,7 +6158,6 @@ V = \frac{\sum \limits_{0}^{n}w_{i} \times (v_{i} - v_{0})}{W} + v_{0} = \frac{a
接下来就是如何把这些值算出来:
-
| cfs_rq | 描述 | 更新时机 | 用途 | 公式 |
|:------:|:----:|:-------:|:---:|:---:|
| avg_vruntime | 用于计算加权平均 vruntime 的中间变量, `\Sum (v_i - v0) * w_i`, cfs_rq 上所有任务 (调度实体) 的累积带 load.weight 加权的 vruntime 相距 min_vruntime 的偏差和. | 1. 每次进程出入队的时候, 会对 cfs_rq 的 avg_vruntime, avg_slice, avg_load 进行更新. 参见 avg_vruntime_add() 和 avg_vruntime_sub().
2. 由于 avg_vruntime 的计算依赖于 cfs->min_vruntime, 因此每次 update_min_vruntime() 都会通过 avg_vruntime_update(), 对 cfs_rq->avg_vruntime 进行校准. | 1. avg_vruntime() 中使用 cfs_rq->avg_vruntime 来计算归一化的 avg_vruntime.
2. entity_eligible() 中通过判断 cfs_rq->vruntime 或者归一化 avg_runtime 来判断进程是否是 eligible.
3. place_entity() 中使用归一化 avg_vruntime 来更新进程的 vlag 以及 dealine.
4. update_entity_lag() 中使用归一化 avg_vruntime 来更新进程的 vlag. | $$avg\_vruntime_{cfs\_rq} = \sum \limits_{i = 0}^{N} (vruntime_{se} - min\_vruntime_{cfs\_rq}) \times load\_weight$$ |
@@ -6140,7 +6213,12 @@ $V = \frac{\sum \limits_{0}^{n}w_{i} \times v_{i}}{\sum \limits_{0}^{n}w_{i}} =
$lag_i = S - s_i = w_i \times (V - v_i) = w_i \times [\frac{\sum \limits_{0}^{n}w_{i} \times (v_{i} - v_{0})}{W} + v_{0} - v_i] = load\_weight_i \times (avg\_vruntime - vruntime_{se})$
-由于 `se->vlag` 是用了 load.weight 以及 avg_load 做了归一的, 因此 reweight_entity 的时候, 需要同步更新 se->vlag 和 se->deadline. 此时如果 se 不是就绪的 (!se->on_rq), 那么仅仅更新 se->vlag 即可, 因为进程后续 enqueue_entity() -=> place_entity(). 否则则不更新 se->vlag, 而是直接更新 se->deadline.
+那么记录 vlag 为进程不带加权的 lag 滞后值, 具体计算参见 [update_entity_lag()](https://elixir.bootlin.com/linux/v6.6/source/kernel/sched/fair.c#L715)
+
+$vlag_i = \frac{S - s_i}{w_i} = V - v_i = \frac{\sum \limits_{0}^{n}w_{i} \times (v_{i} - v_{0})}{W} + v_{0} - v_i = avg\_vruntime - vruntime_{se}) = \frac{avg\_vruntime_{cfs\_rq}}{avg\_load_{cfs\_rq}} + min\_vruntime_{cfs\_rq} - vruntime_{se}$
+
+
+可见 `se->vlag` 是用了 load.weight 以及 avg_load 做了归一的, 因此 reweight_entity 的时候, 需要同步更新 se->vlag 和 se->deadline. 此时如果 se 不是就绪的 (!se->on_rq), 那么仅仅更新 se->vlag 即可, 因为进程后续 enqueue_entity() -=> place_entity(). 否则则不更新 se->vlag, 而是直接更新 se->deadline.
* 判断一个任务是不是 eligible
@@ -6159,21 +6237,69 @@ $lag_i = S - s_i = w_i \times (V - v_i) = w_i \times [\frac{\sum \limits_{0}^{n}
$lag_i = w_i \times [\frac{\sum \limits_{0}^{n}w_{i} \times (v_{i} - v_{0})}{W} - (v_{i} - v_0)] > 0 \Rightarrow \frac{\sum \limits_{0}^{n}w_{i} \times (v_{i} - v_{0})}{W} - (v_{i} - v_0) > 0 \Rightarrow \frac{\sum \limits_{0}^{n}w_{i} \times (v_{i} - v_{0})}{W} > (v_{i} - v_0) \Rightarrow \sum \limits_{0}^{n}w_{i} \times (v_{i} - v_{0}) > W \times (v_{i} - v_0) \Rightarrow avg\_vruntime_{cfs\_rq} > avg\_load_{cfs\_rq} \times (vruntime_{se} - min\_vruntime_{cfs\_rq})$
-* 如何结合 latency_nice
-latency_nice 影响的就是 `se->slice`
+* 计算 deadline
+
+关于 EEVDF 的截止时间, 类似于实时调度里的概念, 就是最晚获得所有请求资源的时间点, 假设已知调度周期 T, 最大服务时间 r, 就是要求每个周期内都能拥有 r 的服务时间长度, 因此资源份额为 f = \frac{r}{T}, 反过来, 已知请求创建的时间点 t, 其请求长度为 r, 截止时间则就是 $t + \frac{r}{T}$. 即 $vd_i = ve_i + r_i / w_i$.
+
+那么实际时间的时候, 参见 [update_deadline()](https://elixir.bootlin.com/linux/v6.6/source/kernel/sched/fair.c#L1034).
+
+$deadline_{se} = vruntime_{se} + slice \times \frac{weight_0}{weight_{se}}$
+
+
+
+### 8.9.3 EEVDF 如何 PICK 任务
+-------
+
+[commit 147f3efaa241 ("sched/fair: Implement an EEVDF-like scheduling policy")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=147f3efaa24182a21706bca15eab2f3f4630b5fe)
+
+[commit 650cad561cce ("sched/eevdf: Also update slice on placement")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=650cad561cce04b62a8c8e0446b685ef171bc3bb)
+
+
+
+### 8.9.4 EEVDF 如何处理睡眠唤醒的任务
+-------
+
+
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:-----:|:----:|:----:|:----:|:------------:|:----:|
-| 2009/09/16 | Ingo Molnar | [sched: Implement a gentler fair-sleepers feature](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=51e0304ce6e55a6e59658558916b4f74da085ff0) | 引入 GENTLE_FAIR_SLEEPERS sched_feature 只给睡眠的线程 50% 的 vruntime 补偿优待, 这使它们能够更快地奔跑, 但不会让他们窃取过多的补偿. | v1 ☐☑✓ | [LORE](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=51e0304ce6e55a6e59658558916b4f74da085ff0) |
-| 2023/04/01 | Xi Wang | [Morphing CFS into FDL, The Fair Deadline Scheduling Class](https://lore.kernel.org/all/20230401230556.2781604-1-xii@google.com) | TODO | v1 ☐☑✓ | [LORE v1,0/1](https://lore.kernel.org/all/20230401230556.2781604-1-xii@google.com) |
-| 2023/03/28 | Peter Zijlstra | [sched: EEVDF using latency-nice](https://lore.kernel.org/all/20230328092622.062917921@infradead.org) | [EEVDF Scheduler Patches Updated For The Linux Kernel](https://www.phoronix.com/news/Linux-EEVDF-EO-March) | v1 ☐☑✓ | [LORE 00/10](https://lore.kernel.org/all/20230306132521.968182689@infradead.org)
*-*-*-*-*-*-*-*
[LORE v1,0/17](https://lore.kernel.org/all/20230328092622.062917921@infradead.org) |
-| 2023/07/19 | Peter Zijlstra | [sched: EEVDF and latency-nice and/or slice-attr](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=b41bbb33cf75d251a816768580819aec17be718d) | [Updated EEVDF Linux CPU Scheduler Patches Posted That Plan To Replace CFS](https://www.phoronix.com/news/EEVDF-Scheduler-Linux-EO-May) 以及 [EEVDF Scheduler May Be Ready For Landing With Linux 6.6](https://www.phoronix.com/news/Linux-6.6-EEVDF-Likely), [EEVDF Scheduler Merged For Linux 6.6, Intel Hybrid Cluster Scheduling Re-Introduced](https://www.phoronix.com/news/Linux-6.6-EEVDF-Merged) | v1 ☐☑✓ 6.6-rc1 | [LORE v1,0/15](https://lore.kernel.org/all/20230531115839.089944915@infradead.org), [CGIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=d07f09a1f99cabbc86bc5c97d962eb8a466106b5) |
| 2023/10/23 | Daniel Jordan | [sched/fair: Preserve PLACE_DEADLINE_INITIAL deadline](https://lore.kernel.org/all/20231023154319.102437-1-daniel.m.jordan@oracle.com) | TODO | v3 ☐☑✓ | [LORE](https://lore.kernel.org/all/20231023154319.102437-1-daniel.m.jordan@oracle.com) |
| 2023/09/15 | peterz@infradead.org | [sched/eevdf: sched_attr::sched_runtime slice hint](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=650cad561cce04b62a8c8e0446b685ef171bc3bb) | TODO | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20230915124354.416936110@noisy.programming.kicks-ass.net) |
| 2023/11/04 | Yiwei Lin | [sched/fair: Track current se's EEVDF parameters](https://lore.kernel.org/all/20231104090054.124945-1-s921975628@gmail.com) | TODO | v4 ☐☑✓ | [LORE v4,0/1](https://lore.kernel.org/all/20231104090054.124945-1-s921975628@gmail.com) |
+| 2023/09/19 | Ingo Molnar | [sched/fair: Do not wakeup-preempt same-prio SCHED_OTHER tasks](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=147f3efaa24182a21706bca15eab2f3f4630b5fe) | Mike 和其他人注意到, EEVDF 确实喜欢过多地安排时间--这确实会造成[许多基准测试/工作负载的性能](https://lore.kernel.org/all/202308101628.7af4631a-oliver.sang@intel.com) 的劣化. 特别是, 似乎导致过度调度的原因是, 当滞后 lag 与请求/切片的顺序相同(或更大)时, 放置不仅会导致任务被放置在当前任务的左边, 而且最后期限比当前任务小, 这会导致立即先发制人, 从另外一个角度上讲, 就是这些任务被过多的安排了时间片. Mike 建议, 只要它有资格运行, 我们就坚持选择 "current", 让它不间断地运行, 直到它与包持平. 引入 sched_feature RUN_TO_PARITY 的实现, 标记 current 的任务的 `curr->vlag = curr->deadline`, 只允许它用尽最初的请求来增强. | v1 ☐☑✓ 6.6-rc1 | [LORE](https://lore.kernel.org/all/ZQljoiSBhZLEFI/G@gmail.com) |
| 2023/11/07 | Abel Wu | [sched/eevdf: Optimize reweight and pick](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=ee4373dc902c0a403dd084b254ce70a78f95466f) | 1. 解决了重新加权时vruntime无法调整的问题 !0-tag 滞点.
2. 按照虚拟截止日期对任务时间线进行排序, 并将 min_vruntime 保留在增强树中, 这样实现了一种基于最后期限排序的最左侧缓存红黑树( deadline-sorted leftmost-cached rbtree). 通过在 best_left 上进行回退搜索, 可以避免在最坏的情况下会使成本翻倍的问题.
3. 充分利用缓存的最左边节点, 可以达成 O(1) 复杂度的 PICK TASK.
4. 最后一个补丁是 EEVDF 的统计维测补丁, 不用于 UPSTREAM. | v1 ☐☑✓ v6.8-rc1 | [LORE v1,0/4](https://lore.kernel.org/all/20231107090510.71322-1-wuyun.abel@bytedance.com) |
| 2024/04/05 | Peter Zijlstra | [sched/fair: Complete EEVDF](https://lore.kernel.org/all/20240405102754.435410987@infradead.org) | [New EEVDF Linux Scheduler Patches Make It Functionally "Complete"](https://www.phoronix.com/news/Linux-Completing-EEVDF-Sched) 以及 [Completing the EEVDF scheduler](https://lwn.net/Articles/969062). | v1 ☐☑✓ | [LORE v1,0/10](https://lore.kernel.org/all/20240405102754.435410987@infradead.org) |
+| 2024/01/11 | Ze Gao | [sched/eevdf: Use tunable knob sysctl_sched_base_slice as explicit time quanta](https://lore.kernel.org/all/20240111115745.62813-2-zegao@tencent.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240111115745.62813-2-zegao@tencent.com) |
+| 2023/09/05 | Mathieu Desnoyers | [sched/eevdf: Rate limit task migration](https://lore.kernel.org/all/20230905171105.1005672-1-mathieu.desnoyers@efficios.com) | 实现任务迁移速率限制, 以加快触发频繁迁移的工作负载模式, 如 hackbbench. 第一个补丁 [sched: Rate limit migrations to 1 per 2ms per task](https://lore.kernel.org/lkml/20230905171105.1005672-2-mathieu.desnoyers@efficios.com) 实现了一个简单的速率限制, 即每 2ms 迁移一次. 第二个补丁 [sched: Implement adaptative rate limiting of task migrations](https://lore.kernel.org/lkml/20230905171105.1005672-3-mathieu.desnoyers@efficios.com) 实现了自适应任务迁移速率限制. | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20230905171105.1005672-1-mathieu.desnoyers@efficios.com) |
+| 2024/02/28 | Tobias Huschle | [sched/eevdf: avoid task starvation in cgroups](https://lore.kernel.org/all/20240228161023.14310-1-huschle@linux.ibm.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240228161023.14310-1-huschle@linux.ibm.com) |
+
+
+滞后计算仅与可运行的任务相关; 休眠很久的任务实际上并没有错过它的虚拟运行时间(因为它没有), 所以它不会累积巨大的滞后值. 但是, EEVDF 调度器实现的时候, 在任务进入睡眠状态时会保留任务的当前滞后值, 并在任务唤醒时从该值开始. 因此, 如果一个任务在它进入睡眠状态之前已经超出了它的分配范围, 那么当它醒来时, 它将为此付出代价.
+
+但是, 确实存在一点, 保留任务的滞后可能没有意义. 一个睡眠了一天的任务真的应该因为昨天被允许超出其分配而受到惩罚吗? 很明显, 任务的滞后迟早会恢复为零. 但何时应该发生这种情况尚不完全清楚. 正如 Peter Zijlstra 在[补丁中](https://lwn.net/ml/linux-kernel/20240405110010.631664251@infradead.org) 指出的那样, 在睡眠时立即忘记延迟将使任务有可能通过在时间片结束时短暂睡眠来玩弄系统(当它们的延迟可能为负数时), 结果他们获得的 CPU 时间超过了他们的份额. 他总结说, 简单地随着时间的推移衰减滞后值也不会奏效, 因为滞后与虚拟运行时有关, 虚拟运行时以不同(且变化)的速率传递.
+
+> Extend / fix 86bfbb7ce4f6 ("sched/fair: Add lag based placement") by noting that lag is fundamentally a temporal measure. It should not be carried around indefinitely.
+>
+> 滞后基本上是一种时间度量. 它不应该无限期地传播下去.
+
+
+解决方案是减少睡眠任务在虚拟运行时上的滞后. 这个想法在 [sched/fair: Complete EEVDF](https://lore.kernel.org/all/20240405102754.435410987@infradead.org) 中的实现有点有趣. 在之前的实现中, 当任务处于休眠状态时, 通常会将其从运行队列中删除, 以便调度程序无需考虑它. [[RFC][PATCH 08/10] sched/fair: Implement delayed dequeue](https://lore.kernel.org/all/20240405110010.631664251@infradead.org) 实现时, 进入睡眠状态的不合格进程将保留在队列中, 但标记为 "延迟取消排队". 由于它不符合条件, 因此不会选择执行, 但其延迟会根据通过的虚拟运行时间而增加. 一旦延迟变为正值, 调度程序将注意到该任务并将其从运行队列中删除.
+
+这种实现的结果是, 短暂休眠的任务将无法无限制的传播其负滞后值, 但长时间休眠的任务最终将免除其滞后债务. 有趣的是, 正滞后值会无限期保留, 直到任务再次运行.
+
+
+### 8.9.5 如何结合 latency_nice
+-------
+
+latency_nice 影响的就是 `se->slice`.
+
+EEVDF 的基础实现中, 具有较短时间片的任务将具有更早的虚拟截止日期, 从而导致调度程序更快地选择它们. 但是, 在当前内核中, 该隐式优先级仅在调度程序查找要运行的新任务时生效. 如果具有短时间片的延迟敏感型任务被唤醒, 它可能仍必须等待当前任务耗尽其时间片(可能很长)才能运行. Peter Zijlstra 的补丁 [[RFC][PATCH 09/10] sched/eevdf: Allow shorter slices to wakeup-preempt](https://lore.kernel.org/all/20240405110010.788110341@infradead.org) 改变了这一点,引入 SCHED_FEAT(PREEMPT_SHORT) 允许一个任务抢占另一个任务, 如果它的虚拟截止日期更早. 此更改为短时间切片的任务提供了更一致的时间, 同时可能会略微减慢长时间运行的任务.
+
+然而, 这留下了一个悬而未决的问题: 如何指定一个给定的任务应该被赋予一个短的时间片? 在当前的内核中, 非实时进程无法告诉内核其时间片应该是什么, 因此补丁 [[RFC][PATCH 10/10] sched/eevdf: Use sched_attr::sched_runtime to set request/slice suggestion](https://lore.kernel.org/all/20240405110010.934104715@infradead.org) 增加了该功能. 具体来说, 任务可以使用 sched_setattr() 系统调用, 在 sched_attr 结构 sched_runtime 字段中传递所需的切片时间(以纳秒为单位). 在当前内核中, 此字段仅用于截止时间调度. 通过此功能, 任何任务都可以请求更短的时间片, 这将导致它更快地运行, 并且可能更频繁地运行. 但是, 如果请求的时间片太短, 则任务将发现自己经常被抢占, 并且总体运行速度会变慢.
+时间片的允许范围为 100μs 到 100ms. 出于好奇, Peter Zijlstra 在此补丁的更新日志中以一组令人印象深刻的 ASCII 艺术图的形式说明了各种时间片选择的结果.
+
+
@@ -6574,7 +6700,7 @@ CFS 调度器为用户和开发人员提供了非常多的调试接口和参数
BPF 钩子 (它已经成功地用于各种内核子系统) 为外部代码 (安全地) 更改一些内核决策提供了一种方法, BPF 工具使这变得非常容易, 部署 BPF 脚本的开发者已经非常习惯于为新的内核版本更新它们.
-#### 11.2.2.1 Facebook 的尝试
+#### 11.2.2.1 sched_ext: Facebook 的尝试
-------
[当 BPF 邂逅 CPU 调度器](https://www.ebpf.top/post/cfs_scheduler_bpf)
@@ -6595,11 +6721,13 @@ Roman Gushchin 在邮件列表发起了 BPF 对调度器的潜在应用的讨论
Changwoo Min 和 Igalia 昨天在北美开源峰会上发表了关于为 Linux 游戏优化内核调度器的演讲, [Optimizing Scheduler for Linux Gaming - Changwoo Min, Igalia](https://ossna2024.sched.com/event/1aBOT/optimizing-scheduler-for-linux-gaming-changwoo-min-igalia?iframe=no&w=100%&sidebar=yes&bg=no), 提出延迟关键感知虚拟截止时间(LAVD) 调度器. 这个[使用 Rust 基于 sched_ext 编写](https://crates.io/crates/scx_lavd/versions)的基于截止日期的调度器已经显示出可喜的结果. 在 Igalia 在基于 Linux 6.9-rc1的内核上进行的测试中，LAVD调度器在平均FPS和1%的低帧速率下都显示出与EEVDF更好或相似的性能. 参见 phoronix 报道 [Rust-Written LAVD Kernel Scheduler Shows Promising Results For Linux Gaming](https://www.phoronix.com/news/LAVD-Scheduler-Linux-Gaming).
+随后作者发布了 sched_ext 的 v6 版本 [Another push for sched_ext](https://lwn.net/Articles/972710), BPF 的工具集 `sched_ext/ravg[_impl].BPF.h` 和 `ravg.read.rs.h` 中的运行平均实现来跟踪负载度量. 以前, 用户空间部分迭代所有任务来计算负载度量并做出 LB 决策. 现在, 高级 LB 决策是通过简单地读取每个域的负载平均值来做出的, 而 Picking 迁移目标任务只访问推送域中固定数量的最近活动任务的负载度量. 这大大减少了 CPU 开销, 并使 rust 的可扩展性大大提高.
+
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 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) |
+| 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) |
#### 11.2.2.2 Google 的 ghOSt
@@ -6626,17 +6754,25 @@ Changwoo Min 和 Igalia 昨天在北美开源峰会上发表了关于为 Linux
William Lee Irwin III 最早提出了调度器模块化框架, 支持启动时配置 CPU 调度器.
-
随后 CK(Con Kolivas) 在 2004 年 基于这个想法实现了 Pluggable CPU Scheduler Framework. 其最终版本停留在 [plugsched-6.5.1](https://sourceforge.net/projects/cpuse/files/PlugSched/v-6.5), 支持 Linux v2.6.22.
-[pluggable I/O schedulers, pluggable CPU schedulers](https://lwn.net/Articles/242894)
+[2004/11/03, LWN, Schedulers, pluggable and realtime](https://lwn.net/Articles/109458)
+
+[2007/07/25, LWN, pluggable I/O schedulers, pluggable CPU schedulers](https://lwn.net/Articles/242894)
+
+[2009/09/10, LWN, pluggable schedulers vs. tunable schedulers](https://lwn.net/Articles/351882)
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
-| 2022/09/10 | K Prateek Nayak | [Pluggable cpu scheduler framework](https://lore.kernel.org/all/4183A602.7090403@kolivas.org) | TODO | v1 ☐☑✓ | [LORE v1,00/28](https://lore.kernel.org/all/4183A602.7090403@kolivas.org) |
+| 2004/10/31 | Con Kolivas | [Pluggable cpu scheduler framework](https://lore.kernel.org/all/4183A602.7090403@kolivas.org) | TODO | v1 ☐☑✓ | [LORE v1,00/28](https://lore.kernel.org/all/4183A602.7090403@kolivas.org) |
-#### 11.2.3.2 Runtime CPU scheduler customization framework
+#### 11.2.3.2 dynsched: scheduler switch at runtime
+-------
+
+[dynsched](https://sourceforge.net/projects/dynsched) 项目的目标是在运行时切换 CPU 调度程序, 它基于 Peter Williams 的 [plugsched](http://cpuse.sourceforge.net). 通过控制 procfs 节点 `/proc/dynsched` 来完成不同调度器之间切换, 当前支持以下调度程序实现: ingosched, nicksched, staircase, 暂不支持基于 spa 的调度器(如 spa_no_folds、zaphod 等), 我希望它们能很快完成, 就像 SMP 的支持一样. dynsched 项目是作者在康 Konstanz 计算机科学研究的一部分. 参见 [scheduler switch at runtime](https://lore.kernel.org/all/1141335697.4419.15.camel@linux.site) 和 [dynsched - different cpu schedulers per cpuset](https://lwn.net/Articles/211141)
+
+#### 11.2.3.3 Runtime CPU scheduler customization framework
-------
接着在 2009 年, IEEE Student Conference on Research and Development (SCOReD) 上发表的一篇 [Runtime CPU scheduler customization framework for a flexible mobile operating system](https://ieeexplore.ieee.org/document/5443304) 介绍了基于 Linux 内核的运行时 CPU 调度程序自定义 (RCSC) 框架, 该框架考虑了不同的应用程序要求, RCSC 框架允许开发人员自定义 CPU 调度程序以使用特定的调度策略运行, 并在运行时从用户空间评估新开发的调度策略. 因此, 可以手动或自动调整移动操作系统, 以适应特定应用程序的要求. 可同步参考作者 2010 年的毕业论文 [Runtime pluggable CPU scheduler for linux operating system](http://myto.upm.edu.my/find/Record/my-upm-ir.40934/Description#tabnav).
@@ -6653,7 +6789,9 @@ LPC-2016 的议题 [Patching of scheduler functions](http://blog.linuxplumbersco
#### 11.2.4.2 PlugSched
-------
-[Plugsched](https://gitee.com/anolis/plugsched) 是 OpenAnolos Linux 内核调度器子系统热升级的 SDK, 它可以实现在不重启系统、应用的情况下动态替换调度器子系统, 毫秒级 downtime. Plugsched 可以对生产环境中的内核调度特性动态地进行增、删、改, 以满足不同场景或应用的需求, 且支持回滚. 参见
+[Plugsched](https://gitee.com/anolis/plugsched) 是 OpenAnolos Linux 内核调度器子系统热升级的 SDK, 它可以实现在不重启系统、应用的情况下动态替换调度器子系统, 毫秒级 downtime. Plugsched 可以对生产环境中的内核调度特性动态地进行增、删、改, 以满足不同场景或应用的需求, 且支持回滚.
+
+阿里云基础软件/达摩操作系统实验室的论文发表的该项技术的论文 [Efficient Scheduler Live Update for Linux Kernel with Modularization](https://dl.acm.org/doi/10.1145/3582016.3582054) 被系统领域著名会议 28th Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS'23) 录用为长论文 (Full Paper).
[龙蜥开源 Plugsched: 首次实现 Linux kernel 调度器热升级 | 龙蜥技术](https://openanolis.cn/blog/detail/532955762604705772).
@@ -6661,6 +6799,7 @@ LPC-2016 的议题 [Patching of scheduler functions](http://blog.linuxplumbersco
B 站 Plugsched 介绍视频 [纯干货解读：Plugsched, 首次实现 Linux kernel 调度器热升级 | 龙蜥大讲堂 18 期](https://www.bilibili.com/video/BV1cW4y1y76c).
+YouTuBe 上 ASPLOS'23 关于 Plugsched 的介绍 [ASPLOS'23 - Session 7C - Efficient Scheduler Live Update for Linux Kernel with Modularization](https://www.youtube.com/watch?v=IiA4S6VUdzU).
基于 Plugsched 实现的调度器热升级, 不修改现有内核代码, 就能获得较好的可修改能力, 天然支持线上的老内核版本. 如果提前在内核调度器代码的关键数据结构中加入 Reserve 字段, 可以额外获得修改数据结构的能力, 进一步提升可修改能力.
@@ -6755,6 +6894,7 @@ B 站 Plugsched 介绍视频 [纯干货解读：Plugsched, 首次实现 Linux ke
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2020/02/07 | 王贇 | [sched/numa: introduce numa locality](https://lore.kernel.org/patchwork/cover/1190383) | per-cgroup 的 NUMASTAT 功能 | [PatchWork v8](https://lore.kernel.org/patchwork/cover/1190383) |
| 2021/09/05 | Yafang Shao | [sched: support schedstats for RT sched class](https://lore.kernel.org/patchwork/cover/1403138) | 我们希望使用 schedstats 工具测量生产环境中 RT 任务的延迟, 但目前只支持公平调度类的 schedstats. 将 sched_statistics 修改为独立于 task_struct 或 task_group 的调度统计数据, 从而完成了 RT 的 schedstats 支持 | v6 ☑ 5.16-rc1 | [PatchWork v2](https://lore.kernel.org/patchwork/cover/1403138)
*-*-*-*-*-*-*-*
[PatchWork v3](http://patches.linaro.org/cover/502064)
*-*-*-*-*-*-*-*
[LORE v4,0/8](https://lore.kernel.org/all/20210905143547.4668-1-laoar.shao@gmail.com) |
+| 2024/05/08 | Ravi Bangoria | [perf sched: Introduce schedstat tool](https://lore.kernel.org/all/20240508060427.417-1-ravi.bangoria@amd.com) | 现有的 "perf-shed" 非常详尽, 并提供了对调度程序行为的许多见解, 但它很快就无法用于长时间运行或调度程序密集型工作负载. 例如, "perf-shed record" 在 hackbeek 上有约 7.77% 的开销(25 个组, 每个组在 2 个套接字的 128 核 256 线程的第三代 EPYC 服务器上运行 700K 循环), [它生成了巨大的 56G 性能数据, 性能准备和写入磁盘需要约 137 分钟](https://youtu.be/lg-9aG2ajA0?t=283). 与 "perf sched record" 不同的是, "perf sched schedstat record" 挂接到一组调度程序跟踪点并在跟踪点命中时生成样本, 它在工作负载前后拍摄 / proc/schedstat 文件的快照, 即对工作负载运行没有干扰. 此外, 解析 / proc/schedstat、将其转换为 perf 示例和将这些示例保存到 perf.data 文件中. 结果 perf.data 文件要小得多. 因此, 总体而言, 与 "perf sched record" 相比, "perf sched schedstat record" 要轻得多. 我们在 AMD 内部一直在使用它的一种变体, 称为 [调度记分板 Scheduler Scoreboard](https://github.com/AMDESE/sched-scoreboard), 并发现它对分析任何调度程序代码更改的影响非常有用 [Re: [PATCH] sched/fair: no sync wakeup from interrupt context](https://lore.kernel.org/lkml/c50bdbfe-02ce-c1bc-c761-c95f8e216ca0@amd.com), [Re: [PATCH v3 6/7] sched: Implement shared runqueue in CFS]. 参见 phoronix 报道 [AMD Linux Engineers Introduce New "schedstat" Tool](https://www.phoronix.com/news/AMD-Linux-perf-schedstat-Tool). | v1 ☐☑✓ | [LORE v1,0/4](https://lore.kernel.org/all/20240508060427.417-1-ravi.bangoria@amd.com) |
## 12.2 tracepoint
@@ -6788,6 +6928,7 @@ ARM & Linaro 的内核团队针对 Android/linux 等做了大量的调度的优
| 2023/08/01 | Ze Gao | [add to report task state in symbolic chars from sched tracepoint](https://lore.kernel.org/all/20230801090124.8050-1-zegao@tencent.com) | TODO | v3 ☐☑✓ | [](https://lore.kernel.org/linux-trace-kernel/20230725072254.32045-1-zegao@tencent.com)
*-*-*-*-*-*-*-*
[LORE v2,0/3](https://lore.kernel.org/linux-trace-kernel/20230726121618.19198-1-zegao@tencent.com)
*-*-*-*-*-*-*-*
[LORE v3,0/6](https://lore.kernel.org/all/20230801090124.8050-1-zegao@tencent.com) |
| 2023/10/09 | Jinyu Tang | [Ftrace: make sched_wakeup can focus on the target process](https://lore.kernel.org/all/20231009153714.10743-1-tangjinyu@tinylab.org) | 此 Patch 只能让我们跟踪目标进程 sched-wakeup 时间, 其他进程 sched-wakeup 将被丢弃, 不会更改 tracing_max_latency. 补丁的评论区各路大神给出了已有可行的解决办法. 包括使用 [synthetic_events](https://lore.kernel.org/all/20231009122500.69854f94@gandalf.local.home) 以及 [rtla](https://bristot.me/linux-scheduling-latency-debug-and-analysis). | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20231009153714.10743-1-tangjinyu@tinylab.org) |
| 2024/04/08 | Marco Elver | [tracing: Add new_exec tracepoint](https://lore.kernel.org/all/20240408090205.3714934-1-elver@google.com) | 添加 "new_exec" 跟踪点, 该跟踪点在不返回点之后但在当前任务采用其新的 exec 标识之前运行. 与跟踪点 "sched_process_exec" 不同, "new_exec" 跟踪点在刷新旧的 exec 之前运行, 即当任务仍处于原始状态 (如原始 MM) 时, 但当新的 exec 成功或崩溃时(但永远不会返回到原始 exec). 能够跟踪此事件在许多用例中都会有所帮助:
1. 在当前 MM 被替换之前, 允许跟踪 eBPF 程序访问 exec 上的原始 MM;
2. 计算原始任务中的 exec(通过 perf 事件);
3. 分析刷新时间("new_exec" 到 "sched_process_exec").
4. 跟踪输出示例("new_exec" 和 "sched_process_exec"). | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240408090205.3714934-1-elver@google.com) |
+| 2024/02/22 | John Stultz | [sched: Add trace_sched_waking() tracepoint to sched_ttwu_pending()](https://lore.kernel.org/all/20240222204917.1719153-1-jstultz@google.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240222204917.1719153-1-jstultz@google.com) |
## 12.3 debug 接口
@@ -6827,6 +6968,7 @@ ARM & Linaro 的内核团队针对 Android/linux 等做了大量的调度的优
| [unixbench/context1]() | NA | NA |
| [os-scheduler-responsiveness-test](https://github.com/hamadmarri/os-scheduler-responsiveness-test) | os 调度程序响应能力测试. 这是一个 Python/Go 脚本, 用于测试操作系统调度程序的响应性或交互性. 交互式线程的睡眠时间多于运行时间 (即用户单击). 该脚本测量与 3 个不同任务的交互性 (对 10000 个数组进行排序, 读取文件并打印到控制台, 读取文件并将其写入另一个文件). 在每个过程中, 它休眠在 1s-3s 之间的随机时间. 同时, 你可以运行素数计算的 CPU 密集型程序, 这对于在繁重的任务运行期间测试交互性很有用. |
| [jitterdebugger](https://github.com/igaw/jitterdebugger) | [foxhoundsk 的博客 jitterdebugger 介绍](https://hackmd.io/@foxhoundsk/jitterdebugger), 衡量调度器 [切换时延](https://source.android.com/docs/core/audio/latency/contrib?hl=en#schedLatency) 以及操作系统底噪抖动的工具. |
+| [michaeljclark/cpipe](https://github.com/michaeljclark/cpipe) | [user-space concurrent pipe buffer scheduler interactions](https://lore.kernel.org/all/969ccc0f-d909-4b45-908e-e98279777733@metaparadigm.com), 实现了一个并发管道缓冲区的 benchmark, 设计用于单生产者单使用者或多生产者多使用者模式, 支持并发预写、并发预读和零复制操作, 用于 IO 缓冲区范围内的数组计算. |
### 12.4.2 调度器延迟分析
diff --git a/study/kernel/00-DESCRIPTION/TIMER.md b/study/kernel/00-DESCRIPTION/TIMER.md
index 9dcff18..89f03a5 100644
--- a/study/kernel/00-DESCRIPTION/TIMER.md
+++ b/study/kernel/00-DESCRIPTION/TIMER.md
@@ -60,7 +60,8 @@ blogexcerpt: 虚拟化 & KVM 子系统
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
-| 2024/02/21 | Anna-Maria Behnsen | [timers: Move from a push remote at enqueue to a pull at expiry model](https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/log/?id=b2cf7507e18649a30512515ec0ca89f26b2c2d0f) | [Linux 6.9 Has A Big Rework To CPU Timers - Some Power/Performance Benefits](https://www.phoronix.com/news/Linux-6.9-Timers-Rework) | v11 ☐☑✓ 6.9-rc1 | [LORE v11,0/20](https://lore.kernel.org/all/20240221090548.36600-1-anna-maria@linutronix.de) |
+| 2024/02/21 | Anna-Maria Behnsen | [timers: Move from a push remote at enqueue to a pull at expiry model](https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/log/?id=b2cf7507e18649a30512515ec0ca89f26b2c2d0f) | [Linux 6.9 Has A Big Rework To CPU Timers - Some Power/Performance Benefits](https://www.phoronix.com/news/Linux-6.9-Timers-Rework) | v11 ☐☑✓ 6.9-rc1 | [2024/01/15, LORE v10,00/20](https://lore.kernel.org/all/20240115143743.27827-1-anna-maria@linutronix.de/)
*-*-*-*-*-*-*-*
[2024/02/21, LORE v11,0/20](https://lore.kernel.org/all/20240221090548.36600-1-anna-maria@linutronix.de) |
+| 2023/06/06 | Thomas Gleixner | [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)
*-*-*-*-*-*-*-*
[LORE v2,00/50](https://lore.kernel.org/lkml/20240410164558.316665885@linutronix.de) |
diff --git a/study/kernel/00-DESCRIPTION/TODO.md b/study/kernel/00-DESCRIPTION/TODO.md
index cb00cbe..18cd3f5 100644
--- a/study/kernel/00-DESCRIPTION/TODO.md
+++ b/study/kernel/00-DESCRIPTION/TODO.md
@@ -615,12 +615,57 @@ cba6167f0adb
| 2023/10/25 | Steven Rostedt | [sched: Extended Scheduler Time Slice](https://lore.kernel.org/all/20231025235413.597287e1@gandalf.local.home) | TODO | v2 ☐☑✓ | [LORE v1](https://lore.kernel.org/all/20231025054219.1acaa3dd@gandalf.local.home)[LORE v2](https://lore.kernel.org/all/20231025235413.597287e1@gandalf.local.home) |
| 2023/10/31 | Keisuke Nishimura | [sched/fair: Fix the decision for load balance](https://lore.kernel.org/all/20231031133821.1570861-1-keisuke.nishimura@inria.fr) | TODO | v3 ☐☑✓ | [LORE](https://lore.kernel.org/all/20231031133821.1570861-1-keisuke.nishimura@inria.fr) |
| 2024/03/04 | Christian Loehle | [Introduce per-task io utilization boost](https://lore.kernel.org/all/20240304201625.100619-1-christian.loehle@arm.com) | TODO | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20240304201625.100619-1-christian.loehle@arm.com) |
-| 2023/11/30 | Valentin Schneider | [sched/fair: Delay throttling to kernel exit](https://lore.kernel.org/all/20231130161245.3894682-1-vschneid@redhat.com) | TODO | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20231130161245.3894682-1-vschneid@redhat.com) |
-| 2024/03/24 | Qais Yousef | [sched: Don't trigger misfit if affinity is restricted](https://lore.kernel.org/all/20240324004552.999936-1-qyousef@layalina.io) | TODO | v8 ☐☑✓ | [LORE v8,0/4](https://lore.kernel.org/all/20240324004552.999936-1-qyousef@layalina.io) |
| 2024/04/11 | Kyle Huey | [Combine perf and bpf for fast eval of hw breakpoint conditions](https://lore.kernel.org/all/20240412015019.7060-1-khuey@kylehuey.com) | TODO | v6 ☐☑✓ | [LORE v6,0/7](https://lore.kernel.org/all/20240412015019.7060-1-khuey@kylehuey.com) |
| 2024/04/07 | Ingo Molnar | [sched: Split out kernel/sched/fair_balance.c, numa_balancing.c and syscalls.c, plus other updates](https://lore.kernel.org/all/20240407084319.1462211-1-mingo@kernel.org) | TODO | v1 ☐☑✓ | [LORE v1,0/5](https://lore.kernel.org/all/20240407084319.1462211-1-mingo@kernel.org) |
| 2023/05/09 | Kristina Martsenko | [arm64: Support for Armv8.8 memcpy instructions in userspace](https://lore.kernel.org/all/20230509142235.3284028-1-kristina.martsenko@arm.com) | Armv8.8 扩展添加了执行 memcpy()、memset() 和 memmove() 操作 (FEAT_MOPS). 此系列增加了对的支持使用用户空间中的新指令. | v8 ☐☑✓ | [LORE v8,0/11](https://lore.kernel.org/all/20230509142235.3284028-1-kristina.martsenko@arm.com) |
| 2023/09/15 | Kristina Martsenko | [KVM: arm64: Support for Arm v8.8 memcpy instructions in KVM guests](https://lore.kernel.org/all/20230915124840.474888-1-kristina.martsenko@arm.com) | TODO | v8 ☐☑✓ | [LORE v8,0/3](https://lore.kernel.org/all/20230915124840.474888-1-kristina.martsenko@arm.com) |
+| 2024/02/01 | alexs@kernel.org | [sched/fair: add SD_CLUSTER in comments](https://lore.kernel.org/all/20240201115447.522627-1-alexs@kernel.org) | TODO | v3 ☐☑✓ | [LORE v3,0/4](https://lore.kernel.org/all/20240201115447.522627-1-alexs@kernel.org) |
+| 2024/01/14 | Vincent Guittot | [sched/fair: Fix frequency selection for non invariant case](https://lore.kernel.org/all/20240114183600.135316-1-vincent.guittot@linaro.org) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240114183600.135316-1-vincent.guittot@linaro.org) |
+| 2024/01/11 | Ze Gao | [sched/eevdf: Use tunable knob sysctl_sched_base_slice as explicit time quanta](https://lore.kernel.org/all/20240111115745.62813-2-zegao@tencent.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240111115745.62813-2-zegao@tencent.com) |
+| 2024/03/15 | Swapnil Sapkal | [Fix lb_imbalance reporting in /proc/schedstat](https://lore.kernel.org/all/20240315135501.1778620-1-swapnil.sapkal@amd.com) | TODO | v2 ☐☑✓ | [LORE v2,0/1](https://lore.kernel.org/all/20240315135501.1778620-1-swapnil.sapkal@amd.com) |
+| 2024/04/03 | Jinjie Ruan via | [target/arm: Implement FEAT_NMI and FEAT_GICv3_NMI](https://lore.kernel.org/all/20240403101611.3204086-1-ruanjinjie@huawei.com) | TODO | v3 ☐☑✓ | [LORE v3,0/23](https://lore.kernel.org/all/20240403101611.3204086-1-ruanjinjie@huawei.com) |
+| 2024/02/22 | zhaoyang.huang | [sched: introduce helper function to calculate distribution over sched class](https://lore.kernel.org/all/20240222092220.642294-1-zhaoyang.huang@unisoc.com) | TODO | v2 ☐☑✓ | [LORE v2,0/2](https://lore.kernel.org/all/20240222092220.642294-1-zhaoyang.huang@unisoc.com) |
+| 2024/05/03 | Andrii Nakryiko | [ioctl()-based API to query VMAs from /proc//maps](https://lore.kernel.org/all/20240504003006.3303334-1-andrii@kernel.org) | TODO | v1 ☐☑✓ | [LORE v1,0/5](https://lore.kernel.org/all/20240504003006.3303334-1-andrii@kernel.org) |
+| 2024/02/25 | Frederic Weisbecker | [timers/nohz cleanups and hotplug reorganization](https://lore.kernel.org/all/20240225225508.11587-1-frederic@kernel.org) | TODO | v3 ☐☑✓ | [LORE v3,0/16](https://lore.kernel.org/all/20240225225508.11587-1-frederic@kernel.org) |
+| 2024/02/14 | David Hildenbrand | [mm/memory: optimize unmap/zap with PTE-mapped THP](https://lore.kernel.org/all/20240214204435.167852-1-david@redhat.com) | TODO | v3 ☐☑✓ | [LORE v3,0/10](https://lore.kernel.org/all/20240214204435.167852-1-david@redhat.com) |
+| 2024/03/29 | Baolin Wang | [support multi-size THP numa balancing](https://lore.kernel.org/all/cover.1711683069.git.baolin.wang@linux.alibaba.com) | 这个补丁试图支持 mTHP-numa 平衡, 作为一个简单的解决方案, mTHP 的 numa 平衡算法将遵循 THP 策略作为基本支持. 请在每个补丁中找到详细信息. | v2 ☐☑✓ | [LORE v2,0/2](https://lore.kernel.org/all/cover.1711683069.git.baolin.wang@linux.alibaba.com) |
+| 2024/03/29 | weilin.wang@intel.com | [TPEBS counting mode support](https://lore.kernel.org/all/20240329191224.1046866-1-weilin.wang@intel.com) | TODO | v6 ☐☑✓ | [LORE v6,0/5](https://lore.kernel.org/all/20240329191224.1046866-1-weilin.wang@intel.com) |
+| 2024/04/30 | Vitalii Bursov | [sched/fair: allow disabling sched_balance_newidle with sched_relax_domain_level](https://lore.kernel.org/all/cover.1714488502.git.vitaly@bursov.com) | TODO | v4 ☐☑✓ | [LORE v4,0/3](https://lore.kernel.org/all/cover.1714488502.git.vitaly@bursov.com) |
+| 2024/02/29 | Thomas Gleixner | [x86/idle: Cure RCU violations and cleanups](https://lore.kernel.org/all/20240229141407.283316443@linutronix.de) | TODO | v1 ☐☑✓ | [LORE v1,0/6](https://lore.kernel.org/all/20240229141407.283316443@linutronix.de) |
+| 2023/12/08 | Qais Yousef | [sched: cpufreq: Remove uclamp max-aggregation](https://lore.kernel.org/all/20231208015242.385103-1-qyousef@layalina.io) | TODO | v1 ☐☑✓ | [LORE v1,0/4](https://lore.kernel.org/all/20231208015242.385103-1-qyousef@layalina.io) |
+| 2024/03/25 | Shrikanth Hegde | [sched/fair: Simplify continue_balancing for newidle](https://lore.kernel.org/all/20240325153926.274284-1-sshegde@linux.ibm.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240325153926.274284-1-sshegde@linux.ibm.com) |
+| 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) |
+| 2024/02/28 | Tobias Huschle | [sched/eevdf: sched feature to dismiss lag on wakeup](https://lore.kernel.org/all/20240228161018.14253-1-huschle@linux.ibm.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240228161018.14253-1-huschle@linux.ibm.com) |
+| 2024/03/29 | Chunxin Zang | [sched/fair: Reset vlag in dequeue when PLAGE_LAG is disabled](https://lore.kernel.org/all/20240329091933.340739-1-spring.cxz@gmail.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240329091933.340739-1-spring.cxz@gmail.com) |
+| 2024/04/03 | Pierre Gondois | [sched/fair|isolation: Correctly clear nohz.[nr_cpus|idle_cpus_mask] for isolated CPUs](https://lore.kernel.org/all/20240403150543.2793354-1-pierre.gondois@arm.com) | TODO | v1 ☐☑✓ | [LORE v1,0/7](https://lore.kernel.org/all/20240403150543.2793354-1-pierre.gondois@arm.com) |
-lag_i = S - s_i = w_i \times (V - v_i) = w_i \times [\frac{\sum \limits_{0}^{n}w_{i} \times (v_{i} - v_{0})}{W} + v_{0} - v_i] = w_i \times [\frac{\sum \limits_{0}^{n}w_{i} \times (v_{i} - v_{0})}{W} - (v_{i} - v_0)] > 0
+
+[udev-hid-bpf To Help Enable HID-BPF Use Rather Than Kernel Drivers To Fix HID Hardware](https://www.phoronix.com/news/udev-hid-bpf)
+[Hutterer: udev-hid-bpf: quickstart tooling to fix your HID devices with eBPF](https://lwn.net/Articles/970702)
+[Cleaning up after BPF exceptions](https://lwn.net/Articles/969185)
+[Better linked-list traversal in BPF](https://lwn.net/Articles/964381)
+[A proposal for shared memory in BPF programs](https://lwn.net/Articles/961941)
+[Sleepable BPF programs](https://lwn.net/Articles/825415)
+
+
+[Wattch: a framework for architectural-level power analysis and optimizations](https://ieeexplore.ieee.org/document/854380)
+
+
+
+
+
+[Intel Talks Up 2024 Xeon Sierra Forest & Granite Rapids At Hot Chips](https://www.phoronix.com/review/intel-hotchips-2023)
+
+
+
+
+| 日期 | LWN | 翻译 |
+|:---:|:----:|:---:|
+| 2007/04/17 | [An update and future plans for DAMON](https://lwn.net/Articles/973702) | NA |
\ No newline at end of file