Linux Process Management && Process Scheduling Principle
目录
1. 引言 2. 进程优先级 3. 进程的生命周 4. 进程表示 5. 进程管理相关的系统调用 6. 进程调度 7. 完全公平调度类 8. 实时调度类 9. 调度器增强 10. 小结
1. 引言
在多处理器系统中，可以真正并行运行的进程数目，取决于物理CPU的数目
内核和处理器建立了多任务的"错觉"，即可以并行做几种操作，这是通过以很短的间隔在系统运行的应用程序之间不停切换而做到的，这种系统管理方式引发了几个内核必须解决的问题
1. 除非明确地要求，否则应用程序不能彼此干扰，例如 1) 应用程序A的错误不能传播到应用程序B 2) 确保程序不能随意读取、修改其他程序的内存 2. CPU时间必须在各种应用程序之间尽可能公平地共享，其中一些程序可能比其他程序更重要 3. 内核必须决定为各个进程分配多长时间，何时切换到下一个进程，这本质上是"哪个进程是下一个进程"的问题。这个决策是平台无关的 4. 在内核从进程A切换到进程B时，必须确保进程B的执行环境与上一次撤销其处理器资源时完全相同(例如寄存器、虚拟地址空间的结构必须与此前相同)
这些任务是被称之为"调度器"的内核子系统的工作，CPU时间如何分配取决于"调度器策略"，这与用于在各个进程之间切换的"任务切换机制"完全无关
2. 进程优先级
进程的"优先级"是一个大的概念，它包含了不同的关键度类别，以满足不同需求
1. 实时进程 1) 硬实时进程 硬实时进程有严格的时间限制，某些任务必须在指定的时限内完成。需要注意的是，这并不意味着所要求的时间范围特别短，而是系统必须保证"决不会超过某一特定的时间范围"，即使在不大可能或条件不利的情况下也是如此 2) 软实时进程 软实时进程是硬实时进程的一种弱化形式，一个典型的例子是对CD的写入操作，CD写入进程接收的数据必须保持某一速率，因为数据是以连续流的形式写入介质的，如果系统负荷过高，数据流可能会暂时中断，这可能导致CD不可用，虽然对实时性也有一定的要求，但并不像飞机导航系统那样严重，而且大多数情况下写入进程在需要CPU时间的时候应该能够得到保证，因为实时进程至少优先于所有其他普通进程 2. 非实时进程 大多数进程是没有特定时间约束的普通进程，但仍然可以根据重要性来分配优先级 这种方案称之为"抢占式多任务处理(preemptive multitasking)"，各个进程都分配到一定的时间段可以执行。时间段到期后，内核会从进程回收控制权，让"下一个进程(由调度器决定)"。被抢占进程的运行环境，即所有CPU寄存器、页表都会保存起来，因此上一个进程的执行结果不会丢失。在之前被抢占的进程恢复执行时，其进程环境可以完全恢复。 时间片的长度会根据进程优先级而变化
3. 进程的生命周期
进程并不总是可以立即运行，有时候它必须等待来自外部信号源、不受其控制的异步中断事件(例如文本编辑器中等待键盘键入)，在事件发生之前，进程无法运行
当调度器在进程之间切换时，必须知道系统中每个进程的状态，将CPU分配到无事可做的进程显然是没有意义的。进程在各个状态之间的转换也同样重要，例如如果一个进程在等待来自外设的数据，那么调度器的任务就是一旦数据已经到达，则需要将进程的状态由等待改为可运行
Linux是一个多用户，多任务的系统，可以同时运行多个用户的多个程序，就必然会产生很多的进程，而每个进程会有不同的状态
0x1: 进程的初始状态
进程是通过fork系列的系统调用(fork、clone、vfork)来创建的，内核(或内核模块)也可以通过kernel_thread函数创建内核进程。这些创建子进程的函数本质上都完成了相同的功能——将调用进程复制一份，得到子进程(可以通过选项参数来决定各种资源是共享、还是私有)
那么既然调用进程处于TASK_RUNNING状态(只有正在运行的进程才会进行系统调用，创建新进程)，则子进程默认也处于TASK_RUNNING状态
另外，在系统调用调用clone和内核函数kernel_thread也接受CLONE_STOPPED选项，从而将子进程的初始状态置为TASK_STOPPED
0x2: 进程状态转换
进程自创建以后，状态可能发生一系列的变化，直到进程退出。而尽管进程状态有好几种，但是进程状态的变迁却只有两个方向(即状态图的迁移必须要经过中间TASK_RUNNING的转换)
1. 从TASK_RUNNING状态变为非TASK_RUNNING状态 2. 从非TASK_RUNNING状态变为TASK_RUNNING状态 /* 例如，如果给一个TASK_INTERRUPTIBLE状态的进程发送SIGKILL信号，这个进程将先被唤醒(进入TASK_RUNNING状态)，然后再响应SIGKILL信号而退出(变为TASK_DEAD状态)。并不会从TASK_INTERRUPTIBLE状态直接退出 Linux进程迁移的这个原则要特别注意 */
进程可能有以下几种状态
1. TASK_RUNNING(ready): 可执行状态(READY状态) 同一时刻可能有多个进程处于可执行状态，这些进程的task_struct结构(进程控制块)被放入对应CPU的可执行队列中(一个进程最多只能出现在一个CPU的可执行队列中)。进程调度器的任务就是从各个CPU的可执行队列中分别选择一个进程在该CPU上运行 只要可执行队列不为空，其对应的CPU就不能偷懒，就要执行其中某个进程。一般称此时的CPU"忙碌(busy)"。对应的，CPU"空闲"就是指其对应的可执行队列为空，以致于CPU无事可做 /* 这里也可以引出一个话题，死循环程序会导致CPU占用高呢？因为死循环程序基本上总是处于TASK_RUNNING状态(进程处于可执行队列中)。除非一些非常极端情况(比如系统内存严重紧缺，导致进程的某些需要使用的页面被换出，并且在页面需要换入时又无法分配到内存)，否则这个进程不会睡眠。所以CPU的可执行队列总是不为空(至少有这个进程存在)，CPU也就不会"空闲" */ 2. TASK_RUNNING(run): 可执行状态(RUNNING状态) 要特别注意和TASK_RUNNING(ready)状态的区分，处于TASK_RUNNING(ready)状态的进程并不一定正在运行，只有在该状态的进程才在CPU上运行，能同时运行的进程数量取决于逻辑CPU的数量 3. TASK_UNINTERRUPTIBLE: 不可中断的深度睡眠 与TASK_INTERRUPTIBLE状态类似，进程处于睡眠状态，但是此刻进程是不可中断的。不可中断，指的并不是CPU不响应"外部硬件的中断"，而是指进程不响应"异步信号" 而TASK_UNINTERRUPTIBLE状态存在的意义就在于，内核的某些处理流程是不能被打断的。如果响应异步信号，程序的执行流程中就会被插入一段用于处理异步信号的流程(这个插入的流程可能只存在于内核态，也可能延伸到用户态)，于是原有的流程就被中断了 /* 在进程对某些硬件进行操作时(比如进程调用read系统调用对某个设备文件进行读操作，而read系统调用最终执行到对应设备驱动的代码，并与对应的物理设备进行交互)，可能需要使用TASK_UNINTERRUPTIBLE状态对进程进行保护，以避免进程与设备交互的过程被打断，造成设备陷入不可控的状态 比如read系统调用触发了一次磁盘到用户空间的内存的DMA，如果DMA进行过程中，进程由于响应信号而退出了，那么DMA正在访问的内存可能就要被释放了，所以需要使用TASK_UNINTERRUPTIBLE状态对其进行保护，要注意的是，TASK_UNINTERRUPTIBLE的进程是非常短暂的，因为要尽可能的让CPU的不可响应时间缩短到最短 */ //linux系统中也存在容易捕捉的TASK_UNINTERRUPTIBLE状态。执行vfork系统调用后，父进程将进入TASK_UNINTERRUPTIBLE状态，直到子进程调用exit或exec 4. TASK_INTERRUPTIBLE: 可中断的睡眠状态 处于这个状态的进程因为等待某某事件的发生(比如等待socket连接、等待信号量)，而被挂起。这些进程的task_struct结构被放入对应事件的等待队列中。当这些事件发生时(由外部中断触发、或由其他进程触发)，对应的等待队列中的一个或多个进程将被唤醒 /* 通过ps命令我们会看到，一般情况下，进程列表中的绝大多数进程都处于TASK_INTERRUPTIBLE状态(除非机器的负载能力很高)，因为CPU资源总是小于需要执行的进程 绝大多数情况下，进程处在睡眠状态时，总是应该能够响应异步信号的。否则将会发生，kill -9竟然杀不死一个正在睡眠的进程了，于是我们也很好理解，为什么ps命令看到的进程几乎不会出现TASK_UNINTERRUPTIBLE状态，而总是TASK_INTERRUPTIBLE状态 */ 5. TASK_STOP(TASK_STOPPED or TASK_TRACED) 向进程发送一个SIGSTOP信号，它就会因响应该信号而进入TASK_STOPPED状态(除非该进程本身处于TASK_UNINTERRUPTIBLE状态而不响应信号)。(SIGSTOP与SIGKILL信号一样，是非常强制的。不允许用户进程通过signal系列的系统调用重新设置对应的"信号处理函数")(即不可通过编程方式实现屏蔽) 向进程发送一个SIGCONT信号，可以让其从TASK_STOPPED状态恢复到TASK_RUNNING状态 当进程正在被跟踪时，它处于TASK_TRACED这个特殊的状态。"正在被跟踪"指的是进程暂停下来，等待跟踪它的进程对它进行操作。比如在GDB中对被跟踪的进程下一个断点，进程在断点处停下来的时候就处于TASK_TRACED状态。而在其他时候，被跟踪的进程还是处于前面提到的那些状态 /* 对于进程本身来说，TASK_STOPPED和TASK_TRACED状态很类似，都是表示进程暂停下来。 而TASK_TRACED状态相当于在TASK_STOPPED之上多了一层保护，处于TASK_TRACED状态的进程不能响应SIGCONT信号而被唤醒。只能等到调试进程通过ptrace系统调用执行PTRACE_CONT、PTRACE_DETACH等操作(通过ptrace系统调用的参数指定操作)，或调试进程退出，被调试的进程才能恢复TASK_RUNNING状态 */ 6. TASK_DEAD(TASK_DEAD - EXIT_ZOMBIE) 进程在退出的过程中，处于TASK_DEAD状态。在这个退出过程中，进程占有的所有资源将被回收(除了task_struct结构，以及少数资源)。于是进程就只剩下task_struct这么个空壳，故称为僵尸 之所以保留task_struct，是因为task_struct里面保存了进程的退出码、以及一些统计信息。而其父进程很可能会关心这些信息。比如在shell中，$?变量就保存了最后一个退出的前台进程的退出码，而这个退出码往往被作为if语句的判断条件 /* 父进程可以通过wait系列的系统调用(如wait4、waitid)来等待某个或某些子进程的退出，并获取它的退出信息。然后wait系列的系统调用会顺便将子进程的尸体(task_struct)也释放掉 子进程在退出的过程中，内核会给其父进程发送一个信号，通知父进程来"收尸"(这个信号默认是"SIGCHLD")，但是在通过clone系统调用创建子进程时，可以设置这个信号 Unix/Linux 处理僵尸进程的方法： 找出父进程号，然后kill 父进程，之后子进程(僵尸进程)会被托管到其他进程，如init进程，然后由init进程将子进程的尸体(task_struct)释放掉 */
进程的状态转换关系图如下
1. 给一个TASK_INTERRUPTIBLE状态的进程发送SIGKILL信号，这个进程将先被唤醒(进入TASK_RUNNING状态)，然后再响应SIGKILL信号而退出(变为TASK_DEAD状态) 2. 而进程从TASK_RUNNING状态变为非TASK_RUNNING状态，则有两种途径： 1) 响应信号而进入TASK_STOPED状态、或TASK_DEAD状态(SIGNAL信号) 2) 执行系统调用主动进入TASK_INTERRUPTIBLE状态(如nanosleep系统调用)、或TASK_DEAD状态(如exit系统调用) 3) 由于执行系统调用需要的资源得不到满足，而进入TASK_INTERRUPTIBLE状态或TASK_UNINTERRUPTIBLE状态(如select系统调用) //显然，这几情况都只能发生在进程正在CPU上执行的情况下
系统将所有进程保存在一个"进程列表"中，无论其状态是运行、睡眠、或等待。但睡眠进程会特别标记出来，调度器会知道它们无法立即运行，同时睡眠进程会被分类到若干队列中，因此它们可在适当的时间唤醒(例如在进程等待的外部事件已经发生时)
0x3: 抢占式多任务处理
Linux进程管理的结构中还需要另外两个进程状态选项，这反映了所有现代CPU都至少有两种不同执行状态的事实
1. 用户态 1) 受到各种限制 2) 禁止访问某些内存区域 3) 进程通常都处于用户态，只能访问自身的数据，无法干扰系统中的其他应用程序，甚至也不会注意到自身之外其他进程的存在 2. 核心态 1) 具有无限的权利
这些区别是建立封闭"隔离罩"的一个重要前提，它维持着系统中现存的各个进程，防止它们与系统其他部分互相干扰
如果进程想要访问系统数据或功能，则必须切换到和心态，这只能在受控情况下完成，而且这种访问必须经由明确定义的路径(即系统调用)实现
从用户态切换到和心态的第二种方法是通过中断，此时切换是自动异步触发的，中断的发生是不可预测的。处理中断的操作，通常与中断发生时执行的进程无关(例如外部块设备向内存传输数据完毕后引发一个中断，但相关数据用于系统中运行的任何进程都是可能的)，类似的，进入系统的网络数据报也是通过中断通知的，显然该网络数据包也未必是用于当前运行的进程。因此，在Linux执行中断操作时，当前运行的进程是不会察觉的
内核的抢占调度模型建立了一个层次结构，用于判断哪些进程状态可以由其他状态抢占
1. 普通进程总是可能被抢占，在一个重要进程变为可运行时，例如编辑器接收到了等待已久的键盘输入(立即进入read状态)，调度器可以决定是否立即执行该进程，即使当前进程仍然正常运行，对于实现良好的交互行为和低系统延迟，这种抢占起到了重要作用 2. 如果系统处于和心态并正在处理系统调用，那么系统中的其他进程是无法夺取其CPU时间的。调度器必须等到系统调用结束，才能选择另一个进程执行，但中断可以中止系统调用 3. 中断可以暂停处于用户态和和心态的进程，中断具有最高优先级，因为在中断触发后需要尽快处理
在内核2.5开发期间，内核抢占(kernel preemption)的选项添加到内核，该选项支持在紧急情况下切换到另一个进程，甚至当前是处于和心态执行系统调用(中断期间是不行的)，从而保证"更平滑的"程序执行
Relevant Link:
http://zhengdl126.iteye.com/blog/1745108 http://blog.csdn.net/tianlesoftware/article/details/6457487 http://www.embeddedlinux.org.cn/html/xianchengjincheng/201304/14-2540.html
4. 进程表示
Linux内核涉及进程和程序的所有算法都围绕task_struct的数据结构建立，这是系统中主要的一个结构，关于task_struct结构体的相关知识，请参阅另一篇文章
http://www.cnblogs.com/LittleHann/p/3865490.html //搜索：struct task_struct
从总体上来说，该结构的内容可以分解为各个部分，每个部分表示进程的一个特定方面
1. 状态和执行信息: 1) 待决信号 2) 使用的二进制格式(和其他系统二进制格式的任何仿真信息) 3) PID 4) 到父进程及其他有关进程的指针 5) 优先级和程序执行有关的时间信息(例如CPU时间) 2. 有关已经分配的虚拟内存的信息 3. 进程身份凭据 1) UID 2) GID 3) cred权限 4. 进程操作的文件 5. 线程信息记录该进程特定于CPU的运行时间数据 6. 进程间通信IPC有关的信息 7. 该进程所用的信号处理程序，用于响应到来的信号
对于Linux内核来说，通常情况下不会采取直接访问数据结构成员的方式读写数据，而是提供的相关的辅助函数(或系统调用)查询(或修改)这些数据
0x1: 命名空间
命名空间提供了虚拟化的一种轻量级形式，使得我们可以从不同的方面来查看运行系统的全局属性，该机制类似于Solaris中的zone、FreeBSD中的jail
关于命名空间的相关知识，请参阅另一篇文章
http://www.cnblogs.com/LittleHann/p/4026781.html //搜索：2. Linux命名空间
0x2: 进程关系
除了源于ID连接的关系之外，内核还负责管理建立在UNIX进程创建模型之上的"家族关系"
1. 如果进程A分支形成进程B，进程A称之为父进程，而进程B则是子进程。如果进程B再次分支建立另一个进程C，进程A和进程C之间则称之为祖孙关系 2. 如果进程A分支若干次形成几个子进程B1、B2、B3...，各个Bn进程之间的关系称之为兄弟关系
task_strut数据结构提供了两个链表表头，用于实现这些关系
struct task_struct { ... struct list_head children; //子进程链表 struct list_head sibling; //连接到父进程的子进程链表(兄弟链表) ... }
5. 进程管理相关的系统调用
0x1: 进程复制
关于Linux进程(线程)复制的相关知识，请参阅另一篇文章
http://www.cnblogs.com/LittleHann/p/3853854.html
0x2: 内核线程
内核线程是直接由内核本身启动的进程，内核线程实际上是将内核函数"委托"给独立的进程，与系统中其他进程"并行"执行(实际上，也并行与内核自身的执行)。内核线程通常称之为"内核守护进程"，它们用于执行下列任务
1. 周期性地将修改的内存页与页来源块设备同步，即数据写回(例如使用mmap的文件映射) 2. 如果内存页很少使用，则写入交换区 3. 管理延时动作(deferred action) 4. 实现文件系统的事务日志
基本上，有两种类型的内核线程，它们对应于以下不同的API
1. int kernel_thread(int (*fn)(void *), void *arg, unsigned long flags) /* 1. fn 产生的线程将执行用fn指针传递的函数 2. arg 而用arg指定的参数将自动传递给该函数 3. flag flag中可以指定CLONE标志 */ linux-2.6.32.63\arch\x86\kernel\process_32.c 调用kernel_thread()函数可以启动一个内核线程，其定义是特定于体系结构的，但函数原型都是相同的(API兼容) 线程启动后一直等待，该函数接下来负责帮助内核掉哟个deamonize以转换为守护进程，直至内核请求线程执行某一特定操作，这依次引发下列操作 1) 该函数从内核线程释放其父进程(用户进程)的所有资源(例如内存上下文、文件描述符..)，否则这些资源会一直锁定到线程结束，这是不可取的，因为守护进程通常运行到系统关机为止，因为守护进程只操作内核地址区域，它基本不需要这些用户态的资源 2) deamonize阻塞信号的接收 3) 将init用作守护进程的父进程 /* * Create a kernel thread */ int kernel_thread(int (*fn)(void *), void *arg, unsigned long flags) { struct pt_regs regs; memset(®s, 0, sizeof(regs)); //kernel_thread的第一个任务就是构建一个pt_regs实例，对其中的寄存器指定适当的值 regs.bx = (unsigned long) fn; regs.dx = (unsigned long) arg; regs.ds = __USER_DS; regs.es = __USER_DS; regs.fs = __KERNEL_PERCPU; regs.gs = __KERNEL_STACK_CANARY; regs.orig_ax = -1; regs.ip = (unsigned long) kernel_thread_helper; regs.cs = __KERNEL_CS | get_kernel_rpl(); regs.flags = X86_EFLAGS_IF | X86_EFLAGS_SF | X86_EFLAGS_PF | 0x2; /* Ok, create the new process.. */ return do_fork(flags | CLONE_VM | CLONE_UNTRACED, 0, ®s, 0, NULL, NULL); } EXPORT_SYMBOL(kernel_thread); 2. struct task_struct *kthread_create(int (*threadfn)(void *data), void *data, const char namefmt[], ...) /* 1. namefmt 该函数创建一个新的内核线程，名字由namefmt给出 2. threadfn 最初该线程是停止的，需要使用wake_up_process启动它，此后，会调用threadfn给出的线程函数 3. data 作为参数传递给新线程 */ linux-2.6.32.63\kernel\kthread.c 3. 宏kthread_run 参数和kthread_create相同，它会调用kthread_create创建新线程，但"立即"唤醒它 4. kthread_create_cpu 可以将新线程绑定到特定的CPU 5. 线程启动后按周期性间隔运行，检测特定资源的使用，在用量超出或低于预置的限制值时采取相应动作，内核使用这类线程用于连续检测任务
内核线程会出现在系统进程列表中，但在ps的输出中由方括号包围，以便和普通进程区分，如果内核线程绑定到特定的CPU，CPU的编号在斜线后给出
可以看到，内核线程和用户态线程一样，在底层同样都是基于do_fork实现的
因为内核线程是由内核自身生成的，应该注意下面两个特别之处
1. 它们在CPU的管态(supervisor mode)执行(即内核态)，而不是用户态执行 2. 它们只可以访问虚拟地址空间的内核部分，但不能访问用户空间
这为优化提供了一些余地，可遵循所谓的"惰性TLB处理(lazy TLB handling)"，在这种模式下，内核线程不与任何特定的用户层进程关联，内核并不需要切换虚拟地址空间的用户层部分，保留旧设置即可，由于内核线程之前可能是任何用户层进程在执行，因此用户空间部分的内容本质上是随机的，内核线程绝不能修改其内容，为强调用户空间部分不能访问，mm设置为空指针，但由于内核必须知道用户空间当前包含了什么，所以在active_mm中保存了指向mm_struct的一个指针来描述它
我们可以从更加本质的角度来理解内核态和用户态，如果把内核理解为一个常驻进程，整个虚拟内存地址空间都是内核进程的内存空间，而用户态部分是由应用层的进程来决定的(也可以理解为为所有进程共享的)，进程上下文的切换(谁在执行)，用户态内存就映射到对应的进程。而这也是为什么在内核态中读写用户态内存需要慎重的原因，因为这个根据进程上下文不断变化的
0x3: 启动新程序
关于Linux进程启动的相关知识，请参阅另一篇文章
http://www.cnblogs.com/LittleHann/p/3853854.html //搜索：4. sys_execve()函数
0x4: 退出进程
进程必须用exit系统调用终止，这使得内核有机会将该进程使用的资源释放回系统，该调用的入口点是sys_exit函数，需要一个错误码作为其参数，以便退出进程，其定义是体系结构无关的
简单来说，该函数的实现就是将各个引用计数器减一，如果引用计数器归零而没有进程再使用对应的结构，那么将相应的内存区域返还给内存管理模块
Relevant Link:
http://www.cnblogs.com/LittleHann/p/3853854.html
6. 进程调度
0x1: 概观
内存中保存了对每个进程的唯一描述，并通过若干结构与其他进程连接起来。调度器面对的情况就是这样，调度器的任务是在程序之间共享CPU时间，创建并行执行的错觉，该任务分为两个不同的部分
1. 调度策略 1) 决定将哪个进程投入运行 2) 何时运行 3) 运行多长时间 2. 上下文切换
调度器是在可运行态进程之间分配"有限"的处理器时间资源、确保进程能够有效工作的内核子系统，调度器是像Linux这样的多任务操作系统的基础，只有通过调度器的合理调度，系统资源才能最大程度地发挥作用，多进程才会有并发执行的效果
理解调度器要从它的原则入手，只要有可以执行的进程，那么就总会有进程正在执行，但是只要系统中可鱼腥的进程的数目比处理器的个数多，就注定某一给定时刻会有一些进程不能执行，这些进程在等待运行，在一组处于"可运行状态(TASK_RUNNING(ready))"的进程中选择一个来执行，这是调度器所需完成的基本工作
0x2: 调度器发展历史
从1991年Linux的第一版到后来的2.4内核系列，Linux的调度器都非常简陋，在每次进程切换时，内核扫描可运行进程的链表(TASK_RUNNING)，计算进程的优先权，然后选择"最佳"进程来运行。这个算法的主要缺点是选择"最佳"进程所要消耗的时间与可运行的进程数量相关，因此，这个算法的开销太大，在运行数千个进程的高端系统中，要消耗太多的时间
正因为如此，在Linux2.5开发系列的内核中，调度程序做了大手术，开始采用一种叫做"O(1)调度程序"的新调度程序，它引入了许多强大的新特性和性能特性，这主要得益于"静态时间片算法"和"针对每一处理器的运行队列"。O(1)虽然在多处理器环境下能表现出近乎完美的性能和可扩展性，但该调度算法对于调度那些响应时间敏感的程序(交互进程)却反应迟钝
为了解决高效CPU调度和交互进行的可响应速度的平衡问题，在2.6内核中引入了新的调度算法，Linux 2.6 的调度算法就复杂多了，最后，"反转楼梯最后期限调度算法(Rotating Staircase Deadline Scheduler RSDL)"，该算法吸取了队列理论，将公平调度的概念引入了Linux调度程序，并最终在2.6.23内核版本中替代了O(1)调度算法，被称为"完全公平调度算法(CFS)"
通过设计，该算法(完全公平调度算法(CFS))较好地解决了与可运行进程数量的比例关系，因为它在固定的时间内(与可运行的进程数量无关)选中要运行的进程。它也很好地处理了与处理器数量的比例关系，因为每个 CPU 都拥有自己的"可运行进程队列"。而且，新算法较好地解决了区分交互式进程和批处理进程的问题。因此，在高负载的系统中，用户感到在 Linux2.6 中交互应用的响应速度比早期的 Linux 版本要快
调度程序总能成功地找到要执行的进程，事实上，总是至少有一个可运行进程：即 init 进程，它的 PID 等于 0，而且它只有在 CPU 不能执行其他进程时才执行
0x3: 多任务系统分类
多任务操作系统就是能"同时"、"并发"、"交互"执行多个进程的操作系统，不论是在单处理器或者多处理器上，多任务操作系统都能够使多个进程处于堵塞或者睡眠状态，因此，现代Linux系统也许有100多个进程在内存，但是只有一个处于可运行状态
多任务系统可以划分为两类
1. 抢占式多任务(preemtive multitasking) 在这个模式下，由调度器来决定什么时候停止一个进程的运行，以便其他进程能够得到执行机会，这个强制的挂起动作就叫做"抢占(preemption)"，进程在被抢占之前能够运行的时间是预先设置好的，即"进程的时间片(timesllice)"，时间片实际上就是分配给每个可运行进程的处理器时间段 有效管理时间片能使调度程序从系统全局的角度做出调度决定，这样还可以避免个别进程独占系统资源 现在操作系统对程序运行都采用了动态时间片计算的方式，并且引入了可配置的计算策略 2. 非抢占式多任务(cooperative multitasking) 在非抢占多任务模式下，除非进程自己主动停止运行，否则它会一直运行下去，进程主动挂起自己的操作称之为让步(yielding)。这种机制有很多缺点，调度程序无法对每个进程该执行多长时间做出统一规定，所以进程独占的处理器时间可能超出用户的预料，甚至来说，如果进程永远不作出让步，则可能使系统崩溃 基于这些原因
需要明白的是，Linux实现的"公平"调度程序本身并没有采取时间片来达到公平调度，Linux调度器的一个杰出特性是，它不需要时间片概念，至少不需要传统的时间片
1. 经典的调度器对系统中的进程分别计算时间片，使进程运行直至时间片用尽，在所有进程的所有时间片都已经用尽时，则需要重新计算 2. 相比之下，当前的调度器只考虑进程的等待时间，即进程在就绪队列(run-queue)中已经等待了多长时间，对CPU时间需求最严格的进程被调度执行
调度器的一般原理是，按所能分配的计算能力，向系统中的每个进程提供最大的公正性。或者从另一个角度来说，它试图确保没有进程被亏待，每次调用调度器时，它会挑选具有最高等待时间的进程，把CPU提供给该进程，在这种情况下，那么进程的不公平待遇不会累积，不公平会均匀分配到系统中的所有进程，从本质上讲，这就是"饥饿算法"
下图简单说明了调度器如何记录哪个进程已经等待了多长时间，由于可运行进程是排队的，该结构被称之为"就绪队列"
所有的可运行进程都按时间在一个红黑树中排序，所谓时间即其等待时间，等待CPU时间最长的进程是最左侧的项，调度器下一次会考虑该进程，等待时间稍短的进程在该树上从左至右排序
红黑树是内核的标准数据结构，该数据结构对所包含的项提供了高效的管理，该树管理的进程数目增加时，查找、插入、删除操作需要的时间只会适度地增加
0x4: 调度策略
调度策略决定了调度程序在何时让什么进程运行，调度器的策略往往就决定系统的整体映像，并且，还要负责优化使用处理器时间，影响调度策略的因素有以下几个
1. I/O消耗型和处理器消耗型的进程 1) I/O消耗型: 进程的大部分时间用来提交I/O请求或等待I/O请求，这样的进程通常都是运行很短的一段时间，因为它在等待更多的I/O请求时最后总会阻塞(例如键盘、或者网络I/O)，典型来说，大多数用户图形界面程序(GUI)都属于I/O密集型，它们大多数时间里都在等待来自鼠标或者键盘的用户交互操作 2) 处理器消耗型: 处理器消耗型进程把时间大多数用在执行代码上，除非被抢占，否则它们通常都一直不停地运行，对于这类处理器消耗型的进程，调度器策略往往是尽量降低它们的调度频率，而延长其运行时间，处理器消耗型进程的极端例子就是无限循环执行，更具代表性的是那些执行大量数学计算的程序，例如sshkeygen、MATLAB /* 要明白的是，这种划分并非决定的，进程可以同时展现这两种行为，例如 1. X Windows服务: 既是I/O消耗型，也是处理器消耗型 2. 自处理器: 通常不断等待键盘输入，但在任一时刻可能又占用CPU进行大量拼写检查或者宏计算 调度策略通常要在两个矛盾的目标中间寻找平衡，进程迅速响应(响应时间短)和最大系统利用率(高吞吐量)。为了满足上述需求，调度器通常采用一套非常复杂的算法来决定最值得运行的进程投入运行 */ 2. 进程优先级 调度算法中最基本的一类就是基于优先级的调度，这是一种根据进程的价值和其对处理器时间的需求来对进程分级的想法。通常的做法是(未被Linux完全采用，只是汲取了其中的精华思想)优先级高的进程先运行，低的后运行，相同优先级的进程按轮转方式进行调度(Round-Robin)。在某些系统中，优先级高的进程使用的时间片也较长，调度程序总是选择时间片未用尽而且优先级最高的进程运行。用户和系统都可以通过设置进程的优先级来影响系统的调度 Linux采用了两种不同的优先级范围 1) nice值: -20 ~ +19，默认值为0，越大的nice值意味着越低的优先级，相比于高nice值(低优先级)的进程，低nice值(高优先级)的进程可以获得更多的处理器时间 2) 实时优先级: 0 ~ 99(其值是可以配置的)，与nice值相反，越高的实时优先级数值意味着进程优先级越高。任何实时进程的优先级都高于普通的进程，也就是说实时优先级数值和nice值互不相交，Linux实时优先级的实现参考了Unix的相关标准(特别是POSIX.1b) /* ps -el N1列对应的就是进程的nice值 ps -eo state,uid,pid,ppid,rtprio,time,comm RTPRIO列对应的实时优先级，如果显示"-"则说明不是实时进程 */ 3. 时间片 时间片是一个数值，它表明进程在被抢占前所能持续运行的时间，调度策略必须规定一个默认的时间片，但这并不是一个简单的事情 1) 时间片过长会导致系统对交互的响应表现欠佳 2) 时间片太短会明显增大进程切换带来的处理器耗时(因为会有大量的时间用在进程上下文切换上)，而这些进程真正能够用来运行的时间片却很短 3) I/O消耗型和处理器消耗型的进程之间的矛盾也更加凸显出来 3.1) I/O消耗型不需要长的时间片 3.2) 处理器消耗型的进程则希望时间片越长越好(比如这样可以让它们的高速缓存命中率更高) /* 综合考虑时间片下的各种矛盾因素，因为长时间片会导致系统交互表现变差，很多操作系统都很重视这点(特别是桌面操作系统)，所以默认的时间片很短(例如10ms) 但是Linux的CFS调度器并没有直接分配时间片到进程，它是将处理器的"使用比例"分给了进程，这样一来，进程所获得的处理器时间其实就和系统负载强关联了，这个比例还进一步受到进程nice值的影响，nice值作为权重将调整进程所使用的处理器时间使用比 1. 更高nice值(更低优先级)的进程将被赋予低权重，从而丧失一小部分的处理器使用比 2. 更小nice值(更高优先级)的进程则被赋予高权重，从而抢得更多的处理器使用比 */ Linux中使用的CFS调度器，其抢占时机取决于新的可运行程序消耗了多少处理器使用比，如果消耗的使用比比当前进程小，则新进程立刻投入运行(抢占当前进程)。否则，将推迟其运行 4. 调度策略的活动 想象下面的系统场景，它拥有两个可运行的进程，一个文件编辑器程序和一个视频解码程序 在这样的场景下，理想情况是调度器应该给与文本编辑器程序相比视频解码程序更多的处理器时间，因为它属于交互式应用，第二是希望文本编辑器能在其被唤醒时(即用户打字时)抢占视频解码程序，这样才能确保文本编辑器具有很好的交互性能，以便能响应用户输入。Linux系统同样需要追求上述目标，它分配给进程一个给定的"处理器使用比"，假如文本编辑器和视频解码器是仅有的两个运行进程，并且又具有同样的nice值，那么处理器的使用比都将是50%(它们平均分配了处理器时间)，但因为因为文本编辑器将大量的时间用于等待用户输入，因此它肯定不会用到处理器的50%，同时，视频解码程序很容易用到超过50%的处理器时间，以便它能更快地完成解码任务 这里关键的问题是，当文本编辑器程序被唤醒时将如何处理，我们的首要目标是确保其能在用户输入发生时立刻运行，在上述场景中，一旦文本编辑器被唤醒，CFS注意到给它的处理器使用比是50%，但是实际使用却很少，特别是CFS发现文本编辑器比视频解码器运行的时间短得多，这样情况下，为了实现让所有进程能公平分享处理器，调度器会立刻抢占视频解码程序，让文本编辑器投入运行，文本编辑器运行后，立即处理了用户的击键输入后，又一次进入睡眠等待用户下一次输入。 因为文本编辑器并没有消费掉分配给它的50%处理器使用比，因此情况依旧，CFS总是会毫不犹豫地让文本编辑器在需要时被投入运行，而让视频解码程序只能在剩下的时刻运行
现在操作系统的调度器是混合了抢占式、非抢占式的综合体，即按动态时间片轮转，也可以允许进程主动yielding让出CPU控制权
0x5: 调度相关数据结构
可以用两种方法激活调度
1. 直接的 进程主动睡眠、或出于其他原因放弃(yeilding)CPU 2. 周期性机制 以固定的频率运行，按照一定的时间间隔检测是否有必要进行进程切换
调度器使用一系列数据结构，来排序和管理系统中的进程，调度器的工作方式与这些结构的设计密切相关，几个组件在许多方面彼此交互
主调度器和周期性调度器合称为"通用调度器(generic scheduler)"或"核心调度器(core scheduler)"，本质上，通用调度器是一个分配器，与其他两个组件交互(调度器类、CPU)
1. 调度类用于判断接下来运行哪个进程，内核支持不同的调度策略(完全公平调度、实时调度、无事可做时调度空闲进程)，调度类这种设计架构使得能够以模块化方法实现这些策略，即一个调度器类的代码不需要和其他类的代码交互 在调度器被调用时，它会查询调度器类，得知接下来运行哪个进程 每个进程都有且只属于一个调度器类，各个调度器类负责管理所属的进程，通用调度器自身完全不涉及进程管理，其工作完全委托给调度器类 2. 在选中将要运行的进程之后，必须执行底层"任务切换"，这需要与CPU的密切交互
1. task_struct的成员
各进程的task_struct有几个成员与调度有关
struct task_struct { .. int prio, static_prio, normal_prio; unsigned int rt_priority; const struct sched_class *sched_class; struct sched_entity se; unsigned int policy; cpumask_t cpus_allowed; .. }
关于task_struct中和调度器相关数据结构的知识，请参阅另一篇文章
http://www.cnblogs.com/LittleHann/p/3865490.html //搜索：0x1: struct task_struct
2. 调度器类
调度器类(task_struct->sched_class)提供了"通用调度器"和各个"调度方法"之间的关联，全局调度器请求的各个操作都可以通过这个指针实现，这使得无须了解不同调度器类的内部工作原理，即可创建通用调度器
\linux-2.6.32.63\include\linux\sched.h
struct sched_class { /* 对各个调度器类，都必须提供struct sched_class的一个实例 调度类之间的层次结构是平坦的 1. 实时进程最重要 2. 完全公平进程次之 3. 空闲进程只有在CPU无事可做时才处于活动状态 next成员将不同调度类的sched_class实例，按上述顺序连接起来，这个层次结构在编译时就已经建立，不能在内核运行时修改 */ const struct sched_class *next; //enqueue_task向就绪队列(TASK_RUNNING(ready))添加一个新进程，在进程从睡眠状态变为可运行状态时，即发生该操作 void (*enqueue_task) (struct rq *rq, struct task_struct *p, int wakeup, bool head); //dequeue_task将一个进程从就绪队列中去除，在进程从可运行状态切换到不可运行状态时，就会发生该操作。内核有可能因为其他理由将进程从就绪队列(红黑树)去除，例如进程的优先级可能需要改变 void (*dequeue_task) (struct rq *rq, struct task_struct *p, int sleep); //在进程想要自愿放弃对处理器的控制权时，可使用sched_yield系统调用，这导致内核调用yield_task void (*yield_task) (struct rq *rq); //在必要的情况下，会调用check_preempt_curr，用一个新唤醒的进程来抢占当前进程，例如在用wake_up_new_task唤醒新进程时，会调用该函数 void (*check_preempt_curr) (struct rq *rq, struct task_struct *p, int flags); //pick_next_task用于选择下一个将要运行的进程 struct task_struct * (*pick_next_task) (struct rq *rq); //put_prev_task在用另一个进程代替当前运行的进程之前调用 void (*put_prev_task) (struct rq *rq, struct task_struct *p); #ifdef CONFIG_SMP int (*select_task_rq)(struct rq *rq, struct task_struct *p, int sd_flag, int flags); unsigned long (*load_balance) (struct rq *this_rq, int this_cpu, struct rq *busiest, unsigned long max_load_move, struct sched_domain *sd, enum cpu_idle_type idle, int *all_pinned, int *this_best_prio); int (*move_one_task) (struct rq *this_rq, int this_cpu, struct rq *busiest, struct sched_domain *sd, enum cpu_idle_type idle); void (*pre_schedule) (struct rq *this_rq, struct task_struct *task); void (*post_schedule) (struct rq *this_rq); void (*task_waking) (struct rq *this_rq, struct task_struct *task); void (*task_woken) (struct rq *this_rq, struct task_struct *task); void (*set_cpus_allowed)(struct task_struct *p, const struct cpumask *newmask); void (*rq_online)(struct rq *rq); void (*rq_offline)(struct rq *rq); #endif //在进程的调度策略发生变化时，需要调用set_curr_task void (*set_curr_task) (struct rq *rq); //task_tick在每次激活周期性调度器时，由周期性调度器使用 void (*task_tick) (struct rq *rq, struct task_struct *p, int queued); void (*task_fork) (struct task_struct *p); void (*switched_from) (struct rq *this_rq, struct task_struct *task, int running); void (*switched_to) (struct rq *this_rq, struct task_struct *task, int running); void (*prio_changed) (struct rq *this_rq, struct task_struct *task, int oldprio, int running); unsigned int (*get_rr_interval) (struct rq *rq, struct task_struct *task); #ifdef CONFIG_FAIR_GROUP_SCHED void (*task_move_group) (struct task_struct *p, int on_rq); #endif };
用户层应用程序无法直接与调度类交互，它们只知道内核定义的常量SCHED_xyz，这些常量和可用的调度类之间提供适当的映射(即调度策略和调度类之间存在对应的映射)，这是内核的工作
1. SCHED_NORMAL、SCHED_BATCH、SCHED_IDLE: 映射到fair_sched_class 2. SCHED_RR、SCHED_FIFO: 映射到re_sched_class //fair_sched_class(公平调度器)、re_sched_class(实时调度器)都是strcut sched_class的实例，这是Linux中两个主要的调度器
3. 就绪队列
核心调度器用于管理活动进程(TASK_RUNNING)的主要数据结构称之为"就绪队列"，各个CPU都有自身的就绪队列，各个活动进程有且只能出现在一个就绪队列中，在多个CPU上同时运行一个进程是不可能的。就绪队列是全局调度器(核心调度器)许多操作的起点
/* This is the main, per-CPU runqueue data structure. Locking rule: those places that want to lock multiple runqueues (such as the load balancing or the thread migration code), lock acquire operations must be ordered by ascending &runqueue. */ struct rq { /* runqueue lock: */ spinlock_t lock; /* nr_running and cpu_load should be in the same cacheline because remote CPUs use both these fields when doing load calculation. nr_running指定了队列上可运行进程的数量，不考虑其优先级或调度类 */ unsigned long nr_running; #define CPU_LOAD_IDX_MAX 5 //用于跟踪此前的负荷状态 unsigned long cpu_load[CPU_LOAD_IDX_MAX]; #ifdef CONFIG_NO_HZ unsigned long last_tick_seen; unsigned char in_nohz_recently; #endif /* capture load from *all* tasks on this cpu: load提供了就绪队列当前负荷的度量，队列的负荷本质上与队列上当前活动进程的数目成正比，其中的各个进程又有优先级作为权重，每个就绪队列的虚拟时钟的速度即基于该信息 */ struct load_weight load; unsigned long nr_load_updates; u64 nr_switches; //cfs是嵌入的子就绪队列，用于完全公平调度器 struct cfs_rq cfs; //rt是嵌入的子就绪队列，用于实时调度器 struct rt_rq rt; #ifdef CONFIG_FAIR_GROUP_SCHED /* list of leaf cfs_rq on this cpu: */ struct list_head leaf_cfs_rq_list; #endif #ifdef CONFIG_RT_GROUP_SCHED struct list_head leaf_rt_rq_list; #endif /* This is part of a global counter where only the total sum over all CPUs matters. A task can increase this counter on one CPU and if it got migrated afterwards it may decrease it on another CPU. Always updated under the runqueue lock: */ unsigned long nr_uninterruptible; //curr指向当前运行的进程的task_struct实例 struct task_struct *curr; //idle指向空闲进程的task_struct实例，该进程也称之为空闲进程，在其他可运行进程时执行 struct task_struct *idle; unsigned long next_balance; struct mm_struct *prev_mm; //clock用于实现就绪队列自身的时钟，每次调用周期性调度器时，都会更新clock的值 u64 clock; u64 clock_task; atomic_t nr_iowait; #ifdef CONFIG_SMP struct root_domain *rd; struct sched_domain *sd; unsigned long cpu_power; unsigned char idle_at_tick; /* For active balancing */ int post_schedule; int active_balance; int push_cpu; /* cpu of this runqueue: */ int cpu; int online; unsigned long avg_load_per_task; struct task_struct *migration_thread; struct list_head migration_queue; u64 rt_avg; u64 age_stamp; u64 idle_stamp; u64 avg_idle; #endif #ifdef CONFIG_IRQ_TIME_ACCOUNTING u64 prev_irq_time; #endif /* calc_load related fields */ unsigned long calc_load_update; long calc_load_active; #ifdef CONFIG_SCHED_HRTICK #ifdef CONFIG_SMP int hrtick_csd_pending; struct call_single_data hrtick_csd; #endif struct hrtimer hrtick_timer; #endif #ifdef CONFIG_SCHEDSTATS /* latency stats */ struct sched_info rq_sched_info; unsigned long long rq_cpu_time; /* could above be rq->cfs_rq.exec_clock + rq->rt_rq.rt_runtime ? */ /* sys_sched_yield() stats */ unsigned int yld_count; /* schedule() stats */ unsigned int sched_switch; unsigned int sched_count; unsigned int sched_goidle; /* try_to_wake_up() stats */ unsigned int ttwu_count; unsigned int ttwu_local; /* BKL stats */ unsigned int bkl_count; #endif };
系统的所有就绪队列都在runqueues数组中，该数组的每个元素分别对应于系统中的一个CPU，在单处理器系统中，由于只需要一个就绪队列，数组只有一个元素
\linux-2.6.32.63\include\linux\sched.c
static DEFINE_PER_CPU_SHARED_ALIGNED(struct rq, runqueues);
内核也定义了一些便利的宏
#define for_each_domain(cpu, __sd) \ for (__sd = rcu_dereference(cpu_rq(cpu)->sd); __sd; __sd = __sd->parent) #define cpu_rq(cpu) (&per_cpu(runqueues, (cpu))) #define this_rq() (&__get_cpu_var(runqueues)) #define task_rq(p) cpu_rq(task_cpu(p)) #define cpu_curr(cpu) (cpu_rq(cpu)->curr) #define raw_rq() (&__raw_get_cpu_var(runqueues))
4. 调度实体
由于调度器可以操作比进程更一般性的实体，因此需要一个适当的数据结构来描述此类实体
/* CFS stats for a schedulable entity (task, task-group etc) Current field usage histogram: 4 se->block_start 4 se->run_node 4 se->sleep_start 6 se->load.weight */ struct sched_entity { /* for load-balancing load指定了权重，决定了各个实体占队列总负荷的比例，计算负荷权重是调度器的一个重要工作，CFS所需的虚拟时钟的速度最终依赖于负荷 */ struct load_weight load; //run_node是标准的树节点，使得实体可以在红黑树上排序 struct rb_node run_node; struct list_head group_node; //on_rq表示该实体当前是否在就绪队列中接受调度 unsigned int on_rq; /* 在进程运行时，我们需要记录消耗的CPU时间，以用于完全公平调度器 1. exec_start: 当前时间 1. sum_exec_runtime: CPU消耗的时间，跟踪运行时间是由update_curr不断累积完成的，调度器中许多地方都会用到这个函数 新进程加入就绪队列时，或者周期性调度器中，每次调用时，会计算当前时间和exec_start之间的差值，exec_start则更新到当前时间，差值则被加到sum_exec_runtime */ u64 exec_start; u64 sum_exec_runtime; //在进程执行期间虚拟时钟上流逝的时间数量由vruntime统计 u64 vruntime; /* 在进程被撤销CPU时，其当前sum_exec_runtime值被保存到prev_sum_exec_runtime，此后，在进程重新再次抢占时又需要这个数据(prev_sum_exec_runtime) 需要注意的是，在prev_sum_exec_runtime中保存sum_exec_runtime的值，sum_exec_runtime并不重置，而是继续增长 */ u64 prev_sum_exec_runtime; u64 last_wakeup; u64 avg_overlap; u64 nr_migrations; u64 start_runtime; u64 avg_wakeup; u64 avg_running; //调度器统计 #ifdef CONFIG_SCHEDSTATS u64 wait_start; u64 wait_max; u64 wait_count; u64 wait_sum; u64 iowait_count; u64 iowait_sum; u64 sleep_start; u64 sleep_max; s64 sum_sleep_runtime; u64 block_start; u64 block_max; u64 exec_max; u64 slice_max; u64 nr_migrations_cold; u64 nr_failed_migrations_affine; u64 nr_failed_migrations_running; u64 nr_failed_migrations_hot; u64 nr_forced_migrations; u64 nr_wakeups; u64 nr_wakeups_sync; u64 nr_wakeups_migrate; u64 nr_wakeups_local; u64 nr_wakeups_remote; u64 nr_wakeups_affine; u64 nr_wakeups_affine_attempts; u64 nr_wakeups_passive; u64 nr_wakeups_idle; #endif //组调度 #ifdef CONFIG_FAIR_GROUP_SCHED struct sched_entity *parent; /* rq on which this entity is (to be) queued: */ struct cfs_rq *cfs_rq; /* rq "owned" by this entity/group: */ struct cfs_rq *my_q; #endif }; struct sched_rt_entity { struct list_head run_list; unsigned long timeout; unsigned int time_slice; int nr_cpus_allowed; struct sched_rt_entity *back; #ifdef CONFIG_RT_GROUP_SCHED struct sched_rt_entity *parent; /* rq on which this entity is (to be) queued: */ struct rt_rq *rt_rq; /* rq "owned" by this entity/group: */ struct rt_rq *my_q; #endif };
由于每个task_struct都嵌入了sched_entity的一个实例，所以进程是可调度实体
0x6: 处理优先级
从用户层的角度来看，优先级就是一些数字，但是从内核的角度来看，内核处理优先级非常复杂
1. 优先级的内核表示
在用户空间可以通过nice命令设置进程的静态优先级，这会最终调用内核的系统调用nice()
内核使用一个简单的数值范围(0 ~ 139)，用来表示内部优先级，值越低，优先级越高，0~99专供实时进程使用，nice(-20 ~ 19)映射到范围100~139，这也是"实时进程一定高于普通进程"的内部原理
1. sched.h #define MAX_USER_RT_PRIO 100 #define MAX_RT_PRIO MAX_USER_RT_PRIO #define MAX_PRIO (MAX_RT_PRIO + 40) #define DEFAULT_PRIO (MAX_RT_PRIO + 20) 2. sched.c #define NICE_TO_PRIO(nice) (MAX_RT_PRIO + (nice) + 20) #define PRIO_TO_NICE(prio) ((prio) - MAX_RT_PRIO - 20) #define TASK_NICE(p) PRIO_TO_NICE((p)->static_prio)
2. 计算优先级
我们知道，优先级的计算涉及到动态优先级(task_struct->prio)、普通优先级(task_struct->normal_prio)、静态优先级(task_struct->static_prio)，它们互相彼此关联
1. static_prio是计算的起点 \linux-2.6.32.63\kernel\sched.c 2. 计算普通优先级 普通优先级需要根据普通进程和实时进程进行不同的计算 /* __normal_prio - return the priority that is based on the static prio */ static inline int __normal_prio(struct task_struct *p) { return p->static_prio; } /* Calculate the expected normal priority: i.e. priority without taking RT-inheritance into account. Might be boosted by interactivity modifiers. Changes upon fork, setprio syscalls, and whenever the interactivity estimator recalculates. */ static inline int normal_prio(struct task_struct *p) { int prio; if (task_has_rt_policy(p)) //实时进程计算普通优先级，由于更高的rt_priority值表示更高的实时优先级(对用户态来说)，内核内部优先级表示则刚好相反，越低的值表示的优先级越高 prio = MAX_RT_PRIO-1 - p->rt_priority; else //对普通进程来说，直接返回静态优先级 prio = __normal_prio(p); return prio; } /* Calculate the current priority, i.e. the priority taken into account by the scheduler. This value might be boosted by RT tasks, or might be boosted by interactivity modifiers. Will be RT if the task got RT-boosted. If not then it returns p->normal_prio. */ static int effective_prio(struct task_struct *p) { //计算普通优先级 p->normal_prio = normal_prio(p); //If we are RT tasks or we were boosted to RT priority, keep the priority unchanged. Otherwise, update priority to the normal priority /* 通过优先级数值，检测当前进程是否为实时进程，即是否小于MAX_RT_PRIO 之所以要通过数值来进行判断，这是因为对于临时提高至实时优先级的非实时进程来说，这是有必要的，这种情况可能发生在使用实时互斥量(RT-Mutex) */ if (!rt_prio(p->prio)) return p->normal_prio; return p->prio; } /* 梳理一下针对不同类型进程上述计算的结果 1. 非实时进程 1) static_prio: static_prio = static_prio 2) normal_prio: normal_prio = static_prio 3) prio: prio = static_prio 2. 优先级提高的非实时进程 1) static_prio: static_prio = static_prio 2) normal_prio: normal_prio = static_prio 3) prio: prio = prio不变 3. 实时进程 1) static_prio: static_prio = static_prio 2) normal_prio: normal_prio = MAX_RT_PRIO-1 - p->rt_priority; 3) prio: prio = prio不变 */
在新建进程用wake_up_new_task唤醒时，或者使用nice系统调用改变静态优先级时，则使用上述算法设置p->prio，需要注意的是，在进程分支出子进程时
1. 子进程的静态优先级(static_prio)继承自父进程 2. 子进程的动态优先级(prio)则设置为父进程的普通优先级(normal_prio)
这确保了实时互斥量引起的优先级提高(prio提高)不会传递到子进程
3. 计算负荷权重
进程的重要性不仅是由优先级指定的，而且还需要考虑保存在task_struct->se.load负荷权重。set_load_weight负责根据"进程类型"及其"静态优先级"计算负荷权重，即优先级是最根本的源头，由优先级及其类型决定负荷权重，然后最终由负荷权重+优先级决定重要性
\linux-2.6.32.63\kernel\sched.h
struct load_weight { unsigned long weight, inv_weight; };
进程每降低一个nice值，则多获得10%的CPU时间(权重)，每升高一个nice值，则放弃10%的CPU时间，为了执行这个策略，内核将优先级转换为权重值
/* Nice levels are multiplicative, with a gentle 10% change for every nice level changed. I.e. when a CPU-bound task goes from nice 0 to nice 1, it will get ~10% less CPU time than another CPU-bound task that remained on nice 0. The "10% effect" is relative and cumulative: from _any_ nice level, if you go up 1 level, it's -10% CPU usage, if you go down 1 level it's +10% CPU usage. (to achieve that we use a multiplier of 1.25. If a task goes up by ~10% and another task goes down by ~10% then the relative distance between them is ~25%.) */ static const int prio_to_weight[40] = { /* -20 */ 88761, 71755, 56483, 46273, 36291, /* -15 */ 29154, 23254, 18705, 14949, 11916, /* -10 */ 9548, 7620, 6100, 4904, 3906, /* -5 */ 3121, 2501, 1991, 1586, 1277, /* 0 */ 1024, 820, 655, 526, 423, /* 5 */ 335, 272, 215, 172, 137, /* 10 */ 110, 87, 70, 56, 45, /* 15 */ 36, 29, 23, 18, 15, };
对内核使用的范围[0, 39]中的每个nice级别(-19~20)，该数组中都有一个对应项，各数组之间的乘数因子是1.25，关于使用该因子的原因，可以考虑下列例子
进程A和进程B在nice级别0运行，因此两个进程的CPU权重相同，即都是50%，nice级别为0的进程，其权重值通过查表可知为1024，每个进程的份额是1024 / (1024 + 1024) = 0.5
如果进程B的优先级加1，那么其CPU权重应该减少10%(准确地说是需要将每个nice之间的权重差值增幅为10%)，即A进程得到CPU权重55%，B进程得到45%
假定"nice = 0"和"nice = 1"的乘数因子为1.25，1024 / 1.25 = 820，此时进程A得到的CPU权重为 1024 / (1024 + 820) = 0.55，而进程B得到的CPU权重为 820 / (1024 + 820) = 0.45，这样就产生了10%的差值
static void set_load_weight(struct task_struct *p) { //执行转换的代码也需要考虑实时进程，实时进程的权重是普通进程的两倍 if (task_has_rt_policy(p)) { p->se.load.weight = 0; p->se.load.inv_weight = WMULT_CONST; return; } /* SCHED_IDLE tasks get minimal weight: SCHED_IDLE得到的权重最小 */ if (p->policy == SCHED_IDLE) { p->se.load.weight = WEIGHT_IDLEPRIO; p->se.load.inv_weight = WMULT_IDLEPRIO; return; } p->se.load.weight = prio_to_weight[p->static_prio - MAX_RT_PRIO]; p->se.load.inv_weight = prio_to_wmult[p->static_prio - MAX_RT_PRIO]; }
不仅进程，而且就绪队列也关联到一个负荷权重，每次进程被加到就绪队列时，内核会调用inc_nr_running，这不仅确保就绪队列能够跟踪记录有多少进程在运行，而且还将进程的权重添加到就绪队列的权重中
static inline void inc_cpu_load(struct rq *rq, unsigned long load) { update_load_add(&rq->load, load); } static inline void update_load_add(struct load_weight *lw, unsigned long inc) { lw->weight += inc; lw->inv_weight = 0; }
在进程从就绪队列移除时，会调用对应的函数(dec_nr_running、dec_cpu_load、update_load_sub)
static void dec_nr_running(struct rq *rq) { rq->nr_running--; } static inline void dec_cpu_load(struct rq *rq, unsigned long load) { update_load_sub(&rq->load, load); } static inline void update_load_sub(struct load_weight *lw, unsigned long dec) { lw->weight -= dec; lw->inv_weight = 0; }
0x7: 核心调度器
我们知道，调度器的实现基于两个函数: 周期性调度函数、主调度函数。它们根据现有的"进程优先级"分配"CPU时间(负荷权重)"，这也是Linux的调度被称为"优先调度"的原因，主调度器和周期性调度器合称为"通用调度器(generic scheduler)"或"核心调度器(core scheduler)"，本质上，通用调度器是一个分配器，与其他两个组件交互(调度器类、CPU)
1. 周期性调度器
周期性调度器在scheduler_tick中实现，如果系统正在活动中，内核会按照频率HZ自动调用该函数，如果没有进程在等待调度，那么在计算计算机电力供应不足的情况下，也可以关闭该调度器以减少电能消耗，该函数有以下两个主要任务
1. 管理内核中与整个系统和各个进程的调度相关的统计量，其间执行的只要操作是对各种计数器加一 2. 激活负责当前进程的调度类的周期性调度方法(Linux下的调度算法采用调度类的模块封装思想)
\linux-2.6.32.63\kernel\sched.c
/* This function gets called by the timer code, with HZ frequency. We call it with interrupts disabled. It also gets called by the fork code, when changing the parent's timeslices. */ void scheduler_tick(void) { int cpu = smp_processor_id(); struct rq *rq = cpu_rq(cpu); struct task_struct *curr = rq->curr; sched_clock_tick(); spin_lock(&rq->lock); //update_rq_clock处理就绪队列时钟的更新，本质上就是增加struct rq当前实例的时钟时间戳，该函数必须处理硬件时钟的一些奇异之处 update_rq_clock(rq); /* update_cpu_load负责更新就绪队列的cpu_load[]数组(struct rq->cpu_load[])，本质上相当于将数组中先前存储的CPU负荷值向后移动一个位置，将当前就绪队列的负荷值记入数组的第一个为自豪 除此之外，该函数还引入了一些取平均值的技巧，以确保符合数组的内容不会呈现出太多的不连续跳变 */ update_cpu_load(rq); /* 由于调度器的模块化结构，主题工程实际上比较简单，因为主要的工作可以完全委托给特定调度器类的方法 task_tick的实现方式取决于底层的调度器类 */ curr->sched_class->task_tick(rq, curr, 0); spin_unlock(&rq->lock); perf_event_task_tick(curr, cpu); #ifdef CONFIG_SMP rq->idle_at_tick = idle_cpu(cpu); trigger_load_balance(rq, cpu); #endif }
2. 主调度器
在内核中的很多地方，如果要将CPU分配给与当前活动进程不同的另一个进程，都会直接调用主调度函数(schedule)。在从系统调用返回后，内核也会检查当前进程是否设置了重调度标志(TIF_NEED_RESCHED)，如果是这样，则内核会调用schedule，该函数假定当前活动进程一定会被另一个进程取代
/* schedule() is the main scheduler function. */ asmlinkage void __sched schedule(void) { struct task_struct *prev, *next; unsigned long *switch_count; struct rq *rq; int cpu; need_resched: preempt_disable(); cpu = smp_processor_id(); //确定当前就绪队列 rq = cpu_rq(cpu); rcu_sched_qs(cpu); //在prev中保存一个指向(仍然)活动进程的task_struct的指针 prev = rq->curr; switch_count = &prev->nivcsw; release_kernel_lock(prev); need_resched_nonpreemptible: schedule_debug(prev); if (sched_feat(HRTICK)) hrtick_clear(rq); spin_lock_irq(&rq->lock); //类似于周期性调度器，内核也利用主调度的这个时机来更新就绪队列的时钟 update_rq_clock(rq); //清除当前运行进程task_struct中的重调度标志(TIF_NEED_RESCHED) clear_tsk_need_resched(prev); //因为调度器的模块化结构，主调度的大部分工作可以委托给调度类 if (prev->state && !(preempt_count() & PREEMPT_ACTIVE)) { /* 如果当前进程原来处于可中断睡眠状态但现在接收到信号，那么它必须再次提升为运行进程 进程状态转换的原则是: 只有非运行到运行状态的双向转换，所以从可中断睡眠状态到被调度之前，需要先转换到运行态(TASK_RUNNING) */ if (unlikely(signal_pending_state(prev->state, prev))) prev->state = TASK_RUNNING; //否则，用相应调度器类的方法使进程停止活动(deactive_task实质上最终调用了sched_class->dequeue_task) else deactivate_task(rq, prev, 1); switch_count = &prev->nvcsw; } pre_schedule(rq, prev); if (unlikely(!rq->nr_running)) idle_balance(cpu, rq); /* put_prev_task首先通知调度器类当前运行的进程将要被另一个进程代替 需要注意的是，这不等价于把进程从就绪队列中移除，而是提供一个时机，执行一些统计工作并更新统计量 */ put_prev_task(rq, prev); //调度类还必须选择下一个应该执行的进程，该工作由，该工作由pick_next_task负责 next = pick_next_task(rq); /* 要注意的是，不一定必然选择一个新进程，也可能其他进程都在睡眠，当前只有一个进程能够运行，这样它自然就被留在CPU上，但如果已经选择了一个新进程，那么必须准备并执行硬件级的进程切换 */ if (likely(prev != next)) { sched_info_switch(prev, next); perf_event_task_sched_out(prev, next, cpu); rq->nr_switches++; rq->curr = next; ++*switch_count; /* unlocks the rq context_switch是一个接口，供访问特定于体系结构的方法，它负责执行底层上下文切换 */ context_switch(rq, prev, next); /* the context switch might have flipped the stack from under us, hence refresh the local variables. */ cpu = smp_processor_id(); rq = cpu_rq(cpu); } else spin_unlock_irq(&rq->lock); post_schedule(rq); if (unlikely(reacquire_kernel_lock(current) < 0)) goto need_resched_nonpreemptible; preempt_enable_no_resched(); //检测当前进程的重调度未是否设置，并跳转到need_resched标号代码位置，重新开始搜索一个新的进程 if (need_resched()) goto need_resched; } EXPORT_SYMBOL(schedule);
3. 与fork的交互
每当使用fork系统调用或其变体之一(本质还是调用了内核的do_fork)建立新进程时，调度器有机会用sched_fork函数挂钩到该进程(在copy_process中被调用)
/* * fork()/clone()-time setup: */ void sched_fork(struct task_struct *p, int clone_flags) { int cpu = get_cpu(); /* 1. 初始化新进程与调度相关的字段 2. 建立数据结构 */ __sched_fork(p); /* We mark the process as running here. This guarantees that nobody will actually run it, and a signal or other external event cannot wake it up and insert it on the runqueue either. */ p->state = TASK_RUNNING; /* Revert to default priority/policy on fork if requested. 3. 确定进程优先级 */ if (unlikely(p->sched_reset_on_fork)) { if (p->policy == SCHED_FIFO || p->policy == SCHED_RR) { p->policy = SCHED_NORMAL; p->normal_prio = p->static_prio; } if (PRIO_TO_NICE(p->static_prio) < 0) { p->static_prio = NICE_TO_PRIO(0); p->normal_prio = p->static_prio; set_load_weight(p); } /* * We don't need the reset flag anymore after the fork. It has * fulfilled its duty: */ p->sched_reset_on_fork = 0; } /* Make sure we do not leak PI boosting priority to the child. 通过使用父进程的普通优先级(normal_prio)作为子进程的动态优先级(prio)，内核确保没有将提供的优先级泄露到子进程(即只取父进程的normal_prio) 因为在使用实时互斥量时进程的动态优先级可以临时修改，该效应不能转移到子进程 */ p->prio = current->normal_prio; //如果优先级不在实时范围中，则进程总是从完全公平调度类开始执行 if (!rt_prio(p->prio)) p->sched_class = &fair_sched_class; if (p->sched_class->task_fork) p->sched_class->task_fork(p); set_task_cpu(p, cpu); #if defined(CONFIG_SCHEDSTATS) || defined(CONFIG_TASK_DELAY_ACCT) if (likely(sched_info_on())) memset(&p->sched_info, 0, sizeof(p->sched_info)); #endif #if defined(CONFIG_SMP) && defined(__ARCH_WANT_UNLOCKED_CTXSW) p->oncpu = 0; #endif #ifdef CONFIG_PREEMPT /* Want to start with kernel preemption disabled. */ task_thread_info(p)->preempt_count = 1; #endif plist_node_init(&p->pushable_tasks, MAX_PRIO); put_cpu(); }
在do_fork中调用的wake_up_new_task唤醒新进程时，则是调度器与进程创建逻辑交互的第二个时机，内核会调用调度类的task_new函数，这将导致新进程被加入到相应类的就绪队列中
4. 上下文切换
内核选择新进程之后，必须处理与多任务相关的技术细节，这些字节总称为上下文切换(context switching)，辅助函数context_switch(schedule()->context_switch())是一个分配器，它会调用所需的特定于体系结构的方法
/* context_switch - switch to the new MM and the new thread's register state. */ static inline void context_switch(struct rq *rq, struct task_struct *prev, struct task_struct *next) { struct mm_struct *mm, *oldmm; //在进程切换之前，prepare_task_switch会调用每个体系结构都必须定义的prepare_arch_switch挂钩，这使得内核执行特定于体系结构的代码，为切换做事先准备 prepare_task_switch(rq, prev, next); trace_sched_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); //上下文切换本身通过特定于处理器的函数完成(switch_mm、switch_to) if (unlikely(!mm)) { next->active_mm = oldmm; atomic_inc(&oldmm->mm_count); //enter_lazy_tlb通知底层体系结构不需要切换虚拟地址空间的用户空间部分，这种加速上下文切换的技术称之为"惰性TLB" enter_lazy_tlb(oldmm, next); } else /* switch_mm更换通过task_struct->mm描述的内存管理上下文，该工作的细节取决于处理器，主要包括 1. 加载页表 2. 刷出地址转换后备缓冲器(部分或全部) 3. 向内存管理单元(MMU)提供新的信息 */ switch_mm(oldmm, mm, next); //内核线程没有自身的用户空间内存上下文，可能在某个随机进程地址空间的上部执行，其task_struct->mm为NULL，从当前进程"借来"的地址空间记录在active_mm中 if (unlikely(!prev->mm)) { //如果前一进程的是内核线程(即prev->mm为NULL)，则其active_mm指针必须被重置为NULL，以断开与借用的地址空间的联系 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: */ #ifndef __ARCH_WANT_UNLOCKED_CTXSW spin_release(&rq->lock.dep_map, 1, _THIS_IP_); #endif /* Here we just switch the register state and the stack. switch_to切换处理器寄存器内容(CPU registered)和内核栈(kernel stack)，因为虚拟地址空间的用户部分在switch_mm中已经变更，其中也包括了用户态下的用户栈 switch_to的工作在不同的体系结构下可能差别很大，代码通常都使用汇编语言编写 由于用户空间进程的寄存器内容在进入核心态时保存在内核栈上，在上下文切换期间无需显式操作，而因为每个进程首先都是从核心态开始执行(在调度期间控制权传递到新进程)(从核心态返回) 在返回用户空间时，会使用内核栈上保存的值自动恢复寄存器数据 */ switch_to(prev, next, prev); //switch_to之后的代码只有在当前进程下一次被选择运行时才会运行(有可能下一次还是选择当前进程，但是也是一次有效的调度选择) //barrier是一个编译器指令，确保switch_to、finish_task_switch语句的执行顺序不会因为任何可能的优化而改变 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. this_rq必须重新计算，因为在调用schedule()之后prev可能已经移动到其他CPU，因此栈帧上的rq可能是无效的 */ //finish_task_switch完成一些清理工作，使得能够正确地释放锁 finish_task_switch(this_rq(), prev); }
finish_task_switch的复杂之处在于，调度过程可能选择了一个新进程，而清理则必须针对此前的活动进程(即被调度之前的那个进程)，内核必须使得该进程(被调度后的新进程)能够与context_switch例程(调度前的旧进程)通信，这可以通过switch_to宏实现，每个体系结构都必须实现它，而且有一个异乎寻常的调用约定，即通过3个参数传递2个变量，这是因为上下文切换不仅涉及2个进程，而是3个进程
假定3个进程A、B、C在系统上运行，在某个时间点，内核决定从进程A切换到进程B，然后从进程B到进程C，再接下来从进程C切换回进程A，在每个switch_to调用之前，next和prev指针位于各进程的栈上，prev指向当前运行的进程，而next指向将要运行的下一个进程，为执行从prev到next的切换，switch_to的前两个参数足够了，对进行A来说，prev指向进程A而next指向进程B
在进程A被选中再次执行时，会出现一个问题，控制权返回至swtich_to之后的点，如果栈准确地恢复到切换之前的状态，那么prev和next仍然指向切换之前的值，即next = B、prev = A，在这种情况下，内核无法知道实际上在进程A之前运行的是进程C
因此，在新进程被选中时，底层的进程切换例程必须将此前执行的进程提供给context_switch，由于控制流会回到该函数的中间(即swtich_to之后)，这无法用普通的函数返回值来做到，因此使用了3个参数的宏，但逻辑上的效果是相同的，仿佛switch_to是带有两个参数的函数，而且返回了一个指向此前运行进程的指针
switch_to宏实际执行的代码如下 prev = switch_to(prev, next); //返回的prev值并不是用作参数的prev值，而是上一个执行的进程，内核实现该行为的的方式依赖于底层的体系结构，但内核显然可以通过考虑两个进程的核心态栈来重建所要的信息，对可以访问所有内存的内核而言，这两个栈显然是同时可用的
惰性FPU模式
由于上下文切换的速度对系统性能的影响很大，所以内核使用了一种技巧来减少所需的CPU时间
1. 浮点寄存器(及其他内核未使用的扩充寄存器，例如IA-32平台上的SSE2寄存器)除非有应用程序实际使用，否则不会保存 2. 除非有应用程序需要，否则这些寄存器也不会恢复
这称之为惰性FPU技术，由于使用了汇编语言代码，因此其实现依平台而有所不同，但基本原理是一样的
Relevant Link:
我们知道，Linux的调度器采用调度类的模块化方式架构，目前内核中有实现以下四种
1. static const struct sched_class fair_sched_class: 完全公平调度类 2. static const struct sched_class rt_sched_class: 实时调度类 3. static const struct sched_class idle_sched_class: CPU空闲时调度类 4. static const struct sched_class stop_sched_class: stop_sched_class
我们接下来着重学习完全公平调度类、和实时调度类
7. 完全公平调度类
核心调度器(由主调度器、周期性调度器组成)必须知道有关完全公平调度器的所有信息
\linux-2.6.32.63\kernel\sched_fair.c
//All the scheduling class methods: static const struct sched_class fair_sched_class = { .next = &idle_sched_class, .enqueue_task = enqueue_task_fair, .dequeue_task = dequeue_task_fair, .yield_task = yield_task_fair, .check_preempt_curr = check_preempt_wakeup, .pick_next_task = pick_next_task_fair, .put_prev_task = put_prev_task_fair, #ifdef CONFIG_SMP .select_task_rq = select_task_rq_fair, .load_balance = load_balance_fair, .move_one_task = move_one_task_fair, .rq_online = rq_online_fair, .rq_offline = rq_offline_fair, .task_waking = task_waking_fair, #endif .set_curr_task = set_curr_task_fair, .task_tick = task_tick_fair, .task_fork = task_fork_fair, .prio_changed = prio_changed_fair, .switched_to = switched_to_fair, .get_rr_interval = get_rr_interval_fair, #ifdef CONFIG_FAIR_GROUP_SCHED .task_move_group = task_move_group_fair, #endif }; //调度类中的函数由主调度器调用
我们接下来逐个学习这些函数在CFS(完全公平调度器)中的实现方式
0x1: 数据结构
我们知道，主调度器的每个就绪队列中都嵌入了一个cfs_rq结构的实例(同时也嵌入了一个rt_rq实例)
\linux-2.6.32.63\kernel\sched.c
/* CFS-related fields in a runqueue */ struct cfs_rq { //load维护了所有队列上可运行进程的累积负荷值 struct load_weight load; //nr_running计算了队列上可运行进程的数目 unsigned long nr_running; u64 exec_clock; //min_vruntime跟踪记录队列上所有进程的最小虚拟运行时间，这个值是实现与就绪队列相关的虚拟时钟的基础 u64 min_vruntime; //tasks_timeline是一个基本成员，用于在按时间排序的红黑树中管理所有进程 struct rb_root tasks_timeline; //rb_leftmost总是设置为指向树最左边的结点，即最需要被调度的进程 struct rb_node *rb_leftmost; struct list_head tasks; struct list_head *balance_iterator; /* 'curr' points to currently running entity on this cfs_rq. curr指向当前执行进程的可调度实体 It is set to NULL otherwise (i.e when none are currently running). */ struct sched_entity *curr, *next, *last; unsigned int nr_spread_over; #ifdef CONFIG_FAIR_GROUP_SCHED struct rq *rq; /* cpu runqueue to which this cfs_rq is attached */ /* * leaf cfs_rqs are those that hold tasks (lowest schedulable entity in * a hierarchy). Non-leaf lrqs hold other higher schedulable entities * (like users, containers etc.) * * leaf_cfs_rq_list ties together list of leaf cfs_rq's in a cpu. This * list is used during load balance. */ struct list_head leaf_cfs_rq_list; struct task_group *tg; /* group that "owns" this runqueue */ #ifdef CONFIG_SMP /* * the part of load.weight contributed by tasks */ unsigned long task_weight; /* * h_load = weight * f(tg) * * Where f(tg) is the recursive weight fraction assigned to * this group. */ unsigned long h_load; /* * this cpu's part of tg->shares */ unsigned long shares; /* * load.weight at the time we set shares */ unsigned long rq_weight; #endif #endif };
0x2: CFS操作
1. 虚拟时钟
我们知道，完全公平调度算法依赖于虚拟时钟，用以度量等待进程在完全公平系统中所能得到的CPU时间，但是struct cfs_rq中并不保存任何有关虚拟时钟的信息，这是因为所有的必要信息都可以根据现存的实际时钟与每个进程相关的负荷权重推算出来。所有与虚拟时钟有关的计算都在update_curr中执行，该函数在系统中的很多地方被调用
/* Update the current task's runtime statistics. Skip current tasks that are not in our scheduling class. 对于运行在nice级别为0的进程来说，根据定义虚拟时间和物理时间是相等的 对于不同的优先级时，必须根据进程的负荷权重重新衡定时间 */ static inline void __update_curr(struct cfs_rq *cfs_rq, struct sched_entity *curr, unsigned long delta_exec) { unsigned long delta_exec_weighted; schedstat_set(curr->exec_max, max((u64)delta_exec, curr->exec_max)); curr->sum_exec_runtime += delta_exec; schedstat_add(cfs_rq, exec_clock, delta_exec); /* 忽略舍入和溢出检查，calc_delta_fair所做的计算就是下列公式 delta_exec_weighted = delta_exec * (NICE_0_LOAD) / curr->load.weight Linux的逆向权重值在计算中体现了作用 1. 越重要的进程会有越高的优先级(越低的nice值)，会得到更大的权重，因此最后计算得到的累加的虚拟运行时间会越小 2. 根据公式可知，nice 0的进程优先级为120，则虚拟时间和物理时间是相等的，即current->load.weight = NICE_0_LOAD的情况 */ delta_exec_weighted = calc_delta_fair(delta_exec, curr); curr->vruntime += delta_exec_weighted; //设置min_vruntime，必须保证该值是单调递增的 update_min_vruntime(cfs_rq); } static void update_curr(struct cfs_rq *cfs_rq) { //确定就绪队列的当前执行进程 struct sched_entity *curr = cfs_rq->curr; //获取主调度器就绪队列的实际时钟值，该值在每个调度周期都会更新 u64 now = rq_of(cfs_rq)->clock_task; unsigned long delta_exec; if (unlikely(!curr)) return; /* Get the amount of time the current task was running since the last time we changed load (this cannot overflow on 32 bits): 内核会计算当前和上一次更新负荷统计量时两次的时间差 */ delta_exec = (unsigned long)(now - curr->exec_start); if (!delta_exec) return; //执行实际的虚拟时钟工作，__update_curr需要更新当前进程在CPU上执行花费的物理时间和虚拟时间 __update_curr(cfs_rq, curr, delta_exec); curr->exec_start = now; if (entity_is_task(curr)) { struct task_struct *curtask = task_of(curr); trace_sched_stat_runtime(curtask, delta_exec, curr->vruntime); cpuacct_charge(curtask, delta_exec); account_group_exec_runtime(curtask, delta_exec); } }
完全公平调度器的真正关键点是，红黑树的排序过程是根据下列键进行的
\linux-2.6.32.63\kernel\sched_fair.c
static inline s64 entity_key(struct cfs_rq *cfs_rq, struct sched_entity *se) { return se->vruntime - cfs_rq->min_vruntime; }
键值较小的节点，排序位置就更靠左，因此会被更快地调度。用这种方法，内核实现了下面两种动态制衡的对立机制
1. 在进程运行时，其vruntime稳定地增加，它在红黑树中总是向右移动的， 因为越重要的进程vruntime增加越慢，因为越重要的进程会有越高的优先级(越低的nice值)，会得到更大的权重，因此最后计算得到的累加的虚拟运行时间会越小。这样其被调度的机会要大于次要进程，这正好是我们所希望看到的 2. 如果进程进入睡眠(例如交互式进程等待键盘输入)，则其vruntime保持不变，因为每个队列的min_vruntime同时会增加，那么睡眠进程醒来后(等待事件已经发生)，在红黑树中的位置会更靠左，因为其键值变得更小了 //上述两种效应是同时发生的，呈现一种动态制衡的效果
2. 延迟跟踪
内核有一个固定的概念，称之为良好的调度延迟，即保证每个可运行的进程都应该至少运行一次的某个时间间隔
1. sysctl_sched_lasency: 一个进程最少运行的时间，可通过/proc/sys/kernel/sched_latency_ns控制，默认值为20毫秒 2. sched_nr_latency: 控制在一个延迟周期中处理的最大活动进程数目 //如果活动进程的数目超出sched_nr_latency上限，则延迟周期sysctl_sched_lasency也会成比例地线性扩展
__sched_period确定延迟周期的长度，通常就是sysctl_sched_lasency，但如果有更多进程在运行，其值有可能按比例线性扩展，在这种情况下
周期长度 = sysctl_sched_lasency * nr_running / sched_nr_latency
通过考虑各个进程的相对权重，将一个延迟周期的时间在活动进程之间进行分配，对于由某个可调度实体表示的给定进程，分配到的时间如下计算
/* We calculate the wall-time slice from the period by taking a part proportional to the weight. s = p*P[w/rw] */ static u64 sched_slice(struct cfs_rq *cfs_rq, struct sched_entity *se) { u64 slice = __sched_period(cfs_rq->nr_running + !se->on_rq); for_each_sched_entity(se) { struct load_weight *load; struct load_weight lw; cfs_rq = cfs_rq_of(se); load = &cfs_rq->load; if (unlikely(!se->on_rq)) { lw = cfs_rq->load; update_load_add(&lw, se->load.weight); load = &lw; } slice = calc_delta_mine(slice, se->load.weight, load); } return slice; }
我们知道，就绪队列的负荷权重是队列上所有活动进程负荷权重的累加和，结果时间段是按实际时间给出的，但内核有时候也需要知道等价的虚拟时间
/* We calculate the vruntime slice of a to be inserted task vs = s/w */ static u64 sched_vslice(struct cfs_rq *cfs_rq, struct sched_entity *se) { /* 对权重weight的进程来说，实际时间段time对应的虚拟时间长度为： time * NICE_0_LOAD / weight */ return calc_delta_fair(sched_slice(cfs_rq, se), se); }
0x3: 队列操作
接下来讨论CFS和全局调度器(核心调度器)交互所必须实现的各个方法，有两个函数可用来增删就绪队列的成员:
1. enqueue_task_fair 2. dequeue_task_fair
1. enqueue_task_fair
/* The enqueue_task method is called before nr_running is increased. Here we update the fair scheduling stats and then put the task into the rbtree: */ static void enqueue_task_fair(struct rq *rq, struct task_struct *p, int wakeup, bool head) { struct cfs_rq *cfs_rq; struct sched_entity *se = &p->se; int flags = 0; //判断指定入队的进程是否最近才被唤醒并转换为运行状态 if (wakeup) flags |= ENQUEUE_WAKEUP; if (p->state == TASK_WAKING) flags |= ENQUEUE_MIGRATE; for_each_sched_entity(se) { //通过struct sched_entity的on_rq成员判断进程是否已经在就绪队列上 if (se->on_rq) break; cfs_rq = cfs_rq_of(se); //将具体工作委托给enqueue_entity完成 enqueue_entity(cfs_rq, se, flags); flags = ENQUEUE_WAKEUP; } hrtick_update(rq); }
继续跟进enqueue_entity
static void enqueue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int flags) { /* Update the normalized vruntime before updating min_vruntime through callig update_curr(). */ if (!(flags & ENQUEUE_WAKEUP) || (flags & ENQUEUE_MIGRATE)) se->vruntime += cfs_rq->min_vruntime; /* Update run-time statistics of the 'current'. 更新统计量 */ update_curr(cfs_rq); account_entity_enqueue(cfs_rq, se); if (flags & ENQUEUE_WAKEUP) { //如果进程此前在睡眠，那么在place_entity中首先会调整进程的虚拟运行时间 place_entity(cfs_rq, se, 0); enqueue_sleeper(cfs_rq, se); } update_stats_enqueue(cfs_rq, se); check_spread(cfs_rq, se); if (se != cfs_rq->curr) //使用了内核的标准方法将进程置于红黑树中 __enqueue_entity(cfs_rq, se); }
由于内核已经承诺在当前的延迟周期内使所有活动进程都至少执行一次，队列的min_vruntime用作基准虚拟时间，通过减去sysctl_sched_latency，则可以确保新唤醒的进程只有在当前延迟周期结束后才能运行。但如果睡眠的进程已经积累了比较的不公平值(即se_vruntime值比较大)，则内核必须考虑这一点，如果se->vruntime比先前计算的差值更大，则将其作为进程的vruntime，这会导致进程在红黑树中处于比较靠左的位置
0x4: 选择下一个进程
选择下一个将要运行的进程由pick_next_task_fair执行(fair_sched_class调度器类的成员)
static struct task_struct *pick_next_task_fair(struct rq *rq) { struct task_struct *p; struct cfs_rq *cfs_rq = &rq->cfs; struct sched_entity *se; //如果nr_running计数器为0，即当前队列上没有可运行进程，则无事可做，函数可以立即返回 if (unlikely(!cfs_rq->nr_running)) return NULL; do { //将具体工作委托给pick_next_entity se = pick_next_entity(cfs_rq); set_next_entity(cfs_rq, se); cfs_rq = group_cfs_rq(se); } while (cfs_rq); p = task_of(se); hrtick_start_fair(rq, p); return p; }
继续跟进pick_next_entity
static struct sched_entity *pick_next_entity(struct cfs_rq *cfs_rq) { //如果最左边的进程可用，可以使用辅助函数first_fair立即确定，然后使用__pick_next_entity从红黑树中提取出sched_entity实例 struct sched_entity *se = __pick_next_entity(cfs_rq); struct sched_entity *left = se; if (cfs_rq->next && wakeup_preempt_entity(cfs_rq->next, left) < 1) se = cfs_rq->next; /* * Prefer last buddy, try to return the CPU to a preempted task. */ if (cfs_rq->last && wakeup_preempt_entity(cfs_rq->last, left) < 1) se = cfs_rq->last; clear_buddies(cfs_rq, se); return se; }
0x5: 处理周期性调度器
/* scheduler tick hitting a task of our scheduling class: */ static void task_tick_fair(struct rq *rq, struct task_struct *curr, int queued) { struct cfs_rq *cfs_rq; struct sched_entity *se = &curr->se; for_each_sched_entity(se) { cfs_rq = cfs_rq_of(se); //实际工作委托给entity_tick entity_tick(cfs_rq, se, queued); } }
继续跟进entity_tick
static void entity_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr, int queued) { /* Update run-time statistics of the 'current'. 使用update_curr更新统计量 */ update_curr(cfs_rq); #ifdef CONFIG_SCHED_HRTICK /* * queued ticks are scheduled to match the slice, so don't bother * validating it and just reschedule. */ if (queued) { resched_task(rq_of(cfs_rq)->curr); return; } /* * don't let the period tick interfere with the hrtick preemption */ if (!sched_feat(DOUBLE_TICK) && hrtimer_active(&rq_of(cfs_rq)->hrtick_timer)) return; #endif //如果nr_running计数器表明队列上可运行的进程少于2个(即1个或没有)，则实际上无事可做(不需要调度) if (cfs_rq->nr_running > 1 || !sched_feat(WAKEUP_PREEMPT)) check_preempt_tick(cfs_rq, curr); }
继续跟进check_preempt_tick
/* Preempt the current task with a newly woken task if needed: 该函数的目的在于: 确保没有哪个进程能够比延迟周期中确定的份额运行的时间更长，该份额对应的实际时间长度在sched_slice中计算 */ static void check_preempt_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr) { unsigned long ideal_runtime, delta_exec; ideal_runtime = sched_slice(cfs_rq, curr); /* 进程在CPU上已经运行的实际时间间隔由"sum_exec_runtime - prev_sum_exec_runtime"给出 因此抢占决策很容易做出 1. 如果进程运行时间比期望的时间间隔长，那么通过resched_task发出重调度请求，这会在task_struct中设置TIF_NEED_RESCHED标志，核心调度器会在下一个适当时机发起重调度 */ delta_exec = curr->sum_exec_runtime - curr->prev_sum_exec_runtime; if (delta_exec > ideal_runtime) { resched_task(rq_of(cfs_rq)->curr); /* * The current task ran long enough, ensure it doesn't get * re-elected due to buddy favours. */ clear_buddies(cfs_rq, curr); return; } /* * Ensure that a task that missed wakeup preemption by a * narrow margin doesn't have to wait for a full slice. * This also mitigates buddy induced latencies under load. */ if (!sched_feat(WAKEUP_PREEMPT)) return; if (delta_exec < sysctl_sched_min_granularity) return; if (cfs_rq->nr_running > 1) { struct sched_entity *se = __pick_next_entity(cfs_rq); s64 delta = curr->vruntime - se->vruntime; if (delta < 0) return; if (delta > ideal_runtime) resched_task(rq_of(cfs_rq)->curr); } }
0x6: 进程唤醒
当在try_to_wake_up、和wake_up_new_task中唤醒进程时，内核使用check_preempt_curr来查看是否新进程可以抢占当前运行的进程，对完全公平调度器处理的进程，则由check_preempt_wakeup函数执行该检测
//All the scheduling class methods: static const struct sched_class fair_sched_class = { .next = &idle_sched_class, .enqueue_task = enqueue_task_fair, .dequeue_task = dequeue_task_fair, .yield_task = yield_task_fair, .check_preempt_curr = check_preempt_wakeup,
新唤醒的进程不一定由完全公平调度器处理，如果新进程是一个实时进程，则会立即请求重调度，因为实时进程总是会抢占CFS进程
/* * Preempt the current task with a newly woken task if needed: */ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p, int wake_flags) { struct task_struct *curr = rq->curr; struct sched_entity *se = &curr->se, *pse = &p->se; struct cfs_rq *cfs_rq = task_cfs_rq(curr); int sync = wake_flags & WF_SYNC; int scale = cfs_rq->nr_running >= sched_nr_latency; update_curr(cfs_rq); //判断新唤醒的进程是否为实时进程 if (unlikely(rt_prio(p->prio))) { resched_task(curr); return; } if (unlikely(p->sched_class != &fair_sched_class)) return; if (unlikely(se == pse)) return; if (sched_feat(NEXT_BUDDY) && scale && !(wake_flags & WF_FORK)) set_next_buddy(pse); /* * We can come here with TIF_NEED_RESCHED already set from new task * wake up path. */ if (test_tsk_need_resched(curr)) return; /* * Batch and idle tasks do not preempt (their preemption is driven by * the tick): */ if (unlikely(p->policy != SCHED_NORMAL)) return; /* Idle tasks are by definition preempted by everybody. */ if (unlikely(curr->policy == SCHED_IDLE)) { resched_task(curr); return; } if ((sched_feat(WAKEUP_SYNC) && sync) || (sched_feat(WAKEUP_OVERLAP) && (se->avg_overlap < sysctl_sched_migration_cost && pse->avg_overlap < sysctl_sched_migration_cost))) { resched_task(curr); return; } if (sched_feat(WAKEUP_RUNNING)) { if (pse->avg_running < se->avg_running) { set_next_buddy(pse); resched_task(curr); return; } } if (!sched_feat(WAKEUP_PREEMPT)) return; find_matching_se(&se, &pse); BUG_ON(!pse); if (wakeup_preempt_entity(se, pse) == 1) { resched_task(curr); /* * Only set the backward buddy when the current task is still * on the rq. This can happen when a wakeup gets interleaved * with schedule on the ->pre_schedule() or idle_balance() * point, either of which can * drop the rq lock. * * Also, during early boot the idle thread is in the fair class, * for obvious reasons its a bad idea to schedule back to it. */ if (unlikely(!se->on_rq || curr == rq->idle)) return; if (sched_feat(LAST_BUDDY) && scale && entity_is_task(se)) set_last_buddy(se); } }
0x7: 处理新进程
对完全公平调度器需要考虑的最后一个操作是创建新进程时调用的挂钩函数: task_new_fair()，该函数的行为可使用sysctl_sched_child_runs_first控制，该参数用于判断新建子进程是否应该在父进程之前运行，这通常是有益的，特别是在copy on write的情况下，如果子进程随后会执行exec系统调用，则这样的操作会大大减少copy on write的发生
该参数的默认设置是1，但可以通过/proc/sys/kernel/sched_child_runs_first修改
8. 实时调度类
按照POSIX标准的强制要求，除了"普通"进程之外，Linux还支持两种实时调度类，调度器结构使得实时进程可以平滑地集成到内核中，而无须修改核心调度器，这是调度类模块架构带来的好处
0x1: 性质
实时进程与普通进程有一个根本的不同之处，即如果系统中有一个实时进程且可运行，那么调度器总是会选择它运行，除非有另一个优先级更高的实时进程，回想之前关于调度策略和调度器类的映射关系
1. SCHED_NORMAL、SCHED_BATCH、SCHED_IDLE: 映射到fair_sched_class 2. SCHED_RR、SCHED_FIFO: 映射到re_sched_class //fair_sched_class(公平调度器)、re_sched_class(实时调度器)都是strcut sched_class的实例，这是Linux中两个主要的调度器
现有的两种实时调度器类，不同之处如下
1. 循环进程(SCHED_RR): 有时间片，其值在进程运行时会减少，就像是普通进程，在所有的时间段都到期后，则该值重置为初始值，而进程则至于队列的末尾，这确保了在有几个优先级相同的SCHED_RR进程的情况下，它们总是依次执行 2、 先进先出进程(SCHED_FIFO): 没有时间片，在被调度器选择执行后，可以运行任意长时间。很明显，如果实时进程编写得比较差，系统可能变得无法使用，很容易hang住
0x2: 数据结构
static const struct sched_class rt_sched_class = { .next = &fair_sched_class, .enqueue_task = enqueue_task_rt, .dequeue_task = dequeue_task_rt, .yield_task = yield_task_rt, .check_preempt_curr = check_preempt_curr_rt, .pick_next_task = pick_next_task_rt, .put_prev_task = put_prev_task_rt, #ifdef CONFIG_SMP .select_task_rq = select_task_rq_rt, .load_balance = load_balance_rt, .move_one_task = move_one_task_rt, .set_cpus_allowed = set_cpus_allowed_rt, .rq_online = rq_online_rt, .rq_offline = rq_offline_rt, .pre_schedule = pre_schedule_rt, .post_schedule = post_schedule_rt, .task_woken = task_woken_rt, .switched_from = switched_from_rt, #endif .set_curr_task = set_curr_task_rt, .task_tick = task_tick_rt, .get_rr_interval = get_rr_interval_rt, .prio_changed = prio_changed_rt, .switched_to = switched_to_rt, };
和完全公平调度器一样，核心调度器的就绪队列也包含了用于实时进程的子就绪队列，是一个嵌入的strcut rt_rq实例
实时进程的就绪队列非常简单，只是一个链表
/* This is the priority-queue data structure of the RT scheduling class: */ struct rt_prio_array { /* include 1 bit for delimiter active.bitmap位图中的每个比特位对应于一个链表，凡包含了进程的链表，对应的比特位则置为，如果链表中没有进程，则对应比特位不置位 */ DECLARE_BITMAP(bitmap, MAX_RT_PRIO+1); //具有相同优先级的所有实时进程都保存在一个链表中，表头为active.queue[prio] struct list_head queue[MAX_RT_PRIO]; }; /* Real-Time classes' related field in a runqueue: */ struct rt_rq { struct rt_prio_array active; unsigned long rt_nr_running; #if defined CONFIG_SMP || defined CONFIG_RT_GROUP_SCHED struct { int curr; /* highest queued rt task prio */ #ifdef CONFIG_SMP int next; /* next highest */ #endif } highest_prio; #endif #ifdef CONFIG_SMP unsigned long rt_nr_migratory; unsigned long rt_nr_total; int overloaded; struct plist_head pushable_tasks; #endif int rt_throttled; u64 rt_time; u64 rt_runtime; /* Nests inside the rq lock: */ spinlock_t rt_runtime_lock; #ifdef CONFIG_RT_GROUP_SCHED unsigned long rt_nr_boosted; struct rq *rq; struct list_head leaf_rt_rq_list; struct task_group *tg; struct sched_rt_entity *rt_se; #endif };
实时调度类中对应update_cur的是update_curr_rt，该函数将当前进程在CPU上执行花费的时间记录在sum_exec_runtime中，所有计算的单位都是实际时间，不需要虚拟时间
0x3: 调度器操作
实时进程的入队和离队都比较简单，只需以p->prio为索引访问queue数组queue[p>prio]，即可获得正确的链表，将进程加入加入链表或从链表删除即可。如果队列中至少有一个进程，则将位图中对应的比特位置位，如果队列中没有进程，则清除位图中对应的比特位，需要注意的是，新进程总是排列在每个链表的末尾
对于实时进程来说，pick_next_task_rt负责选择下一个将执行的进程
static struct sched_rt_entity *pick_next_rt_entity(struct rq *rq, struct rt_rq *rt_rq) { struct rt_prio_array *array = &rt_rq->active; struct sched_rt_entity *next = NULL; struct list_head *queue; int idx; //sched_find_first_bit是一个标准函数，可以找到active.bitmap中第一个置位的比特位，这意味着最高的优先级(对应于较低的内核优先级数值) idx = sched_find_first_bit(array->bitmap); BUG_ON(idx >= MAX_RT_PRIO); queue = array->queue + idx; next = list_entry(queue->next, struct sched_rt_entity, run_list); return next; } static struct task_struct *_pick_next_task_rt(struct rq *rq) { struct sched_rt_entity *rt_se; struct task_struct *p; struct rt_rq *rt_rq; rt_rq = &rq->rt; if (unlikely(!rt_rq->rt_nr_running)) return NULL; if (rt_rq_throttled(rt_rq)) return NULL; do { rt_se = pick_next_rt_entity(rq, rt_rq); BUG_ON(!rt_se); rt_rq = group_rt_rq(rt_se); } while (rt_rq); p = rt_task_of(rt_se); p->se.exec_start = rq->clock_task; return p; } static struct task_struct *pick_next_task_rt(struct rq *rq) { struct task_struct *p = _pick_next_task_rt(rq); /* The running task is never eligible for pushing */ if (p) dequeue_pushable_task(rq, p); #ifdef CONFIG_SMP /* We detect this state here so that we can avoid taking the RQ lock again later if there is no need to push */ rq->post_schedule = has_pushable_tasks(rq); #endif return p; }
9. 调度器增强
0x1: SMP调度
在多处理器系统上，内核必须考虑几个额外的问题，以确保良好的调度
1. CPU负荷必须尽可能公平地在所有处理器上负载 2. 进程与系统中某些处理器的亲和性(affinity)必须是可设置的，例如在4核CPU上，可以将计算密集型应用绑定到前3个CPU，而剩余的(交互式)进程则在第4个CPU上运行 进程对特定CPU的亲和性，定义在task_struct的cpus_allowed成员中，Linux提供了sched_setaffinity系统调用，可修改进程与CPU的现有分配关系 3. 内核必须能够将进程从一个CPU迁移到另一个
1. 数据结构的扩展
在SMP系统上，每个调度器类的调度方法必须增加两个额外的函数
0x2: 调度域和控制组
我们知道，调度器并不直接与进程交互，而是处理"可调度实体"，这使得可以实现"组调度": 进程置于不同的组中，调度器首先在这些组之间保证公平，然后在组中的所有进程之间保证公平
内核提供了控制组(control group)，该特性使得通过通过特殊文件系统cgroups可以创建任意的进程集合，甚至可以分为多个层次
0x3: 内核抢占和低延迟相关工作
1. 内核抢占
我们知道，在系统调用后返回到用户态之前，后者内核中某些指定的点上，都会调用调度器，这确保除了一些明确指定的情况之外，内核是无法中断的(因为外设引发的硬件中断除外)，这是不同于用户进程的地方。
这种情况可能会带来"系统体验"的问题，在编译内核的时候启用对内核抢占的支持，可以解决此问题，如果高优先级的进程有事情需要完成，那么在启动内核抢占的情况下，不仅用户空间应用程序可以被中断，内核也可以被中断
2. 低延迟
10. 小结
1. 在CPU关中断的情况下，进程的调度是不受影响的，调度器仍然可以正常工作 2. 在CPU关中断的情况下，如果主动调用睡眠系统调用放弃CPU权利，这个进程不受影响，因为睡眠的唤醒是依靠信号相关的系统调用完成的，而系统调用的"软中断"响应不受关中断的影响 3. 在CPU关中断的情况下，内核是无法响应外设(例如网卡、内存、硬盘)的中断请求的，即如果这个时候内核中发生了一次缺页中断(PAGE FAULT)，但是硬盘外设发起的数据传输请求是无法得到响应的(执行失败、或者延迟DELAY)，即这个PAGE FAULT无法得到FIX，内核代码在回到之前发生PAGE FAULT的地方准备再次执行的时候，对应的内存页面依然还是无效的，这就导致了KERNEL的一个不一致状态 4. 在CPU关中断的情况下，不能使用vmalloc在LKM代码中申请内存，因为vmalloc分配的是一段"可分页内存(pageable memory)"，在内存使用紧张的时候，swap可能会将vmalloc分配的一部分内存换出到磁盘上的swap分区中，如果在之后的某个时刻，内核其他地方的代码需要访问这块被换出的内存，就会触发"缺页中断"，但是因为缺页中断的响应是响应硬盘外设的中断，这个时候CPU是无法响应这个中断请求的，这有可能导致Kernel Panic 一个好的做法是使用kmalloc来申请内存，但是kmalloc的问题在于它只能申请一段连续的内存，而且上限有限，很多时候不能满足需求，同时，还需要注意使用GFP_ATOMIC标志，这是一个原子操作且保证在分配的时候不睡眠
Copyright (c) 2014 LittleHann All rights reserved
