理解进程调度时机跟踪分析进程调度与进程切换的过程
mqy+ 原创作品转载请注明出处 + 《Linux内核分析》MOOC课程http://mooc.study.163.com/course/USTC-1000029000
进程的调度时机与进程的切换
操作系统原理中介绍了大量进程调度算法，这些算法从实现的角度看仅仅是从运行队列中选择一个新进程，选择的过程中运用了不同的策略而已。
对于理解操作系统的工作机制，反而是进程的调度时机与进程的切换机制更为关键。
进程调度的时机
-
中断处理过程（包括时钟中断、I/O中断、系统调用和异常）中，直接调用schedule()，或者返回用户态时根据need_resched标记调用schedule()；
-
内核线程可以直接调用schedule()进行进程切换，也可以在中断处理过程中进行调度，也就是说内核线程作为一类的特殊的进程可以主动调度，也可以被动调度；
-
用户态进程无法实现主动调度，仅能通过陷入内核态后的某个时机点进行调度，即在中断处理过程中进行调度。
进程的切换
-
为了控制进程的执行，内核必须有能力挂起正在CPU上执行的进程，并恢复以前挂起的某个进程的执行，这叫做进程切换、任务切换、上下文切换；
-
挂起正在CPU上执行的进程，与中断时保存现场是不同的，中断前后是在同一个进程上下文中，只是由用户态转向内核态执行；
-
进程上下文包含了进程执行需要的所有信息
-
用户地址空间： 包括程序代码，数据，用户堆栈等
-
控制信息 ：进程描述符，内核堆栈等
-
硬件上下文（注意中断也要保存硬件上下文只是保存的方法不同）
-
schedule()函数选择一个新的进程来运行，并调用context_switch进行上下文的切换，这个宏调用switch_to来进行关键上下文切换
-
next = pick_next_task(rq, prev);//进程调度算法都封装这个函数内部
-
context_switch(rq, prev, next);//进程上下文切换
-
switch_to利用了prev和next两个参数：prev指向当前进程，next指向被调度的进程
Linux系统的一般执行过程
最一般的情况：正在运行的用户态进程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
几种特殊情况
- 通过中断处理过程中的调度时机，用户态进程与内核线程之间互相切换和内核线程之间互相切换，与最一般的情况非常类似，只是内核线程运行过程中发生中断没有进程用户态和内核态的转换；
- 内核线程主动调用schedule()，只有进程上下文的切换，没有发生中断上下文的切换，与最一般的情况略简略；
- 创建子进程的系统调用在子进程中的执行起点及返回用户态，如fork；
- 加载一个新的可执行程序后返回到用户态的情况，如execve；
Linux操作系统架构和系统执行过程
操作系统的基本概念
操作系统：任何计算机系统包含的一个基本的程序集合
- 内核（进程管理、进程调度、进程间通讯机制、内存管理、中断异常处理、文件系统、I/O系统、网络部分）
- 其他程序（函数库、shell程序、系统程序等等）
操作系统的目的
- 与硬件交互，管理所有的硬件资源
- 为用户程序（应用程序）提供一个良好的执行环境
理解Linux系统中进程调度的时机，可以在内核代码中搜索schedule()函数，看都是哪里调用了schedule()，判断我们课程内容中的总结是否准确；
使用gdb跟踪分析一个schedule()函数 ，验证您对Linux系统进程调度与进程切换过程的理解；推荐在实验楼Linux虚拟机环境下完成实验。
特别关注并仔细分析switch_to中的汇编代码，理解进程上下文的切换机制，以及与中断上下文切换的关系；
实验：
1. 实验目的
- 选择一个系统调用（13号系统调用time除外），系统调用列表，使用库函数API和C代码中嵌入汇编代码两种方式使用同一个系统调用
- 分析汇编代码调用系统调用的工作过程，特别是参数的传递的方式等。
- 阐明自己对“系统调用的工作机制”的理解。
实验过程
2.1 fork函数
本次实验选择fork系统调用，其系统调用号为：
2 i386 fork sys_fork stub32_fork
一个进程，包括代码、数据和分配给进程的资源。fork（）函数通过系统调用创建一个与原来进程几乎完全相同的进程，也就是两个进程可以做完全相同的事，但如果初始参数或者传入的变量不同，两个进程也可以做不同的事。一个进程调用fork（）函数后，系统先给新的进程分配资源，例如存储数据和代码的空间。然后把原来的进程的所有值都复制到新的新进程中，只有少数值与原来的进程的值不同。相当于克隆了一个自己。
fork调用的一个奇妙之处就是它仅仅被调用一次，却能够返回两次，它可能有三种不同的返回值：
- 在父进程中，fork返回新创建子进程的进程ID；
- 在子进程中，fork返回0；
- 如果出现错误，fork返回一个负值；
在fork函数执行完毕后，如果创建新进程成功，则出现两个进程，一个是子进程，一个是父进程。在子进程中，fork函数返回0，在父进程中，fork返回新创建子进程的进程ID。我们可以通过fork返回的值来判断当前进程是子进程还是父进程。 引用一位网友的话来解释fpid的值为什么在父子进程中不同。“其实就相当于链表，进程形成了链表，父进程的fpid(p 意味point)指向子进程的进程id, 因为子进程没有子进程，所以其fpid为0。
fork.c的代码如下：
#include <unistd.h>
#include <stdio.h>
int main ()
{
pid_t fpid;
int count = 0;
fpid = fork();
if (fpid < 0)
printf("error in fork!");
else if (fpid == 0) {
printf("i am the child process, my process id is %d\n",getpid());
count++;
}
else {
printf("i am the parent process, my process id is %d\n",getpid());
count++;
}
printf("count: %d\n",count);
return 0;
}
执行结果
分别用API和嵌入式汇编代码调用fork，结果如图：
创建新进程成功后，系统中出现两个基本完全相同的进程，这两个进程执行没有固定的先后顺序，哪个进程先执行要看系统的进程调度策略。 每个进程都有一个独特（互不相同）的进程标识符（process ID），可以通过getpid（）函数获得，还有一个记录父进程pid的变量，可以通过getppid（）函数获得变量的值。 fork执行完毕后，出现两个进程，进程1的变量为count=0，fpid！=0（父进程）。进程2的变量为count=0，fpid=0（子进程），这两个进程的变量都是独立的，存在不同的地址中，不是共用的，这点要注意。可以说，我们就是通过fpid来识别和操作父子进程的。 还有人可能疑惑为什么不是从#include处开始复制代码的，这是因为fork是把进程当前的情况拷贝一份，执行fork时，进程已经执行完了int count=0;fork只拷贝下一个要执行的代码到新的进程。
3. 实验分析
下面重点分析嵌入式汇编代码的执行，fork-asm.c源代码如下：
#include <unistd.h>
#include <stdio.h>
int main ()
{
pid_t fpid;
int count = 0;
asm volatile (
"mov $0, %%ebx\n\t"
"mov $0x2, %%eax\n\t"
"int $0x80\n\t"
"mov %%eax, %0\n\t"
: "=m" (fpid)
);
if (fpid < 0)
printf("error in fork!");
else if (fpid == 0) {
printf("i am the child process, my process id is %d\n",getpid());
count++;
}
else {
printf("i am the parent process, my process id is %d\n",getpid());
count++;
}
printf("count: %d\n",count);
return 0;
}
以上程序与fork.c的主要区别就是用asm汇编代替了fpid = fork();语句。其主要过程是：
asm volatile (
"mov $0, %%ebx\n\t" // 由于fork函数调用不需要参数，可直接将立即数0赋值给ebx，代表NULL。没有这条语句应该也可以。
"mov $0x2, %%eax\n\t" // 系统调用号默认通过eax传递，因此将fork的系统调用号0x2赋值给eax
"int $0x80\n\t" // 通过0x80中断向量，执行系统调用。系统由eax此时的值可知，用户请求fork调用。
"mov %%eax, %0\n\t" // 系统返回的pid号默认储存在eax中，将eax的值赋给第一个输出操作数，即下面的fpid。
: "=m" (fpid) // =代表操作数在指令中是只写的，m代表内存变量。即输出操作数0为内存中的fpid。
);
除了系统调用号以外，大部分系统调用都还需要一些外部的参数输人。所以，在发生异常的时候，应该把这些参数从用户空间传给内核。最简单的办法就是像传递系统调用号一样把这些参数也存放在寄存器里。在x86系统上，ebx, ecx, edx, esi和edi按照顺序存放前五个参数。需要六个或六个以上参数的情况不多见，此时，应该用一个单独的寄存器存放指向所有这些参数在用户空间地址的指针。 给用户空间的返回值也通过寄存器传递。在x86系统上，它存放在eax寄存器中。接下来许多关于系统调用处理程序的描述都是针对x86版本的。但不用担心，所有体系结构的实现都很类似。
