实验：理解进程调度时机跟踪分析进程调度与进程切换的过程
一、实验要求
(1)理解Linux系统中进程调度的时机，可以在内核代码中搜索schedule()函数，看都是哪里调用了schedule()，判断我们课程内容中的总结是否准确。
(2)使用gdb跟踪分析一个schedule()函数 ，验证您对Linux系统进程调度与进程切换过程的理解。
(3)特别关注并仔细分析switch_to中的汇编代码，理解进程上下文的切换机制，以及与中断上下文切换的关系。
二、实验过程
1、理解进程上下文的切换机制，以及与中断上下文切换的关系
(1)用户态进程它在用户的时候，它没法直接调用schedule（），因为schedule是个内核函数，而且它也不是一个系统调用，没法直接调用它，只能间接的调用它，间接的调用schedule（）的时机就是中断处理过程.对于用户态进程，它要从当前运行中的进程切换出去的话，那么它就必须要进入中断，这个中断是一般中断，进入中断后才会有一个可能会发生进程调度的时机，所以一般的用户态进程只能被动调度。eg正在运行的用户态进程X切换到运行用户态进程Y的过程:
正在运行的用户态进程X
①发生中断——save cs:eip/esp/eflags(current) to kernel stack,then load cs:eip(entry of a specific ISR) and ss:esp(point to kernel stack).
②SAVE_ALL //保存现场
③中断处理过程中或中断返回前调用了schedule()，其中的switch_to做了关键的进程上下文切换
④标号1之后开始运行用户态进程Y(这里Y曾经通过以上步骤被切换出去过因此可以从标号1继续执行)
⑤restore_all //恢复现场
⑥iret - pop cs:eip/ss:esp/eflags from kernel stack
继续运行用户态进程Y
(2)[内核线程]可以直接调用schedule()进行进程切换，也可以在中断处理过程中进行调度，也就是说内核线程作为一类的特殊的进程可以主动调度，也可以被动调度;用户态进程无法实现主动调度，仅能通过陷入内核态后的某个时机点进行调度，即在中断处理过程中进行调度。
2、进程调度的时机
- 中断处理过程（包括时钟中断、I/O中断、系统调用和异常）中，直接调用schedule()，或者返回用户态时根据need_resched标记调用schedule()；
- 内核线程可以直接调用schedule()进行进程切换，也可以在中断处理过程中进行调度，也就是说内核线程作为一类的特殊的进程可以主动调度，也可以被动调度；
- 用户态进程无法实现主动调度，仅能通过陷入内核态后的某个时机点进行调度，即在中断处理过程中进行调度。
3、进程的切换
-
为了控制进程的执行，内核必须有能力挂起正在CPU上执行的进程，并恢复以前挂起的某个进程的执行，这叫做进程切换、任务切换、上下文切换；
-
挂起正在CPU上执行的进程，与中断时保存现场是不同的，中断前后是在同一个进程上下文中，只是由用户态转向内核态执行；
-
进程上下文包含了进程执行需要的所有信息
-
用户地址空间：包括程序代码，数据，用户堆栈等
-
控制信息：进程描述符，内核堆栈等
-
硬件上下文（注意中断也要保存硬件上下文只是保存的方法不同）
-
schedule()函数选择一个新的进程来运行，并调用context_switch进行上下文的切换，这个宏调用switch_to来进行关键上下文切换
-
switch_to利用了prev和next两个参数：prev指向当前进程，next指向被调度的进程
-
4.关键代码分析
（1）schedule
asmlinkage __visible
void __sched schedule(void)
{
struct task_struct *tsk = current;//来获取当前进程
sched_submit_work(tsk);//避免死锁
__schedule();//处理切换过程
}
static void __sched __schedule(void)
{
...
next = pick_next_task(rq, prev);
if (likely(prev != next)) {
...
context_switch(rq, prev, next); /* unlocks the rq */
...
} else {
...
raw_spin_unlock_irq(&rq->lock);
...
}
...
post_schedule(rq);
...
}
我们根据调度策略在运行队列rq中拿出prev进程的下一个进程，如果next进程和prev不是同一个进程，则进行进程的切换并释放自旋锁，否则直接释放自旋锁。
（2）switch_to
asm volatile("pushfl
" // 保存当前进程的标志位
"pushl %%ebp
" // 当前进程的基址压栈保存EBP
"movl %%esp,%[prev_sp]
" // 保存ESP 把当前的内核堆栈栈顶保存下
"movl %[next_sp],%%esp
" // 恢复 ESP
//整体这两步是完成内核堆栈的切换
"movl $1f,%[prev_ip]
" // 保存 EIP
"pushl %[next_ip]
" //恢复 EIP
__switch_canary
"jmp __switch_to
" //跳转l
"1: "
"popl %%ebp
" //恢复 EBP
"popfl
" //恢复标志位
/* output parameters */
: [prev_sp] "=m" (prev->thread.sp),
[prev_ip] "=m" (prev->thread.ip),
"=a" (last),
/* clobbered output registers: */
"=b" (ebx), "=c" (ecx), "=d" (edx),
"=S" (esi), "=D" (edi)
__switch_canary_oparam
/* input parameters: */
: [next_sp] "m" (next->thread.sp),
[next_ip] "m" (next->thread.ip),
/* regparm parameters for __switch_to(): */
[prev] "a" (prev),
[next] "d" (next)
__switch_canary_iparam
: /* reloaded segment registers */
"memory");
先看当前进程(prev):首先保存当前进程的flags，push ebp，然后把EIP置为标号1，等到当前进程(prev)下一次再开始执行时(被__ switch_to切出来)，内核堆栈被恢复了以后，刚好会从pop ebp开始执行(和前面的push ebp相对应)，即恢复原来的堆栈状态。
再看下一个进程(next): 这个进程即将上CPU，是被jmp __ switch_ to 切换出来的进程，由于这里使用的是jmp指令而不是call指令，之前又手工压栈了EIP，所以__ switch_ to会返回到next_ ip的地方开始执行，这样就完成了进程的切换过程。 如果只有两个进程的话，那么下一次prev就变成了next，next变成prev。
课本笔记
一、进程空间分布
对于一个进程，其空间分布如下图所示：
程序段(Text):程序代码在内存中的映射，存放函数体的二进制代码。
初始化过的数据(Data):在程序运行初已经对变量进行初始化的数据。
未初始化过的数据(BSS):在程序运行初未对变量进行初始化的数据。
栈 (Stack):存储局部、临时变量，函数调用时，存储函数的返回指针，用于控制函数的调用和返回。在程序块开始时自动分配内存,结束时自动释放内存，其操作方式类似于数据结构中的栈。
堆 (Heap):存储动态内存分配,需要程序员手工分配,手工释放.注意它与数据结构中的堆是两回事，分配方式类似于链表。
二、内核空间和用户空间
Linux的虚拟地址空间范围为0～4G，Linux内核将这4G字节的空间分为两部分，将最高的1G字节（从虚拟地址0xC0000000到0xFFFFFFFF）供内核使用，称为“内核空间”。而将较低的3G字节（从虚拟地址0x00000000到0xBFFFFFFF）供各个进程使用，称为“用户空间。因为每个进程可以通过系统调用进入内核，因此，Linux内核由系统内的所有进程共享。于是，从具体进程的角度来看，每个进程可以拥有4G字节的虚拟空间。 Linux使用两级保护机制：0级供内核使用，3级供用户程序使用，每个进程有各自的私有用户空间（0～3G），这个空间对系统中的其他进程是不可见的，最高的1GB字节虚拟内核空间则为所有进程以及内核所共享。内核空间中存放的是内核代码和数据，而进程的用户空间中存放的是用户程序的代码和数据。不管是内核空间还是用户空间，它们都处于虚拟空间中。 虽然内核空间占据了每个虚拟空间中的最高1GB字节，但映射到物理内存却总是从最低地址（0x00000000），另外，使用虚拟地址可以很好的保护内核空间被用户空间破坏，虚拟地址到物理地址转换过程有操作系统和CPU共同完成(操作系统为CPU设置好页表，CPU通过MMU单元进行地址转换)。
注：多任务操作系统中的每一个进程都运行在一个属于它自己的内存沙盒中，这个沙盒就是虚拟地址空间（virtual address space），在32位模式下，它总是一个4GB的内存地址块。这些虚拟地址通过页表（page table）映射到物理内存，页表由操作系统维护并被处理器引用。每个进程都拥有一套属于它自己的页表。
三、进程内存布局
Linux进程标准的内存段布局，如下图所示，地址空间中的各个条带对应于不同的内存段，如：堆、栈之类的。
栈
进程地址空间中最顶部的段是栈，大多数编程语言将之用于存储函数参数和局部变量。调用一个方法或函数会将一个新的栈帧（stack frame）压入到栈中，这个栈帧会在函数返回时被清理掉。由于栈中数据严格的遵守FIFO的顺序，这个简单的设计意味着不必使用复杂的数据结构来追踪栈中的内容，只需要一个简单的指针指向栈的顶端即可，因此压栈（pushing）和退栈（popping）过程非常迅速、准确。进程中的每一个线程都有属于自己的栈。
通过不断向栈中压入数据，超出其容量就会耗尽栈所对应的内存区域，这将触发一个页故障（page fault），而被Linux的expand_ stack()处理，它会调用acct_ stack_ growth()来检查是否还有合适的地方用于栈的增长。如果栈的大小低于RLIMIT_STACK（通常为8MB），那么一般情况下栈会被加长，程序继续执行，感觉不到发生了什么事情。这是一种将栈扩展到所需大小的常规机制。然而，如果达到了最大栈空间的大小，就会栈溢出（stack overflow），程序收到一个段错误（segmentation fault）。
内存映射段
在栈的下方是内存映射段，内核将文件的内容直接映射到内存。任何应用程序都可以通过Linux的mmap()系统调用或者Windows的CreateFileMapping()/MapViewOfFile()请求这种映射。内存映射是一种方便高效的文件I/O方式，所以它被用来加载动态库。创建一个不对应于任何文件的匿名内存映射也是可能的，此方法用于存放程序的数据。在Linux中，如果你通过malloc()请求一大块内存，C运行库将会创建这样一个匿名映射而不是使用堆内存。“大块”意味着比MMAP_THRESHOLD还大，缺省128KB，可以通过mallocp()调整。
BBS和数据段
在C语言中，BSS和数据段保存的都是静态（全局）变量的内容。区别在于BSS保存的是未被初始化的静态变量内容，他们的值不是直接在程序的源码中设定的。BSS内存区域是匿名的，它不映射到任何文件。如果你写static intcntActiveUsers，则cntActiveUsers的内容就会保存到BSS中去。
数据段保存在源代码中已经初始化的静态变量的内容。数据段不是匿名的，它映射了一部分的程序二进制镜像，也就是源代码中指定了初始值的静态变量。所以，如果你写static int cntActiveUsers=10，则cntActiveUsers的内容就保存在了数据段中，而且初始值是10。尽管数据段映射了一个文件，但它是一个私有内存映射，这意味着更改此处的内存不会影响被映射的文件。
比较图：
