Linux cpuidle framework(4)_menu governor
menu governor的主要任务就转化为两个：1. 根据系统的运行情况，预测CPU将在C state中停留的时间（简称predicted_us）；2. 借助pm qos framework，获取系统当前的延迟容忍度（简称latency_req）。
1. 前言
本文以menu governor为例，进一步理解cpuidle framework中governor的概念，并学习governor的实现方法。
在当前的kernel中，有2个governor，分别为ladder和menu（蜗蜗试图理解和查找，为什么会叫这两个名字，暂时还没有答案）。ladder在periodic timer tick system中使用，menu在tickless system中使用。
现在主流的系统，出于电源管理的考量，大多都是tickless system。另外，menu governor会利用pm qos framework（蜗蜗会在后续的文章中分析），在选择策略中加入延迟容忍度（Latency tolerance）的考量。因此本文选取menu governor作为分析对象，至于ladder，就不再分析了。
注：有关periodic timer tick和tickless的知识，可参考本站时间子系统的系列文章。
2. 背后的思考
本节的内容，主要来源于drivers/cpuidle/governors/menu.c中的注释。
governor的主要职责，是根据系统的运行情况，选择一个合适idle state（在kernel的标准术语中，也称作C state）。具体的算法，需要基于下面两点考虑：
1）切换的代价
进入C state的目的，是节省功耗，但CPU在C state和normal state之间切换，是要付出功耗上面的代价的。这最终会体现在idle state的target_residency字段上。
idle driver在注册idle state时，要非常明确state切换的代价，基于该代价，CPU必须在idle state中停留超过一定的时间（target_residency）才是划算的。
因此governor在选择C state时，需要预测出CPU将要在C state中的停留时间，并和备选idle state的target_residency字段比较，选取满足“停留时间 > target_residency”的state。
2）系统的延迟容忍程度
备选的的C state中，功耗和退出延迟是一对不可调和的矛盾，电源管理的目标，是在保证延迟在系统可接受的范围内的情况下，尽可能的节省功耗。
idle driver在注册idle state时，会提供两个信息：CPU在某个state下的功耗（power_usage）和退出该state的延迟（exit_latency）。那么如果知道系统当前所能容忍的延迟（简称latency_req），就可以在所有exit_latency小于latency_req的state中，选取功耗最小的那个。
因此，governor算法就转换为获取系统当前的latency_req，而这正是pm qos的特长。
基于上面的考量，menu governor的主要任务就转化为两个：1. 根据系统的运行情况，预测CPU将在C state中停留的时间（简称predicted_us）；2. 借助pm qos framework，获取系统当前的延迟容忍度（简称latency_req）。
任务1，menu governor从如下几个方面去达成：
前面讲过，menu governor用于tickless system，简化处理，menu将“距离下一个tick来临的时间（由next timer event测量，简称next_timer_us）”作为基础的predicted_us。
当然，这个基础的predicted_us是不准确的，因为在这段时间内，随时都可能产生除next timer event之外的其它wakeup event。为了使预测更准确，有必要加入一个校正因子（correction factor），该校正因子基于过去的实际predicted_us和next_timer_us之间的比率，例如，如果wakeup event都是在预测的next timer event时间的一半时产生，则factor为0.5。另外，为了更精确，menu使用动态平均的factor。
另外，对不同范围的next_timer_us，correction factor的影响程度是不一样的。例如期望50ms和500ms的next timer event时，都是在10ms时产生了wakeup event，显然对500ms的影响比较大。如果计算平均值时将它们混在一起，就会对预测的准确性产生影响，所以计算correction factor的数据时，需要区分不同级别的next_timer_us。同时，系统是否存在io wait，对factor的敏感度也不同。基于这些考虑，menu使用了一组factor（12个），分别用于不同next_timer_us、不同io wait的场景下的的校正。
最后，在有些场合下，next_timer_us的预测是完全不正确的，如存在固定周期的中断时（音频等）。这时menu采用另一种不同的预测方式：统计过去8次停留时间的标准差（stand deviation），如果小于一定的门限值，则使用这8个停留时间的平均值，作为预测值。
任务2，延迟容忍度（latency_req）的估算，menu综合考虑了两种因素，如下：
1）由pm qos获得的，系统期望的，CPU和DMA的延迟需求。这是一个硬性指标。
2）基于这样一个经验法则：越忙的系统，对系统延迟的要求越高，结合任务1中预测到的停留时间（predicted_us），以及当前系统的CPU平均负荷和iowaiters的个数（get_iowait_load函数获得），算出另一个延迟容忍度，计算公式（这是一个经验公式）为：
predicted_us / (1 + 2 * loadavg +10 * iowaiters)
这个公式反映的是退出延迟和预期停留时间之间的比例，loadavg和iowaiters越大，对退出延迟的要求就越高奥。最后，latency_req的值取上面两个估值的最小值。
3. 代码分析
理解menu governor背后的思考之后，再去看代码，就比较简单了。
3.1 初始化
首先，在init代码中，调用cpuidle_register_governor，注册menu_governor，如下：
1: static struct cpuidle_governor menu_governor = {
2: .name = "menu",
3: .rating = 20,
4: .enable = menu_enable_device,
5: .select = menu_select,
6: .reflect = menu_reflect,
7: .owner = THIS_MODULE,
8: };
9:
10: /**
11: * init_menu - initializes the governor
12: */
13: static int __init init_menu(void)
14: {
15: return cpuidle_register_governor(&menu_governor);
16: }
17:
18: postcore_initcall(init_menu);
由menu_governor变量可知，该governor的名字为“menu”，rating为20，共提供了enable、select、reflect三个API。
3.2 enable API
enable API负责governor运行前的准备动作，由menu_enable_device实现：
1: static int menu_enable_device(struct cpuidle_driver *drv,
2: struct cpuidle_device *dev)
3: {
4: struct menu_device *data = &per_cpu(menu_devices, dev->cpu);
5: int i;
6:
7: memset(data, 0, sizeof(struct menu_device));
8:
9: /*
10: * if the correction factor is 0 (eg first time init or cpu hotplug
11: * etc), we actually want to start out with a unity factor.
12: */
13: for(i = 0; i < BUCKETS; i++)
14: data->correction_factor[i] = RESOLUTION * DECAY;
15:
16: return 0;
17: }
由代码可知，主要任务是初始化在私有数据结构（struct menu_device）中保存的correction_factor。struct menu_device的定义如下：
1: struct menu_device {
2: int last_state_idx;
3: int needs_update;
4:
5: unsigned int next_timer_us;
6: unsigned int predicted_us;
7: unsigned int bucket;
8: unsigned int correction_factor[BUCKETS];
9: unsigned int intervals[INTERVALS];
10: int interval_ptr;
11: };
last_state_idx，记录了上一次进入的C state；
needs_update，每次从C state返回时，kernel（kernel\sched\idle.c）会调用governor的reflect接口，以便有机会让governor考虑这一次state切换的结果（如更新统计信息）。对menu而言，它的reflect接口会设置needs_update标志，并在下一次select时，更新状态，具体行为可参考后面的描述；
next_timer_us、predicted_us，可参考第2章中的有关说明；
correction_factor，保存校正因子的数组，因子的个数为BUCKETS（当前代码为12）；
bucket，指明select state时所使用的因子（当前的校正因子）；
intervals、interval_ptr，可参考第2章中的描述，用于计算停留时间的标准差，当前代码使用了8个停留时间（INTERVALS）。
3.2 select接口
governor的核心API，根据系统的运行情况，选择一个合适的C state。由menu_select接口实现，逻辑如下：
1: /**
2: * menu_select - selects the next idle state to enter
3: * @drv: cpuidle driver containing state data
4: * @dev: the CPU
5: */
6: static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev)
7: {
8: struct menu_device *data = this_cpu_ptr(&menu_devices);
9: int latency_req = pm_qos_request(PM_QOS_CPU_DMA_LATENCY);
10: int i;
11: unsigned int interactivity_req;
12: unsigned long nr_iowaiters, cpu_load;
13:
14: if (data->needs_update) {
15: menu_update(drv, dev);
16: data->needs_update = 0;
17: }
18:
19: data->last_state_idx = CPUIDLE_DRIVER_STATE_START - 1;
20:
21: /* Special case when user has set very strict latency requirement */
22: if (unlikely(latency_req == 0))
23: return 0;
24:
25: /* determine the expected residency time, round up */
26: data->next_timer_us = ktime_to_us(tick_nohz_get_sleep_length());
27:
28: get_iowait_load(&nr_iowaiters, &cpu_load);
29: data->bucket = which_bucket(data->next_timer_us, nr_iowaiters);
30:
31: /*
32: * Force the result of multiplication to be 64 bits even if both
33: * operands are 32 bits.
34: * Make sure to round up for half microseconds.
35: */
36: data->predicted_us = div_round64((uint64_t)data->next_timer_us *
37: data->correction_factor[data->bucket],
38: RESOLUTION * DECAY);
39:
40: get_typical_interval(data);
41:
42: /*
43: * Performance multiplier defines a minimum predicted idle
44: * duration / latency ratio. Adjust the latency limit if
45: * necessary.
46: */
47: interactivity_req = data->predicted_us / performance_multiplier(nr_iowaiters, cpu_load);
48: if (latency_req > interactivity_req)
49: latency_req = interactivity_req;
50:
51: /*
52: * We want to default to C1 (hlt), not to busy polling
53: * unless the timer is happening really really soon.
54: */
55: if (data->next_timer_us > 5 &&
56: !drv->states[CPUIDLE_DRIVER_STATE_START].disabled &&
57: dev->states_usage[CPUIDLE_DRIVER_STATE_START].disable == 0)
58: data->last_state_idx = CPUIDLE_DRIVER_STATE_START;
59:
60: /*
61: * Find the idle state with the lowest power while satisfying
62: * our constraints.
63: */
64: for (i = CPUIDLE_DRIVER_STATE_START; i < drv->state_count; i++) {
65: struct cpuidle_state *s = &drv->states[i];
66: struct cpuidle_state_usage *su = &dev->states_usage[i];
67:
68: if (s->disabled || su->disable)
69: continue;
70: if (s->target_residency > data->predicted_us)
71: continue;
72: if (s->exit_latency > latency_req)
73: continue;
74:
75: data->last_state_idx = i;
76: }
77:
78: return data->last_state_idx;
79: }
8行，取出per cpu的struct menu_device指针；
9行，调用pm_qos_request接口，获取系统CPU和DMA所能容忍的延迟。因为cpuidle状态下，运行任何的中断事件唤醒，因此这里只考虑了CPU和DMA；
14~17行，根据needs_update标志，调用menu_update，更新统计信息，具体可参考代码；
19行，last_state_idx会在menu_reflect中设置，并在menu_update中使用，此时已经没有用处了，初始化为无效值；
22~23行，如果pm qos要求的latency为0，则当前系统是一个比较苛刻的状态，不能进入idle状态，直接返回零。由此可以看出，software可以通过pm qos，控制系统是否可以进入idle状态，后续分析pm qos时，会再说明；
26~29行，调用timer子系统的接口，获取next_timer_us，调用sched提供de接口，获取iowaiter的个数以及CPU load信息，并利用next_timer_us和iowaiters信息，计算出需要使用哪一类校正因子。计算逻辑比较简单，详见代码；
36~39行，将next_timer_us乘以校正因子，得到predicted_us。计算时考虑了溢出、精度等情况；
40行，调用get_typical_interval接口，检查是否存在固定周期的情况，检查的逻辑就是计算8次停留时间的标准差，如果存在，则利用平均值更新predicted_us；
42~48，根据predicted_us和系统负荷情况（cpu load、iowaiters），估算另一个延迟容忍值，并和latency_req，取最小值；
51~78行，根据上面的信息，查找cpuidle device的所有state，选出一个符合条件的state，并返回该state在cpuidle state数组中的index。
3.3 reflect接口
menu的reflect接口比较简单，更新data->last_state_idx后，置位data->needs_update标志。可以多思考一下：为什么不直接在reflect中更新状态，而是到下一次select时再更新？这个问题留给读者吧。