sched/fair：hrtick 在同任务重选后未重启——kbuild 机器人报错

系列概况

标题：[PATCH] sched/fair: Restart hrtick after same-task repicks
作者：Shubhang Kaushik (Ampere) sh@gentwo.org
版本：v1（2026-08-13），本邮件是 v1 发出 12 天后的 0day CI 自动报告（2026-08-25）
规模：单 patch，本邮件只含错误摘要，未携带 diff
修改文件：kernel/sched/fair.c（机器人报错定位到第 14885 行第 19 列）
代码统计：本邮件未提供 diff 行数；从错误信息推断 patch 新增了 rq->hrtick_rearm_fair 相关引用
Message-ID：202608250251.11earlUX-lkp@intel.com
完整性：仅 1 封回复（机器人告警）；原始 patch、maintainer 评审、后续版本均未出现在本次输入中

补丁目的

原始 patch 想修复 CFS（sched/fair）中的一处调度精度回归：当 pick_next_task_fair() 经历多次 repick、最终又选回同一个任务时，原有的高精度调度 tick（hrtick，用作 preemption 的硬件计时器）已经因为重选流程而被清掉或暂停，却没有重新挂回去。结果是该任务在被唤醒/迁移等路径上错过原有 preemption 截止时间，只能退到普通 tick 粒度才被发现，造成额外调度延迟。patch 试图在 repick 同任务时重新 start hrtick。

旧流程的问题

旧代码里，pick_next_task_fair() 在多个 eligible 任务之间迭代挑选；当 repick 落回原任务时：

进入新一轮循环，hrtick 没有被重新启动。
计时基准丢失：原本预定的 preemption deadline 不再受硬件 timer 监控。
该任务即便执行时间已超 slice 阈值，也不会被 hrtick 提前抢占，要等到下一个普通 tick 才发现，引入调度延迟。

新流程

新 patch引入一个状态字段（例如 rq->hrtick_rearm_fair 或配套标志位），并在 repick 路径中显式重启 hrtick：

pick_next_task_fair()
 |
   +-- iterate idle_cpu / best eligible task
   |
   +-- if selected == last picked (repick same task)
   |       |
   |       +-- rearm_hrtick_fair(rq, task)
   |
   +-- return selected

+------------------+
| struct rq (old)  |
| - hrtick_flags   |
| - hrtick_time    |
+------------------+
        |
        | patch expects
        v
+------------------+
| struct rq (new)  |
| + hrtick_rearm   |
|   _fair          | <-- 0day error: no member
+------------------+

Patch 概览

本邮件是 kbuild 机器人报告，不携带 diff。从错误信息推断 patch 的最小改动：

kernel/sched/fair.c 新增对 rq->hrtick_rearm_fair 的读/写引用。
在 pick_next_task_fair() 的 repick 分支调用 rearm_hrtick_fair()，重新安装 hrtick_timer。

然而当前 mainline（或机器人测试树）的 struct rq 中并不存在该字段，导致 patch 在编译阶段直接失败，根本原因是 patch 与基础内核存在依赖/上下文错位。

关键实现

机器人错误原文：

kernel/sched/fair.c:14885:19: error: 'struct rq' has no member named 'hrtick_rearm_fair'

含义清晰：patch 在 .c 文件里引用了 struct rq 的新成员 hrtick_rearm_fair，但 patch 自身没有把对应成员加进 kernel/sched/sched.h 的 struct rq 定义。可能的根因：

/* kernel/sched/fair.c, near line 14885 -- patch 期待出现的位置 */
+ if (rq->hrtick_rearm_fair) { /* 编译失败：no member */
+ /* re-arm hrtick for the same-task repick path */
+         hrtick_start_fair(rq, p);
+ }

root cause A: patch 系列拆分时漏发了 sched.h 段
root cause B:  作者基于含私有字段的 Ampere/OSS 分支，
 0day 测试树用的是 mainline/intel-lab-lkpresult:        struct rq 没有 hrtick_rearm_fair，编译报错

类比

把 hrtick 想成一口定时响铃的闹钟：

旧流程：闹钟已经上好，你又把表盘拆下来擦灰（repick），结果闹钟停在拆下的那一刻；下次该响时房间一片安静，没人提醒你。
新流程：拆表盘擦灰之前，先把闹钟重新挂回原位并重新上弦，时间一到依旧会响。
编译错误：相当于闹钟（hrtick）机制装好了，但闹钟底座（rq->hrtick_rearm_fair）没跟着新闹钟一起送到房间；安装师傅只能摊手说"这个桌子没这个孔"。

Highlight：风险与注意点

patch 拆分不完整：错误指向 struct rq 缺成员，几乎可以确认 patch 系列漏发了 kernel/sched/sched.h 中 struct rq 的字段定义，是 v1 阶段的常见疏漏。
基础树不一致：也可能作者基于含私有字段的 Ampere/OSS 分支，而 0day 用的是 mainline/int el-lab-lkp 自己的测试树，需要作者明确 patch 的 base树。
7 天自动复核：机器人提示 "patch is more than 7 days old, verify it wasn't already superseded"，v1 自 2026-08-13 之后既没有作者新版，也没有 maintainer 跟帖，需要确认是否已被 v2 取代或被默默忽略。
跨线程注意：本邮件不含 maintainer 评审；后续真实回复（Re:/Reviewed-by/Acked-by）应在 lore 上继续跟踪。
行为面风险：即使编译修好，仍需关注 repick 同任务时重复 rearm hrtick 是否会与 hrtick_cancel() 路径产生竞态，例如双重 rearm 把 deadline 推到未来反而延长延迟。

版本变化

输入中只有 v1 的 kbuild 报告，没有 v2/v3 邮件，无版本演进可描述。

一句话总结

sched/fair 试图在同任务 repick 后重启 hrtick，但 patch 在 struct rq 中引用的 hrtick_rearm_fair 字段并未随 patch 一同加入 sched.h，导致 0day CI 编译失败，需要作者补齐 struct 字段或对齐 base 树后重新提交。

Re: [PATCH] sched/fair: Restart hrtick after same-task repicks

LLM 分析