From edaa4df6c4f7874e2934dd3674ec4c400b6edefe Mon Sep 17 00:00:00 2001 From: Cheng Jian Date: Sat, 3 Dec 2022 19:40:39 +0800 Subject: [PATCH] description/scheduler: Intel Thread Director (ITD) --- study/kernel/00-DESCRIPTION/ARCH.md | 39 +++++++++++++++---- study/kernel/00-DESCRIPTION/BPF.md | 7 ++++ study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md | 6 +++ study/kernel/00-DESCRIPTION/SCHEDULER.md | 6 ++- 4 files changed, 49 insertions(+), 9 deletions(-) diff --git a/study/kernel/00-DESCRIPTION/ARCH.md b/study/kernel/00-DESCRIPTION/ARCH.md index 79de471..3b8f518 100644 --- a/study/kernel/00-DESCRIPTION/ARCH.md +++ b/study/kernel/00-DESCRIPTION/ARCH.md @@ -65,6 +65,12 @@ blogexcerpt: 虚拟化 & KVM 子系统 ### 1.1.1 split lock detect ------- +| 日期 | LWN | 翻译 | +|:---:|:----:|:---:| +| 2021/02/08 | [Detecting and handling split locks](https://lwn.net/Articles/790464) | [LWN：检测Intel CPU的split locks以及阻止攻击](https://blog.csdn.net/Linux_Everything/article/details/93270786) | +| 2019/12/06 | [Developers split over split-lock detection](https://lwn.net/Articles/806466) | [LWN：开发者争论split-lock检测机制！](https://blog.csdn.net/Linux_Everything/article/details/103640683) | + + [字节跳动技术团队的博客--深入剖析 split locks, i++ 可能导致的灾难](https://blog.csdn.net/ByteDanceTech/article/details/124701175) 拆分锁是指原子指令对跨越多个高速缓存行的数据进行操作. 由于原子性质, 在两条高速缓存行上工作时需要全局总线锁, 这反过来又会对整体系统性能造成很大的性能影响. @@ -181,20 +187,40 @@ Intel Architecture Day 2021, 官宣了自己的服务于终端和桌面场景的 #### 1.4.1.3 ITMT SMT migration Improvement ------- -Intel 在 LPC-2022 演示 [Bringing Energy-Aware Scheduling to x86](https://lpc.events/event/16/contributions/1275) 时, 对 ITMT 的改进一并进行了阐述. LWN 也对此进行了讲解 [Hybrid scheduling gets more complicated](https://lwn.net/Articles/909611). +ASYM_PACKING 用于平衡物理核心与 SMT 之间的负载均衡处理 (例如, 支持 Intel ITMT 3.0 和混合处理器的英特尔处理器) 以及物理核心的 SMT 兄弟(例如, Power7). 这项机制对于后者来说工作地不错, 但是对于前者的支持, 不慎友好, 特别是在混合了高性能的 P-core 以及高能效的 E-core 的混合处理器(比如 Alder Lake)上, 这引发了 CPU 之间不必要甚至是错误的迁移. -自 v4.10 开始, 英特尔的 ITMT 技术支持 ASYM_PACKING, 使得调度程序更喜欢 P-core 而不是 E-cores. 这产生了在可能的情况下将进程放在更快更强劲的 P-core 上的效果. 但是 Alder Lake 等混合架构的 CPU, P-core 支持 SMT, E-core 不支持 SMT. 这样 CPU 的选择顺序应该倾向于 P-core(ST) > E-core > p-core(HT/SMT), 即调度器应该先尝试 P-core, 其次是 E-core, 最后才是 P-core/E-core 的 SMT 兄弟 CPU, 但是调度器并没有意识到这点, 它也会在 P-core 不满足要求时, 优先加载了 P-core 同级的 SMT 兄弟 CPU, 而不是尝试 E-cores. 从而导致整体性能的下降. 这已于 v5.16 [commit 4006a72bdd93 ("sched/fair: Fix load balancing of SMT siblings with ASYM_PACKING")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=4006a72bdd93b1ffedc2bd8646dee18c822a2c26) 修复. 其解决方案是: +自 v4.10 开始, 支持 ITMT 的 Intel 处理器使用 ASYM_PACKING 将更高的优先级分配给可以 Boost 的 CPU. 它通过将较低的优先级分配给编号较高的 SMT 兄弟节点, 以确保它们最后使用. + +* 错误的优先级标记, 导致错误的迁移. + +首先发现 ITMT 标记 HT/SMT CPU 优先级的算法存在问题, 它使得调度程序更喜欢 P-core 而不是 E-cores. 调度器的本意是在可能的情况下将进程放在更快更强劲的 P-core 上的效果. 但是事实情况是: 如果 CPU 的一个或多个 SMT 兄弟 CPU 都很繁忙, 那么 CPU 的吞吐量就会降低. 因此, 完全空闲的低优先级 CPU 比拥有繁忙 SMT 兄弟节点的高优先级 CPU 更受欢迎. 对于 Alder Lake 等混合架构的 CPU, P-core 支持 SMT, E-core 不支持 SMT. 这样 CPU 的选择顺序应该倾向于 P-core(ST) > E-core > p-core(HT/SMT), 即调度器应该先尝试 P-core, 其次是 E-core, 最后才是 P-core/E-core 的 SMT 兄弟 CPU, 但是调度器并没有意识到这点, 它也会在 P-core 不满足要求时, 优先加载了 P-core 同级的 SMT 兄弟 CPU, 而不是尝试 E-cores. 从而导致整体性能的下降. + +因此 v5.16 [commit 4006a72bdd93 ("sched/fair: Fix load balancing of SMT siblings with ASYM_PACKING")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=4006a72bdd93b1ffedc2bd8646dee18c822a2c26) 修复. 其解决方案是修正 SMT 兄弟 CPU 的优先级分配, 使得 P-core(SMT) 比 E-core 的优先级更低. 1. [commit 183b8ec38f1e ("x86/sched: Decrease further the priorities of SMT siblings")"](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=183b8ec38f1ec6c1f8419375303bf1d09a2b8369) 修改了 ITMT 下 sched_core_priority 中 smt_prio 的计算方式, HT 的优先级永远比 ST 的 core 要低, 从而保证 P-core 的 HT 优先级比 E-core 要低. 这样负载平衡器将选择高优先级的 P-core (Intel Core) 而不是中优先级的 E-core (Intel Atom), 最后才将负载溢出到低优先级的 SMT 同级 CPU. 2. [commit 4006a72bdd93 ("sched/fair: Consider SMT in ASYM_PACKING load balance")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4006a72bdd93b1ffedc2bd8646dee18c822a2c26) 当决定在 ASYM_PACKING 中提取任务时, 不仅需要检查 dst CPU 的空闲状态, 还需要检查其同级 SMT CPU 的空闲状态. 如果 dst CPU 处于空闲状态, 但其同级 SMT CPU 处于繁忙状态, 则如果将任务从没有 SMT 中等优先级 CPU(比如 AderLake 的 E-core)中 PULL 过来, 性能必然会受到影响. 实现 [asym_smt_can_pull_tasks()](https://elixir.bootlin.com/linux/v5.16/source/kernel/sched/fair.c#L8492) 以检查候选最忙组中 dst CPU 和 CPU 的同级 SMT 的状态. +2. 不感知 SMT 兄弟 CPU 的状态, 导致不必要的迁移. +但是测试发现, v5.16 优先级的修复, 只是一定程度缓解了问题, 修正了 HT 和 SMT CPU 的次序, 优先 P-core(HT) -=> E-core(HT, 不支持 SMT) -=> P-core(SMT). 但是 E-core 和 P-core(SMT) 在判断是否进行迁移时, 并不感知 SMT CORE 上其他兄弟 CPU 实际的工作状态. 系统中依旧存在异常的进程迁移. + +现在 ASYM_PACKING 的实现, x86 初始化 ITMT 时通过 [sched_set_itmt_core_prio()](https://elixir.bootlin.com/linux/v6.0/source/arch/x86/kernel/itmt.c#L189) 为编号较高的 SMT 兄弟节点分配较低的优先级 [arch_asym_cpu_priority()](https://elixir.bootlin.com/linux/v6.0/source/arch/x86/kernel/itmt.c#L199). 但是实际上, CPU Core 的任何 SMT 兄弟之间没有区别. + +因此其实为每个 SMT 兄弟分配不同的优先级是非常不合理的. 相反, 应该调整 ASYM_PACKING 的负载均衡逻辑, 标记出 SMT 兄弟的状态, 如果有多个繁忙兄弟的 SMT CPU, 则[低优先级 CPU 的 E-core 将积极地从高优先级的 P-core 中提取任务](https://lore.kernel.org/lkml/20220825225529.26465-4-ricardo.neri-calderon@linux.intel.com). 随后 Ricardo Neri 向社区发送了修复方案 [sched/fair: Avoid unnecessary migrations within SMT domains v1,0/4](https://lore.kernel.org/all/20220825225529.26465-1-ricardo.neri-calderon@linux.intel.com). + +在 Peter 的建议下, [v2, 0/4](https://lore.kernel.org/all/20220825225529.26465-1-ricardo.neri-calderon@linux.intel.com) 采用了开始跟踪 SMT CPU 的状态, 通过调整 sym_pack 负载均衡逻辑, arch_asym_cpu_priority() 中[通过 sched_smt_siblings_idle() 考虑 CPU 的 SMT 兄弟节点的空闲状态](https://lore.kernel.org/lkml/20221122203532.15013-8-ricardo.neri-calderon@linux.intel.com). 参见 phoronix 报道 [Intel Posts Reworked Linux Patches To Improve Hybrid CPU + HT/SMT Kernel Behavior](https://www.phoronix.com/news/Intel-SMT-Hybrid-Avoid-Migrate). + +不再对 SMT 的兄弟 CPU [标记不同的优先级](https://lore.kernel.org/lkml/20221122203532.15013-8-ricardo.neri-calderon@linux.intel.com), 也不再通过 ASYM_PACKING 指导 SMT 之间的负载均衡, 这可以避免多余的迁移. + +通过 [find_busiest_group()](https://lore.kernel.org/lkml/20221122203532.15013-2-ricardo.neri-calderon@linux.intel.com) 让低优先级的核检查所有 SMT 兄弟节点以找到最繁忙的队列. 这对于支持 Intel Thread Director 的 IPC Classes 也是必需的, 因为目标 CPU 将需要检查在相同优先级 CPU 上运行的任务. + +当然这组补丁集不会影响原来 Power7 SMT8 的 ASYM_PACKING 逻辑. 对于没有实现 sched_ferences_asym() 的 新 check_smt 参数的架构, 功能不会改变. | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2021/09/10 | Ricardo Neri | [sched/fair: Fix load balancing of SMT siblings with ASYM_PACKING](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=4006a72bdd93b1ffedc2bd8646dee18c822a2c26) | 参见 [Fixing a corner case in asymmetric CPU packing](https://lwn.net/Articles/880367), 在使用非对称封装(ASM_PACKING)时, 可能存在具有三个优先级的 CPU 拓扑, 其中只有物理核心的子集支持 SMT. 这种架构下 ASM_PACKING 和 SMT 以及 load_balance 都存在冲突.
这种拓扑的一个实例是 Intel Alder Lake. 在 Alder Lake 上, 应该通过首先选择 Core(酷睿) cpu, 然后选择 Atoms, 最后再选择 Core 的 SMT 兄弟 cpu 来分散工作. 然而, 当前负载均衡器的行为与使用 ASYM_PACKING 时描述的不一致. 负载平衡器将选择高优先级的 CPU (Intel Core) 而不是中优先级的 CPU (Intel Atom), 然后将负载溢出到低优先级的 SMT 同级 CPU. 这使得中等优先级的 Atoms cpu 空闲, 而低优先级的 cpu sibling 繁忙.
1. 首先改善了 SMT 中 sibling cpu 优先级的计算方式, 它将比单个 core 优先级更低.
2. 当决定目标 CPU 是否可以从最繁忙的 CPU 提取任务时, 还检查执行负载平衡的 CPU 和最繁忙的候选组的 SMT 同级 CPU 的空闲状态. | v5 ☑ 5.16-rc1 | [PatchWork v1](https://lore.kernel.org/patchwork/cover/1408312)
*-*-*-*-*-*-*-*
[PatchWork v2](https://lore.kernel.org/patchwork/cover/1413015)
*-*-*-*-*-*-*-*
[PatchWork v3 0/6](https://lore.kernel.org/patchwork/cover/1428441)
*-*-*-*-*-*-*-*
[PatchWork v4,0/6](https://lore.kernel.org/patchwork/cover/1474500)
*-*-*-*-*-*-*-*
[LKML v5,0/6](https://lkml.org/lkml/2021/9/10/913), [LORE v5,0/6](https://lore.kernel.org/all/20210911011819.12184-1-ricardo.neri-calderon@linux.intel.com) | -| 2022/08/25 | Ricardo Neri | [sched/fair: Avoid unnecessary migrations within SMT domains](https://lore.kernel.org/all/20220825225529.26465-1-ricardo.neri-calderon@linux.intel.com) | TODO | v1 ☐☑✓ | [LORE v1,0/4](https://lore.kernel.org/all/20220825225529.26465-1-ricardo.neri-calderon@linux.intel.com)
*-*-*-*-*-*-*-*
[LORE v2,0/7](https://lore.kernel.org/lkml/20221122203532.15013-1-ricardo.neri-calderon@linux.intel.com) | +| 2022/08/25 | Ricardo Neri | [sched/fair: Avoid unnecessary migrations within SMT domains](https://lore.kernel.org/all/20220825225529.26465-1-ricardo.neri-calderon@linux.intel.com) | TODO | v1 ☐☑✓ | [2022/08/25 LORE v1,0/4](https://lore.kernel.org/all/20220825225529.26465-1-ricardo.neri-calderon@linux.intel.com)
*-*-*-*-*-*-*-*
[2022/11/22 LORE v2,0/7](https://lore.kernel.org/lkml/20221122203532.15013-1-ricardo.neri-calderon@linux.intel.com) | #### 1.4.1.3 Intel Thread Director (ITD) @@ -206,11 +232,9 @@ Intel 在 LPC-2022 演示 [Bringing Energy-Aware Scheduling to x86](https://lpc. 首先 v5.18, Intel 先完成了对 HFI 硬件的支持. [Intel Hardware Feedback Interface "HFI" Driver Submitted For Linux 5.18](https://www.phoronix.com/news/Intel-HFI-Thermal-Linux-5.18). -随后 Intel 发布了 Linux 上 Thread-Driector 的支持补丁. [Intel Posts Big Linux Patch Set For "Classes of Tasks" On Hybrid CPUs, Thread Director](https://www.phoronix.com/news/Intel-Linux-Classes-Of-Tasks-TD). 并随后在 LPC-2022 做了主题为 [Bringing Energy-Aware Scheduling to x86](https://lpc.events/event/16/contributions/1275) 的演示. phoronix 随即进行了报道 [Intel Working On Energy Aware Scheduling For x86 Hybrid CPUs](https://www.phoronix.com/news/Intel-x86-EAS-To-Come). - -随后 LWN 对此进行了讨论 [Hybrid scheduling gets more complicated](https://lwn.net/Articles/909611). - +随后 Intel 发布了 Linux 上 Thread-Driector 的支持补丁. [Intel Posts Big Linux Patch Set For "Classes of Tasks" On Hybrid CPUs, Thread Director](https://www.phoronix.com/news/Intel-Linux-Classes-Of-Tasks-TD). 并随后在 LPC-2022 做了主题为 [Bringing Energy-Aware Scheduling to x86](https://lpc.events/event/16/contributions/1275) 的演示. phoronix 随即进行了报道 [Intel Working On Energy Aware Scheduling For x86 Hybrid CPUs](https://www.phoronix.com/news/Intel-x86-EAS-To-Come). 随后 LWN 对此进行了讨论 [Hybrid scheduling gets more complicated](https://lwn.net/Articles/909611). +随后发布了 v2, 参见 phoronix 报道 [Intel Advances Linux "IPC Classes" Design To Improve Load Balancing For Hybrid CPUs](https://www.phoronix.com/news/Intel-IPC-Classes-Post-RFC). | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| @@ -1023,6 +1047,7 @@ openEuler 提供了 [openEuler/prefetch_tuning](https://gitee.com/openeuler/pref [AMD Making It Easier To Switch To Their New P-State CPU Frequency Scaling Driver](https://www.phoronix.com/news/AMD-Easier-P-State-Usage) [AMD P-State EPP Driver Updated For More Power/Performance Control On Linux](https://www.phoronix.com/news/AMD-P-State-EPP-v4) [New Patches Allow More Easily Managing The AMD P-State Linux Driver](https://www.phoronix.com/news/AMD-P-State-Built-In-Options) +[Linux 6.1-rc7 Makes It Easier To Manage The AMD P-State Driver](https://www.phoronix.com/news/Linux-6.1-rc7-Easier-AMD-Pstate) | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:---:|:----:|:---:|:----:|:---------:|:----:| diff --git a/study/kernel/00-DESCRIPTION/BPF.md b/study/kernel/00-DESCRIPTION/BPF.md index 68d1cee..7cd5e10 100644 --- a/study/kernel/00-DESCRIPTION/BPF.md +++ b/study/kernel/00-DESCRIPTION/BPF.md @@ -390,6 +390,13 @@ raw_tracepoint 相比 tracepoint [Toward signed BPF programs](https://lwn.net/Articles/853489) +# 4 子系统支持 +------- + +[Innovative HID-BPF Expected To Land In Linux 6.2](https://www.phoronix.com/news/Linux-6.2-HID-BPF-Expected) + +[](https://www.phoronix.com/news/Linux-eBPF-For-HID) + # 5 网络场景 ------- diff --git a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md index d2405ed..c2e6326 100644 --- a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md +++ b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md @@ -3340,6 +3340,7 @@ MGLRU 的开发者在 LPC-2022 上演示了 MGLRU [Multi-Gen LRU: Current Status | 2022/09/11 | Yuanchu Xie | [mm: multi-gen LRU: per-process heatmaps](https://patchwork.kernel.org/project/linux-mm/cover/20220911083418.2818369-1-yuanchu@google.com/) | MGLRU debugfs 接口(`/sys/kernel/debug/lru_gen`) 提供了一个统计属于每一代的页面数量的直方图, 提供了一些内存冷量数据, 但我们实际上不知道内存实际在哪里, 通过 BPF 程序连接到 MGLRU 页表访问位获取, 以收集有关相对 HOT 和 COLD、NUMA 节点以及页是否为 anon/file 等的信息. 使用 BPF 程序收集和聚合页面访问信息允许用户空间代理自定义收集什么以及如何聚合. 它可以关注特定的兴趣区域, 并计算移动平均访问频率, 或者找到从未访问过的分配, 这些分配可以一起消除. 目前, MGLRU 依赖于关于页面被分配到哪一代的启发式方法, 例如, 通过页面表访问的页面总是被分配给最年轻的一代. 公开页面访问数据可以允许未来的工作自定义页面生成分配(使用更多 BPF). | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/all/20220911083418.2818369-1-yuanchu@google.com) | | 2022/09/18 | Yu Zhao | [[v14-fix,01/11] mm: multi-gen LRU: update admin guide](https://patchwork.kernel.org/project/linux-mm/patch/20220918204755.3135720-1-yuzhao@google.com/) | 677981 | v1 ☐☑ | [LORE v1,0/11](https://lore.kernel.org/r/20220918204755.3135720-1-yuzhao@google.com) | | 2022/09/20 | zhaoyang.huang | [[RFC] mm: track bad page via kmemleak](https://patchwork.kernel.org/project/linux-mm/patch/1663679468-16757-1-git-send-email-zhaoyang.huang@unisoc.com/) | 678650 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/1663679468-16757-1-git-send-email-zhaoyang.huang@unisoc.com) | +| 2022/12/01 | Yu Zhao | [mm: multi-gen LRU: memcg LRU](https://lore.kernel.org/all/20221201223923.873696-1-yuzhao@google.com) | TODO | v1 ☐☑✓ | [LORE v1,0/8](https://lore.kernel.org/all/20221201223923.873696-1-yuzhao@google.com) | @@ -3891,6 +3892,11 @@ v2.5 的时候引入了 shrink 机制, 并提供了 API 统一了各个模块的 [Facebook Developing THP Shrinker To Avoid Linux Memory Waste](https://www.phoronix.com/news/Linux-THP-Shrinker) +| 日期 | LWN | 翻译 | +|:---:|:----:|:---:| +| 2022/09/08 | [The transparent huge page shrinker](https://lwn.net/Articles/906511) | [LWN：针对透明巨页的shrinker！](https://blog.csdn.net/Linux_Everything/article/details/127020244) | + + | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:---:|:----:|:---:|:----:|:---------:|:----:| | 2022/08/05 | alexlzhu@fb.com | [mm: add thp_utilization metrics to /proc/thp_utilization](https://lore.kernel.org/all/20220805184016.2926168-1-alexlzhu@fb.com) | 由于性能的提高或降低取决于特定应用程序如何使用物理内存, THP 在历史上一直是针对每个应用程序启用的. 当 THP 被大量利用时, 由于 TLB 缓存失败的减少, 应用程序性能会得到改善. 长期以来, 人们一直怀疑启用 THP 时的性能下降是由于大量未充分利用的匿名 THP 造成的. 以前, 没有办法跟踪到底有多少 THP 被实际使用. 通过这个补丁, 帮助开发者了解 THP 的使用情况, 以便在分页方面做出更智能的决策. 这个更改引入了一个工具, 该工具扫描匿名 THP 的所有物理内存, 并根据使用率将它们分组到桶中. 它还包括一个位于 `/sys/kernel/debug/thp_utilization` 下的接口. THP 的利用率定义为 THP 中非零页面的百分比. 工作线程将扫描所有物理内存, 并获得所有匿名 THP 的利用率. 它将通过定期扫描所有物理内存来收集这些信息, 寻找匿名 THP, 根据利用率将它们分组到桶中, 并通过 `/sys/kernel/debug/thp_utilization` 下的 debugfs 报告利用率信息. | v3 ☐☑✓ | [LORE v2](https://lore.kernel.org/lkml/20220809014950.3616464-1-alexlzhu@fb.com)
*-*-*-*-*-*-*-*
[LORE v3](https://lore.kernel.org/all/20220805184016.2926168-1-alexlzhu@fb.com)
*-*-*-*-*-*-*-*
[LORE v3,0/1](https://lore.kernel.org/r/20220818000112.2722201-1-alexlzhu@fb.com) | diff --git a/study/kernel/00-DESCRIPTION/SCHEDULER.md b/study/kernel/00-DESCRIPTION/SCHEDULER.md index df588b5..388203f 100644 --- a/study/kernel/00-DESCRIPTION/SCHEDULER.md +++ b/study/kernel/00-DESCRIPTION/SCHEDULER.md @@ -520,7 +520,7 @@ linux 调度器定义了多个调度类, 不同调度类的调度优先级不同 2. ITMT 技术将 CPU package 中的某些 CPU 提升到更高的 Turbo 频率, 可以获得更好的性能, 这样倾向于将进程打包到 Turbo 的 CPU 上, 也可以获得更好的性能. -3. Alder Lake 等混合架构的 CPU, P-core 支持 SMT, E-core 不支持 SMT. 这样 CPU 的选择顺序应该倾向于 P-core(ST) > E-core > p-core(SMT). +3. Alder Lake 等混合架构的 CPU, P-core 支持 SMT, E-core 不支持 SMT. 这样 CPU 的选择顺序应该倾向于 P-core(ST) > E-core > P-core(SMT). | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| @@ -529,7 +529,7 @@ linux 调度器定义了多个调度类, 不同调度类的调度优先级不同 | 2016/04/06 | Srikar Dronamraju | [sched/fair: Fix asym packing to select correct cpu](https://lore.kernel.org/all/1459948660-16073-1-git-send-email-srikar@linux.vnet.ibm.com) | NA | v2 ☑ 4.7-rc1 | [PatchWork v2](https://lore.kernel.org/all/1459948660-16073-1-git-send-email-srikar@linux.vnet.ibm.com) | | 2016/12/29 | Peter Oskolkov | [sched/x86: Change CONFIG_SCHED_ITMT to CONFIG_SCHED_MC_PRIO](https://lore.kernel.org/all/2b2ee29d93e3f162922d72d0165a1405864fbb23.1480444902.git.tim.c.chen@linux.intel.com) | 将 ITMT 的 CONFIG_SCHED_ITMT 更新为 CONFIG_SCHED_MC_PRIO, 这使得该配置在将来可以扩展到希望在调度器中类似地建立 CPU 核心优先级支持的其他体系结构. | v1 ☑ 4.10-rc1 | [PatchWork](https://lore.kernel.org/all/2b2ee29d93e3f162922d72d0165a1405864fbb23.1480444902.git.tim.c.chen@linux.intel.com) | | 2019/1/17 | Vincent Guittot | [sched/fair: some fixes for asym_packing](https://lkml.org/lkml/2019/1/17/658) | NA | v2 ☑ 5.1-rc1 | [LKML v3,0/3](https://lkml.org/lkml/2018/12/20/616), [PatchWork v3,0/3](https://lore.kernel.org/all/1545292547-18770-1-git-send-email-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[LKML v4,0/3](https://lkml.org/lkml/2019/1/17/658) | -| 2021/09/10 | Ricardo Neri | [sched/fair: Fix load balancing of SMT siblings with ASYM_PACKING](https://lore.kernel.org/patchwork/cover/1428441) | 在使用非对称封装 (ASM_PACKING) 时, 可能存在具有三个优先级的 CPU 拓扑, 其中只有物理核心的子集支持 SMT. 这种架构下 ASM_PACKING 和 SMT 以及 load_balance 都存在冲突.
这种拓扑的一个实例是 Intel Alder Lake. 在 Alder Lake 上, 应该通过首先选择 Core(酷睿) cpu, 然后选择 Atoms, 最后再选择 Core 的 SMT 兄弟 cpu 来分散工作. 然而, 当前负载均衡器的行为与使用 ASYM_PACKING 时描述的不一致. 负载平衡器将选择高优先级的 CPU (Intel Core) 而不是中优先级的 CPU (Intel Atom), 然后将负载溢出到低优先级的 SMT 同级 CPU. 这使得中等优先级的 Atoms cpu 空闲, 而低优先级的 cpu sibling 繁忙.
1. 首先改善了 SMT 中 sibling cpu 优先级的计算方式, 它将比单个 core 优先级更低.
2. 当决定目标 CPU 是否可以从最繁忙的 CPU 提取任务时, 还检查执行负载平衡的 CPU 和最繁忙的候选组的 SMT 同级 CPU 的空闲状态. | v5 ☑ 5.16-rc1 | [PatchWork v1](https://lore.kernel.org/patchwork/cover/1408312)
*-*-*-*-*-*-*-*
[PatchWork v2](https://lore.kernel.org/patchwork/cover/1413015)
*-*-*-*-*-*-*-*
[PatchWork v3 0/6](https://lore.kernel.org/patchwork/cover/1428441)
*-*-*-*-*-*-*-*
[PatchWork v4,0/6](https://lore.kernel.org/patchwork/cover/1474500)
*-*-*-*-*-*-*-*
[LKML v5,0/6](https://lkml.org/lkml/2021/9/10/913), [LORE v5,0/6](https://lore.kernel.org/all/20210911011819.12184-1-ricardo.neri-calderon@linux.intel.com) | +| 2021/09/10 | Ricardo Neri | [sched/fair: Fix load balancing of SMT siblings with ASYM_PACKING](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=4006a72bdd93b1ffedc2bd8646dee18c822a2c26) | 在使用非对称封装 (ASM_PACKING) 时, 可能存在具有三个优先级的 CPU 拓扑, 其中只有物理核心的子集支持 SMT. 这种架构下 ASM_PACKING 和 SMT 以及 load_balance 都存在冲突.
这种拓扑的一个实例是 Intel Alder Lake. 在 Alder Lake 上, 应该通过首先选择 Core(酷睿) cpu, 然后选择 Atoms, 最后再选择 Core 的 SMT 兄弟 cpu 来分散工作. 然而, 当前负载均衡器的行为与使用 ASYM_PACKING 时描述的不一致. 负载平衡器将选择高优先级的 CPU (Intel Core) 而不是中优先级的 CPU (Intel Atom), 然后将负载溢出到低优先级的 SMT 同级 CPU. 这使得中等优先级的 Atoms cpu 空闲, 而低优先级的 cpu sibling 繁忙.
1. 首先改善了 SMT 中 sibling cpu 优先级的计算方式, 它将比单个 core 优先级更低.
2. 当决定目标 CPU 是否可以从最繁忙的 CPU 提取任务时, 还检查执行负载平衡的 CPU 和最繁忙的候选组的 SMT 同级 CPU 的空闲状态. | v5 ☑ 5.16-rc1 | [PatchWork v1](https://lore.kernel.org/patchwork/cover/1408312)
*-*-*-*-*-*-*-*
[PatchWork v2](https://lore.kernel.org/patchwork/cover/1413015)
*-*-*-*-*-*-*-*
[PatchWork v3 0/6](https://lore.kernel.org/patchwork/cover/1428441)
*-*-*-*-*-*-*-*
[PatchWork v4,0/6](https://lore.kernel.org/patchwork/cover/1474500)
*-*-*-*-*-*-*-*
[LKML v5,0/6](https://lkml.org/lkml/2021/9/10/913), [LORE v5,0/6](https://lore.kernel.org/all/20210911011819.12184-1-ricardo.neri-calderon@linux.intel.com) | ### 1.5.4 SMT @@ -6008,6 +6008,8 @@ Roman Gushchin 在邮件列表发起了 BPF 对调度器的潜在应用的讨论 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2021/09/15 | Roman Gushchin | [Scheduler BPF](https://www.phoronix.com/scan.php?page=news_item&px=Linux-BPF-Scheduler) | NA | RFC ☐ | [PatchWork rfc,0/6](https://patchwork.kernel.org/project/netdevbpf/cover/20210916162451.709260-1-guro@fb.com)
*-*-*-*-*-*-*-*
[LPC 2021](https://linuxplumbersconf.org/event/11/contributions/954)
*-*-*-*-*-*-*-*
[LKML](https://lkml.org/lkml/2021/9/16/1049), [LWN](https://lwn.net/Articles/869433), [LWN](https://lwn.net/Articles/873244) | +| 2022/11/29 | Tejun Heo | [sched: Implement BPF extensible scheduler class](https://lore.kernel.org/all/20221130082313.3241517-1-tj@kernel.org) | 随后 FaceBook 进一步扩展, 引入 sched_ext 模块, 使用 eBPF 对调度器进行可编程重构. [Experimental Patches Allow eBPF To Extend The Linux Kernel's Scheduler](https://www.phoronix.com/news/RFC-eBPF-Linux-Scheduler), [The BPF extensible scheduler class](https://lwn.net/Articles/916291). | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20221130082313.3241517-1-tj@kernel.org) | + #### 11.2.2.2 Google 的 ghOSt -------