ucore操作系统lab6（理论部分）

一、实验流程

1、进程的正常生命周期如下：



进程首先在 cpu 初始化或者 sys_fork 的时候被创建，当为该进程分配了一个进程控制块之后，该进程进入 uninit态(在proc.c 中 alloc_proc)。

当进程完全完成初始化之后，该进程转为runnable态。

当到达调度点时，由调度器 sched_class 根据运行队列rq的内容来判断一个进程是否应该被运行，即把处于runnable态的进程转换成running状态，从而占用CPU执行。

running态的进程通过wait等系统调用被阻塞，进入sleeping态。

sleeping态的进程被wakeup变成runnable态的进程。

running态的进程主动 exit 变成zombie态，然后由其父进程完成对其资源的最后释放，子进程的进程控制块成为unused。

所有从runnable态变成其他状态的进程都要出运行队列，反之，被放入某个运行队列中。

2、调用进程调度函数schedule的位置和原因

编号	位置	原因
1	proc.c::do_exit	用户线程执行结束，主动放弃CPU控制权。
2	proc.c::do_wait	用户线程等待子进程结束，主动放弃CPU控制权。
3	proc.c::init_main	1. initproc内核线程等待所有用户进程结束，如果没有结束，就主动放弃CPU控制权; 2. initproc内核线程在所有用户进程结束后，让kswapd内核线程执行10次，用于回收空闲内存资源
4	proc.c::cpu_idle	idleproc内核线程的工作就是等待有处于就绪态的进程或线程，如果有就调用schedule函数
5	sync.h::lock	在获取锁的过程中，如果无法得到锁，则主动放弃CPU控制权
6	trap.c::trap	如果在当前进程在用户态被打断去，且当前进程控制块的成员变量need_resched设置为1，则当前线程会放弃CPU控制权

仔细分析上述位置，第1、2、5处的执行位置体现了由于获取某种资源一时等不到满足、进程要退出、进程要睡眠等原因而不得不主动放弃CPU。第3、4处的执行位置比较特殊，initproc内核线程等待用户进程结束而执行schedule函数；idle内核线程在没有进程处于就绪态时才执行，一旦有了就绪态的进程，它将执行schedule函数完成进程调度。这里只有第6处的位置比较特殊：

if (!in_kernel) {
……

if (current->need_resched) {
schedule();
}
}

3、进程切换过程

假定有两个用户进程，在二者进行进程切换的过程中，具体的步骤如下：

首先在执行某进程A的用户代码时，出现了一个 trap (例如是一个外设产生的中断)，这个时候就会从进程A的用户态切换到内核态(过程(1))，并且保存好进程A的trapframe；当内核态处理中断时发现需要进行进程切换时，ucore要通过schedule函数选择下一个将占用CPU执行的进程（即进程B），然后会调用proc_run函数，proc_run函数进一步调用switch_to函数，切换到进程B的内核态(过程(2))，继续进程B上一次在内核态的操作，并通过iret指令，最终将执行权转交给进程B的用户空间(过程(3))。

当进程B由于某种原因发生中断之后(过程(4))，会从进程B的用户态切换到内核态，并且保存好进程B的trapframe；当内核态处理中断时发现需要进行进程切换时，即需要切换到进程A，ucore再次切换到进程A(过程(5))，会执行进程A上一次在内核调用schedule (具体还要跟踪到 switch_to 函数)函数返回后的下一行代码，这行代码当然还是在进程A的上一次中断处理流程中。最后当进程A的中断处理完毕的时候，执行权又会反交给进程A的用户代码(过程(6))。这就是在只有两个进程的情况下，进程切换间的大体流程。

二、调度框架和调度算法
1、数据结构
运行队列通过链表的形式进行组织。链表的每一个节点是一个list_entry_t,每个list_entry_t
又对应到了 struct proc_struct *,这其间的转换是通过宏 le2proc 来完成 的。具体来说，我们知道在 struct proc_struct 中有一个叫 run_link 的 list_entry_t，因此可以通过偏移量逆向找到对因某个 run_list的 struct proc_struct。即进程结构指针 proc = le2proc(链表节点指针, run_link)。

struct sched_class {
// 调度器的名字
const char *name;
// 初始化运行队列
void (*init) (struct run_queue *rq);
// 将进程 p 插入队列 rq
void (*enqueue) (struct run_queue *rq, struct proc_struct *p);
// 将进程 p 从队列 rq 中删除
void (*dequeue) (struct run_queue *rq, struct proc_struct *p);
// 返回 运行队列 中下一个可执行的进程
struct proc_struct* (*pick_next) (struct run_queue *rq);
// timetick 处理函数
void (*proc_tick)(struct  run_queue* rq, struct proc_struct* p);
};

此外，proc.h
中的 struct proc_struct 中也记录了一些调度相关的信息：

struct proc_struct {
// . . .
// 该进程是否需要调度，只对当前进程有效
volatile bool need_resched;
// 该进程的调度链表结构，该结构内部的连接组成了 运行队列 列表
list_entry_t run_link;
// 该进程剩余的时间片，只对当前进程有效
int time_slice;
// round-robin 调度器并不会用到以下成员
// 该进程在优先队列中的节点
skew_heap_entry_t  lab6_run_pool;
// 该进程的调度优先级
uint32_t lab6_priority;
// 该进程的调度步进值
uint32_t lab6_stride;
};

在此次实验中，需要了解 default_sched.c中的实现RR调度算法的函数。在该文件中，你可以看到ucore 已经为 RR 调度算法创建好了一个名为 RR_sched_class 的调度策略类。

通过数据结构 struct run_queue 来描述完整的 run_queue（运行队列）。它的主要结构如下：

struct run_queue {
//其运行队列的哨兵结构，可以看作是队列头和尾
list_entry_t run_list;
//优先队列形式的进程容器
skew_heap_entry_t  *lab6_run_pool;
//表示其内部的进程总数
unsigned int proc_num;
//每个进程一轮占用的最多时间片
int max_time_slice;
};

在
ucore 框架中，运行队列存储的是当前可以调度的进程，所以，只有状态为runnable的进程才能够进入运行队列。当前正在运行的进程并不会在运行队列中，这一点需要注意。

2、调度点的相关关键函数
仔细观察各个流程的共性部分，会发现其中只涉及了三个关键调度相关函数：wakup_proc、shedule、run_timer_list。如果我们能够让这三个调度相关函数的实现与具体调度算法无关，那么就可以认为ucore实现了一个与调度算法无关的调度框架。

wakeup_proc函数其实完成了把一个就绪进程放入到就绪进程队列中的工作，为此还调用了一个调度类接口函数sched_class_enqueue，这使得wakeup_proc的实现与具体调度算法无关。schedule函数完成了与调度框架和调度算法相关三件事情:把当前继续占用CPU执行的运行进程放放入到就绪进程队列中，从就绪进程队列中选择一个“合适”就绪进程，把这个“合适”的就绪进程从就绪进程队列中摘除。通过调用三个调度类接口函数sched_class_enqueue、sched_class_pick_next、sched_class_enqueue来使得完成这三件事情与具体的调度算法无关。run_timer_list函数在每次timer中断处理过程中被调用，从而可用来调用调度算法所需的timer时间事件感知操作，调整相关进程的进程调度相关的属性值。通过调用调度类接口函数sched_class_proc_tick使得此操作与具体调度算法无关。

这里涉及了一系列调度类接口函数：

sched_class_enqueue
sched_class_dequeue
sched_class_pick_next
sched_class_proc_tick

这4个函数的实现其实就是调用某基于sched_class数据结构的特定调度算法实现的4个指针函数。采用这样的调度类框架后，如果我们需要实现一个新的调度算法，则我们需要定义一个针对此算法的调度类的实例，一个就绪进程队列的组织结构描述就行了，其他的事情都可交给调度类框架来完成。

3、RR 调度算法实现
RR调度算法的调度思想是让所有runnable态的进程分时轮流使用CPU时间。RR调度器维护当前runnable进程的有序运行队列。当前进程的时间片用完之后，调度器将当前进程放置到运行队列的尾部，再从其头部取出进程进行调度。RR调度算法的就绪队列在组织结构上也是一个双向链表，只是增加了一个成员变量，表明在此就绪进程队列中的最大执行时间片。而且在进程控制块proc_struct中增加了一个成员变量time_slice，用来记录进程当前的可运行时间片段。这是由于RR调度算法需要考虑执行进程的运行时间不能太长。在每个timer到时的时候，操作系统会递减当前执行进程的time_slice，当time_slice为0时，就意味着这个进程运行了一段时间（这个时间片段称为进程的时间片），需要把CPU让给其他进程执行，于是操作系统就需要让此进程重新回到rq的队列尾，且重置此进程的时间片为就绪队列的成员变量最大时间片max_time_slice值，然后再从rq的队列头取出一个新的进程执行。下面来分析一下其调度算法的实现。
RR_enqueue的函数实现如下表所示。即把某进程的进程控制块指针放入到rq队列末尾，且如果进程控制块的时间片为0，则需要把它重置为rq成员变量max_time_slice。这表示如果进程在当前的执行时间片已经用完，需要等到下一次有机会运行时，才能再执行一段时间。

static void
RR_enqueue(struct run_queue *rq, struct proc_struct *proc) {
assert(list_empty(&(proc->run_link)));
list_add_before(&(rq->run_list), &(proc->run_link));
if (proc->time_slice == 0 || proc->time_slice > rq->max_time_slice) {
proc->time_slice = rq->max_time_slice;
}
proc->rq = rq;
rq->proc_num ++;
}

RR_pick_next的函数实现如下表所示。即选取就绪进程队列rq中的队头队列元素，并把队列元素转换成进程控制块指针。

static struct proc_struct *
FCFS_pick_next(struct run_queue *rq) {
list_entry_t *le = list_next(&(rq->run_list));
if (le != &(rq->run_list)) {
return le2proc(le, run_link);
}
return NULL;
}

RR_dequeue的函数实现如下表所示。即把就绪进程队列rq的进程控制块指针的队列元素删除，并把表示就绪进程个数的proc_num减一。

static void
FCFS_dequeue(struct run_queue *rq, struct proc_struct *proc) {
assert(!list_empty(&(proc->run_link)) && proc->rq == rq);
list_del_init(&(proc->run_link));
rq->proc_num --;
}

RR_proc_tick的函数实现如下表所示。即每次timer到时后，trap函数将会间接调用此函数来把当前执行进程的时间片time_slice减一。如果time_slice降到零，则设置此进程成员变量need_resched标识为1，这样在下一次中断来后执行trap函数时，会由于当前进程程成员变量need_resched标识为1而执行schedule函数，从而把当前执行进程放回就绪队列末尾，而从就绪队列头取出在就绪队列上等待时间最久的那个就绪进程执行。

static void
RR_proc_tick(struct run_queue *rq, struct proc_struct *proc) {
if (proc->time_slice > 0) {
proc->time_slice --;
}
if (proc->time_slice == 0) {
proc->need_resched = 1;
}
}

三、Stride Schedule算法
1、基本思路
考察 round-robin 调度器，在假设所有进程都充分使用了其拥有的 CPU
时间资源的情况下，所有进程得到的 CPU 时间应该是相等的。但是有时候我们希望调度器能够更智能地为每个进程分配合理的 CPU 资源。假设我们为不同的进程分配不同的优先级，则我们有可能希望每个进程得到的时间资源与他们的优先级成正比关系。Stride调度是基于这种想法的一个较为典型和简单的算法。除了简单易于实现以外，它还有如下的特点：

可控性：如我们之前所希望的，可以证明 Stride Scheduling对进程的调度次数正比于其优先级。

确定性：在不考虑计时器事件的情况下，整个调度机制都是可预知和重现的。该算法的基本思想可以考虑如下：

1、为每个runnable的进程设置一个当前状态stride，表示该进程当前的调度权。另外定义其对应的pass值，表示对应进程在调度后，stride 需要进行的累加值。

2、每次需要调度时，从当前 runnable 态的进程中选择 stride最小的进程调度。

对于获得调度的进程P，将对应的stride加上其对应的步长pass（只与进程的优先权有关系）。

3、在一段固定的时间之后，回到 2.步骤，重新调度当前stride最小的进程。

可以证明，如果令 P.pass =BigStride / P.priority 其中 P.priority 表示进程的优先权（大于 1），而 BigStride 表示一个预先定义的大常数，则该调度方案为每个进程分配的时间将与其优先级成正比。将该调度器应用到 ucore 的调度器框架中来，则需要将调度器接口实现如下：

init:

– 初始化调度器类的信息（如果有的话）。

– 初始化当前的运行队列为一个空的容器结构。（比如和RR调度算法一样，初始化为一个有序列表）

enqueue

– 初始化刚进入运行队列的进程 proc的stride属性。

– 将 proc插入放入运行队列中去（注意：这里并不要求放置在队列头部）。

dequeue

– 从运行队列中删除相应的元素。

pick next

– 扫描整个运行队列，返回其中stride值最小的对应进程。

– 更新对应进程的stride值，即pass = BIG_STRIDE / P->priority; P->stride += pass。

proc tick:

– 检测当前进程是否已用完分配的时间片。如果时间片用完，应该正确设置进程结构的相关标记来引起进程切换。

– 一个 process 最多可以连续运行 rq.max_time_slice个时间片。

在具体实现时，有一个需要注意的地方：stride属性的溢出问题，令PASS_MAX为当前所有进程里最大的步进值。则我们可以证明如下结论：对每次Stride调度器的调度步骤中，有其最大的步进值STRIDE_MAX和最小的步进值STRIDE_MIN之差：

STRIDE_MAX – STRIDE_MIN <= PASS_MAX

有了该结论，在加上之前对优先级有Priority > 1限制，我们有STRIDE_MAX – STRIDE_MIN <= BIG_STRIDE,于是我们只要将BigStride取在某个范围之内，即可保证对于任意两个 Stride 之差都会在机器整数表示的范围之内。而我们可以通过其与0的比较结构，来得到两个Stride的大小关系。基于这种特殊考虑的比较方法，即便Stride有可能溢出，我们仍能够得到理论上的当前最小Stride，并做出正确的调度决定。

2、使用优先队列实现 Stride Scheduling
优先队列是这样一种数据结构：使用者可以快速的插入和删除队列中的元素，并且在预先指定的顺序下快速取得当前在队列中的最小（或者最大）值及其对应元素。可以看到，这样的数据结构非常符合
Stride 调度器的实现。

本次实验提供了libs/skew_heap.h 作为优先队列的一个实现，该实现定义相关的结构和接口，其中主要包括：

// 优先队列节点的结构
typedef struct skew_heap_entry  skew_heap_entry_t;
// 初始化一个队列节点
void skew_heap_init(skew_heap_entry_t *a);
// 将节点 b 插入至以节点 a 为队列头的队列中去，返回插入后的队列
skew_heap_entry_t  *skew_heap_insert(skew_heap_entry_t  *a,
skew_heap_entry_t  *b,
compare_f comp);
// 将节点 b 插入从以节点 a 为队列头的队列中去，返回删除后的队列
skew_heap_entry_t  *skew_heap_remove(skew_heap_entry_t  *a,
skew_heap_entry_t  *b,
compare_f comp);

其中优先队列的顺序是由比较函数comp决定的，sched_stride.c中提供了proc_stride_comp_f比较器用来比较两个stride的大小，可以直接使用它。当使用优先队列作为Stride调度器的实现方式之后，运行队列结构也需要作相关改变，其中包括：

struct run_queue中的lab6_run_pool指针，在使用优先队列的实现中表示当前优先队列的头元素，如果优先队列为空，则其指向空指针（NULL）。

struct proc_struct中的lab6_run_pool结构，表示当前进程对应的优先队列节点。本次实验已经修改了系统相关部分的代码，使得其能够很好地适应LAB6新加入的数据结构和接口。而在实验中我们需要做的是用优先队列实现一个正确和高效的Stride调度器，如果用较简略的伪代码描述，则有：

init(rq):

– Initialize rq->run_list

– Set rq->lab6_run_pool to NULL

– Set rq->proc_num to 0

enqueue(rq, proc)

– Initialize proc->time_slice

– Insert proc->lab6_run_pool into rq->lab6_run_pool

– rq->proc_num ++

dequeue(rq, proc)

– Remove proc->lab6_run_pool from rq->lab6_run_pool

– rq->proc_num --

pick_next(rq)

– If rq->lab6_run_pool == NULL, return NULL

– Find the proc corresponding to the pointer rq->lab6_run_pool

– proc->lab6_stride += BIG_STRIDE / proc->lab6_priority

– Return proc

proc_tick(rq, proc):

– If proc->time_slice > 0, proc->time_slice --

– If proc->time_slice == 0, set the flag proc->need_resched