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時再更新？這個問題留給讀者吧。

總結

以上是生活随笔為你收集整理的Linux cpuidle framework(4)_menu governor的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。