第一次作业：深入源码分析进程模型(Linux kernel 2.6.32)

1.前言

本文基于Linux 2.6.32分析其进程模型，包括进程的概念、组织、转换、调度等内容，帮助对操作系统课程及Linux相关知识的理解和学习。

附Linux Kernel 2.6.32源码下载地址：

https://mirrors.edge.kernel.org/pub/linux/kernel/v2.6/linux-2.6.32.tar.gz

2.进程的概念

2.1什么是进程？

在正式开始结合源代码分析进程模型之前，我们首先需要搞清楚进程的究竟是什么。

维基百科上对于进程的定义如下：

进程（英语：process），是计算机中已运行程序的实体。

我们知道，我们的系统仅认识二进制文件，那么当我们要让系统运行某个功能的时候，也就是需要启动一个二进制文件，这个文件就是程序。

而Linux系统中，每个进程拥有三组人的权限（分别为u/g/o，即拥有者/拥有者所属组其他成员/不是拥有者也不是所属组的成员），每组人可能拥有的权限为r/w/x（读/写/执行），所以，不同的用户身份执行同一个程序时，系统给予的权限可能不同，即产生的进程也可能不同。

如上图所示，程序一般存储在磁盘中，通过用户的执行来触发，触发后，程序加载到内存中，成为一个个体，那就是进程。操作系统为了管理这个进程，会给予进程执行者的权限/属性等参数，以及进程所需要的数据，最后再给予一个PID，通过PID来识别该进程。

2.2进程与程序、线程的区别

在面向进程设计的系统（如早期的UNIX，Linux 2.4及更早的版本）中，进程是程序的基本执行实体；在面向线程设计的系统（如当代多数操作系统、Linux 2.6及更新的版本）中，进程本身不是基本运行单位，而是线程的容器。

简单地来说，进程与程序是动态与静止的区别，进程与程序是多对一的，同样，线程与进程也是多对一的。

3.进程的组织

3.1进程描述符

进程描述符是用于描述一个进程的结构体，每个进程只有一个这样的结构体，包含了关于这个进程的所有信息。这个结构体名为task_struct，被定义在源代码包目录下的include/linux/sched.h头文件中，这里截取部分代码进行分析说明。（ps:由于我是在虚拟机下运行linux，为方便代码的拷贝，使用了secureCRT的sftp服务器将虚拟机中的相关代码文件传输到了客户端上，用虚拟机运行linux的朋友可以参考此用法）

struct task_struct{
    volatile long state;    /* -1 unrunnable, 0 runnable, >0 stopped */
    ......
    int prio, static_prio, normal_prio;
    unsigned int rt_priority;
    ......
    pid_t pid;
    ......
}

3.2进程标识符(PID)

文章的第二部分已经提到过，系统通过PID来唯一的标识每个进程。可用如下命令查看系统当前的进程信息：

ps -l

运行结果如图，我们可以看到当前系统中的三个进程，分别为bash,top,ps。其中bash即我们的终端，每运行一个终端，都会生成一个bash进程，可以看到这个bash进程的PID为7275。而ps是在终端下运行的查看进程的指令，它的PID为7287。除了PID外，还有一个PPID，指的是父进程的PID，即执行了这条命令的bash的PID-7275。何为父进程呢？这样说吧， 当我们打开终端时，会获得一个bash进程，然后，我们用这个bash提供的接口去执行另外的命令，例如刚刚所说的ps，这些命令也会被分配PID，这就是“子进程”，而原本的bash环境，自然就是“父进程”了。

3.3进程优先级(PRI)

进程的优先级是指系统在进程调度时用于判决进程是否能够获取CPU资源的依据。进程的优先级越高，则越能在竞争中胜出而获得CPU资源。在Linux中，进程的优先级用一个整数表达，数值越低，优先级越高。在上一小节的截图中，我们能看到每个进程都有一个优先级，默认情况下为80。

在task_struct中，用了几个成员变量来表示优先级。

int prio,static_prio, normal_prio;
unsigned int rt_priority;

为什么会出现这么多优先级呢？这是因为在某些情况下，系统需要暂时改变进程的优先级，但这些改变不是持久的，因此这个优先级会用prio表示（调度器会考虑的优先级也保存在prio），而不改变静态优先级和普通优先级。需要注意的是，当我们用renice命令改变进程的优先级时，改变的是静态优先级。

3.4进程的状态

进程的状态在task_struct中以如下方式定义

struct task_struct{
    volatile long state;    /* -1 unrunnable, 0 runnable, >0 stopped */

在sched.h头文件中，有着state变量可能拥有的值：

/*
 * Task state bitmask. NOTE! These bits are also
 * encoded in fs/proc/array.c: get_task_state().
 *
 * We have two separate sets of flags: task->state
 * is about runnability, while task->exit_state are
 * about the task exiting. Confusing, but this way
 * modifying one set can‘t modify the other one by
 * mistake.
 */
#define TASK_RUNNING        0
#define TASK_INTERRUPTIBLE  1
#define TASK_UNINTERRUPTIBLE    2
#define __TASK_STOPPED      4
#define __TASK_TRACED       8
/* in tsk->exit_state */
#define EXIT_ZOMBIE     16
#define EXIT_DEAD       32
/* in tsk->state again */
#define TASK_DEAD       64
#define TASK_WAKEKILL       128
#define TASK_WAKING     256

通过注释我们可以知道，进程状态分为两类，其中state是关于运行的状态，exit_state是关于退出的状态。代码中定义的各字段所代表的意义如下：

|字段 |描述 |

| -------- | -----: | ----: |

|TASK_RUNNING|可运行状态，进程要么正在执行，要么准备执行。|

|TASK_INTERRUPTIBLE|可中断的等待状态，进程处于睡眠状态，直到某个条件为真而被唤醒。|

|TASK_UNINTERRUPTIBLE|不可中断的等待状态，与可中断的等待状态类似，但是不能被信号所唤醒|

|TASK_STOPED|暂停状态，当进程接收到SIGSTOP、SIGTSTP、SIGTTIN或SIGTTOU信号后进入。|

|TASK_TRACED|跟踪状态，进程被另一个进程所监控，如debugger|

|EXIT_ZOMBIE|僵尸状态，进程已经终止，但父进程还没有获得进程的终止信息|

|EXIT_DEAD|进程被终止的最终状态|

综合以上两部分，我们大致清楚了，系统通过进程标识符（PID)来唯一地标识进程，通过优先级（PRI）来决定哪些进程现在应该被运行，通过进程的状态来有序安排进程在什么时候应该做什么事情，这便是进程的组织了。

4.进程的转换

上图清楚的展示了进程间的转换过程，这里简单说明一下。当我们创建一个任务并运行时，它就是TASK_RUNNING状态，CPU不停地分配时间片给这个进程，当时间片耗尽，进程转为就绪态（仍然为TASK_RUNNING），等待CPU再次分配时间片。如果进程需要进行像写入磁盘文件这样的操作时，进程就会进入TASK_INTERRUPTIBLE状态，等待操作完毕，操作完毕后，进程收到中断告知，则重新回到运行状态。

当硬件条件不满足，比如进程打开一个设备文件，驱动开始探测相应的硬件时，会进入TASK_UNINTERRUPTIBLE状态，此时只能通过特定的方式唤醒。进程需要退出时，会进入僵尸状态，保留其进程描述符供父进程获取信息，当父进程通过wait()系统调用告诉系统后，进程进入EXIT_DEAD状态，运行周期结束。

5.进程的调度

5.1关于调度

无论是在linux下输入ps命令，还是在windows下打开任务管理器，我们通常都能看到一大堆的进程，这给了我们一种错觉：系统同时在执行很多个进程。事实上，我们看到的进程中，绝大部分处在休眠状态，CPU在同一时间只会执行一个进程，这就是调度器面对的情况。调度器需要在进程之间共享CPU时间，创造并行执行的错觉。它不仅要尽可能公平地共享CPU，同时又要考虑不同的任务优先级，以提供良好的用户体验。整个调度系统至少包含两种调度算法，分别针对实时进程和普通进程。最开始的调度器是复杂度为O(n)的始调度算法，每次都会遍历所有任务，效率低下。后来引入了O(1)调度器，大大提高了效率。当然，在全球程序员的智慧下，自linux2.6开始，一个更优秀的调度器取代了O(1)调度器，即CFS调度器。它有着完全公平的思想，将所有的进程统一对待，本文的这一部分主要介绍的就是调度普通进程的CFS调度器。

5.2优先级和nice值

在分析CFS之前，我想先补充一下前面提到过的优先级和nice值。为什么需要优先级呢？我们知道，CPU一秒钟可以运行G级别的微命令次数，通过内核的CPU调度，各进程被CPU切换运行，因此，每个进程在一秒之内可能会被CPU或多或少地执行部分。如果没有优先级的存在，每个进程像游乐场排队一样，玩过一遍还想玩，得去后面继续排队等待，如果前面的任务又臭又长，紧急的任务得不到及时的反馈，用户体验自然会很差了。这就是我们为什么需要优先级来提高紧急任务的执行频率。要注意的是，PRI是由系统内核动态调整的，用户无法直接调整PRI，要想调整进程的优先执行顺序时，我们得通过Nice值（谦让值）。一般来说，PRI与NICE的相关性如下：

PRI(NEW)=PRI(OLD)+nice

Nice是一个从-20~19的值，默认等于0。需要注意，Nice的值为负数时，优先级的数值下降，即代表优先级升高，Nice值越小，代表越不”谦让“，优先级就越高。

5.3CFS算法

task_struct中有一个struct_entity se成员，定义了调度器的实体结构。进程调度算法实际上也就是管理所以进程的这个se成员。

struct_entity 部分代码如下

struct sched_entity {
    struct load_weight  load;       /* for load-balancing */
    struct rb_node      run_node;
    struct list_head    group_node;
    unsigned int        on_rq;

    u64         exec_start;
    u64         sum_exec_runtime;
    u64         vruntime;

5.3.1关于vruntime

vruntime是CFS的重要概念，简单地说，vruntime是该进程的运行时间，但这个时间是通过优先级等计算过的虚拟运行时间，并非物理时间。之前在进程的转换中提到过CPU分配时间片，在CFS中，已经不再使用时间片，而是按照虚拟运行时间来衡量进程此时是否该被调度。那么，虚拟时间是如何被计算出来的呢?kernel/sched.c中有一个用于处理时钟中断的函数，如下

void scheduler_tick(void)
{
…
    raw_spin_lock(&rq->lock);
    update_rq_clock(rq);
    update_cpu_load(rq);
    curr->sched_class->task_tick(rq, curr, 0);
    raw_spin_unlock(&rq->lock);
…
}

其中，curr->sched_class->task_tick(rq, curr, 0);用于执行调度器，更新vruntime值。task_tike_fair函数则会在循环语句中，对所以有se变量调用entity_tick()，代码如下

for_each_sched_entity(se) {
        cfs_rq = cfs_rq_of(se);
        entity_tick(cfs_rq, se, queued);//Look at this line
    }

static void entity_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr, int queued)
{
    /*
     * Update run-time statistics of the ‘current‘.
     */
    update_curr(cfs_rq);    //Look at this line

#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

    if (cfs_rq->nr_running > 1 || !sched_feat(WAKEUP_PREEMPT))
        check_preempt_tick(cfs_rq, curr);
}

重点是update_curr(cfs_rq);更新了就绪队列的vruntime值。ps:cfs_rq为普通进程的就绪队列，声明如下

    struct cfs_rq       *cfs_rq;
    /* rq "owned" by this entity/group: */

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);
    delta_exec_weighted = calc_delta_fair(delta_exec, curr);

    curr->vruntime += delta_exec_weighted;
    update_min_vruntime(cfs_rq);
}

可以看到，update_curr函数首先累计了实际的运行时间(Line:7)，然后调用calc_delta_fair(delta_exec,curr)对delta_exec进行加权计算(Line:9)(至于如何进行加权计算没有再深入研究)，然后再将加权计算的结果累计加入vruntime(Line:11)，最后更新并保存cfs_rq队列中的的最小虚拟运行时间(Line:12)。由此，我们可以大概看到vruntime产生的整个过程。

5.3.2关于决定下一个进程

CFS用红黑树来调度实体SE，而键值则是虚拟运行时间vruntime，CFS会选择具有最小vruntime值的进程作为下一个进程，而这个进程，实际上就是红黑树中的最左叶子节点。CFS调度器中有pick_next_task_fair()用于选择下一个进程。

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;

    if (!cfs_rq->nr_running)
        return NULL;

    do {
        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;
}

实际上用于选择下一个进程的函数在11行：pick_next_entity(cfs_rq)

/*
 * Pick the next process, keeping these things in mind, in this order:
 * 1) keep things fair between processes/task groups
 * 2) pick the "next" process, since someone really wants that to run
 * 3) pick the "last" process, for cache locality
 * 4) do not run the "skip" process, if something else is available
 */
static struct sched_entity *
pick_next_entity(struct cfs_rq *cfs_rq, struct sched_entity *curr)
{
    struct sched_entity *left = __pick_first_entity(cfs_rq);
    struct sched_entity *se;

    /*
     * If curr is set we have to see if its left of the leftmost entity
     * still in the tree, provided there was anything in the tree at all.
     *
     */
    if (!left || (curr && entity_before(curr, left)))
    {
        left = curr;
    }

    se = left; /* ideally we run the leftmost entity */

    if (cfs_rq->skip == se)
    {
        struct sched_entity *second;

        if (se == curr)
        {
            second = __pick_first_entity(cfs_rq);
        }
        else
        {

            second = __pick_next_entity(se);
            if (!second || (curr && entity_before(curr, second)))
                second = curr;
        }

        if (second && wakeup_preempt_entity(second, left) < 1)
            se = second;
    }

    /*
     * 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;

    /*
     * Someone really wants this to run. If it‘s not unfair, run it.
     */
    if (cfs_rq->next && wakeup_preempt_entity(cfs_rq->next, left) < 1)
        se = cfs_rq->next;

    clear_buddies(cfs_rq, se);

    return se;
}

这段代码实现了选中红黑树中最左叶子节点的进程，并将其从树上移除，更新红黑树。至此，下一个进程已经成功选出了。

6.感想与看法

Linux自0.01版问世以来，就从未停止过变化，发展至今，已经有无数的程序员们为Linux贡献了自己的代码，于是展现在我们眼前的，是一个无比精妙成熟的系统架构。我们无法知道未来的linux会进化成什么模样，至少在今天，我们看到了CFS，利用简单的vruntime机制，就实现了以往复杂度为O(n)的算法才能实现的需求，不得不感叹这个系统背后的人们付出的努力。当然,CFS的完全公平，也并不是所有进程绝对的平等，而是体现在虚拟运行时间上，实际上其更新和增长的速度是并不一样的。能否完全兼顾到效率与公平，答案只能交给时间来告诉我们了。

7.参考资料

1.Linux进程调度CFS算法实现分析

2.进程——维基百科，自由的百科全书

3.TASK_KILLABLE: New process state in Linux

4.《鸟哥的Linux私房菜》，鸟哥，人民邮电出版社

原文地址：https://www.cnblogs.com/HHhuhao/p/8975526.html