Mirrors_BOOKS/LDD-LinuxDeviceDrivers
1
0 Fork 0
mirror of https://github.com/gatieme/LDD-LinuxDeviceDrivers.git synced 2026-11-15 13:04:18 +08:00
Code Issues Packages Projects Releases Wiki Activity

description/open_source: update phoronix vs LWN to date 20240720

Browse Source
This commit is contained in:
Cheng Jian committed 2024-07-31 22:47:42 +08:00
1 parent d28783a80b
commit 1bf667ce23
7 files changed
+72 -20
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

study/kernel/00-DESCRIPTION/ARCH.md
+2
View File
@@ -1053,6 +1053,8 @@ https://blogs.vmware.com/vsphere/2021/10/introducing-project-capitola.html
[kernel cxl.git](https://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl.git)
[The Current State Of CXL Support On Linux](https://www.phoronix.com/news/Linux-6.11-CXL)
#### 6.3.2.1 CXL Support
-------
study/kernel/00-DESCRIPTION/DEBUGGING.md
+8 -1
View File
@@ -258,9 +258,13 @@ $reclaim = current\_mem \times reclaim\_ratio \times max(0,1 – \frac{psi_some}
[A vDSO implementation of getrandom()](https://lwn.net/Articles/919008)
[Linux 6.11 Lands Support For getrandom() In The vDSO](https://www.phoronix.com/news/Linux-6.11-Lands-getrandom-vDSO)
[What became of getrandom() in the vDSO](https://lwn.net/Articles/983186)
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2022/07/29 | Jason A. Donenfeld <Jason@zx2c4.com> | [random: implement getrandom() in vDSO](https://lore.kernel.org/all/20220729145525.1729066-1-Jason@zx2c4.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20220729145525.1729066-1-Jason@zx2c4.com)<br>*-*-*-*-*-*-*-* <br>[2023/01/01 LORE v14,0/7](https://lore.kernel.org/all/20230101162910.710293-1-Jason@zx2c4.com) |
| 2022/07/29 | Jason A. Donenfeld <Jason@zx2c4.com> | [random: implement getrandom() in vDSO](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=ad8070cb1b4bd40aa19a5e3f7c24d7f62c71b382) | TODO | v1 ☐☑✓ v6.11-rc1 | [LORE](https://lore.kernel.org/all/20220729145525.1729066-1-Jason@zx2c4.com)<br>*-*-*-*-*-*-*-* <br>[2023/01/01 LORE v14,0/7](https://lore.kernel.org/all/20230101162910.710293-1-Jason@zx2c4.com) |
# 9 PRINTK
@@ -1160,6 +1164,9 @@ 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/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) |
study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md
+11 -8
View File
@@ -367,7 +367,8 @@ Linux 一开始是在一台 i386 上的机器开发的, i386 的硬件页表是
| 2023/07/28 | Yin, Fengwei <fengwei.yin@intel.com> | [support large folio for mlock](https://patchwork.kernel.org/project/linux-mm/cover/20230728070929.2487065-1-fengwei.yin@intel.com/) | 770426 | v1 ☐☑ | [LORE v1,0/3](https://lore.kernel.org/r/20230728070929.2487065-1-fengwei.yin@intel.com) |
| 2023/08/21 | Matthew Wilcox <willy@infradead.org> | [Convert perf ringbuffer to folios](https://patchwork.kernel.org/project/linux-mm/cover/20230821202016.2910321-1-willy@infradead.org/) | 777998 | v1 ☐☑ | [LORE v1,0/4](https://lore.kernel.org/r/20230821202016.2910321-1-willy@infradead.org) |
| 2024/05/15 | Daniel Gomez <da.gomez@samsung.com> | [[LSF/MM/BPF RFC] shmem/tmpfs: add large folios support](https://lore.kernel.org/all/20240515055719.32577-1-da.gomez@samsung.com) | [Large-folio support for shmem and tmpfs](https://lwn.net/Articles/974630) | v1 ☐☑✓ | [LORE v1,0/12](https://lore.kernel.org/all/20240515055719.32577-1-da.gomez@samsung.com) |
| 2024/05/06 | Baolin Wang <baolin.wang@linux.alibaba.com> | [add mTHP support for anonymous shmem](https://lore.kernel.org/all/cover.1714978902.git.baolin.wang@linux.alibaba.com) | TODO | v1 ☐☑✓ | [LORE v1,0/8](https://lore.kernel.org/all/cover.1714978902.git.baolin.wang@linux.alibaba.com) |
| 2024/05/06 | Baolin Wang <baolin.wang@linux.alibaba.com> | [add mTHP support for anonymous shmem](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=66f44583f9b617d74ffa2487e75a9c3adf344ddb) | 这个补丁集的目标是为匿名共享内存 (shmem) 添加多尺寸透明巨大页 (mTHP) 的支持. Baolin Wang 提出, 根据两周一次的 MM 会议讨论, mTHP 控制应该覆盖所有的共享内存(shmem), 不仅仅是匿名共享内存. 虽然补丁集将逐步添加支持, 但首先从支持匿名共享内存开始.<br>背景: Baolin Wang 指出, 匿名页面已经可以通过 [commit 19eaf44954df ("mm: thp: support allocation of anonymous multi-size THP")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=19eaf44954df64f9bc8dec398219e15ad0811497) 支持多尺寸透明巨大页 (mTHP) 分配, 这允许用户通过位于 `/sys/kernel/mm/transparent_hugepage/hugepage-XXkb/enabled` 的 sysfs 接口来配置透明巨大页(THP). 然而, 匿名共享内存 (shmem) 会忽略通过 sysfs 接口配置的匿名 mTHP 规则, 并且只能使用 PMD 映射的 THP. Baolin Wang 强调这种行为并不合理, 因为许多应用程序 (尤其是在数据库使用场景中) 通过 mmap(MAP_SHARED | MAP_ANONYMOUS) 实现匿名页面共享, 因此用户期望对所有匿名页面应用统一的 mTHP 策略, 包括匿名共享页面, 以享受 mTHP 的好处, 例如更低的延迟、更小的内存膨胀以及在 ARM 架构上减少 TLB 缺失等.<br>策略: <br>1. 该补丁集引入了一个新的 sysfs 接口 `/sys/kernel/mm/transparent_hugepage/hugepage-XXkb/shmem_enabled`, 它几乎与顶级的 `/sys/kernel/mm/transparent_hugepage/shmem_enabled` 具有相同的值, 增加了 "inherit" 选项并去掉了测试选项 "force" 和 "deny". 默认情况下, 所有大小都将设置为 "never", 除了 PMD 大小, 这将设置为 "inherit". 这样可以确保与现有的匿名共享内存启用设置的向后兼容性.<br>2. 修改了匿名共享内存的分配逻辑, 以便支持多尺寸透明巨大页.<br>3. 添加了针对匿名共享内存的 mTHP 计数器. | v1 ☐☑✓ v6.11-rc1 | [LORE v1,0/8](https://lore.kernel.org/all/cover.1714978902.git.baolin.wang@linux.alibaba.com)<br>*-*-*-*-*-*-*-* <br>[2024/06/11, LORE v5, 0/6](https://lore.kernel.org/all/cover.1718090413.git.baolin.wang@linux.alibaba.com) |
| 2024/06/28 | Bang Li <libang.li@antgroup.com> | [support "THPeligible" semantics for mTHP with anonymous shmem](https://lore.kernel.org/all/20240628104926.34209-1-libang.li@antgroup.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240628104926.34209-1-libang.li@antgroup.com) |
@@ -5354,17 +5355,19 @@ David Rientjes 率先提出了这种想法 [Hugepage collapse in process context
| 2019/08/22 | Yang Shi <yang.shi@linux.alibaba.com> | [Make deferred split shrinker memcg aware](https://lore.kernel.org/patchwork/patch/869414) | 目前, THP 延迟分割收缩器不了解 memcg, 这可能会导致某些配置过早地处罚 OOM.<br> 通过引入每个 memcg 延迟拆分队列, 转换延迟拆分收缩器 memcg aware. THP 应位于每个节点或每个 memcg 延迟拆分队列上(如果它属于 memcg). 当页面迁移到另一个 memcg 时, 它也将迁移到目标 memcg 的延迟分割队列.<br> 对于每个 memcg 列表, 重复使用第二个尾页的延迟列表, 因为同一个 THP 不能位于多个延迟拆分队列上.<br> 使延迟分割收缩器不依赖于 memcg kmem, 因为它不是 slab. 过上述更改, 即使禁用了 memcg kmem(配置 cgroup.memory=nokmem), 测试也不会触发 OOM. | v6 ☑ 5.4-rc1 | [PatchWork v6,0/4](https://patchwork.kernel.org/project/linux-mm/cover/1566496227-84952-1-git-send-email-yang.shi@linux.alibaba.com) |
| 2018/01/03 | Michal Hocko <mhocko@kernel.org> | [unclutter thp migration](https://lore.kernel.org/patchwork/patch/869414) | THP 迁移以令人惊讶的语义侵入了通用迁移. 迁移分配回调应该检查 THP 是否可以立即迁移, 如果不是这样, 则分配一个简单的页面进行迁移. 取消映射和移动, 然后通过将 THP 拆分为小页面, 同时将标题页面移动到新分配的 order-0 页面来修复此问题. 剩余页面通过拆分页面移动到 LRU 列表. 如果 THP 分配失败, 也会发生同样的情况. 这真的很难看而且容易出错. | v1 ☐ | [PatchWork 0/3](https://lore.kernel.org/patchwork/patch/869414) |
| 2020/11/19 | Zi Yan <ziy@nvidia.com> | [Split huge pages to any lower order pages and selftests.](https://patchwork.kernel.org/project/linux-mm/cover/20201119160605.1272425-1-zi.yan@sent.com) | NA | v1 ☐ | [PatchWork 0/7](https://patchwork.kernel.org/project/linux-mm/cover/20201119160605.1272425-1-zi.yan@sent.com)<br>*-*-*-*-*-*-*-* <br>[LORE v1,0/5](https://lore.kernel.org/r/20220321142128.2471199-1-zi.yan@sent.com) |
#### 7.2.5.2 splitting test
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2016/01/15 | Kirill A. Shutemov <kirill.shutemov@linux.intel.com> | [thp: add debugfs handle to split all huge pages](https://www.spinics.net/lists/linux-mm/msg99353.html) | 将 1 写入 "split_huge_pages" 接口将尝试查找并拆分系统中的所有 THP. 这对于调试非常有用. | v1 ☑ 4.5-rc1 | [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49071d436b51b58aeaf7abcd1877f38ca0146e31) |
| 2020/11/19 | Zi Yan <ziy@nvidia.com> | [mm: huge_memory: a new debugfs interface for splitting THP tests.](https://patchwork.kernel.org/project/linux-mm/cover/20201119160605.1272425-1-zi.yan@sent.com) | 提供了一个直接的用户接口来拆分 THP. 使用 `<debugfs>/split` 接受一个新命令来执行此操作. 通过将 "<pid>,<vaddr_start>,<vaddr_end>" 写入 "<debugfs>/split_huge_pages"将 分割具有给定 pid 的进程中给定虚拟地址范围内的 thp. 用于测试拆分页面功能. 此外, 还向 `tools/testing/selftests/vm` 添加了一个自检程序, 通过拆分 PMD THP 和 PTE 映射 THP 来利用该接口. 这不会改变旧的行为, 即向接口写入 1 仍然会拆分系统中的所有 THP. | v8 ☑ 5.13-rc1 | [PatchWork v8,1/2](https://patchwork.kernel.org/project/linux-mm/patch/20210331235309.332292-1-zi.yan@sent.com), [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fa6c02315f745f00b62c634b220c3fb5c3310258) |
#### 7.2.5.2 Reclaim THP
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2024/05/01 | Lance Yang <ioworker0@gmail.com> | [Reclaim lazyfree THP without splitting](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=735ecdfaf4e802209caf34b7ac45adf448c54ccc) | 该补丁集旨在改进内核处理透明巨大页 (THP) 的 lazyfree 机制. 添加了支持在不需要先分割大型 folio 的情况下回收被标记为 lazyfree 的 PMD 映射 THP 的能力. 当用户不再需要这些页面时, 他们会使用 madvise(MADV_FREE) 标记这些页面为 lazyfree. 之后, 用户通常不会再写入这些内存. 在内存回收期间, 如果检测到大型 folio 和其 PMD 都仍然被标记为干净, 并且没有意外的引用(如 GUP), 那么就可以懒惰地丢弃这些内存, 从而提高内存回收的效率. Lance Yang 在 Intel i5 CPU 上测试了回收 1 GiB 的 lazyfree THP 的性能, 使用 mem_cgroup_force_empty() 函数进行回收, 使用新的补丁集可以显著降低回收所需的时间, 从原来的 0.683426 秒减少到了 0.049197 秒, 减少了大约 92.80%. | v4 ☐☑✓ v6.11-rc1 | [LORE v4,0/3](https://lore.kernel.org/all/20240501042700.83974-1-ioworker0@gmail.com) |
### 7.2.6 Reduce memory bloat
-------
study/kernel/00-DESCRIPTION/OPEN_SOURCE.md
+1 -1
View File
@@ -111,7 +111,7 @@
| 6.8 | [The first half of the 6.8 merge window](https://lwn.net/Articles/957188), [The rest of the 6.8 merge window](https://lwn.net/Articles/958178) | NA | NA |
| 6.9 | [The first half of the 6.9 merge window](https://lwn.net/Articles/965141), [Kernel prepatch 6.9-rc1](https://lwn.net/Articles/966525), [The rest of the 6.9 merge window](https://lwn.net/Articles/965541) | NA | NA |
| 6.10 | [The first half of the 6.10 merge window](https://lwn.net/Articles/973687)<br>*-*-*-*-*-*-*-* <br>[The rest of the 6.10 merge window](https://lwn.net/Articles/974869)<br>*-*-*-*-*-*-*-* <br>[Kernel prepatch 6.10-rc2](https://lwn.net/Articles/976498). | NA | [Linux 6.10-rc1 Kernel Released With Many New Features](https://www.phoronix.com/news/Linux-6.10-rc1), [Linux 6.10-rc5 Released With This Kernel Cycle Looking Good So Far](https://www.phoronix.com/news/Linux-6.10-rc5) |
| 6.11 | [The first half of the 6.11 merge window](https://lwn.net/Articles/982034) | NA | NA |
| 6.11 | [The first half of the 6.11 merge window](https://lwn.net/Articles/982034), [LWN, 2024/07/28, Kernel prepatch 6.11-rc1](https://lwn.net/Articles/983760), [LWN, 2024/07/29, The rest of the 6.11 merge window](https://lwn.net/Articles/982605/) | NA | NA |
年终盘点
study/kernel/00-DESCRIPTION/SCHEDULER.md
+25 -9
View File
@@ -927,6 +927,8 @@ Chang 的 patch set 采用了与之前不同的方法: 允许 cgroup 将一些
[CPU 负载均衡之 WALT 学习](https://blog.csdn.net/xiaoqiaoq0/article/details/107135747)
[when_walt_load_update_happened](https://github.com/Rust401/OS-kernel-dev-config/blob/main/notes/walt/when_walt_load_update_happened.md)
WALT 以一个窗口 walt_ravg_window 内 TASK/RQ 的平均执行速率作为其 utilization. 通过窗口内每个周期对进程的运行时间 delta 按照 capacity_curr_of 进行缩放得到 scale\_exec\_time, 然后窗口内所有 scale\_exec\_time 累计求和, 即可得到窗口内 TASK/RQ 的负载信息. 即:
$scale\_exec\_time=delta \times \frac{capacity\_curr\_of}{1024}$
@@ -1069,14 +1071,14 @@ $load = \displaystyle \sum^{n}_{i = 0}{{L_i}{y^i}} = L_0+L_1y+L_2y^2+L_3y^3.....
* 32 个 period 之前负载对当前 period 的影响力降到原来一半. 也就是说 $y^{32} = 0.5$, 即 $y \approx 0.97857206$
* period [超过 $32^63-1$ 之后, 就会将 load 衰减为 0](https://elixir.bootlin.com/linux/v4.12/source/kernel/sched/fair.c#L2738), 也就是只会统计前 64*63-1 个 perod 的 load.
* period [超过 $32^63-1$ 之后, 就会将 load 衰减为 0](https://elixir.bootlin.com/linux/v4.12/source/kernel/sched/fair.c#L2738), 也就是只会统计前 `64*63-1` 个 perod 的 load.
很明显这是一个无穷级数, 那么一个 entity, 从创建开始如果一直运行, 那么 $L_i$ 一直为 1, 那么就成为一个等比数列求和 (公比为衰减因子 y).
$Sum_n = L_i{\frac{1-q^n}{1-q}}$
该公式的图像参见 [函数图像绘制工具](https://zh.numberempire.com/graphingcalculator.php?functions=y%3D1024*(1-0.9785%5Ex)%2F(1-0.9785)&xmin=0&xmax=603.054551&ymin=0&ymax=47628&var=x).
该公式的图像参见 [函数图像绘制工具](https://zh.numberempire.com/graphingcalculator.php?functions=y%3D1024*(1-0.9785%5Ex)%2F(1-0.9785)&xmin=0&xmax=603.054551&ymin=0&ymax=47628&var=x) 以及 [desmos.com/calculator](https://www.desmos.com/calculator?lang=zh-CN).
对于一个无穷递降数列, 数列的公比 y < 1, 因此无穷级数是收敛的, 当上式得 n 趋向于正无穷大时, 分子括号中的值趋近于 1, 取极限即得无穷递减数列求和公式.
@@ -1603,7 +1605,7 @@ rebalance_domains()
-=> activate_task(rq, p, 0);
```
### 4.3.1.3 新的命名方式
#### 4.3.1.3 新的命名方式
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
@@ -1996,7 +1998,7 @@ CPU 负载均衡器在不同的域之间进行平衡, 以分散负载, 并努力
|:----:|:----:|:---:|:---:|:----------:|:----:|
| 2020/03/11 | Valentin Schneider <valentin.schneider@arm.com> | [sched: Streamline select_task_rq() & select_task_rq_fair()](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=36c5bdc4387056af3840adb4478c752faeb9d15e) | 选核流程上的重构和优化, 当然除此之外还做了其他操作, 比如清理了 sd->flags 信息, 甚至 sysfs 接口都变成只读了. 只合入了补丁集的前 4 个补丁. | v3 ☑ 5.8-rc1 | [LORE v2,0/9](https://lore.kernel.org/lkml/20200311181601.18314-1-valentin.schneider@arm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v3,0/9](https://lore.kernel.org/all/20200415210512.805-1-valentin.schneider@arm.com) |
#### 4.3.3.3 power aware scheduling
#### 4.3.3.4 power aware scheduling
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
@@ -4544,7 +4546,8 @@ c27c56105dca ANDROID: Add find_best_target to minimise energy calculation overhe
#### 7.2.3.6 energy-aware load-balancing decisions
-------
* sched domain overutilized
##### 7.2.3.6.1 sched domain overutilized
-------
EAS 按照能效进行选核等操作也是有一定开销的, 因此调度器 更倾向于在系统负载不高仍有余力时使用 EAS 按照能效进行调度, 而当系统负载已经很高时, 不再使用 EAS, 而是回退到原生 SMP NICE 的情况. 这就需要一种标记系统是否过载的方法.
@@ -4573,7 +4576,8 @@ EAS 原生的 overutilized 机制非常保守, 一旦发现某个 CPU 出现了
| 2024/03/25 | Shrikanth Hegde <sshegde@linux.ibm.com> | [sched: Minor changes for rd->overload access](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log?id=4d0a63e5b841c759c9a306aff158420421ef016f) | 当在大型系统中运行工作负载时, 可以观察到对 rd->overload 的访问需要时间.<br>1. 补丁 1, 更新之前最好检查一下值, 因为值更改的频率较低.<br>补丁 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
##### 7.2.3.6.2 sched group energy
-------
AOSP 4.14
@@ -4597,7 +4601,8 @@ b523403113a5 ANDROID: sched: Enable idle balance to pull single task towards cpu
ac3ecee61d29 ANDROID: sched: Prevent unnecessary active balance of single task in sched group
```
* 可运行提升 (runnable boosting)
##### 7.2.3.6.3 可运行提升 (runnable boosting)
-------
在 EAS 平衡器中实现可运行提升 (runnable boosting) 功能: 考虑频率中的 CPU 争用、EAS 最大效用和负载平衡最繁忙的 CPU 选择. 将 CPU runnable_avg 纳入 CPU 利用率的考虑范畴, 以此来考虑以下方面的 CPU 争用:
@@ -4657,6 +4662,15 @@ load_balance()
##### 7.2.3.6.4 Check nr_balance_failed
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2023/12/06 | Pierre Gondois <pierre.gondois@arm.com> | [sched/fair: Use all little CPUs for CPU-bound workload](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3af7524b14198f5159a86692d57a9f28ec9375ce) | 旨在改进 Linux 内核调度器的行为, 确保在处理 CPU 密集型工作负载时能更有效地利用所有小核心 (little CPUs).<br> 背景: 在具有非对称 CPU 容量的 n CPU 平台上运行 n 个 CPU 密集型任务时, 如果系统不是 DynamIQ 系统(即, 调度域在 PKG 级别上没有设置 SD_SHARE_PKG_RESOURCES 标志), 可能会导致任务分配不是最优的, 如两个任务运行在一个大核心上, 而一个小核心则完全空闲.<br> 使用的测试平台是 Juno-r2, 具有 2 个大核心(CPU 1-2) 和 4 个小核心 (CPU 0,3-5), 它们的最大容量分别是 1024 和 383. 运行 6 个 CPU 密集型任务. 在最初的 100 毫秒内, 除了一个保持空闲的小核心和一个承载两个任务的大核心外, 每个任务都绑定到一个 CPU 上. 100 毫秒后, 移除 CPU 亲和性限制.<br> 补丁前的行为: 在测试的第二步, 调度器从空闲的小核心运行时, 会将调度域标记为 "有备用容量" 或 "过载", 导致最繁忙的运行队列(runqueue) 是承载两个任务的大核心的运行队列, 而空闲的小核心由于容量太小而无法吸引这些任务.<br> 补丁后的行为: 随着调度失败尝试次数的增加(nr_balance_failed), 补丁使得将大任务迁移到空闲的小核心变得更加容易. 这种机制也适用于 "migrate_load" 迁移类型.<br>在测试工作负载中, 补丁能够将大核心在第二步的负载时间从大约 19.3 秒减少到 18 秒, 性能提升了 6.7%.<br>在 detach_tasks 函数中, 将判断迁移任务的条件从简单的 `util > env->imbalance` 改为 `shr_bound(util, env->sd->nr_balance_failed) > env->imbalance`, 这允许在多次平衡尝试失败后, 更容易地迁移任务. | v3 ☐☑✓ v6.8-rc1 | [LORE](https://lore.kernel.org/all/20231206090043.634697-1-pierre.gondois@arm.com) |
#### 7.2.3.x EAS timeline
-------
@@ -4882,7 +4896,7 @@ Misfit Task 对调度器 ** 负载均衡 ** 做了如下改造, 参见 [commit c
| 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
* Check Affinity
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
@@ -6370,7 +6384,7 @@ $deadline_{se} = vruntime_{se} + slice \times \frac{weight_0}{weight_{se}}$
| 2023/11/04 | Yiwei Lin <s921975628@gmail.com> | [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 <mingo@kernel.org> | [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 <wuyun.abel@bytedance.com> | [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 滞点.<br>2. 按照虚拟截止日期对任务时间线进行排序, 并将 min_vruntime 保留在增强树中, 这样实现了一种基于最后期限排序的最左侧缓存红黑树( deadline-sorted leftmost-cached rbtree). 通过在 best_left 上进行回退搜索, 可以避免在最坏的情况下会使成本翻倍的问题.<br>3. 充分利用缓存的最左边节点, 可以达成 O(1) 复杂度的 PICK TASK.<br>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 <peterz@infradead.org> | [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/04/05 | Peter Zijlstra <peterz@infradead.org> | [sched/fair: Complete EEVDF](https://lore.kernel.org/all/20240405102754.435410987@infradead.org) | 这是 EEVDF 补丁集的最终版本. 补丁集中包含了大量错误修复以及一些新的特性, 具体包括:<br>1. 分割大型的延迟卸载(delay-dequeue)补丁: 补丁集中的一个大型补丁被拆分成了多个较小的补丁, 以便更好地理解和维护.<br>2. CFS 带宽测试与修复: CFS (Completely Fair Scheduler) 带宽相关的功能进行了测试并修复了一些问题.<br>3. PLACE_REL_DEADLINE: 引入了一个新特性, 可以在任务迁移时保留相对截止时间.<br>4. SCHED_BATCH 等同于 RESPECT_SLICE: SCHED_BATCH 任务现在等同于 RESPECT_SLICE, 这意味着批处理任务将受到切片限制.<br>5. min_slice 在控制组层级传播: 最小切片(min_slice)的设置现在会在控制组(cgroup)层级中向上传播.<br>6. CLOCK_THREAD_DVFS_ID: 引入了一个新的线程时钟标识符(CLOCK_THREAD_DVFS_ID), 这可能与动态电压和频率缩放(DVFS)相关. 参见 [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), [phoronix, 2024/07/27, EEVDF Scheduler On The Verge Of Being "Complete"](https://www.phoronix.com/news/Linux-Completing-EEVDF). | v1 ☐☑✓ | [2024/04/05, LORE v1,0/10](https://lore.kernel.org/all/20240405102754.435410987@infradead.org)<br>*-*-*-*-*-*-*-* <br>[2024/07/27, LORE 02,00/24](https://lore.kernel.org/all/20240727102732.960974693@infradead.org) |
| 2024/01/11 | Ze Gao <zegao2021@gmail.com> | [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 <mathieu.desnoyers@efficios.com> | [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 <huschle@linux.ibm.com> | [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) |
@@ -6882,6 +6896,8 @@ LSFMMBPF 2024 上对 sched_ext 进行了讨论 [LWN, 2024/05/23, LSFMMBPF-2024,
尽管其他内核开发人员也提出了一些反对意见, 但是 Linus Torvalds 作为 Linux 内核的终身 "BDFL"(仁慈的独裁者), 认为 sched_ext V6 的代码已经准备好了, 在 Linux 内核主线更能体现其价值, 不应该拖延 sched_ext 的合入. 因此 Linus Torvalds 在邮件列表 [Re: [PATCHSET v6] sched: Implement BPF extensible scheduler class](https://lore.kernel.org/lkml/CAHk-=wg8APE61e5Ddq5mwH55Eh0ZLDV4Tr+c6_gFS7g2AxnuHQ@mail.gmail.com) 宣布他打算合并 Linux 6.11 的 sched_ext 补丁. 参见 phoronix 报道 [phoronix, 2024/06/11, Linus Torvalds Throws Down The Hammer: Extensible Scheduler "sched_ext" In Linux 6.11](https://www.phoronix.com/news/Linux-6.11-Extensible-Scheduler) 和 LWN 报道 [LWN, 2024/06/11, Extensible scheduler class to be merged for 6.11](https://lwn.net/Articles/978007) 以及 [Linus 强势拍板合入: BPF 赋能调度器终成正果](https://mp.weixin.qq.com/s/dWPWuDtxQBM9Z_GXwKe0kQ).
因此, 按照要求, 早在 2024/07/15, Linux 6.11 合并窗口一打开, Tejun Heo 就提交了 sched_ext 的 Pull Request [sched_ext: Initial pull request for v6.11](https://lore.kernel.org/lkml/ZpWjbCQPtuUcvo8r@slm.duckdns.org/). sched_ext 已经演变成近 14k 行新代码, 包括测试和相关基础设施. 但是 Reviewer 指出不少代码需要改进, Qais Yousef 更是提出了一些担忧, 因此最终 6.11-rc1 发布的时候, sched_ext 并没有被合并. 参见 [phoronix, 2024/07/28, Linus Torvalds Doesn't Merge sched_ext For The Linux 6.11 Merge Window](https://www.phoronix.com/news/Linux-6.11-No-sched_ext).
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
study/kernel/00-DESCRIPTION/TODO.md
+24
View File
@@ -756,4 +756,28 @@ 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 负载平衡.
总结
study/kernel/00-DESCRIPTION/VIRT.md
+1 -1
View File
@@ -244,7 +244,7 @@ Anbox 使用 Linux 命名空间 (user, pid, uts, net, mount, ipc) 在容器中
| 2023/04/24 | Elliot Berman <quic_eberman@quicinc.com> | [Drivers for Gunyah hypervisor](https://lore.kernel.org/all/20230424231558.70911-1-quic_eberman@quicinc.com) | [Qualcomm Continues Working To Upstream Gunyah Hypervisor Support In Linux](https://www.phoronix.com/news/Qualcomm-Gunyah-Linux-v12) | v12 ☐☑✓ | [LORE v12,0/25](https://lore.kernel.org/all/20230424231558.70911-1-quic_eberman@quicinc.com) |
| 2023/05/12 | Yi-De Wu <yi-de.wu@mediatek.com> | [GenieZone hypervisor drivers](https://lore.kernel.org/all/20230512080405.12043-1-yi-de.wu@mediatek.com) | TODO | v3 ☐☑✓ | [LORE v1,0/6](https://lore.kernel.org/lkml/20230413090735.4182-1-yi-de.wu@mediatek.com)<br>*-*-*-*-*-*-*-*<br>[LORE v2,0/7](https://lore.kernel.org/lkml/20230428103622.18291-1-yi-de.wu@mediatek.com)<br>*-*-*-*-*-*-*-*<br>[LORE v3,0/7](https://lore.kernel.org/all/20230512080405.12043-1-yi-de.wu@mediatek.com) |
| 2024/02/26 | Lai Jiangshan <jiangshanlai@gmail.com> | [KVM: x86/PVM: Introduce a new hypervisor](https://lore.kernel.org/all/20240226143630.33643-1-jiangshanlai@gmail.com) | [PVM Virtualization Framework Proposed For Linux - Built Atop The KVM Hypervisor](https://www.phoronix.com/news/PVM-Hypervisor-Linux-RFC) | v1 ☐☑✓ | [LORE v1,0/73](https://lore.kernel.org/all/20240226143630.33643-1-jiangshanlai@gmail.com) |
| 2024/06/13 | Alexey Makhalov <alexey.makhalov@broadcom.com> | [VMware hypercalls enhancements](https://lore.kernel.org/all/20240613191650.9913-1-alexey.makhalov@broadcom.com) | Broadcom 一直在开发适用于 Linux 内核的 VMware Hypercall API. 这个 PATCHSET 提供了 "vmware_hyperscall" 是一系列新的功能, 供 VMware 客户机代码和虚拟设备驱动程序以独立于体系结构的方式使用. 参见 phoronix 报道 [VMware Hypercall API To Likely Land In Linux 6.11](https://www.phoronix.com/news/VMware-Hypercall-API-Linux-6.11). | v11 ☐☑✓ | [LORE v11,0/8](https://lore.kernel.org/all/20240613191650.9913-1-alexey.makhalov@broadcom.com) |
| 2024/06/13 | Alexey Makhalov <alexey.makhalov@broadcom.com> | [VMware hypercalls enhancements](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=57b7b6acb41b51087ceb40c562efe392ec8c9677) | Broadcom 一直在开发适用于 Linux 内核的 VMware Hypercall API. 这个 PATCHSET 提供了 "vmware_hyperscall" 是一系列新的功能, 供 VMware 客户机代码和虚拟设备驱动程序以独立于体系结构的方式使用. 参见 phoronix 报道 [VMware Hypercall API To Likely Land In Linux 6.11](https://www.phoronix.com/news/VMware-Hypercall-API-Linux-6.11) 和 [VMware Hypercall API Makes It Into Linux 6.11 For Basis To Allow Confidential Computing](https://www.phoronix.com/news/VMware-Hypercall-Linux-6.11). | v11 ☐☑✓ v6.11-rc1 | [LORE v11,0/8](https://lore.kernel.org/all/20240613191650.9913-1-alexey.makhalov@broadcom.com) |
# 12 HaltPolling