进程调度与 EEVDF

• 理解 sched_latency 决定一个队列中所有任务都至少被调度一次的时间目标
• 理解 sched_min_granularity 防止进程被过度频繁切换引入的开销
• 掌握两者在任务数量变化时的动态关系与目标延迟计算

在 CFS 中，sched_latency 是一个理想时间窗口，表示在理想情况下所有可运行任务都各获得一次运行的时间长度，也是调度器"目标延迟"。默认值通常为 6ms（Linux 上 sysctl_sched_latency）。sched_min_granularity 是单个任务一次运行的最小时间片，默认通常为 0.75ms，防止任务切换过频导致调度开销过大。当可运行任务数量增加时，目标延迟会按任务数分摊：每个任务获得的时间片 = sched_latency / nr_running。但当 nr_running * sched_min_granularity 超过 sched_latency 时，每个任务的时间片会被限制在 sched_min_granularity，此时实际调度周期会超过 sched_latency。工程上，若增大 sched_latency 会减少切换开销、提高吞吐，但降低交互任务的响应性；若减小则响应更快但消耗更多 CPU 在切换上。因此需要根据负载特征权衡：延迟敏感负载倾向小延迟，吞吐型负载倾向大延迟。

这组参数本质是"公平性"与"切换开销"之间的折中。CFS 用 vruntime 实现公平，但每次切换都有成本，因此必须用最小粒度约束切换频率，用目标延迟定义公平吞吐的粒度。理解它们的关系（period = max(sched_latency, nr_running * sched_min_granularity)）是排查调度响应问题的基础。

• 理解 virtual time 对应任务获得的服务量
• 理解 eligible time 与 virtual deadline 定义任务可被调度的时间窗口
• 理解 lag 反映任务相对公平份额的落后或超前

EEVDF 在 CFS 的 vruntime 框架基础上引入更精确的调度决策。virtual time（虚拟时间）衡量任务实际获得的 CPU 服务量，按权重归一化。eligible time 是任务最早可以被调度的时间，即任务获得应得服务到达的时间点；virtual deadline 是任务"最晚"被调度的时间，按权重计算：deadline = eligible + delta，其中 delta 与任务权重成反比。调度器选择具有最早 virtual deadline 且已 eligible 的任务。lag 表示任务当前实际服务量相对其公平份额的偏差，lag > 0 表示超前（获得服务过多），lag < 0 表示落后。当任务睡眠时，超出其应得份额的 surplus 会被"回收"到整个调度器，从而抑制睡眠取巧（sleep hack）行为。

EEVDF 相比 CFS 的彻底公平调度，关键在于它显式地追踪每个任务相对公平的"落后程度"，从而让延迟敏感任务通过充分利用其应得份额获得更低延迟，同时防止任务通过睡眠等手段窃取带宽。lag 的回收机制是它优于 CFS 的重要点。

• 理解 SCHED_DEADLINE 使用 runtime、deadline、period 三元组描述任务
• 理解 CBS 如何通过预算充值机制防止任务超时运行
• 理解 CBS 与 EDF 的结合方式

SCHED_DEADLINE 是 Linux 的硬实时调度策略，基于最早截止时间优先（EDF）并结合 CBS 服务器机制。每个任务用三个参数描述：runtime（每个周期内最多运行的 CPU 时间）、deadline（截止时间）、period（周期）。CBS 维护一个"预算"，每当任务运行时预算递减，当一个周期内预算耗尽或当前虚拟截止时间已过，就会重置预算并推进虚拟截止时间。当任务在上限（runtime/period，即最大 CPU 占用率）内运行，它总能获得 WCET 保证；若任务超过设定的 runtime，CBS 会将其降级为被节流（throttled）状态，从而隔离其他实时任务，防止一个任务耗尽系统资源。调度器始终选择 virtual deadline 最早且有空余预算的任务执行。

CBS 的核心价值是"带宽隔离"——它把每个任务的服务需求封装在固定的预算内，即使任务运行超时，也不会破坏其他实时任务的截止时间保证。这对音频、视频、运动控制等硬实时场景至关重要，因为 EDF 单独使用在任务超时时会连锁破坏所有截止时间。

• 理解 cpu.max 提供绝对带宽上限（quota/period）
• 理解 cpu.weight 提供相对权重分配
• 理解两者如何协同影响 CPU 分配

cgroup v2 的 cpu.max 以 "quota period" 形式给出一个 cgroup 内所有任务可以使用的最大 CPU 时间比例，例如 50000 100000 表示在 100ms 周期内最多运行 50ms，即最多使用 50% 的 CPU。这是绝对上限，即使系统空闲也不能超过。cpu.weight 则是一个相对权重，范围为 1-10000，默认 100，在 CPU 竞争时决定各子 cgroup 按权重比例分配 CPU。两者可以同时存在：当系统 CPU 空闲时，即使有 cpu.max 限制，任务也不能超过上限；而当 CPU 竞争激烈时，cpu.weight 决定空闲带宽的分配比例。二者结合可以提供"保底"与"封顶"的双重控制。

cpu.max 是硬性上限（cap），用于保证其他租户或重要任务的资源；cpu.weight 是软性比例（share），用于在资源充裕时按需分配。理解二者是服务编排与资源隔离的核心，也解释了为什么同一 cgroup 同时设置两者时行为不同。

• 理解 nice 值越大优先级越低
• 理解 nice 值到权重的映射关系（约 1.25 倍）与静态优先级
• 理解 O(1) 调度器使用 140 个优先级队列数组

nice 值范围是 -20 到 19，数值越大表示越"友好"、优先级越低。在 Linux 中，静态优先级 static_prio = 120 + nice，因此 nice 为 0 对应静态优先级 120，nice 为 -20 对应 100，nice 为 19 对应 139。O(1) 调度器维护 140 个优先级队列（0-99 为实时优先级，100-139 为普通优先级），每次调度 O(1) 地在活跃队列中选取最高优先级任务。nice 值到权重的映射遵循近似 1.25 的比率：每增加 1 个 nice 值，任务的 CPU 份额约减少 1.25 倍（即权重约除以 1.25），整个范围（-20 到 19，共 40 级）两端权重相差可达数千倍。优先级更高的任务会优先被选择，而权重则用于共享剩余 CPU 的按比例分配。

nice 值既决定调度优先级（谁先被选中），也决定权重（CPU 份额比例）。O(1) 调度器用固定优先级数组实现 O(1) 查找，但牺牲了公平性，后来被 CFS 的 vruntime 红黑树取代。理解这种映射是理解从 O(1) 到 CFS 演进的关键。

• 理解 SCHED_FIFO 一旦运行就持续运行直到主动让出或更高优先级任务到达
• 理解 SCHED_RR 为同优先级任务轮转分配时间片
• 理解实时优先级范围 1-99 及抢占规则

SCHED_FIFO 与 SCHED_RR 都用于实时任务，优先级范围为 1-99（数值越大越优先）。SCHED_FIFO 下，一个运行中的任务会持续运行直到它主动阻塞（如 sleep、I/O）或主动让出 CPU，或者有更高优先级的实时任务到达；同优先级的 FIFO 任务之间没有抢占，前一个不退出，后一个只能等待。SCHED_RR 在 FIFO 基础上增加了时间片概念：同优先级的多个任务按时间片轮转，时间片耗尽后切换到下一个同优先级任务，从而保证同优先级任务都能获得运行。两者都属于可抢占的实时调度，但 FIFO 允许多个同优先级任务无限期阻塞彼此，RR 则保证公平轮转。

选择 FIFO 还是 RR 取决于对同优先级任务的处理需求。FIFO 适合一个任务独占 CPU 完成关键工作，RR 适合多个同优先级任务需要轮流处理。需要注意实时任务优先级高于所有普通任务，设计不当会饿死普通任务，因此生产环境需谨慎。

• 理解 sched_setaffinity 通过 CPU 位图限制任务可运行的 CPU 集合
• 理解亲和性对缓存局部性与 NUMA 本地内存访问的影响
• 理解 NUMA 节点绑定与 CPU 亲和性的区别

sched_setaffinity 系统调用允许为进程或线程设置 CPU 亲和性掩码，即允许该任务运行在哪些 CPU 上。调度器只会把任务调度到掩码允许的 CPU 上，这可以提高 CPU 缓存局部性，避免任务在 CPU 间迁移导致缓存失效。在 NUMA 架构下，CPU 亲和性还能限定任务运行在特定 NUMA 节点的 CPU 上，从而保证其内存访问主要发生在本地节点，降低跨节点内存访问延迟。但亲和性本身不分配内存，NUMA 内存分配由 mempolicy（如 MPOL_BIND）控制。实际工程中，若要绑定到 NUMA 节点，通常同时设置 CPU 亲和性（sched_setaffinity）与内存策略（set_mempolicy/numactl）。

CPU 亲和性是软性约束，调度器会尽量遵守但可能因负载均衡而适度迁移；NUMA 绑定则更进一步，配套内存策略才能保证数据本地性。理解二者对数据库、网络等服务的高性能调优至关重要。

• 理解 sched_domain 按拓扑层级（SMT、双核、NUMA 节点等）组织
• 理解不同层级使用不同 flags 与均衡策略
• 理解负载均衡的遍数与层级的关系

sched_domain 是 Linux 调度器按 CPU 拓扑分层构建的调度域层级结构。每个调度域由若干 CPU 组成，由底层向上通常是：SMT 线程对（PERF 域）、同核、同 NUMA 节点、整个系统。每个调度域有独立的调度组（sched_group）与调度标志（flags），控制该层级的负载均衡行为。负载均衡发生时，调度器从最底层向上逐层进行，在每层内把负载从高负载组迁移到低负载组。层级感知体现在：均衡优先在同层内进行，避免跨层迁移造成缓存与存储层次损失。例如，优先在 SMT 线程间平衡，其次在核间，最后才跨 NUMA 节点，因为跨 NUMA 迁移会引入远程内存访问代价。

多级调度域的设计本质是"就近均衡"——在就近的 CPU 间先平衡，把昂贵的跨节点迁移作为最后手段。这既保证了整体负载均衡，又尽可能保留缓存与内存局部性。理解它在 NUMA 性能调优和容器绑核场景中很重要。

• 理解 schedstats 提供 runqueue wait time、调度次数等统计
• 理解 perf sched 的 latency、record/replay 等子命令
• 理解如何定位调度延迟问题

schedstats 是内核的调度统计功能（通过 /proc/sys/kernel/sched_schedstats 启用），为每个任务记录运行队列等待时间、调度次数、抢占次数等，可从 /proc/ /sched 或 /proc//schedstat 读取。perf sched 是 perf 工具提供的调度分析子命令：perf sched record 记录调度事件，perf sched latency 汇总每个任务的调度延迟分布（wait time、avg latency、max latency），perf sched timehist 输出逐任务时间线，perf sched replay 用记录重放以测试调度器。通过观察高等待时间任务，可以定位是 CPU 竞争、任务优先级过低还是负载均衡不足导致的调度延迟。

调度延迟是性能问题的常见来源。先看 schedstats 的 runqueue 等待时间判断是否排队，再用 perf sched 的延迟分布确定具体任务与趋势，从而针对性调优（调整优先级、亲和性、cgroup 限额）。这是系统性能工程师的常用诊断流程。

• 理解 CFS 的公平调度与 sleep 补偿问题
• 理解 CFS 无法精确控制任务调度的及时性
• 理解 EEVDF 如何通过虚拟截止时间改善延迟

CFS 通过 vruntime 红黑树实现"完全公平"，但存在明显不足：一是 sleep 补偿问题，任务睡眠时其 vruntime 停止增长，醒来后会因 vruntime 落后而获得补偿，导致任务可以通过频繁睡眠"取巧"抢占 CPU；二是它只保证长期公平，无法精确控制某个任务何时被调度，延迟敏感任务（如音频、数据库、交互应用）可能等待过长；三是 CFS 的 pick_next 选择 vruntime 最小的任务，但缺乏对"任务应得服务窗口"的显式建模。EEVDF 引入 eligible time 与 virtual deadline，使调度器能精确选择"该轮到谁"的任务，并回收 sleep 任务超额获得的带宽，从而在保持公平的同时改善延迟敏感任务的响应。

EEVDF 的动机是"公平与延迟并重"。它把 CFS 的语义从"平均分摊"推进到"按时分摊"，通过 deadline 让任务在应得时间内被调度，同时用 lag 回收堵塞 sleep hack，这是对 CFS 调度公平与延迟权衡的系统性改进。

• 理解 EEVDF 在 6.6 内核成为默认调度器
• 理解 EEVDF 与 CFS 在算法与用户可见行为上的差异
• 理解可用的回退方式

Linux 6.6 内核将 EEVDF 设为默认的公平调度器，取代了自 2.6.23 以来沿用的 CFS。EEVDF 仍基于 vruntime 的公平框架，但选择标准从"vruntime 最小者"改为"virtual deadline 最早且 eligible 者"，并引入 lag 追踪与回收机制。对用户而言，多数调度行为（nice 值、权重、cgroup cpu.weight）保持兼容，但延迟敏感任务的响应与公平性行为有所改善，且 sleep 取巧收益被削弱。若需回退到旧 CFS 行为，可通过内核启动参数 sched_eevdf=off 或相关 sysctl 关闭 EEVDF。新旧对比的关键在于：CFS 是完全"公平累积"的，EEVDF 是"公平 + 及时性 + 反取巧"的。

这一默认变更说明内核调度器的发展方向是把延迟保证纳入公平调度。对应用开发者而言，EEVDF 的默认启用意味着交互式与延迟敏感应用无需额外配置即可获得更好响应，同时恶意 sleep 补偿行为被抑制。

• 理解 sched_yield 在 CFS/EEVDF 中的行为（放入队列尾部/虚拟时间补偿）
• 理解它只让出给更高优先级任务
• 理解其与传统 yield 语义的差异

传统上 yield 语义是"让出 CPU 给其他任务"，但 Linux 的 sched_yield 语义被弱化。在普通公平调度（CFS/EEVDF）下，sched_yield 只是把当前任务放到运行队列中合适的位置，实际效果是让出给优先级更高或同等竞争的任务，而如果所有任务优先级相同，它可能立即再次被选中，即"让出后立刻又回来"，并不保证其他任务获得运行机会。在实时调度中，sched_yield 会尝试让出给同优先级或更高优先级的实时任务。因此 sched_yield 不能保证"其他任务运行"，而应视为"提示调度器重新选择"。在 EEVDF 下，sched_yield 还会给调用者一个虚拟时间惩罚，使其让出后不会立即被重新选中。

理解 sched_yield 的弱语义很重要，靠它实现"让出"会导致 busy-wait 或错误设计。生产代码应使用条件变量、futex、cond_wait 等同步原语而非 sched_yield。这也是一个容易踩坑的经典面试点。

• 理解 EEVDF 对延迟敏感任务的响应改善
• 理解音频播放、数据库查询等场景的典型延迟指标
• 理解收益的边界与约束

在音频、数据库等延迟敏感负载上，EEVDF 的实测收益主要体现在更低的调度延迟与更稳定的响应。音频任务（如 JACK、PipeWire）需要周期性的低延迟唤醒，EEVDF 通过虚拟截止时间让这类任务在应得窗口内被及时调度，减少错过帧导致的声音卡顿（underrun）。数据库任务（如 PostgreSQL、MySQL）的查询与事务处理需要快速响应，EEVDF 降低了因公平性导致的偶发长等待，减少了请求延迟的尾部延迟（tail latency）。总体而言，EEVDF 在同等负载下可降低调度等待时间、改善最坏情况延迟，并抑制 sleep 型任务的带宽窃取。但其收益受负载竞争程度、任务数、nice 配置影响，在 CPU 极度饱和时仍可能延迟。

EEVDF 的收益源于其"及时性"模型——它把任务的调度窗口显式化，使延迟敏感任务能更早地被选中。对追求稳定低延迟的应用（实时音频、数据库、交易系统），这是从调度器层面获得的优化，但需结合真实负载测试验证。

• 理解 vruntime 的加权定义与更新逻辑
• 理解红黑树按 vruntime 排序的组织结构
• 理解 pick_next 与 sleeper 唤醒的流程

CFS（Completely Fair Scheduler）以虚拟运行时间 vruntime 为核心实现公平调度。每个任务的 vruntime 代表其获得的"虚拟 CPU 时间"，计算公式为 vruntime += 实际运行时间 * (NICE_0_LOAD / weight)，即权重越大的任务 vruntime 增长越慢。所有可运行任务按 vruntime 值组织在一棵红黑树中，树的左子树是最小 vruntime。调度器 pick_next 时选择红黑树中最左节点（vruntime 最小）运行，从而实现"谁获得服务最少，谁优先运行"。任务唤醒时会重新插入红黑树，sleeper 会获得 vruntime 补偿（防止被饿死）。任务被抢占或 sleep 后重新排队。由于 vruntime 单调增长，CFS 需要处理 vruntime 溢出，通过把最小 vruntime 作为基准来"归一化"。

红黑树保证插入/删除/查找 O(log n)，按 vruntime 选出最应运行的任务，是"把公平建模为最小累积服务者优先"的经典实现。理解 vruntime 的加权计算与红黑树结构是理解 CFS 及后来 EEVDF 的基础。

• 理解 sched_setattr 传入的 sched_attr 结构体
• 理解 policy（SCHED_OTHER、FIFO、RR、DEADLINE）与 sched_priority、sched_runtime 等属性
• 理解 sched_setattr 的原子性与扩展性

sched_setattr 是设置线程调度策略与属性的现代系统调用，相比 sched_setscheduler 的优势是能通过 sched_attr 结构体一次性设置多个属性，并且支持 SCHED_DEADLINE 等新策略。sched_attr 包含 sched_policy（调度策略，如 SCHED_OTHER/normal、SCHED_FIFO、SCHED_RR、SCHED_DEADLINE、SCHED_BATCH、SCHED_IDLE）、sched_priority（用于实时策略的优先级，1-99）、sched_runtime/sched_deadline/sched_period（用于 SCHED_DEADLINE 的参数）、sched_nice（用于普通策略）以及 sched_flags（如 SCHED_FLAG_RESET_ON_FORK）。调用时通过 sched_attr 与 size 参数，内核按位处理，支持在用户态声明扩展字段。SCHED_DEADLINE 需要 CAP_SYS_NICE 权限。

sched_setattr 的"填充结构体 + 拓展字段"设计使其成为可扩展的调度接口，是新调度策略（尤其 DEADLINE）的标准入口。相比旧接口，它原子性地设置策略与参数，避免中间不一致状态。

• 理解 BORE 是 EEVDF 上的一个增强补丁
• 理解 BORE 通过 burst 感知调整任务优先级
• 理解 BORE 的适用场景与取舍

BORE（Burst-Oriented Response Enhancer）是社区针对 EEVDF 的一个增强补丁，它通过识别任务的"突发计算活跃度"（burst）来动态调整其调度优先级，从而改善交互式与延迟敏感任务的响应。BORE 的核心思想是：任务在短期内持续活跃（burst）说明其处于忙碌的关键处理阶段，应给予更高的调度权重；而空转/睡眠较多的任务则降低权重。BORE 在 EEVDF 基础上引入 burst 感知的 vruntime 修正，使处于突发状态的任务能更早被选中，从而降低桌面、游戏、交互应用的响应延迟。它常以内核补丁或发行版（如 CachyOS 等）的形式提供，默认关闭或可配置。

BORE 是"调度器微调"的典型代表，它把 EEVDF 的公平语义与"突发活跃度的及时性"结合，牺牲少许公平性换取更佳的交互响应。对桌面与游戏场景收益明显，但对严格公平的服务器负载需谨慎评估。

• 理解 idle task 是每个 CPU 在无任务时运行的调度实体
• 理解 NO_HZ 减少 tick 中断以省电
• 理解 idle balancing 与 nohz idle 的唤醒均衡

Idle task（swapper 进程）是每个 CPU 上优先级最低的调度实体，当运行队列为空时运行，它主要执行进入低功耗状态（idle loop）与检查是否有新任务入队。NO_HZ（tickless idle）模式下，当 CPU 空闲时内核会停止周期性 tick 中断，以降低功耗与唤醒开销，这也意味着空闲 CPU 无法通过自身 tick 主动参与负载均衡。为此，内核引入 idle balancing（空闲负载均衡）：当一个 CPU 将要进入空闲时，会在"空闲 CPU 集合"中登记，其他 CPU 发现新任务时，会通过 wake affine 或周期性检查（由非空闲 CPU 的 tick 触发）把任务迁移到空闲 CPU 上运行，从而避免空闲 CPU 闲置而其他 CPU 排队。NO_HZ 的负载均衡由剩余的非空闲 CPU 承担。

NO_HZ 省电与负载均衡是一对矛盾：空闲 CPU 不再 tick，就无法主动找活，因此需要"他人"把任务推过来。理解 idle task + idle balancing + nohz 的配合，是掌握现代省电调度与多核负载均衡的关键。

• 理解优先级反转的定义与危害
• 理解 priority inheritance 与 priority ceiling 的方法
• 理解 Linux 的 rt_mutex 实现

优先级反转是指高优先级任务因等待低优先级任务持有的资源（如锁）而被阻塞，而低优先级任务又被中优先级任务抢占，导致高优先级任务被间接"拖住"的经典问题。在 Linux 中，内核通过 rt_mutex（实时互斥锁）实现优先级继承：当一个高优先级任务阻塞在低优先级任务持有的锁上时，低优先级任务会临时"继承"高优先级任务的优先级，避免被中优先级任务抢占，从而尽快释放锁，让高优先级任务继续运行。除 RT 任务外，内核的普通 mutex 也支持优先级继承（通过 rt_mutex 实现），用于缓解实时系统中优先级反转。另一种方法是 priority ceiling（优先级上限），即锁被赋予一个固定高优先级，所有持锁任务都以该优先级运行。Linux 主要采用优先级继承方案。

优先级反转是实时系统正确性的关键，继承机制通过"临时提升持锁者优先级"来破局。理解 rt_mutex 与继承逻辑，是分析实时任务卡顿与锁竞争问题的核心。