Core scheduling support allows userspace to define groups of tasks that can share a core. These groups can be specified either for security usecases (one group of tasks don't trust another), or for performance usecases (++some workloads may benefit from running on the same core as they don't need the same hardware resources of the shared core, or may prefer different cores if they do share hardware resource needs++). This document only describes the security usecase.
Documentation/admin-guide/hw-vuln/l1tf.rst
某些工作负载（workloads）在共享同一个 CPU 核心时可能获得性能提升，前提是它们不竞争相同的硬件资源。以下从计算机体系结构、操作系统调度和微架构资源管理的角度，逐层解析该描述的深层含义 ：
1. CPU 核心的硬件资源共享机制
现代 CPU 核心（尤其是支持 SMT/超线程的）通常由多个执行单元组成，例如：
- 整数运算单元（ALU）
- 浮点运算单元（FPU）
- 向量计算单元（如 AVX/NEON）
- 内存加载/存储单元（Load/Store）
- 分支预测单元（Branch Prediction）
- 缓存（L1/L2 Cache）
如果两个任务（Task A 和 Task B）使用的硬件资源不重叠，例如：
- Task A 主要使用 整数运算（ALU） 和 分支预测
- Task B 主要使用 浮点运算（FPU） 和 向量计算（AVX）
那么它们可以并行执行，而不会因为竞争相同的硬件资源而降低性能。此时，让它们共享同一个核心（如超线程环境下的两个逻辑 CPU）可以提高整体吞吐量。
2. 避免资源争用（Resource Contention）
如果两个任务需要相同的硬件资源，例如：
- Task A 和 Task B 都大量使用 AVX-512 指令（高功耗、高带宽需求）
- Task A 和 Task B 都频繁访问 L1/L2 缓存（导致缓存颠簸）
那么它们共享核心会导致性能下降 ，因为 CPU 必须动态分配资源，可能造成：
- 执行单元争抢（如两个任务同时需要 FPU，但 FPU 数量有限）
- 缓存抖动（Cache Thrashing，两个任务频繁替换对方的数据）
- 前端解码瓶颈（如两个任务都占用大量指令解码带宽）
因此，核心调度（Core Scheduling） 需要智能判断：
- 哪些任务可以共享核心（互补型任务） → 提升性能
- 哪些任务应该隔离（竞争型任务） → 避免性能下降
3. 实际应用场景
（1）互补型任务（适合共享核心）
-
计算密集型 + I/O 密集型
- 例如：一个任务做数学计算（FPU 密集），另一个任务处理网络包（内存/IO 密集）
- 它们不会竞争相同的执行单元，可以高效共享核心。
-
整数计算 + 浮点计算
- 例如：一个任务处理逻辑判断（ALU 密集），另一个任务做科学计算（FPU 密集）
- 它们可以并行执行，提高 CPU 利用率。
（2）竞争型任务（不适合共享核心）
- 两个 AVX-512 密集型任务
- AVX-512 会占用大量执行单元和功耗，共享核心会导致性能下降。
- 两个内存带宽密集型任务
- 如果都频繁访问内存，会导致缓存争用，增加延迟。
4. 与安全隔离（Security Usecase）的关系
虽然本文档主要讨论安全隔离 （防止不可信任务共享核心，避免侧信道攻击如 Spectre/Meltdown），但性能优化同样重要：
- 安全隔离：强制某些任务不能共享核心（即使它们可以互补）。
- 性能优化：允许某些任务共享核心（如果它们不竞争资源）。
理想情况下，调度器应同时考虑安全和性能，动态调整任务分组策略。
总结
- 互补型任务（不竞争资源） → 共享核心可提高 CPU 利用率，提升性能。
- 竞争型任务（需求相同资源） → 共享核心会降低性能，应隔离到不同核心。
- 核心调度的目标：在安全隔离的基础上，智能匹配任务组合，最大化系统效率。
这种优化在云计算、HPC、实时系统等场景尤为重要，因为错误的调度策略可能导致显著的性能损失。