隨着技術的發展,我們對CPU的處理能力提出了越來越高的需求,芯片廠家也對製造工藝不斷地提升。現在的主流PC處理器的主頻已經在3GHz左右,就算是智能手機的處理器也已經可以工作在1.5GHz以上,可是我們並不是時時刻刻都需要讓CPU工作在最高的主頻上,尤其是移動設備和筆記本電腦,大部分時間裏,CPU其實工作在輕負載狀態下,我們知道:主頻越高,功耗也越高。爲了節省CPU的功耗和減少發熱,我們有必要根據當前CPU的負載狀態,動態地提供剛好足夠的主頻給CPU。在Linux中,內核的開發者定義了一套框架模型來完成這一目的,它就是CPUFreq系統。
/*****************************************************************************************************/
聲明:本博內容均由http://blog.csdn.net/droidphone原創,轉載請註明出處,謝謝!
/*****************************************************************************************************/
1. sysfs接口
我們先從CPUFreq提供的sysfs接口入手,直觀地看看它提供了那些功能。以下是我的電腦輸出的結果:
- droidphone@990:~$ cd /sys/devices/system/cpu
- droidphone@990:/sys/devices/system/cpu$ ls
- cpu0 cpu3 cpu6 cpuidle offline power release
- cpu1 cpu4 cpu7 kernel_max online present uevent
- cpu2 cpu5 cpufreq modalias possible probe
所有與CPUFreq相關的sysfs接口都位於:/sys/devices/system/cpu下面,我們可以看到,8個cpu分別建立了一個自己的目錄,從cpu0到cpu7,我們再看看offline和online以及present的內容:
- droidphone@990:/sys/devices/system/cpu$ cat online
- 0-7
- droidphone@990:/sys/devices/system/cpu$ cat offline
- 8-15
- droidphone@990:/sys/devices/system/cpu$ cat present
- 0-7
- droidphone@990:/sys/devices/system/cpu$
接着往下看:
- droidphone@990:/sys/devices/system/cpu/cpu0$ ls
- cache cpuidle microcode power thermal_throttle uevent
- cpufreq crash_notes node0 subsystem topology
- droidphone@990:/sys/devices/system/cpu/cpu0$ cd cpufreq/
- droidphone@990:/sys/devices/system/cpu/cpu0/cpufreq$ ls
- affected_cpus related_cpus scaling_max_freq
- bios_limit scaling_available_frequencies scaling_min_freq
- cpuinfo_cur_freq scaling_available_governors scaling_setspeed
- cpuinfo_max_freq scaling_cur_freq stats
- cpuinfo_min_freq scaling_driver
- cpuinfo_transition_latency scaling_governor
- droidphone@990:/sys/devices/system/cpu/cpu0/cpufreq$
cpuinfo_cur_freq: 1600000
cpuinfo_max_freq: 3401000
cpuinfo_min_freq: 1600000
scaling_cur_freq: 1600000
scaling_max_freq: 3401000
scaling_min_freq: 1600000
所以,我的cpu0的最低運行頻率是1.6GHz,最高是3.4GHz,目前正在運行的頻率是1.6GHz,前綴cpuinfo代表的是cpu硬件上支持的頻率,而scaling前綴代表的是可以通過CPUFreq系統用軟件進行調節時所支持的頻率。cpuinfo_cur_freq代表通過硬件實際上讀到的頻率值,而scaling_cur_freq則是軟件當前的設置值,多數情況下這兩個值是一致的,但是也有可能因爲硬件的原因,有微小的差異。scaling_available_frequencies會輸出當前軟件支持的頻率值,看看我的cpu支持那些頻率:
- droidphone@990:/sys/devices/system/cpu/cpu0/cpufreq$ cat scaling_available_frequencies
- 3401000 3400000 3000000 2800000 2600000 2400000 2200000 2000000 1800000 1600000
- droidphone@990:/sys/devices/system/cpu/cpu0/cpufreq$
- conservative ondemand userspace powersave performance
- dong@dong-990:/sys/devices/system/cpu/cpu0/cpufreq$ cat scaling_governor
- ondemand
當我們選擇userspace作爲我們的調頻governor時,我們可以通過scaling_setspeed手工設置需要的頻率。powersave則簡單地使用最低的工作頻率進行運行,而performance則一直選擇最高的頻率進行運行。
2. 軟件架構
通過上一節的介紹,我們可以大致梳理出CPUFreq系統的構成和工作方式。首先,CPU的硬件特性決定了這個CPU的最高和最低工作頻率,所有的頻率調整數值都必須在這個範圍內,它們用cpuinfo_xxx_freq來表示。然後,我們可以在這個範圍內再次定義出一個軟件的調節範圍,它們用scaling_xxx_freq來表示,同時,根據具體的硬件平臺的不同,我們還需要提供一個頻率表,這個頻率表規定了cpu可以工作的頻率值,當然這些頻率值必須要在cpuinfo_xxx_freq的範圍內。有了這些頻率信息,CPUFreq系統就可以根據當前cpu的負載輕重狀況,合理地從頻率表中選擇一個合適的頻率供cpu使用,已達到節能的目的。至於如何選擇頻率表中的頻率,這個要由不同的governor來實現,目前的內核版本提供了5種governor供我們選擇。選擇好適當的頻率以後,具體的頻率調節工作就交由scaling_driver來完成。CPUFreq系統把一些公共的邏輯和接口代碼抽象出來,這些代碼與平臺無關,也與具體的調頻策略無關,內核的文檔把它稱爲CPUFreq Core(/Documents/cpufreq/core.txt)。另外一部分,與實際的調頻策略相關的部分被稱作cpufreq_policy,cpufreq_policy又是由頻率信息和具體的governor組成,governor纔是具體策略的實現者,當然governor需要我們提供必要的頻率信息,governor的實現最好能做到平臺無關,與平臺相關的代碼用cpufreq_driver表述,它完成實際的頻率調節工作。最後,如果其他內核模塊需要在頻率調節的過程中得到通知消息,則可以通過cpufreq notifiers來完成。由此,我們可以總結出CPUFreq系統的軟件結構如下:
3. cpufreq_policy
一種調頻策略的各種限制條件的組合稱之爲policy,代碼中用cpufreq_policy這一數據結構來表示:
- struct cpufreq_policy {
- cpumask_var_t cpus;
- cpumask_var_t related_cpus;
- unsigned int shared_type;
- unsigned int cpu;
- unsigned int last_cpu;
- struct cpufreq_cpuinfo cpuinfo;
- unsigned int min; /* in kHz */
- unsigned int max; /* in kHz */
- unsigned int cur;
- unsigned int policy;
- struct cpufreq_governor *governor;
- void *governor_data;
- struct work_struct update;
- struct cpufreq_real_policy user_policy;
- struct kobject kobj;
- struct completion kobj_unregister;
- };
- cpus和related_cpus 這兩個都是cpumask_var_t變量,cpus表示的是這一policy控制之下的所有還出於online狀態的cpu,而related_cpus則是online和offline兩者的合集。主要是用於多個cpu使用同一種policy的情況,實際上,我們平常見到的大多數系統中都是這種情況:所有的cpu同時使用同一種policy。我們需要related_cpus變量指出這個policy所管理的所有cpu編號。
- cpu和last_cpu 雖然一種policy可以同時用於多個cpu,但是通常一種policy只會由其中的一個cpu進行管理,cpu變量用於記錄用於管理該policy的cpu編號,而last_cpu則是上一次管理該policy的cpu編號(因爲管理policy的cpu可能會被plug out,這時候就要把管理工作遷移到另一個cpu上)。
- cpuinfo 保存cpu硬件所能支持的最大和最小的頻率以及切換延遲信息。
- min/max/cur 該policy下的可使用的最小頻率,最大頻率和當前頻率。
- policy 該變量可以取以下兩個值:CPUFREQ_POLICY_POWERSAVE和CPUFREQ_POLICY_PERFORMANCE,該變量只有當調頻驅動支持setpolicy回調函數的時候有效,這時候由驅動根據policy變量的值來決定系統的工作頻率或狀態。如果調頻驅動(cpufreq_driver)支持target回調,則頻率由相應的governor來決定。
- governor和governor_data 指向該policy當前使用的cpufreq_governor結構和它的上下文數據。governor是實現該policy的關鍵所在,調頻策略的邏輯由governor實現。
- update 有時在中斷上下文中需要更新policy,需要利用該工作隊列把實際的工作移到稍後的進程上下文中執行。
- user_policy 有時候因爲特殊的原因需要修改policy的參數,比如溫度過高時,最大可允許的運行頻率可能會被降低,爲了在適當的時候恢復原有的運行參數,需要使用user_policy保存原始的參數(min,max,policy,governor)。
- kobj 該policy在sysfs中對應的kobj的對象。
4. cpufreq_governor
所謂的governor,我把它翻譯成:調節器。governor負責檢測cpu的使用狀況,從而在可用的範圍中選擇一個合適的頻率,代碼中它用cpufreq_governor結構來表示:
- struct cpufreq_governor {
- char name[CPUFREQ_NAME_LEN];
- int initialized;
- int (*governor) (struct cpufreq_policy *policy,
- unsigned int event);
- ssize_t (*show_setspeed) (struct cpufreq_policy *policy,
- char *buf);
- int (*store_setspeed) (struct cpufreq_policy *policy,
- unsigned int freq);
- unsigned int max_transition_latency; /* HW must be able to switch to
- next freq faster than this value in nano secs or we
- will fallback to performance governor */
- struct list_head governor_list;
- struct module *owner;
- };
其中的各個字段的解釋如下:
- name 該governor的名字。
- initialized 初始化標誌。
- governor 指向一個回調函數,CPUFreq Core會在不同的階段調用該回調函數,用於該governor的啓動、停止、初始化、退出動作。
- list_head 所有註冊的governor都會利用該字段鏈接在一個全局鏈表中,以供系統查詢和使用。
5. cpufreq_driver
上一節提到的gonvernor只是負責計算並提出合適的頻率,但是頻率的設定工作是平臺相關的,這需要cpufreq_driver驅動來完成,cpufreq_driver的結構如下:
- struct cpufreq_driver {
- struct module *owner;
- char name[CPUFREQ_NAME_LEN];
- u8 flags;
- bool have_governor_per_policy;
- /* needed by all drivers */
- int (*init) (struct cpufreq_policy *policy);
- int (*verify) (struct cpufreq_policy *policy);
- /* define one out of two */
- int (*setpolicy) (struct cpufreq_policy *policy);
- int (*target) (struct cpufreq_policy *policy,
- unsigned int target_freq,
- unsigned int relation);
- /* should be defined, if possible */
- unsigned int (*get) (unsigned int cpu);
- /* optional */
- unsigned int (*getavg) (struct cpufreq_policy *policy,
- unsigned int cpu);
- int (*bios_limit) (int cpu, unsigned int *limit);
- int (*exit) (struct cpufreq_policy *policy);
- int (*suspend) (struct cpufreq_policy *policy);
- int (*resume) (struct cpufreq_policy *policy);
- struct freq_attr **attr;
- };
相關的字段的意義解釋如下:
- name 該頻率驅動的名字。
- init 回調函數,該回調函數必須實現,CPUFreq Core會通過該回調函數對該驅動進行必要的初始化工作。
- verify 回調函數,該回調函數必須實現,CPUFreq Core會通過該回調函數檢查policy的參數是否被驅動支持。
- setpolicy/target 回調函數,驅動必須實現這兩個函數中的其中一個,如果不支持通過governor選擇合適的運行頻率,則實現setpolicy回調函數,這樣系統只能支持CPUFREQ_POLICY_POWERSAVE和CPUFREQ_POLICY_PERFORMANCE這兩種工作策略。反之,實現target回調函數,通過target回調設定governor所需要的頻率。
- get 回調函數,用於獲取cpu當前的工作頻率。
- getavg 回調函數,用於獲取cpu當前的平均工作頻率。
6. cpufreq notifiers
CPUFreq的通知系統使用了內核的標準通知接口。它對外提供了兩個通知事件:policy通知和transition通知。
policy通知用於通知其它模塊cpu的policy需要改變,每次policy改變時,該通知鏈上的回調將會用不同的事件參數被調用3次,分別是:
- CPUFREQ_ADJUST 只要有需要,所有的被通知者可以在此時修改policy的限制信息,比如溫控系統可能會修改在大允許運行的頻率。
- CPUFREQ_INCOMPATIBLE 只是爲了避免硬件錯誤的情況下,可以在該通知中修改policy的限制信息。
- CPUFREQ_NOTIFY 真正切換policy前,該通知會發往所有的被通知者。
- CPUFREQ_PRECHANGE 調整前的通知。
- CPUFREQ_POSTCHANGE 完成調整後的通知。
- CPUFREQ_RESUMECHANG