Linux 内核调度子系统周报（2026-06-29 ~ 2026-07-05）

本期重点

1. 1. Andrea Righi 提出 proxy execution 与 sched_ext 共存方案 v2——打破 CONFIG_SCHED_PROXY_EXEC 与 CONFIG_SCHED_CLASS_EXT 的编译期互斥，引入 per-scheduler 的 SCX_OPS_ENQ_BLOCKED 能力位，把 donor→owner 的执行权交接建模成"函数调用"，donor 仍是 BPF 视角的运行实体，owner 仅作核心内部的执行上下文替换。
2. 2. Tejun Heo 为子调度器引入 capability-based CPU 委派模型（32 补丁）——把 sub-scheduler 的 CPU 访问控制从仅 dispatch 路径扩展到 enqueue、占用、kick/preempt、idle 上报全部路径，用 SCX_CAP_ENQ_IMMED/ENQ/PREEMPT 三级能力位 + 分片 cmask 表达父子调度器间的 CPU 归属与让渡。
3. 3. Mark Rutland 简化 PREEMPT_DYNAMIC，正式淘汰 NONE/VOLUNTARY 模型——让 PREEMPT_DYNAMIC 依赖 ARCH_HAS_PREEMPT_LAZY，删除自 v7.0 起就已不可达的 NONE/VOLUNTARY 相关代码，x86_64 bzImage 缩小 28K、净删 367 行。
4. 4. EAS 解除对 schedutil governor 的硬依赖——Lucas de Lima Nóbrega 的补丁允许在 root domain 内所有 EM 均为 EM_PERF_DOMAIN_ARTIFICIAL 时启用 EAS，使 intel_pstate active/HWP 和 cppc_cpufreq 这类只编码成本排序、不预测真实功耗的场景也能用上 find_energy_efficient_cpu()。
5. 5. EEVDF reweight 的 avruntime 单向漂移问题被曝光（RFC）——华为 Chen Jinghuang 指出 reweight_entity() 里 entity_lag() 的边界 limit 在频繁 cgroup reweight 下累积非对称截断误差，导致运行实体的 vruntime 被单向压低、全局 avruntime 漂移、甚至抑制 entity_tick 的正常抢占。

一、核心进展

proxy execution 与 sched_ext 共存

原文^[1]

proxy execution 让等待 mutex 的任务（donor）把执行上下文捐给锁持有者（owner），让 owner 在 donor 仍留在运行队列、保持运行资格的同时往前跑。当前 CONFIG_SCHED_PROXY_EXEC 和 CONFIG_SCHED_CLASS_EXT 在编译期互斥，发行版想用一个内核同时在运行时选特性时受阻。

互斥的根源在于两条路径对"谁在运行"的理解不一致：sched_ext 通过自己的 dispatch 接口和 DSQ 驱动任务派发，proxy 的 handoff 可能让一个 BPF scheduler 从未 dispatch 过的任务跑起来，于是 sched_ext 回调看到的 current 与 BPF 侧认定的运行任务对不上，kfuncs 和 helper 状态读到不一致视图；DSQ 的 vtime、排序也会和核心实际执行的任务脱节。

Andrea Righi 的 v2（10 补丁，基于 John Stultz 早期工作）把 proxy 支持做成 per-scheduler 的可选能力：BPF scheduler 设置 SCX_OPS_ENQ_BLOCKED 才接收被 mutex 阻塞的任务，不设则 mutex 等待者按常规阻塞、proxy execution 自动禁用。设了该位时，阻塞 donor 经 ops.enqueue() 上报，BPF 用 scx_bpf_task_is_blocked() 识别并应用自己的准入和排序策略；想知道 owner 位置的可调 scx_bpf_task_proxy_cpu()/scx_bpf_task_proxy_cid() 把捐献引导到 owner 所在 CPU，核心仍会重新校验 owner 关系再做实际迁移。

设计上把 donor→owner 的交接建模成"函数调用"：donor 仍是 BPF 选中的运行调度实体，其调度上下文、运行时间、slice 被消耗，核心只是临时调用 owner 的代码让临界区推进，这不是一次 scheduler 可见的任务切换。调度状态记到 rq->donor，rq->curr 标识执行上下文，owner 的内部替换不为 BPF 未 dispatch 的任务产生合成回调。配套的 scx_qmap 改造演示了 opt-in 策略，新 kselftest enq_blocked 用三任务优先级反转（nice +19 owner / nice -20 donor / nice 0 竞争者）验证，开启后 mutex 等待时间下降约 18%。

子调度器的 capability-based CPU 委派

原文^[2]

sched_ext 现有的 sub-scheduler 支持只覆盖了调度的一部分：子调度器可挂到另一个 scx_sched 的 cgroup 子树下，dispatch 路径通过 scx_bpf_sub_dispatch() 做自上而下的程序化委派。但 enqueue 路径尚未实现，层级里每个调度器都能往任意 local DSQ 插入任务，父调度器无法在子调度器间划分 CPU、也无法保护自己的份额。

Tejun Heo 这组 32 补丁补上 enqueue 路径的控制，并把同样的控制扩展到所有触及 CPU 访问的路径：占用、kick/preempt、idle 上报。enqueue 没法照搬 dispatch 的程序化模型——dispatch 自上而下、委派隐含在调用链里；enqueue 从另一端开始，叶子调度器为任务选 cid，它能用哪些 cid 是所有祖先委派决定的累积结果，每次 enqueue 都做跨调度器往返调用代价过高。因此委派被设计成状态而非调用：

• • 归属按 (scheduler, cid) 用一组能力位跟踪：SCX_CAP_ENQ_IMMED（往 cid 的 local DSQ 插 IMMED 任务，是任何 CPU 使用的基础能力 SCX_CAP_BASE）、SCX_CAP_ENQ（插入任意任务）、SCX_CAP_PREEMPT（抢占本子树之外的任务）。高层能力隐含低层。
• • root 拥有每个 cid 上的全部能力；父用 scx_bpf_sub_grant() 把能力下放给子，用 scx_bpf_sub_revoke() 收回；子的能力集永远是父的子集，且仅靠隐含持有的能力不能再下放。
• • 能力状态分片：cid 空间按拓扑对齐切成多个 shard，每个调度器在 per-shard 的 cmask 里记录能力、配 per-shard 锁，操作按 shard 边界拆分，不同 shard 不产生争用。
• • 热路径用 per-cpu 的 effective-caps 副本单次读取判断；grant/revoke 触发 per-cpu doorbell， owning CPU 在 balance() 顶部把新配置折叠进来，跨调度器通信只在委派集合变化时发生。

强制执行层面，缺少所需能力的插入会被改道到一个内核内部的 per-rq reject DSQ，再交还 BPF scheduler 重新决策，任务打上 SCX_TASK_REENQ_CAP 和缺失的能力位；revoke 通过同样的重入路径驱逐已排队和正在运行的任务；CPU 占用与 task slice 绑定，延长 slice 需要该 CPU 的 baseline 访问；kick 在投递时强制，SCX_KICK_PREEMPT 在越界且无 SCX_CAP_PREEMPT 时降级为普通 reschedule。scx_qmap 的层级 demo 演示了按 cpu.weight 比例划分全权 CPU、轮转共享取整余量、并支持向未持有 cid 故障注入 dispatch 来验证内核侧强制。原文^[2]

PREEMPT_DYNAMIC 简化：NONE/VOLUNTARY 正式退出

原文^[3]

自 v7.0 的 7dadeaa6e851（"sched: Further restrict the preemption modes"）以后，选了 ARCH_HAS_PREEMPT_LAZY 的架构上已无法再选 NONE 和 VOLUNTARY 抢占模型。而当前所有支持 PREEMPT_DYNAMIC 的架构（arm64、loongarch、powerpc、riscv、s390、x86）都选了 ARCH_HAS_PREEMPT_LAZY，所以 PREEMPT_DYNAMIC 实际上已不再支持 NONE/VOLUNTARY。

Mark Rutland（ARM，5 补丁）把这个既成事实官方化：让 PREEMPT_DYNAMIC 直接 depend on ARCH_HAS_PREEMPT_LAZY，再删掉为 NONE/VOLUNTARY 保留的冗余代码——{cond,might}_resched()、preempt_schedule{,_notrace}()、irqentry_exit_cond_resched() 的旧路径，以及 HAVE_PREEMPT_DYNAMIC_{CALL,KEY} 这套选择机制。x86_64 v7.2-rc1 defconfig 用 GCC 10.2.1 构建，bzImage 缩小约 28K（主要来自运行时永远不会被 patch 成 {cond,might}_resched() 的 NOP），净删 367 行。这是把"理论上的多模式动态切换"收敛到"实际只有 lazy + full"的现实。

EAS 解除对 schedutil 的硬依赖

原文^[4]

EAS 一直要求 root domain 内所有 CPU 的 CPUFreq governor 必须是 schedutil 才肯启用（cpufreq_ready_for_eas()），理由是 EAS 用 util 预测 CPU 将运行的 OPP，只有 schedutil 真正按 util 请求频率时预测才有意义。

Lucas de Lima Nóbrega 指出这条要求对 artificial Energy Model（EM_PERF_DOMAIN_ARTIFICIAL）不成立。artificial EM 由 get_cost() 回调构建，只编码 CPU 间的成本排序（如给定 util 下 P-core 比 E-core 贵），不预测任何具体 OPP 的真实能耗，也就没有需要 governor 守护的 per-OPP 精度。intel_pstate 正是给无 SMT 的混合架构（P/E core）注册这种 artificial EM，且 active 模式下走 HWP 自主选频、从不用 schedutil；cppc_cpufreq 注册同类排序 EM，同样受影响。结果是这些系统即便 SD_ASYM_CPUCAPACITY、频率不变性、EM 都齐备，EAS 也不 engages——is_rd_overutilized() 在 sched_energy_enabled() 为 false 时被硬编码成 true，find_energy_efficient_cpu() 根本到不了。

补丁改为：当 root domain 内每个 CPU 的 EM 都是 artificial 时，允许 EAS 启用，即使 governor 不是 schedutil。Raptor Lake-P 笔记本（nosmt=force、intel_pstate active/HWP）上验证，改动前 find_energy_efficient_cpu() 从未被调用（经 sched_overutilized_tp tracepoint 确认），改动后按预期被触发。Rafael Wysocki 在 review 中就 sched_energy sysfs 开关的语义和文档措辞与作者多轮讨论，作者将据反馈出下一版。

sched_domain_shared 挂载点适配 sd_asym_cpucapacity

原文^[5]

非对称容量系统的唤醒路径用 select_idle_capacity() 扫描 sd_asym_cpucapacity 的 span 而非 sd_llc，但 has_idle_cores 提示存在 sd_llc->shared 上，于是唤醒时读的空闲提示是 LLC 范围的、实际扫描决策却跨 asym 域，范围不匹配；同处的 nr_busy_cpus 在 asym 场景从不被用。

K Prateek Nayak（AMD）与 Andrea Righi 的补丁把 sched_domain_shared 对象在 CPU 拥有非重叠（非 NUMA 构造的）SD_ASYM_CPUCAPACITY_FULL 祖先时挂到 asym 域，使 has_idle_cores 的范围与唤醒扫描范围对齐。三种情况回退到 LLC：纯对称系统；cpuset 独占切出的对称容量"孤岛"（系统级 has_asym 为真但那些 CPU 无 SD_ASYM_CPUCAPACITY_FULL 祖先）；以及 asym 域落在 NUMA 构造域上的异构拓扑（init_sched_domain_shared() 按 cpumask_first(span) 建索引会把不相关 span 混到同一 blob）。per-CPU 变量随之从 sd_llc_shared 改名为 sd_balance_shared，因为它不再严格绑定 LLC。该补丁 5 月已合入 tip，本周 Breno Leitao 在 arm64 asym 系统上用 cpuset 触发 sched-domain rebuild 时撞到 struct sched_domain_shared 的 kmemleak（__sds_alloc → build_sched_domains），K Prateek Nayak 在跟进定位拓扑构造条件。

cpu_preferred_mask 系列迭代到 v6

原文^[6]

Shrikanth Hegde（IBM，v6，23 补丁）的虚拟化 steal-driven vCPU backoff 系列本周出 v6。相对 v5 的主要变化集中在回应 review：cpu_preferred_mask 改为 EXPORT_SYMBOL_GPL；set_preferred_cpu 在 CONFIG_PREFERRED_CPU=n 时编译为 NOP；删掉 select_fallback_rq 里缓存 preferred 状态的优化——缓存值在 mask 变化后会误重置任务亲和性，暴露出竞态；删掉独立的 wakeup 补丁（Peter Zijlstra 建议，测下来无性能退化，非 preferred CPU 在唤醒路径走 select_fallback_rq 即可）；并处理了 steal monitor 驱动访问 active_mask 的 CPU hotplug 问题、u64 溢出、nohz_full 末尾段假设 housekeeping core 总在开头等问题。作者继续就 drivers/virt/steal_monitor 新驱动的 MAINTAINERS 归属征求意见。

EEVDF：reweight 引发的 avruntime 单向漂移（RFC）

原文^[7]

Chen Jinghuang（华为，RFC）报告：跑 EEVDF 测试时观察到持续运行的调度实体 vruntime 出现整体下降趋势。拓扑是 cgroup A/B 共存，CPU 0 上 A1 在跑、B1 周期性 sleep/wake（50us sleep / 10us wake），其他 CPU 上 A2/A3、B2/B3 频繁 sleep/wake；CPU 0 上 gse(A) 因兄弟任务频繁 sleep/wake 反复触发 update_cfs_cgroup() → reweight_entity()，entity_lag() 的边界 limit 引入非对称累积误差，使 gse->vruntime 异常走低，而 gse 自身权重并未变化。

机制是：se->vruntime > avruntime 时，downscale 阶段 vlag = entity_lag(...) 若超界被 clamp，缩放后的 vlag 偏大、se->vruntime = avruntime - vlag 被强行压向 avruntime（比理论值小）；upscale 阶段因 se->vruntime 已带上一轮 clamp 误差，隐式偏移了后续全局 avruntime 的计算轨迹，权重还原时 vruntime 偏离真值、真正的 vlag 无法重建，形成单向漂移。作者列出四个待讨论问题：curr se 因 RUN_TO_PARITY 通常处于 vruntime > avruntime 状态，reweight 时被强制下压是否预期；avruntime 按 EEVDF 原理应在权重变化下保持不变，单向漂移是否合理；avruntime 的非功能性下降会连带压低运行队列上其他实体的 se->vlag、加剧它们饥饿；以及最严重的——entity_tick → update_deadline 里 curr->vruntime 被 clamp 误差异常拉低而 deadline 不变，vruntime < deadline 每个 tick 都满足、resched_curr() 被跳过，抑制抢占直到频繁 reweight 停止或 curr 的 vlag 回到 limit 内。entity_lag() 当初是为防溢出导致的 NULL deref 引入，作者据此问这一 limit 的必要性与实现是否该重新考虑。

二、重要 Bug 修复

sched_ext：子调度器 enable 失败路径未 arm exit，半启用残留

原文^[8]

【问题】子调度器 enable 失败时，scx_sub_enable_workfn() 跳到 err_disable 调 scx_flush_disable_work() 清理，但该 flush 只在 exit 被 arm（经 scx_error()/scx_exit()）后才起作用。多条错误路径（ops.init_task() 用有效 errno 拒绝任务、arena/cmask scratch 分配的 -ENOMEM）到达 err_disable 时并未 arm exit。

【根因】teardown 从不运行：半启用的调度器仍链在父里，ops.exit() 不被调用，停留在 bypass 状态，cgroup 子树仍指向它，cmd->ret == 0 还把 attach 报成成功，直到 struct_ops map detach 才清理。

【修复方案】参照 root enable 路径在 flush 前先 arm exit 的做法，在 err_disable 标号处补 scx_error(sch, "scx_sub_enable() failed (%d)", ret)；scx_claim_exit() 对已出错的路径幂等。

【影响范围】David Carlier，针对 kernel/sched/ext/sub.c 的 sub-scheduler enable 路径。

sched_ext：task setter kfuncs 可被非 SCX 程序越权调用

原文^[9]

【问题】scx_bpf_task_set_slice() 和 scx_bpf_task_set_dsq_vtime() 修改 sched_ext 任务状态，原本依赖 scx_prog_sched()/scx_task_on_sched() 校验调用方对目标任务的主管权。但这两个 kfunc 属于 scx_kfunc_ids_any，该集合同时注册给 tracing 和 syscall 程序，verifier 的上下文过滤允许 any-set kfunc 从非 STRUCT_OPS 程序类型调用——非 SCX 的 tracing 程序能在调过 task setter 包装后加载成功，在 SCX scheduler context 之外触达 mutator kfunc。

【根因】kfunc 集合划分未把"修改 SCX 任务状态"的 mutator 与普通 any kfunc 区分开，verifier 无法在加载期把它们挡在 SCX 上下文之外。

【修复方案】把两个 task setter kfunc 拆进独立的 filtered kfunc set（scx_kfunc_ids_task_setter），仍注册给 STRUCT_OPS/TRACING/SYSCALL 以便 verifier 找到，但用 scx_kfunc_context_filter() 在非 SCX struct_ops 上下文拒绝。SCX scheduler 仍可正常调用，运行时的任务主管权校验保留。附带一个负向 selftest task_setter_kfunc_deny，从 tracing 程序调这两个 setter——改动前程序加载成功（测试失败），改动后 verifier 拒绝（测试通过）zhidao su（Xiaomi）。

proxy execution：proxy_reset_donor 漏设 rq->next_class

原文^[10]

【问题】proxy_reset_donor() 在归还 donor 执行权时未设置 rq->next_class。

【根因】与 04f80f8b12a0（"sched: Switch rq->next_class on proxy_resched_idle()"）同一类遗漏——proxy_resched_idle() 路径已补，proxy_reset_donor() 漏了。

【修复方案】在 put_prev_set_next_task(rq, rq->donor, rq->curr) 之后补一行 rq->next_class = rq->curr->sched_class。

【影响范围】Fixes: f13beb010e4a（"sched: Have try_to_wake_up() handle return-migration for PROXY_WAKING case"），John Stultz（Google），proxy execution 系列 v30。

影响较小的修复

• • active balance 在 src_rq->curr 不在运行队列时无效触发（v5）：Xin Zhao 观察到 CFS 任务且 on_rq==0 时 active balance 失败率极高（18 CPU 上 300 秒采样 1839 次触发、1791 次失败）——pick_next_task() 里 sched_balance_rq() 解锁再加锁制造"窗口"，期间 try_to_block_task() 已把 curr->on_rq 置 0 但 rq->curr 还没换给 next，其他 CPU 看到 curr->on_rq==0。补丁在已知 busiest cpu 刚触发过 active balance 的检查之后，对 CFS curr 且 on_rq==0 的情况跳过 active balance；非 CFS curr 仍保留亲和性检查（成功率 98.4%）。v5 按 Valentin Schneider 建议去掉了 sched_class == &fair_sched_class 的显式判断。原文^[11]
• • core-sched forced idle 误告警（v3）：Tejun Heo 把上周的补丁迭代到 v3，跳过 put_prev_task_scx() 在 core-sched forced idle 下对未设 SCX_OPS_ENQ_LAST 任务的 WARN。原文^[12]
• • TIF_NEED_RESCHED 触发 BPF 栈溢出（v3）：Sechang Lim 把上周的修复迭代到 v3，把"先 test 再 set"换成原子 test_and_set_tsk_thread_flag()，消除 set_tsk_need_resched() 经 tracepoint 的无限递归。原文^[13]

三、sched_ext 进展

核心功能演进

proxy execution 共存（见一、）和 capability-based CPU 委派（见一、）是本周两条主线，分别落在 sched_ext/for-7.3，都围绕"让 BPF scheduler 在更复杂的执行权和 CPU 归属场景下仍保持一致视图"。

子调度器实现拆分到 sub.c（Tejun Heo，4 补丁，PATCHSET v1→v2→v3 一周内三版）——sub-scheduler 代码已长到需要独立文件，前三个补丁做机械准备（给 file-local helper 加 scx_ 前缀、暴露共享内部接口、内联少量 trivial helper），第四个补丁把实现从 ext.c 移到新建的 kernel/sched/ext/sub.c，ext.c 净减约 900 行。纯代码搬迁，零功能变更，承接上周的 kernel/sched/ext/ 子目录重组。原文^[14]

稳定性修复

除前述 enable 失败路径 arm exit、task setter kfuncs 越权外：

SCX_EVENTS_LIST 替换手写事件枚举（Tejun Heo，for-7.3）——把 open-coded 的事件列表用 SCX_EVENTS_LIST 宏统一，顺带补一个补丁给 local SCX_EVENT 定义加括号以修 checkpatch 报错。原文^[14]

生态与工具改进

cmask 字访问统一用 READ_ONCE/WRITE_ONCE（Tejun Heo，capability 系列的 03/32）——cmask 的 word 操作改用 READ_ONCE/WRITE_ONCE，删掉 _RACY 变体，为后续分片锁的并发访问铺路。原文^[2]

compat.h 改用 btf_vlen() helper（Liang Luo，KylinOS）——tools/sched_ext 的 compat 头去掉手写 BTF 访问，换用 btf_vlen()。原文^[15]

四、工具链与调试

need-resched 定时等待接口（Ankur Arora，Oracle，v13 11/15）——新增 tif_bitset_relaxed_wait() 及包裹它的 tif_need_resched_relaxed_wait()，带 thread_info 位和超时参数，用 smp_cond_load_relaxed_timeout() 实现，抽象出 poll_idle 式" spin 等标志位变更直到超时"的模式。放在 linux/sched/idle.h 而非 thread_info.h 以绕开递归头文件依赖，服务于 cpuidle poll 路径。原文^[16]

schedutil iowait boost 注释自相矛盾（Zhongqiu Han，高通）——sugov_iowait_apply() 的 kerneldoc 同一句里说 boost 在本函数既增又减，实际本函数只减、增加发生在 sugov_iowait_boost()。改注释点名正确的函数。No functional change，Fixes: fd7d5287fd65。Christian Loehle 给 Reviewed-by。原文^[17]

五、趋势观察

sched_ext 子调度器从"dispatch 委派"扩展到"全路径 capability 委派"。此前的 sub-scheduler 只在 dispatch 路径有程序化委派（scx_bpf_sub_dispatch()），enqueue 路径对父调度器是个黑盒——任何子都能往任何 local DSQ 插任务。capability 模型把委派做成显式状态（grant/revoke 的能力位 + 分片 cmask），覆盖 enqueue、占用、kick/preempt、idle 上报，核心侧用 reject DSQ 强制执行。配合 proxy execution 共存方案，sched_ext 正在构建一套能在 BPF scheduler 间层级化划分 CPU、又能在 mutex 阻塞场景下保持执行权一致的完整模型。

proxy execution 的 donor 建模为"函数调用"而非任务切换。让 proxy execution 与 sched_ext 共存的最大障碍是 BPF scheduler 对 current 的假设会被 owner 替换打破。把 donor→owner 交接建模成 donor 仍是运行调度实体、owner 只是核心临时调用的执行上下文，调度状态记 rq->donor、rq->curr 标识执行上下文，回避了为 BPF 未 dispatch的任务产生合成回调这一复杂路径。

PREEMPT_DYNAMIC 收敛到 lazy preempt。NONE 和 VOLUNTARY 在 v7.0 之后的架构上本就选不出来，本周的清理只是把代码层面的多模式动态切换收掉。结果是 PREEMPT_DYNAMIC 实际只区分 lazy 与 full，相关 {cond,might}_resched() 的运行时 patch 机制也随之简化。

EAS 与 CPUFreq governor 解耦的范围正在厘清。EAS 要求 schedutil 的初衷是保护 per-OPP 能耗预测精度，artificial EM 只做成本排序、不做 OPP 预测，自然不受此约束。intel_pstate HWP active 和 cppc_cpufreq 这类场景现在能用到 find_energy_efficient_cpu()。

EEVDF reweight 的公平性细节持续被审视。entity_lag() 的边界 limit 当初是为防溢出 NULL deref，但在频繁 cgroup reweight 下暴露出非对称截断误差——vruntime 被单向压低、avruntime 漂移、极端情况下抑制正常抢占。

六、下周关注点

1. 1. capability-based CPU 委派的强制语义验收——Tejun Heo 的 32 补丁系列刚发出，reject DSQ 改道、revoke 驱逐、kick 降级这些核心侧强制动作的边界情况（尤其 migration-disabled 任务、跨 shard 操作）会经受 review。
2. 2. proxy execution + sched_ext v2 的公平性——donor 建模为函数调用后，mutex hold/wait 时间的分布、与 BPF scheduler 自身 vtime/slice 记账的相互作用需要更广的实测，kselftest 之外的工作负载表现待验证。
3. 3. EEVDF avruntime 漂移 RFC 的回应——华为提出 entity_lag() limit 的必要性问题，是否会有 maintainer 给出保留或重写该 limit 的判断、以及它与既有 avruntime drift 修复的关系。
4. 4. EAS 解除 schedutil 依赖的下一版——Rafael Wysocki 已就 sched_energy 开关语义和文档深入 review，下一版如何处理 overutilized 判定与 sysfs 接口。
5. 5. sched_domain_shared kmemleak 定位——Breno Leitao 在 arm64 asym 系统上 cpuset 触发 domain rebuild 撞到的 struct sched_domain_shared 泄漏，K Prateek Nayak 正在收集拓扑信息定位触发条件。

引用链接

[1] 原文: https://lore.kernel.org/all/20260702171909.1994478-1-arighi@nvidia.com/[2] 原文: https://lore.kernel.org/all/20260703080159.2314350-1-tj@kernel.org/[3] 原文: https://lore.kernel.org/all/20260703133358.698078-1-mark.rutland@arm.com/[4] 原文: https://lore.kernel.org/all/20260629083542.10041-1-lucaslnobrega38@gmail.com/[5] 原文: https://lore.kernel.org/all/20260509180955.1840064-3-arighi@nvidia.com/[6] 原文: https://lore.kernel.org/all/20260701141654.500125-1-sshegde@linux.ibm.com/[7] 原文: https://lore.kernel.org/all/20260703092635.583332-1-chenjinghuang2@huawei.com/[8] 原文: https://lore.kernel.org/all/20260703191002.804763-1-devnexen@gmail.com/[9] 原文: https://lore.kernel.org/all/20260701091954.384565-1-soolaugust@gmail.com/[10] 原文: https://lore.kernel.org/all/20260701214615.3773339-5-jstultz@google.com/[11] 原文: https://lore.kernel.org/all/20260617072151.1173416-2-jackzxcui1989@163.com/[12] 原文: https://lore.kernel.org/all/20260629225548.3562257-1-tj@kernel.org/[13] 原文: https://lore.kernel.org/all/20260630084750.2792851-1-rhkrqnwk98@gmail.com/[14] 原文: https://lore.kernel.org/all/20260701031429.1892218-1-tj@kernel.org/[15] 原文: https://lore.kernel.org/all/20260630031246.2618216-1-luoliang@kylinos.cn/[16] 原文: https://lore.kernel.org/all/20260702013334.140905-12-ankur.a.arora@oracle.com/[17] 原文: https://lore.kernel.org/all/20260703092433.4080165-1-zhongqiu.han@oss.qualcomm.com/