1 进程切换
进程切换，又称为任务切换、上下文切换、或者任务调度。本文就研究Linux内核的进程切换。我们首先理解几个概念。
1.1 硬件上下文
我们知道每个进程都有自己的地址空间，但是所有的进程却共享CPU寄存器。所以，在恢复进程执行之前，内核必须保证该进程在挂起时的寄存器值重新加载到CPU的寄存器中。
这些需要加载到CPU寄存器中的值就成为硬件上下文。硬件上下文是进程执行上下文的一个子集，进程执行上下文包含进程执行所需要的所有信息。在Linux中，进程的硬件上下文一部分存储在进程描述符中，而其它部分存储在内核态的栈中。
在下面的描述中，我们假设，prev指向旧进程，而next指向新进程。因此，我们就可以说，进程切换就是保存prev进程的硬件上下文，然后加载next进程的硬件上下文。因为进程的切换非常频繁，所以缩短保存和加载硬件上下文的时间就很重要了。
旧版本的linux利用x86架构提供的硬件支持，并通过远程调转指令（GNU-ljump；Intel-jmp far）进行进程切换，跳转到下一个进程的任务状态段（TSS）描述符。执行这条跳转指令的同时，CPU自动执行硬件上下文切换，保存旧的硬件上下文，加载新的硬件上下文。但是，linux2.6版本以后，通过软件进行进程切换，原因如下：
- 通过一连串的mov指令，一步步执行切换，可以更好地控制加载数据的合法性。尤其是ds和es段寄存器中的值，有可能会被恶意用户篡改。如果使用远程跳转指令是无法进程数据检查的。
- 新旧方法所要求的时间是大致相同的。但是，优化硬件上下文的切换是不可能的，因为都是由CPU完成的，而Linux是使用软件代替硬件上下文切换的，所以有优化的空间，以便提高执行时间。
进程切换只能发生在内核态。在进行进程切换之前，用户态进程使用的所有寄存器内容都已经包含在内核态的栈中了。这其中就包含指定用户态进程栈指针地址的ss和esp这对寄存器内容。
1.2 任务状态段-TSS
x86架构包含一个特殊的段寄存器，称为任务状态段（TSS），用来保存硬件上下文内容。尽管Linux不使用硬件上下文切换，但还是给每个不同CPU建立一个TSS。这么做，基于两个原因：
- 当x86架构的CPU从用户态到内核态时，会从TSS中获取内核态的栈地址
- 用户态进程想要访问I/O端口的时候，CPU需要访问存储在TSS中的I/O权限位，判断进程是否被允许访问这个I/O端口。那么，当用户态进程执行in或out指令时，I/O控制单元到底做了什么呢？
- 检查eflags寄存器中IOPL位（2位）。如果等于3，也就是超级用户权限，也就是进程对于这个I/O端口来说就是一个超级用户，那么，直接执行I/O指令。否则，继续执行检查。
- 访问tr寄存器，确定当前的TSS，以及正确的I/O访问权限。
- 它检查I/O端口对应的访问权限位。如果清零，指令被执行；否则，控制单元发出常规保护的异常。
内核中使用tss_struct结构体描述TSS。init_tss数组为系统中的每一个CPU包含一个tss_struct结构。每一次进程切换，内核更新TSS相关内容，使CPU控制单元能够安全地检索自己想要的信息。因而，TSS反映了当前运行在CPU上的进程的特权级别，但是当进程不运行的时候，无需维护这些信息。
每个TSS具有8个字节长度的任务状态段描述符（TSSD）。这个描述符包含一个32位的基地址，指向TSS的起始地址 以及20位的Limit域，表示页的大小。TSSD的S标志被清零，说明这是一个系统段（参见第2章的段描述符）。
Type域设置为9或者11都可以，表明该段是一个TSS段即可。Intel最初的设计中，系统中的每个进程都应该引用自己的TSS：Type域的低第2个有效位称为Busy位，如果被设为1，进程正在CPU上执行；设为0，没有执行。在Linux的设计中，每个CPU就只有一个TSS，所以，Busy位总是设为1。换句话说，Linux中Type域一般为11。
创建的这些TSSD存储在全局描述符表（GDT）中，该表的基地址存储在CPU的gdtr寄存器中。每个CPU的tr寄存器包含对应TSS的TSSD选择器，还包含两个隐藏的、不可编程的域：TSSD的Base和Limit域。使用这种方法，CPU可以直接寻址TSS，而不必非得访问GDT中TSS的地址。
1.3 线程域
每当进程切换时，将要被替换掉的进程硬件上下文内容都应该被保存到某个地址。显然不能保存在TSS中，因为Linux为每个CPU就建立了一个TSS，而不是为每个进程建立TSS。
因而，进程描述符中添加了一个类型为thread_struct的结构，通过它，内核保存旧进程的硬件上下文。后面我们会看到，该数据结构包含了大部分的CPU寄存器，除了通用目的寄存器，比如eax、ebx等，它们被存储在内核态的栈中。
2 执行进程切换
- 进程切换的时机：
- 中断处理程序中直接调用schedule()函数，实现进程调度。
- 内核线程，是一个特殊的进程，只有内核态没有用户态。所以即可以主动调用schedule()函数进行调度，也可以被中断处理程序调用。
- 内核态进程没法直接主动调度，因为schedule()是一个内核函数，不是系统调用。所以只能在中断处理程序进行调度。
- 关键代码梳理
- 首先，schedule()函数会调用
next = pick_next_task(rq, prev);，所做的工作就是根据调度算法策略，选取要执行的下一个进程。 - 其次，根据调度策略得到要执行的进程后，调用
context_switch(rq, prev, next);，完成进程上下文切换。其中，最关键的switch_to(prev,next, prev);切换堆栈和寄存器的状态。
- 首先，schedule()函数会调用
我们假设prev指向被切换掉的进程描述符，next指向将要执行的进程描述符。我们将会在第7章发现，prev和next正是schedule()函数的局部变量。
2.1 switch_to宏
进程硬件上下文的切换是由宏switch_to完成的。该宏的实现与硬件架构是息息相关的，要想理解它需要下一番功夫。下面是基于X86架构下的该宏实现的汇编代码：
#define switch_to(prev, next, last)
do {
/*
* 进程切换可能会改变所有的寄存器，所以我们通过未使用的输出变量显式地修改它们。
* EAX和EBP没有被列出，是因为EBP是为当前进程访问显式地保存和恢复的寄存器，
* 而EAX将会作为函数__switch_to()的返回值。
*/
unsigned long ebx, ecx, edx, esi, edi;
asm volatile("pushflnt" /* save flags */
"pushl %�pnt" /* save EBP */
"movl %%esp,%[prev_sp]nt" /* save ESP */
"movl %[next_sp],%%espnt" /* restore ESP */
"movl $1f,%[prev_ip]nt" /* save EIP */
"pushl %[next_ip]nt" /* restore EIP */
__switch_canary
__retpoline_fill_return_buffer
"jmp __switch_ton" /* regparm call */
"1:t"
"popl %�pnt" /* restore EBP */
"popfln" /* restore flags */
/* 输出参数 */
: [prev_sp] "=m" (prev->thread.sp),
[prev_ip] "=m" (prev->thread.ip),
"=a" (last),
/* 列出所有可能会修改的寄存器 */
"=b" (ebx), "=c" (ecx), "=d" (edx),
"=S" (esi), "=D" (edi)
__switch_canary_oparam
/* 输入参数 */
: [next_sp] "m" (next->thread.sp),
[next_ip] "m" (next->thread.ip),
/* 为函数__switch_to()设置寄存器参数 */
[prev] "a" (prev),
[next] "d" (next)
__switch_canary_iparam
: /* reloaded segment registers */
"memory");
} while (0)
上面是一段GCC内嵌汇编代码，关于其详细的语法使用方法可以参考GCC内嵌汇编使用手册。
- 首先，该宏具有3个参数，
prev、next和lastprev和next这2个参数很容易理解，分别指向新旧进程的描述符地址；last，是一个输出参数，用来记录是从哪个进程切换来的。
- 为什么需要
last参数呢？ 当进程切换涉及到3个进程的时候，3个进程分别假设为A、B、C。假设内核决定关掉A进程，激活B进程。在schedule函数中，prev指向A的描述符，而next指向B的描述符。只要switch_to宏使A失效，A的执行流就会冻结。后面，当内核想要重新激活A，必须关掉C进程，就要再执行一次switch_to宏，此时prev指向C，next指向A。当A进程想要继续执行之前的执行流时，会查找原先的内核态栈，发现prev等于A进程描述符，next等于B进程描述符。此时，调度器失去了对C进程的引用。保留这个引用非常有用，我们后面再讨论。
图3-7分别展示了进程A、B和C内核态栈的内容，及寄存器eax的值。还展示了last的值，随后被eax中的值覆盖。
switch_to宏的处理过程如下：
将新旧进程描述符存放到CPU寄存器中：
保存旧进程的内核态栈，比如eflags和ebp寄存器的内容。
保存旧进程栈指针esp到prev->thread.esp中
操作数484(�x)表明目的地址是寄存器eax中的地址加上484。
将新进程的栈指针加载到esp寄存器中。
movl 484(�x), %esp
保存标签1的地址->prev->thread.eip。
movl $1f, 480(�x)
加载新进程的指令流。
意义和第5步差不多，就是执行顺序相反。
跳转到__switch_to()函数执行，是一个C函数。
至此，进程A被进程B取代：开始执行B进程的指令。第一步应该是先弹出eflags和ebp寄存器的值。
拷贝eax寄存器的内容（第1步加载的）到last变量中。
也就是说，last记录了被取代的进程。
2.2 __switch_to()函数
实际上大部分的进程切换工作是由__switch_to()函数完成的，它的参数是prev_p和next_p，分别指向旧进程和新进程。这个函数和普通的函数有些差别，因为__switch_to()函数从eax和edx寄存器中获取prev_p和next_p这两个参数（在分析switch_to宏的时候已经讲过），而不是像普通函数那样，从栈中获取参数。为了强制函数从寄存器中获取参数，内核使用__attribute__和regparm进行声明。这是gcc编译器对C语言的一个非标准扩展。__switch_to()函数定义在include/asm-i386/system.h文件中：
__switch_to(struct task_struct *prev_p,
struct task_struct *next_p)
__attribute__(regparm(3));
这个函数执行的内容：
执行__unlazy_fpu()宏，保存旧进程的FPU、MMX和XMM寄存器
执行smp_processor_id()宏，获取正在执行代码的CPU的ID。从thread_info结构的cpu成员中获取。
加载新进程的next_p->thread.esp0到当前CPU的TSS段中的esp0成员中。通过调用sysenter汇编指令从用户态切换到内核态引起的任何特权级别的改变都会导致将这个地址拷贝到esp寄存器中。
将新进程的线程本地存储（TLS）段加载到当前CPU的GDT中。3个段选择器存储在进程描述符的tls_array数组中。
存储fs和gs段寄存器的内容到旧进程的prev_p->thread.fs和prev_p->thread.gs中。汇编指令如下：
寄存器esi指向prev_p->thread结构。gs寄存器用来存放TLS段的地址。fs寄存器实际上windows使用。
加载新进程的fs或gs寄存器内容。数据来源是新进程的thread_struct描述符中对应的值。汇编语言如下：
ebx寄存器指向next_p->thread结构。
载入新进程的调式寄存器中的信息。
更新TSS中的I/O权限位（如果有必要的话）。也就是如果新旧进程对I/O访问有自己特殊的要求的话就需要更改。
__switch_to()函数结束。
相应的汇编语言就是：
因为switch_to总是假设eax寄存器保存旧进程的进程描述符的地址。所以，这里把prev_p变量再次写入到eax寄存器中。
