课本：第八章 进程的切换和系统的一般执行过程

• 进行进程调度的时机
  • Linux内核通过schedule函数实现进程调度，schedule函数在运行队列中找到一个进程，把CPU分配给它
  • 调用schedule函数一次就是调度一次，调用schedule函数的时候就是进程调度的时机
  • 当内核即将返回用户空间时，内核会检查need_resched标志是否设置，若设置，则调用schedule函数，此时是从中断处理程序返回用户空间的时间点作为一个固定的调度时机点
  • 内核线程是一个特殊进程，只有内核态没有用户态，内核线程和中断处理程序中任何需要暂时中止当前执行路径的位置都可以直接调用schedule()
  • 内核线程作为一类的特殊的进程可以主动调用schedule函数让出CPU，也可以被动调度
• 上下文
  • 进程切换，又称上下文切换，是指为了控制进程执行，内核必须有能力挂起正在CPU上执行的进程，恢复以前挂起的某个进程的执行
  • 内核线程以进程上下文的形式运行在内核空间中
  • 每个进程可以拥有属于自己的地址空间，但所有进程必须共享CPU及寄存器，所以在恢复一个进程执行之前，内核必须确保每个寄存器装入了挂起进程时的值
  • 进程恢复执行前必须装入寄存器的一组数据，称为硬件上下文
  • 进程上下文包含了进程执行需要的所有信息
    • 用户地址空间：包括程序代码、数据、用户堆栈等
    • 控制信息：进程描述符、内核堆栈等
    • 硬件上下文，相关寄存器的值
  • 进程切换就是更变进程上下文，最核心的是几个关键寄存器的保存与变换
    • CR3寄存器代表进程页目录表，即地址空间、数据
    • ESP寄存器（内核态时）代表进程内核堆栈，struct thread、PCB、内核堆栈存储于连续8KB区域中，通过ESP获取地址
    • EIP寄存器及其他寄存器代表进程硬件上下文，即要执行的下条指令及环境
    • 这些寄存器从一个进程的状态切换到另一个进程的状态，进程切换就算完成了
  • 实际代码中，每个进程切换基本由两个步骤组成
    • 切换页全局目录CR3以安装一个新的地址空间，这样不同进程的虚拟地址如0x8048400就会经过不同的页表转换为不同的物理地址
    • 切换内核态堆栈和硬件上下文，因为硬件上下文提供了内核执行新进程所需要的所有信息，包含CPU寄存器状态
• 进程切换的过程（正在运行的用户态进程X切换到用户态进程Y的过程）
  • 正在运行的用户态进程X
  • 发生中断（包括异常、系统调用等），硬件完成以下动作
    • save cs:eip/ss:esp/eflags:当前CPU上下文压入用户态进程X的内核堆栈
    • load cs:eip(entry of a specific ISR) and ss:esp(point to kernel stack):加载当前进程内核堆栈相关信息，跳转到中断处理程序，即中断执行路径的起点
  • SAVE_ALL，保存现场，此时完成了中断上下文切换，即从进程X的用户态到进程X的内核态
  • 中断处理过程中或中断返回前调用了schedule函数，其中switch_to做了关键的进程上下文切换。将当前用户进程X的内核堆栈切换到选出的next进程（此处为进程Y）的内核堆栈，并完成了进程上下文所需的EIP等寄存器状态切换
  • 标号1（即代码1:\t处）之后开始运行用户态进程Y
  • restore_all，恢复现场，与保存现场对应
  • iret - pop cs:eip/ss:esp/eflags，从Y进程的内核堆栈中弹出硬件完成的压栈内容。至此，完成了中断上下文切换，即从进程Y的内核态返回到进程Y的用户态
  • 继续运行用户态进程Y
• 操作系统内核
  • Linux操作系统内核通过中断上下文切换和进程上下文切换这些基本的运行机制来保障Linux操作系统内核为用户提供最基本和重要的服务。如下：
    • 通过系统调用的形式为进程提供各种服务
    • 通过异常处理程序与中断服务程序为硬件的正常工作提供各种服务
    • 通过内核线程为系统提供动态的维护服务和中断服务中可延时处理的任务
  • 对于x86-32位的系统所有进程地址空间3GB以上的部分（内核态）都是共享的，也就是说所有进程看到的3GB以上部分的地址和内容都是完全一样的，尽管逻辑上每个进程的地址空间是独立的
• Linux操作系统的整体构架如下：
  
  
• ls命令执行过程示意
  
  

实验：理解进程调度时机跟踪分析进程调度与进程切换的过程

使用实验楼，配置menuOS：



打开gdb，设置断点，其中switch_to为宏定义，不能设置断点，需到context_switch函数中单步执行查看调用：



执行程序，停在了schedule函数处，查看代码发现调用了schedule函数，发生了进程调度：



继续执行程序，代码来到了pick_next_task断点处：



继续执行，来到了context_switch处：



在context_switch中单步执行，发现其中调用到了switch_to：





继续单步执行，结束切换：

代码分析

context_switch函数部分

static inline void 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;

    /*

     * For paravirt, this is coupled with an exit in switch_to to

     * combine the page table reload and the switch backend into

     * one hypercall.

     */

    arch_start_context_switch(prev);

    if (!mm) {    //如果被切换进来的进程的mm为空切换，内核线程mm为空

        next->active_mm = oldmm;  //将共享切换出去的进程的active_mm

        atomic_inc(&oldmm->mm_count);  //有一个进程共享，所有引用计数加一

        enter_lazy_tlb(oldmm, next);  //普通mm不为空，则调用switch_mm切换地址空间

    } else

        switch_mm(oldmm, mm, next);

    if (!prev->mm) {

        prev->active_mm = NULL;

        rq->prev_mm = oldmm;

    }

    /*

     * Since the runqueue lock will be released by the next

     * task (which is an invalid locking op but in the case

     * of the scheduler it's an obvious special-case), so we

     * do an early lockdep release here:

     */

    spin_release(&rq->lock.dep_map, 1, _THIS_IP_);

    context_tracking_task_switch(prev, next);

    // Here we just switch the register state and the stack.切换寄存器状态和栈

    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);

}

schedule函数选择一个新的进程来运行，并调用context_switch函数进行上下文的切换

switch_to函数部分

#define switch_to(prev, next, last)

do {

    /*

     * Context-switching clobbers all registers, so we clobber

     * them explicitly, via unused output variables.

     * (EAX and EBP is not listed because EBP is saved/restored

     * explicitly for wchan access and EAX is the return value of

     * __switch_to())

     */

    unsigned long ebx, ecx, edx, esi, edi;

    asm volatile(

                     "pushfl\n\t"        // 保存当前进程flags

             "pushl %%ebp\n\t"      // 当前进程堆栈基址压栈

             "movl %%esp,%[prev_sp]\n\t"    // 保存ESP，将当前堆栈栈顶保存起来

             "movl %[next_sp],%%esp\n\t"    // 更新ESP，将下一栈顶保存到ESP中

                     // 完成内核堆栈的切换

             "movl $1f,%[prev_ip]\n\t"       // 保存当前进程的EIP

             "pushl %[next_ip]\n\t"       // 将next进程起点压入堆栈，即next进程的栈顶为起点，next_ip一般为$1f，对于新创建的子进程是ret_from_fork

             __switch_canary

             "jmp __switch_to\n"    // prve进程中，设置next进程堆栈，jmp与call不同，是通过寄存器传递参数（call通过堆栈），所以ret时弹出的是之前压入栈顶的next进程起点

                     // 完成EIP的切换

             "1:\t"             // next进程开始执行

             "popl %%ebp\n\t"       // restore EBP

             "popfl\n"          // restore flags

             // 输出量

             : [prev_sp] "=m" (prev->thread.sp),   // 保存当前进程的esp

               [prev_ip] "=m" (prev->thread.ip),     // 保存当前进仓的eip

               "=a" (last),

               // 要破坏的寄存器

               "=b" (ebx), "=c" (ecx), "=d" (edx),

               "=S" (esi), "=D" (edi)

               __switch_canary_oparam

              // 输入量

             : [next_sp]  "m" (next->thread.sp),   // next进程的内核堆栈栈顶地址，即esp

               [next_ip]  "m" (next->thread.ip),     // next进程的eip

               // regparm parameters for __switch_to():

               [prev]     "a" (prev),

               [next]     "d" (next)

               __switch_canary_iparam

             : // 重新加载段寄存器

            "memory");

} while (0)

context_switch调用宏switch_to进行硬件上下文切换，主要是内联汇编代码

问题与总结

总统来说实验过程没有遇到什么问题，但是对于原理还需要进一步理解，switch_to处的执行过程还需要断点到context_switch函数后单步执行进入函数内部，才能看到调用switch_to的执行过程。

linux内核调用schedule()函数进行进程调度，并调用context_switch进行上下文的切换，调用switch_to来进行进程关键上下文切换。

在linux中，进程主动调度的时机可以在中断处理过程中、内核线程中，但用户态进程无法实现主动调度，仅能通过陷入内核态的新时机点进行调度，即在中断处理过程中进行调度。