Chinaunix首页 | 论坛 | 博客
  • 博客访问: 698387
  • 博文数量: 31
  • 博客积分: 330
  • 博客等级: 一等列兵
  • 技术积分: 3004
  • 用 户 组: 普通用户
  • 注册时间: 2012-09-05 22:38
个人简介

java开发工程师,专注于内核源码,算法,数据结构。 qq:630501400

文章分类
文章存档

2014年(2)

2013年(22)

2012年(7)

分类: C/C++

2013-03-28 16:01:03

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_entityvruntime来选择对应的调度单位,对于不同的sched_entityload并不相同,cfs_rq中记录了runningsched_entity的总load,可以根据sched_entityload占总cfs_rqload的比重来分配调度时间,内核中就是通过统计sched_entity的运行时间来确定是否运行的时间够了,如果够了,那么要重新选择vruntime最小的单位进行调度,这样才能保证在sysctl_sched_latency让所有的runningsched_entity运行一次。
  • sysctl_sched_min_granularity变量比较好理解,sched_tick中,应该判断当前运行的sched_entity的运行时间是否超过了sysctl_sched_min_granularity,如果未超过,就表示当前sched_entity还需要继续运行,如果超过了,可能会考虑让wakeupsched_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_entityload来平分sysctl_sched_latency的。

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

  4.         for_each_sched_entity(se) {
  5.                 struct load_weight *load;
  6.                 struct load_weight lw;

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

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

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

    __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.         if (unlikely(nr_running > nr_latency)) {
  6.                 period = sysctl_sched_min_granularity;
  7.                 period *= nr_running;
  8.         }

  9.         return period;
  10. }

    如果当前可以运行的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.         ideal_runtime = sched_slice(cfs_rq, curr);
  6.    //获得当前进程的理想运行时间,按照sched_entity的load和rq的总load平分 sysctl_sched_latency所得的时间
  7.         delta_exec = curr->sum_exec_runtime – curr->prev_sum_exec_runtime;
  8. //sum_exec_runtime是sched_entity自fork出来的运行时间,prev表示截止到上次切换进程的运行时间,所以这两个时间之差就是切换到当前进程后,该进程所运行的时间
  9.         if (delta_exec > ideal_runtime) {
  10.   //可以知道如果当前进程运行时间超过了理论运行时间,那么就应该让其它的进程运行了。
  11.                 resched_task(rq_of(cfs_rq)->curr);
  12.                 /*
  13.                  * The current task ran long enough, ensure it doesn't get
  14.                  * re-elected due to buddy favours.
  15.                  */
  16.                 clear_buddies(cfs_rq, curr);
  17. //如果curr被放在了cfs_rq的next或者last位,就应该清除这个引用。
  18.                 return;
  19.         }

  20.         /*
  21.          * Ensure that a task that missed wakeup preemption by a
  22.          * narrow margin doesn't have to wait for a full slice.
  23.          * This also mitigates buddy induced latencies under load.
  24.          */
  25.         if (!sched_feat(WAKEUP_PREEMPT))
  26.                 return;

  27.         if (delta_exec < sysctl_sched_min_granularity)
  28.   //如果进程运行的时间小于最小的进程切换的时间,那么是不需要切换进程的,切换的越频繁,成本开销也就越大
  29.                 return;

  30.         if (cfs_rq->nr_running > 1) {
  31.     //给刚wakeup的进程一个机会,避免使他等太久的时间未得到调度(由于当前进程的理想运行时间过长),其实在wakeup一个进程 的时候已经有机会让wakeup的进程先调度,可能由于vruntime和curr的vruntime相距不大,没有得到运行的机会,这里再给新wakeup的进程一次被调度的机会。
  32.                 struct sched_entity *se = __pick_next_entity(cfs_rq);
  33.                 s64 delta = curr->vruntime - se->vruntime;

  34.                 if (delta > ideal_runtime)
  35.                         resched_task(rq_of(cfs_rq)->curr);
  36.         }
  37. }

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





阅读(6945) | 评论(0) | 转发(2) |
给主人留下些什么吧!~~