当前位置:首页>Linux>Linux 内核调度子系统周报(2026 W31)

Linux 内核调度子系统周报(2026 W31)

  • 2026-09-19 06:05:18
Linux 内核调度子系统周报(2026 W31)

Linux 内核调度子系统周报(2026-07-27 ~ 2026-08-02)

本期重点

  1. 1. sched_ext 引入 bandwidth-limited rescue execution——Tejun Heo 的 12 补丁系列解决子调度器 cid 不覆盖任务亲和时的 stranded task 问题:调度器用 SCX_ENQ_RESCUE 标记 insert,内核在目标 CPU 以配置的小带宽运行该任务,超时未服务升级为 protected execution,CPU rescue 队列过载则 eject rescue 消耗最高的子调度器。
  2. 2. proxy execution 与 sched_ext 共存推进到 v10——Andrea Righi 在上期 v9 基础上出 v10,sched_can_stop_tick() 在 RT fast path 前检查 constrained FAIR proxy donor(防 throttled RT owner 绕过带宽强制),DEQUEUE_CLASS 只在 SCHED_FLAG_KEEP_PARAMS 允许 class 变化时设。
  3. 3. dl_server revised wakeup rule 修复合入 tip sched/urgent——Gabriele Monaco 5 月报告的补丁(revised wakeup rule 误用于非 running 的 deferrable server)本周由 Peter Zijlstra 合入,Fixes: 14a857056466。
  4. 4. sched_ext idle CPU 状态初始化修复——Andrea Righi 指出内建 idle mask 初始化把所有在线 CPU 标 idle,但 idle tracking 在 sched_ext 完全启用后才开始,导致 ops.init() 到下次 idle 转换前 busy CPU 被误报为 idle;v2 把 idle-mask 初始化移到核心并加专用 static key。

一、核心进展

sched_ext:bandwidth-limited rescue execution for stranded tasks

[1]

子调度器只持父 grant 的 cid,不保证这些 cid 覆盖其任务的亲和。一个任务若不能在它持有的任何 cid 上运行,此前没有好结局:insert 被 cap-reject 后 reenqueue 直到重复上限 eject 调度器,或任务 stall 进 watchdog。

Tejun Heo 这套系列加 kernel 侧 rescue execution。调度器用 SCX_ENQ_RESCUE 标记可能被 cap-reject 的 insert,内核不再改道该任务,而是在目标 CPU 上以配置的小带宽运行它。rescue 起初非破坏性:持 cap 的调度器在很大程度上仍掌控 CPU(例如 preemption cap 仍让持有者能抢占 rescuee)。当 rescue 长时间未被服务,升级为 protected execution。(Tejun Heo,v2 系列)

CPU 的 rescue 队列持续过饱和(超过 overload 阈值)时,内核 eject 该 CPU 上近期 rescue 消耗最高的子调度器,而非错误归责 waiter 的 owner。

系列结构:0001-0005 是 prep(重命名 scx_local_or_reject_dsq 为目标中立的 scx_resolve_local_dsq、helper 可见性、dsq-move flag 审查、SCX_ENQ_IGNORE_CAPS 豁免 preemption);0006-0007 在 insertion commit 时同步 slice/dsq_vtime 写入并加 SCX_TASK_PROTECTED,让 kernel 授予的 slice 能在调度器写入后存活;0008-0009 加 rescue 机制和 overload ejection;0010 同步工具 autogen enum 头;0011-0012 修 scx_qmap 的 pinned-task direct dispatch 并加 rescue 支持作演示消费者。

v2(8 月 2 日)按 sashiko AI review 修:scx_sched_all 移出 CONFIG_EXT_SUB_SCHED 块(定义是无条件的);overload grace 和 usage-decay 时间戳改用 jiffies_64(避免 32 位算术回绕);删不再读取的 always_enq_immed rodata 镜像。[2]

proxy execution 与 sched_ext 共存:v9→v10

[3]

上期 v9 引入 incoming-class prepare_switch() callback、per-rq reject DSQ 泛化、ops.tick() 记账限定 tracked session(设计见上期周报一、)。本周 v10(7 月 30 日)改动集中在带宽强制与 class 转换回调的边界。(Andrea Righi,v10 系列)

v10 关键变更:sched_can_stop_tick() 里在 RT fast path 之前检查 constrained FAIR proxy donor,使 throttled RT owner 不能绕过带宽强制(sashiko);加 prep fix,只在 SCHED_FLAG_KEEP_PARAMS 允许 class 变化时设 DEQUEUE_CLASS,防止无实际 class 转换时仍跑 class-transition callback(sashiko,与下面 KEEP_PARAMS 修复同源);更新 try_to_block_task() 注释描述 sched_ext blocked-donor admission check。

系列内的 reject DSQ reenqueue path 泛化补丁(patch 09/15)sashiko AI 标出一个 High 风险:瞬态设置 reject reason 失败会让任务永久滞留 reject DSQ。[3]

sched_ext:idle CPU 状态初始化修复

[4]

内建 idle mask 初始化时把所有在线 CPU 标 idle,但 idle tracking 当前只在 sched_ext 完全启用后才开始。这导致 ops.init() 期间及直到每个 CPU 下次 idle 转换前,busy CPU 被错误广播为 idle。

Andrea Righi 的系列让内建 idle mask 从 ops.init() 起可靠:在 ops.init() 前启用 idle tracking 并在每个在线 CPU 的 rq 锁下同步其状态。这个早期阶段只更新内建 mask,ops.update_idle() 通知仍抑制到调度器完全启用。同时重做 allowed_cpus kselftest,把有竞态的 remote-CPU 检查替换为依赖新保证的初始 idle-mask 状态的稳定本地不变量。v2 把 idle-mask 初始化从 selftest 移进 sched_ext 核心(Kuba Piecuch 建议)、加专用 idle-tracking static key、目标改为 for-7.3。这条与上期 w30 的 WAKESYNC waker CPU busy、allowed_cpus race-free 修复属同一 idle 跟踪失同步问题域。[4]

二、重要 Bug 修复

sched/deadline:revised wakeup rule 误用于非 running 的 dl_server

[5]

【问题】commit 14a857056466 ("sched/deadline: Use revised wakeup rule for dl_server") 把 revised wakeup rule 用于任意 server,导致未运行(dl_defer_running == 0)且以 deadline overflow 开始的 server 被 enqueue,并像运行中的 server 一样 boost 任务,破坏 defer rule 和文档化的状态模型。

【修复方案】revised wakeup rule 只用于标记为 running 的 deferrable server(条件从 dl_se->dl_defer 改为 dl_se->dl_defer && dl_se->dl_defer_running)。

【影响范围】Fixes: 14a857056466。Gabriele Monaco 5 月发出,Juri Lelli Acked、Andrea Righi Tested,本周由 Peter Zijlstra 合入 tip sched/urgent(commit 1842bf97af10)。

sched/core:idle_stamp 为 0 时 avg_idle 误更新

[6]

【问题】commit 4b603f1551a73 ("sched: Update rq->avg_idle when a task is moved to an idle CPU") 把 rq->avg_idle 记账从 wakeup 路径移到 put_prev_task_idle(),使 idle 区间在 idle task 切出时消费。但它替代的 wakeup 侧记账只在 rq->idle_stamp 非零时更新 rq->avg_idle,新 helper 丢了有效性检查,无条件计算 rq_clock(rq) - rq->idle_stamp。rq->idle_stamp 为 0 时把 rq_clock(rq) 当 sample,这不是有效 idle 时长,会立即把 rq->avg_idle 推到 clamp。

【修复方案】在 update_rq_avg_idle() 恢复 idle_stamp 有效性检查,无测得的 idle 区间时跳过更新。

【影响范围】Fixes: 4b603f1551a73。作者在 hackbench 负载下用临时 tracing 确认 update_rq_avg_idle() 能以 rq->idle_stamp == 0 到达,hackbench 相对 v7.2-rc5 mainline 无实质回归。(Shubhang Kaushik / Ampere)

sched_ext:ENABLING→ENABLED 转换失败的 stale errno

[7]

【问题】scx_root_enable_workfn() 尾部的 SCX_ENABLING -> SCX_ENABLED cmpxchg 失败时跳到 err_disable 未设 ret,此时 ret 仍持有最后一次成功的 __scx_init_task() 返回值 0,fallback 报无意义的 "scx_root_enable() failed (0)"。

【修复方案】设 ret = -EBUSY,与同函数顶部的其他 enable-state guard 一致。(Liang Luo / KylinOS)与上期 w29/w30 的 sub-enable stale errno(scx_sub_enable_workfn())是同一类 stale errno 问题。

sched_ext:sub-enable stale errno v2 apply 后的延续

上期 w30 报告的 sub-enable stale errno v2(nesting depth 设 -EINVAL、cgroup online 设 -ENODEV)已被 Tejun apply 到 for-7.3。本周的 ENABLING→ENABLED errno(#9)属同类问题的 root enable 路径补全。

sched:SCHED_FLAG_KEEP_PARAMS 的副作用

[3]

【问题】SCHED_FLAG_KEEP_PARAMS 允许 sched_setattr() 更新通用任务属性同时保留现有调度参数和 class。但 __sched_setscheduler() 有两条路径仍按 requested policy 行动:一条标 class change 并调 class transition callback(switching_from/switched_from/switching_to/switched_to),即便 class 实际未变;另一条做 deadline admission control,可能给从不进入 deadline class 的非 deadline 任务计带宽。

【修复方案】设 SCHED_FLAG_KEEP_PARAMS 时跳过两条路径:只在 class 允许变化时设 DEQUEUE_CLASS(Fixes: 637b0682821b);deadline 带宽记账跳过。(Andrea Righi,2 补丁)K Prateek Nayak 参与 review。

三、sched_ext 进展

核心功能演进

本周核心演进的主线是上面三节展开的 rescue execution、proxy execution v10、idle CPU 状态初始化。承接上期判断,本周改动集中在 capability 模型的失败处理终态(rescue execution)、proxy-exec 下更多核心路径的一致性(带宽强制、class 转换)、idle 跟踪的初始状态可靠性。

rescue execution 是 capability 模型落地后的一个重要补全:cap-rejected 任务此前只能 reenqueue 到 eject 或 stall,现在 kernel 提供保底运行。proxy-exec v10 把带宽强制和 DEQUEUE_CLASS 的边界对齐到 SCHED_FLAG_KEEP_PARAMS 语义。

稳定性修复

本周稳定性修复包括 idle CPU 状态初始化(见一、)、ENABLING→ENABLED stale errno(见二、)、rq->avg_idle 有效性检查(见二、)。NMI-safe exit 系列(上期报告)本周 Andrea Righi review,讨论了 scx_claim_exit() 的 lockless sweep 实现细节。

生态与工具改进

sched_ext: Fix stale @cgroup_id in sched_ext_ops kernel-doc(Liang Luo,KylinOS)——sched_ext_ops::sub_cgroup_id 的 kernel-doc 还用旧名 @cgroup_id,产生两个 kernel-doc warning。Tejun Heo apply 到 for-7.3(重排注释到 80 列内)。[8]

四、工具链与调试

perf sched: Suppress latency table output when trace samples are missing(Aaron Tomlin,v4→v7)——延续上期。perf sched latency 在不含 tracepoint sample 的 perf.data 上 perf_sched__read_events() fall through 返回 0,调用方误以为成功渲染空表头。补丁在缺 trace sample 时抑制表输出。本周出到 v7。[9]

sched: Remove the unused preempt_offset parameter of __cant_sleep()(Boqun Feng)——__cant_sleep() 所有 callsite 的 preempt_offset 都是 0,删除该参数;同时把 __cant_migrate() 的 preempt_count() > 0 改为零检查,为将来使用全部 32 位 preempt_count(可能产生负值)做准备。无功能变化。[10]

sched: fix two misspellings(Jiangong.Han,Wind River)——延续上期,include/linux/sched.h 一个拼错单词和一个函数名 typo。[11]

五、下周关注点

  1. 1. rescue execution v2 的 review——12 补丁系列引入 kernel 侧保底运行机制,overload ejection 归责和 protected execution 升级是新的复杂度,关注 sashiko AI 标出的 reject DSQ 滞留 High 风险如何处理,以及是否进 for-7.3。
  2. 2. proxy execution + sched_ext v10 之后——v10 把带宽强制和 DEQUEUE_CLASS 对齐后,Peter Zijlstra 是否接受函数调用模型;reject DSQ reenqueue path 泛化补丁的 High 风险(瞬态 reject reason 失败致任务永久滞留)如何解决。
  3. 3. idle CPU 状态初始化系列的合入——v2 目标 for-7.3,与上期 w30 的 WAKE_SYNC waker CPU busy、allowed_cpus race-free 属同一问题域,关注是否合并处理。
  4. 4. capability 模型本身的合入窗口——rescue execution、bound reenqueues、NMI-safe exit、follow-up + cap enforcement 等系列本周密集推进,关注哪些在 7.3 窗口冻结前进 for-7.3。

引用链接

[1] 原文: https://lore.kernel.org/all/20260801085150.2697653-1-tj@kernel.org/
[2] 原文: https://lore.kernel.org/all/20260802215447.3134509-1-tj@kernel.org/
[3] 原文: https://lore.kernel.org/all/20260730055011.2267333-1-arighi@nvidia.com/
[4] 原文: https://lore.kernel.org/all/20260731090334.2911948-1-arighi@nvidia.com/
[5] 原文: https://lore.kernel.org/all/178540943305.112641.1315748029395427194.tip-bot2@tip-bot2/
[6] 原文: https://lore.kernel.org/all/20260728-master-v1-1-f95d9b0147d2@gentwo.org/
[7] 原文: https://lore.kernel.org/all/20260728060955.4102964-1-luoliang@kylinos.cn/
[8] 原文: https://lore.kernel.org/all/dc692a6642cff66bc023912fe385d2f0@kernel.org/
[9] 原文: https://lore.kernel.org/all/20260725160513.57477-1-arighi@nvidia.com/
[10] 原文: https://lore.kernel.org/all/20260731203031.13679-9-boqun@kernel.org/
[11] 原文: https://lore.kernel.org/all/20260720010027.4020911-1-jiangong.han@windriver.com/

最新文章

随机文章