Linux 调度器:schedule() 触发条件与抢占路径分析

schedule() 什么时候会被调用，这个问题的答案决定了 Linux 调度器的行为边界。内核代码里到处都有 trigger to schedule 的逻辑，但如果不能系统理解哪些时机真实存在、哪些是陷阱，写代码和排错的时候就会两眼一抹黑。

一、调度触发源

调度触发分三类，理解清楚就不会在代码里乱猜。

主动调度：进程在代码里主动调用 schedule()。典型场景是等 I/O、等锁、等某个事件。代码走到这里，说明当前工作已经暂时没法继续了，干脆把 CPU 让给其他人。这种调度最干净，进程自己知道该退。

被动唤醒抢占：try_to_wake_up 把一个进程唤醒之后，发现它的优先级比当前进程高，内核不会直接调用 schedule()，而是只做一件事——把当前进程的 TIF_NEED_RESCHED 标志置 1。真正的调度要等到下一个检查点才发生。

时钟中断抢占：scheduler_tick 每秒执行 HZ 次（可配，常见 100/250/1000），更新当前进程的时间片或者 vruntime。如果时间片耗尽或者 vruntime 领先太多，同样只是置 TIF_NEED_RESCHED，不直接触发调度。

关键点：后两种方式都不在中断处理程序里直接调 schedule()，只打标记。这是内核设计的一致性原则——中断上下文越短越好，真正的调度决策要等到安全点。

二、调度执行时机

TIF_NEED_RESCHED 置了之后，谁来查？谁来调？

检查点一：从中断或系统调用返回用户态之前

每个中断处理和系统调用的 exit 路径上，都会查 TIF_NEED_RESCHED。如果置了，就调 schedule()。这是最高频的调度时机——每次时钟中断回去之前都要查一次。

检查点二：preempt_enable()

如果内核编译时开了 CONFIG_PREEMPT（内核抢占），preempt_enable() 不是简单开个锁就完了，它会检查是否有人在等调度。如果 TIF_NEED_RESCHED 置了，直接触发调度。

这就是为什么抢占内核能在用户态和内核态之间被打断——普通内核（CONFIG_PREEMPT_NONE）下，只有从系统调用返回时才能调 schedule()，内核代码跑起来就是原子的。开了抢占之后，连 spinlock 解锁、preempt_enable 这些点都可能触发调度。

检查点三：中断处理返回内核态（irq_exit）

这个点最容易被忽略。硬件中断或软中断处理完毕、从 irq_exit() 返回时，如果 TIF_NEED_RESCHED 置了，在开启 CONFIG_PREEMPT 的内核下会调用 preempt_schedule_irq()，直接从内核态抢占当前进程。这不是说在中断处理程序里调 schedule()，而是中断退出路径上的安全检查——每次 I/O 中断、timer 中断回来都可能触发抢占，频率比"返回用户态"高得多。

三、主调度器执行流程

schedule() 本身只是个壳，真正的逻辑在 __schedule() 里。

步骤 1：关抢占 + 取运行队列

preempt_disable();rq = this_rq();prev = rq->curr;

先关抢占，防止调度过程中被另一个 CPU 抢走当前核心。然后取当前 CPU 的运行队列 rq 和当前进程 prev。

步骤 2：pick_next_task() 按调度类选进程

这是调度器的核心设计——插件化的调度类。内核定义了 5 个调度类，优先级从高到低：

Stop > DL (Deadline) > RT (Real-Time) > CFS > Idle

调度时，内核按这个顺序从高到低问每个调度类："你有任务要跑吗？"谁先说有，就用谁的算法选下一个。

但有一个性能快速路径（Fast Path）：如果当前 CPU 上所有可运行进程都只是普通 CFS 进程（nr_running == cfs.h_nr_running），内核直接跳过 Stop/DL/RT 类的遍历，秒进 CFS 逻辑。绝大多数服务器场景都命中这个快速路径，按"遍历 5 个类"去理解调度开销会高估实际延迟。

Stop 类最特殊，只在 CPU 热插拔、suspend/resume 这些内核级场景才用，普通应用调度不会落到这里。

步骤 3：各调度类的选法

RT 类（实时进程，优先级 1~99）：

RT 类维护一个优先级位图 + 每个优先级一个双链表。选最高优先级非空链表的头节点，O(1) 复杂度。

注意 RT 有两种调度策略：SCHED_FIFO 没有时间片，高优先级进程会一直占着 CPU 直到主动让出（sched_yield）、等待资源或被更高优先级进程抢走；SCHED_RR 有固定时间片，同优先级的进程按时间片轮转。

/* 伪代码，简化自 kernel/sched/rt.c */static struct task_struct *pick_next_rt_entity(struct rt_rq *rt_rq){  struct rt_prio_array *array = &rt_rq->active;  int idx = sched_find_first_bit(array->bitmap);  // O(1) 找最高优先级  struct list_head *head =array->queue + idx;  return list_entry(head->next, struct rt_se, run_list);}

CFS 类（普通进程，SCHED_NORMAL）：

Linux 6.6 之前，CFS 用红黑树按 vruntime 排序，选最左叶子。6.6 之后已改为 EEVDF（最早合格虚拟截止时间优先） 算法。

EEVDF 不再选 vruntime 最小的进程，而是选虚拟截止时间（virtual deadline）最小且已就绪（eligible）的实体。每个进程有一个 lag 值（延迟）和一个 deadline（截止时间），调度器挑 deadline 最小的满足 eligibility 条件的进程跑。

简单说：过去是谁"等得最久"谁跑，现在是谁"截止时间最早"谁跑。更适合多媒体、交互式等有时延敏感的场景。

/* 简化自 kernel/sched/fair.c pick_next_entity *//* 注意：这颗红黑树的排序键已从 vruntime 改为 virtual deadline */static struct sched_entity *pick_next_entity(struct cfs_rq *cfs_rq){  /* 选 deadline 最小且 eligible 的实体 */  struct sched_entity *se = __pick_first_entity(cfs_rq);  return se;}

如果你在内核 6.6 以下的机器上跑，看到的仍是红黑树按 vruntime 排序的逻辑。

Idle 类：

如果 CFS 队列是空的，说明没有普通进程想跑，那就执行 swapper/0——每个 CPU 核心的空闲进程。它的 vruntime 是负数，永远最小，兜底保证 CPU 不会闲着。

步骤 4：context_switch 上下文切换

选出来的进程如果不是当前进程，就做上下文切换，两件事：

切换地址空间：

switch_mm(prev->mm, next->mm, cpu);

把 CR3 寄存器换成下一个进程的页表。如果两个进程用同一个 mm（线程场景），这里什么都不做，TLB 也不需要刷。ASID/PCID 机制让 TLB 不一定每次都全刷。

切换内核栈和寄存器：

switch_to(prev, next, prev);  // 返回时 prev 已换成"上一个 prev"

x86 上对应的是 RSP 切换，加上 FS/GS 段寄存器等少量状态的保存/恢复。这条汇编宏返回时看起来像什么都没发生，但寄存器状态已经是下一个进程的了。

finish_task_switch：

切换完成后做清理——释放上一个进程的信号量、统计调度延迟、更新 rq 相关字段。

步骤 5：开抢占

preempt_enable();

调度完成，重新开启内核抢占。下一次被调度回来时，preempt_count 应该已经是 0 了。

四、负载均衡

调度器不只是选下一个就跑，各 CPU 核心之间的负载也要平衡。这个工作由软中断 run_rebalance_domains 驱动。

现代内核开启 NO_HZ（动态时钟）后，空闲 CPU 的时钟中断会被关闭以省电。此时负载均衡由 nohz_idle_balance() 驱动——要么由即将进入 idle 的 CPU 主动发起均衡，要么由其他忙碌 CPU 通过 IPI（处理器间中断）唤醒空闲核心来拉取任务。排查 SCHED_SOFTIRQ 延迟问题时注意：均衡不是"每秒固定 HZ 次"，而是事件驱动。

均衡逻辑比较直观：如果一个 CPU 的运行队列排着长队，另一个核心闲着，就从长的队列里搬几个进程过去。搬运的单位不是进程，是"实体"（sched_entity），CFS 里对应的是调度实体，可以是进程也可以是线程组。

负载均衡和 __schedule() 是相对独立的两个机制——均衡器改的是运行队列的内容，调度器决定的是从队列里选哪个跑。

五、一个完整的调度周期

把上面的内容串起来，看一个完整场景：

1. 进程 A 在用户态跑，时间片还没用完
2. 时钟中断来了，scheduler_tick 检查 A 的时间片，发现没用完，不置 TIF_NEED_RESCHED，直接返回
3. 进程 A 继续跑，时间片用完了
4. 时钟中断来了，scheduler_tick 发现 A 的时间片耗尽，置 TIF_NEED_RESCHED = 1，返回
5. A 从系统调用返回用户态之前，查到 TIF_NEED_RESCHED 置了，调 schedule()
6. schedule() → __schedule()，pick_next_task() 选了进程 B（虚拟截止时间 virtual deadline 最小）

（6.6 之前的内核按 vruntime 最小选，逻辑类似但排序键不同） 7. B 不等于 A，context_switch 切过去 8. A 被换下，下次被调度到时从断点继续

这就是 Linux 调度最常见的路径。每秒 HZ 次的时钟中断打标记，安全点查标记触发调度，调度器按调度类优先级选下一个进程跑。理解了这条主线，再去看具体的调度类实现或者 RT 进程的实时性保证，就不容易迷失。