进程调度所使用到的数据结构：
1.就绪队列
内核为每一个cpu创建一个进程就绪队列，该队列上的进程均由该cpu执行，代码如下（kernel/sched/core.c）。
DEFINE_PER_CPU_SHARED_ALIGNED(struct rq, runqueues);
定义了一个struct rq结构体数组，每个数组元素是一个就绪队列，对应一个cpu。下面看下struct rq结构体（kernel/sched/sched.h）：
struct rq {
/* runqueue lock: */
raw_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.
*/
unsigned int nr_running;
#ifdef CONFIG_NUMA_BALANCING
unsigned int nr_numa_running;
unsigned int nr_preferred_running;
#endif
#define CPU_LOAD_IDX_MAX 5
unsigned long cpu_load[CPU_LOAD_IDX_MAX];
unsigned long last_load_update_tick;
#ifdef CONFIG_NO_HZ_COMMON
u64 nohz_stamp;
unsigned long nohz_flags;
#endif
#ifdef CONFIG_NO_HZ_FULL
unsigned long last_sched_tick;
#endif
int skip_clock_update;
/* capture load from *all* tasks on this cpu: */
struct load_weight load;
unsigned long nr_load_updates;
u64 nr_switches;
struct cfs_rq cfs;
struct rt_rq rt;
struct dl_rq dl;
#ifdef CONFIG_FAIR_GROUP_SCHED
/* list of leaf cfs_rq on this cpu: */
struct list_head leaf_cfs_rq_list;
struct sched_avg avg;
#endif /* CONFIG_FAIR_GROUP_SCHED */
/*
* 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;
struct task_struct *curr, *idle, *stop;
unsigned long next_balance;
struct mm_struct *prev_mm;
u64 clock;
u64 clock_task;
atomic_t nr_iowait;
#ifdef CONFIG_SMP
struct root_domain *rd;
struct sched_domain *sd;
unsigned long cpu_capacity;
unsigned char idle_balance;
/* For active balancing */
int post_schedule;
int active_balance;
int push_cpu;
struct cpu_stop_work active_balance_work;
/* cpu of this runqueue: */
int cpu;
int online;
struct list_head cfs_tasks;
u64 rt_avg;
u64 age_stamp;
u64 idle_stamp;
u64 avg_idle;
/* This is used to determine avg_idle's max value */
u64 max_idle_balance_cost;
#endif
#ifdef CONFIG_IRQ_TIME_ACCOUNTING
u64 prev_irq_time;
#endif
#ifdef CONFIG_PARAVIRT
u64 prev_steal_time;
#endif
#ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING
u64 prev_steal_time_rq;
#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_count;
unsigned int sched_goidle;
/* try_to_wake_up() stats */
unsigned int ttwu_count;
unsigned int ttwu_local;
#endif
#ifdef CONFIG_SMP
struct llist_head wake_list;
#endif
};
struct rq
该结构体是本地cpu所有进程组成的就绪队列，在linux内核中，进程被分为普通进程和实时进程，这两种进程的调度策略是不同的，因此在31-32行可以看到rq结构体中又内嵌了struct cfs_rq cfs和struct rt_rq rt两个子就绪队列，分别来组织普通进程和实时进程（普通进程将采用完全公平调度策略cfs，而实时进程将采用实时调度策略），第33行struct dl_rq dl调度空闲进程，暂且不讨论。所以，如果咱们研究的是普通进程的调度，需要关心的就是struct cfs_rq cfs队列；如果研究的是实时进程，就只关心struct rt_rq rt队列。
1.1普通进程的就绪队列struct cfs_rq（kernel/sched/sched.h）
/* CFS-related fields in a runqueue */
struct cfs_rq {
struct load_weight load;
unsigned int nr_running, h_nr_running; u64 exec_clock;
u64 min_vruntime;
#ifndef CONFIG_64BIT
u64 min_vruntime_copy;
#endif struct rb_root tasks_timeline;
struct rb_node *rb_leftmost; /*
* 'curr' points to currently running entity on this cfs_rq.
* It is set to NULL otherwise (i.e when none are currently running).
*/
struct sched_entity *curr, *next, *last, *skip; #ifdef CONFIG_SCHED_DEBUG
unsigned int nr_spread_over;
#endif #ifdef CONFIG_SMP
/*
* CFS Load tracking
* Under CFS, load is tracked on a per-entity basis and aggregated up.
* This allows for the description of both thread and group usage (in
* the FAIR_GROUP_SCHED case).
*/
unsigned long runnable_load_avg, blocked_load_avg;
atomic64_t decay_counter;
u64 last_decay;
atomic_long_t removed_load; #ifdef CONFIG_FAIR_GROUP_SCHED
/* Required to track per-cpu representation of a task_group */
u32 tg_runnable_contrib;
unsigned long tg_load_contrib; /*
* h_load = weight * f(tg)
*
* Where f(tg) is the recursive weight fraction assigned to
* this group.
*/
unsigned long h_load;
u64 last_h_load_update;
struct sched_entity *h_load_next;
#endif /* CONFIG_FAIR_GROUP_SCHED */
#endif /* CONFIG_SMP */ #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.
*/
int on_list;
struct list_head leaf_cfs_rq_list;
struct task_group *tg; /* group that "owns" this runqueue */ #ifdef CONFIG_CFS_BANDWIDTH
int runtime_enabled;
u64 runtime_expires;
s64 runtime_remaining; u64 throttled_clock, throttled_clock_task;
u64 throttled_clock_task_time;
int throttled, throttle_count;
struct list_head throttled_list;
#endif /* CONFIG_CFS_BANDWIDTH */
#endif /* CONFIG_FAIR_GROUP_SCHED */
};
struct cfs_rq
cfs_rq就绪队列是以红黑树的形式来组织调度实体。第12行tasks_timeline成员就是红黑树的树根。第13行rb_leftmost指向了红黑树最左边的左孩子（下一个可调度的实体）。第19行curr指向当前正运行的实体，next指向将被唤醒的进程，last指向唤醒next进程的进程，next和last用法后边会提到。第55行rq指向了该cfs_rq就绪队列所属的rq队列。
1.2实时进程的就绪队列struct rt_rq（kernel/sched/sched.h）
/* Real-Time classes' related field in a runqueue: */
struct rt_rq {
struct rt_prio_array active;
unsigned int 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_queued; int rt_throttled;
u64 rt_time;
u64 rt_runtime;
/* Nests inside the rq lock: */
raw_spinlock_t rt_runtime_lock; #ifdef CONFIG_RT_GROUP_SCHED
unsigned long rt_nr_boosted; struct rq *rq;
struct task_group *tg;
#endif
};
struct rt_rq
2.调度实体（include/linux/sched.h）
2.1普通进程的调度实体sched_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;
u64 prev_sum_exec_runtime;
u64 nr_migrations;
#ifdef CONFIG_SCHEDSTATS
struct sched_statistics statistics;
#endif
#ifdef CONFIG_FAIR_GROUP_SCHED
int depth;
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
#ifdef CONFIG_SMP
/* Per-entity load-tracking */
struct sched_avg avg;
#endif
};
每个进程描述符中均包含一个该结构体变量，内核使用该结构体来将普通进程组织到采用完全公平调度策略的就绪队列中（struct rq中的cfs队列中，上边提到过），该结构体有两个作用，一是包含有进程调度的信息（比如进程的运行时间，睡眠时间等等，调度程序参考这些信息决定是否调度进程），二是使用该结构体来组织进程，第3行的struct rb_node类型结构体变量run_node是红黑树节点，因此struct sched_entity调度实体将被组织成红黑树的形式，同时意味着普通进程也被组织成红黑树的形式。第18-25行是和组调度有关的成员，需要开启组调度。第20行parent顾名思义指向了当前实体的上一级实体，后边再介绍。第22行的cfs_rq指向了该调度实体所在的就绪队列。第24行my_q指向了本实体拥有的就绪队列（调度组），该调度组（包括组员实体）属于下一个级别，和本实体不在同一个级别，该调度组中所有成员实体的parent域指向了本实体，这就解释了上边的parent，此外，第19行depth代表了此队列（调度组）的深度，每个调度组都比其parent调度组深度大1。内核依赖my_q域实现组调度。
2.2实时进程的调度实体 sched_rt_entity
struct sched_rt_entity {
struct list_head run_list;
unsigned long timeout;
unsigned long watchdog_stamp;
unsigned int time_slice;
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
};
该结构体和上个结构体是类似的，只不过用来组织实时进程，实时进程被组织到struct rq中的rt队列中，上边有提到。每个进程描述符中也包含一个该结构体。该结构体中并未包含struct rb_node类型结构体变量，而在第1行出现了struct list_head类型结构体变量run_list，因此可以看出实时进程的就绪队列是双向链表形式，而不是红黑数的形式。
3.调度类（kernel/sched/sched.h）
struct sched_class {
const struct sched_class *next;
void (*enqueue_task) (struct rq *rq, struct task_struct *p, int flags);
void (*dequeue_task) (struct rq *rq, struct task_struct *p, int flags);
void (*yield_task) (struct rq *rq);
bool (*yield_to_task) (struct rq *rq, struct task_struct *p, bool preempt);
void (*check_preempt_curr) (struct rq *rq, struct task_struct *p, int flags);
/*
* It is the responsibility of the pick_next_task() method that will
* return the next task to call put_prev_task() on the @prev task or
* something equivalent.
*
* May return RETRY_TASK when it finds a higher prio class has runnable
* tasks.
*/
struct task_struct * (*pick_next_task) (struct rq *rq,
struct task_struct *prev);
void (*put_prev_task) (struct rq *rq, struct task_struct *p);
#ifdef CONFIG_SMP
int (*select_task_rq)(struct task_struct *p, int task_cpu, int sd_flag, int flags);
void (*migrate_task_rq)(struct task_struct *p, int next_cpu);
void (*post_schedule) (struct rq *this_rq);
void (*task_waking) (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
void (*set_curr_task) (struct rq *rq);
void (*task_tick) (struct rq *rq, struct task_struct *p, int queued);
void (*task_fork) (struct task_struct *p);
void (*task_dead) (struct task_struct *p);
void (*switched_from) (struct rq *this_rq, struct task_struct *task);
void (*switched_to) (struct rq *this_rq, struct task_struct *task);
void (*prio_changed) (struct rq *this_rq, struct task_struct *task,
int oldprio);
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_class的结构体类型，用来实现不同的调度策略，可以看到该结构体成员都是函数指针，这些指针指向的函数就是调度策略的具体实现，所有和进程调度有关的函数都直接或者间接调用了这些成员函数，来实现进程调度。此外，每个进程描述符中都包含一个指向该结构体类型的指针sched_class，指向了所采用的调度类。下面我们看下完全公平调度策略类的定义和初始化（kernel/sched/fair.c）。
const struct sched_class fair_sched_class;
定义了一个全局的调度策略变量。初始化如下：
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,
.yield_to_task = yield_to_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,
.migrate_task_rq = migrate_task_rq_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_from = switched_from_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
};
可以看到该结构体变量中函数成员很多，它们实现了不同的功能，待会用到时我们再做分析。
4.进程描述符task_struct（include/linux/sched.h）
struct task_struct {
volatile long state; /* -1 unrunnable, 0 runnable, >0 stopped */
.....
int on_rq;
int prio, static_prio, normal_prio;
unsigned int rt_priority;
const struct sched_class *sched_class;
struct sched_entity se;
struct sched_rt_entity rt;
#ifdef CONFIG_CGROUP_SCHED
struct task_group *sched_task_group;
#endif
struct sched_dl_entity dl;
.....
.....
unsigned int policy;
.....
.....
struct sched_info sched_info;
.....
.....
};
只列出了和进程调度有关的成员。第6行三个变量代表了普通进程的三个优先级，第7行的变量代表了实时进程的优先级。关于进程优先级的概念，大家可以看看《深入理解linux内核架构》这本书的进程管理章节。第8-10行就是我们上边提到的那些结构体在进程描述符中的定义。第17行的policy代表了当前进程的调度策略，内核给出了宏定义，它可以在这些宏中取值，关于详细的讲解还是去看《深入理解linux内核架构》这本书的进程管理部分。policy取了什么值，sched_class也应该取相应的调度类指针。
进程调度过程分析：
进程调度过程分为两部分，一是对进程信息进行修改，主要是修改和调度相关的信息，比如进程的运行时间，睡眠时间，进程的状态，cpu的负荷等等，二是进程的切换。和进程调度相关的所有函数中，只有schedule函数是用来进行进程切换的，其他函数都是用来修改进程的调度信息。schedule函数我们在前边的博文中已经探讨过了，这里不再分析。对于其他函数，我们将按照其功能，逐类来分析。
1.scheduler_tick（kernel/sched/core.c ）
void scheduler_tick(void)
{
int cpu = smp_processor_id();
struct rq *rq = cpu_rq(cpu);
struct task_struct *curr = rq->curr; sched_clock_tick(); raw_spin_lock(&rq->lock);
update_rq_clock(rq);
curr->sched_class->task_tick(rq, curr, );
update_cpu_load_active(rq);
raw_spin_unlock(&rq->lock); perf_event_task_tick(); #ifdef CONFIG_SMP
rq->idle_balance = idle_cpu(cpu);
trigger_load_balance(rq);
#endif
rq_last_tick_reset(rq);
}
该函数被时钟中断处理程序调用，将当前cpu的负载情况记载到运行队列struct rq的某些成员中，并更新当前进程的时间片。第3行获取当前的cpu号，第4行获取当前cpu的就绪队列（每个cpu有一个）rq，第5行从就绪队列中获取当前运行进程的描述符，第10行更新就绪队列中的clock和clock_task成员值，代表当前的时间，一般我们会用到clock_task。第11行进入当前进程的调度类的task_tick函数中，更新当前进程的时间片，不同调度类的该函数实现不同，待会我们分析下完全公平调度类的该函数。第12行更新就绪队列的cpu负载信息。第18行判断当前cpu是否是空闲的，是的话idle_cpu返回1，否则返回0。第19行挂起SCHED_SOFTIRQ软中断函数，去做周期性的负载平衡操作。第21行将最新的时钟滴答数jiffies存入就绪队列的last_sched_tick域中。再来看下task_tick_fair函数（kernel/sched/fair.c）：
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(cfs_rq, se, queued);
} if (numabalancing_enabled)
task_tick_numa(rq, curr); update_rq_runnable_avg(rq, );
}
如果某个进程的调度类采用完全公平调度类的话，那么上个函数scheduler_tick第11行所执行的task_tick函数指针，就指向了本函数。可以回头看看完全公平调度对象的初始化，第24行的赋值语句.task_tick = task_tick_fair。回到本函数，第4行获取当前进程的普通调度实体，将指针存放到se中，第6-8行遍历当前调度实体的上一级实体，以及上上一级实体，以此类推，然后在entity_tick函数中更新调度实体的运行时间等信息。在这里用循环来遍历的原因是当开启了组调度后，调度实体的parent域就存储了它的上一级节点，该实体和它parent指向的实体不是同一级别，因此使用循环就把从当前级别（组）到最顶层的级别遍历完了；如果未选择组支持，则循环只执行一次，仅对当前调度实体进行更新。下面看下entity_tick的代码（kernel/sched/fair.c）：
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); /*
* Ensure that runnable average is periodically updated.
*/
update_entity_load_avg(curr, );
update_cfs_rq_blocked_load(cfs_rq, );
update_cfs_shares(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 if (cfs_rq->nr_running > )
check_preempt_tick(cfs_rq, curr);
}
在该函数中对调度实体（进程）的运行时间等信息进行更新。第7行update_curr函数对当前进程的运行时间进行更新，随后分析。 第21行如果传进来的参数queued不为0的话，当前进程会被无条件设置重新调度标志（允许被抢占了）。第33-34行如果当前cfs_rq队列等待调度的进程数量大于1，那么就执行check_preempt_tick函数检查当前进程的时间片是否用完，用完的话就需要调度别的进程来运行（具体来说，如果当前进程“真实时间片”用完，该函数给当前进程设置need_resched标志，然后schedule程序就可以重新在就绪队列中调度新的进程），下面分析update_curr函数（kernel/sched/fair.c）：
static void update_curr(struct cfs_rq *cfs_rq)
{
struct sched_entity *curr = cfs_rq->curr;
u64 now = rq_clock_task(rq_of(cfs_rq));
u64 delta_exec; if (unlikely(!curr))
return; delta_exec = now - curr->exec_start;
if (unlikely((s64)delta_exec <= ))
return; curr->exec_start = now; schedstat_set(curr->statistics.exec_max,
max(delta_exec, curr->statistics.exec_max)); curr->sum_exec_runtime += delta_exec;
schedstat_add(cfs_rq, exec_clock, delta_exec); curr->vruntime += calc_delta_fair(delta_exec, curr);
update_min_vruntime(cfs_rq); 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);
} account_cfs_rq_runtime(cfs_rq, delta_exec);
}
该函数是更新进程运行时间最核心的一个函数。第3行获取当前的调度实体，第4行从就绪队列rq的clock_task成员中获取当前时间，存入now中，该成员我们在scheduler_tick函数中提到过。第10行用当前时间减去进程在上次时钟中断tick中的开始时间得到进程运行的时间间隔，存入delta_exec中。第14行当前时间又成为进程新的开始时间。第19行将进程运行的时间间隔delta_exec累加到调度实体的sum_exec_runtime成员中，该成员代表进程到目前为止运行了多长时间。第20行将进程运行的时间间隔delta_exec也累加到公平调度就绪队列cfs_rq的exec_clock成员中。第22行calc_delta_fair函数很关键，它将进程执行的真实运行时间转换成虚拟运行时间，然后累加到调度实体的vruntime域中，进程的虚拟时间非常重要，完全公平调度策略就是依赖该时间进行调度。关于进程的真实时间和虚拟时间的概念，以及它们之间的转换算法，文章的后面会提到，详细的内容大家可以看看《深入理解linux内核架构》的进程管理章节。第23行更新cfs_rq队列中的最小虚拟运行时间min_vruntime，该时间是就绪队列中所有进程包括当前进程的已运行的最小虚拟时间，只能单调递增，待会我们分析update_min_vruntime函数，该函数比较重要。第25-30行，如果调度单位是进程的话（不是组），会更新进程描述符中的运行时间。第33行更新cfs_rq队列的剩余运行时间，并计算出期望运行时间，必要的话可以对进程重新调度。下面我们先分析update_min_vruntime函数，然后分析calc_delta_fair函数（kernel/sched/fair.c）：
static void update_min_vruntime(struct cfs_rq *cfs_rq)
{
u64 vruntime = cfs_rq->min_vruntime; if (cfs_rq->curr)
vruntime = cfs_rq->curr->vruntime; if (cfs_rq->rb_leftmost) {
struct sched_entity *se = rb_entry(cfs_rq->rb_leftmost,
struct sched_entity,
run_node); if (!cfs_rq->curr)
vruntime = se->vruntime;
else
vruntime = min_vruntime(vruntime, se->vruntime);
} /* ensure we never gain time by being placed backwards. */
cfs_rq->min_vruntime = max_vruntime(cfs_rq->min_vruntime, vruntime);
#ifndef CONFIG_64BIT
smp_wmb();
cfs_rq->min_vruntime_copy = cfs_rq->min_vruntime;
#endif
}
每个cfs_rq队列均有一个min_vruntime成员，装的是就绪队列中所有进程包括当前进程已运行的虚拟时间中最小的那个时间。本函数来更新这个时间。第5-6行如果当前有进程正在执行，将当前进程已运行的虚拟时间保存在vruntime变量中。第8-17行如果就绪队列中有下一个要被调度的进程（由rb_leftmost指针指向），则进入if体，第13-16行从当前进程和下个被调度进程中，选择最小的已运行虚拟时间，保存到vruntime中。第20行从当前队列的min_vruntime域和vruntime变量中，选最大的保存到队列的min_vruntime域中，完成更新。其实第13-17行是最关键的，保证了队列的min_vruntime域中存放的是就绪队列中最小的虚拟运行时间，而第20行的作用仅仅是保证min_vruntime域中的值单调递增，没有别的含义了。队列中的min_vruntime成员非常重要，用于在睡眠进程被唤醒后以及新进程被创建好时，进行虚拟时间补偿或者惩罚，后面会分析到。
static inline u64 calc_delta_fair(u64 delta, struct sched_entity *se)
{
if (unlikely(se->load.weight != NICE_0_LOAD))
delta = __calc_delta(delta, NICE_0_LOAD, &se->load); return delta;
}
第3行判断当前进程nice值是否为0，如果是的话，直接返回真实运行时间delta（nice0级别的进程真实运行时间和虚拟运行时间值相等）；如果不是的话，第4行将真实时间转换成虚拟时间。下面我们分析__calc_delta函数（kernel/sched/fair.c）：
static u64 __calc_delta(u64 delta_exec, unsigned long weight, struct load_weight *lw)
{
u64 fact = scale_load_down(weight);
int shift = WMULT_SHIFT; __update_inv_weight(lw); if (unlikely(fact >> )) {
while (fact >> ) {
fact >>= ;
shift--;
}
} /* hint to use a 32x32->64 mul */
fact = (u64)(u32)fact * lw->inv_weight; while (fact >> ) {
fact >>= ;
shift--;
} return mul_u64_u32_shr(delta_exec, fact, shift);
}
该函数执行了两种算法：要么是delta_exec * weight / lw.weight，要么是(delta_exec * (weight * lw->inv_weight)) >> WMULT_SHIFT。计算的结果就是转换后的虚拟时间。至此，scheduler_tick函数大致就分析完了，当然还有一些细节没有分析到，进程调度这块非常庞杂，要想把所有函数分析完非常耗费时间和精力，以后如果分析到的话，再慢慢补充。scheduler_tick函数主要更新进程的运行时间，包括物理时间和虚拟时间。
2.进程优先级设置的函数，进程的优先级和调度关系密切，通过上边分析可以看到，计算进程的虚拟运行时间要用到优先级，优先级决定进程权重，权重决定进程虚拟时间的增加速度，最终决定进程可运行时间的长短。权重越大的进程可以执行的时间越长。从effective_prio函数开始（kernel/sched/core.c）：
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:
*/
if (!rt_prio(p->prio))
return p->normal_prio;
return p->prio;
}
该函数在进程创建时或者在用户的nice系统调用中都会被调用到，来设置进程的活动优先级（进程的三种优先级：活动优先级prio，静态优先级static_prio，普通优先级normal_prio），该函数设计的有一定技巧性，函数的返回值是用来设置进程的活动优先级，但是在函数体中也把进程的普通优先级设置了。第3行设置进程的普通优先级，随后分析normal_prio函数。第9-11行，通过进程的活动优先级可以判断出该进程是不是实时进程，如果是实时进程，则执行11行，返回p->prio，实时进程的活动优先级不变。否则返回p->normal_prio，这说明普通进程的活动优先级等于它的普通优先级。下面我们看看normal_prio函数（kernel/sched/core.c）：
static inline int normal_prio(struct task_struct *p)
{
int prio; if (task_has_dl_policy(p))
prio = MAX_DL_PRIO-;
else if (task_has_rt_policy(p))
prio = MAX_RT_PRIO- - p->rt_priority;
else
prio = __normal_prio(p);
return prio;
}
该函数用来设置进程的普通优先级。第5行判断当前进程是不是空闲进程，是的话设置进程的普通优先级为-1（-1是空闲进程的优先级），否则的话第7行判断进程是不是实时进程，是的话设置实时进程的普通优先级为0-99（数字越小优先级越高），可以看到这块减去了p->rt_priority，比较奇怪，这是因为实时进程描述符的rt_priority成员中事先存放了它自己的优先级（数字也是0-99，但在这里数字越大，优先级越高），因此往p->prio中倒换的时候，需要处理一下，MAX_RT_PRIO值为100，因此MAX_RT_PRIO--（0，99）就倒换成了（99，0），这仅仅是个小技巧。如果当前进程也不是实时进程（说明是普通进程喽），则第10行将进程的静态优先级存入prio中，然后返回（也就是说普通进程的普通优先级等于其静态优先级）。
总结下，总共有三种进程：空闲进程，实时进程，普通进程；每种进程都包含三种优先级：活动优先级，普通优先级，静态优先级。空闲进程的普通优先级永远-1，实时进程的普通优先级是根据p->rt_priority设定的（0-99），普通进程的普通优先级是根据其静态优先级设定的（100-139）。
3.进程权重设置的函数，上边我们提到，进程的优先级决定进程的权重。权重进而决定进程运行时间的长短。我们先分析和权重相关的数据结构。
struct load_weight（include/linux/sched.h）
struct load_weight {
unsigned long weight;
u32 inv_weight;
};
每个进程描述符，调度实体，就绪对列中都包含一个该类型变量，用来保存各自的权重。成员weight中存放进程优先级所对应的权重。成员inv_weight中存放NICE_0_LOAD/weight的结果，这个结果乘以进程运行的时间间隔delta_exec就是进程运行的虚拟时间。因此引入权重就是为了计算进程的虚拟时间。在这里将中间的计算结果保存下来，后边就不用再计算了，直接可以用。
数组prio_to_weight[40]（kernel/sched/sched.h）
static const int prio_to_weight[] = {
/* -20 */ , , , , ,
/* -15 */ , , , , ,
/* -10 */ , , , , ,
/* -5 */ , , , , ,
/* 0 */ , , , , ,
/* 5 */ , , , , ,
/* 10 */ , , , , ,
/* 15 */ , , , , ,
};
该数组是普通进程的优先级和权重对应关系。数组元素是权重值，分别是优先级从100-139或者nice值从-20-+19所对应的权重值。nice值（-20-+19）是从用户空间看到的普通进程的优先级，和内核空间的优先级（100-139）一一对应。struct load_weight中的weight成员存放正是这些权重值。
中间结果数组prio_to_wmult[40] （kernel/sched/sched.h）
static const u32 prio_to_wmult[] = {
/* -20 */ , , , , ,
/* -15 */ , , , , ,
/* -10 */ , , , , ,
/* -5 */ , , , , ,
/* 0 */ , , , , ,
/* 5 */ , , , , ,
/* 10 */ , , , , ,
/* 15 */ , , , , ,
};
该数组元素就是上个数组元素被NICE_0_LOAD除的结果，一一对应。struct load_weight中的inv_weight成员存放正是这些值。
下边我们分析和权重设置相关的函数。从set_load_weight函数开始（kernel/sched/core.c）：
static void set_load_weight(struct task_struct *p)
{
int prio = p->static_prio - MAX_RT_PRIO;
struct load_weight *load = &p->se.load; /*
* SCHED_IDLE tasks get minimal weight:
*/
if (p->policy == SCHED_IDLE) {
load->weight = scale_load(WEIGHT_IDLEPRIO);
load->inv_weight = WMULT_IDLEPRIO;
return;
} load->weight = scale_load(prio_to_weight[prio]);
load->inv_weight = prio_to_wmult[prio];
}
该函数用来设置进程p的权重。第3行将进程p的静态优先级转换成数组下标（减去100，从100-139--->0-39）。第4行获取当前进程的调度实体中的权重结构体指针，存入load中。第9-12行，如果当前进程是空闲进程，则设置相应的权重和中间计算结果。第15-16行，设置实时进程和普通进程的权重和中间计算结果。
由于就绪队列中也包含权重结构体，所以也要对它们进行设置。使用以下函数（kernel/sched/fair.c）：
static inline void update_load_set(struct load_weight *lw, unsigned long w)
{
lw->weight = w;
lw->inv_weight = ;
}
该函数用来设置就绪队列的权重。
static inline void update_load_add(struct load_weight *lw, unsigned long inc)
{
lw->weight += inc;
lw->inv_weight = ;
}
当有进程加入就绪队列，使用该函数增加就绪队列的权重。
static inline void update_load_sub(struct load_weight *lw, unsigned long dec)
{
lw->weight -= dec;
lw->inv_weight = ;
}
当有进程从就绪队列移除时，使用该函数减少就绪队列的权重。就绪队列的load_weight.inv_weight成员总是0，因为不会使用到就绪队列的该域。
4.计算进程延迟周期的相关函数。进程的延迟周期指的是将所有进程执行一遍的时间。当就绪队列中的进程数量不超出规定的时候，内核有一个固定的延迟周期供调度使用，但是当进程数量超出规定以后，就需要对该固定延迟周期进行扩展（不然随着进程越多，每个进程分配的执行时间会越少）。下面看看sched_slice函数（kernel/sched/fair.c）：
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(slice, se->load.weight, load);
}
return slice;
}
直接看第18行，__calc_delta用来计算当前进程在延迟周期中可占的时间（相当于“时间片”，就是当前进程可用的时间）。__calc_delta函数很强大，记得前边在entity_tick函数中也调用过该函数（entity_tick--->update_curr--->calc_delta_fair--->__calc_delta），当时使用该函数是为了将进程运行过的物理时间（真实时间）转换成虚拟时间；而在此处，我们用它来计算当前进程在延迟周期中可占的时间（相当于“时间片”）。前边提过，__calc_delta中用到param1 * param2 / param3.weight这个公式（param代表该函数接收的参数），当param2的值固定不变（等于NICE_0_LOAD），param3（代表当前进程的权重）在变化时，该函数是用来转换真实时间和虚拟时间的；当param3（代表当前cfs_rq的权重，cfs_rq->load->weight）的值固定不变，param2在变化（代表当前进程的权重）时，该函数则是用来计算当前进程应该运行的时间。因此第18行计算结果slice就是当前进程应该运行的真实时间。下面再看一个函数sched_vslice（kernel/sched/fair.c）：
static u64 sched_vslice(struct cfs_rq *cfs_rq, struct sched_entity *se)
{
return calc_delta_fair(sched_slice(cfs_rq, se), se);
}
该函数用来将进程应该运行的真实时间转换成应该运行的虚拟时间，以供调度使用。可以看到该函数调用了cals_delta_fair来进行时间转换，前边已分析过，不再赘述。
5.选择下一个需要调度的进程。所使用的函数是pick_next_task_fair，代码如下（kernel/sched/fair.c）：
static struct task_struct *
pick_next_task_fair(struct rq *rq, struct task_struct *prev)
{
struct cfs_rq *cfs_rq = &rq->cfs;
struct sched_entity *se;
struct task_struct *p;
int new_tasks; again:
#ifdef CONFIG_FAIR_GROUP_SCHED
if (!cfs_rq->nr_running)
goto idle; if (prev->sched_class != &fair_sched_class)
goto simple; /*
* Because of the set_next_buddy() in dequeue_task_fair() it is rather
* likely that a next task is from the same cgroup as the current.
*
* Therefore attempt to avoid putting and setting the entire cgroup
* hierarchy, only change the part that actually changes.
*/ do {
struct sched_entity *curr = cfs_rq->curr; /*
* Since we got here without doing put_prev_entity() we also
* have to consider cfs_rq->curr. If it is still a runnable
* entity, update_curr() will update its vruntime, otherwise
* forget we've ever seen it.
*/
if (curr && curr->on_rq)
update_curr(cfs_rq);
else
curr = NULL; /*
* This call to check_cfs_rq_runtime() will do the throttle and
* dequeue its entity in the parent(s). Therefore the 'simple'
* nr_running test will indeed be correct.
*/
if (unlikely(check_cfs_rq_runtime(cfs_rq)))
goto simple; se = pick_next_entity(cfs_rq, curr);
cfs_rq = group_cfs_rq(se);
} while (cfs_rq); p = task_of(se); /*
* Since we haven't yet done put_prev_entity and if the selected task
* is a different task than we started out with, try and touch the
* least amount of cfs_rqs.
*/
if (prev != p) {
struct sched_entity *pse = &prev->se; while (!(cfs_rq = is_same_group(se, pse))) {
int se_depth = se->depth;
int pse_depth = pse->depth; if (se_depth <= pse_depth) {
put_prev_entity(cfs_rq_of(pse), pse);
pse = parent_entity(pse);
}
if (se_depth >= pse_depth) {
set_next_entity(cfs_rq_of(se), se);
se = parent_entity(se);
}
} put_prev_entity(cfs_rq, pse);
set_next_entity(cfs_rq, se);
} if (hrtick_enabled(rq))
hrtick_start_fair(rq, p); return p;
simple:
cfs_rq = &rq->cfs;
#endif if (!cfs_rq->nr_running)
goto idle; put_prev_task(rq, prev); do {
se = pick_next_entity(cfs_rq, NULL);
set_next_entity(cfs_rq, se);
cfs_rq = group_cfs_rq(se);
} while (cfs_rq); p = task_of(se); if (hrtick_enabled(rq))
hrtick_start_fair(rq, p); return p; idle:
new_tasks = idle_balance(rq);
/*
* Because idle_balance() releases (and re-acquires) rq->lock, it is
* possible for any higher priority task to appear. In that case we
* must re-start the pick_next_entity() loop.
*/
if (new_tasks < )
return RETRY_TASK; if (new_tasks > )
goto again; return NULL;
}
pick_next_task_fair
该函数会被赋给公平调度类的pick_next_task成员（.pick_next_task = pick_next_task_fair），在schedule函数中会调用该函数选择下一个需要调用的进程，然后进行进程切换。第11-12行如果当前就绪队列中的进程数量为0，则退出函数。第25-49行对所有的调度组进行遍历，从中选择下一个可调度的进程，而不只局限在当前队列的当前组。第26行获取当前调度实体，第34-37行如果存在一个当前调度实体（进程）并且正在运行，则更新进程的运行时间，否则就绪队列cfs_rq.curr置为null，表示当前无进程运行。第47行获取下一个调度实体，待会来分析该函数。第48行获取下个调度实体所拥有的就绪队列my_q（代表一个调度组），如果调度组非空，则进入下一次循环，在新的就绪队列（调度组）中挑选下一个可调度进程，直到某个实体没有自己的就绪队列为止（遍历完所有的调度组了）。退出循环后，可以发现此时的se是所遍历的最后一个调度组的下个可运行实体。第51行获取se对应的进程描述符，第58-77行，如果当前进程和下一个进程（se所对应的进程）不是同一个的话，则执行if体，第59行将当前进程的调度实体指针装入pse中，第61-72行如果当前进程和下一个调度的进程（se对应的进程）不属于同一调度组，则进入循环。否则，执行第75-76行，将当前进程放回就绪队列，将下个进程从就绪队列中拿出，这两个函数涉及到了就绪队列的出队和入队操作，我们在下边分析。第61-73的循环根据当前实体和下个调度实体的节点深度进行调整（同一个级别的进程才能切换）。下面看看pick_next_entity，put_prev_entity和set_prev_entity函数代码（kernel/sched/fair.c）：
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 */ /*
* Avoid running the skip buddy, if running something else can
* be done without getting too unfair.
*/
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) < )
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) < )
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) < )
se = cfs_rq->next; clear_buddies(cfs_rq, se); return se;
}
该函数选择下一个调度的实体。第4行将红黑树的最左边实体赋给left，第11-12行如果红黑树的最左边实体为空或者当前实体运行的虚拟时间小于下一个实体（继续当前的实体），把当前实体赋给left，实际上left指向的是下一个要执行的进程（该进程要么还是当前进程，要么是下一个进程），第14行将left赋给se，第20-33行如果se进程是需要跳过的进程（不能被调度），执行if体，如果se进程是当前进程，则选择红黑数最左的进程赋给second，否则se进程已经是最左的进程，就把next指向的进程赋给second（next指向的是刚刚被唤醒的进程），第32行将second再次赋给se，se是挑选出来的下个进程。第38-45，再次判断，要么把last指向的进程赋给se，要么把next指向进程赋给se，内核更倾向于把last赋给se，因为last是唤醒next进程的进程（一般就是当前进程），所以执行last就意味着不用切换进程，效率最高。第47行清理掉next和last域。第31，38，44行使用到的wakeup_preempt_entity函数我们在进程唤醒那块再分析。
static void put_prev_entity(struct cfs_rq *cfs_rq, struct sched_entity *prev)
{
/*
* If still on the runqueue then deactivate_task()
* was not called and update_curr() has to be done:
*/
if (prev->on_rq)
update_curr(cfs_rq); /* throttle cfs_rqs exceeding runtime */
check_cfs_rq_runtime(cfs_rq); check_spread(cfs_rq, prev);
if (prev->on_rq) {
update_stats_wait_start(cfs_rq, prev);
/* Put 'current' back into the tree. */
__enqueue_entity(cfs_rq, prev);
/* in !on_rq case, update occurred at dequeue */
update_entity_load_avg(prev, );
}
cfs_rq->curr = NULL;
}
该函数将当前调度实体放回就绪队列。第7-8行如果当前实体正在运行，更新其时间片。第17行将当前实体加入到就绪队列中，待会分析__enqueue_entity函数。第21行将就绪队列的curr域置为null，因为当前进程已经放回就绪队列了，就表示当前没有进程正在执行了，因此curr为空。
static void
set_next_entity(struct cfs_rq *cfs_rq, struct sched_entity *se)
{
/* 'current' is not kept within the tree. */
if (se->on_rq) {
/*
* Any task has to be enqueued before it get to execute on
* a CPU. So account for the time it spent waiting on the
* runqueue.
*/
update_stats_wait_end(cfs_rq, se);
__dequeue_entity(cfs_rq, se);
} update_stats_curr_start(cfs_rq, se);
cfs_rq->curr = se;
#ifdef CONFIG_SCHEDSTATS
/*
* Track our maximum slice length, if the CPU's load is at
* least twice that of our own weight (i.e. dont track it
* when there are only lesser-weight tasks around):
*/
if (rq_of(cfs_rq)->load.weight >= *se->load.weight) {
se->statistics.slice_max = max(se->statistics.slice_max,
se->sum_exec_runtime - se->prev_sum_exec_runtime);
}
#endif
se->prev_sum_exec_runtime = se->sum_exec_runtime;
}
该函数将下一个被调度实体从就绪队列中取出。第12行实现取出操作，待会分析该函数。第16行将取出的调度实体指针赋给就绪队列的curr，那么此时就有了正在运行的进程了。后边的代码更新当前进程的时间统计信息。
6.就绪队列的入队和出队操作（kernel/sched/fair.c）。
static void __enqueue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se)
{
struct rb_node **link = &cfs_rq->tasks_timeline.rb_node;
struct rb_node *parent = NULL;
struct sched_entity *entry;
int leftmost = ; /*
* Find the right place in the rbtree:
*/
while (*link) {
parent = *link;
entry = rb_entry(parent, struct sched_entity, run_node);
/*
* We dont care about collisions. Nodes with
* the same key stay together.
*/
if (entity_before(se, entry)) {
link = &parent->rb_left;
} else {
link = &parent->rb_right;
leftmost = ;
}
} /*
* Maintain a cache of leftmost tree entries (it is frequently
* used):
*/
if (leftmost)
cfs_rq->rb_leftmost = &se->run_node; rb_link_node(&se->run_node, parent, link);
rb_insert_color(&se->run_node, &cfs_rq->tasks_timeline);
}
该函数实现入队操作。第3行获取就绪队列中红黑树的根节点，将树根指针保存在link中。第12行parent暂时指向树根。第13行获得树根节点的调度实体，保存在entry中。第18-22行，比较要入队的实体中的已运行虚拟时间和树根实体中的该信息，如果前者小的话，就要插入到树的左子树上（link指向树根的左孩子，再次进入循环，类似于递归），否则就要插入到树的右子树上（同上）。这块就将进程的调度策略展现的淋漓尽致：根据进程已运行的虚拟时间来决定进程的调度，红黑树的左子树比右子树要先被调度，已运行的虚拟时间越小的进程越在树的左侧。第30-31行，如果入队的实体最终被插在左孩子上（该入队实体仍是就绪队列上最靠前的实体，下次就会被调用），那么就要让就绪队列的rb_leftmost指向入队实体。rb_leftmost指针始终指向下次要被调度的实体（进程）。最后两行要给红黑数重新着色。
static void __dequeue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se)
{
if (cfs_rq->rb_leftmost == &se->run_node) {
struct rb_node *next_node; next_node = rb_next(&se->run_node);
cfs_rq->rb_leftmost = next_node;
} rb_erase(&se->run_node, &cfs_rq->tasks_timeline);
}
该函数实现出队操作。第3行判断要出队的实体是不是红黑树最左侧的孩子（rb_leftmost所指向的），如果不是的话，第10行直接删除该出队实体。否则执行if体，第6行找到出队实体的下一个实体（中序遍历的下一个节点，也就是当出队实体删除后，最左边的孩子），赋给next_node。第7行让rb_leftmost指向next_node。在删除掉要出队实体后，下一个需要被调度的实体也就设置好了。
7.睡眠进程被唤醒后抢占当前进程。当某个资源空出来后，等待该资源的进程就会被唤醒，唤醒后也许就要抢占当前进程，因此这块的函数也需要分析（kernel/sched/core.c）。
static int
try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
{
unsigned long flags;
int cpu, success = ; /*
* If we are going to wake up a thread waiting for CONDITION we
* need to ensure that CONDITION=1 done by the caller can not be
* reordered with p->state check below. This pairs with mb() in
* set_current_state() the waiting thread does.
*/
smp_mb__before_spinlock();
raw_spin_lock_irqsave(&p->pi_lock, flags);
if (!(p->state & state))
goto out; success = ; /* we're going to change ->state */
cpu = task_cpu(p); if (p->on_rq && ttwu_remote(p, wake_flags))
goto stat; #ifdef CONFIG_SMP
/*
* If the owning (remote) cpu is still in the middle of schedule() with
* this task as prev, wait until its done referencing the task.
*/
while (p->on_cpu)
cpu_relax();
/*
* Pairs with the smp_wmb() in finish_lock_switch().
*/
smp_rmb(); p->sched_contributes_to_load = !!task_contributes_to_load(p);
p->state = TASK_WAKING; if (p->sched_class->task_waking)
p->sched_class->task_waking(p); cpu = select_task_rq(p, p->wake_cpu, SD_BALANCE_WAKE, wake_flags);
if (task_cpu(p) != cpu) {
wake_flags |= WF_MIGRATED;
set_task_cpu(p, cpu);
}
#endif /* CONFIG_SMP */ ttwu_queue(p, cpu);
stat:
ttwu_stat(p, cpu, wake_flags);
out:
raw_spin_unlock_irqrestore(&p->pi_lock, flags); return success;
}
该函数会唤醒参数p指定的进程，将进程加入就绪队列中等待调度。第15行判断p进程的状态码和传进来的状态码是否一致，不一致的话函数结束（不一致则说明进程等待的条件未满足）。第19行获取要唤醒进程p原先所在的cpu号。第37行设置要唤醒进程p的状态为TASK_WAKING。第40行执行进程p的调度类中的task_waking函数，该函数指针指向了task_waking_fair函数，该函数主要是对睡眠进程的已运行虚拟时间进行补偿，待会分析该函数。第42行为刚唤醒进程p选择一个合适的就绪队列供其加入，返回就绪队列所在的cpu号。第43行如果进程p所在的原先cpu和为它挑选的cpu不是同一个的话，第45行更改进程p的cpu号。
void wake_up_new_task(struct task_struct *p)
{
unsigned long flags;
struct rq *rq; raw_spin_lock_irqsave(&p->pi_lock, flags);
#ifdef CONFIG_SMP
/*
* Fork balancing, do it here and not earlier because:
* - cpus_allowed can change in the fork path
* - any previously selected cpu might disappear through hotplug
*/
set_task_cpu(p, select_task_rq(p, task_cpu(p), SD_BALANCE_FORK, ));
#endif /* Initialize new task's runnable average */
init_task_runnable_average(p);
rq = __task_rq_lock(p);
activate_task(rq, p, );
p->on_rq = ;
trace_sched_wakeup_new(p, true);
check_preempt_curr(rq, p, WF_FORK);
#ifdef CONFIG_SMP
if (p->sched_class->task_woken)
p->sched_class->task_woken(rq, p);
#endif
task_rq_unlock(rq, p, &flags);
}
该函数用来唤醒刚创建好的进程，而上个函数是用来唤醒睡眠中的进程。第13行为将唤醒的进程p设置合适的cpu。第17行设置进程p的可运行时间长度（类似“时间片”），第19行activate_task函数主要将唤醒的进程p加入就绪队列,并更新队列的时间,初始化进程p的时间等，该函数中的调用关系大致为activate_task->enqueue_task->enqueue_task_fair(p->sched_class->enqueue_task)->enqueue_entity。第22行check_preempt_curr函数调用了check_preempt_wakeup函数，来检查唤醒进程是否能抢占当前进程，下面分析该函数（kernel/sched/fair.c）。
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 scale = cfs_rq->nr_running >= sched_nr_latency;
int next_buddy_marked = ; if (unlikely(se == pse))
return; /*
* This is possible from callers such as move_task(), in which we
* unconditionally check_prempt_curr() after an enqueue (which may have
* lead to a throttle). This both saves work and prevents false
* next-buddy nomination below.
*/
if (unlikely(throttled_hierarchy(cfs_rq_of(pse))))
return; if (sched_feat(NEXT_BUDDY) && scale && !(wake_flags & WF_FORK)) {
set_next_buddy(pse);
next_buddy_marked = ;
} /*
* We can come here with TIF_NEED_RESCHED already set from new task
* wake up path.
*
* Note: this also catches the edge-case of curr being in a throttled
* group (e.g. via set_curr_task), since update_curr() (in the
* enqueue of curr) will have resulted in resched being set. This
* prevents us from potentially nominating it as a false LAST_BUDDY
* below.
*/
if (test_tsk_need_resched(curr))
return; /* Idle tasks are by definition preempted by non-idle tasks. */
if (unlikely(curr->policy == SCHED_IDLE) &&
likely(p->policy != SCHED_IDLE))
goto preempt; /*
* do not preempt non-idle tasks (their preemption
* is driven by the tick):
*/
if (unlikely(p->policy != SCHED_NORMAL) || !sched_feat(WAKEUP_PREEMPTION))
return; find_matching_se(&se, &pse);
update_curr(cfs_rq_of(se));
BUG_ON(!pse);
if (wakeup_preempt_entity(se, pse) == ) {
/*
* Bias pick_next to pick the sched entity that is
* triggering this preemption.
*/
if (!next_buddy_marked)
set_next_buddy(pse);
goto preempt;
} return; preempt:
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);
}
第21-24行，如果开启了NEXT_BUDDY并且唤醒的进程不是新进程（而是睡眠进程），那么第22行就将cfs_rq的next指针指向唤醒的进程，并且设置标记。第36行如果当前进程可以被抢占，函数直接返回。否则，第40-42行如果当前进程是空闲进程并且被唤醒的进程不是空闲进程，则跳到preempt处，设置need_resched标志，完成抢占设置。第48行，如果被唤醒进程是空闲进程或者批处理进程，直接返回，这些进程不能抢占别的进程。第51行如果当前进程和被唤醒进程不在同一级别（同一个调度组），则寻找它们的祖先parent，把它们调整到同一级别，才能进行虚拟运行时间的比较，进而决定能否抢占。第54行，对当前进程和被唤醒进程的虚拟运行时间进行比较，可以抢占的话（唤醒进程的虚拟时间小于当前进程）执行if体，跳到preempt处完成抢占。否则所有都不满足的话，当前进程不能被抢占，执行第64行返回，随后分析该函数。第80-81行如果开启了LAST_BUDDY，就将cfs_rq的last指针指向唤醒进程的进程。在pick_next_entity函数中，next和last所指的进程会先于就绪队列的left进程被选择。下面分析下wakeup_preempt_entity函数（kernel/sched/fair.c）。
static int
wakeup_preempt_entity(struct sched_entity *curr, struct sched_entity *se)
{
s64 gran, vdiff = curr->vruntime - se->vruntime; if (vdiff <= )
return -; gran = wakeup_gran(curr, se);
if (vdiff > gran)
return ; return ;
}
该函数是要保证在se实体在抢占curr实体时，curr实体已经运行过一段时间（具体而言，物理时间1ms），第9行wakeup_gran函数是将sysctl_sched_wakeup_granularity的值（1ms）转换成se实体的虚拟时间，保存在gran中，第10行比较vdiff和gran大小，实际上是比较curr->vruntime 和 se->vruntime+gran，因此就是想让curr实体多执行gran时间，才能被抢占。
最后我们再分析下 try_to_wake_up函数中第40行遗留的那个函数指针task_waking，该指针指向了task_waking_fair函数，代码如下（kernel/sched/fair.c）：
static void task_waking_fair(struct task_struct *p)
{
struct sched_entity *se = &p->se;
struct cfs_rq *cfs_rq = cfs_rq_of(se);
u64 min_vruntime; #ifndef CONFIG_64BIT
u64 min_vruntime_copy; do {
min_vruntime_copy = cfs_rq->min_vruntime_copy;
smp_rmb();
min_vruntime = cfs_rq->min_vruntime;
} while (min_vruntime != min_vruntime_copy);
#else
min_vruntime = cfs_rq->min_vruntime;
#endif se->vruntime -= min_vruntime;
record_wakee(p);
}
该函数完成对睡眠进程的虚拟时间补偿。考虑到睡眠时间长时间没有运行，因此第19行从唤醒进程se的已运行虚拟时间中减去就绪队列的最小虚拟时间，做点补偿，让其可以多运行一点时间。
8.新进程的处理函数（kernel/sched/fair.c）：
static void task_fork_fair(struct task_struct *p)
{
struct cfs_rq *cfs_rq;
struct sched_entity *se = &p->se, *curr;
int this_cpu = smp_processor_id();
struct rq *rq = this_rq();
unsigned long flags; raw_spin_lock_irqsave(&rq->lock, flags); update_rq_clock(rq); cfs_rq = task_cfs_rq(current);
curr = cfs_rq->curr; /*
* Not only the cpu but also the task_group of the parent might have
* been changed after parent->se.parent,cfs_rq were copied to
* child->se.parent,cfs_rq. So call __set_task_cpu() to make those
* of child point to valid ones.
*/
rcu_read_lock();
__set_task_cpu(p, this_cpu);
rcu_read_unlock(); update_curr(cfs_rq); if (curr)
se->vruntime = curr->vruntime;
place_entity(cfs_rq, se, ); if (sysctl_sched_child_runs_first && curr && entity_before(curr, se)) {
/*
* Upon rescheduling, sched_class::put_prev_task() will place
* 'current' within the tree based on its new key value.
*/
swap(curr->vruntime, se->vruntime);
resched_task(rq->curr);
} se->vruntime -= cfs_rq->min_vruntime; raw_spin_unlock_irqrestore(&rq->lock, flags);
}
该函数在do_fork--->copy_process函数中调用，用来设置新创建进程的虚拟时间信息。第5行获取当前的cpu号，第23行为新进程设置该cpu号。第29行将当前进程（父进程）的虚拟运行时间拷贝给新进程（子进程）。第30行的place_entity函数完成新进程的“时间片”计算以及虚拟时间惩罚，之后将新进程加入红黑数中，待会分析。第32行如果设置了子进程先于父进程运行的标志并且当前进程不为空且当前进程已运行的虚拟时间比新进程小，则执行if体，第37行交换当前进程和新进程的虚拟时间（新进程的虚拟时间变小，就排在了红黑树的左侧，当前进程之前，下次就能被调度），第38行设置重新调度标志。第41行给新进程的虚拟运行时间减去队列的最小虚拟时间来做一点补偿（因为在上边的place_entity函数中给新进程的虚拟时间加了一次min_vruntime，所以在这里要减去），再来看看place_entity函数（kernel/sched/fair.c）：
static void
place_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int initial)
{
u64 vruntime = cfs_rq->min_vruntime; /*
* The 'current' period is already promised to the current tasks,
* however the extra weight of the new task will slow them down a
* little, place the new task so that it fits in the slot that
* stays open at the end.
*/
if (initial && sched_feat(START_DEBIT))
vruntime += sched_vslice(cfs_rq, se); /* sleeps up to a single latency don't count. */
if (!initial) {
unsigned long thresh = sysctl_sched_latency; /*
* Halve their sleep time's effect, to allow
* for a gentler effect of sleepers:
*/
if (sched_feat(GENTLE_FAIR_SLEEPERS))
thresh >>= ; vruntime -= thresh;
} /* ensure we never gain time by being placed backwards. */
se->vruntime = max_vruntime(se->vruntime, vruntime);
}
该函数完成新进程的“时间片”计算和虚拟时间惩罚，并且将新进程加入就绪队列。第4行将就绪队列的min_vruntime值存入vruntime中，第12-13行，如果initial标志为1的话（说明当前计算的是新进程的时间），将计算出的新进程的虚拟时间片累加到vruntime中，累加到原因是调度系统要保证先把就绪队列中的所有的进程执行一遍之后才能执行新进程，一会具体解释。第16-17行，如果当前计算的不是新进程（睡眠的进程），把一个延迟周期的长度sysctl_sched_latency（6ms）赋给thresh，第24行thresh减半，第26行睡眠进程的虚拟运行时间减去减半后的thresh，因为睡眠进程好长时间未运行，因此要进行虚拟时间补偿，把它已运行的虚拟时间减小一点，使得它能多运行一会。第30行将设置好的虚拟时间保存到进程调度实体的vruntime域。下面解释下为什么要对新进程进行虚拟时间惩罚，其实原因只有一个，就是调度系统要保证将就绪队列中现有的进程执行一遍之后再执行新进程，那么就必须使新进程的 vruntime=cfs_rq->min_vruntime+新进程的虚拟时间片，才能使得新进程插入到红黑树的右边，最后参与调度，不然无法保证所有进程在新进程之前执行。
最后，分析下和调度相关的这些函数执行的时机
前面在介绍这些函数的时候，基本上都提到了会在哪里调用这些函数，最后，我们再系统总结一下：
进程调度分为两个部分：一是进程信息的修改，二是进程切换。进程切换只有一个函数schedule，schedule的运行时机我们最后分析。其它函数的运行时机如下：
1.scheduler_tick函数是在每个时钟中断中被调用，用来更新当前进程运行的时间。
2.effective_prio函数是在创建一个新进程或者用户使用nice系统调用设置进程的优先级时调用，用来设置进程的在内核中优先级（不同于nice值）。
3.set_load_weight函数也是在创建新进程或者用户使用nice()设置进程的优先级时调用，用来设置进程的权重。该函数和2中的函数其实是配套使用的，当设置或者改变了一个进程的优先级时，要么就要为这个进程设置或者改变该优先级对应的权重。
4.sched_slice函数主要是在scheduler_tick->...->check_preempt_tick中调用（别的地方也有），因此也是每个时钟周期调用一次，用来计算当前进程应该执行的“时间片”，进而才能判断进程是否已经超出它的时间片，超出的话就要设置抢占标志，切换别的进程。
5.pick_next_task_fair函数schedule中调用，用来选择下一个要被调度的进程，然后才能切换进程。它的执行时机就是schedule的执行时机，随后分析。
6.__enqueue_entity/__dequeue_entity函数是在需要入就绪队列或者出就绪队列的地方被调用，因此使用它们的地方较多，比如schedule中调用（间接调用），就不一一分析了。
7.try_to_wake_up/wake_up_new_task函数，前者在进程所等待的资源满足时被调用（一般在中断内调用）；后者是在创建好新进程后被调用。都是用来唤醒进程的，前者唤醒睡眠进程，后者唤醒新进程并将进程加入就绪队列。
8.task_fork_fair函数也是在新进程被创建好后调用，用来设置新进程的“时间片”等信息，设置好以后新进程就可以被唤醒了。所以该函数和wake_up_new_task函数调用时机是一样的。
最后，我们分析schedule函数的调用时机。该函数是唯一实现进程切换的函数。
在分析schedule函数的调用时机之前，我们先为大家介绍下“内核控制路径“的概念。所谓内核控制路径，就是由中断或者异常引出的执行路径，说白了，执行中断或者异常处理程序时就处在内核控制路径中，此时代表的也是当前进程。内核控制路径可以嵌套（也就是可以嵌套中断），但是无论嵌套多少，最终都要回到当前进程中，也就是说要从内核控制路径中返回，不可以在内核控制路径中进行进程切换（因此中断处理程序中不允许调用能引起进程睡眠的函数）。说到底，内核要么处在进程中，要么处在内核控制路径中（其实内核控制路径也代表当前进程，因为其有特殊性，所以我们单列出来谈），不会再有别的什么路径了。那么进程切换的时机，或者说schedule函数被调用的时机，也就只可能发生于上述两种路径中。那么，1.当在进程中调用schedule函数时（就是ULK这本书上说的直接调用），表明当前进程因为等待资源或者别的原因需要挂起，主动放弃使用cpu，调用schedule函数切换到别的进程中；2.当在内核控制路径中调用schedule函数时（上边说过了，内核控制路径中不允许切换进程），其实是在内核控制路径返回进程时调用（该时机就是ULK上说的延迟调用），说明有更重要的进程等待执行，需要抢占当前进程，因此在中断处理程序/异常处理程序返回时都要去检查当前进程能否被抢占，可以抢占的话就要调用schedule函数进行进程切换，包括从系统调用中返回用户空间时也要检查（这是统一的，因为系统调用本身也是异常，因此从系统调用中返回相当于从异常处理程序中返回，通过系统调用进入到内核态也可以说是内核控制路径，但是一般不这么叫）当前进程的抢占标志，能发生抢占的话就要去调用schedule函数。至此，进程切换的时机就分析完了。很好记的，要么是进程上下文发生进程切换（主动调用schedule），要么是从中断返回时切换，因此每次中断返回时必须要检查能否发生抢占，包括从系统调用返回也属于这种情形。
至此，进程调度机制咱们就分析完了（其实只分析了CFS调度）。实时进程调度以后再分析！
参考书籍：《深入理解linux内核》
《深入理解linux内核架构》
参考文章：blog.csdn.net/wudongxu/article/details/8574737