Linux cpuidle framework(4)_menu governor

最新推荐文章于 2024-02-29 05:30:00 发布

jacob

最新推荐文章于 2024-02-29 05:30:00 发布

阅读量562

点赞数

分类专栏：电源

电源专栏收录该内容

45 篇文章 13 订阅

订阅专栏

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，如下：

 
static struct cpuidle_governor menu_governor = { 
        .name =         "menu", 
        .rating =       20, 
        .enable =       menu_enable_device, 
        .select =       menu_select, 
        .reflect =      menu_reflect, 
        .owner =        THIS_MODULE, 
}; 
   
/** 
 * init_menu - initializes the governor 
 */ 
static int __init init_menu(void) 
{ 
        return cpuidle_register_governor(&menu_governor); 
} 
   
postcore_initcall(init_menu); 
 

由menu_governor变量可知，该governor的名字为“menu”，rating为20，共提供了enable、select、reflect三个API。

3.2 enable API

enable API负责governor运行前的准备动作，由menu_enable_device实现：

 
static int menu_enable_device(struct cpuidle_driver *drv, 
                                struct cpuidle_device *dev) 
{ 
        struct menu_device *data = &per_cpu(menu_devices, dev->cpu); 
        int i; 
   
        memset(data, 0, sizeof(struct menu_device)); 
   
        /* 
         * if the correction factor is 0 (eg first time init or cpu hotplug 
         * etc), we actually want to start out with a unity factor. 
         */ 
        for(i = 0; i < BUCKETS; i++) 
                data->correction_factor[i] = RESOLUTION * DECAY; 
   
        return 0; 
} 
 

由代码可知，主要任务是初始化在私有数据结构（struct menu_device）中保存的correction_factor。struct menu_device的定义如下：

 
struct menu_device { 
        int             last_state_idx; 
        int             needs_update; 
   
        unsigned int    next_timer_us; 
        unsigned int    predicted_us; 
        unsigned int    bucket; 
        unsigned int    correction_factor[BUCKETS]; 
        unsigned int    intervals[INTERVALS]; 
        int             interval_ptr; 
}; 
 

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接口实现，逻辑如下：

 
/** 
 * menu_select - selects the next idle state to enter 
 * @drv: cpuidle driver containing state data 
 * @dev: the CPU 
 */ 
static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev) 
{ 
    struct menu_device *data = this_cpu_ptr(&menu_devices); 
    int latency_req = pm_qos_request(PM_QOS_CPU_DMA_LATENCY); 
    int i; 
    unsigned int interactivity_req; 
    unsigned long nr_iowaiters, cpu_load; 
   
    if (data->needs_update) { 
        menu_update(drv, dev); 
        data->needs_update = 0; 
    } 
   
    data->last_state_idx = CPUIDLE_DRIVER_STATE_START - 1; 
   
    /* Special case when user has set very strict latency requirement */ 
    if (unlikely(latency_req == 0)) 
        return 0; 
   
    /* determine the expected residency time, round up */ 
    data->next_timer_us = ktime_to_us(tick_nohz_get_sleep_length()); 
   
    get_iowait_load(&nr_iowaiters, &cpu_load); 
    data->bucket = which_bucket(data->next_timer_us, nr_iowaiters); 
   
    /* 
     * Force the result of multiplication to be 64 bits even if both 
     * operands are 32 bits. 
     * Make sure to round up for half microseconds. 
     */ 
    data->predicted_us = div_round64((uint64_t)data->next_timer_us * 
                     data->correction_factor[data->bucket], 
                     RESOLUTION * DECAY); 
   
    get_typical_interval(data); 
   
    /* 
     * Performance multiplier defines a minimum predicted idle 
     * duration / latency ratio. Adjust the latency limit if 
     * necessary. 
     */ 
    interactivity_req = data->predicted_us / performance_multiplier(nr_iowaiters, cpu_load); 
    if (latency_req > interactivity_req) 
        latency_req = interactivity_req; 
   
    /* 
     * We want to default to C1 (hlt), not to busy polling 
     * unless the timer is happening really really soon. 
     */ 
    if (data->next_timer_us > 5 && 
        !drv->states[CPUIDLE_DRIVER_STATE_START].disabled && 
        dev->states_usage[CPUIDLE_DRIVER_STATE_START].disable == 0) 
        data->last_state_idx = CPUIDLE_DRIVER_STATE_START; 
   
    /* 
     * Find the idle state with the lowest power while satisfying 
     * our constraints. 
     */ 
    for (i = CPUIDLE_DRIVER_STATE_START; i < drv->state_count; i++) { 
        struct cpuidle_state *s = &drv->states[i]; 
        struct cpuidle_state_usage *su = &dev->states_usage[i]; 
   
        if (s->disabled || su->disable) 
            continue; 
        if (s->target_residency > data->predicted_us) 
            continue; 
        if (s->exit_latency > latency_req) 
            continue; 
   
        data->last_state_idx = i; 
    } 
   
    return data->last_state_idx; 
} 
 

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。