From a25cc0fddc379871f4cf46774cb84d69c873a1b0 Mon Sep 17 00:00:00 2001 From: Cheng Jian Date: Sun, 4 Jun 2023 17:49:37 +0800 Subject: [PATCH] description/scheduler: EEVDF --- study/kernel/00-DESCRIPTION/LOCKING.md | 1 + study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md | 18 ++++++++++- study/kernel/00-DESCRIPTION/SCHEDULER.md | 30 +++++++++++++++---- study/kernel/00-DESCRIPTION/TODO.md | 5 ++-- study/kernel/00-DESCRIPTION/TOOLS.md | 2 ++ 5 files changed, 47 insertions(+), 9 deletions(-) diff --git a/study/kernel/00-DESCRIPTION/LOCKING.md b/study/kernel/00-DESCRIPTION/LOCKING.md index ce08942..be99278 100644 --- a/study/kernel/00-DESCRIPTION/LOCKING.md +++ b/study/kernel/00-DESCRIPTION/LOCKING.md @@ -445,6 +445,7 @@ Peter Zijlstra 在 [RT-Summit 2017](https://wiki.linuxfoundation.org/realtime/ev | 2018/10/09 | Juri Lelli | [Towards implementing proxy execution](https://lore.kernel.org/all/20181009092434.26221-1-juri.lelli@redhat.com) | TODO | v1 ☐☑✓ | [LORE v1,0/8](https://lore.kernel.org/all/20181009092434.26221-1-juri.lelli@redhat.com) | | 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 v3](https://lore.kernel.org/all/20230601055846.2349566-1-jstultz@google.com) | TODO | v3 ☐☑✓ | [LORE v3,0/13](https://lore.kernel.org/all/20230601055846.2349566-1-jstultz@google.com) | # 12 深入理解并行编程 diff --git a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md index dc513a4..1ee1377 100644 --- a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md +++ b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md @@ -539,6 +539,11 @@ MADV_PAGEOUT 在某种程度上类似于 MADV_DONTNEED, 它提示内核当前不 |:----:|:----:|:---:|:----:|:---------:|:----:| | 2023/01/01 | Jason A. Donenfeld | [[v14,2/7] mm: add VM_DROPPABLE for designating always lazily freeable mappings](https://patchwork.kernel.org/project/linux-mm/patch/20230101162910.710293-3-Jason@zx2c4.com/) | 708127 | v14 ☐☑ | [LORE v14,0/7](https://lore.kernel.org/r/20230101162910.710293-3-Jason@zx2c4.com) | +### 1.6.7 Optimizing single-owner memory +------- + +[Optimizing single-owner memory](https://lwn.net/Articles/932391) + ## 1.7 page table pages ------- @@ -608,6 +613,10 @@ github 地址: [Mitosis Project](https://github.com/mitosis-project), [linux 内 | 2021 | [Fast Local Page-Tables for Virtualized NUMA Servers with vMitosis; April, 2021; asplos21_vmitosis.pdf](https://research.vmware.com/files/attachments/0/0/0/0/1/3/8/asplos21_vmitosis.pdf)
[Fast Local Page-Tables for Virtualized NUMA Servers with vMitosis; April, 2021; vmitosis_ext_abstract.pdf](https://research.vmware.com/files/attachments/0/0/0/0/1/3/1/vmitosis_ext_abstract.pdf) | +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:----:|:---------:|:----:| +| 2023/05/30 | Russell King (Oracle) | [arm64 kernel text replication](https://lore.kernel.org/all/ZHYCUVa8fzmB4XZV@shell.armlinux.org.uk) | NUMA 系统在跨节点访问数据和指令时具有更大的延迟, 这可能导致主要执行本地节点以外访问的 CPU 核心的性能降低. 通常情况下, 当 ARM64 系统启动时, 内核最终会被放置在内存中, 每个 CPU 内核都必须从内核所在的 NUMA 节点中获取指令和数据. 这意味着在执行内核代码时, 该节点本地的 CPU 将比远程节点中的 CPU 运行得更快. 访问远程 NUMA 节点内存的延迟越高, 这些节点上的内核性能就越差.
如果每个节点的 RAM 中都有内核文本的本地副本, 并且每个节点都使用其内核文本的局部副本运行内核, 那么理所当然的是, 在从远程内存获取指令时, 内核将运行得更快, 因为 STALL 更少. | v1 ☐☑✓ | [LORE v1,0/17](https://lore.kernel.org/all/ZHYCUVa8fzmB4XZV@shell.armlinux.org.uk) | + ### 1.7.5 Shared Page Table ------- @@ -723,7 +732,7 @@ MTE 实现了锁和密钥访问内存. 这样在内存访问期间, 可以在内 ## 1.9 page attributes ------- -## 1.9.1 CPA(Change Page Attribute) +### 1.9.1 CPA(Change Page Attribute) ------- | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | @@ -5688,6 +5697,7 @@ Dirty COW(CVE-2016-5195) 是近几年影响比较严重的问题, 参见 [Dirty | 2021 年 | [Introducing maple trees](https://lwn.net/Articles/845507) | | 2021 年 | [LSF/MM TOPIC] mmap locking topics](https://www.spinics.net/lists/linux-mm/msg258803.html) | | 2022 年 | [The ongoing search for mmap_lock scalability](https://lwn.net/Articles/893906)
LPC-2022 [Scalability solutions for the mmap_lock - Maple Tree and per-VMA locks](https://lpc.events/event/16/contributions/1271) | +| 2023 年 | [Improving page-fault scalability](https://lwn.net/Articles/932298) 和 [Mitigating vmap lock contention](https://lwn.net/Articles/932396) | #### 8.2.5.1 SPF(Speculative page faults) ------- @@ -7426,6 +7436,8 @@ OS 判断如果是在用户态触发这个硬件内存错误时, 处理方式是 ## 14.7 ASLR ------- +[万字长文---手把手教你加固内核安全配置](https://blog.csdn.net/weixin_42135087/article/details/126658723) + ### 14.7.1 ASLR(User Space) ------- @@ -7737,6 +7749,10 @@ ZONE_MOVABLE 一个 pseudo zone, 它实际是从内核划分的某个 zone 中 并提供代码标记的几个应用程序, 提供内存分配跟踪 (Memory allocation tracking)、动态故障注入(Dynamic fault injection)、延迟跟踪(Latency tracking) 和改进的错误代码报告(Improved error codes). +[Code tagging and memory-allocation profiling](https://lwn.net/Articles/932402) + +[A framework for code tagging](https://lwn.net/Articles/906660) + | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:---:|:----:|:---:|:----:|:---------:|:----:| | 2022/08/30 | Suren Baghdasaryan | [Code tagging framework and applications](https://lore.kernel.org/all/20220830214919.53220-1-surenb@google.com) | TODO | v1 ☐☑✓ | [LORE v1,0/30](https://lore.kernel.org/all/20220830214919.53220-1-surenb@google.com) | diff --git a/study/kernel/00-DESCRIPTION/SCHEDULER.md b/study/kernel/00-DESCRIPTION/SCHEDULER.md index 81d0d53..085346f 100644 --- a/study/kernel/00-DESCRIPTION/SCHEDULER.md +++ b/study/kernel/00-DESCRIPTION/SCHEDULER.md @@ -595,7 +595,7 @@ coscheduling 协同调度是为了解决云服务场景, 为不同用户提供 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| -| 2018/09/07 | Jan H. Schönherr | [[RFC,00/60] Coscheduling for Linux](https://lore.kernel.org/lkml/20180907214047.26914-1-jschoenh@amazon.de) | 亚马逊的协同调度方案 | RFC ☐ | [LORE RFC,00/60](https://lore.kernel.org/lkml/20180907214047.26914-1-jschoenh@amazon.de) | +| 2018/09/07 | Jan H. Schönherr | [[RFC,00/60] Coscheduling for Linux](https://lore.kernel.org/lkml/20180907214047.26914-1-jschoenh@amazon.de) | 亚马逊的协同调度方案. 参见 LWN 报道 [Coscheduling: simultaneous scheduling in control groups](https://lwn.net/Articles/764482) 以及 [Linux Coscheduling调度器简介](https://blog.csdn.net/dog250/article/details/101752290). | RFC ☐ | [LORE RFC,00/60](https://lore.kernel.org/lkml/20180907214047.26914-1-jschoenh@amazon.de) | | 2019/02/18 | Peter & Kirill Tkhai 等 | [Core scheduling](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=67692435c411e5c53a1c588ecca2037aebd81f2e) | 核调度器, 限制同一个 SMT 域内的两个 CPU 只能运行同一组进程.
1. v3 合入了 8 个重构的补丁.
2. | v9 ☑ 5.4-rc1 | [2019/02/18 LORE RFC](https://lore.kernel.org/lkml/20190218165620.383905466@infradead.org)
*-*-*-*-*-*-*-*
[2019/04/23 LORE v2,00/17](https://lore.kernel.org/lkml/cover.1556025155.git.vpillai@digitalocean.com)
*-*-*-*-*-*-*-*
[2019/05/29 LORE v3,00/16](https://lore.kernel.org/all/cover.1559129225.git.vpillai@digitalocean.com)
*-*-*-*-*-*-*-*
[2019/10/30 LORE v4,00/19](https://lore.kernel.org/lkml/cover.1572437285.git.vpillai@digitalocean.com)
*-*-*-*-*-*-*-*
[2020/03/04 LORE v5,00/13](https://lore.kernel.org/lkml/cover.1583332764.git.vpillai@digitalocean.com)
*-*-*-*-*-*-*-*
[2020/06/30 LORE v6,00/16](https://lore.kernel.org/lkml/cover.1593530334.git.vpillai@digitalocean.com)
*-*-*-*-*-*-*-*
[2020/08/28 LORE v7,00/23](https://lore.kernel.org/lkml/cover.1598643276.git.jdesfossez@digitalocean.com)
*-*-*-*-*-*-*-*
[2020/10/19 LORE v8,00/26](https://lore.kernel.org/lkml/20201020014336.2076526-1-joel@joelfernandes.org)
*-*-*-*-*-*-*-*
[2020/11/17 LORE v9,00/32](https://lore.kernel.org/lkml/20201117232003.3580179-1-joel@joelfernandes.org) | | 2021/03/25 | Joel Fernandes 等 | [Core scheduling remaining patches rebase](https://lore.kernel.org/patchwork/cover/1369931) | Core scheduling v9 的大部分补丁都已经在 TIP 分支了, 部分未合入补丁的重构与适配. | v10 ☐ | [2021/01/23 LORE v10,0/5](https://lore.kernel.org/lkml/20210123011704.1901835-1-joel@joelfernandes.org)
*-*-*-*-*-*-*-*
[2021/03/24 LORE v10 resend,0/8](https://lore.kernel.org/lkml/20210324214020.34142-1-joel@joelfernandes.org) | | 2021/04/01 | Peter Zijlstra | [sched: Core scheduling interfaces](https://lore.kernel.org/lkml/20210401131012.395311786@infradead.org/) | Peter 将 TIP 分支 core scheduling 进行了重构. 重新设计了 Core scheduling 的接口. | v11 ☐ |[2021/04/01 v11,0/9](https://lore.kernel.org/lkml/20210401131012.395311786@infradead.org) | @@ -3797,8 +3797,8 @@ Oracle 数据库具有类似的虚拟化功能, 称为 Oracle Multitenant, 其 调度器最核心的工作就两个内容 : -- [x] ** 选进程 **: 选择下一个更合适的进程 **pick_next_task** -- [x] ** 选核 **: 为某个进程选择更合适的 CPU 运行 **select_task_rq** +- [x] ** 选进程 **: 选择下一个更合适的进程 pick_next_task/Pick Next/Task Selection +- [x] ** 选核 **: 为某个进程选择更合适的 CPU 运行 select_task_rq/Task Placement 所有其他的机制都是直接或者间接服务这两个终极任务的. @@ -4015,6 +4015,7 @@ y = (1 - \frac{pct^{2}}{10000^{2}} \times x^{2}) \times llc\_weight | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:----:|:---:|:----------:|:---:| | 2021/12/01 | Mel Gorman | [Adjust NUMA imbalance for multiple LLCs](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=e496132ebedd870b67f1f6d2428f9bb9d7ae27fd) | [commit 7d2b5dd0bcc4 ("sched/numa: Allow a floating imbalance between NUMA nodes")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7d2b5dd0bcc4) 允许 NUMA 节点之间的不平衡, 这样通信任务不会被 load balance 分开. 当 LLC 和 node 之间有 1:1 的关系时, 这种方法可以很好地工作, 但是对于多个 LLC, 如果独立的任务过早地使用 CPU 共享缓存, 这种方法就不太理想了. 本系列解决了两个问题:
1. 调度程序域权重的使用不一致, 以及当每个 NUMA 节点有许多 LLC 时性能不佳. NUMA 之间允许的不均衡的进程数目不再是一个固定的值 NUMA_IMBALANCE_MIN(2), 而是在 build_sched_domains() 中实际探测 NUMA 域下辖的 LLC 的数目, 作为 sd->imb_numa_nr. | v4 ☑✓ 5.18-rc1 | [PatchWork v3,0/2](https://lore.kernel.org/lkml/20211201151844.20488-1-mgorman@techsingularity.net)
*-*-*-*-*-*-*-*
[LORE v4,0/2](https://lore.kernel.org/lkml/20211210093307.31701-1-mgorman@techsingularity.net)
*-*-*-*-*-*-*-*
[LORE v6,0/2](https://lore.kernel.org/all/20220208094334.16379-1-mgorman@techsingularity.net) | +| 2023/05/30 | Peter Zijlstra | [sched/fair: Multi-LLC select_idle_sibling()](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c7dfd6b9122d29d0e9a4587ab470c0564d7f92ab) | Tejun 报告: Zen2 机器上有 4 LLC, 每个 LLC 上 3 个 core 的机器时, 发现系统很繁忙的情况下仍然出现大量 CPU 空间.
分析发现, 这是因为 select_idle_sibling() 不会考虑本地 LLC 之外的任何事情, 而且由于所有这些任务都是短时间运行的, 所以周期性空闲负载平衡器失效了.
虽然将工作缓存保存在本地很好, 但最好不要有大量的空闲时间. 因此, 当本地的 LLC 为空时, 让 select_idle_sibling() 尝试在同一节点内的其他 LLC. 参见 phoronix 的报道 [Linux 6.5 Scheduler Patch Will To Help AMD Systems With Multiple LLCs Per Die](https://www.phoronix.com/news/Multi-LLC-Select-Idle-Sibling). | v1 ☐☑✓ | [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c7dfd6b9122d29d0e9a4587ab470c0564d7f92ab) | ## 5.6 相关学术研究 @@ -5707,7 +5708,7 @@ PREEMPT-RT PATCH 的核心思想是最小化内核中不可抢占部分的代码 之前已经使用了许多方法来尝试改进重要进程的响应时间, 例如, 可以使用传统的 nice 值来提高进程的优先级, 这是可行的, 但是进程的友好性并不直接转化为延迟; 它控制进程可用的 CPU 时间的消耗, 但不能控制进程的调度延迟. 使用实时优先级将使调度程序快速运行进程, 解决进程的时延诉求. 但是也存在诸多问题. -### 8.9.1 latency_nice +### 8.9.1 Latency Nice & EEVDF ------- | 日期 | LWN | 翻译 | @@ -5717,7 +5718,11 @@ PREEMPT-RT PATCH 的核心思想是最小化内核中不可抢占部分的代码 | 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 | -| 2023/03/09 | [An EEVDF CPU scheduler for Linux](https://lwn.net/Articles/925371) | +| 2023/03/09 | [An EEVDF CPU scheduler for Linux](https://lwn.net/Articles/925371), 论文 [Earliest Eligible Virtual Deadline First A Flexible](https://people.eecs.berkeley.edu/~istoica/papers/eevdf-tr-95.pdf), [翻译-LWN：Linux 新的 EEVDF 调度器!](https://blog.csdn.net/Linux_Everything/article/details/129807209), [Updated EEVDF Linux CPU Scheduler Patches Posted That Plan To Replace CFS](https://www.phoronix.com/news/EEVDF-Scheduler-Linux-EO-May) | + + +#### 8.9.1.1 Latency Nice +------- 2020 年, Parth Shah 提出了 latency nice 的概念. 旨在对应用的延迟进行感知和标记, 降低延迟敏感应用程序的调度延迟, 使其更快地获得 CPU 时间. latency_nice 值与现有 nice 值相对应, 介于 -20 和 19 之间. 数字越低, 优先级越高. @@ -5768,8 +5773,17 @@ enqueue_task_fair() |:-----:|:----:|:----:|:----:|:------------:|:----:| | 2020/02/28 | Parth Shah | [Introduce per-task latency_nice for scheduler hints](https://lore.kernel.org/all/20200228090755.22829-1-parth@linux.ibm.com) | 20200228090755.22829-1-parth@linux.ibm.com | v5 ☐☑✓ | [LORE v4,0/4](https://lore.kernel.org/lkml/20200224085918.16955-1-parth@linux.ibm.com)
*-*-*-*-*-*-*-*
[LORE v5,0/4](https://lore.kernel.org/all/20200228090755.22829-1-parth@linux.ibm.com) | | 2020/05/07 | Parth Shah | [IDLE gating in presence of latency-sensitive tasks](https://lore.kernel.org/all/20200507133723.18325-1-parth@linux.ibm.com) | 20200507133723.18325-1-parth@linux.ibm.com | v1 ☐☑✓ | [LORE v1,0/4](https://lore.kernel.org/all/20200507133723.18325-1-parth@linux.ibm.com) | -| 2022/09/16 | Vincent Guittot | [Add latency_nice priority](https://lore.kernel.org/all/20220311161406.23497-1-vincent.guittot@linaro.org) | 参见 [Improved response times with latency nice](https://lwn.net/Articles/887842). | v1 ☐☑✓ | [2022/03/11 LORE v1,0/6](https://lore.kernel.org/all/20220311161406.23497-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/05/12 LORE v2,0/7](https://lore.kernel.org/all/20220512163534.2572-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/09/09 LORE v3,0/8](https://lore.kernel.org/all/20220909130309.25458-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/09/16 LORE v4,0/8](https://lore.kernel.org/all/20220916080305.29574-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/09/25 LORE v5,0/8](https://lore.kernel.org/all/20220925143908.10846-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/10/28 LORE v6,0/9](https://lore.kernel.org/all/20221028073637.31195-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/10/28 LORE v7,0/9](https://lore.kernel.org/all/20221028093403.6673-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/11/10 LORE v8,0/9](https://lore.kernel.org/all/20221110175009.18458-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/11/15 LORE v9,0/9](https://lore.kernel.org/all/20221115171851.835-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2023/01/13 LORE v10,0/9](https://lore.kernel.org/all/20230113141234.260128-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2023/02/23 LORE v11,0/9](https://lore.kernel.org/all/20230223191041.577305-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2023/02/24 LORE v12,0/8](https://lore.kernel.org/all/20230224093454.956298-1-vincent.guittot@linaro.org/) | +| 2022/09/16 | Vincent Guittot | [Add latency_nice priority](https://lore.kernel.org/all/20220311161406.23497-1-vincent.guittot@linaro.org) | 参见 [Improved response times with latency nice](https://lwn.net/Articles/887842). | v1 ☐☑✓ | [2022/03/11 LORE v1,0/6](https://lore.kernel.org/all/20220311161406.23497-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/05/12 LORE v2,0/7](https://lore.kernel.org/all/20220512163534.2572-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/09/09 LORE v3,0/8](https://lore.kernel.org/all/20220909130309.25458-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/09/16 LORE v4,0/8](https://lore.kernel.org/all/20220916080305.29574-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/09/25 LORE v5,0/8](https://lore.kernel.org/all/20220925143908.10846-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/10/28 LORE v6,0/9](https://lore.kernel.org/all/20221028073637.31195-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/10/28 LORE v7,0/9](https://lore.kernel.org/all/20221028093403.6673-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/11/10 LORE v8,0/9](https://lore.kernel.org/all/20221110175009.18458-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2022/11/15 LORE v9,0/9](https://lore.kernel.org/all/20221115171851.835-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2023/01/13 LORE v10,0/9](https://lore.kernel.org/all/20230113141234.260128-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2023/02/23 LORE v11,0/9](https://lore.kernel.org/all/20230223191041.577305-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2023/02/24 LORE v12,0/8](https://lore.kernel.org/all/20230224093454.956298-1-vincent.guittot@linaro.org) | + + + +#### 8.9.1.2 EEVDF +------- + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:-----:|:----:|:----:|:----:|:------------:|:----:| | 2023/03/28 | Peter Zijlstra | [sched: EEVDF using latency-nice](https://lore.kernel.org/all/20230328092622.062917921@infradead.org) | TODO | 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/05/31 | Peter Zijlstra | [sched: EEVDF and latency-nice and/or slice-attr](https://lore.kernel.org/all/20230531115839.089944915@infradead.org) | TODO | v1 ☐☑✓ | [LORE v1,0/15](https://lore.kernel.org/all/20230531115839.089944915@infradead.org) | ### 8.9.2 Xen CPU Scheduling @@ -6255,6 +6269,10 @@ B 站 Plugsched 介绍视频 [纯干货解读：Plugsched, 首次实现 Linux ke | [CacULE CPU Scheduler](https://github.com/hamadmarri/cacule-cpu-scheduler) | 是基于交互性评分机制 (CacULE Interactivity Score) 的 CFS 补丁集. 交互性分数的灵感来自 FreeBSD 的 ULE 调度器, 可以增强系统响应能力 / 延迟. ARCHLINUX 的开发者 ptr1337, 同样移植了 [CacULE Scheduler](https://github.com/ptr1337/linux-cacule), [CachyOS/linux-cachyos](https://github.com/CachyOS/linux-cachyos). 使用 calc_interactivity(), calc_cache_score(), calc_starve_score() 分别计算任务的交互性评分 (Interactivity Score), 缓存亲和性评分(Cache Score) 以及饥饿评分(Starve Score), 然后将 CFS 的选取下一个任务机制 pick_next_task_fair 更改为 ULE 的评分机制, 以便选取要运行的下一个任务. | | [Task Type(TT) CPU Scheduler](https://github.com/hamadmarri/TT-CPU-Scheduler) | 根据任务的行为检测并识别任务类型, 并根据其类型控制调度. 基于任务类型的好处是允许调度程序进行更多控制, 并选择接下来在 CPU 中运行的最佳任务. 当前有 5 种类型: 实时(REALTIME), 交互(INTERACTIVE), 无类型(NO_TYPE), 计算密集型(CPU_BOUND), 批处理(BATCH). 调度器通过 detect_type() 周期性地探测应用的 task_type. | | [Baby-CPU-Scheduler](https://github.com/hamadmarri/Baby-CPU-Scheduler) | 一个非常基本, 轻量级但性能非常高的调度器 Basic Scheduler (BS). 可以将其用作 Linux 上的基本调度程序进行学习 | +| [Burst-Oriented Response Enhancer (BORE) CPU Scheduler](https://github.com/firelzrd/bore-scheduler) | BORE(面向突发的响应增强器)是 CFS(完全公平调度程序)的增强版本, CFS 是 Linux 中默认的 CPU 调度程序, 旨在保持 CFS 的高吞吐量性能, 同时在尽可能宽的负载情况下提供对用户输入的更高响应能力. 为了实现这一目标, BORE 为每个单独的任务引入了一个称为 "突发性" 的灵活性维度, 部分偏离了 CFS 固有的 "完全公平" 原则. 延迟是指任务在显式放弃后通过进入睡眠、IO 等待或屈服而消耗的累积 CPU 时间得出的分数. 该分数代表了广泛的时间特征, 从纳秒到数百秒不等, 在不同的任务中有所不同. | +| [Multiple run-queues for BFS](https://lore.kernel.org/all/1355591803.23863.3.camel@findus-T530) | [两个非常有意思的适合桌面使用的Linux task调度器: BFS和MuqSS](https://blog.csdn.net/juS3Ve/article/details/102380529)
[操作系统调度算法5——MuQss，多队列跳表调度器](https://zhuanlan.zhihu.com/p/373693657), [ckolivas/linux](https://github.com/ckolivas/linux), [CK 的博客](http://ck-hack.blogspot.com). [细说CFS与MuQSS以及load-balance](https://blog.csdn.net/qq_23662505/article/details/120220689), [MuQSS_调度器-The_MuQSS_CPU_scheduler](https://github.com/jiebaomaster/linux-kernel-doc-translate/blob/master/lwn/MuQSS_调度器-The_MuQSS_CPU_scheduler.md) | + + #### 11.2.5.2 User Sensitive Factors for Scheduler ------- diff --git a/study/kernel/00-DESCRIPTION/TODO.md b/study/kernel/00-DESCRIPTION/TODO.md index 26af51f..b47dc70 100644 --- a/study/kernel/00-DESCRIPTION/TODO.md +++ b/study/kernel/00-DESCRIPTION/TODO.md @@ -459,14 +459,15 @@ kagi.com/summarizer [Memory passthrough for virtual machines](https://lwn.net/Articles/931933) - +[Memory-management documentation and development process](https://lwn.net/Articles/932398/) BPF verifiery 已经做了很多工作来尽量确保加载进 kernel 的 BPF program 是不会导致安全问题的. 包括检查 memory 的访问, 以及模拟执行流程来确保 program 会在有限时间内结束, 等等. 其中很多检查都有助于确保 program 是安全的, 能避免某些类型的 bug, 其他的检查都是专门为了排查恶意 program 的, 如果 kernel 允许接受非特权用户的 BPF program 的话, 这些检查都是必须的. 大多数这类恶意 program 的检查工作都是在 2015 年的 4.4 kernel 里实现的. 尤其是其中很多工作是为了阻止 BPF program 把 kernel 指针值泄露给 user space. 这些指针对攻击者会很有用, 因为他们可以被用来推算出某些特定的数据结构或者代码的位置. 所以我们一定要避免被非特权的进程拿到这些指针数据. 在 kernel 4.7 里面 - 其他还有一些 patch 是用来避免 BPF program 里的预测执行(speculative-execution)类型的攻击. + 其他还有一些 patch 是用来避免 BPF program 里的预测执行 (speculative-execution) 类型的攻击. +[Code tagging and memory-allocation profiling](https://lwn.net/Articles/932402) \ No newline at end of file diff --git a/study/kernel/00-DESCRIPTION/TOOLS.md b/study/kernel/00-DESCRIPTION/TOOLS.md index cc26087..1dc0277 100644 --- a/study/kernel/00-DESCRIPTION/TOOLS.md +++ b/study/kernel/00-DESCRIPTION/TOOLS.md @@ -104,6 +104,8 @@ Intel 发布的 ControlFlag 用机器学习来发现代码中的错误, 支持 C 在内核态尝试 dump 用户态的栈对调试是非常有帮助的. +[Dumping User and Kernel Stacks on Kernel Events](https://blog.csdn.net/devwang_com/article/details/93633488) + [how to print stack trace in-your-user](http://kungjohan.blogspot.com/2012/06/how-to-print-stack-trace-in-your-user.html) [how-to-dump-user-space-stack-in-kernel-space](https://stackoverflow.com/questions/38384259/how-to-dump-user-space-stack-in-kernel-space)