转自：https://zhuanlan.zhihu.com/p/163728119
概述：
进程切换分为自愿(voluntary)和强制(involuntary)两种。通常自愿切换是指任务由于等待某种资源，将state改为非RUNNING状态后，调用schedule()主动让出CPU；而强制切换(即抢占)则是任务状态仍为RUNNING却失去CPU使用权，情况有任务时间片用完、有更高优先级的任务、任务中调用cond_resched()或yield让出CPU。
本文主要介绍抢占式进程切换(involuntary context switch)，抢占又根据抢占发生的时机划分为用户抢占和内核抢占。
注意：1.文章基于arm64架构的linux5.0内核代码；2. 默认开启内核抢占CONFIG_PREEMPT
关于调度器：
内核中存在两个调度器，即主调度器及周期性调度器，通称为通用调度器。主调度器函数为__schedule()；周期性调度器函数为scheduler_tick()。其中主调度器在内核代码中需要被主动调用，周期性调度器则伴随着系统的tick中断每秒HZ次的发生。
抢占前的检查：
- 是否安全？
抢占发生的前提是要确保此次抢占是安全的。什么算安全？即current任务没有持有自旋锁，否则可能会发生死锁。于是在引入内核抢占机制(CONFIG_PREEMPT)的时同时引入了preempt_count，用来保证抢占的安全性，获取锁前会去inc抢占计数，而抢占发生前会去检查preempt_count是否为0。
- 是否需要抢占？
关于是否需要去抢占，会去判断thread_info的成员flags是否设置了TIF_NEED_RESCHED标志位。(tif_need_resched()即用来判断此flag是否置位)
*后面会有具体的抢占例子分析。
进程切换的统计：
每个进程的强制切换和自愿切换的次数都会被记录在/proc/pid/status中：
/*通过procfs查看*/
grep ctxt /proc/26995/status
voluntary_ctxt_switches: 79
nonvoluntary_ctxt_switches: 4
/*使用pidstat命令查看*/
pidstat -w 自愿切换和强制切换的统计值在实践中有什么意义呢？
答：大致而言，如果一个进程的自愿切换占多数，意味着它对CPU资源的需求不高；如果一个进程的强制切换占多数，表明它对CPU的依赖较强，意味着对它来说CPU资源可能是个瓶颈(这里需要排除进程频繁调用sched_yield()导致强制切换的情况)
内核抢占的几个时机：
- 中断返回内核空间：
发生在内核态的中断el1_irq退出前，即irq handler之后，kernel_exit恢复现场之间。会去检查current进程的preempt_count和need_resched以判断是否需要进行一次抢占。
/*文:arch/arm64/kernel/entry.S
函数调用：
el1_irq
irq_handler
el1_preempt
preempt_schedule_irq
__schedule(true)
*/
el1_irq:
kernel_entry 1
enable_da_f
irq_handler
#ifdef CONFIG_PREEMPT
ldr x24, [tsk, #TSK_TI_PREEMPT] /* 抢占前的检查：preempt_count和need_resched.
注意：设置need_resched的地方，同时也会设置TIF_NEED_RESCHED，所以这里检查need_resched即可。
*/
cbnz x24, 1f /* 判断是否要跳转*/
bl el1_preempt /* 跳转el1_preempt中尝试抢占*/
1:
#endif
#ifdef CONFIG_TRACE_IRQFLAGS
bl trace_hardirqs_on
#endif
kernel_exit 1
ENDPROC(el1_irq)
#ifdef CONFIG_PREEMPT
el1_preempt:
mov x24, lr
1: bl preempt_schedule_irq /* 中断抢占的核心函数。注意：执行到此中断仍是关闭的，所以跳转回来时中断也要是关闭的*/
ldr x0, [tsk, #TSK_TI_FLAGS]
tbnz x0, #TIF_NEED_RESCHED, 1b
ret x24
#endif
/*文件：kernel/sched/core.c */
asmlinkage __visible void __sched preempt_schedule_irq(void) // 封装了__schedule函数，且它会保证返回时local中断仍关闭。
{
enum ctx_state prev_sta;
/* Catch callers which need to be fixed */
BUG_ON(preempt_count() || !irqs_disabled()); //检测异常：若抢占计数不为零，或者中断没有关闭 则dump_stack并产生oops。
prev_state = exception_enter(); //保存当前cpu的异常状态下的上下文到prev_state
do {
preempt_disable(); //关抢占，__schedule的过程不允许被抢占
local_irq_enable(); //使能中断
__schedule(true); //调度器核心函数。true表示此次切换为抢占。
local_irq_disable(); //关闭中断
sched_preempt_enable_no_resched(); //开抢占
} while (need_resched()); //如果调度出去后的进程操作了被中断进程的thread_info.flags，使它仍为TIF_NEED_SCHED，那就继续进行调度。
exception_exit(prev_state); //恢复抢占前的保存在prev_state中的异常上下文。
}
- 内核中调用cond_resched()
内核代码中显式调用cond_resched()触发抢占，它的核心函数是preempt_schedule_common
/*cond_resched()在kernel代码中有着较广泛的使用*/
int __sched _cond_resched(void)
{
if (should_resched(0)) { //判断preempt_count是否为0。为0则代表开启抢占，need_resched也已被设置。
preempt_schedule_common(); //__schedule函数的封装函数。
return 1;
}
rcu_all_qs();
return 0;
}
static void __sched notrace preempt_schedule_common(void)
{
do {
preempt_disable_notrace();
preempt_latency_start(1);
__schedule(true); //调用__sechdule,且传参true代表这里是抢占
preempt_latency_stop(1);
preempt_enable_no_resched_notrace();
} while (need_resched()); //如果调度出去后的进程操作了被当前进程的thread_info.flags，使它仍为TIF_NEED_SCHED，那就继续进行调度
}- 内核中使能preempt时
内核代码中调用preempt_enable()开启preempt时也会检查执行抢占。
/*函数调用：
preempt_enable()
__preempt_schedule()
preempt_schedule()
preempt_schedule_common()
*/
当前任务开启抢占时，也会检查并执行一次抢占。类似cond_resched()最终调用preempt_schedule_common()函数。注意：非抢占的内核在spin_unlock()中不检查调度，而cond_resched在两种内核中都检查调度 (具体可查看代码实现)
用户抢占：
- 中断返回用户空间：
当中断发生在进程的用户态，中断返回用户空间时也会检查是否需要执行抢占。
/*文件:arch/arm64/kernel/entry.S
函数调用：
ret_to_user
work_pending
do_notify_resume
schedule()
*/
work_pending:
mov x0, sp // 'regs'
bl do_notify_resume //跳转到do_notify_resume函数。
#ifdef CONFIG_TRACE_IRQFLAGS
bl trace_hardirqs_on // enabled while in userspace
#endif
ldr x1, [tsk, #TSK_TI_FLAGS] // re-check for single-step
b finish_ret_to_user
ret_to_user:
disable_daif //D A I F分别为PSTAT中的四个异常屏蔽标志位，此处屏蔽这4中异常。(irq这里理论上没有开，为什么还关？)
ldr x1, [tsk, #TSK_TI_FLAGS] //获取thread_info中的flags变量的值
and x2, x1, #_TIF_WORK_MASK //_TIF_WORK_MASK是一些列flags的集合，其中包括NEED_RESCHED|SIGPENDING|NOTIFY_RESUME等值
cbnz x2, work_pending //判断并跳转。此处判断若有_TIF_WORK_MASK的中任何flag都去执行work_pending
finish_ret_to_user:
enable_step_tsk x1, x2
#ifdef CONFIG_GCC_PLUGIN_STACKLEAK
bl stackleak_erase
#endif
kernel_exit 0
ENDPROC(ret_to_user)
asmlinkage void do_notify_resume(struct pt_regs *regs, /* 处理thread_info中pending的flag事件。
unsigned long thread_flags) 进入此函数，中断必须是关闭的。这里大概就是ret_to_user中再次调disable_daif的原因。
*/
{
do {
/* Check valid user FS if needed */
addr_limit_user_check();
if (thread_flags & _TIF_NEED_RESCHED) { //上来就判断_TIF_NEED_RESCHED，若置位则直接调schedule
/* Unmask Debug and SError for the next task */ //取消被屏蔽的其他异常，只关闭IRQ异常！
local_daif_restore(DAIF_PROCCTX_NOIRQ);
schedule(); //调度的核心函数，进行抢占。
} else {
......
} while (thread_flags & _TIF_WORK_MASK);
}- 系统调用返回用户空间
系统调用返回用户空间和中断返回用户空间都是通过ret_to_user函数，所以判断执行抢占的部分是相同的。
/*文件:arch/arm64/kernel/entry.S
函数调用：
ret_to_user
work_pending
do_notify_resume
schedule()
*/
arm64中syscall通过同步异常el0_sync->el0_svc->el0_svc_handler处理完成后，ret_to_user返回用户空间。
参考中断返回用户空间。主动调度：
当进程阻塞时，例如mutex，sem，waitqueue获取不到资源，在或者进程进行磁盘读写。这种情况下进程会将自己的状态从TASK_RUNNING修改为TASK_INTERRUPTIBLE或是TASK_UNINTERRUPTIBLE，然后调用schedule()主动让出CPU并等待唤醒。
/*以磁盘IO中的一处使用举例：
文件:fs/direct-io.c
*/
static struct bio *dio_await_one(struct dio *dio)
{
....
while (dio->refcount > 1 && dio->bio_list == NULL) {
__set_current_state(TASK_UNINTERRUPTIBLE); //先将当前进程的state设置为TASK_UNINTERRUPTIBLE不可唤醒状态。
dio->waiter = current;
spin_unlock_irqrestore(&dio->bio_lock, flags);
if (!(dio->iocb->ki_flags & IOCB_HIPRI) ||
!blk_poll(dio->bio_disk->queue, dio->bio_cookie, true))
io_schedule(); //调用io_schedule让出cpu，并等待io完成后被唤醒。
/* wake up sets us TASK_RUNNING */
.....
}关于周期性调度器的简要说明：
前文我们说到，执行抢占时会检查TIF_NEED_RESCHED标志，以判断是否需要执行抢占。那TIF_NEED_RESCHED在什么地方被设置呢？其一是在进程被wakeup的时候，再一地方就是在周期性调度器(scheduler_tick)中。
时钟tick以每秒HZ次的频率发生，在时钟tick的中断处理函数里，会去调用周期性调度器scheduler_tick()检查并设置TIF_NEED_RESCHED和need_resched。而这本身就在一个中断里，当中断返回时又回去检查执行抢占。
/*函数调用：
.....
tick_sched_timer()
tick_sched_handle()
update_process_times()
scheduler_tick()
task_tick_fair()
entity_tick()
resched_curr()
set_tsk_need_resched(curr); //设置TIF_NEED_RESCHED
set_preempt_need_resched(); //设置need_resched，即PREEMPT_NEED_RESCHED
*/
scheduler_tick(){
sched_clock_tick(); //更新系统的时钟ticket
update_rq_lock(rq); //更新当前cpu就需队列中的时钟计数，struct rq中包含clock和clock_task两个runqueue的时间
curr->sched_class->task_tick(rq,curr,0); //调用对应调度类中的task_tick方法(每个调度类都有实现自己的task_tick)
//重点关注cfs中实现的task_tick_fair->entity_tick；分析如下面代码
//entity_tick中会检查是否需要抢占调度
cpu_load_update_active(rq);
trigger_load_balance(rq); //若是smp架构的话会去调负载均衡
}
void resched_curr(struct rq *rq)
{
.....
if (cpu == smp_processor_id()) {
set_tsk_need_resched(curr); //设置TIF_NEED_RESCHED
set_preempt_need_resched(); //设置need_resched，即PREEMPT_NEED_RESCHED
return;
}
......
}
转自：https://zhuanlan.zhihu.com/p/163728119