4.6 抢占和上下文切换
上下文切换，是从一个可执行进程切换到另一个可执行进程，定义在kernel/sched.c中context_switch()函数负责处理。
/*
* context_switch - switch to the new MM and the new
* thread's register state.
*/
static inline void
context_switch(struct rq *rq, struct task_struct *prev,
struct task_struct *next)
{
struct mm_struct *mm, *oldmm;
prepare_task_switch(rq, prev, next);
trace_sched_switch(rq, prev, next);
mm = next->mm;
oldmm = prev->active_mm;
/*
* For paravirt, this is coupled with an exit in switch_to to
* combine the page table reload and the switch backend into
* one hypercall.
*/
arch_start_context_switch(prev);
if (likely(!mm)) {
next->active_mm = oldmm;
atomic_inc(&oldmm->mm_count);
enter_lazy_tlb(oldmm, next);
} else
switch_mm(oldmm, mm, next);
if (likely(!prev->mm)) {
prev->active_mm = NULL;
rq->prev_mm = oldmm;
}
/*
* Since the runqueue lock will be released by the next
* task (which is an invalid locking op but in the case
* of the scheduler it's an obvious special-case), so we
* do an early lockdep release here:
*/
#ifndef __ARCH_WANT_UNLOCKED_CTXSW
spin_release(&rq->lock.dep_map, 1, _THIS_IP_);
#endif
/* Here we just switch the register state and the stack. */
switch_to(prev, next, prev);
barrier();
/*
* this_rq must be evaluated again because prev may have moved
* CPUs since it called schedule(), thus the 'rq' on its stack
* frame will be invalid.
*/
finish_task_switch(this_rq(), prev);
}
当一个新的进程被选出来准备投入运行时，schedule()就会调用该函数。主要完成两项基本工作：
调用声明在asm/mmu_context.h中的switch_mm()，该函数负责把虚拟内存从上一个进程映射切换到新进程中。
调用声明在asm/system.h中的switch_to，该函数负责从上一个进程的处理器状态切换到新进程的处理器状态。这包括保存、恢复栈信息和寄存器信息，还有其他任何与体系结构相关的状态信息，都必须以每个进程为对象进行管理和保存。
内核知道何时调用schedule()。如果仅靠用户程序代码显式地调用schedule()，它们可能会永远地执行下去。相反，内核提供一个need_resched标志来表明是否需要重新执行一次调度。当某个进程应该被抢占时，scheduler_tick()就会设置这个标志；当一个优先级高的进程进入可执行状态时，try_to_wake_up()也会设置这个标志，内核检查该标志，确认其被设置，调用schedule()来切换到一个新的进程。该标志对于内核来讲是一个信息，它表示有其他进程应当被运行了，要尽快调用调度程序。
再返回用户空间以及从中断返回时，内核也会检查need_resched标志。如果已被设置，内核会在继续执行之前调用调度程序。
每个进程都包含一个need_resched标志，这是因为访问进程描述符内的数值要比访问一个全局变量快。
1、用户抢占
内核即将返回用户空间时，如果need_resched标志被设置，会导致schedule()函数被调用，此时会发生用户抢占。在内核返回用户空间时，它知道自己是安全的，因为既然它可以继续去执行当前进程，那么它当然可以再去选择一个新的进程去执行。所以，内核无论是在中断处理程序还是在系统调用后返回，都会检查need_resched标志。如果它被设置了，那么，内核会选择一个其他进程投入运行。从中断处理程序或系统调用返回的返回路径都是跟体系结构相关的，在entry.S 文件中通过汇编语言来实现的。
用户抢占在以下情况是发生：
从系统调用返回用户空间时。
从中断处理程序返回用户空间时。
2、内核抢占
Linux支持内核抢占。在不支持内核抢占的内核中，内核代码可以一直执行，到完成为止。调度程序没有办法在一个内核级的任务正在执行时重新调度——内核中的各任务是以协作方式调度的，不具备抢占性。内核代码一直要执行到完成（返回用户空间）或明显的阻塞为止。在2.6的内核中，内核引入抢占能力；现在，只要重新调度是安全的，内核就可以在任何时间抢占正在执行的任务。
那么，何时重新调度是安全的？只要没有持有锁，内核就可以进行抢占。锁是非抢占区域的标志。由于内核支持SMP的，所以，如果没有持有锁，正在执行的代码就是可以抢占的。
为了支持内核抢占所做的第一处变动，就是为每个进程的thread_info引入preempt_count计数器。
arch/arm/include/asm/thread_info.h
/*
* low level task data that entry.S needs immediate access to.
* __switch_to() assumes cpu_context follows immediately after cpu_domain.
*/
struct thread_info {
unsigned long flags; /* low level flags */
int preempt_count; /* 0 => preemptable, <0 => bug */
mm_segment_t addr_limit; /* address limit */
struct task_struct *task; /* main task structure */
struct exec_domain *exec_domain; /* execution domain */
__u32 cpu; /* cpu */
__u32 cpu_domain; /* cpu domain */
struct cpu_context_save cpu_context; /* cpu context */
__u32 syscall; /* syscall number */
__u8 used_cp[16]; /* thread used copro */
unsigned long tp_value;
struct crunch_state crunchstate;
union fp_state fpstate __attribute__((aligned(8)));
union vfp_state vfpstate;
#ifdef CONFIG_ARM_THUMBEE
unsigned long thumbee_state; /* ThumbEE Handler Base register */
#endif
struct restart_block restart_block;
};
preempt_count的初始值为0，每当使用锁时数值加1，释放锁时数值减1。当数值为0时，内核就可以抢占。从中断返回用户空间时，内核会检查need_resched和preempt_count的值。如果need_resched被设置，并且preempt_count为0，这说明有一个更为重要的任务需要执行并且可以安全地抢占，此时，调度程序就会被调用。如果preempt_count不为0，说明当前任务持有锁，所以抢占是不安全的。这时，内核直接从中断返回当前执行进程。如果当前进程持有的所有锁都被释放了，preempt_count会重新为0。此时，释放锁的代码会检查need_resched是否被设置。如果是，会调用调度程序。
如果内核中的进程被阻塞了，或它显式地调用了schedule()，内核抢占也会显式地发生。这种形式的内核抢占从来都是受支持的，因为根本无须额外的逻辑来保证内核可以安全地被抢占。如果代码显式地调用了schedule()，那么可以安全地被抢占的。
内核抢占会发生在：
中断处理程序正在执行，且返回内核空间之前。
内核代码再一次具有可抢占性的时候。
如果内核中的任务显式地调用schedule()。
如果内核中的任务阻塞，这同样也会导致调用schedule()。