CFS中一些调度参数的实现原理

在cfs调度中有这么几个常用的参数：

• sysctl_sched_latency：表示一段时间内，sched_entity肯定会被调度到一次，也就是一个sched_entity调度的最大的延时，2.6.35.13内核中默认是6ms。
• sysctl_sched_min_granularity：表示调度的最小粒度，如果调度的时间间隔小于这个时间段，内核是不会挑选其他sched_entity进行调度，这个2.6.35.13内核中默认是2ms。
• nr_latency：表示在上面的那段最大调度延迟中，最多处理的sched_entity。

上面的这些参数，书上都是这么说的，说下个人的理解。

• 对于sysctl_sched_latency参数是调度的最大延迟，在cfs中，调度根据sched_entity的vruntime来选择对应的调度单位，对于不同的sched_entity的load并不相同，cfs_rq中记录了running的sched_entity的总load，可以根据sched_entity的load占总cfs_rqload的比重来分配调度时间，内核中就是通过统计sched_entity的运行时间来确定是否运行的时间够了，如果够了，那么要重新选择vruntime最小的单位进行调度，这样才能保证在sysctl_sched_latency让所有的running的sched_entity运行一次。
• sysctl_sched_min_granularity变量比较好理解，sched_tick中，应该判断当前运行的sched_entity的运行时间是否超过了sysctl_sched_min_granularity，如果未超过，就表示当前sched_entity还需要继续运行,如果超过了，可能会考虑让wakeup的sched_entity抢占调度。
• nr_latency是延迟时间段能最大处理任务的数量，在这段时间点有可能切换进程，这几个时间点就是当一个sched_entity运行时间超过了sysctl_sched_min_granularity，那么就可以考虑切换进程了，这样如果每次都切换进程，那么延迟时间段内最大处理任务的数量就是nr_latency

        nr_latency=sysctl_sched_latency/sysctl_sched_min_granularity

    sched_entity的理论运行时间是按照cfs_rq中的总的load和当前sched_entity的load来平分sysctl_sched_latency的。

static u64 sched_slice(struct cfs_rq *cfs_rq, struct sched_entity *se)
{
        u64 slice = __sched_period(cfs_rq->nr_running + !se->on_rq);//获得总的运行时间段，这个时间有可能比sysctl_sched_latency要大

        for_each_sched_entity(se) {
                struct load_weight *load;
                struct load_weight lw;

                cfs_rq = cfs_rq_of(se);
                load = &cfs_rq->load;//获得cfs_rq总的load

                if (unlikely(!se->on_rq)) { //如果se不再rq中，说明rq中的load不包括se的load，这个时候需要把se的load加到rq上
                        lw = cfs_rq->load;

                        update_load_add(&lw, se->load.weight);
                        load = &lw;
                }
                //根据slice是一轮调度总的时间，load是rq总的load，se->load.weight是se的load，这样就可以算出load占总load的百分比，然后体现在平分slice上
                slice = calc_delta_mine(slice, se->load.weight, load);
        }
        return slice;
}

    __sched_period函数是计算调度一轮所有的sched_entity所需要的时间

static u64 __sched_period(unsigned long nr_running)
{
        u64 period = sysctl_sched_latency;
        unsigned long nr_latency = sched_nr_latency;

        if (unlikely(nr_running > nr_latency)) {
                period = sysctl_sched_min_granularity;
                period *= nr_running;
        }

        return period;
}

    如果当前可以运行的sched_entity的个数超过了 nr_latency，那么认为 在sysctl_sched_latency的一段时间内调度所有的sched_entity时间不够，这时候需要按照nr_running的个树，扩大 sysctl_sched_latency。时钟周期中断函数会调用scheduler_tick，最终调用了cfs中的check_preempt_tick，检测当前调度的sched_entity是否需要被抢占，需要调度其他的sched_entity。

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);
   //获得当前进程的理想运行时间，按照sched_entity的load和rq的总load平分 sysctl_sched_latency所得的时间
        delta_exec = curr->sum_exec_runtime – curr->prev_sum_exec_runtime;
//sum_exec_runtime是sched_entity自fork出来的运行时间，prev表示截止到上次切换进程的运行时间，所以这两个时间之差就是切换到当前进程后，该进程所运行的时间
        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);
//如果curr被放在了cfs_rq的next或者last位，就应该清除这个引用。
                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) {
    //给刚wakeup的进程一个机会，避免使他等太久的时间未得到调度（由于当前进程的理想运行时间过长），其实在wakeup一个进程 的时候已经有机会让wakeup的进程先调度，可能由于vruntime和curr的vruntime相距不大，没有得到运行的机会，这里再给新wakeup的进程一次被调度的机会。
                struct sched_entity *se = __pick_next_entity(cfs_rq);
                s64 delta = curr->vruntime - se->vruntime;

                if (delta > ideal_runtime)
                        resched_task(rq_of(cfs_rq)->curr);
        }
}

    在切换sched_entity的时候会记录当前sched_entity的 prev_sum_exec_runtime，表示当前的 prev_sum_exec_runtime=sum_exec_runtime,至于最后pick出next sched_entity后为什么要判断和当前vruntime之差大于理想运行时间，才能重新调度新的进程，猜测一下，对于一个刚刚wakeup的进程，sleep了足够长的时间了，一个sysctl_sched_latency就可以让curr进程的vruntime增加ideal_runtime(nice=0,优先级低的增加的会更快，优先级高的增加的会相对慢一些，需要多个sysctl_sched_latency的时间)，那么可以认为curr的vruntime和wakeup的vruntime差距超过了ideal_runtime，curr相对于sleep进程已经执行了足够长的时间了，这时候即使curr在这一轮调度没有达到ideal_runtime的时间，那么也该需要新唤醒的进程轮到调度了，所以这个时候需要resched了，上面的分析只是个人一些猜测。望大牛多加指点。