Linux内核13-进程切换

简介: Linux内核13-进程切换

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控制单元到底做了什么呢?
  1. 检查eflags寄存器中IOPL位(2位)。如果等于3,也就是超级用户权限,也就是进程对于这个I/O端口来说就是一个超级用户,那么,直接执行I/O指令。否则,继续执行检查。
  2. 访问tr寄存器,确定当前的TSS,以及正确的I/O访问权限。
  3. 它检查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 执行进程切换


  1. 进程切换的时机:
  • 中断处理程序中直接调用schedule()函数,实现进程调度。
  • 内核线程,是一个特殊的进程,只有内核态没有用户态。所以即可以主动调用schedule()函数进行调度,也可以被中断处理程序调用。
  • 内核态进程没法直接主动调度,因为schedule()是一个内核函数,不是系统调用。所以只能在中断处理程序进行调度。
  1. 关键代码梳理
  • 首先,schedule()函数会调用next = pick_next_task(rq, prev);,所做的工作就是根据调度算法策略,选取要执行的下一个进程。
  • 其次,根据调度策略得到要执行的进程后,调用context_switch(rq, prev, next);,完成进程上下文切换。其中,最关键的switch_to(prev,next, prev);切换堆栈和寄存器的状态。

我们假设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("pushfl\n\t"               /* save    flags */ \
             "pushl %%ebp\n\t"              /* save    EBP   */ \
             "movl %%esp,%[prev_sp]\n\t"    /* save    ESP   */ \
             "movl %[next_sp],%%esp\n\t"    /* restore ESP   */ \
             "movl $1f,%[prev_ip]\n\t"      /* save    EIP   */ \
             "pushl %[next_ip]\n\t"         /* restore EIP   */ \
             __switch_canary                                    \
             __retpoline_fill_return_buffer                     \
             "jmp __switch_to\n"            /* regparm call  */ \
             "1:\t"                                             \
             "popl %%ebp\n\t"               /* restore EBP   */ \
             "popfl\n"                      /* 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个参数,prevnextlast
  • prevnext这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中的值覆盖。

640.png


switch_to宏的处理过程如下:

  1. 将新旧进程描述符存放到CPU寄存器中:
movl prev, %eax
 movl next, %edx
  1. 保存旧进程的内核态栈,比如eflagsebp寄存器的内容。
pushfl
 pushl %ebp
  1. 保存旧进程栈指针espprev->thread.esp
movl %esp,484(%eax)
  1. 操作数484(%eax)表明目的地址是寄存器eax中的地址加上484
  2. 将新进程的栈指针加载到esp寄存器中。
    新进程的栈指针位于next->thread.esp中。从现在起,内核在新进程的内核态栈上操作,所以,这条指令才是执行旧进程切换到新进程的开始。因为内核态栈的地址和进程描述符的地址紧密相关,那么改变内核栈意味着改变了当前的进程。
movl 484(%edx), %esp
  1. 保存标签1的地址->prev->thread.eip
    标签1标记进程当前执行的指令。这条指令意味着,再恢复进程A执行的时候,就从标签1处的地址中的指令开始执行。
movl $1f, 480(%eax)
  1. 加载新进程的指令流。
pushl 480(%edx)
  1. 意义和第5步差不多,就是执行顺序相反。
  2. 跳转到__switch_to()函数执行,是一个C函数。
jmp __switch_to
  1. 至此,进程A被进程B取代:开始执行B进程的指令。第一步应该是先弹出eflags和ebp寄存器的值。
1:
     popl %ebp
     popfl
  1. 拷贝eax寄存器的内容(第1步加载的)到last变量中。
movl %eax, last
  1. 也就是说,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));

这个函数执行的内容:

  1. 执行__unlazy_fpu()宏,保存旧进程的FPU、MMX和XMM寄存器
    __unlazy_fpu(prev_p);
  2. 执行smp_processor_id()宏,获取正在执行代码的CPU的ID。从thread_info结构的cpu成员中获取。
  3. 加载新进程的next_p->thread.esp0到当前CPU的TSS段中的esp0成员中。通过调用sysenter汇编指令从用户态切换到内核态引起的任何特权级别的改变都会导致将这个地址拷贝到esp寄存器中。
init_tss[cpu].esp0 = next_p->thread.esp0;
  1. 将新进程的线程本地存储(TLS)段加载到当前CPU的GDT中。3个段选择器存储在进程描述符的tls_array数组中。
cpu_gdt_table[cpu][6] = next_p->thread.tls_array[0];
 cpu_gdt_table[cpu][7] = next_p->thread.tls_array[1];
 cpu_gdt_table[cpu][8] = next_p->thread.tls_array[2];
  1. 存储fs和gs段寄存器的内容到旧进程的prev_p->thread.fs和prev_p->thread.gs中。汇编指令如下:
movl %fs, 40(%esi)
 movl %gs, 44(%esi)
  1. 寄存器esi指向prev_p->thread结构。gs寄存器用来存放TLS段的地址。fs寄存器实际上windows使用。
  2. 加载新进程的fs或gs寄存器内容。数据来源是新进程的thread_struct描述符中对应的值。汇编语言如下:
movl 40(%ebx),%fs
 movl 44(%ebx),%gs
  1. ebx寄存器指向next_p->thread结构。
  2. 载入新进程的调式寄存器中的信息。
if (next_p->thread.debugreg[7]){
     loaddebug(&next_p->thread, 0);
     loaddebug(&next_p->thread, 1);
     loaddebug(&next_p->thread, 2);
     loaddebug(&next_p->thread, 3);
     /* no 4 and 5 */
     loaddebug(&next_p->thread, 6);
     loaddebug(&next_p->thread, 7);
 }
  1. 更新TSS中的I/O权限位(如果有必要的话)。也就是如果新旧进程对I/O访问有自己特殊的要求的话就需要更改。
if (prev_p->thread.io_bitmap_ptr || next_p->thread.io_bitmap_ptr)
     handle_io_bitmap(&next_p->thread, &init_tss[cpu]);
  1. __switch_to()函数结束。
return prev_p;
  1. 相应的汇编语言就是:
movl %edi,%eax
 ret
  1. 因为switch_to总是假设eax寄存器保存旧进程的进程描述符的地址。所以,这里把prev_p变量再次写入到eax寄存器中。
    ret指令把栈上要返回的地址写入到eip寄存器中。其实,栈上的返回地址就是标签为1处的指令地址,这是由switch_to压栈的。如果新进程从来没挂起过,因为是第一次执行,然后就会跳转到ret_from_fork()函数返回的起始地址处(这部分等讲进程的创建时再细说)。至此,完成了进程的切换。
相关文章
|
18天前
|
算法 Linux 调度
深入理解Linux操作系统的进程管理
本文旨在探讨Linux操作系统中的进程管理机制,包括进程的创建、执行、调度和终止等环节。通过对Linux内核中相关模块的分析,揭示其高效的进程管理策略,为开发者提供优化程序性能和资源利用率的参考。
43 1
|
6天前
|
存储 监控 Linux
嵌入式Linux系统编程 — 5.3 times、clock函数获取进程时间
在嵌入式Linux系统编程中,`times`和 `clock`函数是获取进程时间的两个重要工具。`times`函数提供了更详细的进程和子进程时间信息,而 `clock`函数则提供了更简单的处理器时间获取方法。根据具体需求选择合适的函数,可以更有效地进行性能分析和资源管理。通过本文的介绍,希望能帮助您更好地理解和使用这两个函数,提高嵌入式系统编程的效率和效果。
56 13
|
13天前
|
SQL 运维 监控
南大通用GBase 8a MPP Cluster Linux端SQL进程监控工具
南大通用GBase 8a MPP Cluster Linux端SQL进程监控工具
|
18天前
|
算法 Linux
深入探索Linux内核的内存管理机制
本文旨在为读者提供对Linux操作系统内核中内存管理机制的深入理解。通过探讨Linux内核如何高效地分配、回收和优化内存资源,我们揭示了这一复杂系统背后的原理及其对系统性能的影响。不同于常规的摘要,本文将直接进入主题,不包含背景信息或研究目的等标准部分,而是专注于技术细节和实际操作。
|
18天前
|
存储 缓存 网络协议
Linux操作系统的内核优化与性能调优####
本文深入探讨了Linux操作系统内核的优化策略与性能调优方法,旨在为系统管理员和高级用户提供一套实用的指南。通过分析内核参数调整、文件系统选择、内存管理及网络配置等关键方面,本文揭示了如何有效提升Linux系统的稳定性和运行效率。不同于常规摘要仅概述内容的做法,本摘要直接指出文章的核心价值——提供具体可行的优化措施,助力读者实现系统性能的飞跃。 ####
|
19天前
|
监控 算法 Linux
Linux内核锁机制深度剖析与实践优化####
本文作为一篇技术性文章,深入探讨了Linux操作系统内核中锁机制的工作原理、类型及其在并发控制中的应用,旨在为开发者提供关于如何有效利用这些工具来提升系统性能和稳定性的见解。不同于常规摘要的概述性质,本文将直接通过具体案例分析,展示在不同场景下选择合适的锁策略对于解决竞争条件、死锁问题的重要性,以及如何根据实际需求调整锁的粒度以达到最佳效果,为读者呈现一份实用性强的实践指南。 ####
|
19天前
|
缓存 监控 网络协议
Linux操作系统的内核优化与实践####
本文旨在探讨Linux操作系统内核的优化策略与实际应用案例,深入分析内核参数调优、编译选项配置及实时性能监控的方法。通过具体实例讲解如何根据不同应用场景调整内核设置,以提升系统性能和稳定性,为系统管理员和技术爱好者提供实用的优化指南。 ####
|
21天前
|
负载均衡 算法 Linux
深入探索Linux内核调度机制:公平与效率的平衡####
本文旨在剖析Linux操作系统内核中的进程调度机制,特别是其如何通过CFS(完全公平调度器)算法实现多任务环境下资源分配的公平性与系统响应速度之间的微妙平衡。不同于传统摘要的概览性质,本文摘要将直接聚焦于CFS的核心原理、设计目标及面临的挑战,为读者揭开Linux高效调度的秘密。 ####
32 3
|
24天前
|
负载均衡 算法 Linux
深入探索Linux内核调度器:公平与效率的平衡####
本文通过剖析Linux内核调度器的工作机制,揭示了其在多任务处理环境中如何实现时间片轮转、优先级调整及完全公平调度算法(CFS),以达到既公平又高效地分配CPU资源的目标。通过对比FIFO和RR等传统调度策略,本文展示了Linux调度器如何在复杂的计算场景下优化性能,为系统设计师和开发者提供了宝贵的设计思路。 ####
35 6
|
21天前
|
运维 监控 Linux
Linux操作系统的守护进程与服务管理深度剖析####
本文作为一篇技术性文章,旨在深入探讨Linux操作系统中守护进程与服务管理的机制、工具及实践策略。不同于传统的摘要概述,本文将以“守护进程的生命周期”为核心线索,串联起Linux服务管理的各个方面,从守护进程的定义与特性出发,逐步深入到Systemd的工作原理、服务单元文件编写、服务状态管理以及故障排查技巧,为读者呈现一幅Linux服务管理的全景图。 ####