部分cfs调度器的tuning参数

最近看了rhel6.2内核的cfs进程调度代码，作为学习总结，把相关的部分tuning参数做了下整理，摘录如下。

* sched_child_runs_first
  当创建子进程时，保证子进程会在父进程之前运行。在创建子进程时，首先会
  将子进程的虚拟运行时间设置为min_vruntime，这个min_vruntime大约等于当
  前运行队列中所有进程的虚拟运行时间的最小值，然后，看sched_features中
  是否设置了START_DEBIT位，如果这一位被设置了，表示要给新创建的进程的
  虚拟运行时间再增加一些，这样会让它的运行时间向后延迟，以防进程通过不
  停的fork来不停的获得cpu时间。当设置完子进程的虚拟运行时间之后，会判
  断sched_child_runs_first是不是设置为1，如果是的话就比较父进程和子进
  程的虚拟运行时间，如果父进程的虚拟运行时间比较小的话,就交换父子进程
  的虚拟运行时间，这样子进程就会在父进程之前运行了。

* sched_min_granularity_ns
  这个值在两个地方会用到。一个是计算nice值为0的进程运行一次需要的时间。
  如果进程的总数大于sched_latency/sched_min_granularity个，就用
  sched_min_granularity_ns的值乘以进程的个数，将乘积作为nice值为0的进程
  调度一次运行的时间。然后每个进程会以此为基准，按照自己的优先级来计算
  自己被调度一次的运行时间。。另一个用途是判断当前进程是否要被调度下
  CPU的时候。如果当前进程的执行时间已经超过了它被调度一次所允许的执行时
  间（其实也可以说是时间片,尽管cfs声称自己没有时间片），那么必然要被调
  度下CPU。但如果它的时间片还没到期，在判断它的运行时间是不是比
  sched_min_granularity_ns小。如果是的话，那么就肯定不把它调度下CPU，如
  果进程的运行时间比sched_min_granularity_ns大的话，就用当前进程的虚拟
  运行时间减去runqueue上虚拟运行时间最小的进程的虚拟运行时间，如果差值
  比当前进程的时间片（这个时间片确实不是传统的时间片，总是随当前负载的
  状况变化）还大的话，那么当前进程也会被调度下CPU。

* sched_latency_ns
  计算nice值为0的进程运行一次所需的时间时用到。。如果进程总数小于等于
  sched_latency/sched_min_granularity个，就将sched_latency_ns作为nice
  值为0的进程运行一次的时间，否则按照前面介绍sched_min_granularity_ns
  时的方法计算。

* sched_wakeup_granularity_ns
  判断一个进程是否可以抢占当前进程时用到。如果该进程的虚拟运行时间比当
  前进程的虚拟运行时间大，那么肯定不能抢占。如果该进程的虚拟运行时间比
  当前进程的虚拟运行时间小的话，就计算出两者之差vdiff。如果vdiff大于一
  定的范围的话，就可以抢占，否则不可以抢占。
  sched_wakeup_granularity_ns就是用来确定这个范围的。它表示一个nice值
  为0的进程要抢占当前进程，它的虚拟运行时间需要被当前进程的虚拟运行时
  间小多少，其他优先级的进程以此为基准进行调整，优先级越高的进程，需要
  的差值越小。

* sched_tunable_scaling
  当内核试图调整sched_min_granularity，sched_latency和
  sched_wakeup_granularity这三个值的时候所使用的更新方法，0为不调整，1
  为按照cpu个数以2为底的对数值进行调整，2为按照cpu的个数进行线性比例的
  调整。

* sched_features
  每个bit都表示调度器的一个特性是否打开。在sched_features.h文件中记录
  了全部的特性。

* sched_migration_cost
  用来判断一个进程是不是cache hot的。如果进程的运行时间小于
  sched_migration_cost就认为是cache host的，在多CPU之间进行负载均衡的
  时候不会转移cache hot的进程。

* sched_nr_migrate
  在多CPU情况下进行负载均衡时，一次最多移动sched_nr_migrate个进程到另
  一个CPU上。

关于linux内核抢占的一点思考

偶然看了一下rhel6.2系统内核中处理软中断的内核线程，很意外的产生了一点困
惑，这是ksoftirqd线程的主循环:

1    while (!kthread_should_stop()) {
2        preempt_disable();
3        if (!local_softirq_pending()) {
4            preempt_enable_no_resched();
5            schedule();
6            preempt_disable();
7        }
8
9        __set_current_state(TASK_RUNNING);
10
11        while (local_softirq_pending()) {
12            /* Preempt disable stops cpu going offline.
13               If already offline, we'll be on wrong CPU:
14               don't process */
15            if (cpu_is_offline((long)__bind_cpu))
16                goto wait_to_die;
17            do_softirq();
18            preempt_enable_no_resched();
19            cond_resched();
20            preempt_disable();
21            rcu_sched_qs((long)__bind_cpu);
22        }
23        preempt_enable();
24        set_current_state(TASK_INTERRUPTIBLE);
25    }

假设在23行执行完之后，有人试图唤醒这个线程，此时，线程还处于
TASK_RUNNING的状态，所以什么都不会发生。然后，在第24行，线程将自己设置
成了TASK_INTERRUPT状态，在执行第24行之后，线程被抢占了，那么，它在
TASK_INTERRUPT状态下被抢占，除非再次有人唤醒它，它岂不是再也返回不了了？
这样，不就丢失了一次唤醒吗？

这让我很困扰，于是，我自己写了个测试程序，启动一个内核线程，然后让它把
自己设置成TASK_INTERRUPTIBLE的状态，再进行几秒钟的忙循环。正常来说，执
行几秒钟的忙循环的话，肯定会被抢占了。然后我看它还能不能再被调度上来。
结果意外的发现rhel6的内核编译时是配置成不可抢占的（后来发现rhel5也这
样），我那个单核的虚拟机一执行忙循环就hang住。于是，重新编译了一个可抢
占的内核跑起来。结果发现，执行忙循环后，还是能被调度上来的。但如果我不
执行忙循环，而是调用schedule()函数，那么，除非被唤醒，否则就不能再被调
度上来了。

用systemtap跟踪了一下我的内核线程进入schedule()函数时的一些信息，结果
发现如果我主动调用schedule()函数，在进入schedule()函数时，thread_info
中的preempt_count的值是0x00000005，而如果在执行忙循环时被抢占调用
schedule函数时，preempt_count的值是0x10000005。这个最高位1在内核中被定
义为PREEMPT_ACTIVE。

原来，每当在抢占点上执行schedule函数时，这个标志会被设置，比如，从中断
返回时，调用：
retint_kernel
-> preempt_schedule_irq
   -> schedule

在preempt_schedule_irq函数中，就会调用这几行代码：

        add_preempt_count(PREEMPT_ACTIVE);
        local_irq_enable();
        schedule();
        local_irq_disable();
        sub_preempt_count(PREEMPT_ACTIVE);

设置PREEMPT_ACTIVE后，再调用schedule()函数，然后再清除PREEMPT_ACTIVE标
志。

而在schedule()函数中，有这样一段代码：

    if (prev->state && !(preempt_count() & PREEMPT_ACTIVE)) {
        if (unlikely(signal_pending_state(prev->state, prev)))
            prev->state = TASK_RUNNING;
        else
            deactivate_task(rq, prev, DEQUEUE_SLEEP);
        switch_count = &prev->nvcsw;
    }

prev就是当前要被调度下cpu的进程。prev->state为0表示TASK_RUNNING的状态。
如果进程的状态不是TASK_RUNNING并且PREEMPT_ACTIVE标志没有被设置，再判断进程是否有pending的信号，如果有，就把进程状态设置成TASK_RUNNING状态，
如果没有pending的信号，就把进程从RUNNING的进程队列里拿下来。

因此，逻辑关系是这样的：
如果PREEMPT_ACTIVE被设置了，说明进程是由于内核抢占被调度下CPU的，这时不
把它从RUNNING的队列里移除，如果进程不是由于内核抢占被调度下来的，看它
有没有未处理的信号，如果有的话，也不把它从RUNNING的队列里移除。只有再
上述两种情况都为假的情况下，进程才会被从RUNNING的队列里移除。

这就解释了为什么内核线程把自己设置成TASK_INTERRUPTIBLE状态之后，只要不
是主动调用schedule()函数，而是被抢占调度下cpu的，它就还会获得机会运行。