从 scheduler_tick 到上下文切换：深入解析 Linux 内核的 TIF_NEED_RESCHED 标志设置流程
Linux 是如何决定何时进行上下文切换的？
在Linux中，CPU 上下文切换是指当操作系统将 CPU 从一个进程切换到另一个进程时，保存当前进程的执行状态，并加载新进程的执行状态的过程就称为上下文切换。
但在 Linux 内核中，是否切换进程通常由一个关键标志位 TIF_NEED_RESCHED 来决定。
当该标志被设置时，内核会在合适的时机（例如从中断返回或系统调用结束时）调用schedule()，从而触发上下文切换。
TIF_NEED_RESCHED标志的设置过程
刚才我们提到切换进程或任务是由TIF_NEED_RESCHED标志位来判断，那这个标志位是如何设置的呢
接下来，我们将从 scheduler_tick() 函数开始，逐步揭示这个标志位是如何被设置，并最终触发上下文切换的。
1. scheduler_tick()：调度的“心跳”
让我们先从**scheduler_tick()**函数开始 说起
scheduler_tick() 是由定时器中断（以 HZ 频率）触发的调度驱动函数。它会获取当前 CPU 上正在运行的进程，并调用该进程所属调度器的 task_tick() 方法，然后根据具体对应的调度策略判断是否需要重新调度。
// kernel/sched/core.c
void scheduler_tick(void)
{int cpu = smp_processor_id();struct rq *rq = cpu_rq(cpu);struct task_struct *curr = rq->curr;struct rq_flags rf;// ...rq_lock(rq, &rf); // 加锁以保护运行队列// ... 省略 ...// 这是核心调用：根据任务类型调用其对应的 task_tick 方法curr->sched_class->task_tick(rq, curr, 0);// ... 其他逻辑 ...rq_unlock(rq, &rf); // 解锁// ...
}
在上述代码中，最关键的一行是 curr->sched_class->task_tick(rq, curr, 0);
这行代码是调度器逻辑的入口，它根据当前运行任务 (curr) 所属的调度类 (sched_class)，动态地调用其特有的 task_tick 方法。对于 CFS（完全公平调度器）任务，就会调用 task_tick_fair()，从而进入具体的调度决策流程。
2. task_tick_fair()：CFS 的任务周期调度
刚才提到过每种调度策略都会通过一个sched_class结构体定义其行为，完全公平调度器（CFS）的调度类定义在**kernel/sched/fair.c** 文件中，它通过 DEFINE_SCHED_CLASS(fair) 结构体被绑定到 task_tick 接口上。
/* kernel/sched/fair.c */
DEFINE_SCHED_CLASS(fair) = {.enqueue_task = enqueue_task_fair,.dequeue_task = dequeue_task_fair,.yield_task = yield_task_fair,....task_tick = task_tick_fair, // 👈 心跳函数绑定在这里....update_curr = update_curr_fair,
};
那我们接着就看一下task_tick_fair函数
/** scheduler tick hitting a task of our scheduling class.** NOTE: This function can be called remotely by the tick offload that* goes along full dynticks. Therefore no local assumption can be made* and everything must be accessed through the @rq and @curr passed in* parameters.*/
static void task_tick_fair(struct rq *rq, struct task_struct *curr, int queued)
{struct cfs_rq *cfs_rq;struct sched_entity *se = &curr->se;for_each_sched_entity(se) {cfs_rq = cfs_rq_of(se);entity_tick(cfs_rq, se, queued);}if (static_branch_unlikely(&sched_numa_balancing))task_tick_numa(rq, curr);update_misfit_status(curr, rq);update_overutilized_status(task_rq(curr));task_tick_core(rq, curr);
}
首先CFS 把调度的最小单位抽象成 sched_entity，它即可以是线程也可以是进程组。每个sched_entity都会对应一个 运行队列
struct cfs_rq *cfs_rq;
struct sched_entity *se = &curr->se;
接着**for_each_sched_entity循环会一直向上遍历到最顶层的调度实体**（例如：线程 → 进程组 → 父组），并在每一层都调用 entity_tick() 函数。
for_each_sched_entity(se) {cfs_rq = cfs_rq_of(se);entity_tick(cfs_rq, se, queued);
}
3. entity_tick() 与 update_deadline()：判断是否“超时”
在 entity_tick() 函数中会调用 update_curr()，该函数会负责更新当前任务的运行时间统计信息，并在此过程中判断任务是否已超出其分配的时间片。
update_curr() 随后会调用 update_deadline()，这里便是我们寻找的触发点。该函数会更新当前任务的运行时间，并判断是否需要触发调度。我们先看一下update_deadline的具体代码
/** XXX: strictly: vd_i += N*r_i/w_i such that: vd_i > ve_i* this is probably good enough.*/
static void update_deadline(struct cfs_rq *cfs_rq, struct sched_entity *se)
{if ((s64)(se->vruntime - se->deadline) < 0)return;/** For EEVDF the virtual time slope is determined by w_i (iow.* nice) while the request time r_i is determined by* sysctl_sched_base_slice.*/se->slice = sysctl_sched_base_slice;/** EEVDF: vd_i = ve_i + r_i / w_i*/se->deadline = se->vruntime + calc_delta_fair(se->slice, se);/** The task has consumed its request, reschedule.*/if (cfs_rq->nr_running > 1) {resched_curr(rq_of(cfs_rq));clear_buddies(cfs_rq, se);}
}
当Linux中任务的虚拟运行时间超过其截止时间，并且运行队列 (cfs_rq) 中有其他可运行的任务时，就会认为当前任务的时间片已用完。此时就会调用 resched_curr() 从而设置TIF_NEED_RESCHED 标志位了
if (cfs_rq->nr_running > 1) {resched_curr(rq_of(cfs_rq));clear_buddies(cfs_rq, se);
}
4. resched_curr()：设置 TIF_NEED_RESCHED 标志
最后再看一下**resched_curr**的代码，代码在kernel/sched/core.c中
/** resched_curr - mark rq's current task 'to be rescheduled now'.** On UP this means the setting of the need_resched flag, on SMP it* might also involve a cross-CPU call to trigger the scheduler on* the target CPU.*/
void resched_curr(struct rq *rq)
{struct task_struct *curr = rq->curr;int cpu;lockdep_assert_rq_held(rq);if (test_tsk_need_resched(curr))return;cpu = cpu_of(rq);if (cpu == smp_processor_id()) {set_tsk_need_resched(curr); // 标记当前任务需要被调度set_preempt_need_resched(); // 触发抢占检查return;}if (set_nr_and_not_polling(curr))smp_send_reschedule(cpu);elsetrace_sched_wake_idle_without_ipi(cpu);
}
检查是否已标记 resched_curr函数首先会检查当前任务 (curr) 的 need_resched 标志是否已经被设置。如果已经被设置，说明任务已经被标记为需要调度就直接返回避免重复操作。
if (test_tsk_need_resched(curr))return;
处理当前对应CPU核心上的调度
这段代码检查 resched_curr 是否在当前 CPU 上被调用。如果是，它会执行两个关键步骤：
set_tsk_need_resched(curr): 显式地设置当前任务的TIF_NEED_RESCHED标志。set_preempt_need_resched(): 告诉抢占机制，在下一个安全点（例如从中断返回或系统调用结束时），应该检查该标志并立即进行一次上下文切换。
if (cpu == smp_processor_id()) {set_tsk_need_resched(curr); // 标记当前任务需要被调度set_preempt_need_resched(); // 触发抢占检查return;
}
总结：need_resched 的调用链
现在，我们可以清晰地梳理出 TIF_NEED_RESCHED 标志的完整设置流程：
这个调用链展示了 Linux 内核如何利用一个周期性的定时器中断，结合 CFS 调度器的公平性原则，最终实现了抢占式多任务的调度核心。
完整代码参考： 完整的源码可以在 Linux 内核源码的 kernel/sched/fair.c 和 kernel/sched/core.c 文件中找到这些函数的完整实现。
linux/kernel/sched/fair.c at master · torvalds/linux · GitHublinux/kernel/sched/core.c at master · torvalds/linux · GitHub