Linux動態頻率調節系統CPUFreq之三:governor

在上一篇文章中,介紹了cpufreq的core層,core提供了cpufreq系統的初始化,公共數據結構的建立以及對cpufreq中其它子部件提供註冊功能。core的最核心功能是對policy的管理,一個policy通過cpufreq_policy結構中的governor字段,和某個governor相關聯,本章的內容正是要對governor進行討論。

通過前面兩篇文章的介紹,我們知道,governor的作用是:檢測系統的負載狀況,然後根據當前的負載,選擇出某個可供使用的工作頻率,然後把該工作頻率傳遞給cpufreq_driver,完成頻率的動態調節。內核默認提供了5種governor供我們使用,在之前的內核版本中,每種governor幾乎是獨立的代碼,它們各自用自己的方式實現對系統的負載進行監測,很多時候,檢測的邏輯其實是很相似的,各個governor最大的不同之處其實是根據檢測的結果,選擇合適頻率的策略。所以,爲了減少代碼的重複,在我現在分析的內核版本中(3.10.0),一些公共的邏輯代碼被單獨抽象出來,單獨用一個文件來實現:/drivers/cpufreq/cpufreq_governor.c,而各個具體的governor則分別有自己的代碼文件,如:cpufreq_ondemand.c,cpufreq_performance.c。下面我們先從公共部分討論。

1.  數據結構


cpu_dbs_common_info  該結構把對計算cpu負載需要使用到的一些輔助變量整合在了一起,通常,每個cpu都需要一個cpu_dbs_common_info結構體,該結構體中的成員會在governor的生命週期期間進行傳遞,以用於統計當前cpu的負載,它的定義如下:

  1. /* Per cpu structures */  
  2. struct cpu_dbs_common_info {  
  3.         int cpu;  
  4.         u64 prev_cpu_idle;  
  5.         u64 prev_cpu_wall;  
  6.         u64 prev_cpu_nice;  
  7.         struct cpufreq_policy *cur_policy;  
  8.         struct delayed_work work;  
  9.   
  10.         struct mutex timer_mutex;  
  11.         ktime_t time_stamp;  
  12. };  
  • cpu  與該結構體相關聯的cpu編號。
  • prev_cpu_idle  上一次統計時刻該cpu停留在idle狀態的總時間。
  • prev_cpu_wall  上一次統計時刻對應的總工作時間。
  • cur_policy  指向該cpu所使用的cpufreq_policy結構。
  • work  工作隊列,該工作隊列會被定期地觸發,然後定期地進行負載的更新和統計工作。
dbs縮寫,實際是:demand based switching,通常,因爲cpu_dbs_common_info只包含了經過抽象後的公共部分,所以,各個governor會自己定義的一個包含cpu_dbs_common_info的自定義結構,例如對於ondemand,他會定義:

  1. struct od_cpu_dbs_info_s {  
  2.         struct cpu_dbs_common_info cdbs;  
  3.         struct cpufreq_frequency_table *freq_table;  
  4.         unsigned int freq_lo;  
  5.         unsigned int freq_lo_jiffies;  
  6.         unsigned int freq_hi_jiffies;  
  7.         unsigned int rate_mult;  
  8.         unsigned int sample_type:1;  
  9. };  
而對於Conservative,他的定義如下:

  1. struct cs_cpu_dbs_info_s {  
  2.         struct cpu_dbs_common_info cdbs;  
  3.         unsigned int down_skip;  
  4.         unsigned int requested_freq;  
  5.         unsigned int enable:1;  
  6. };  
把它理解爲類似於C++語言的基類和子類的概念就是了。


common_dbs_data    各個獨立的governor,需要和governor的公共層交互,需要實現一套公共的接口,這個接口由common_dbs_data結構來提供:

  1. struct common_dbs_data {  
  2.         /* Common across governors */  
  3.         #define GOV_ONDEMAND            0  
  4.         #define GOV_CONSERVATIVE        1  
  5.         int governor;  
  6.         struct attribute_group *attr_group_gov_sys; /* one governor - system */  
  7.         struct attribute_group *attr_group_gov_pol; /* one governor - policy */  
  8.   
  9.         /* Common data for platforms that don't set have_governor_per_policy */  
  10.         struct dbs_data *gdbs_data;  
  11.   
  12.         struct cpu_dbs_common_info *(*get_cpu_cdbs)(int cpu);  
  13.         void *(*get_cpu_dbs_info_s)(int cpu);  
  14.         void (*gov_dbs_timer)(struct work_struct *work);  
  15.         void (*gov_check_cpu)(int cpu, unsigned int load);  
  16.         int (*init)(struct dbs_data *dbs_data);  
  17.         void (*exit)(struct dbs_data *dbs_data);  
  18.   
  19.         /* Governor specific ops, see below */  
  20.         void *gov_ops;  
  21. };  
主要的字段意義如下:
  • governor  因爲ondemand和conservative的實現部分有很多相似的地方,用該字段做一區分,可以設置爲GOV_ONDEMAND或GOV_CONSERVATIVE的其中之一。
  • attr_group_gov_sys  該公共的sysfs屬性組。
  • attr_group_gov_pol  各policy使用的屬性組,有時候多個policy會使用同一個governor算法。
  • gdbs_data  通常,當沒有設置have_governor_per_policy時,表示所有的policy使用了同一種governor,該字段指向該governor的dbs_data結構。
  • get_cpu_cdbs  回調函數,公共層用它取得對應cpu的cpu_dbs_common_info結構指針。
  • get_cpu_dbs_info_s  回調函數,公共層用它取得對應cpu的cpu_dbs_common_info_s的派生結構指針,例如:od_cpu_dbs_info_s,cs_cpu_dbs_info_s。
  • gov_dbs_timer  前面說過,cpu_dbs_common_info_s結構中有一個工作隊列,該回調通常用作工作隊列的工作函數。
  • gov_check_cpu  計算cpu負載的回調函數,通常會直接調用公共層提供的dbs_check_cpu函數完成實際的計算工作。
  • init   初始化回調,用於完成該governor的一些額外的初始化工作。
  • exit  回調函數,governor被移除時調用。
  • gov_ops  各個governor可以用該指針定義各自特有的一些操作接口。

dbs_data    該結構體通常由governor的公共層代碼在governor的初始化階段動態創建,該結構的一個最重要的字段就是cdata:一個common_dbs_data結構指針,另外,該結構還包含一些定義governor工作方式的一些調節參數。該結構的詳細定義如下:

  1. struct dbs_data {  
  2.         struct common_dbs_data *cdata;  
  3.         unsigned int min_sampling_rate;  
  4.         int usage_count;  
  5.         void *tuners;  
  6.   
  7.         /* dbs_mutex protects dbs_enable in governor start/stop */  
  8.         struct mutex mutex;  
  9. };  
幾個主要的字段:

  • cdata  一個common_dbs_data結構指針,通常由具體governor的實現部分定義好,然後作爲參數,通過公共層的API:cpufreq_governor_dbs,傳遞到公共層,cpufreq_governor_dbs函數在創建好dbs_data結構後,把該指針賦值給該字段。
  • min_sampling_rate  用於記錄統計cpu負載的採樣週期。
  • usage_count  當沒有設置have_governor_per_policy時,意味着所有的policy採用同一個governor,該字段就是用來統計目前該governor被多少個policy引用。
  • tuners  指向governor的調節參數結構,不同的governor可以定義自己的tuner結構,公共層代碼會在governor的初始化階段調用common_dbs_data結構的init回調函數,governor的實現可以在init回調中初始化tuners字段。
如果設置了have_governor_per_policy,每個policy擁有各自獨立的governor,也就是說,擁有獨立的dbs_data結構,它會記錄在cpufreq_policy結構的governor_data字段中,否則,如果沒有設置have_governor_per_policy,多個policy共享一個governor,和同一個dbs_data結構關聯,此時,dbs_data被賦值在common_dbs_data結構的gdbs_data字段中。

cpufreq_governor  這個結構在本系列文章的第一篇已經介紹過了,請參看Linux動態頻率調節系統CPUFreq之一:概述。幾個數據結構的關係如下圖所示:


                                                                                         圖 1.1  governor的數據結構關係

下面我們以ondemand這個系統已經實現的governor爲例,說明一下如何實現一個governor。具體的代碼請參看:/drivers/cpufreq/cpufreq_ondemand.c。

2.  定義一個governor


要實現一個governor,首先要定義一個cpufreq_governor結構,對於ondeman來說,它的定義如下:

  1. struct cpufreq_governor cpufreq_gov_ondemand = {  
  2.         .name                   = "ondemand",  
  3.         .governor               = od_cpufreq_governor_dbs,  
  4.         .max_transition_latency = TRANSITION_LATENCY_LIMIT,  
  5.         .owner                  = THIS_MODULE,  
  6. };  
其中,governor是這個結構的核心字段,cpufreq_governor註冊後,cpufreq的核心層通過該字段操縱這個governor的行爲,包括:初始化、啓動、退出等工作。現在,該字段被設置爲od_cpufreq_governor_dbs,我們看看它的實現:

  1. static int od_cpufreq_governor_dbs(struct cpufreq_policy *policy,  
  2.                 unsigned int event)  
  3. {  
  4.         return cpufreq_governor_dbs(policy, &od_dbs_cdata, event);  
  5. }  
只是簡單地調用了governor的公共層提供的API:cpufreq_governor_dbs,關於這個API,我們在後面會逐一進行展開,這裏我們注意到參數:&od_dbs_cdata,正是我們前面討論過得common_dbs_data結構,作爲和governor公共層的接口,在這裏它的定義如下:

  1. static struct common_dbs_data od_dbs_cdata = {  
  2.         .governor = GOV_ONDEMAND,  
  3.         .attr_group_gov_sys = &od_attr_group_gov_sys,  
  4.         .attr_group_gov_pol = &od_attr_group_gov_pol,  
  5.         .get_cpu_cdbs = get_cpu_cdbs,  
  6.         .get_cpu_dbs_info_s = get_cpu_dbs_info_s,  
  7.         .gov_dbs_timer = od_dbs_timer,  
  8.         .gov_check_cpu = od_check_cpu,  
  9.         .gov_ops = &od_ops,  
  10.         .init = od_init,  
  11.         .exit = od_exit,  
  12. };  
這裏先介紹一下get_cpu_cdbs和get_cpu_dbs_info_s這兩個回調,前面介紹cpu_dbs_common_info_s結構的時候已經說過,各個governor需要定義一個cpu_dbs_common_info_s結構的派生結構,對於ondemand來說,這個派生結構是:od_cpu_dbs_info_s。兩個回調函數分別用來獲得基類和派生類這兩個結構的指針。我們先看看od_cpu_dbs_info_s是如何定義的:

  1. static DEFINE_PER_CPU(struct od_cpu_dbs_info_s, od_cpu_dbs_info);  
沒錯,它被定義爲了一個per_cpu變量,也就是說,每個cpu擁有各自獨立的od_cpu_dbs_info_s,這很正常,因爲每個cpu需要的實時負載是不一樣的,需要獨立的上下文變量來進行負載的統計。前面也已經列出了od_cpu_dbs_info_s的聲明,他的第一個字段cdbs就是一個cpu_dbs_common_info_s結構。內核爲我們提供了一個輔助宏來幫助我們定義get_cpu_cdbs和get_cpu_dbs_info_s這兩個回調函數:

  1. #define define_get_cpu_dbs_routines(_dbs_info)                          \  
  2. static struct cpu_dbs_common_info *get_cpu_cdbs(int cpu)                \  
  3. {                                                                       \  
  4.         return &per_cpu(_dbs_info, cpu).cdbs;                           \  
  5. }                                                                       \  
  6.                                                                         \  
  7. static void *get_cpu_dbs_info_s(int cpu)                                \  
  8. {                                                                       \  
  9.         return &per_cpu(_dbs_info, cpu);                                \  
  10. }        
所以,在cpufreq_ondemand.c中,我們只要簡單地使用上述的宏即可定義這兩個回調:

  1. define_get_cpu_dbs_routines(od_cpu_dbs_info);  
經過上述這一系列的定義以後,governor的公共層即可通過這兩個回調獲取各個cpu所對應的cpu_dbs_common_info_s和od_cpu_dbs_info_s的結構指針,用來記錄本次統計週期的一些上下文參數(idle時間和運行時間等等)。


3.  初始化一個governor


當一個governor被policy選定後,核心層會通過__cpufreq_set_policy函數對該cpu的policy進行設定,參看 Linux動態頻率調節系統CPUFreq之二:核心(core)架構與API中的第4節和圖4.1。如果policy認爲這是一個新的governor(和原來使用的舊的governor不相同),policy會通過__cpufreq_governor函數,並傳遞CPUFREQ_GOV_POLICY_INIT參數,而__cpufreq_governor函數實際上是調用cpufreq_governor結構中的governor回調函數,在第2節中我們已經知道,這個回調最後會進入governor公共API:cpufreq_governor_dbs,下面是它收到CPUFREQ_GOV_POLICY_INIT參數時,經過簡化後的代碼片段:

  1. case CPUFREQ_GOV_POLICY_INIT:  
  2.         ......  
  3.   
  4.         dbs_data = kzalloc(sizeof(*dbs_data), GFP_KERNEL);  
  5.         ......  
  6.   
  7.         dbs_data->cdata = cdata;  
  8.         dbs_data->usage_count = 1;  
  9.         rc = cdata->init(dbs_data);  
  10.         ......  
  11.   
  12.         rc = sysfs_create_group(get_governor_parent_kobj(policy),  
  13.                         get_sysfs_attr(dbs_data));  
  14.         ......  
  15.   
  16.         policy->governor_data = dbs_data;  
  17.   
  18.         ......  
  19.         /* Bring kernel and HW constraints together */  
  20.         dbs_data->min_sampling_rate = max(dbs_data->min_sampling_rate,  
  21.                         MIN_LATENCY_MULTIPLIER * latency);  
  22.         set_sampling_rate(dbs_data, max(dbs_data->min_sampling_rate,  
  23.                                 latency * LATENCY_MULTIPLIER));  
  24.         if ((cdata->governor == GOV_CONSERVATIVE) &&  
  25.                         (!policy->governor->initialized)) {  
  26.                 struct cs_ops *cs_ops = dbs_data->cdata->gov_ops;  
  27.   
  28.                 cpufreq_register_notifier(cs_ops->notifier_block,  
  29.                                 CPUFREQ_TRANSITION_NOTIFIER);  
  30.         }  
  31.   
  32.         if (!have_governor_per_policy())  
  33.                 cdata->gdbs_data = dbs_data;  
  34.   
  35.         return 0;  
首先,它會給這個policy分配一個dbs_data實例,然後把通過參數cdata傳入的common_dbs_data指針,賦值給它的cdata字段,這樣,policy就可以通過該字段獲得governor的操作接口(通過cdata的一系列回調函數)。然後,調用cdata的init回調函數,對這個governor做進一步的初始化工作,對於ondemand來說,init回調的實際執行函數是:od_init,主要是完成和governor相關的一些調節參數的初始化,然後把初始化好的od_dbs_tuners結構指針賦值到dbs_data的tuners字段中,它的詳細代碼這裏就不貼出了。接着,通過sysfs_create_group函數,建立該governor在sysfs中的節點,以後我們就可以通過這些節點對該governor的算法邏輯進行微調,ondemand在我的電腦中,建立了以下這些節點(sys/devices/system/cpu/cpufreq/ondemand):

sampling_rate;
io_is_busy;
up_threshold;
sampling_down_factor;
ignore_nice;
powersave_bias;
sampling_rate_min;

繼續,把初始化好的dbs_data結構賦值給policy的governor_data字段,以方便以後的訪問。最後是通過set_sampling_rate設置governor的採樣週期,如果還有設置have_governor_per_policy,把dbs_data結構指針賦值給cdata結構的gdbs_data字段,至此,governor的初始化工作完成,下面是整個過程的序列圖:


                                                                                        圖 3.1  governor的初始化

4.  啓動一個governor


核心層會通過__cpufreq_set_policy函數,通過CPUFREQ_GOV_POLICY_INIT參數,在公共層的API:cpufreq_governor_dbs中,完成了對governor的初始化工作,緊接着,__cpufreq_set_policy會通過CPUFREQ_GOV_START參數,和初始化governor的流程一樣,最終會到達cpufreq_governor_dbs函數中,我們看看它是如何啓動一個governor的:

  1. case CPUFREQ_GOV_START:  
  2.         if (!policy->cur)  
  3.                 return -EINVAL;  
  4.   
  5.         mutex_lock(&dbs_data->mutex);  
  6.   
  7.         for_each_cpu(j, policy->cpus) {  
  8.                 struct cpu_dbs_common_info *j_cdbs =  
  9.                         dbs_data->cdata->get_cpu_cdbs(j);  
  10.   
  11.                 j_cdbs->cpu = j;  
  12.                 j_cdbs->cur_policy = policy;  
  13.                 j_cdbs->prev_cpu_idle = get_cpu_idle_time(j,  
  14.                                        &j_cdbs->prev_cpu_wall, io_busy);  
  15.                 if (ignore_nice)  
  16.                         j_cdbs->prev_cpu_nice =  
  17.                                 kcpustat_cpu(j).cpustat[CPUTIME_NICE];  
  18.   
  19.                 mutex_init(&j_cdbs->timer_mutex);  
  20.                 INIT_DEFERRABLE_WORK(&j_cdbs->work,  
  21.                                      dbs_data->cdata->gov_dbs_timer);  
  22.         }  
首先,遍歷使用該policy的所有的處於online狀態的cpu,針對每一個cpu,做以下動作:

  • 取出該cpu相關聯的cpu_dbs_common_info結構指針,之前已經討論過,governor定義了一個per_cpu變量來定義各個cpu所對應的cpu_dbs_common_info結構,通過common_dbs_data結構的回調函數可以獲取該結構的指針。
  • 初始化cpu_dbs_common_info結構的cpu,cur_policy,prev_cpu_idle,prev_cpu_wall,prev_cpu_nice字段,其中,prev_cpu_idle,prev_cpu_wall這兩個字段會被以後的負載計算所使用。
  • 爲每個cpu初始化一個工作隊列,工作隊列的執行函數是common_dbs_data結構中的gov_dbs_timer字段所指向的回調函數,對於ondemand來說,該函數是:od_dbs_timer。這個工作隊列會被按照設定好的採樣率定期地被喚醒,進行cpu負載的統計工作。
然後,記錄目前的時間戳,調度初始化好的工作隊列在稍後某個時間點運行:
  1. /* Initiate timer time stamp */  
  2.  cpu_cdbs->time_stamp = ktime_get();  
  3.   
  4.  gov_queue_work(dbs_data, policy,  
  5.                  delay_for_sampling_rate(sampling_rate), true);  
下圖表達了啓動一個governor的過程:

                                                                           圖 4.1  啓動一個governor

工作隊列被調度執行後,會在工作隊列的執行函數中進行cpu負載的統計工作,這個我們在下一節中討論。

5.  系統負載的檢測


上一節我們提到,核心層啓動一個governor後,會在每個使用該governor的cpu上建立一個工作隊列,工作隊列的執行函數是在common_dbs_data中gov_dbs_timer字段所指向的函數,理所當然,該函數由各個governor的具體代碼來實現,對於ondemand governor,它的實現函數是od_dbs_timer。governor的公共層代碼爲我們提供了一個API:dbs_check_cpu,該API用來計算兩個統計週期期間某個cpu的負載情況,我們先分析一下dbs_check_cpu:
  1. void dbs_check_cpu(struct dbs_data *dbs_data, int cpu)  
  2. {  
  3.         struct cpu_dbs_common_info *cdbs = dbs_data->cdata->get_cpu_cdbs(cpu);  
  4.         ......  
  5.   
  6.         policy = cdbs->cur_policy;  
  7.   
  8.         /* Get Absolute Load (in terms of freq for ondemand gov) */  
  9.         for_each_cpu(j, policy->cpus) {  
  10.                 struct cpu_dbs_common_info *j_cdbs;  
  11.                 ......  
  12.   
  13.                 j_cdbs = dbs_data->cdata->get_cpu_cdbs(j);  
  14.   
  15.                 ......  
  16.                 cur_idle_time = get_cpu_idle_time(j, &cur_wall_time, io_busy);  
  17.   
  18.                 wall_time = (unsigned int)  
  19.                         (cur_wall_time - j_cdbs->prev_cpu_wall);  
  20.                 j_cdbs->prev_cpu_wall = cur_wall_time;  
  21.   
  22.                 idle_time = (unsigned int)  
  23.                         (cur_idle_time - j_cdbs->prev_cpu_idle);  
  24.                 j_cdbs->prev_cpu_idle = cur_idle_time;  
  25.                 ......  
  26.   
  27.                 load = 100 * (wall_time - idle_time) / wall_time;  
  28.                 ......  
  29.                 load *= cur_freq;    /* 實際的代碼不是這樣,爲了簡化討論,精簡爲實際的計算邏輯*/  
  30.   
  31.                 if (load > max_load)  
  32.                         max_load = load;  
  33.         }  
  34.   
  35.         dbs_data->cdata->gov_check_cpu(cpu, max_load);  
  36. }  
由代碼可以看出,遍歷該policy下每個online的cpu,取出該cpu對應的cpu_dbs_common_info結構,該結構中的prev_cpu_idle和prev_cpu_wall保存有上一次採樣週期時記錄的idle時間和運行時間,負載的計算其實很簡單:
  • idle_time = 本次idle時間 - 上次idle時間;
  • wall_time = 本次總運行時間 - 上次總運行時間;
  • 負載load = 100 * (wall_time - idle_time)/ wall_time;
  • 把所有cpu中,負載最大值記入max_load中,作爲選擇頻率的依據;
計算出最大負載max_load後,調用具體governor實現的gov_check_cpu回調函數,對於ondemand來說,該回調函數是:od_check_cpu,我們跟進去看看:
  1. static void od_check_cpu(int cpu, unsigned int load_freq)  
  2. {  
  3.         struct od_cpu_dbs_info_s *dbs_info = &per_cpu(od_cpu_dbs_info, cpu);  
  4.         struct cpufreq_policy *policy = dbs_info->cdbs.cur_policy;  
  5.         struct dbs_data *dbs_data = policy->governor_data;  
  6.         struct od_dbs_tuners *od_tuners = dbs_data->tuners;  
  7.   
  8.         dbs_info->freq_lo = 0;  
  9.   
  10.         /* Check for frequency increase */  
  11.         if (load_freq > od_tuners->up_threshold * policy->cur) {  
  12.                 /* If switching to max speed, apply sampling_down_factor */  
  13.                 if (policy->cur < policy->max)  
  14.                         dbs_info->rate_mult =  
  15.                                 od_tuners->sampling_down_factor;  
  16.                 dbs_freq_increase(policy, policy->max);  
  17.                 return;  
  18.         }  
當負載比預設的閥值高時(od_tuners->up_threshold,默認值是95%),立刻選擇該policy最大的工作頻率作爲接下來的工作頻率。如果負載沒有達到預設的閥值,但是當前頻率已經是最低頻率了,則什麼都不做,直接返回:

  1. if (policy->cur == policy->min)  
  2.         return;  
運行到這裏,cpu的頻率可能已經在上面的過程中被設置爲最大頻率,實際上我們可能並不需要這麼高的頻率,所以接着判斷,當負載低於另一個預設值時,這時需要計算一個合適於該負載的新頻率:

  1. if (load_freq < od_tuners->adj_up_threshold  
  2.                 * policy->cur) {  
  3.         unsigned int freq_next;  
  4.         freq_next = load_freq / od_tuners->adj_up_threshold;  
  5.   
  6.         /* No longer fully busy, reset rate_mult */  
  7.         dbs_info->rate_mult = 1;  
  8.   
  9.         if (freq_next < policy->min)  
  10.                 freq_next = policy->min;  
  11.   
  12.         if (!od_tuners->powersave_bias) {  
  13.                 __cpufreq_driver_target(policy, freq_next,  
  14.                                 CPUFREQ_RELATION_L);  
  15.                 return;  
  16.         }  
  17.   
  18.         freq_next = od_ops.powersave_bias_target(policy, freq_next,  
  19.                                 CPUFREQ_RELATION_L);  
  20.         __cpufreq_driver_target(policy, freq_next, CPUFREQ_RELATION_L);  
  21. }  
對於ondemand來說,因爲傳入的負載是乘上了當前頻率後的歸一化值,所以計算新頻率時,直接用load_freq除以想要的負載即可。本來計算出來的頻率直接通過__cpufreq_driver_target函數,交給cpufreq_driver調節頻率即可,但是這裏的處理考慮了powersave_bias的設置情況,當設置了powersave_bias時,表明我們爲了進一步節省電力,我們希望在計算出來的新頻率的基礎上,再乘以一個powersave_bias設定的百分比,作爲真正的運行頻率,powersave_bias的值從0-1000,每一步代表0.1%。實際的情況比想象中稍微複雜一點,考慮到乘以一個powersave_bias後的新頻率可能不在cpu所支持的頻率表中,ondemand算法會在頻率表中查找,分別找出最接近新頻率的一個區間,由高低兩個頻率組成,低的頻率記入od_cpu_dbs_info_s結構的freq_lo字段中,高的頻率通過od_ops.powersave_bias_target回調返回。同時,od_ops.powersave_bias_target回調函數還計算出高低兩個頻率應該運行的時間,分別記入od_cpu_dbs_info_s結構的freq_hi_jiffies和freq_low_jiffies字段中。原則是,通過兩個不同頻率的運行時間的組合,使得綜合結果接近我們想要的目標頻率。詳細的計算邏輯請參考函數:generic_powersave_bias_target。
討論完上面兩個函數,讓我們回到本節的開頭,負載的計算工作是在一個工作隊列中發起的,前面說過,ondemand對應的工作隊列的工作函數是od_dbs_timer,我們看看他的實現代碼:

  1. static void od_dbs_timer(struct work_struct *work)  
  2. {  
  3.         ......  
  4.   
  5.         /* Common NORMAL_SAMPLE setup */  
  6.         core_dbs_info->sample_type = OD_NORMAL_SAMPLE;  
  7.         if (sample_type == OD_SUB_SAMPLE) {  
  8.                 delay = core_dbs_info->freq_lo_jiffies;  
  9.                 __cpufreq_driver_target(core_dbs_info->cdbs.cur_policy,  
  10.                                 core_dbs_info->freq_lo, CPUFREQ_RELATION_H);  
  11.         } else {  
  12.                 dbs_check_cpu(dbs_data, cpu);  
  13.                 if (core_dbs_info->freq_lo) {  
  14.                         /* Setup timer for SUB_SAMPLE */  
  15.                         core_dbs_info->sample_type = OD_SUB_SAMPLE;  
  16.                         delay = core_dbs_info->freq_hi_jiffies;  
  17.                 }  
  18.         }  
  19.   
  20. max_delay:  
  21.         if (!delay)  
  22.                 delay = delay_for_sampling_rate(od_tuners->sampling_rate  
  23.                                 * core_dbs_info->rate_mult);  
  24.   
  25.         gov_queue_work(dbs_data, dbs_info->cdbs.cur_policy, delay, modify_all);  
  26.         mutex_unlock(&core_dbs_info->cdbs.timer_mutex);  
  27. }  
如果sample_type是OD_SUB_SAMPLE時,表明上一次採樣時,需要用高低兩個頻率來模擬實際的目標頻率中的第二步:需要運行freq_lo,並且持續時間爲freq_lo_jiffies。否則,調用公共層計算負載的API:dbs_check_cpu,開始一次新的採樣,當powersave_bias沒有設置時,該函數返回前,所需要的新的目標頻率會被設置,考慮到powersave_bias的設置情況,判斷一下如果freq_lo被設置,說明需要用高低兩個頻率來模擬實際的目標頻率,高頻率已經在dbs_check_cpu返回前被設置(實際的設置工作是在od_check_cpu中),所以把sample_type設置爲OD_SUB_SAMPLE,以便下一次運行工作函數進行採樣時可以設置低頻率運行。最後,調度工作隊列在下一個採樣時刻再次運行,這樣,cpu的工作頻率實現了在每個採樣週期,根據實際的負載情況,動態地設定合適的工作頻率進行運行,既滿足了性能的需求,也降低了系統的功耗,達到了cpufreq系統的最終目的,整個流程可以參考下圖:

                                                                                  圖 5.1  負載計算和頻率選擇

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章