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

description/scheduler: Group Identity

Browse Source
This commit is contained in:
Cheng Jian
2022-07-24 16:51:33 +08:00
parent 1427707632
commit 411a59ae3d
5 changed files with 211 additions and 55 deletions
Download Patch File Download Diff File Expand all files Collapse all files
study/kernel/00-DESCRIPTION/ARCH.md
+30 -4
View File
@@ -210,6 +210,8 @@ Intel Alder Lake CPU 支持 AVX 512
[Intel Core i7 1280P "Alder Lake P" Linux Laptop Performance](https://www.phoronix.com/scan.php?page=article&item=intel-corei7-1280p)
[An Important Note On The Alder Lake Mobile Power/Performance With Linux 5.19](https://www.phoronix.com/scan.php?page=article&item=linux-519-alderlakep) 针对 AdlerLake 笔记本测试了 v5.18 和 v5.19 电源管理等带来的能效差异.
#### 1.4.1.4 调度器优化
-------
@@ -478,11 +480,28 @@ TLB entry shootdown 常常或多或少的带来一些性能问题.
在 x86 上, 批处理和延迟 TLB shootdown 的解决方案使 TLB shootdown 的性能提高了 90%. 在 arm64 上, 硬件可以在没有软件 IPI 的情况下执行 TLB shootdown. 但同步 tlbi 仍然相当昂贵.
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 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) |
### 2.2.5 relaxed TLB flushes
-------
[VMware Is Exploring Reducing Meltdown/PTI Overhead With Deferred Flushes](https://www.phoronix.com/scan.php?page=news_item&px=VMware-RFC-Defer-PTI-Flushes)
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2019/08/23 | Nadav Amit <namit@vmware.com> | [x86/mm/tlb: Defer TLB flushes with PTI](https://lore.kernel.org/all/20190823225248.15597-1-namit@vmware.com) | TODO | v2 ☐☑✓ | [LORE v2,0/3](https://lore.kernel.org/all/20190823225248.15597-1-namit@vmware.com) |
[Relaxed TLB Flushes Being Worked On For Linux As Another Performance Optimization](https://www.phoronix.com/scan.php?page=news_item&px=Linux-Relaxed-TLB-Flushes).
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2022/07/18 | Nadav Amit <nadav.amit@gmail.com> | [mm: relaxed TLB flushes and other optimi.](https://lore.kernel.org/all/20220718120212.3180-1-namit@vmware.com) | TODO | v1 ☐☑✓ | [LORE v1,0/14](https://lore.kernel.org/all/20220718120212.3180-1-namit@vmware.com) |
## 2.3 指令加速
@@ -855,7 +874,14 @@ Rosetta 是一个转译过程, 允许用户在 Apple Silicon 上运行包含 x86
[macOS 13 Adding Ability To Use Rosetta In ARM Linux VMs For Speedy x86_64 Linux Binaries](https://www.phoronix.com/scan.php?page=news_item&px=macOS-13-Rosetta-Linux-Binaries)
## 6.8 芯片设计
## 6.8 原子操作
-------
[ARMV8 datasheet 学习笔记 3：AArch64 应用级体系结构之 Atomicity](https://www.cnblogs.com/smartjourneys/p/6843978.html)
[ARMv8 之 Atomicity](http://www.wowotech.net/?post=295)
## 6.10 芯片设计
-------
Tachyum 宣布其设计一款完全通用的处理器 Prodigy T16128, 预计 2023 年发布, [Tachyum's Monster 128 Core 5.7GHz 'Universal Processor' Does Everything](https://www.tomshardware.com/news/tachyum-128-core-all-purpose-cpu), 号称一款芯片上可以同时运行通用计算, 高性能计算以及 AI 等业务和负载, 原生支持 x86, ARM, RISC-V 和 ISA 的二进制.
@@ -866,7 +892,7 @@ Google Google 推出[芯片设计门户网站](https://developers.google.com/sil
中国科学院大学("国科大")的 ["一生一芯" 计划](https://ysyx.org).
## 6.9 预取
### 6.10.1 预取
-------
富士通添加了 sysfs 接口来控制 CPU L2 Cache/DCU 等硬件的预取行为, 以便从用户空间对 A64FX 处理器和 x86 行性能调优.
@@ -879,13 +905,13 @@ Google Google 推出[芯片设计门户网站](https://developers.google.com/sil
openEuler 提供了 [openEuler/prefetch_tuning](https://gitee.com/openeuler/prefetch_tuning) 提供了鲲鹏芯片设计的渔区相关寄存器读写接口, 用于读取和配置在 CPU 的硬件层面的芯片性能调优参数. 内核中更是提供了 [CONFIG_HISILICON_ERRATUM_HIP08_RU_PREFETCH](https://gitee.com/openeuler/kernel/commit/13ab4b7fa6f92eb9819a01129c4e4a0a9c401ee8) 来在启动时配置预期.
## 6.10 Software Branch Hinting
### 6.10.2 Software Branch Hinting
-------
[Software Branch Hinting](https://labs.engineering.asu.edu/mps-lab/research-themes/low-power-computing/sbh)
## 6.9 指令集
### 6.10.3 指令集架构
-------
study/kernel/00-DESCRIPTION/DEBUGGING.md
+26 -2
View File
@@ -337,11 +337,35 @@ x86 和 arm64 都支持直接访问用户空间中的事件计数器. 访问序
[AMD Branch Sampling "BRS" Feature To Land With Linux 5.19](https://www.phoronix.com/scan.php?page=news_item&px=AMD-Branch-Sampling-v5.19)
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:-----:|:----:|:----:|:----:|:------------:|:----:|
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2022/03/22 | Stephane Eranian <eranian@google.com> | [perf/x86/amd: Add AMD Fam19h Branch Sampling support](https://lore.kernel.org/all/20220322221517.2510440-1-eranian@google.com) | 引入 CONFIG_PERF_EVENTS_AMD_BRS. perf 支持 BRS. AMD 系列 19h "Zen 3" 处理器新增了分支采样功能 BRS, 用于收集代码执行期间所采用分支的详细信息. 该功能可用于 AMD 处理器上的 AutoFDO 样式优化, 编译器利用收集的硬件数据来做出更明智和准确的优化决策. | v7 ☑✓ 5.19-rc1 | [LORE v7,0/13](https://lore.kernel.org/all/20220322221517.2510440-1-eranian@google.com) |
## 11.5 perf-KWork
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2022/07/09 | Yang Jihong <yangjihong1@huawei.com> | [perf: Add perf kwork](https://lore.kernel.org/all/20220709015033.38326-1-yangjihong1@huawei.com) | 开发者经常需要分析内核工作的时间属性, 例如 irq、softirq 和工作队列, 包括特定中断的延迟和运行时间. 目前, 这些事件具有内核跟踪点, 但 perf 工具不直接分析这些事件的延迟. perf kwork 工具用于跟踪内核工作的时间属性(如 irq、softirq 和 workqueue), 包括运行时、延迟和时间历史, 使用 perf 工具中的基础设施来允许跟踪额外的目标, 我们还使用 bpf 跟踪来收集和过滤内核中的数据, 以解决大 perf 数据量和额外文件系统中断的问题. | v3 ☐☑✓ | [LORE v3,0/17](https://lore.kernel.org/all/20220709015033.38326-1-yangjihong1@huawei.com) |
## 11.6 perf-lock
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2022/06/15 | Namhyung Kim <namhyung@kernel.org> | [perf lock: New lock contention tracepoints support (v4)](https://lore.kernel.org/all/20220615163222.1275500-1-namhyung@kernel.org) | TODO | v4 ☐☑✓ | [LORE v4,0/7](https://lore.kernel.org/all/20220615163222.1275500-1-namhyung@kernel.org) |
## 11.7 perf bench
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2022/07/04 | Marco Elver <elver@google.com> | [perf/hw_breakpoint: Optimize for thousands of tasks](https://lore.kernel.org/all/20220704150514.48816-1-elver@google.com) | TODO | v3 ☐☑✓ | [LORE v3,0/14](https://lore.kernel.org/all/20220704150514.48816-1-elver@google.com) |
# 12 KPROBE
-------
study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md
+19
View File
@@ -624,8 +624,12 @@ MTE 实现了锁和密钥访问内存. 这样在内存访问期间, 可以在内
#### 1.8.3 Linear Address Masking
-------
[Intel Preparing Linear Address Masking Support (LAM)](https://www.phoronix.com/scan.php?page=news_item&px=Intel-LAM-Glibc)
[Intel Gets Back To Working On Linear Address Masking Support For The Linux Kernel](https://www.phoronix.com/scan.php?page=news_item&px=Intel-LAM-Linux-Kernel-May-2022)
[Intel Revs Its Linear Address Masking Patches For Linux](https://www.phoronix.com/scan.php?page=news_item&px=Intel-LAM-Linux-v5)
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2021/02/05 | "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> | [Linear Address Masking enabling](https://patchwork.kernel.org/project/linux-mm/cover/20210205151631.43511-1-kirill.shutemov@linux.intel.com) | [线性地址屏蔽(LAM)](https://software.intel.com/content/dam/develop/external/us/en/documents-tps/architecture-instruction-set-extensions-programming-reference.pdf) 修改应用于 64 位线性地址的检查, 允许软件将未翻译的地址位用于元数据. 手册参见 [ISE, Chapter 14](https://patchwork.kernel.org/project/linux-mm/cover/20210205151631.43511-1-kirill.shutemov@linux.intel.com). 代码参见 [kas/linux.git](https://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git/log/?h=lam). | RFC ☐ | [PatchWork RFC,0/9](https://patchwork.kernel.org/project/linux-mm/cover/20210205151631.43511-1-kirill.shutemov@linux.intel.com)<br>*-*-*-*-*-*-*-* <br>[LORE v1,0/8](https://lore.kernel.org/r/20220610143527.22974-1-kirill.shutemov@linux.intel.com) |
@@ -4628,6 +4632,16 @@ Google 的工程师 Mina Almasry 提出了一种新的思路, 通过 [mremap 的
| 2022/02/02 | Mike Kravetz <mike.kravetz@oracle.com> | [Add hugetlb MADV_DONTNEED support](https://patchwork.kernel.org/project/linux-mm/cover/20220128222605.66828-1-mike.kravetz@oracle.com/) | 609660 | v1 ☐☑ | [PatchWork v1,0/3](https://lore.kernel.org/all/20220128222605.66828-1-mike.kravetz@oracle.com)<br>*-*-*-*-*-*-*-* <br>[PatchWork v2,0/3](https://lore.kernel.org/r/20220202014034.182008-1-mike.kravetz@oracle.com)<br>*-*-*-*-*-*-*-* <br>[LORE v3,0/3](https://lore.kernel.org/r/20220215002348.128823-1-mike.kravetz@oracle.com) |
### 7.1.9 HugeTLBFS
--------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2015/06/22 | Mike Kravetz <mike.kravetz@oracle.com> | [hugetlbfs: add fallocate support](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log?id=72079ba0dfefc1444b4ef98a2fa3d040838a775f) | 为 HugeTLBFS 增加了 fallocate 功能. 目前, Hugetlbfs 用于那些想要对巨大页面使用进行高度控制的应用程序. 通常, 大型 HugeTLBFS 文件用于将大量巨面映射到应用程序进程中. 应用程序知道何时不再使用这些大文件中的页面范围, 理想情况下希望将它们释放回子池或全局池以作其他用途. fallocate() 系统调用提供了一个用于预分配和在文件中打孔的接口. 这是基于 shmem 版本的, 但它有相当大的分歧. 我们既不用担心交换, 也不用担心新文件的密封. 这允许我们在 HugeTLBFS 文件中移动物理内存, 而不需要映射它. 这也使我们能够支持 MADV_REMOVE, 因为它目前是使用 fallocate () 实现的. MADV_REMOVE 允许我们从 HugeTLBFS 文件中间删除数据, 这在以前是不可能的. | v5 ☐☑✓ | [LORE RFC,0/4](https://lore.kernel.org/lkml/1429225378-22965-1-git-send-email-mike.kravetz@oracle.com)<br>*-*-*-*-*-*-*-* <br>[LORE v4,00/10](https://lore.kernel.org/lkml/1437502184-14269-1-git-send-email-mike.kravetz@oracle.com)<br>*-*-*-*-*-*-*-* <br>[LORE v5,0/9](https://lore.kernel.org/all/1435019919-29225-1-git-send-email-mike.kravetz@oracle.com) |
| 2022/06/13 | Mike Kravetz <mike.kravetz@oracle.com> | [hugeTLBfs: zero partial pages during fallocate hole punch](https://patchwork.kernel.org/project/linux-mm/patch/20220613180858.15933-1-mike.kravetz@oracle.com/) | NA | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220613180858.15933-1-mike.kravetz@oracle.com) |
### 7.1.x More HugeTLB Patchset
-------
@@ -6693,6 +6707,10 @@ DAMON 利用两个核心机制 : **基于区域的采样**和**自适应区域
[Better tools for out-of-memory debugging](https://lwn.net/Articles/894546)
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2022/07/08 | Gang Li <ligang.bdlg@bytedance.com> | [mm, oom: Introduce per numa node oom for CONSTRAINT_{MEMORY_POLICY,CPUSET}](https://lore.kernel.org/all/20220708082129.80115-1-ligang.bdlg@bytedance.com) | 在本系列补丁之前, OOM 只会通过选择整个系统上错误率最高的进程来杀死内存使用率最高(最富裕)的进程. 这在 UMA 系统上运行良好, 但在 NUMA 系统上可能会发生一些意外死亡. 比如, 如果进程 c.out 绑定到 Node1, 并继续从 Node1 分配页面, 而 OOM-Killer 将首先选择 a.out, 但是杀死 a.out 并没有释放 Node1 上的任何内存, 所以 c.out 将被杀死. 如果 mempolicy 或 cpuset 有效, out_of_memory() 将选择特定节点上的受害者进行杀死. 这样内核就可以避免 NUMA 系统上的意外杀戮. | v2 ☐☑✓ | [LORE v2,0/5](https://lore.kernel.org/all/20220708082129.80115-1-ligang.bdlg@bytedance.com) |
## 14.5 能耗感知(EAMM)
-------
@@ -6995,6 +7013,7 @@ ZONE_MOVABLE 一个 pseudo zone, 它实际是从内核划分的某个 zone 中
[Bringing Android closer to the mainline](https://lwn.net/Articles/472984)
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2011/12/20 | Robert Love <rlove@google.com> | [ashmem: Anonymous shared memory subsystem](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=11980c2ac4ccfad21a5f8ee9e12059f1e687bb40) | Android匿名共享内存(Ashmem) | v1 ☐☑✓ | [LORE](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=11980c2ac4ccfad21a5f8ee9e12059f1e687bb40) |
study/kernel/00-DESCRIPTION/SCHEDULER.md
+80 -26
View File
@@ -442,30 +442,7 @@ RT_RUNTIME_SHARE 这个机制本身是为了解决不同 CPU 上, 以及不同
## 1.4 其他一些调度类的尝试
-------
业务场景中总存在一些对时延敏感但是负载很小的在线任务, 和一些时延不敏感但是负载很大的离线任务. 单独使用 isolation 等为时延敏感的业务分配 CPU 是比较浪费 CPU 资源的, 因此这些业务往往混部在一起. 然而, 现有的实现在混部后在线业务的服务质量下降严重.
虽然内核提供了 SCHED_BATCH 和 SCHED_IDLE 两种优先级比较低的调度算法, 但它们仍然和CFS共用相同的实现, 尤其是在负载均衡时是未做区分的, 它们是没有完全的和CFS隔离开来, 所以效果上面介绍的通用方案存在类似的问题.
其实, 在大家看来, 专门为这些应用新增一个调度类也是一个不错的想法, 通过各个调度类的优先级次序, 原生可以保证在线任务直接抢占离线任务, 保证在线任务的唤醒时延等.
- 一种思路是为时延敏感的在线任务, 新增一个优先级比 CFS 高的调度类.
暂且称作 background 调度类, 这样在选择 idle 的调度类之前, background 可以兜底了. 各个厂商也都做过类型的尝试. 比如腾讯曾经发往邮件列表的 [BT scheduling class](https://lore.kernel.org/patchwork/cover/1092086), 不过这个版本不完善, 存在诸多问题, 如果大家关注的话, 可以查考查阅 TencentOS-kernel 的 商用版本 [离线调度算法bt](https://github.com/Tencent/TencentOS-kernel#离线调度算法bt).
- 另外一种思路是为时延不敏感的离线任务, 新增一个优先级比 CFS 低的调度类.
[sched: Add micro quanta scheduling class](https://lkml.org/lkml/2019/9/6/178) 在 RT 之后, CFS 之前实现了一个类似于 RT 的策略, 为在线任务提供服务, 来解决同样的问题.
- 当前其实很多情况下使用 SCHED_IDLE 策略也已经能满足我们的基本要求, SCHED_NORMAL 可以抢占 SCHED_IDLE, 而 SCHED_IDLE 的进程也只有在空闲时候才出来蹦跶蹦跶.
特别是在之前提到的 [sched/fair: Fallback to sched-idle CPU in absence of idle CPUs](https://lore.kernel.org/patchwork/cover/1094197) 合入之后, SCHED_NORMAL 的时延已经很低, 其实可以理解为在 SCHED_NORMAL(CFS) 下面又添加了一层时延不敏感的离线任务, 只不过不是使用新增调度类的方式. 而是借助了 CFS 的框架和策略实现.
- 历史上昙花一现的调度算法 ARTiS
历史上昙花一现的调度算法 ARTiS
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
@@ -493,7 +470,7 @@ ARCHLINUX 的开发者 ptr1337, 同样移植了 [CacULE Scheduler](https://githu
参考 [ARCHLINUX Kernel WIKI](https://wiki.archlinux.org/title/kernel).
## 1.5 调度类的一些其他优化点
## 1.6 调度类的一些其他优化点
-------
调度器的演进是 linux 不断发展和完善的风向标之一. 调度器对性能的追求是无止境的, 不光调度本身对性能的影响比较大. 另外一方面, 调度器本身的性能影响也要最小. 于是内核开发者们在这条路上, 不断前行. 调度器的终极目标就是: 用最小的性能开销, 发挥 CPU 的最大能力.
@@ -1213,6 +1190,17 @@ X86 下提供了一种 Fake Numa 的方式来模拟 NUMA 配置.
| 2012/05/01 | Peter Zijlstra <a.p.zijlstra@chello.nl> | [x86/numa: Allow specifying node_distance() for numa=fake](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=ad7687dde8780a0d618a3e3b5a62bb383696fc22) | TODO | v1 ☑✓ 3.5-rc1 | [LORE v1,0/5](https://lore.kernel.org/all/20120501181430.007891123@chello.nl) |
### 4.1.4 NUMA Distance
-------
[NVIDIA Improving Linux NUMA Distance Interface To Enhance Performance](https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-NUMA-Distance-Metrics)
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2022/07/19 | Tariq Toukan <tariqt@nvidia.com> | [Introduce and use NUMA distance metrics](https://lore.kernel.org/all/20220719162339.23865-1-tariqt@nvidia.com) | NVIDIA 工程师一直在 Linux 内核中研究 NUMA 距离指标, 以取代某些驱动程序目前用于 NUMA 感知内存分配的简单本地/远程 NUMA 首选项接口. 在他们的测试中, 这种改进的 NUMA 距离处理对吞吐量和 CPU 利用率产生了"显著的性能影响". 根据调度程序的 sched_numa_find_closest() 实现并公开 CPU spread API sched_cpus_set_spread(). 在给定 NUMA 节点的情况下, 基于距离设置 CPU 分布替代基于 cpumask_local_spread() 的传统逻辑. 在 mlx5 和 enic 设备驱动程序中使用它. 这将使得 NUMA 首选项(本地/远程)替换为考虑实际距离的改进首选项, 因此短距离的远程 NUMA 优先于较远的 NUMA. | v3 ☐☑✓ | [LORE v3,0/3](https://lore.kernel.org/all/20220719162339.23865-1-tariqt@nvidia.com) |
## 4.2 负载均衡总概
-------
@@ -4172,18 +4160,30 @@ v5.0 EAS 合入主线之后, 引入了 EM, 各平台或者设备通过 [em_dev_r
### 7.2.6 IPA(Thermal 管控)
-------
#### 7.2.6.1 Thermal Support
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:-----:|:---:|:----:|:---:|:---------:|:----:|
| 2019/11/01 | Amit Kucheria <amit.kucheria@linaro.org> | [thermal: qcom: tsens: Add interrupt support](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=634e11d5b450a9bcc921219611c5d2cdc0f9066e) | NA | v7 ☑✓ 5.5-rc1 | [LORE v7,0/15](https://lore.kernel.org/all/cover.1572526427.git.amit.kucheria@linaro.org) |
| 2019/10/30 | Quentin Perret <qperret@google.com> | [Make IPA use PM_EM](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=163b00cde7cf2206e248789d2780121ad5e6a70b) | NA | v9 ☑✓ 5.5-rc1 | [LORE v9,0/4](https://lore.kernel.org/all/20191030151451.7961-1-qperret@google.com) |
#### 7.2.6.2 Thermal Tools
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:-----:|:----:|:----:|:----:|:------------:|:----:|
| 2013/10/14 | Jacob Pan <jacob.jun.pan@linux.intel.com> | [TMON thermal monitoring/tuning tool](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=94f69966faf8e70bd655ea25f9dd5b9400567b75) | 实现温控工具 tmon. | v1 ☑✓ 3.13-rc1 | [LORE v1](https://lore.kernel.org/lkml/1381791747-7458-1-git-send-email-jacob.jun.pan@linux.intel.com)<br>*-*-*-*-*-*-*-* <br>[LORE](https://lore.kernel.org/lkml/1381259024-25433-1-git-send-email-jacob.jun.pan@linux.intel.com)<br>*-*-*-*-*-*-*-* <br>[LORE v1](https://lore.kernel.org/all/1381791747-7458-1-git-send-email-jacob.jun.pan@linux.intel.com) |
| 2022/04/20 | Daniel Lezcano <daniel.lezcano@linaro.org> | [tools/thermal: thermal library and tools](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=cb4487d2b4043bbe98f60f2628387b40fa4896f8) | Linaro 提出了一个与 Linux 内核的热框架接口的热库. 作为其中的一部分, 它也是一个用于用户空间的温度计实用程序, 用于监视热数据. 实现了 Netlink 通知机制, 以接收散热配置发现、跳变点更改和违规以及冷却设备更改通知. 这种抽象使用户空间更容易处理 Linux 内核的热框架. 在这个库之上构建的温控工具将允许从通过配置文件指定的一组热区域捕获温度. 这个低开销的工具可以很容易地捕获热数据, 然后集成到其他工具, 如 GNU Plot. 还提供了一个基本的 "散热" 守护程序. 参见 [New Thermal Library, "Thermometer" Tool Proposed For Linux](https://www.phoronix.com/scan.php?page=news_item&px=Linux-Thermometer-RFC), [New Thermal Library & Temperature Capture Tool Readied For Linux 5.19](https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.19-New-Thermal-Lib-Tool) | v3 ☑✓ 5.19-rc1 | [LORE v1,0/4](https://lore.kernel.org/lkml/20220218125334.995447-1-daniel.lezcano@linaro.org)<br>*-*-*-*-*-*-*-* <br>[LORE RFC,v1,1/4](https://lore.kernel.org/lkml/20220214210446.255780-1-daniel.lezcano@linaro.org)<br>*-*-*-*-*-*-*-* <br>[LORE v3,0/4](https://lore.kernel.org/all/20220420160933.347088-1-daniel.lezcano@linaro.org) |
#### 7.2.6.3 Thermal Pressure
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2020/02/21 | Thara Gopinath <thara.gopinath@linaro.org> | [Introduce Thermal Pressure](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=05289b90c2e40ae80f5c70431cd0be4cc8a6038d) | TODO | v10 ☑✓ 5.7-rc1 | [LORE v10,0/9](https://lore.kernel.org/all/20200222005213.3873-1-thara.gopinath@linaro.org) |
### 7.2.5 社区其他相关讨论
-------
@@ -4831,8 +4831,62 @@ enqueue_task_fair()
Xen 的 CPU 调度算法主要有 3 种: BVT(borrowed virtual time)调度算法、SEDF(simple earliest deadline first)调度算法、以及 [Credit 调度算法](https://www.cnblogs.com/linanwx/tag/Xen/).
### 8.9.3 混部场景(在离线)
-------
#### 8.9.3.1 在离线混部基本思路
-------
业务场景中总存在一些对时延敏感但是负载很小的在线任务, 和一些时延不敏感但是负载很大的离线任务. 单独使用 isolation 等为时延敏感的业务分配 CPU 是比较浪费 CPU 资源的, 因此这些业务往往混部在一起. 然而, 现有的实现在混部后在线业务的服务质量下降严重.
虽然内核提供了 SCHED_BATCH 和 SCHED_IDLE 两种优先级比较低的调度算法, 但它们仍然和CFS共用相同的实现, 尤其是在负载均衡时是未做区分的, 它们是没有完全的和CFS隔离开来, 所以效果上面介绍的通用方案存在类似的问题.
其实, 在大家看来, 专门为这些应用新增一个调度类也是一个不错的想法, 通过各个调度类的优先级次序, 原生可以保证在线任务直接抢占离线任务, 保证在线任务的唤醒时延等.
- 一种思路是为时延敏感的在线任务, 新增一个优先级比 CFS 高的调度类.
暂且称作 background 调度类, 这样在选择 idle 的调度类之前, background 可以兜底了. 各个厂商也都做过类型的尝试. 比如腾讯曾经发往邮件列表的 [BT scheduling class](https://lore.kernel.org/patchwork/cover/1092086), 不过这个版本不完善, 存在诸多问题, 如果大家关注的话, 可以查考查阅 TencentOS-kernel 的 商用版本 [离线调度算法bt](https://github.com/Tencent/TencentOS-kernel#离线调度算法bt).
- 另外一种思路是为时延不敏感的离线任务, 新增一个优先级比 CFS 低的调度类.
[sched: Add micro quanta scheduling class](https://lkml.org/lkml/2019/9/6/178) 在 RT 之后, CFS 之前实现了一个类似于 RT 的策略, 为在线任务提供服务, 来解决同样的问题.
- 当前其实很多情况下使用 SCHED_IDLE 策略也已经能满足我们的基本要求, SCHED_NORMAL 可以抢占 SCHED_IDLE, 而 SCHED_IDLE 的进程也只有在空闲时候才出来蹦跶蹦跶.
特别是在之前提到的 [sched/fair: Fallback to sched-idle CPU in absence of idle CPUs](https://lore.kernel.org/patchwork/cover/1094197) 合入之后, SCHED_NORMAL 的时延已经很低, 其实可以理解为在 SCHED_NORMAL(CFS) 下面又添加了一层时延不敏感的离线任务, 只不过不是使用新增调度类的方式. 而是借助了 CFS 的框架和策略实现.
#### 8.9.3.2 Group Identity(云场景)
-------
在业务的混合部署(延迟敏感型和计算型任务混合部署在同一台实例)场景中, Linux 内核调度器需要为高优先级任务赋予更多的调度机会以最小化调度延迟, 并需要把低优先级任务对内核调度带来的影响降到最低.
基于该场景, Alibaba Cloud Linux 2 提供了 Group Identity 功能, 为 CPU cgroup 新增了配置调度优先级的接口, 且不同优先级的任务具有以下特点:
- 高优先级任务的唤醒延迟最小化.
- 低优先级任务不对高优先级任务造成性能影响. 主要体现在:
- 低优先级任务的唤醒不会对高优先级任务造成性能影响.
- 低优先级任务不会通过 SMT 调度器共享硬件 unit 而对高优先级任务造成性能影响.
Group Identity 功能可以对每一个 CPU cgroup 设置身份标识, 以区分 cgroup 中的任务优先级. Group Identity 核心是双红黑树设计, 在 CFS(Completely Fair Scheduler)调度队列的单红黑树基础上, 新增了一颗低优先级的红黑树, 用于存放低优先级任务.
[Alibaba Cloud Linux/内核功能与接口/Group Identity 功能说明](https://help.aliyun.com/document_detail/338407.html)
#### 8.9.3.3 HUAWEI VIP Thread(终端场景)
-------
华为在终端场景提供了 CONFIG_HW_VIP_THREAD, CONFIG_HUAWEI_SCHED_VIP 两套 VIP 机制. 基本思路差不太多, 都是基于 CFS 调度类提供了一级优先级更高的运行队列, 由于终端上需要保证的关键线程基本只有前台绘帧相关的线程, 因此该 VIP 队列没有使用红黑树, 直接使用 list 维护更关键的业务线程.
其中:
CONFIG_HW_VIP_THREAD 被标记为 static_vip/dynamic_vip, VIP 线程提供了 mutex, rwsem 等锁以及 fork 时的 VIP 传递功能, 锁传递可以有效地防止优先级翻转问题, DYNAMIC_VIP_TYPE 标记的场景都可以被传递. 同时通过 trigger_vip_balance() 提供了简单的负载均衡机制. 系统直接设置的进程被标记为 static_vip, 动态传递出来的线程被标记为 dynamic_vip.
CONFIG_HUAWEI_SCHED_VIP 被标记为 vip_prio, 为 VIP 线程提供了近似于优先级的功能. 同时提供了较为完善的 VIP Load Balance 机制.
# 9 IDLE
-------
study/kernel/01-process/05-schedule/07-cfs/09-pelt/README.md
+56 -23
View File
@@ -662,39 +662,36 @@ Frequency Invariance 通过按照 CPU 频率和实际 capacity 对进程运行
得益于 ARM big.LITTLE 架构和 DynamicIQ 架构在安卓的广泛使用, FIE 和 CIE 的支持, ARM64 走在了其他架构的最前面, 但是 X86_64 服务器虽然更看重吞吐量, 但是对功耗的追求也是永恒的话题, 更何况 X86_64 也有一些低端嵌入式芯片, 因此这组补丁补齐了 X86 架构下 FIE 的支持.
# 12 PELT 5.7@2020 remove runnable_load_avg and improve group_classify
# 12 PELT 5.7@2020 Support frequency invariance for X86
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:---:|:----:|:---:|:---:|:----------:|:----:|
| 2020/2/21 | Vincent Guittot | [remove runnable_load_avg and improve group_classify](https://lore.kernel.org/patchwork/cover/1198654) | 重构组调度的 PELT 跟踪, 在每次更新平均负载的时候, 更新整个 CFS_RQ 的平均负载| V10 ☑ 5.7 | [PatchWork](https://lore.kernel.org/patchwork/cover/1198654), [lkml](https://lkml.org/lkml/2020/2/21/1386) |
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2020/02/21 | Thara Gopinath <thara.gopinath@linaro.org> | [Introduce Thermal Pressure](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=05289b90c2e40ae80f5c70431cd0be4cc8a6038d) | TODO | v10 ☑✓ 5.7-rc1 | [LORE v10,0/9](https://lore.kernel.org/all/20200222005213.3873-1-thara.gopinath@linaro.org) |
# 13 PELT 5.7@2020 Rework the CFS load balance
-------
```cpp
070f5e860ee2 sched/fair: Take into account runnable_avg to classify group
9f68395333ad sched/pelt: Add a new runnable average signal
0dacee1bfa70 sched/pelt: Remove unused runnable load average
6499b1b2dd1b sched/numa: Replace runnable_load_avg by load_avg
6d4d22468dae sched/fair: Reorder enqueue/dequeue_task_fair path
```
之前的负载均衡流程中, 较多的使用了 runnable_load_avg, 但是这也引入了不少问题.
后来 Vincent Guittot 对整个 load_balance 和 numa_balancing 进行了重构和优化.
## 13.1 rework the CFS load balance
-------
| 时间 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:------:|:---:|
| 2019/10/18 | Vincent Guittot | [sched/fair: rework the CFS load balance](https://linuxplumbersconf.org/event/4/contributions/480) | 重构 load balance | v4 ☑ | [LWN](https://lwn.net/Articles/793427), [PatchWork](https://lore.kernel.org/patchwork/patch/1141687), [lkml](https://lkml.org/lkml/2019/10/18/676) |
| 2020/2/21 | Vincent Guittot | [remove runnable_load_avg and improve group_classify](https://lore.kernel.org/patchwork/cover/1198654) | 重构组调度的 PELT 跟踪, 在每次更新平均负载的时候, 更新整个 CFS_RQ 的平均负载| V10 ☑ 5.7 | [PatchWork](https://lore.kernel.org/patchwork/cover/1198654), [lkml](https://lkml.org/lkml/2020/2/21/1386) |
| 2019/2/24 | Mel Gorman | [Reconcile NUMA balancing decisions with the load balancer](https://linuxplumbersconf.org/event/4/contributions/480) | 重构 load balance | v4 ☑ | [LWN](https://lwn.net/Articles/793427), [PatchWork](https://lore.kernel.org/patchwork/cover/1199507), [lkml](https://lkml.org/lkml/2019/10/18/676) |
| | [Accumulated fixes for Load/NUMA Balancing reconcilation series](https://lore.kernel.org/patchwork/cover/1203922) | fix 补丁 | | |
v5.5 版本的 rq->runnable_load_avg 是一个带 weight 加权的 runnable 负载.
其中 [rework the CFS load balance](https://lore.kernel.org/patchwork/patch/1141687) 中
后来 Vincent Guittot 对整个 load_balance 和 numa_balancing 进行了重构和优化. [rework the CFS load balance](https://lore.kernel.org/lkml/1571405198-27570-1-git-send-email-vincent.guittot@linaro.org) 中
[commit b0fb1eb4f04a sched/fair: Use load instead of runnable load in load_balance()](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b0fb1eb4f04a) 将 load_balance 路径下原来使用 RQ runnable_load_avg 的地方都修改成了 load_avg.
[commit c63be7be59de sched/fair: Use utilization to select misfit task](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c63be7be59de) 修改了 misfit task 的路径.
[commit 11f10e5420f6 sched/fair: Use load instead of runnable load in wakeup path](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=11f10e5420f6) 修改了唤醒路径.
## 13.2 remove runnable_load_avg and improve group_classify
-------
接着的 [remove runnable_load_avg and improve group_classify](https://lore.kernel.org/patchwork/cover/1198654), Vincent Guittot 进一步修正了 numa_balance 下使用 runnable_load_avg 的路径. 这组补丁包含了几个 RFC 的补丁, 最后的 Mel Gorman 继续完善了 Vincent Guittot 在 numa balance 上的工作. [Reconcile NUMA balancing decisions with the load balancer v6](https://lore.kernel.org/patchwork/cover/1199507)
[6499b1b2dd1b sched/numa: Replace runnable_load_avg by load_avg](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6499b1b2dd1b) 将 numa_balancing 路径下之前使用 cfs_rq_runnable_load_avg(RQ runnable_load_avg) 的地方全改成了 cfs_rq_load_avg(RQ load_avg).
@@ -704,10 +701,21 @@ Frequency Invariance 通过按照 CPU 频率和实际 capacity 对进程运行
[9f68395333ad sched/pelt: Add a new runnable average signal](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9f68395333ad) 前脚把 runnable_load_{sum|avg} 删掉了, 这个补丁找了一种新的 runnable 计算方式来(runnable_{sum|avg})替代旧的方式. 之前 runnable_load_{sum|avg} 的计算包含了太多作者认为不合适的信息(比如 se 和 group 的 runnable 负载 包含了太多的权重 load_weight 信息), 而作者**更希望 runnable 能体现出等待进程的数量, 这个才能突出反应示 CFS_RQ 上的可运行压力**. 新的 runnable 负载计算方式只在意有多少进程在等待, 而不关心他们的 load_weight, 因此可以理解为该信号跟踪 RQ 上任务的等待压力, 有助于更好地定义 RQ 的状态. 这种计算方式与 load_{sum|avg} 的计算方式是类似的, 这样的好处是, 我们**可以直接将 runnable 的负载和 running 的负载进行比较**. 当任务竞争同一个 RQ时, 它们的可运行平均负载将高于 util_avg, 因为它将包含等待时间(不再包含之前的 load_weight 信息), 我们可以使用这个信号更好地对 CFS_RQ 进行分类.
# 13 背景知识
| 时间 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:------:|:---:|
| 2019/10/18 | Vincent Guittot | [sched/fair: rework the CFS load balance](https://linuxplumbersconf.org/event/4/contributions/480) | 重构 load balance | v4 ☑ | [LWN](https://lwn.net/Articles/793427), [PatchWork](https://lore.kernel.org/patchwork/patch/1141687), [lkml](https://lkml.org/lkml/2019/10/18/676) |
| 2020/2/21 | Vincent Guittot | [remove runnable_load_avg and improve group_classify](https://lore.kernel.org/patchwork/cover/1198654) | 合并到 [Reconcile NUMA balancing decisions with the load balancer v6](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=a0f03b617c3b2644d3d47bf7d9e60aed01bd5b10) 中作为一个 patchset | V10 ☑ 5.7-rc1 | [PatchWork](https://lore.kernel.org/patchwork/cover/1198654), [lkml](https://lkml.org/lkml/2020/2/21/1386) |
| 2019/2/24 | Mel Gorman | [Reconcile NUMA balancing decisions with the load balancer](https://linuxplumbersconf.org/event/4/contributions/480) | 重构 load balance | v4 ☑ 5.7-rc1 | [LWN](https://lwn.net/Articles/793427), [PatchWork](https://lore.kernel.org/patchwork/cover/1199507), [lkml](https://lkml.org/lkml/2019/10/18/676) |
| | [Accumulated fixes for Load/NUMA Balancing reconcilation series](https://lore.kernel.org/patchwork/cover/1203922) | fix 补丁 | | |
# 14 背景知识
-------
## 13.1 进程的最大运行负载
## 14.1 进程的最大运行负载
-------
进程投入运行至今, 如果一直运行那么能达到的负载最大值是多少呢?
@@ -759,7 +767,7 @@ LOAD_AVG_MAX - 1024 + sa->period_contrib = LOAD_AVG_MAX - (1024 - sa->period_con
语义上可以理解为, 最后一个的窗口只运行了 `sa->period_contrib`, 这个窗口不需要衰减.
## 13.2 FIE 和 CIE
## 14.2 FIE 和 CIE
-------
内核当前 PELT 在计算负载的时候, 考虑了两个跟 CPU 性能和频率相关的变量(scale_freq 和 scale_cpu
@@ -823,7 +831,7 @@ scale_delta = scale(delta, scale_freq) = delta * scale_freq / SCHED_CAPACITY_SCA
真正计算 util 的时候, 同时考虑了 FIE 和 CIE.
## 13.3 FI Support
## 14.3 FI Support
-------
| 时间 | 特性 | 描述 | 是否合入主线 | 链接 |
@@ -832,11 +840,36 @@ scale_delta = scale(delta, scale_freq) = delta * scale_freq / SCHED_CAPACITY_SCA
| 2015/8/14 | [Compute capacity invariant load/utilization tracking](https://lore.kernel.org/patchwork/cover/590249) | PELT 支持 Capacity Invariant, 对之前, 对 frequency scale invariance 的进一步优化 | V1 ☑4.4 | [LWN](https://lwn.net/Articles/531853), [PatchWork](https://lore.kernel.org/patchwork/cover/590249), [lkml](https://lkml.org/lkml/2015/8/14/296) |
| 2019/01/16 | [sched/fair: update scale invariance of PELT](https://lore.kernel.org/patchwork/cover/1034952) | v9 ☑ 5.1-rc1 | [v3](https://lore.kernel.org/patchwork/patch/784059)<br>*-*-*-*-*-*-*-*<br> [v9](https://lore.kernel.org/patchwork/cover/1034952) |
## 14.4 Max Frequency Capping Engine (MFCE)
-------
| SCALE | 值 | 描述 |
|:-----:|:--:|:---:|
| topology_get_cpu_scale | per_cpu(cpu_scale, cpu); | 参见 topology_normalize_cpu_scale() -=> topology_set_cpu_scale(), 当前 CPU 硬件所能提供的最大 capacity, 不受频率影响, 不受限频影响. capacity << SCHED_CAPACITY_SHIFT / capacity_scale |
| topology_get_freq_scale | per_cpu(arch_freq_scale, cpu) | 参见 topology_set_freq_scale(), policy->cur << SCHED_CAPACITY_SHIFT) / policy->cpuinfo.max_freq. 当前 CPU 在当前硬件下所能提供的相对于自身的 capacity, 不受频率影响, 不受限频影响.|
# 14 参考资料
举例来说, 小核最大 capacity 512, 对应频率 1.6G, 在当前频率 800M 下能提供的 capacity:
cpu_scale 为 256, freq_scale 为 512.
此外 ANDROID Mainline 还通过 [Max Frequency Capping Engine (MFCE) [commit 0cfe39fe403e ("ANDROID: cpufreq: arch_topology: implement max frequency capping")](https://github.com/aosp-mirror/kernel_common/commit/0cfe39fe403ea6dbe2fdfb38edd36022b35d4d66) 提供了 max-frequency-invariant accounting 的 SCALE 接口 arch_scale_max_freq_capacity()/topology_get_max_freq_scal()
| SCALE | 值 | 描述 |
|:-----:|:--:|:---:|
| NA | per_cpu(max_cpu_freq, cpu) | 参见 topology_set_freq_scale(), 即 policy->cpuinfo.max_freq, CPU 硬件所能提供的最大频率, 不受限频影响. |
| topology_get_max_freq_scale | per_cpu(max_freq_scale, cpu) | 参见 arch_set_max_freq_scale(), (per_cpu(max_cpu_freq, cpu) << SCHED_CAPACITY_SHIFT) / policy->max, CPU 硬件所能提供的最大频率相比较于当前能提供的最大频率(受限频影响的 scale), 该值 ≥ 1024. |
topology_get_max_freq_scale() 是当前 CPU 受到限频影响的缩放比, 通过 [commit ff481da6367e ("ANDROID: sched/fair: add arch scaling function for max frequency capping")](https://github.com/aosp-mirror/kernel_common/commit/ff481da6367e6ab2d54ef27829bd2b54eaee9618) 和 [commit bfc73d183074 ("ANDROID: sched: Update max cpu capacity in case of max frequency constraints")](https://github.com/aosp-mirror/kernel_common/commit/bfc73d183074c72d8e90199e03cbcb98c7fc8357), update_cpu_capacity() 的时候, 会对 cpu_capacity 按照限频做 SCALE, 具体计算如下所示:
$= \frac{cpu\_capacity\_orig \times arch\_scale\_max\_freq\_capacity}{1024}$
$= \frac{cpu\_capacity\_orig \times \frac{cpuinfo.max_cpu_freq \times 1024}{policy->max}}{1024}$
$= \frac{cpu\_capacity\_orig \times cpuinfo\_max\_freq}{policy\_max}$
通过这种方式, rq->cpu_capacity 会受到限频的影响, 从而使得负载均衡路径下感知到 Thermal 等的变化.
# 15 参考资料
-------
[task 的 load_avg_contrib 的更新参考](https://www.codenong.com/cs106477101)