理解进程调度时机
进程调度时机
- 中断处理过程（包括时钟中断、I/O中断、系统调用和异常）中，直接调用schedule()，或者返回用户态时根据need_resched标记调用schedule()；
- 内核线程可以直接调用schedule()进行进程切换，也可以在中断处理过程中进行调度，也就是说内核线程作为一类的特殊的进程可以主动调度，也可以被动调度；
- 用户态进程无法实现主动调度，仅能通过陷入内核态后的某个时机点进行调度，即在中断处理过程中进行调度。
schedule()函数分析
schedule()函数原型位于linux-3.18.6/kernel/sched/core.c中，其中主要的关键函数有pick_next_task()，这个函数调用之后，会根据某种进程调度策略选择出下一个运行的进程。紧接着是context_switch()，这是进程上下文切换函数，它的函数实现如下：
context_switch(struct rq *rq, struct task_struct *prev,struct task_struct *next)
{
struct mm_struct *mm, *oldmm;
prepare_task_switch(rq, prev, next);
mm = next->mm;
oldmm = prev->active_mm;
arch_start_context_switch(prev);
if (!mm) {
next->active_mm = oldmm;
atomic_inc(&oldmm->mm_count);
enter_lazy_tlb(oldmm, next);
} else
switch_mm(oldmm, mm, next);
if (!prev->mm) {
prev->active_mm = NULL;
rq->prev_mm = oldmm;
}
spin_release(&rq->lock.dep_map, 1, _THIS_IP_);
context_tracking_task_switch(prev, next);
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);
}
在context_switch()函数中，最为重要的是switch_to()函数，它主要是由内联汇编实现，功能是完成进程切换。
#define switch_to(prev, next, last)
do {
unsigned long ebx, ecx, edx, esi, edi;
asm volatile("pushfl\n\t" /* 保存当前进程的flags */
"pushl %%ebp\n\t" /* 把当前进程的当前的ebp压入当前进程的栈 */
"movl %%esp,%[prev_sp]\n\t" /*保存当前的esp到prev->thread.sp指向的内存中 */
"movl %[next_sp],%%esp\n\t" /* 重置esp，把下个进程的next->thread.sp赋予esp */
"movl $1f,%[prev_ip]\n\t" /*把1：的代码在内存中存储的地址保存到prev->thread.ip中*/
"pushl %[next_ip]\n\t" /*重置eip */
__switch_canary
"jmp __switch_to\n" /*跳转到switch_to函数*/
"1:\t"
"popl %%ebp\n\t" /* 重置ebp */
"popfl\n" /* 重置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),
[prev] "a" (prev),
[next] "d" (next)
__switch_canary_iparam
"memory");
} while (0)
switch_to()是A进程到B进程的过渡，我们可以认为在switch_to()这个点上,A进程被切出,B进程被切入。进入 switch_to()的宏里面之后，首先pushfl和pushl ebp肯定仍然属于进程 A,之后把esp指向了B的堆栈,从此时开始的指令流都属于跟B进程有关的了。但是，这个时候B进程还没有完全准备好，因为 ebp和硬件上下文等内容还没有切换成B的，剩下的部分宏代码就是完成这些事情。对于 A 进程它始终没有感觉到自己被打断过，它认为自己一直是不间断执行的。switch_to()函数，除了改变了A进程中的prev变量外，对A没有其它任何影响。在系统中任何进程看到的都是这个样子，所有进程都认为自己在不间断的独立运行。
gdb跟踪fork命令
一想到schedule()函数，我想到的就是fork命令，正好上上节课在MenOS中新增加了fork命令，所以就用gdb跟踪之前的fork命令吧。
断点设置：
b schedule
b context_switch
b pick_next_task
本来想在switch_to也设置一个断点，但设置了好几遍都没成功，起初还在想为什么，后来发现switch_to并不是单独函数，而是定义在宏中的一个宏。所以设置不了断点，然后尝试在它附近的函数设置断点，发现都无果，说明在context_switch中的“函数”都是写在宏中的，那果断放弃。
schedule()断点：
pick_next_task()断点：
context_switch()断点：
总结
进程切换的一般过程：一个用户态进程A，发生中断，save cs:eip/esp/eflags等到内核堆栈；SAVE_ALL保存现场。中断处理过程中直接调用或者中断返回前调用schedule，其中switch_to中的汇编代码做了关键的部分。切换了内核堆栈，从当前进程进入到下一个进程。从标号1开始就开始运行下一个进程（这个进程必须是曾经通过这个过程被切换出去的，比如新进程就不包含在内）;恢复下一个进程的现场，pop出eip,esp。继续运行进程切换前用户态正在跑的程序。
特殊情况：
- 通过中断处理过程中的调度，用户态进程与内核进程之间互相切换，与一般情形类似；
- 内核进程程主动调用 schedule 函数，只有进程上下文的切换，没有中断上下文切换；
- 创建子进程的系统调用在子进程中的执行起点及返回用户态，如：fork；
- 加载一个新的可执行程序后返回到用户态的情况，如：execve。
课本内容
mm_struct 与内核线程
当一个进程被调度时，该进程的mm域指向的地址空间被装载到内存，进程描述符中的active_mm域会被更新，指向新的地址空间。内核线程没有地址空间，所以mm域为NULL。于是，当一个内核线程被调度时，内核发现它的mm域为NULL，就会保留前一个进程的地址空间，随后内核更新内核线程对应的进程描述符中的active_mm域，使其指向前一个进程的内存描述符，所以在需要时，内核线程便可以使用前一个进程的页表。因为内核线程不防问用户空间的内存，所以它们仅仅使用地址空间中和内核内存相关的信息，这些信息的含义和普通进程完全相同。
页表
Linux中使用三级页表完成地址转换。利用多级页表能够节约地址转换需占用的存放空间。
- 顶级页表是全局目录（PGD)，它包含一个pgd_t类型数组，多数体系结构中pgd_t类型等同于无符号长整型类型。PGD中的表项指向二级页目录中的表项：PMD。
- 二级页表是中间爱你页目录（PMD），它是个pmd_t类型数组，其中的表项指向PTE中的表项。
- 最后一级的页表简称页表，其中包含了pte_t类型的页表项，该页表项指向物理页面。
高速缓存（cache）存在的意义（回顾）
- 访问磁盘速度要远远低于内存访问的速度，因此，从内存访问数据比从磁盘访问速度更快。
- 数据一旦被访问，就很有可能在短期再次被访问，这种在短时间内集中访问同一片数据的原理称作临时局部原理。
基树
因为在任何页I/O操作内核前都要检查页是否已经在页高速缓存中了，所以这种频繁进行的检查必须是迅速高效的，否则搜索和检查页高速缓存的开销肯能抵消页高速缓存带来的好处。页高速缓存通过两个参数address_space对象加一个偏移量进行搜索。每个address_space对象都有唯一的基树，它保存在page_tree结构体中。基树是一个二叉树，只要指定了文件偏移量，就可以在基树中迅速检索到希望的页。页面高速缓存的搜索函数find_get_page()要调用radix_tree_lookup()，该函数会在指定的基树中搜索指定的页面。
PS：学了这么多关于Linux系统实现的内容，越来越觉得数据结构的重要性，起初感觉数据结构这门课很“废”，可能是我代码写得太少。现在看来，数据结构真的是门艺术。
多线程可以避免拥塞
单个线程可能会堵塞在某个队列的处理上，不能使所有磁盘都处于饱和的工作状态，原因在于磁盘的吞吐量是非常有限的。正是因为磁盘的吞吐量很有限，所以如果只有唯一线程执行页回写操作，那么这个线程很容易苦苦等待对一个磁盘的操作。为了避免这种情况发生，内核需要多个回写线程并发执行，这样单个设备队列的拥塞救护会成为系统的瓶颈了。