sched/cache: honor migrate_llc_task semantics in active load balance
💡 一句话总结
cache-aware 负载均衡引入了一种叫 migrate_llc_task 的迁移类型，专门把「偏爱某个 LLC（最后一级缓存）的任务」迁回它偏爱的缓存域。但 主动负载均衡（active load balance，均衡失败时由 cpu_stop 停机线程强制执行迁移的那条路径）没有遵循这一语义——它把这类任务当成普通迁移来评估，可能把任务迁到会破坏缓存偏爱的 CPU，或干脆判为「不可迁移」。本补丁让 active_load_balance_cpu_stop() 按 migrate_llc_task 的语义挑选源运行队列，使 cache-aware 迁移在主动均衡路径上与常规均衡一致。属于修复补丁（bugfix），作者未提供性能基准数据。
📋 补丁基本信息
| 项目 | 内容 |
|---|---|
| 补丁类型 | bugfix（修复 cache-aware 主动均衡路径对 migrate_llc_task 语义的遗漏） |
| 状态 | In Review（v2，2026-08-01 提交） |
| 当前版本 | v2 · lore 链接 |
| 版本演进 | v1（08-01 20:17，+23/-3）→ v2（08-01 20:22，同规模），v2 为当前版 |
| 作者机构 | Lu Wang（wanglu.priv@gmail.com） |
| 提交日期 | 2026-08-01（v2） |
| 改动范围 | kernel/sched/fair.c + kernel/sched/sched.h，+23/-3 行，2 文件 |
| 核心函数 | active_load_balance_cpu_stop() / sched_balance_find_src_rq() / migrate_degrades_llc() |
| 原始链接 | lore Message-ID |
📊 速览卡片
🎯 解决什么问题
migrate_llc_task 迁移类型由 Intel Tim Chen / Chen Yu 在 e4c9a4cb244a（"sched/cache: Add migrate_llc_task migration type for cache-aware balancing"）中引入，是 cache-aware 负载均衡（CONFIG_SCHED_CACHE）的核心机制：识别出「任务偏爱某个 LLC」后，在 calculate_imbalance() 里把迁移类型设为 migrate_llc_task，再在 sched_balance_find_src_rq() 中挑选「偏爱目标 CPU 的任务最多」的运行队列。但这个新类型只在常规均衡路径被处理；主动负载均衡路径漏掉了它。
nr_balance_failed 超阈值）时，调度器通过 stop_one_cpu() 触发 active_load_balance_cpu_stop()，由停机线程强制执行迁移。这条路径在选择「从哪个运行队列拉任务」时，对 migrate_llc_task 类型没有对应的分支——它沿用默认的「按负载高低挑 busiest rq」逻辑，而不是按「偏爱目标 LLC 的任务数」来挑。结果：cache-aware 均衡在主动路径上退化为按负载迁移，可能把任务迁离其偏爱的 LLC，破坏缓存局部性；或因 migrate_degrades_llc() 判定而拒绝迁移，使均衡停滞。
- 多 LLC 服务器：现代服务器（多路/多 CCD）有多个 LLC 域。cache-aware 调度让任务长期驻留其偏爱 LLC，减少跨缓存域访问（LLC miss）。
- 触发条件：当某 LLC 域过载、任务被钉住、或
sd域nr_balance_failed反复超过cache_nice_tries+2时，会走主动均衡。此时若不遵循migrate_llc_task语义，要么误迁移（破坏偏爱），要么卡住不迁移（过载无法缓解）。 - 负载特征：线程数多且按 LLC 分布敏感的负载（如 HPC 分解、数据库分区、虚拟化 vCPU 亲和性场景）。
🧩 核心机制
补丁在 active_load_balance_cpu_stop() 的源运行队列选择处补上 case migrate_llc_task，与常规路径（sched_balance_find_src_rq() 中已有的分支）对齐。
sched_balance_find_src_rq() 中已有 case migrate_llc_task：遍历 busiest 组内每个 rq，取 sd->llc_counts[dst_llc]（该 rq 上偏爱目标 LLC 的任务数）最大的作为 busiest。本补丁把同样的选择逻辑补进 active_load_balance_cpu_stop() 的遍历循环。改动很小（+23/-3），本质是把已定义好的迁移类型语义，从一条路径补齐到另一条路径。
| 步骤 | 操作 | 目的 |
|---|---|---|
| 识别类型 | 主动均衡路径读取 env->migration_type == migrate_llc_task | 判断当前是 cache-aware 迁移 |
| 挑源 rq | 按 llc_counts[dst_llc] 选「偏爱目标 LLC 任务最多」的 rq | 迁移不破坏缓存偏爱 |
| 与常规对齐 | 复用 sched_balance_find_src_rq() 的 migrate_llc_task 分支 | 两条均衡路径行为一致 |
🔬 关键代码
以下 diff 逐字取自特性引入 commit e4c9a4cb244a（本地内核 git git show），展示了 migrate_llc_task 类型在常规均衡路径中的处理——本补丁正是把同样的处理补到主动均衡路径。
① 迁移类型定义（e4c9a4cb244a）
enum migration_type {
migrate_load = 0,
migrate_util,
migrate_task,
- migrate_misfit
+ migrate_misfit,
+ migrate_llc_task
};▲ 新增 migrate_llc_task 类型。本补丁要保证它在主动均衡路径也生效。
② 常规路径按「偏爱目标 LLC 的任务数」选源 rq（e4c9a4cb244a）
case migrate_llc_task:
#ifdef CONFIG_SCHED_CACHE
sd_tmp = rcu_dereference_all(rq->sd);
dst_llc = llc_id(env->dst_cpu);
if (sd_tmp && (unsigned)dst_llc < sd_tmp->llc_max) {
unsigned int this_pref_llc =
sd_tmp->llc_counts[dst_llc];
if (busiest_pref_llc < this_pref_llc) {
busiest_pref_llc = this_pref_llc;
busiest = rq;
}
}
#endif
break;▲ 常规均衡路径：对每个 rq 统计 llc_counts[dst_llc]（偏爱目标 LLC 的任务数），取最大者为源。本补丁把此逻辑补进 active_load_balance_cpu_stop() 的对应位置（解读(AI 分析)：补丁改的是 fair.c 中 active_load_balance_cpu_stop() 的 rq 遍历处，与其共享 sched_balance_find_src_rq() 逻辑）。
③ detach_tasks 对 llc 迁移的记账（e4c9a4cb244a）
env->imbalance = 0;
break;
+
+ case migrate_llc_task:
+ env->imbalance--;
+ break;▲ llc 迁移一次只搬 1 个任务（imbalance-- 而非清零），保证按偏爱逐个迁移而非堆负载。
关于本补丁自身 diff 的说明：本补丁（Lu Wang，+23/-3）在 active_load_balance_cpu_stop() 路径补齐上述 case migrate_llc_task 分支。其逐字 diff 未能从 lore 拉取（本次会话 lore MCP 与 raw 端点均不可用），上方针基于特性 commit 的真实 diff + over.db 记录的改动函数（active_load_balance_cpu_stop / sched_balance_rq / migrate_degrades_llc / alb_break_llc / can_migrate_task）推断的机制位置，标记为解读(AI 分析)。
📈 性能影响
migrate_llc_task 的处理一致）。
- on-CPU 视角：改动仅补一个
switch分支，常规路径已存在同类逻辑，主动均衡路径每次迁移多几次llc_counts[dst_llc]读取，开销可忽略（解读(AI 分析)）。 - off-CPU 视角：主动均衡在均衡失败时才会触发，属于低频兜底路径；主要收益不在降低等待，而在避免 cache-aware 场景下误迁移或均衡停滞——这更多是正确性/避免性能退化，而非主动提升。
- 对 cache-aware 场景：修复后，任务在主动均衡下也会按「偏爱目标 LLC」迁移，缓存局部性不被破坏，间接维持既有的 cache-aware 收益。
🔄 方案演进 + 讨论焦点
- 04-01：特性
e4c9a4cb244a合入主线（Tim Chen / Chen Yu，Intel），引入migrate_llc_task。 - 08-01 20:17 v1：Lu Wang 提交本补丁（+23/-3），补 active load balance 路径。
- 08-01 20:22 v2：同日 5 分钟后发 v2（同规模），修正细节后作为当前版。
- 08-03 12:20：Intel Chen Yu 回复参与讨论——Chen Yu 是
migrate_llc_task特性的 co-author，对本修复的语义一致性提出关切/确认。 - 08-03 18:02：作者（wanglu.priv@gmail.com）回应。
- 核心关切：active load balance 路径是否应完全复用
sched_balance_find_src_rq()的migrate_llc_task分支，还是需要额外处理（如alb_break_llc()的交互）？特性作者 Chen Yu 参与确认语义（讨论具体内容以 lore 为准；本处为 over.db 记录的讨论参与方与时间，解读(AI 分析)）。 - 待决：v2 之后是否还有 v3 尚不可知（over.db 最新记录到 08-03 讨论）。
⚠️ 风险与局限
- 改动面小：+23/-3、2 文件，仅补 switch 分支，回归风险低。
- 条件编译：
migrate_llc_task分支在CONFIG_SCHED_CACHE下才生效；未开启 cache-aware 调度的内核零行为变化（no-op）（解读(AI 分析)）。 - 多核扩展性：
llc_counts[dst_llc]是每-sd 计数器，遍历取最大仍 O(组内 CPU 数)，与常规路径一致，无新增串行化。 - 交互风险：主动均衡里还有
alb_break_llc()/migrate_degrades_llc()这些「拒绝破坏缓存迁移」的守卫，需确认新分支不与它们冲突——这是 review 中值得关注的点（解读(AI 分析)）。 - 验证缺口：补丁未提供测试/基准，语义一致性依赖 code review 确认。
🔗 交叉引用
714059f79ff0 sched/cache: Handle moving single tasks to/from their preferred LLC — cache-aware 调度系列配套 commit
Intel Chen Yu review 讨论 — 特性 co-author 对修复的讨论
✅ 关键洞察
- 发现：cache-aware 调度的
migrate_llc_task迁移类型在常规均衡路径已实现，但主动负载均衡（均衡失败兜底路径）漏掉了该语义，会导致 cache-aware 场景误迁移或均衡停滞；本补丁补齐这条路径。 - 证据：特性 commit
e4c9a4cb244a的真实 diff 已核实；补丁改动函数（active_load_balance_cpu_stop/sched_balance_rq等）来自 over.db 记录。无性能基准（作者未提供）。 - 边界：仅在
CONFIG_SCHED_CACHE生效；无 cache-aware 配置时 no-op。 - 风险 / 建议：小改动正确性修复，回归风险低；待确认与
alb_break_llc()守卫的交互、以及补测试/基准；值得关注后续版本与 Intel Chen Yu 的讨论进展。
本站内容均由 AI 基于公开知识辅助生成，仅供学习参考，请勿直接引用作为依据。作者不对信息的准确性、完整性及适用性作保证，亦不对因使用本站内容产生的任何损失承担责任。