Mirrors_BOOKS/LDD-LinuxDeviceDrivers
1
0
Fork 0
mirror of https://github.com/gatieme/LDD-LinuxDeviceDrivers.git synced 2026-08-18 09:07:43 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

description/open_source: update phoronix vs LWN to date 20240801

Browse Source
This commit is contained in:
Cheng Jian
2024-08-12 09:54:39 +08:00
parent 631dc4cabe
commit 98a746ddb1
6 changed files with 66 additions and 51 deletions
Download Patch File Download Diff File Expand all files Collapse all files
study/kernel/00-DESCRIPTION/ARCH.md
+18 -17
View File
File diff suppressed because one or more lines are too long
study/kernel/00-DESCRIPTION/DEBUGGING.md
+20 -5
View File
@@ -249,6 +249,8 @@ $reclaim = current\_mem \times reclaim\_ratio \times max(0,1 – \frac{psi_some}
[getrandom() In The vDSO Aims For Linux 6.11 To Provide Faster Yet Secure User-Space RNG](https://www.phoronix.com/news/getrandom-vDSO-RNG-Linux-6.11)
[Glibc Patch Being Reviewed For getrandom vDSO Support](https://www.phoronix.com/news/Glibc-Review-getrandom-vDSO)
## 8.2 getrandom vDSO
-------
@@ -349,7 +351,7 @@ $reclaim = current\_mem \times reclaim\_ratio \times max(0,1 – \frac{psi_some}
| 2022/07/25 | Albert Huang <huangjie.albert@bytedance.com> | [faster kexec reboot](https://lore.kernel.org/all/20220725083904.56552-1-huangjie.albert@bytedance.com) | TODO | v1 ☐☑✓ | [LORE v1,0/4](https://lore.kernel.org/all/20220725083904.56552-1-huangjie.albert@bytedance.com) |
# 11 perf
# 11 PERF
-------
## 11.1 perf-user
@@ -385,10 +387,18 @@ $reclaim = current\_mem \times reclaim\_ratio \times max(0,1 – \frac{psi_some}
| 2022/06/16 | Namhyung Kim <namhyung@kernel.org> | [perf/core: Add a new read format to get a number of lost samples](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=119a784c81270eb88e573174ed2209225d646656) | 有时候用户想知道样本的准确数量, 即使存在一定数量的样本丢失. 当因为环缓冲区冲突造成的事件丢失使用 PERF_RECORD_LOST 标记记录, 虽然很难知道每个事件丢失的次数, 但是聊胜于无. 因此定义 PERF_FORMAT_LOST, 通过 event->lost_samples 记录丢失的次数, 以便从用户空间获取到它. | v4 ☑✓ 6.0-rc1 | [LORE](https://lore.kernel.org/all/20220616180623.1358843-1-namhyung@kernel.org) |
| 2022/08/16 | Namhyung Kim <namhyung@kernel.org> | [perf tools: Support reading PERF_FORMAT_LOST (v2)](https://lore.kernel.org/all/20220816221747.275828-1-namhyung@kernel.org) | TODO | v2 ☐☑✓ | [LORE 0/4](https://lore.kernel.org/lkml/20220815190106.1293082-1-namhyung@kernel.org)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/4](https://lore.kernel.org/all/20220816221747.275828-1-namhyung@kernel.org) |
## 11.2 ARM SPE
## 11.2 高精度采样
-------
## 11.2.1 x86 PEBS
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2024/07/20 | weilin.wang@intel.com <weilin.wang@intel.com> | [TPEBS counting mode support](https://lore.kernel.org/all/20240720062102.444578-1-weilin.wang@intel.com) | 支持 TPEBS 在 perf 计数模式下的使用, TPEBS(Timed Process Event-Based Sampling) 是 Intel 提供的一种处理器机制, 用于在性能分析中更准确地测量事件的退休延迟 (retire latency). 补丁集实现了在 Linux 的 perf 工具中, 当使用 TPEBS 功能时, 可以在计数模式下收集事件的退休延迟值. 关于 TPEBS 参见 [Timed Process Event Based Sampling (TPEBS)](https://www.intel.com/content/www/us/en/developer/articles/technical/timed-process-event-based-sampling-tpebs.html). | v18 ☐☑✓ | [LORE v18,0/8](https://lore.kernel.org/all/20240720062102.444578-1-weilin.wang@intel.com) |
## 11.2.2 ARM SPE
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
@@ -809,6 +819,9 @@ Mold 链接器中添加了一个新的 "--separate-debug-file" 选项, 以实现
["CC_OPTIMIZE_FOR_PERFORMANCE_O3" Performance Tunable Dropped In Linux 6.0](https://www.phoronix.com/news/Linux-6.0-Drops-O3-Kconfig)
[Canonical Evaluating -O3 Optimized Packages For Ubuntu Linux](https://www.phoronix.com/news/Ubuntu-Evaluating-O3-Optimized)
[Trying Out The Ubuntu "-O3" Optimized Build For Greater Performance](https://www.phoronix.com/review/ubuntu-o3-experiment)
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2022/06/21 | Miko Larsson <mikoxyzzz@gmail.com> | [Kconfig: -O3 enablement](https://lore.kernel.org/all/20220621133526.29662-1-mikoxyzzz@gmail.com) | 允许所有架构支持 -O3 编译. | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20220621133526.29662-1-mikoxyzzz@gmail.com) |
@@ -1152,9 +1165,10 @@ Fedora 尝试优化 systemd 开机以及重启的时间, 参见 phoronix 报道
[Arm Helping With AArch64 Rust Linux Kernel Enablement](https://www.phoronix.com/news/AArch64-Rust-Linux-Kernel)
[Linux 6.11 Adds Support For Rust-Based Block Drivers & Atomic Writes](https://www.phoronix.com/news/Linux-6.11-Block-IO_uring)
[An Empirical Study of Rust-for-Linux: The Success, Dissatisfaction, and Compromise](https://www.usenix.org/conference/atc24/presentation/li-hongyu)
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2022/09/27 | Miguel Ojeda <ojeda@kernel.org> | [Rust support](https://lore.kernel.org/all/20220927131518.30000-1-ojeda@kernel.org) | TODO| v10 ☐☑✓ | [LORE 00/13](https://lore.kernel.org/all/20210414184604.23473-1-ojeda@kernel.org)<br>*-*-*-*-*-*-*-* <br>[LORE v10,0/27](https://lore.kernel.org/all/20220927131518.30000-1-ojeda@kernel.org) |
@@ -1164,9 +1178,10 @@ Fedora 尝试优化 systemd 开机以及重启的时间, 参见 phoronix 报道
| 2024/05/14 | Wedson Almeida Filho <wedsonaf@gmail.com> | [Rust abstractions for VFS](https://lore.kernel.org/all/20240514131711.379322-1-wedsonaf@gmail.com) | 参见 phoronix 报道 [Microsoft Engineer Ports EXT2 File-System Driver To Rust](https://www.phoronix.com/news/Rust-VFS-Linux-V2-Now-With-EXT2) 以及 [Rust for filesystems](https://lwn.net/Articles/978738). | v2 ☐☑✓ | [LORE v2,0/30](https://lore.kernel.org/all/20240514131711.379322-1-wedsonaf@gmail.com) |
| 2024/05/20 | Danilo Krummrich <dakr@redhat.com> | [DRM Rust abstractions and Nova](https://lore.kernel.org/all/20240520172059.181256-1-dakr@redhat.com) | [RFC Patches Posted For Rust-Written NVIDIA"Nova"GPU Driver](https://www.phoronix.com/news/RFC-Rust-Nova-NVIDIA-Driver). | v1 ☐☑✓ | [LORE v1,0/8](https://lore.kernel.org/all/20240520172059.181256-1-dakr@redhat.com) |
| 2024/07/17 | Benno Lossin <benno.lossin@proton.me> | [Introduce the Rust Safety Standard](https://lore.kernel.org/all/20240717221133.459589-1-benno.lossin@proton.me) | [Rust Safety Standard Proposed For The Linux Kernel](https://www.phoronix.com/news/Rust-Safety-Standard-Linux-RFC). | v1 ☐☑✓ | [LORE v1,0/5](https://lore.kernel.org/all/20240717221133.459589-1-benno.lossin@proton.me) |
| 2024/07/01 | Miguel Ojeda <ojeda@kernel.org> | [Support several Rust toolchain versions](https://lore.kernel.org/all/20240701183625.665574-1-ojeda@kernel.org) |
几乎每一个 Linux 内核周期都会引入新的补丁, 这些补丁通常会提升内核支持的 Rust 语言版本, 以便达到一个合适的最低版本要求. Miguel Ojeda 发布的这组组补丁, 旨在使 Rust 内核代码能够支持多个版本的 Rust 编译器("rustc"), 然后只需要指定一个安全的最低 Rust 版本要求. 参见 [The Linux Kernel Matures To Having A Minimum Rust Toolchain Version](https://www.phoronix.com/news/Linux-Patches-Multiple-Rust-Ver). | v1 ☐☑✓ | [LORE v1,0/13](https://lore.kernel.org/all/20240701183625.665574-1-ojeda@kernel.org) |
| 2024/07/01 | Miguel Ojeda <ojeda@kernel.org> | [Support several Rust toolchain versions](https://lore.kernel.org/all/20240701183625.665574-1-ojeda@kernel.org) | 几乎每一个 Linux 内核周期都会引入新的补丁, 这些补丁通常会提升内核支持的 Rust 语言版本, 以便达到一个合适的最低版本要求. Miguel Ojeda 发布的这组组补丁, 旨在使 Rust 内核代码能够支持多个版本的 Rust 编译器("rustc"), 然后只需要指定一个安全的最低 Rust 版本要求. 参见 [The Linux Kernel Matures To Having A Minimum Rust Toolchain Version](https://www.phoronix.com/news/Linux-Patches-Multiple-Rust-Ver). | v1 ☐☑✓ | [LORE v1,0/13](https://lore.kernel.org/all/20240701183625.665574-1-ojeda@kernel.org) |
| 2024/07/24 | Miguel Ojeda <ojeda@kernel.org> | [Rust: support `CPU_MITIGATIONS` and enable `objtool`](https://lore.kernel.org/all/20240724161501.1319115-1-ojeda@kernel.org) | 关于在 Rust 内核代码中实现各种 CPU 安全缓解措施的最新补丁, 作为其中的一部分, 同时为 Rust 启用了 objtool 支持. 重点是根据编译器的 Retpolines、Rethunk 和直线推测 (SLS) 处理来传递相关的编译器标志以构建 Rust 代码. 通过这些补丁, 适当的标志将被传递给 Rust 编译器, 以便在需要编译器端操作的安全缓解措施中提供足够的保护. | v2 ☐☑✓ |[LORE v2,0/6](https://lore.kernel.org/all/20240724161501.1319115-1-ojeda@kernel.org) |
几乎每一个 Linux 内核周期都会引入新的补丁, 这些补丁通常会提升内核支持的 Rust 语言版本, 以便达到一个合适的最低版本要求. Miguel Ojeda 发布的这组组补丁, 旨在使 Rust 内核代码能够支持多个版本的 Rust 编译器("rustc"), 然后只需要指定一个安全的最低 Rust 版本要求. 参见 [The Linux Kernel Matures To Having A Minimum Rust Toolchain Version](https://www.phoronix.com/news/Linux-Patches-Multiple-Rust-Ver). | v1 ☐☑✓ | [LORE v1,0/13](https://lore.kernel.org/all/20240701183625.665574-1-ojeda@kernel.org) |
| 2024/08/05 | Danilo Krummrich <dakr@kernel.org> | [Generic `Allocator` support for Rust](https://lore.kernel.org/all/20240805152004.5039-1-dakr@kernel.org) | 这个补丁系列是关于为 Rust 语言在 Linux 内核中添加通用的内核分配器(Allocator)支持. 以下是补丁系列的主要变更和目的:<br>1. 添加通用内核分配器支持: 目前主线上, Rust 在 Linux 内核中的内存分配仅限于 kmalloc. 这个补丁系列扩展了这一功能, 允许使用更多的内存分配器以及分配策略.<br>2. 自定义 Allocator trait: 为了避免向内核添加不稳定的 Rust 特性, 补丁系列没有扩展 Rust 的 alloc crate 中的 Allocator trait, 也没有扩展 BoxExt 和 VecExt 扩展. 而是引入了特定的 Allocator trait, 并由 Kmalloc、Vmalloc 和 KVmalloc 分配器实现, 这些分配器也是在这个系列中实现的.<br>3. 定义内核专用类型, 移除对 alloc crate 的依赖:: 为了使用新的分配器, 补丁系列添加了自定义的 `Box<T, A>` 和 `Vec<T, A>` 类型(其中 A 是特定的分配器), 这些类型依赖于特定的分配器. | v1 ☐☑✓ | [2024/08/05, LORE v4,00/28](https://lore.kernel.org/all/20240805152004.5039-1-dakr@kernel.org) |
study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md
+1
View File
@@ -315,6 +315,7 @@ Linux 一开始是在一台 i386 上的机器开发的, i386 的硬件页表是
[Folio Improvements For Linux 5.17, Large Folio Patches Posted](https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.17-Folios)
[LWN, 2024/07/24, Large folios, swap, and FS-Cache](https://lwn.net/Articles/982887/)
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
study/kernel/00-DESCRIPTION/OPEN_SOURCE.md
+1 -1
View File
@@ -205,7 +205,7 @@ OSDI 的全称是 USENIX Symposium on Operating Systems Design and Implementatio
| 日期 | 官网 | 链接 | 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)<br>[LWN-Reports from OSPM 2023, part 1](https://lwn.net/Articles/934142)<br>[LWN-Reports from OSPM 2023, part 2](https://lwn.net/Articles/934459)<br>[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 汇总]()<br>[LORE](https://lore.kernel.org/all/ZbJHfiWnujLz2Pfm@localhost.localdomain) | [OSPM24 - topics - Google 云端硬盘](https://docs.google.com/spreadsheets/d/13lOYsbNWhQU7pNbyHI97fC7GT0Eu8aMbU9ATvPJfV0A/edit?usp=sharing) |
| 2024/05/30-2024/05/21 | [6th OSPM Summit](https://retis.sssup.it/ospm-summit/2024) | [LWN, 2024/07/11, Reports from OSPM 2024, part 1](https://lwn.net/Articles/981371)<br>[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)
-------
study/kernel/00-DESCRIPTION/SCHEDULER.md
+9 -1
View File
@@ -4713,6 +4713,9 @@ CAS 特性是通过 STATIC_KEY sched_asym_cpucapacity 控制的.
EAS 特性是通过 STATIC_KEY sched_energy_present 控制的.
[Linux内核 算力感知调度](https://mp.weixin.qq.com/s/6-UPioWDvED0lQMAmF9Vfw)
[cpu算力归一化](https://zhuanlan.zhihu.com/p/707011550)
#### 7.2.4.1 Capacity Asymmetry Detection
-------
@@ -5040,6 +5043,9 @@ DTB 中通过 OPP 字段标记 CPU 的电压及频率信息, 参见 [Documentati
CPU 的 capacity 通过 capacity-dmips-mhz 来标记. CPU 的 power Energy Model 则提供了两种方式来注册, 一种是通过 dynamic-power-coefficient, 再结合电压和频率进行计算, 一种是不提供 dynamic-power-coefficient, 那么就要求在 OPP 表中通过 opp-microwatt 显式设置功耗数据.
> dmips-mhz
> dmips 是 Dhrystone Million Instructions Per Second 的缩写. 它是一个测量 CPU 运行一个叫 Dhrystone (整数运算)的测试程序时表现出来的相对性能高低的一个单位. Dhrystone 并不包括浮点运算, 其输出结果为每秒钟运行 Dhrystone 的次数, 即每秒钟迭代主循环的次数. Dhrystone的重要性在于其能作为处理器整数计算性能的指标.
| DTB 结构 | DTB 字段 | 描述 |
|:-------:|:--------:|:---:|
| cpu-map | clutser, core, thread | 标记 CPU 的 topology 信息. |
@@ -5354,6 +5360,7 @@ CPUFreq 驱动是处理和平台相关的逻辑, Governor 中实现了具体的
| 2021/08/12 | Viresh Kumar <viresh.kumar@linaro.org> | [Add callback to register with energy model](https://lore.kernel.org/patchwork/cover/1424708) | 当前许多 cpufreq 驱动程序向每个策略的注册了能耗模型, 并通过相同的操作 dev_pm_opp_of_register_em() 来完成. 但是随着 thermal-cooling 的完善, 可以在 cpufreq 层次通过新的回调 register_em 来完成这个工作. | v3 ☐ | [PatchWork V3,0/9](https://patchwork.kernel.org/project/linux-arm-kernel/cover/cover.1628742634.git.viresh.kumar@linaro.org) |
| 2021/09/08| Viresh Kumar <viresh.kumar@linaro.org> | [Inefficient OPPs](https://patchwork.kernel.org/project/linux-pm/cover/1631109930-290049-1-git-send-email-vincent.donnefort@arm.com) | schedutil 中增加了对低能效 (inefficient) OPP 的感知, 引入 CPUFREQ_RELATION_E 标记来使得 CPUFREQ 只使用和引用有效的频点.<br>Arm 的 Power 团队在为谷歌的 Pixel4 开发一个实验性内核, 以评估和改进现实生活中 Android 设备上的主线性能和能耗. 发现 SD855 SoC 有几个效率低下的 OPP. 这些 OPP 尽管频率较低, 但功耗却较高, 任务这种频率下工作, 性能不光下降了, 功耗也很高. 通过将它们从 EAS 能效模型中移除, 使得最高效的 CPU 在任务分配上更有吸引力, 有助于减少中、大型 CPU 的运行时间, 同时提高了集群的空闲时间. 由于集群之间存在巨大的能源成本差异, 因此增加空闲时间对该平台来说至关重要. | v7 ☑ 5.16-rc1 | [PatchWork v7,0/9](https://patchwork.kernel.org/project/linux-pm/cover/1631109930-290049-1-git-send-email-vincent.donnefort@arm.com) |
| 2023/07/24 | Jie Zhan <zhanjie9@hisilicon.com> | [cpufreq: Support per-policy performance boost](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=218a06a79d9a98a96ef46bb003d4d8adb0962056) | 通过添加 "local_boost" sysfs 接口启用按策略提升. 与全局升压开关相同, 将 1/0 写入 "local_boost" 可分别启用 / 禁用 cpufreq 策略上的升压.<br> 全局和本地增压控制的用户视图应为:<br>1. 启用全局增强最初会对所有策略启用本地增强, 然后可以对每个策略单独启用或禁用本地增强, 前提是平台确实支持.<br>2. 禁用全局 boost 会使启用本地 boost 成为非法, 而将 0 写入 "local_boost" 是可以的, 但不会生效. [Per-Policy CPU Performance Boosting Proposed For Linux](https://www.phoronix.com/news/Linux-Per-Policy-CPU-Perf-Boost) | v1 ☐☑✓ 6.6-rc1 | [LORE](https://lore.kernel.org/all/20230724075827.4160512-1-zhanjie9@hisilicon.com) |
| 2024/07/28 | Qais Yousef <qyousef@layalina.io> | [cpufreq: sched/schedutil: Remove LATENCY_MULTIPLIER](https://lore.kernel.org/all/20240728192659.58115-1-qyousef@layalina.io) | 1. 移除 LATENCY_MULTIPLIER: 旧版内核中存在一个称为 LATENCY_MULTIPLIER 的常量, 其值为 1000. 这个常量被用来放大频率转换延迟(transition latency), 以计算频率请求的速率限制(rate_limit_us). 但是, 由于现代硬件的快速响应能力, 这种放大已不再必要, 且可能导致不必要的延迟.<br>2. 更新 transition_delay_us 的计算方式: 补丁提出了一个新算法来计算 transition_delay_us, 即频率转换延迟的 1.5 倍. 这样做的目的是为了给硬件处理频率转换请求留出一定的余地, 但同时又避免了过大的延迟.<br>3. 考虑现代硬件的响应时间: 补丁指出, 现代硬件的响应时间通常很短, 例如在 M1 Mac Mini 上, 频率转换延迟仅为 50 到 56 微秒. 然而, 由于之前的 LATENCY_MULTIPLIER, 实际设置的 rate_limit_us 为 50 至 56 毫秒, 这被限制为 2 毫秒. 因此, 这个补丁旨在更好地反映现代硬件的能力.<br>4. 考虑突发负载的需求: 补丁提到现代工作负载经常需要系统能够快速响应负载的变化, 例如任务的睡眠/唤醒、迁移, 或者由于 uclamp 导致的突然提升或限制. 因此, 2 毫秒的延迟可能不再是最佳选择, 尤其是考虑到 2 毫秒大约是 120 Hz 显示刷新率周期的四分之一. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240728192659.58115-1-qyousef@layalina.io) |
#### 7.3.3.2 各个手机厂商基于 schedutil 的进一步优化和改进
@@ -7247,9 +7254,10 @@ ECRTS 2020(32nd Euromicro Conference on Real-Time Systems) 上 Daniel 等人发
## 12.5 功耗
-------
| 编号 | 工具 | 描述 | 链接 |
|:---:|:----:|:---:|:---:|
| 1 | Turbostat | [tools/power/x86/turbostat](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/tools/power/x86/turbostat) | [Turbostat Gains New Features & New Hardware Support With Linux 6.10](https://www.phoronix.com/news/Linux-6.10-Turbostat) |
| 1 | Turbostat | [tools/power/x86/turbostat](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/tools/power/x86/turbostat) | [Turbostat Gains New Features & New Hardware Support With Linux 6.10](https://www.phoronix.com/news/Linux-6.10-Turbostat), [Linux's Turbostat Utility Can Now Be Used For Reading Intel PMT Counters](https://www.phoronix.com/news/Linux-6.11-Turbostat-PMT) |
study/kernel/00-DESCRIPTION/TODO.md
+17 -27
View File
@@ -659,6 +659,21 @@ cba6167f0adb
[Updates to pahole](https://lwn.net/Articles/978727)
[Eliminating indirect calls for security modules](https://lwn.net/Articles/979683)
[A capability set for user namespaces](https://lwn.net/Articles/978846)
[A look inside the BPF verifier](https://lwn.net/Articles/982077)
[CRIB: checkpoint/restore in BPF](https://lwn.net/Articles/984313)
[Direct-to-device networking](https://lwn.net/Articles/979549)
[FetchBPF: Customizable Prefetching Policies in Linux with eBPF](https://www.usenix.org/conference/atc24/presentation/cao)
[DINT: Fast In-Kernel Distributed Transactions with eBPF](https://www.usenix.org/conference/nsdi24/presentation/zhou-yang)
[Fast (Trapless) Kernel Probes Everywhere](https://atcosdi24.sched.com/event/1fLcd/fast-trapless-kernel-probes-everywhere), https://www.usenix.org/conference/atc24/presentation/jia
[Identifying On-/Off-CPU Bottlenecks Together with Blocked Samples](https://www.usenix.org/conference/osdi24/presentation/ahn)
[wPerf: Generic Off-CPU Analysis to Identify Bottleneck Waiting Events](https://www.usenix.org/conference/osdi18/presentation/zhou)
[Harvesting Memory-bound CPU Stall Cycles in Software with MSH](https://www.usenix.org/conference/osdi24/presentation/luo)
[OS2ATC-PPT](https://cloud.tsinghua.edu.cn/d/8e6c77ad1ad548acb909/)
@@ -754,30 +769,5 @@ HUAWEI P10 Plus, Vicky, Android 7.0, EMUI 5.1
Proxy Execution 是一种通用形式的优先级继承机制, 它旨在解决在多处理器系统中出现的优先级反转问题. 传统的优先级继承机制在实时任务之间工作良好, 但在复杂的工作负载中, 尤其是在涉及完全公平调度器 (CFS) 或 SCHED_DEADLINE 任务时, 传统的优先级继承机制可能会失效. 这是因为这些任务的调度不仅取决于优先级, 还取决于其他因素, 如任务的运行时间、截止时间等.
实现思想
Proxy Execution 的核心思想是, 当一个任务因为持有互斥锁而阻止另一个更高优先级的任务运行时, 持有锁的任务将 "代表" 被阻塞的任务运行. 这样做的目的是确保高优先级的任务不会被低优先级的任务长时间阻塞.
具体实现
通过保持被阻塞任务在就绪队列上、跟踪阻塞状态、选择持有互斥锁的任务作为代理、分离调度和执行上下文等方式实现了优先级继承. 这些变化旨在解决传统优先级继承机制在复杂场景下的局限性, 尤其是涉及多处理器系统中的 CFS 和 SCHED_DEADLINE 任务.
| 编号 | 目标 | 描述 | 实现细节 |
|:---:|:----:|:---:|:----:|
| 1 | 保持阻塞任务在就绪队列上 | 阻塞等待互斥锁的任务不会被从就绪队列中移除.<br> 这样, 当选择下一个任务运行时, 即使任务被阻塞, 它仍然可以被选中. |
| 2 | 跟踪阻塞任务的状态 | 任务结构中增加额外的状态来跟踪哪个互斥锁被阻塞, 以及哪个任务持有该锁.<br> 当一个任务被选中运行时, 如果它是被阻塞的, 那么系统会查找该任务被阻塞的互斥锁, 并找到持有该锁的任务. | 1. 任务状态更新: 更新了 task_struct 结构, 引入了新的字段来跟踪阻塞状态和阻塞原因.<br>2. 修改了互斥锁的数据结构以支持手递 (handoff) 模式而不是乐观自旋(optimistic spinning). |
| 3 | 选择互斥锁持有者作为代理 | 当一个被阻塞的任务被选中时, 实际上会运行持有相应互斥锁的任务.<br> 持有锁的任务现在继承了被阻塞任务的调度属性, 从而代表被阻塞的任务运行. | 1. 重构了调度器逻辑, 包括 pick_next_task() 函数, 使其能够选择合适的任务运行, 即使该任务被阻塞.<br>2. 引入了新的函数如 find_proxy_task() 来寻找合适的代理任务. [PATCH v7, 11/23] sched: Add a initial sketch of the find_proxy_task() function](https://lore.kernel.org/all/20231220001856.3710363-12-jstultz@google.com), [PATCH v7, 13/23, sched: Start blocked_on chain processing in find_proxy_task()](https://lore.kernel.org/all/20231220001856.3710363-14-jstultz@google.com) 以及 [PATCH v7, 16/23, sched: Add deactivated (sleeping) owner handling to find_proxy_task()](https://lore.kernel.org/all/20231220001856.3710363-17-jstultz@google.com)<br>3. 为了解决 RT 和 DL 负载平衡问题, 引入了链级平衡处理. |
| 4 | 调度器上下文和执行上下文的分离 | 调度器需要跟踪两个概念: "scheduler context"(即选择的任务和用于调度决策的状态)和 "execution context"(实际正在运行的任务). 这种分离允许持有锁的任务代表被阻塞的任务运行. | [PATCH v7 08/23, sched: Split scheduler and execution contexts](https://lore.kernel.org/all/20231220001856.3710363-9-jstultz@google.com) 将调度上下文定义为 task_struct 中选定要运行的任务的所有调度器状态, 将执行上下文定义为实际运行任务所需的所有状态 通过在逻辑上拆分这些任务, 以便我们可以使用所选要调度的任务的调度上下文, 但实际运行时使用不同任务的执行上下文. 为此, 引入 rq_selectd() 宏指向调度程序从运行队列中选择的 task_struct, 并将用于调度程序状态, 并保留 rq->curr 以指示实际运行的任务的执行上下文. |
| 5 | 处理复杂的边缘情况 | 比如互斥锁持有者自身也可能被阻塞, 或者在不同的 CPU 上运行, 或处于迁移状态等.<br> 为了处理这些复杂情况, Proxy Execution 引入了额外的逻辑来处理这些边缘情况. | 比如:<br>1. 当一个被阻塞的任务最终获得所需的资源时, 它需要被迁移到适当的 CPU 上. 优化了返回迁移逻辑, 例如避免在不适当的时间迁移任务. |
测试案例:
为了验证负载平衡不变性, 引入了一个名为 sched_football 的测试案例.
这个测试案例模拟了锁链上的任务调度, 以验证 Proxy Execution 是否正确处理了 RT 和 DL 负载平衡.
总结
这个补丁系列是关于为 Rust 语言在 Linux 内核中添加通用的内核分配器(Allocator)支持. 以下是补丁系列的主要变更和目的:<br>1. 添加通用内核分配器支持: 目前主线上, Rust 在 Linux 内核中的内存分配仅限于 kmalloc. 这个补丁系列扩展了这一功能, 允许使用更多的内存分配器以及分配策略.<br>2. 自定义 Allocator trait: 为了避免向内核添加不稳定的 Rust 特性, 补丁系列没有扩展 Rust 的 alloc crate 中的 Allocator trait, 也没有扩展 BoxExt 和 VecExt 扩展. 而是引入了特定的 Allocator trait, 并由 Kmalloc、Vmalloc 和 KVmalloc 分配器实现, 这些分配器也是在这个系列中实现的. 为了使用新的分配器, 补丁系列添加了自定义的 `Box<T, A>` 和 `Vec<T, A>`` 类型(其中 A 是特定的分配器), 这些类型依赖于特定的分配器.<br>3. 移除对 alloc crate 的依赖: 通过这个系列的更改, 内核构建完全移除了对 Rust 的 alloc crate 的依赖.
定义内核专用类型: 定义了内核专用的 Box<T, A> 和 Vec<T, A> 类型, .