linux 多核支持原理,linux在多核处理器上的负载均衡原理(2)

假如现在是 Core 3 在执行idle_balance，则先在domain 1里找最忙的group，找到第二忙的group是core 0(core 4不在domain 1里，所以不会找到它)，再从core 0里找最忙的runqueue(运行队列)，core 0就一个运行队列，所以直接就是它对应的runqueue了，然后从该runqueue里挪出几个任务到Core 3，这一层domain的均衡做完了。

接着是domain

1的父domain，即 cpu_domain，下图的domain 0：

这个domain 0包含了两个group，每个group对应一个chip，即每个group对应了4个core。

在domain 0找最繁忙的group，显然会找到Processor1 对应的group(因为core 4超忙)，那么继续在Processor 1里找最忙的runqueue，于是找到core 4，最后从core 4的runqueue里挑出几个任务挪到core 3,。

这样，整个系统8个核都基本平衡了。

也许有人要问，为什么是从子domain到父domain这样遍历，而不是倒过来，从父到子遍历呢？这是因为子domain通常都是在一个chip上，任务的很多数据在共享的L2 cache上，为了不让其失效，有必要尽量让任务保持在一个chip上。

也许还有人要问：如果core 3本来就是最忙的core，它如果运行idle_balance，会发生什么？答案是什么也不会发生。因为在find_busiest_group函数里，如果发现最忙的是“本CPU”，那么就直接返回NULL，也就不再做任何事。

那core 3岂不永远是最忙的了？呵呵，大家忘了，系统里总有闲的CPU(哪怕是相对比较闲)，它总会执行schedule()，就算它从不调用sleep从不睡眠，时钟中断也会迫使其进程切换，进而调用schedule，进而将繁忙CPU的任务揽一部分到自己身上。这样，谁最闲，谁早晚会从忙人身上揽活儿过来，所以忙人不会永远最忙，闲人也不会永远最闲，所以就平等，就均衡了。

再看try_to_wake_up()：

[kernel/sched.c --> try_to_wake_up()]

1398 static int try_to_wake_up(struct task_struct *p, unsigned int state, int sync)

1399 {

......

1417

1418     cpu = task_cpu(p);

1419     this_cpu = smp_processor_id();

1420

1421 #ifdef CONFIG_SMP

1422     if (unlikely(task_running(rq, p)))

1423         goto out_activate;

1424

1425     new_cpu = cpu;

1426

1427     schedstat_inc(rq, ttwu_cnt);

1428     if (cpu == this_cpu) {

1429         schedstat_inc(rq, ttwu_local);

1430         goto out_set_cpu;

1431     }

变量this_cpu和变量cpu有什么区别？变量this_cpu是实际运行这个函数的处理器(“目标处理器”)，而变量cpu是进程p在睡眠之前运行的处理器??为了方便我们暂且称之为“源处理器”。当然，这两个处理器也可能是同一个，比如进程p在处理器A上运行，然后睡眠，而运行try_to_wake_up的也是处理器A，其实这样就最好了，进程p在处理器A里cache的数据都不用动，直接让A运行p就行了??这就是1428行的逻辑。

如果this_cpu和cpu不是同一个处理器，那么代码继续：

1447     if (this_sd) {

1448         int idx = this_sd->wake_idx;

1449         unsigned int imbalance;

1450

1451         imbalance = 100 + (this_sd->imbalance_pct - 100) / 2;

1452

1453         load = source_load(cpu, idx);

1454         this_load = target_load(this_cpu, idx);

1455

1456         new_cpu = this_cpu; /* Wake to this CPU if we can */

1457

1458         if (this_sd->flags & SD_WAKE_AFFINE) {

1459             unsigned long tl = this_load;

1460             unsigned long tl_per_task;

1461

1462             tl_per_task = cpu_avg_load_per_task(this_cpu);

1463

1464             /*

1465              * If sync wakeup then subtract the (maximum possible)

1466              * effect of the currently running task from the load

1467              * of the current CPU:

1468              */

1469             if (sync)

1470                 tl -= current->load_weight;

1471

1472             if ((tl <= load &&

1473                 tl + target_load(cpu, idx) <= tl_per_task) ||

1474                 100*(tl + p->load_weight) <= imbalance*load) {

1475                 /*

1476                  * This domain has SD_WAKE_AFFINE and

1477                  * p is cache cold in this domain, and

1478                  * there is no bad imbalance.

1479                  */

1480                 schedstat_inc(this_sd, ttwu_move_affine);

1481                 goto out_set_cpu;

1482             }

1483         }

计算出“目标处理器”和“源处理器”各自的负载(

1453行和1454行)，再计算“目标处理器”上的每任务平均负载

tl_per_task，最后进行判断：如果“目标处理器”的负载小于“源处理器”的负载且两处理器负载相加都比 tl_per_task小的话，唤醒的进程转为“目标处理器”执行。还有一种情况就是1474行的判断，如果“目标处理器”的负载加上被唤醒的进程的负载后，还比“源处理器”的负载(乘以imbalance后)的小的话，也要把唤醒的进程转为“目标处理器”执行。如果两个因素都不满足，那还是由p进程原来呆的那个CPU(即”源处理器“)继续来处理吧。

有点儿绕，是吧？其实代码虽绕，用意是简单的：

1472行-1473行其实是这样一个用意：如果“目标处理器”的负载很小，小得即使把压力全给到“源处理器”上去也不会超过“源处理器”上的平均任务负载，那么这“目标处理器”的负载是真的很小，值得把p进程挪过来。

1474行的用意则是：如果我们真的把p进程挪到“目标处理器”以后，“目标处理器”的压力也不比“源处理器”大多少，所以，还是值得一挪。

说来说去，还是那个笨原则：把任务从最忙的CPU那儿转到很闲的CPU这儿。

我们已经看过了睡眠和醒来时的内核函数，那么软中断里的

run_rebalance_domains又干了些什么呢？其实也很简单，它调用了load_balance函数，而这个函数和load_balance_newidle实现上基本一样，就不累述了。