Mirrors_BOOKS/LDD-LinuxDeviceDrivers
1
0
Fork 0
mirror of https://github.com/gatieme/LDD-LinuxDeviceDrivers.git synced 2026-10-15 06:53:56 +08:00
Code Issues Packages Projects Releases Wiki Activity

description/open_source: update phoronix to date 20220925

Browse Source
This commit is contained in:
Cheng Jian
2022-09-25 16:14:13 +08:00
parent 150811ffb8
commit 78bc1875e5
6 changed files with 196 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files
study/kernel/00-DESCRIPTION/ARCH.md
+1 -1
View File
@@ -496,7 +496,7 @@ TLB entry shootdown 常常或多或少的带来一些性能问题.
| 2015/07/06 | Mel Gorman <mgorman@suse.de> | [TLB flush multiple pages per IPI v7](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=c7e1e3ccfbd153c890240a391f258efaedfa94d0) | BATCHED_UNMAP_TLB_FLUSH 完成了 TLB 批处理, 在批量解除页面映射后, 发送一个 IPI 来刷新多个 TLB range 的条目, 而不是每个 TLB entry 刷新都发送一个 IPI. | v7 ☑✓ 4.3-rc1 | [LORE v5,0/3](https://lore.kernel.org/all/1433767854-24408-1-git-send-email-mgorman@suse.de)<br>*-*-*-*-*-*-*-* <br>[LORE v7,0/4](https://lore.kernel.org/all/1436189996-7220-1-git-send-email-mgorman@suse.de) |
| 2017/05/07 | Andy Lutomirski <luto@kernel.org> | [x86 TLB flush cleanups, moving toward PCID support](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=d6e41f1151feeb118eee776c09323aceb4a415d9) | TODO | v1 ☑✓ 4.13-rc1 | [LORE v1,0/10](https://lore.kernel.org/all/cover.1494160201.git.luto@kernel.org) |
| 2021/02/23 | Barry Song <song.bao.hua@hisilicon.com> | [Documentation/features: mark BATCHED_UNMAP_TLB_FLUSH doesn't apply to ARM64](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6bfef171d0d74cb050112e0e49feb20bfddf7f42) | 在 x86 上, BATCHED_UNMAP_TLB_FLUSH 用于批处理 TLB, 在解除页面映射后, 发送一个 IPI 到 TLB 刷新所有条目. 在 arm64 上, TLB shootdown 是由硬件完成的. 刷新指令是内部共享的. 本地刷新限制在启动(每个 CPU 1 次)和任务获得新的 ASID 时. 因此, 将该特性标记为 "TODO" 是不恰当的. 所以这个补丁对某些架构上不需要的这类功能标记为 "N/A". | v1 ☑✓ 5.13-rc1 | [LORE](https://lore.kernel.org/all/20210223003230.11976-1-song.bao.hua@hisilicon.com) |
| 2022/07/11 | Barry Song <21cnbao@gmail.com> | [mm: arm64: bring up BATCHED_UNMAP_TLB_FLUSH](https://lore.kernel.org/all/20220711034615.482895-1-21cnbao@gmail.com) | 虽然 ARM64 有硬件来完成 TLB shootdown, 但硬件广播的开销并不小. 最简单的微基准测试表明, 即使在只有 8 核的 snapdragon 888 上, ptep_clear_flush() 的开销也是巨大的, 即使只分页一个进程映射的一个页面, perf top 显示这造成 5.36% 的 CPU 消耗. 当页面由多个进程映射或硬件有更多 CPU 时, 由于 TLB 分解的可扩展性较差, 成本应该会更高. 在这种场景下同样的基准测试可能会导致大约 100 核的 ARM64 服务器上 16.99% 的 CPU 消耗. 该补丁集利用了现有的 BATCHED_UNMAP_TLB_FLUSH 进行了优化.<br>1. 仅在第一阶段 arch_tlbbatch_add_mm() 中发送 tlbi 指令.<br>2. 等待 dsb 完成 tlbi, 同时在 arch_tlbbatch_flush() 中执行 tlbbatch sync. 在 snapdragon 上的测试表明, ptep_clear_flush() 的开销已被该补丁集优化掉. 即使在 snapdragon 888 上通过单个进程映射一个页面, 微基准也能提升 5% 的性能. | v2 ☐☑✓ | [LORE v1,0/4](https://lore.kernel.org/lkml/20220707125242.425242-1-21cnbao@gmail.com)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/4](https://lore.kernel.org/all/20220711034615.482895-1-21cnbao@gmail.com) |
| 2022/07/11 | Barry Song <21cnbao@gmail.com> | [mm: arm64: bring up BATCHED_UNMAP_TLB_FLUSH](https://lore.kernel.org/all/20220711034615.482895-1-21cnbao@gmail.com) | 虽然 ARM64 有硬件来完成 TLB shootdown, 但硬件广播的开销并不小. 最简单的微基准测试表明, 即使在只有 8 核的 snapdragon 888 上, ptep_clear_flush() 的开销也是巨大的, 即使只分页一个进程映射的一个页面, perf top 显示这造成 5.36% 的 CPU 消耗. 当页面由多个进程映射或硬件有更多 CPU 时, 由于 TLB 分解的可扩展性较差, 成本应该会更高. 在这种场景下同样的基准测试可能会导致大约 100 核的 ARM64 服务器上 16.99% 的 CPU 消耗. 该补丁集利用了现有的 BATCHED_UNMAP_TLB_FLUSH 进行了优化.<br>1. 仅在第一阶段 arch_tlbbatch_add_mm() 中发送 tlbi 指令.<br>2. 等待 dsb 完成 tlbi, 同时在 arch_tlbbatch_flush() 中执行 tlbbatch sync. 在 snapdragon 上的测试表明, ptep_clear_flush() 的开销已被该补丁集优化掉. 即使在 snapdragon 888 上通过单个进程映射一个页面, 微基准也能提升 5% 的性能. | v2 ☐☑✓ | [LORE v1,0/4](https://lore.kernel.org/lkml/20220707125242.425242-1-21cnbao@gmail.com)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/4](https://lore.kernel.org/all/20220711034615.482895-1-21cnbao@gmail.com)<br>*-*-*-*-*-*-*-* <br>[LORE v3,0/4](https://lore.kernel.org/r/20220822082120.8347-1-yangyicong@huawei.com)<br>*-*-*-*-*-*-*-* <br>[LORE v4,0/2](https://lore.kernel.org/r/20220921084302.43631-1-yangyicong@huawei.com) |
### 2.2.5 relaxed TLB flushes
-------
study/kernel/00-DESCRIPTION/BPF.md
+15
View File
@@ -479,6 +479,21 @@ glcc 则实现了 eBPF 驱动和 libbpf 的支持, 允许 eBPF 程序无需修
[bcc/ebpf 安装及示例（2019）](http://arthurchiao.art/blog/bcc-ebpf-tutorial-zh)
# 9 WASM(WebAssembly)
-------
[WebAssembly 中文网|Wasm 中文文档](https://www.wasm.com.cn)
## 9.1 Wasmtime
-------
2019 年, 英特尔、Mozilla 和红帽就启动了字节码联盟, 作为一项旨在促进"无处不在"运行 WebAssembly, 并将 WASM 的范围扩展到 Web 浏览器之外的倡议. 开发三年后(2022 年), WebAssembly 运行时 Wasmtime 1.0 发布了. 参见 phoronix 报道 [Wasmtime 1.0 Released - Bytecode Alliance Declares It Production Ready](https://www.phoronix.com/news/Wasmtime-1.0-Released).
Wasmtime 完全开源, 使用 Rust 编程语言, 是的, 并且符合 WASI 标准. Wasmtime还支持与 C/C++, Python, .NET, Go 和其他编程语言的集成, 同时在 Windows / Linux / macOS 平台上运行等等.
<br>
* 本作品/博文 ( [AderStep-紫夜阑珊-青伶巷草 Copyright ©2013-2017](http://blog.csdn.net/gatieme) ), 由 [成坚(gatieme)](http://blog.csdn.net/gatieme) 创作.
study/kernel/00-DESCRIPTION/DEBUGGING.md
+7 -3
View File
@@ -125,6 +125,9 @@ https://lwn.net/Articles/422487/
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2009/08/05 | Arjan van de Ven <arjan@infradead.org> | [Implement crashkernel=auto](https://lore.kernel.org/patchwork/cover/166256) | 实现 crashkernel=auto . | v1 ☐ | [PatchWork](https://lore.kernel.org/patchwork/cover/166256) |
| 2022/08/28 | Baoquan He <bhe@redhat.com> | [arm64, kdump: enforce to take 4G as the crashkernel low memory end](https://patchwork.kernel.org/project/linux-mm/cover/20220828005545.94389-1-bhe@redhat.com/) | 671768 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/20220828005545.94389-1-bhe@redhat.com) |
[crash extension modules](https://crash-utility.github.io/extensions.html)
# 5 REFCOUNT
@@ -166,14 +169,13 @@ Load Averages 是一项历史悠久的指标, 在 1973 年 8 月的 RFC 546 中
## 6.3 memory vmpressure
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2018/08/28 | Johannes Weiner <hannes@cmpxchg.org> | [psi: pressure stall information for CPU, memory, and IO v4](https://lwn.net/Articles/759781) | 引入 PSI 评估系统 CPU, MEMORY, IO 等资源的压力. | v4 ☑ [4.20-rc1](https://kernelnewbies.org/Linux_4.20#Core_.28various.29) | [LWN](https://lwn.net/Articles/544652), [](https://lkml.org/lkml/2013/2/10/140), [关键 commit](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=70ddf637eebe47e61fb2be08a59315581b6d2f38) |
| 2022/02/19 | Suren Baghdasaryan <surenb@google.com> | [[1/1] mm: count time in drain_all_pages during direct reclaimas memory pressure](https://patchwork.kernel.org/project/linux-mm/patch/20220219174940.2570901-1-surenb@google.com/) |615990 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220219174940.2570901-1-surenb@google.com) |
| 2022/09/10 | Christoph Hellwig <hch@lst.de> | [improve pagecache PSI annotations](https://lore.kernel.org/all/20220910065058.3303831-1-hch@lst.de) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20220910065058.3303831-1-hch@lst.de)<br>*-*-*-*-*-*-*-* <br>[LORE v2](https://lore.kernel.org/all/20220915094200.139713-1-hch@lst.de) |
## 6.4 PSI
## 6.4 PSI Core
-------
[知乎-兰新宇--Linux 的资源控制监测 - PSI [上]](https://zhuanlan.zhihu.com/p/523716850)
@@ -204,6 +206,8 @@ $reclaim = current\_mem \times reclaim\_ratio \times max(0,1 – \frac{psi_some}
| 2020/03/31 | Yafang Shao <laoar.shao@gmail.com> | [psi: enhance psi with the help of ebpf](https://lwn.net/Articles/1218304) | 引入 psi_memstall_type 标记 MEMSTALL 的类别, 并在 tracepoint 输出, 从而可以被 ebpf 使用来增强工具. | v4 ☑ [4.20-rc1](https://kernelnewbies.org/Linux_4.20#Core_.28various.29) | [Patchwork](https://lore.kernel.org/patchwork/patch/1218304) |
| 2022/07/21 | Chengming Zhou <zhouchengming@bytedance.com> | [sched/psi: some optimization and extension](https://lore.kernel.org/all/20220721040439.2651-1-zhouchengming@bytedance.com) | 优化 PSI 的性能, 同时增加对 IRQ/SOFTIRQ 的负载压力跟踪. | v1 ☐☑✓ | [LORE v1,0/9](https://lore.kernel.org/all/20220721040439.2651-1-zhouchengming@bytedance.com) |
| 2022/08/01 | CGEL <cgel.zte@gmail.com> | [[RFC,1/2] psi: introduce memory.pressure.stat](https://patchwork.kernel.org/project/linux-mm/patch/20220801004205.1593100-1-ran.xiaokai@zte.com.cn/) | 664363 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/20220801004205.1593100-1-ran.xiaokai@zte.com.cn) |
| 2022/09/10 | Christoph Hellwig <hch@lst.de> | [[1/5] mm: add PSI accounting around ->read_folio and ->readahead calls](https://patchwork.kernel.org/project/linux-mm/patch/20220910065058.3303831-2-hch@lst.de/) | 675899 | v1 ☐☑ | [LORE v1,0/5](https://lore.kernel.org/r/20220910065058.3303831-2-hch@lst.de) |
| 2022/09/15 | Christoph Hellwig <hch@lst.de> | [improve pagecache PSI annotations v2](https://lore.kernel.org/all/20220915094200.139713-1-hch@lst.de) | TODO | v2 ☐☑✓ | [LORE](https://lore.kernel.org/all/20220915094200.139713-1-hch@lst.de) |
# 7 DYNAMIC_DEBUG
study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md
+79 -12
View File
File diff suppressed because it is too large Load Diff
study/kernel/00-DESCRIPTION/SCHEDULER.md
+83 -4
View File
@@ -696,6 +696,16 @@ Chang 的 patch set 采用了与之前不同的方法: 允许 cgroup 将一些
| 2021/06/21 | JHuaixin Chang | [sched/fair: Burstable CFS bandwidth controller](https://lore.kernel.org/patchwork/cover/1396878) | 突发任务的带宽控制优化, 通过临时之前剩余累计的配额, 使得突发进程在当前周期的配额突然用尽之后, 还可以临时使用之前累计的配额使用, 从而降低突发任务的时延. | v6 ☑ 5.14-rc1 | [ 2020/12/17 v1](https://lore.kernel.org/patchwork/cover/1354613)<br>*-*-*-*-*-*-*-*<br>[2021/01/20 v2](https://lore.kernel.org/patchwork/cover/1368037)<br>*-*-*-*-*-*-*-*<br>[2021/01/21 v3](https://lore.kernel.org/patchwork/cover/1368746)<br>*-*-*-*-*-*-*-*<br>[2021-02-02 v4](https://lore.kernel.org/patchwork/cover/1396878)<br>*-*-*-*-*-*-*-*<br>[2021/05/20 v5](https://lore.kernel.org/patchwork/cover/1433660)<br>*-*-*-*-*-*-*-*<br>[2021/06/21 v6](https://lore.kernel.org/patchwork/cover/1449268)<br>*-*-*-*-*-*-*-*<br>[commit](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f4183717b370ad28dd0c0d74760142b20e6e7931) |
| 2021/08/30 | Huaixin Chang <changhuaixin@linux.alibaba.com> | [Add statistics and ducument for cfs bandwidth burst](https://lore.kernel.org/patchwork/cover/1396878) | 为 Burstable CFS bandwidth 添加统计信息和文档. | v1 ☑ 5.16-rc1 | [2020/12/17 v1](https://lore.kernel.org/patchwork/cover/1396878)<br>*-*-*-*-*-*-*-*<br>[2021/08/30 LORE v2 0/2](https://lore.kernel.org/all/20210830032215.16302-1-changhuaixin@linux.alibaba.com) |
| 2021/11/29 | Honglei Wang <wanghonglei@didichuxing.com> | [sched/fair: prevent cpu burst too many periods](https://lore.kernel.org/patchwork/cover/1396878) | commit f4183717b370 ("sched/fair: Introduce the burstable CFS controller") 引入了一个问题, 任务在持久性期间可能获得比配额更多的 cpu. 例如, 一个任务组的配额为每周期 100ms, 可以获得 100ms 突发, 其平均利用率约为每周期 105ms. 一旦这个组获得了一个空闲时间段, 它就有机会在公共带宽配置中获得超过其配额的 10 个或更多时间段的计算能力(例如, 100 毫秒作为时间段). 这意味着任务获得了可以 "偷走" 完成日常工作的能力, 因为所有任务都可以安排出去或睡觉, 以帮助团队获得空闲时间. cpu burst 的本来目的是帮助处理突发性工作负载. 但是, 如果一个任务组在没有突发性工作负载的情况下, 能够在持续时间内获得超过其配额的计算能力, 那么它违背了初衷. 此修补程序将突发限制为一个时段, 以便在很长时间内不会突破配额限制. 有了这个, 我们可以给任务组更多的 cpu 突发能力来处理真正的突发性工作负载, 而不必担心被恶意 "窃取". | v1 ☑ 5.16-rc1 | [LKML](https://lkml.org/lkml/2021/11/29/663) |
| 2022/05/18 | Fam Zheng <fam.zheng@bytedance.com> | [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.4 leaf_cfs_rq
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2022/05/26 | Chengming Zhou <zhouchengming@bytedance.com> | [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) |
## 2.2 实时进程的组调度支持(RT Group Scheduling)
@@ -1206,6 +1216,7 @@ enqueue_task()
| 2018/05/30 | Srikar Dronamraju <srikar@linux.vnet.ibm.com> | [Skip numa distance for offline nodes](https://lore.kernel.org/patchwork/patch/1433871) | NA | v1 ☐ | [LORE 0/3](https://lore.kernel.org/lkml/20210520154427.1041031-1-srikar@linux.vnet.ibm.com) |
| 2019/5/13 | Len Brown <len.brown@intel.com> | [v6 multi-die/package topology support](https://lore.kernel.org/patchwork/patch/1433871) | 支持 DIE 拓扑层级. | v6 ☑ 5.3-rc1 | [LKML 0/19](https://lkml.org/lkml/2019/5/13/768) |
| 2020/03/11 | Valentin Schneider <valentin.schneider@arm.com> | [sched: Instrument sched domain flags](https://lore.kernel.org/patchwork/cover/1224722) | 基于上一组补丁, 重构了 SD_FLAGS 的定义 | v4 ☑ 5.10-rc1 | [PatchWork v5,00/17](https://lore.kernel.org/patchwork/cover/1224722)<br>*-*-*-*-*-*-*-* <br>[LORE v6,00/17](https://lore.kernel.org/all/20200817113003.20802-1-valentin.schneider@arm.com) |
| 2022/07/04 | Sudeep Holla <sudeep.holla@arm.com> | [arch_topology: Updates to add socket support and fix cluster ids](https://lore.kernel.org/all/20220704101605.1318280-1-sudeep.holla@arm.com) | [Impact of recent CPU topology changes on Android's phantom domains](https://lpc.events/event/16/contributions/1342) | v6 ☐☑✓ | [LORE v6,0/21](https://lore.kernel.org/all/20220704101605.1318280-1-sudeep.holla@arm.com) |
### 4.1.2 3-hops 问题
@@ -3265,6 +3276,8 @@ v3.0 版本 [sched: Reduce runqueue lock contention -v6](https://git.kernel.org/
| 2013/08/09 | Oleg Nesterov <oleg@redhat.com> | [sched: fix the theoretical signal_wake_up() vs schedule() race](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e0acd0a68ec7dbf6b7a81a87a867ebd7ac9b76c4) | 20130812170257.GA32358@redhat.com | v1 ☑✓ 3.11-rc6 | [LORE v1](https://lore.kernel.org/lkml/20130812170257.GA32358@redhat.com) |
| 2015/08/03 | tip-bot for Peter Zijlstra <tipbot@zytor.com> | [sched: Introduce the 'trace_sched_waking' tracepoint](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fbd705a0c6184580d0e2fbcbd47a37b6e5822511) | NA | v1 ☑✓ 4.3-rc1 | [LORE](https://lore.kernel.org/all/tip-fbd705a0c6184580d0e2fbcbd47a37b6e5822511@git.kernel.org/) |
| 2020/05/24 | Mel Gorman | [Optimise try_to_wake_up() when wakee is descheduling](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=2ebb17717550607bcd85fb8cf7d24ac870e9d762) | 唤醒时如果 wakee 进程正在睡眠或者调度(释放 CPU), 优化在 on_cpu 的自旋等待时间 | v1 ☑ 5.8-rc1 | [LORE 0/2](https://lore.kernel.org/lkml/20200524202956.27665-1-mgorman@techsingularity.net) |
| 2022/08/24 | Peng Wang <rocking@linux.alibaba.com> | [sched/fair: select waker's cpu for wakee on sync wakeup](https://lore.kernel.org/all/1508aa17d1a169077c8d8d8c22d2bd529101af0e.1661313074.git.rocking@linux.alibaba.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/1508aa17d1a169077c8d8d8c22d2bd529101af0e.1661313074.git.rocking@linux.alibaba.com) |
| 2022/09/16 | Chen Yu <yu.c.chen@intel.com> | [sched/fair: Choose the CPU where short task is running during wake up](https://lore.kernel.org/all/20220915165407.1776363-1-yu.c.chen@intel.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20220915165407.1776363-1-yu.c.chen@intel.com) |
### 4.7.1.1 TTWU 中的内存屏障
@@ -4294,6 +4307,9 @@ Misfit Task 对调度器**负载均衡**做了如下改造, 参见 [commit cad68
### 7.2.5 Energy Model
-------
#### 7.2.5.1 Energy Model
-------
EAS 依赖于 EM(Energy Model) 提供的能效模型等信息来计算能效最优的调度行为.
v5.0 EAS 合入主线之前, 内核通过 init_sched_energy_costs() 解析 DTB 中 sched-energy-costs, freq-energy-model, busy-cost-data 等节点和字段来构建 CPU 的能效表.
@@ -4313,6 +4329,22 @@ v5.0 EAS 合入主线之后, 引入了 EM, 各平台或者设备通过 [em_dev_r
| 2021/08/12 | Viresh Kumar <viresh.kumar@linaro.org> | [Add callback to register with energy model](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=37f188318ea3f1da75b32df3b1a19f45d9840652) | TODO | v3 ☑✓ 5.15-rc1 | [LORE v3,0/9](https://lore.kernel.org/all/cover.1628742634.git.viresh.kumar@linaro.org) |
#### 7.2.5.2 Dynamic Energy Model to handle leakage power
-------
LPC-2022 [Dynamic Energy Model to handle leakage power](https://lpc.events/event/16/contributions/1341)
能量模型(EM) 框架描述 CPU 功率模型, 用于任务调度决策或热控制. 它是在启动期间以受支持的方式之一设置的, 并且在正常运行期间不会修改. 测试发现: 首先芯片的功耗也受其温度的影响,首先同样的 CPU 核即使同一个频点, 在不同温度下, 其功耗也存在差异, 因此不同温度下, CPU 核的能效曲线不同(温度越高, 功耗越高, 能效越差). 其次不同芯片(微架构/工艺)对温度的敏感度也不同, 因此不同温度下, 不同 CPU 核(大核/小核)的能效曲线变化也存在差异.
为了更好地解决诸如此类问题, ARM 提出希望允许在运行时修改EM. EM 运行时修改将引入新功能:
1. 允许提供(启动后)每个 OPP 的总功率值, 不限于任何公式或 DTS 数据.
2. 为芯片不同的工艺和集成方式, 允许提供适合的 SoC 的功率值.
3. 允许在运行时根据 SoC 的当前温度修改功率值, 因为与小核和中核相比, 大核的能效对温度更敏感.
### 7.2.6 IPA(Thermal 管控)
-------
@@ -4985,7 +5017,7 @@ PREEMPT-RT PATCH 的核心思想是最小化内核中不可抢占部分的代码
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2017/05/12 | Rohit Jain <rohit.k.jain@oracle.com> | [Interrupt Aware Scheduler](https://lkml.org/lkml/2017/5/12/512) | NA | v1 ☐ | [LORE 0/5](https://lore.kernel.org/lkml/1494612267-29465-1-git-send-email-rohit.k.jain@oracle.com) |
| 2021/09/20 | Libo Chen <libo.chen@oracle.com> | [Overeager pulling from wake_wide() in interrupt heavy workloads](https://lkml.org/lkml/2017/5/12/512) | 当前 wake_affine() 机制并不感知 ISR 唤醒的场景, 在这种场景下, 在中断上下文发起唤醒 wakee 进程的请求, 其实的 waker 并不是真正的 waker, 而是因为唤醒发生时中断正好打断了这个 waker 进程. wake_affine() 机制仍旧比较 waker/wakee 进程的 wakee_flips 到导致错误的唤醒. 作者讲了一个 IST 唤醒的场景, 导致 CPU 唤醒到中断所在的 NUMA NODE, 但是系统中其他 NODE 却是空闲的. | v1 ☐ | [Slide](https://linuxplumbersconf.org/event/11/contributions/1044/attachments/801/1508/lpc21_wakeup_pulling_libochen.pdf) |
| 2022/08/22 | John Stultz <jstultz@google.com> | [Softirq -rt Optimizations](https://lore.kernel.org/all/20220822190501.2171100-1-jstultz@google.com) | TODO | v2 ☐☑✓ | [LORE v2,0/2](https://lore.kernel.org/all/20220822190501.2171100-1-jstultz@google.com) |
| 2022/08/22 | John Stultz <jstultz@google.com> | [Softirq -rt Optimizations](https://lore.kernel.org/all/20220822190501.2171100-1-jstultz@google.com) | TODO | v2 ☐☑✓ | [LORE v2,0/2](https://lore.kernel.org/all/20220822190501.2171100-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[LORE v2,0/2](https://lore.kernel.org/all/20220822190501.2171100-1-jstultz@google.com) |
| 2020/12/04 | Thomas Gleixner <tglx@linutronix.de> | [softirq: Make it RT aware](https://lore.kernel.org/all/20201204170151.960336698@linutronix.de) | TODO | v2 ☐☑✓ | [LORE v2,0/9](https://lore.kernel.org/all/20201204170151.960336698@linutronix.de) |
@@ -5015,6 +5047,8 @@ PREEMPT-RT PATCH 的核心思想是最小化内核中不可抢占部分的代码
| 2020/05/18 | [The many faces of Latency nice](https://lwn.net/Articles/820659) | [LWN: Latency nice 的方方面面](https://blog.csdn.net/Linux_Everything/article/details/106435501) |
| 2022/03/17 | [Improved response times with latency nice](https://lwn.net/Articles/887842) | [LWN: 采用 latency nice 改善响应时间](https://blog.csdn.net/Linux_Everything/article/details/123887454) |
| 2022/04/05 | NA | 国内对这组补丁的分析 [latency-nice 优先级补丁源码分析](https://blog.csdn.net/qq_23662505/article/details/123977540) |
| 2022/09/13 | LPC-2022 上关于 latency nice 的演讲: [Latency hints for CFS task](https://lpc.events/event/16/contributions/1273) | NA |
2020 年, Parth Shah 提出了 latency nice 的概念. 旨在对应用的延迟进行感知和标记, 降低延迟敏感应用程序的调度延迟, 使其更快地获得 CPU 时间. latency_nice 值与现有 nice 值相对应, 介于 -20 和 19 之间. 数字越低, 优先级越高.
@@ -5049,7 +5083,7 @@ enqueue_task_fair()
|:-----:|:----:|:----:|:----:|:------------:|:----:|
| 2020/02/28 | Parth Shah <parth@linux.ibm.com> | [Introduce per-task latency_nice for scheduler hints](https://lore.kernel.org/all/20200228090755.22829-1-parth@linux.ibm.com) | 20200228090755.22829-1-parth@linux.ibm.com | v5 ☐☑✓ | [LORE v4,0/4](https://lore.kernel.org/lkml/20200224085918.16955-1-parth@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v5,0/4](https://lore.kernel.org/all/20200228090755.22829-1-parth@linux.ibm.com) |
| 2020/05/07 | Parth Shah <parth@linux.ibm.com> | [IDLE gating in presence of latency-sensitive tasks](https://lore.kernel.org/all/20200507133723.18325-1-parth@linux.ibm.com) | 20200507133723.18325-1-parth@linux.ibm.com | v1 ☐☑✓ | [LORE v1,0/4](https://lore.kernel.org/all/20200507133723.18325-1-parth@linux.ibm.com) |
| 2022/09/09 | Vincent Guittot <vincent.guittot@linaro.org> | [Add latency_nice priority](https://lore.kernel.org/all/20220311161406.23497-1-vincent.guittot@linaro.org) | 参见 [Improved response times with latency nice](https://lwn.net/Articles/887842). | v1 ☐☑✓ | [2022/03/11 LORE v1,0/6](https://lore.kernel.org/all/20220311161406.23497-1-vincent.guittot@linaro.org)<br>*-*-*-*-*-*-*-* <br>[2022/05/12 LORE v2,0/7](https://lore.kernel.org/all/20220512163534.2572-1-vincent.guittot@linaro.org)<br>*-*-*-*-*-*-*-* <br>[2022/09/09 LORE v3,0/8](https://lore.kernel.org/all/20220909130309.25458-1-vincent.guittot@linaro.org)<br>*-*-*-*-*-*-*-* <br>[LORE v4,0/8](https://lore.kernel.org/all/20220916080305.29574-1-vincent.guittot@linaro.org) |
| 2022/09/16 | Vincent Guittot <vincent.guittot@linaro.org> | [Add latency_nice priority](https://lore.kernel.org/all/20220311161406.23497-1-vincent.guittot@linaro.org) | 参见 [Improved response times with latency nice](https://lwn.net/Articles/887842). | v1 ☐☑✓ | [2022/03/11 LORE v1,0/6](https://lore.kernel.org/all/20220311161406.23497-1-vincent.guittot@linaro.org)<br>*-*-*-*-*-*-*-* <br>[2022/05/12 LORE v2,0/7](https://lore.kernel.org/all/20220512163534.2572-1-vincent.guittot@linaro.org)<br>*-*-*-*-*-*-*-* <br>[2022/09/09 LORE v3,0/8](https://lore.kernel.org/all/20220909130309.25458-1-vincent.guittot@linaro.org)<br>*-*-*-*-*-*-*-* <br>[2022/09/16 LORE v4,0/8](https://lore.kernel.org/all/20220916080305.29574-1-vincent.guittot@linaro.org) |
### 8.9.2 Xen CPU Scheduling
-------
@@ -5177,11 +5211,56 @@ CONFIG_HUAWEI_SCHED_VIP 被标记为 vip_prio, 为 VIP 线程提供了近似于
### 10.1.2 进程退出
-------
#### 10.1.2.1 进程退出时的处理
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2021/11/18 | Sebastian Andrzej Siewior <bigeasy@linutronix.de> | [kernel/fork: Move thread stack free otu of the scheduler path](https://lore.kernel.org/all/20211118143452.136421-1-bigeasy@linutronix.de) | [sched: Delay task stack freeing on RT](https://lore.kernel.org/all/20210928122411.593486363@linutronix.de) 的完善方案. 在 finish_task_switch() 完成后任务可能会死亡并退出, 这时候虽然快速回收任务堆栈有利于繁重的工作负载, 但这是内核实时性延迟的源头. 因此, 延迟启用 RT 的内核上的堆栈清理. | v1 ☐ | [PatchWork 0/8](https://lore.kernel.org/all/20211118143452.136421-1-bigeasy@linutronix.de) |
| 2021/11/18 | Sebastian Andrzej Siewior <bigeasy@linutronix.de> | [kernel/fork: Move thread stack free out of the scheduler path](https://lore.kernel.org/all/20211118143452.136421-1-bigeasy@linutronix.de) | [sched: Delay task stack freeing on RT](https://lore.kernel.org/all/20210928122411.593486363@linutronix.de) 的完善方案. 在 finish_task_switch() 完成后任务可能会死亡并退出, 这时候虽然快速回收任务堆栈有利于繁重的工作负载, 但这是内核实时性延迟的源头. 因此, 延迟启用 RT 的内核上的堆栈清理. | v1 ☐ | [PatchWork 0/8](https://lore.kernel.org/all/20211118143452.136421-1-bigeasy@linutronix.de) |
| 2021/11/18 | Linus Torvalds <torvalds@linux-foundation.org> | [task: Making tasks on the runqueue rcu protected](https://lore.kernel.org/all/20211118143452.136421-1-bigeasy@linutronix.de) | [sched: Delay task stack freeing on RT](https://lore.kernel.org/all/20210928122411.593486363@linutronix.de) 的完善方案. 在 finish_task_switch() 完成后任务可能会死亡并退出, 这时候虽然快速回收任务堆栈有利于繁重的工作负载, 但这是内核实时性延迟的源头. 因此, 延迟启用 RT 的内核上的堆栈清理. | v1 ☐ | [PatchWork 0/8](https://lore.kernel.org/all/20211118143452.136421-1-bigeasy@linutronix.de) |
#### 10.1.2.2 reaper 进程
-------
linux 下, reaper 线程用于释放已经执行结束的线程所占用的资源. 通常这个工作由父进程通过 wait() 或者 waitpid() 完成. 在 linux 中, 父进程死亡后, 需要由其他 reaper 进程来完成这项工作. 粗略地说:
1. 如果父亲还有其他活着的线索, 这条线索就是 reaper.
2. 否则, 如果有一个父亲的祖先(中间没有 pidns 级别变化), 同时它有 PR_SET_CHILD_SUBREAPER 设置, 这个祖先将是一个 reaper.
3. 否则, 父亲的祖先将成为孩子们的 reaper.
### 10.1.3 进程冻结与恢复
-------
CRIU 是一个在 Linux 用户空间 (userspace) 上实现了 checkpoint/restore 功能的软件工具.
Checkpoint/Restore In Userspace 或者 CRIU 是一个软件工具, 通过使用这个工具, 你可以冻结或者部分冻结一个应用程序的执行, 并将其执行状态保存到磁盘中一系列文件中. 你可以使用这些文件来恢复继续运行这个应用程序, 从之前被冻结的点上开始执行. 与其他软件不同的是 CRIU 最大的特点是在用户空间中执行.
对于 CRIU 来说, 社区传统的 reaper 管理方式存在较多问题. 当 CRIU 开始转储进程时, 它不知道进程及其资源的创建顺序. 进程可以拥有以下资源:
a. 只能在克隆进程时继承;
b. 只能由特定进程创建;
c. 在多个进程之间共享(例如进程会话).
对于这样的资源, CRIU 恢复需要重新创建这样的进程创建顺序, 同时创建所需的进程树拓扑并允许继承所有资源.
当进程重养育涉及到子-子-收割者时, 可以在进程树中大量混合进程, 这样就不容易明显地恢复一切正确.
所以我们引入 CABD(最近的在世后代) 来帮助 CRIU 克服这个问题:
我们希望将流程放到另一个树中——CABA树. 这棵树不会以任何方式影响重新养育或进程创建, 只是向 CRIU 提供了一个新信息, 以便我们可以了解重新养育的子进程是从哪里被重新养育的. 尽管原来的父进程已经死亡, 可能也是父进程的父进程, 但我们仍然可以获得关于仍然活着的进程的信息, 它最初是进程序列(已经死亡的进程)的父进程, 它通向我们—— CABA.
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2022/09/08 | Pavel Tikhomirov <ptikhomirov@virtuozzo.com> | [Add CABA tree to task_struct](https://patchwork.kernel.org/project/linux-mm/patch/20220908220944.822942-1-ptikhomirov@virtuozzo.com) | 675404 | v4 ☐☑ | [LORE v4,0/2](https://lore.kernel.org/all/20220908220944.822942-1-ptikhomirov@virtuozzo.com) |
## 10.3 IPC
-------
@@ -5394,7 +5473,7 @@ B 站 Plugsched 介绍视频 [纯干货解读：Plugsched, 首次实现 Linux ke
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2022/09/08 | Waiman Long <longman@redhat.com> | [sched: Persistent user requested affinity](https://lore.kernel.org/all/20220908194121.858462-1-longman@redhat.com) | COMMIT b90ca8badbd1 ("sched: Introduce task_struct::user_cpus_ptr to track requested affinity") 引入了 user_cpus_ptr (狭义地)来保持 CPU 的亲和性不受非对称 CPU 设置的影响.<br>该补丁集扩展了 user_cpus_ptr, 通过 sched_setaffinity() API 存储用户请求的 CPU 亲和性. 有了这些可用的信息, 它将使 cpuset 和 set_cpus_allowed_ptr() 的其他调用者(如 HOTPLUG)能够在当前 cpuset 的 CPUs 约束内保持 CPU 的亲和性尽可能接近用户想要的. 否则, CPU 层次结构的更改或热插拔事件可能会将受影响 CPU 集中的任务的 cpumask 重置为默认的 cpuset cpus 值, 即使这些任务具有用户之前显式设置的 CPU 亲和性.<br>这还意味着, 成功调用 sched_setaffinity() 之后, user_cpus_ptr 将继续分配, 直到任务退出, 除非在一些罕见的情况下. | v8 ☐☑✓ | [LORE v8,0/7](https://lore.kernel.org/all/20220908194121.858462-1-longman@redhat.com) |
| 2022/09/08 | Waiman Long <longman@redhat.com> | [sched: Persistent user requested affinity](https://lore.kernel.org/all/20220908194121.858462-1-longman@redhat.com) | COMMIT b90ca8badbd1 ("sched: Introduce task_struct::user_cpus_ptr to track requested affinity") 引入了 user_cpus_ptr (狭义地)来保持 CPU 的亲和性不受非对称 CPU 设置的影响.<br>该补丁集扩展了 user_cpus_ptr, 通过 sched_setaffinity() API 存储用户请求的 CPU 亲和性. 有了这些可用的信息, 它将使 cpuset 和 set_cpus_allowed_ptr() 的其他调用者(如 HOTPLUG)能够在当前 cpuset 的 CPUs 约束内保持 CPU 的亲和性尽可能接近用户想要的. 否则, CPU 层次结构的更改或热插拔事件可能会将受影响 CPU 集中的任务的 cpumask 重置为默认的 cpuset cpus 值, 即使这些任务具有用户之前显式设置的 CPU 亲和性.<br>这还意味着, 成功调用 sched_setaffinity() 之后, user_cpus_ptr 将继续分配, 直到任务退出, 除非在一些罕见的情况下. | v8 ☐☑✓ | [LORE v8,0/7](https://lore.kernel.org/all/20220908194121.858462-1-longman@redhat.com)<br>*-*-*-*-*-*-*-* <br>[LORE v9,0/7](https://lore.kernel.org/all/20220916183217.1172225-1-longman@redhat.com)<br>*-*-*-*-*-*-*-* <br>[LORE v10,0/5](https://lore.kernel.org/all/20220922180041.1768141-1-longman@redhat.com) |
## 11.5 其他
study/kernel/00-DESCRIPTION/VIRT.md
+11
View File
@@ -182,6 +182,17 @@ Anbox 使用 Linux 命名空间 (user, pid, uts, net, mount, ipc) 在容器中
[Android apps on Linux with Waydroid](https://lwn.net/Articles/901459)
# 8 MEMORY
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2022/08/23 | Yosry Ahmed <yosryahmed@google.com> | [KVM: mm: count KVM mmu usage in memory stats](https://patchwork.kernel.org/project/linux-mm/cover/20220823004639.2387269-1-yosryahmed@google.com/) | 669960 | v7 ☐☑ | [LORE v7,0/4](https://lore.kernel.org/r/20220823004639.2387269-1-yosryahmed@google.com) |
| 2022/09/15 | Chao Peng <chao.p.peng@linux.intel.com> | [KVM: mm: fd-based approach for supporting KVM](https://patchwork.kernel.org/project/linux-mm/cover/20220915142913.2213336-1-chao.p.peng@linux.intel.com/) | 677360 | v8 ☐☑ | [LORE v8,0/8](https://lore.kernel.org/r/20220915142913.2213336-1-chao.p.peng@linux.intel.com) |
<br>
* 本作品/博文 ( [AderStep-紫夜阑珊-青伶巷草 Copyright ©2013-2017](http://blog.csdn.net/gatieme) ), 由 [成坚(gatieme)](http://blog.csdn.net/gatieme) 创作.