本篇范围

本篇只钉一件事：

CPU 决定「下一个跑谁」时，内核会按固定顺序询问若干调度模块（sched_class）。
这个顺序从哪来？运行时怎么用？sched_ext（BPF 调度）怎样插进来？

行号基于 linux-source-7.0.0（Makefile 为 7.0.12）。

官方源码：

• • https://cdn.kernel.org/pub/linux/kernel/v7.x/linux-7.0.12.tar.xz
• • 目录：https://cdn.kernel.org/pub/linux/kernel/v7.x/
• • 在线浏览：https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/?h=v7.0.12

wget https://cdn.kernel.org/pub/linux/kernel/v7.x/linux-7.0.12.tar.xz
tar -xf linux-7.0.12.tar.xz

第 1 步：从一次调度说起

先钉死的要点与结论

后面会跟源码，但读之前先把「本篇认重要」的几条摆出来（这一节主要围着它们转）：

1. 1. 调度原则：next 是任务（task_struct *），不是调度器。决定它时不是把本 CPU 所有可跑任务摊平打分，而是 按固定顺序问各个调度类（stop → dl → rt → fair → ext → idle）——前面的类有可跑任务就返回，后面的类不再问。
2. 2. 这个顺序写在链接脚本里（SCHED_DATA），不是运行时注册表；地址更小的类更先被问到。
3. 3. fair 排在 ext 前面 → fair 先于 ext 被询问。BPF / sched_ext 不是靠把 ext 链到 fair 上面来「抢优先级」。
4. 4. BPF「接管」靠两件事：把任务挂到 ext 类上，以及扫描时 跳过空的 fair / 未启用的 ext；链接顺序本身不变。
5. 5. 全开还是 PARTIAL，由当前加载的那份 BPF 的 flags 决定；PARTIAL 下通常要显式 SCHED_EXT 才进 BPF。

调用入口记住一条链即可：

schedule → __schedule → __pick_next_task（按类询问，交出 next）

下面从入口跟起，把结论逐条对上源码。

这一步要搞清什么

本 CPU 上正在跑的进程，过一会儿可能要换：睡了、时间片到了、被更高优先级任务打断……
内核最终会进 schedule()：找出 下一个要跑的任务，再做上下文切换。

这里的 next 是任务（类型是 struct task_struct *），不是调度器。
当前任务常叫 prev，即将上场的叫 next；各调度类（fair / rt / ext …）只是被依次询问「你这边有没有可跑任务可交出来当 next」。

本文不关心「怎么切寄存器」，只关心调用一路跟到哪里、这个 next 任务是在哪一层被决定的。

先把调用链说清楚

一次普通调度，大致经过四层包装，一层比一层更靠近「决定 next」：

1. 1. schedule()（core.c:6975）
   对外入口。进程主动让出 CPU、或内核路径里调用 schedule() 时从这里进。
   它自己几乎不做事，转给下面的循环。
2. 2. __schedule_loop()（core.c:6966）
   关抢占，调用一次 __schedule（里面会挑 next、可能切换）；
   出来后再看 need_resched()——若仍标着「该调度」，再挑一轮。
   详见下方源码注释（为何已经选过还要再选）。
3. 3. __schedule()（core.c:6748）
   真正干活的大函数：拿到本 CPU 的运行队列 rq、当前任务叫 prev；
   若 prev 要睡，先把它从可跑队列里弄下去；
   然后调用下一层去得到 next，最后做上下文切换。
   「下一个跑谁」不是在这一层算出来的，而是交给下面的 pick。
4. 4. pick_next_task() → __pick_next_task()（调用点 core.c:6836，实现 core.c:5910）
   名字里的 pick = 从本 CPU 可跑任务里 挑出下一个。
   多数配置下前者只是薄包装，后者才是按调度类挨个询问的地方（第 2 步展开）。

串起来就是：

schedule()                      // 入口：我要调度了
  → __schedule_loop()           // 关抢占，必要时多调几次
  → __schedule()                // 处理 prev，准备切换
       └─ pick_next_task()      // 请给出 next
            └─ __pick_next_task()  // 真正决定 next（按类询问）

对照源码

下面按调用顺序看。主线用完整语句标出；大约三成旁支用注释说明「它是什么 / 为什么在这」，不必深追。

1）schedule：入口

/* core.c:6975 */
asmlinkage __visible void __sched schedule(void)
{
struct task_struct *tsk = current;
    /*
     * current：本 CPU 当前正在跑的那个任务（宏，不是普通局部变量）。
     * task_struct：描述一个任务/线程的内核对象（pid、状态、sched_class…）。
     */

    /* ... 调试断言等，可忽略 ... */

    /*
     * task_is_running：状态是否还是 TASK_RUNNING（可跑）。
     * 若已经不是（例如准备睡眠），先做 workqueue / block 层收尾，
     * 再进真正的调度。细节与「谁当下一个任务」无关。
     */
    if (!task_is_running(tsk))
        sched_submit_work(tsk);

    /*
     * SM_NONE：sched_mode 之一，表示「普通主动 schedule」。
     * 另有 SM_PREEMPT（抢占进来）、SM_IDLE（idle 路径）等，
     * 主要影响 __schedule 里对「是否算抢占 / 是否阻塞 prev」的判断。
     */
    __schedule_loop(SM_NONE);

    sched_update_worker(tsk);    /* worker 线程记账，可忽略 */
}

2）__schedule_loop：可能多轮「挑 next」

/* core.c:6966 */
static __always_inline void __schedule_loop(int sched_mode)
{
    do {
        /*
         * preempt_disable：禁止内核抢占。
         * 调度过程中不能再被别的路径半路打断另开一次 schedule。
         */
        preempt_disable();
        __schedule(sched_mode);    /* 内部：挑 next，必要时 context_switch */
        /*
         * 开回抢占计数，但「先不要因为 need_resched 立刻再抢进 schedule」：
         * 交给下面 while 统一决定要不要再来一轮。
         */
        sched_preempt_enable_no_resched();
    } while (need_resched());
    /*
     * need_resched()：当前任务（current）是否还挂着 TIF_NEED_RESCHED。
     * __schedule 开头会清掉 prev 的该标记；若循环条件仍为真，
     * 说明「这一轮结束之后、或结束过程中」又被标了一次「该调度」，
     * 必须再进 __schedule 重新挑 next——不是 while 闲的。
     */
}

为何已经挑过 next，还可能再进一轮？

__schedule 整段里抢占是关着的；中断仍可能进，但不能在中途再开一次完整 schedule。
常见做法是：中断 / 唤醒路径只打上 TIF_NEED_RESCHED，等 __schedule 返回、本循环看到 need_resched() 再选。典型情况包括：

1. 1. 唤醒了更高优先级任务
   别的 CPU 或本 CPU 中断路径里 try_to_wake_up → 若应抢占当前任务，就 resched_curr 置位。
   本轮 __schedule 可能已挑完甚至切走过；回到 loop 时标记还在 → 再挑。
2. 2. 时钟节拍认为该让出
   scheduler_tick 发现时间片/延迟等需要换人，置 need_resched。
   若恰好落在「正在 __schedule / 刚返回」的窗口，本轮 while 会再进一次。
3. 3. IPI 远程求调度
   其它 CPU 对你发 reschedule IPI（例如把任务迁过来、或需要你立刻重算），同样落成 need_resched。
4. 4. 本轮几乎没切走，但标记已在
   例如 prev == next（没人可换），或刚清完标记又在关抢占窗口里被再次置位；
   sched_preempt_enable_no_resched 不会自动再进 schedule，靠 while 补上，避免漏调度。

直观记：

__schedule 挑好 next（甚至切走再切回）
    → 回到 loop
    → need_resched 仍真？ → 局面可能已变 → 再 __schedule 重挑
    → 否则才真正离开 schedule()

主线仍是「一次 __schedule 里如何按类交出 next」；loop 只是保证 标记不会白打。

3）__schedule：处理 prev，再请出 next

函数从 core.c:6748 起很长。按阶段读：

/* core.c:6748 起，结构示意 + 关键原句 */
static void __schedule(int sched_mode)
{
struct task_struct *prev, *next;
struct rq_flags rf;
struct rq *rq;
    int cpu;
    /* ... 局部变量：preempt、prev_state 等 ... */

    cpu = smp_processor_id();    /* 当前 CPU 编号 */
    rq = cpu_rq(cpu);        /* 该 CPU 的运行队列 runqueue */
    prev = rq->curr;        /* 当前正在跑的任务 → 后面叫 prev */

    /* ... schedule_debug / hrtick / livepatch 等旁路，可跳过 ... */

    local_irq_disable();        /* 关本 CPU 中断，避免选 next 时被打断 */
    /* ... RCU / migrate_disable 记账 ... */

    rq_lock(rq, &rf);        /* 拿住本 rq 的锁；调度核心数据结构要串行改 */
    /* ... update_rq_clock：更新 rq 时钟，供 fair 等算时间 ... */

    prev_state = READ_ONCE(prev->__state);
    /*
     * __state：任务状态。TASK_RUNNING=可跑；非 0 常表示睡眠/停止等。
     * 主动 schedule 且 prev 已非 RUNNING → 通常要把 prev 移出可跑队列。
     */
    if (sched_mode == SM_IDLE) {
        /* idle 专用捷径：队列空则继续跑自己，不必 pick */
        /* ... */
    } else if (!preempt && prev_state) {
        try_to_block_task(rq, prev, &prev_state, /* ... */);
        /* 把要睡的 prev 从 rq 可跑集合里弄下去（出队） */
    }

pick_again:
    /*
     * 本文主线：请本 CPU 的调度逻辑给出下一个任务。
     * 返回值 next：struct task_struct *，即将上场的任务。
     * rq->donor：与代理执行相关，初读可当成「从谁的视角挑」；
     * 多数路径下等价于从当前 rq 挑。
     */
    next = pick_next_task(rq, rq->donor, &rf);
    rq_set_donor(rq, next);
    rq->next_class = next->sched_class;    /* 记下 next 属于哪个调度类 */

    /* ... 若 next 被 mutex 挡住，可能 find_proxy_task 再挑；初读可跳过 ... */

picked:
    clear_tsk_need_resched(prev);    /* 清「该调度」标记 */
    /* ... */

    if (likely(prev != next)) {
        /*
         * 真发生切换：rq->curr = next，再 context_switch(prev, next)
         * 保存 prev 寄存器 / 恢复 next 寄存器。细节不在本文范围。
         */
        /* ... context_switch ... */
    }
    /* ... 放锁、开中断、可能返回到 next 的执行流 ... */
}

要点：__schedule 负责「场面」（锁、阻塞 prev、切换）；谁当 next 交给 pick_next_task。

4）pick_next_task：多数配置下只是转一手

/* core.c:6465（无 CONFIG_SCHED_CORE 时） */
static struct task_struct *
pick_next_task(struct rq *rq, struct task_struct *prev, struct rq_flags *rf)
{
    /*
     * 有 SCHED_CORE（SMT 同核协同）时，这里会更复杂，见第 2 步旁支。
     * 未开时就是直接进 __pick_next_task。
     */
    return __pick_next_task(rq, prev, rf);
}

__pick_next_task（core.c:5910）才是「按调度类挨个问」的地方，第 2 步展开。

到这里记住：

schedule → __schedule → __pick_next_task：next（下一个任务）在最后一层被决定。

决定 next 时，内核怎么组织这些任务？

容易以为：本 CPU 上所有可跑任务排成一张大表，__pick_next_task 从头扫到尾，挑一个「最该跑」的。

实际不是这样。 任务按策略分在不同调度类里（rt 管实时、fair 管普通进程、ext 管 BPF……），各自有自己的队列和算法。
__pick_next_task 做的是：按固定顺序问各个调度类——「你这类有没有可跑任务？」——而不是把全机任务摊平扫一遍。

1. 1. 先问排在最前的那一类。
2. 2. 有 → 用它返回的那个任务当 next，后面的类不再问。
3. 3. 没有 → 再问下一类，直到有类交出任务。

问 stop → 有可跑的？有就返回；没有再问
问 dl   → 有可跑的？有就返回；没有再问
问 rt   → …
问 fair → …
问 ext  → …
问 idle → 总能交出 idle（兜底）

例如有 SCHED_FIFO 可跑时，根本不会去 fair 里挑普通进程。

全文主线因此变成：

先问哪一个调度类？这个顺序从哪来？

下一步打开 __pick_next_task，看它怎么按类循环。

第 2 步：在 __pick_next_task 里看见「按类循环」

上一层只负责请出 next；真正决定「哪个任务」在这里（core.c:5910）。
读法同第 1 步：主线看语句，旁支看注释。

/* core.c:5909–5965 */
/*
 * Pick up the highest-prio task:
 * 在本 CPU 的 rq 上，挑出优先级最高的那一类里的下一个任务。
 * 「类间谁更高」= 后面 for_each_active_class 的遍历顺序（第 3–4 步）。
 */
static inlinestruct task_struct *
__pick_next_task(struct rq *rq, struct task_struct *prev, struct rq_flags *rf)
    __must_hold(__rq_lockp(rq))    /* 调用方必须已持有 rq 锁 */
{
    conststruct sched_class *class;    /* 当前问到的调度类 */
struct task_struct *p;            /* 某一类交出来的候选任务 */

    rq->dl_server = NULL;    /* deadline server 相关，初读可忽略 */

    /*
     * scx_enabled()：是否已加载并启用了 BPF 调度器（sched_ext）。
     * 为真时关掉下面的 fair 捷径，一律走 restart 按类扫描。
     * 原因：BPF 可能接管了大量原 fair 任务，捷径假设不再成立。
     */
    if (scx_enabled())
        goto restart;

    /*
     * ========== fair 捷径（优化路径，不是主线语义）==========
     * 若本 rq 上可跑任务「几乎全是 fair」，且 prev 也不比 fair 更高类，
     * 就直接调 fair，免去 for 循环问 stop/dl/rt/…。
     *
     * sched_class_above(a, b)：a 是否比 b「更高类」（地址更小更优先）。
     * nr_running：本 rq 可跑任务总数。
     * cfs.h_nr_queued：fair/cfs 侧排队任务数。
     * 两者相等 ≈ 没有 rt/dl 等其它类的可跑任务。
     */
    if (likely(!sched_class_above(prev->sched_class, &fair_sched_class) &&
           rq->nr_running == rq->cfs.h_nr_queued)) {

        p = pick_next_task_fair(rq, prev, rf);
        /*
         * RETRY_TASK：特殊哨兵值，表示「现在定不了，请重来」
         * （例如 balance 后队列变了）。不是真正的 task_struct。
         */
        if (unlikely(p == RETRY_TASK))
            goto restart;

        /*
         * fair 也没人可跑 → 通常只剩 idle。
         * put_prev_set_next_task：从 prev 切到 p 时，通知两类
         * 「你不再是 curr / 你是 curr」的成对回调，初读知职责即可。
         */
        if (!p) {
            p = pick_task_idle(rq, rf);
            put_prev_set_next_task(rq, prev, p);
        }

        return p;    /* 捷径命中：next 已定，函数返回 */
    }

restart:
    /*
     * ========== 慢路径 / 主线：按调度类挨个问 ==========
     * prev_balance：挑 next 前，必要时做负载均衡（拉任务过来等）。
     * 与「类间顺序」无关，失败/变化可能配合 RETRY_TASK 重来。
     */
    prev_balance(rq, prev, rf);

    /*
     * for_each_active_class：从最高类扫到最低类（宏，第 3 步展开）。
     * 顺序大致：stop → dl → rt → fair → ext → idle。
     * 「前面的类只要交出非空任务，后面的类不会被问到」。
     */
    for_each_active_class(class) {
        if (class->pick_next_task) {
            /*
             * 目前主要是 fair 填了 .pick_next_task。
             * 接口更「完整」：知道 prev，便于 fair 做特殊优化。
             */
            p = class->pick_next_task(rq, prev, rf);
            if (unlikely(p == RETRY_TASK))
                goto restart;
            if (p)
                return p;    /* 该类有可跑任务 → 就是 next */
        } else {
            /*
             * stop / dl / rt / ext / idle 等多走 .pick_task：
             * 「你这类里挑一个可跑的出来；没有就返回 NULL」。
             */
            p = class->pick_task(rq, rf);
            if (unlikely(p == RETRY_TASK))
                goto restart;
            if (p) {
                put_prev_set_next_task(rq, prev, p);
                return p;    /* 同上：有货就返回，不再问后面 */
            }
        }
        /* p == NULL：该类没人，循环继续问下一类 */
    }

    /*
     * 理论上走不到：idle 类在链接顺序最后，总能交出 per-CPU idle 任务。
     * 若仍为空，说明调度类链接/实现坏了。
     */
    BUG();
}

这一步只要带走三句话：

1. 1. 有 scx 时不走 fair 捷径，直接按类扫。
2. 2. 捷径只是「全是 fair」时的加速，语义上仍等价于「最终会落到 fair/idle」。
3. 3. 主线是 for_each_active_class：按类顺序问，先交出任务的类赢得 next。
   类间优先级 = 这个 for 的遍历顺序，不是另写一张数字表。

CONFIG_SCHED_CORE 是什么（旁支）

Kconfig：kernel/Kconfig.preempt:151，全称 Core Scheduling for SMT。

• • 针对 SMT / 超线程：同一物理核上的多个逻辑 CPU（siblings）可以协同选任务。
• • 打开后，可用 prctl(PR_SCHED_CORE) 把任务划进同一 core group；选 next 时尽量让 siblings 跑同组任务，对不上就让一侧 idle。
• • 用途包括缓解部分 SMT 侧信道、减少同核干扰（确定性/性能）。
• • 发行版常编进内核但默认不用；不用时几乎无额外开销。
• • 和本文主线（sched_class 谁先被问）正交：有无 SCHED_CORE，类间顺序仍是那一套。

对调用的影响：

开了之后，同文件还有一份更简单的按类扫描，只走 .pick_task（给 core 路径用）：

/* core.c:5990–6003 */
static inline struct task_struct *pick_task(struct rq *rq, struct rq_flags *rf)
{
    conststruct sched_class *class;
struct task_struct *p;

    rq->dl_server = NULL;

    for_each_active_class(class) {
        p = class->pick_task(rq, rf);
        if (p)
            return p;
    }

    BUG(); /* The idle class should always have a runnable task. */
}

初读知「同样按类问」即可；SMT cookie / forced-idle 细节可后看。

下一步：这个 for 的头尾指针、以及「下一类」怎么跳，在 sched.h 里。

第 3 步：展开 for_each_active_class，看见头尾指针

第 2 步的 for_each_active_class(class) 不是普通 class++。
它从链接排出的「最高类」走到「最低类」，每一步用 next_active_class 前进——多数时候加一格，有 scx 时可能再跳过一格空类。

宏：从哪扫到哪

/* sched.h:2714–2716：头尾是链接脚本里的地址标号（第 4 步） */
externstruct sched_class __sched_class_highest[];
externstruct sched_class __sched_class_lowest[];

/* sched.h:2746–2750 */
#define for_active_class_range(class, _from, _to)                \
    for (class = (_from); class != (_to); class = next_active_class(class))

#define for_each_active_class(class)                        \
    for_active_class_range(class, __sched_class_highest, __sched_class_lowest)
/*
 * 展开后等价于：
 *   for (class = 最高类;
 *        class != 最低类标号;          // 不含终点
 *        class = next_active_class(class))
 * 注意：这里用 != 和 next_active_class，不是简单的 class++。
 * （另有 for_each_class 用 class++ 扫「全部类」，含未激活的；选 next 用 active 版。）
 */

/* sched.h:2752 */
#define sched_class_above(_a, _b)    ((_a) < (_b))
/* 地址更小 → 类更高 → 更先被 for 问到 */

next_active_class：重点看 scx 那两段

内存里类对象大致排成一排（第 4 步钉死）：

stop → dl → rt → fair → ext → idle

class++ 就是顺着这排往后移一格。有 CONFIG_SCHED_CLASS_EXT 时，移完还可能再移一格，用来跳过当前没必要问的类：

/* sched.h:2724–2737 */
/*
 * Iterate only active classes. SCX can take over all fair tasks or be
 * completely disabled. If the former, skip fair. If the latter, skip SCX.
 *
 * 官方注释已经点明：全开 scx → 跳过 fair；没启用 scx → 跳过 ext。
 */
static inline const struct sched_class *
next_active_class(const struct sched_class *class)
{
class++;    /* 先正常走到「下一格」 */

#ifdef CONFIG_SCHED_CLASS_EXT
    /*
     * ---------- 情况 A：跳过 fair ----------
     * scx_switched_all()：BPF 已「全量接管」——原来挂在 fair 上的
     * 普通任务大都迁到 ext 了（开关何时置位见第 7 步）。
     *
     * 此时 fair 队列几乎没人，每次 schedule 仍问 fair 是浪费。
     * 若本次 class++ 刚好落到 &fair_sched_class，再 ++ 一次，直接去 ext。
     *
     * 注意比较时机：是「++ 之后」的指针和 &fair 比。
     * 例如当前停在 rt，next 时：
     *   class++ → fair → 条件成立再 ++ → ext
     * 于是扫描序列变成：… → rt →（跳过 fair）→ ext → …
     *
     * 链接顺序仍是 fair 在 ext 前；这里只是迭代时少问空类，
     * 并没有把 ext「提升」到 fair 上面。
     */
    if (scx_switched_all() && class == &fair_sched_class)
class++;

    /*
     * ---------- 情况 B：跳过 ext ----------
     * scx_enabled()：是否已加载并启用某个 BPF 调度器。
     *
     * 内核可能编译了 ext_sched_class（开了 CONFIG_SCHED_CLASS_EXT），
     * 但运行时还没 load 任何 BPF。这时问 ext 没有意义。
     * 若 class++ 落到 &ext_sched_class，再 ++，直接去 idle。
     *
     * 例如当前停在 fair，且没启用 scx：
     *   class++ → ext → 条件成立再 ++ → idle
     * 扫描序列：… → fair →（跳过 ext）→ idle
     */
    if (!scx_enabled() && class == &ext_sched_class)
class++;
#endif
    return class;
}

两个开关本身（sched.h:1830–1834）：

DECLARE_STATIC_KEY_FALSE(__scx_enabled);    /* 已 load BPF 调度器 */
DECLARE_STATIC_KEY_FALSE(__scx_switched_all);    /* fair 类任务已迁到 SCX */

#define scx_enabled()        static_branch_unlikely(&__scx_enabled)
#define scx_switched_all()    static_branch_unlikely(&__scx_switched_all)
/*
 * static_branch：运行时可开关的「极便宜」分支（内核常用技巧）。
 * 默认都是 false：没 load BPF 时，上面两段 if 都不进，等价于纯 class++。
 */

对照三种常见扫描结果（链接顺序不变，变的是「跳谁」）：

没 load BPF：     stop → dl → rt → fair → (跳过 ext) → idle
BPF + 部分接管：  stop → dl → rt → fair → ext → idle      // 两段 if 都不跳
BPF 全开：        stop → dl → rt → (跳过 fair) → ext → idle

没开 CONFIG_SCHED_CLASS_EXT 时：没有 ext 对象，也没有这两段 if；scx_enabled() 等编译成恒 false。

这一步带走什么

1. 1. for_each_active_class = 从 __sched_class_highest 走到 lowest，步进函数是 next_active_class。
2. 2. next_active_class 先 class++；有 scx 配置时，可能再跳过 空的 fair 或 未启用的 ext。
3. 3. 跳过 ≠ 改优先级：fair 在链接里仍排在 ext 前面。

运行时「怎么扫」说到这。还缺的几块，后面按这个顺序补：

第 4 步  这一排 stop→…→idle 谁写死的？     → 链接脚本 SCHED_DATA
第 5 步  每个 sched_class 对象从哪来？       → DEFINE_SCHED_CLASS + 编译
第 6 步  ext 何时出现在这一排里？           → CONFIG_SCHED_CLASS_EXT
第 7 步  第 3 步两个开关谁、何时置位？       → 加载 BPF / PARTIAL
第 8 步  任务怎么挂到某一类上？             → policy → __setscheduler_class

第 4 步：这一排顺序谁写死的？（链接脚本）

第 3 步里 class++ 能成立，是因为各 sched_class 在内存里已经排成连续一排。
__sched_class_highest / lowest不是 C 里手写的数组，而是链接脚本里的地址标号。

/* include/asm-generic/vmlinux.lds.h:153–162 */
#define SCHED_DATA                \
    STRUCT_ALIGN();                \
    __sched_class_highest = .;        \
    *(__stop_sched_class)            \
    *(__dl_sched_class)            \
    *(__rt_sched_class)            \
    *(__fair_sched_class)            \
    *(__ext_sched_class)            \
    *(__idle_sched_class)            \
    __sched_class_lowest = .;
/*
 * 链接器按上面顺序，把名为 __xxx_sched_class 的 section
 * 拼进 vmlinux。拼完后：
 *   highest 标在第一格之前，lowest 标在最后一格之后。
 * for 从 highest 扫到 lowest，class++ 就是沿这排往后走。
 */

因此固定顺序是：

低地址 ← 先被 for 问到
  stop → dl → rt → fair → ext → idle
高地址 ← 最后才问到

「谁更高」用指针比大小（第 3 步已出现）：

/* sched.h:2752 */
#define sched_class_above(_a, _b)    ((_a) < (_b))  /* 地址更小更优先 */

钉死：fair 在 ext 前面 → fair 先于 ext 被询问。
第 3 步的「跳过」只是少问空格，不能把 ext 插到 fair 前面。

下一问：链接脚本收集的是 section 名；那每个 xxx_sched_class 对象是谁放进这些 section 的？

第 5 步：每个 class 对象从哪来？

答：各调度实现文件里用宏定义全局表，编译进具名 section，再被第 4 步的 SCHED_DATA 收进去。
没有运行时 register_sched_class()。