上下文切换

进程调度是linux系统中再常见不过的事情，对于进程的调度，这里不管什么调度策略什么的，直接来看看进程的切换做了些什么事情。

这里从内核的上下文切换函数context_switch开始分析。

static inline   task_t * context_switch(runqueue_t * rq, task_t *prev, task_t *next)   {   struct mm_struct *mm = next->mm;   struct mm_struct *oldmm = prev->active_mm;      if (unlikely(!mm)) {  /*切换进来的进程是内核线程*/ next->active_mm = oldmm;   /*借用前一个进程的进程空间*/ atomic_inc(&oldmm->mm_count);   enter_lazy_tlb(oldmm, next);  /*惰性TLB*/ } else   switch_mm(oldmm, mm, next);  /*切换运行空间*/    if (unlikely(!prev->mm)) { /*前一个进程是内核线程*/  prev->active_mm = NULL;   /*断开与借用的地址空间的联系*/ WARN_ON(rq ->prev_mm);   rq ->prev_mm = oldmm;   }      /* Here we just switch the register state and the stack. */   switch_to(prev, next, prev);  /*切换执行环境*/    return prev;   }

进程切换最主要的事情是进程执行环境的切换和运行空间的切换。

先来看看task_struct结构体的两个重要字段：mm和active_mm。mm是表示进程所拥有的内存的描述符，active_mm是表示进程运行时所使用的内存的描述符。内核线程和用户进程都是task_struct的实例，区别在于内核线程是没有进程地址空间的。

	mm	active_mm
内核线程	NULL	指向上一个被调用进程的active_mm值
用户进程	两者相等

context_switch函数首先判断切换进来的进程next是内核线程还是用户进程。如果next是内核线程，那么它借用上一个进程的地址空间；由于内核线程不访问用户态地址空间，没有必要使一个用户态线性地址对应的TLB表项无效，因此调用enter_lazy_tlb通知底层体系结构不需要切换虚拟地址空间的用户空间部分。

如果next是用户进程，那么就调用switch_mm函数切换运行空间。下面分析下次函数代码实现。

static inline void switch_mm(struct mm_struct *prev,  struct mm_struct *next,   struct task_struct *tsk)   {   if (likely(prev != next)) {   cpu_clear(cpu, prev->cpu_vm_mask); /*清除cpu_vm_mask，表示prev已经弃用了当前cpu*/ #ifdef CONFIG_SMP   per_cpu(cpu_tlbstate, cpu).state = TLBSTATE_OK;   per_cpu(cpu_tlbstate, cpu).active_mm = next;   #endif   cpu_set(cpu, next->cpu_vm_mask); /*设置next的cpu_vm_mask标志，表示next占用了当前cpu*/   /*将进程next的页目录表首地址next->pgd转换成物理地址，并将其写入寄存器cr3中*/  load_cr3(next->pgd);     if (unlikely(prev->context.ldt != next->context.ldt))   load_LDT_nolock(&next->context, cpu);   }   #ifdef CONFIG_SMP   else {   per_cpu(cpu_tlbstate, cpu).state = TLBSTATE_OK;   BUG_ON(per_cpu(cpu_tlbstate, cpu).active_mm != next);           /*判断next进程在切换出去之前是否运行在当前cpu上*/ if (!cpu_test_and_set(cpu, next->cpu_vm_mask)) {     load_cr3(next->pgd);   load_LDT_nolock(&next->context, cpu);   }   }   #endif   }

从上面代码可以看到switch_mm最主要的工作就是切换pgd，我们知道pgd是包括内核空间和用户空间的地址映射的，但是因为所有进程的内核空间的地址映射是相同的，所以只需要进行用户空间的切换。

这里切换了页表，即地址空间，不会立马引起控制流程的改变。现在处于内核空间，而所有进程的内核空间的地址映射是一样的。但是当从内核空间返回用户空间时，这里的改变就会引起本质的改变，会跳到next的用户代码中执行。

在SMP系统中，即使prev和next是同一个进程，但是如果切换前后运行在不同的CPU上，这里还是需要重新加载CR3的。

接下来分析switch_to宏，这个宏比较难理解。下面是x86架构下面的代码分析。

#define switch_to(prev,next,last) do {  \   unsigned long esi,edi;  \   asm volatile("pushfl\n\t"   \  /*在prev内核栈上保存prev进程的efalgs*/ "pushl %%ebp\n\t"  \        /*在prev内核栈上保存prev进程的ebp*/ "movl %%esp,%0\n\t" /* save ESP */ \  /*将esp寄存器的值装入prev进程的thread.esp*/ "movl %5,%%esp\n\t"   /* restore ESP */  \  /*将next进程的thread.esp装入esp寄存器*/ "movl $1f,%1\n\t"  /* save EIP */  \         /*将prev进程恢复执行的指令设置为标号1位置处*/ "pushl %6\n\t"   /* restore EIP */ \       /*将next进程恢复执行的指令位置压入next的内核栈*/ "jmp __switch_to\n"  \         "1:\t"   \   "popl %%ebp\n\t"  \   "popfl"  \   :"=m" (prev->thread.esp),"=m" (prev->thread.eip),  \   "=a" (last),"=S" (esi),"=D" (edi)   \   :"m" (next->thread.esp),"m" (next->thread.eip), \   "2" (prev), "d" (next));    \   } while (0)

上面是x86架构下的switch_to宏的代码，是用内嵌汇编实现的。switch_to函数有5个输出参数，4个输入参数，第一个输出参数开始，参数以0开始编号，依次增加。

我们从注释就可以看到switch_to主要干的事情就是切换内核栈和寄存器。此宏开始4条命令就是切换内核堆栈。它首先保存prev进程的eflags、ebp寄存器压入prev进程的内核栈，然后将esp的值装入prev进程的thread.esp字段，最后就是将next进程的thread.esp字段装入esp寄存器中，这样就开始使用next进程的内核栈，即达到了切换内核栈的目的了。

调用switch_to宏之前

切换内核栈之前

切换内核栈之后

接下来的3条指令就是切换内核的控制流程。首先将prev进程恢复执行的指令位置设置为标号1位置处，然后就是将next进程恢复执行的指令位置压入next的内核栈。接下来就是通过jmp跳转到__switch_to函数执行，此函数执行完之后不会返回到下面的标号1处，而是到next进程的thread.ip处开始执行。

__switch_to返回之前

__switch_to返回之后

call和jmp指令的差别： call指令在执行前将其后紧跟着的一条指令的地址压入堆栈，然后jmp到call调用的地址去执行，遇到ret时弹出堆栈中的指令地址，继续执行。

试想一下，如果next进程不是新创建的，那么它上一次也是通过switch_to宏调度出去的，它的恢复执行的位置必定也是在标号1处，此时next进程的内核栈上还保存有eflags和ebp寄存器。紧跟的两条pop命令就会弹出寄存器。

switch_to宏完成

上面就是switch_to宏的做的事情，下面分析下switch_to为什么有三个参数，prev和next两个参数不行吗？

switch_to宏的第三个参数last是输出参数，而且是使用寄存器eax的值。__switch_to函数是有两个参数和一个返回值的，x86架构下默认的是堆栈传参的，但我们在前面的内嵌汇编代码中，没有看到在调用__switch_to之前有对参数入栈的操作？那有可能是通过寄存器传参的，查找arch/i386/Makefile文件，有下面的代码：

-mregparm=3表示使用3个寄存器传参，这证明了__switch_to是通过寄存器传参的，返回值是通过eax寄存器传递的。因此__switch_to函数的返回值就传递给了last，即作为switch_to宏的输出参数传递给力context_swicth函数。

分析__switch_to函数就知道返回值last为prey进程。此prev就需要好好分析下了。

上图为进程A的一个执行流示意图。调用switch_to宏切换到进程B，在switch函数返回之后，即进程A又切换回来执行的情况下，可能已经发生了多次进程的切换，就像图中所示的A切换到B，B切换到C，C切换到D，D最终切换到A。这个时候，switch_to(prev,next,last)中的第三个参数last，就是指向的进程D。

这样我们就能够对进程A重新回来执行之前被切换出去的进程D进行清理的工作。