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的。

1. static u64 sched_slice(struct cfs_rq *cfs_rq, struct sched_entity *se)
   
2. {
   
3. //获得总的运行时间段，这个时间有可能比sysctl_sched_latency要大
4.         u64 slice = __sched_period(cfs_rq->nr_running + !se->on_rq);
5. 
   
6.         for_each_sched_entity(se) {
   
7.                 struct load_weight *load;
   
8.                 struct load_weight lw;
   
9. 
   
10.                 cfs_rq = cfs_rq_of(se);
    
11.                 load = &cfs_rq->load;//获得cfs_rq总的load

//如果se不再rq中，说明rq中的load不包括se的load，这个时候需要把se的load加到rq上

1.                 if (unlikely(!se->on_rq)) { 
2.                         lw = cfs_rq->load;
   
3. 
   
4.                         update_load_add(&lw, se->load.weight);
   
5.                         load = &lw;
   
6.                 }
   
7.                 //根据slice是一轮调度总的时间，load是rq总的load，se->load.weight是se的load，
8. //这样就可以算出load占总load的百分比，然后体现在平分slice上
   
9.                 slice = calc_delta_mine(slice, se->load.weight, load); 
10.         } 
    
11.         return slice;
    
12. }

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

1. static u64 __sched_period(unsigned long nr_running)
   
2. {
   
3.         u64 period = sysctl_sched_latency;
   
4.         unsigned long nr_latency = sched_nr_latency;
   
5. 
   
6.         if (unlikely(nr_running > nr_latency)) {
   
7.                 period = sysctl_sched_min_granularity;
   
8.                 period *= nr_running;
   
9.         }
   
10. 
    
11.         return period;
    
12. }

    如果当前可以运行的sched_entity的个数超过了 nr_latency，

那么认为 在sysctl_sched_latency的一段时间内调度所有的sched_entity时间不够，

这时候需要按照nr_running的个树，扩大 sysctl_sched_latency。

时钟周期中断函数会调用scheduler_tick，最终调用了cfs中的check_preempt_tick，

检测当前调度的sched_entity是否需要被抢占，需要调度其他的sched_entity。

1. static void
   
2. check_preempt_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr)
   
3. {
   
4.         unsigned long ideal_runtime, delta_exec;
   
5. 
   
6.         ideal_runtime = sched_slice(cfs_rq, curr);
   
7.    //获得当前进程的理想运行时间，按照sched_entity的load和rq的总load平分 sysctl_sched_latency所得的时间
   
8.         delta_exec = curr->sum_exec_runtime – curr->prev_sum_exec_runtime;
   
9. //sum_exec_runtime是sched_entity自fork出来的运行时间，prev表示截止到上次切换进程的运行时间，
10. //所以这两个时间之差就是切换到当前进程后，该进程所运行的时间
    
11.         if (delta_exec > ideal_runtime) {
    
12.   //可以知道如果当前进程运行时间超过了理论运行时间，那么就应该让其它的进程运行了。
    
13.                 resched_task(rq_of(cfs_rq)->curr);
    
14.                 /*
    
15.                  * The current task ran long enough, ensure it doesn't get
    
16.                  * re-elected due to buddy favours.
    
17.                  */
    
18.                 clear_buddies(cfs_rq, curr);
    
19. //如果curr被放在了cfs_rq的next或者last位，就应该清除这个引用。
    
20.                 return;
    
21.         }
    
22. 
    
23.         /*
    
24.          * Ensure that a task that missed wakeup preemption by a
    
25.          * narrow margin doesn't have to wait for a full slice.
    
26.          * This also mitigates buddy induced latencies under load.
    
27.          */
    
28.         if (!sched_feat(WAKEUP_PREEMPT))
    
29.                 return;
    
30. 
    
31.         if (delta_exec < sysctl_sched_min_granularity)
    
32.   //如果进程运行的时间小于最小的进程切换的时间，那么是不需要切换进程的，切换的越频繁，成本开销也就越大
    
33.                 return;
    
34. 
    
35.         if (cfs_rq->nr_running > 1) {
    
36.     //给刚wakeup的进程一个机会，避免使他等太久的时间未得到调度（由于当前进程的理想运行时间过长），
37. //其实在wakeup一个进程 的时候已经有机会让wakeup的进程先调度，可能由于vruntime和curr的
38. //vruntime相距不大，没有得到运行的机会，这里再给新wakeup的进程一次被调度的机会。
    
39.                 struct sched_entity *se = __pick_next_entity(cfs_rq);
    
40.                 s64 delta = curr->vruntime - se->vruntime;
    
41. 
    
42.                 if (delta > ideal_runtime)
    
43.                         resched_task(rq_of(cfs_rq)->curr);
    
44.         }
    
45. }

    在切换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了，上面的分析只是个人一些猜测。望大牛多加指点。