Linux 2.6 內核中的最新電源管理技術(shù)綜述

如圖 1 所示，cpufreq 在設計上主要分為以下三個(gè)模塊：

Cpufreq模塊(cpufreqmodule)對如何在底層控制各種不同CPU所支持的變頻技術(shù)以及如何在上層根據系統負載動(dòng)態(tài)選擇合適的運行頻率進(jìn)行了封裝和抽象，并在二者之間定義了清晰的接口，從而在設計上完成了前文所提到的對mechanism與policy的分離。
在cpufreq模塊的底層，各個(gè)CPU生產(chǎn)廠(chǎng)商只需根據其變頻技術(shù)的硬件實(shí)現和使用方法提供與其CPU相關(guān)的變頻驅動(dòng)程序(CPU-specificdrivers)，例如Intel需要提供支持EnhancedSpeedStep技術(shù)的CPU驅動(dòng)程序，而AMD則需要提供支持PowerNow!技術(shù)的CPU驅動(dòng)程序。
在cpufreq模塊的上層，governor作為選擇合適的目標運行頻率的決策者，根據一定的標準在適當的時(shí)刻選擇出CPU適合的運行頻率，并通過(guò)cpufreq模塊定義的接口操作底層與CPU相關(guān)的變頻驅動(dòng)程序，將CPU設置運行在選定的運行頻率上。目前最新的Linux內核中提供了performance、powersave、userspace、conservative和ondemand五種governors供用戶(hù)選擇使用，它們在選擇CPU合適的運行頻率時(shí)使用的是各自不同的標準并分別適用于不同的應用場(chǎng)景。用戶(hù)在同一時(shí)間只能選擇其中一個(gè)governor使用，但是可以在系統運行過(guò)程中根據應用需求的變化而切換使用另一個(gè)governor。
這種設計帶來(lái)的好處是使得governor和CPU相關(guān)的變頻驅動(dòng)程序的開(kāi)發(fā)可以相互獨立進(jìn)行，并在最大限度上實(shí)現代碼重用，內核開(kāi)發(fā)人員在編寫(xiě)和試驗新的governor時(shí)不會(huì )再陷入到某款特定CPU的變頻技術(shù)的硬件實(shí)現細節中去，而CPU生產(chǎn)廠(chǎng)商在向Linux內核中添加支持其特定的CPU變頻技術(shù)的代碼時(shí)只需提供一個(gè)相對來(lái)說(shuō)簡(jiǎn)單了很多的驅動(dòng)程序，而不必考慮在各種不同的應用場(chǎng)景中如何選擇合適的運行頻率這些復雜的問(wèn)題。

內核中的cpufreq子系統通過(guò)sysfs文件系統向上層應用提供了用戶(hù)接口，對于系統中的每一個(gè)CPU而言，其cpufreq的sysfs用戶(hù)接口位于/sys/devices/system/cpu/cpuX/cpufreq/目錄下，其中X代表processorid，與/proc/cpuinfo中的信息相對應。以cpu0為例，用戶(hù)一般會(huì )在該目錄下觀(guān)察到以下文件：

$ls-F/sys/devices/system/cpu/cpu0/cpufreq/
affected_cpus
cpuinfo_cur_freq
cpuinfo_max_freq

cpuinfo_min_freq
ondemand/
scaling_available_frequencies
scaling_available_governors
scaling_cur_freq
scaling_driver
scaling_governor
scaling_max_freq
scaling_min_freq
stats/



這其中的所有可讀文件都可以使用cat命令進(jìn)行讀操作，另外所有可寫(xiě)文件都可以使用echo命令進(jìn)行寫(xiě)操作。其中cpuinfo_max_freq和cpuinfo_min_freq分別給出了CPU硬件所支持的最高運行頻率及最低運行頻率，cpuinfo_cur_freq則會(huì )從CPU硬件寄存器中讀取CPU當前所處的運行頻率。雖然CPU硬件支持多種不同的運行頻率，但是在有些場(chǎng)合下用戶(hù)可以只選擇使用其中的一個(gè)子集，這種控制是通過(guò)scaling_max_freq和scaling_min_freq進(jìn)行的。Governor在選擇合適的運行頻率時(shí)只會(huì )在scaling_max_freq和scaling_min_freq所確定的頻率范圍內進(jìn)行選擇，這也就是scaling_available_frequencies所顯示的內容。與cpuinfo_cur_freq不同，scaling_cur_freq返回的是cpufreq模塊緩存的CPU當前運行頻率，而不會(huì )對CPU硬件寄存器進(jìn)行檢查。scaling_available_governors會(huì )告訴用戶(hù)當前有哪些governors可供用戶(hù)使用，而scaling_driver則會(huì )顯示該CPU所使用的變頻驅動(dòng)程序。Stats目錄下給出了對CPU各種運行頻率的使用統計情況，例如CPU在各種頻率下的運行時(shí)間以及在各種頻率之間的變頻次數。Ondemand目錄則與ondemandgovernor相關(guān)，在后文會(huì )進(jìn)行相應的介紹。

通過(guò)以上的介紹，大家對如何使用cpufreq通過(guò)sysfs提供的用戶(hù)接口已經(jīng)有了大致的了解，但是對于絕大部分用戶(hù)而言，逐一操作這些文件既費力又耗時(shí)。因此Dominik等人開(kāi)發(fā)了cpufrequtils工具包[2]，為用戶(hù)提供了更加簡(jiǎn)便的對內核cpufreq子系統的操作接口。通過(guò)cpufreq-info的輸出，讀者可以很清楚的看到剛剛在上面介紹過(guò)的/sys/devices/system/cpu/cpuX/cpufreq/目錄下各個(gè)文件的內容。

$cpufreq-info
cpufrequtils002:cpufreq-info(C)DominikBrodowski2004-2006
Reporterrorsandbugstolinux@brodo.de,please.
analyzingCPU0:
driver:acpi-cpufreq
CPUswhichneedtoswitchfrequencyatthesametime:01
hardwarelimits:1000MHz-1.67GHz
availablefrequencysteps:1.67GHz,1.33GHz,1000MHz
availablecpufreqgovernors:userspace,conservative,ondemand,powersave,performance
currentpolicy:frequencyshouldbewithin1000MHzand1.67GHz.
Thegovernor"ondemand"maydecidewhichspeedtouse
withinthisrange.
currentCPUfrequencyis1000MHz.
analyzingCPU1:
driver:acpi-cpufreq
CPUswhichneedtoswitchfrequencyatthesametime:01
hardwarelimits:1000MHz-1.67GHz
availablefrequencysteps:1.67GHz,1.33GHz,1000MHz
availablecpufreqgovernors:userspace,conservative,ondemand,powersave,performance
currentpolicy:frequencyshouldbewithin1000MHzand1.67GHz.
Thegovernor"ondemand"maydecidewhichspeedtouse
withinthisrange.
currentCPUfrequencyis1000MHz.


Ondemandgovernor的由來(lái)及其實(shí)現

剛剛我們在cpufreq-info的輸出中可以看到cpufreq子系統一共提供了五種governors供用戶(hù)選擇使用，它們分別是userspace，conservative，ondemand，powersave和performance。在最新的內核中如果用戶(hù)不進(jìn)行額外設置的話(huà)，ondemand會(huì )被作為默認的governor使用。為了理解是什么原因造成了這種現狀，我們在這里帶領(lǐng)讀者回顧一下cpufreq子系統中的governor在內核中的開(kāi)發(fā)歷史。

Cpufreq作為一個(gè)子系統最早被加入到Linux內核中時(shí)只配備了三個(gè)governors，分別是performance、powersave和userspace。當用戶(hù)選擇使用performancegovernor時(shí)，CPU會(huì )固定工作在其支持的最高運行頻率上；當用戶(hù)選擇使用powersavegovernor時(shí)，CPU會(huì )固定工作在其支持的最低運行頻率上。因此這兩種governors都屬于靜態(tài)governor，即在使用它們時(shí)CPU的運行頻率不會(huì )根據系統運行時(shí)負載的變化動(dòng)態(tài)作出調整。這兩種governors對應的是兩種極端的應用場(chǎng)景，使用performancegovernor體現的是對系統高性能的最大追求，而使用powersavegovernor則是對系統低功耗的最大追求。雖然這兩種應用需求確實(shí)存在，但大多數用戶(hù)在大部分時(shí)間里需要的是更加靈活的變頻策略。最早的cpufreq子系統通過(guò)userspacegovernor為用戶(hù)提供了這種靈活性。正如它的名字一樣，使用userspacegovernor時(shí)，系統將變頻策略的決策權交給了用戶(hù)態(tài)應用程序，并提供了相應的接口供用戶(hù)態(tài)應用程序調節CPU運行頻率使用。通過(guò)使用cpufrequtils工具包中的cpufreq-set將userspace設置為cpufreq子系統所使用的governor后，我們可以看到與之前相比在/sys/devices/system/cpu/cpuX/cpufreq/目錄下多出了一個(gè)名為scaling_setspeed的文件，這正是userspacegovernor所提供的特殊用戶(hù)接口。用戶(hù)可以通過(guò)向該文件寫(xiě)入任何一個(gè)scaling_available_frequencies中所支持的運行頻率，從而將CPU設置在該頻率下運行。

#cpufreq-set-guserspace
#catcpuinfo_cur_freq
1000000
#catscaling_available_frequencies
166700013330001000000
#echo1333000>scaling_setspeed
#catcpuinfo_cur_freq
1333000



剛剛提到在使用userspacegovernor時(shí)，系統將變頻策略的決策權交給了用戶(hù)態(tài)應用程序。該用戶(hù)態(tài)應用程序一般是一個(gè)daemon程序，每隔一定的時(shí)間間隔收集一次系統信息并根據系統的負載情況使用userspacegovernor提供的scaling_setspeed接口動(dòng)態(tài)調整CPU的運行頻率。作為這個(gè)daemon程序，當時(shí)在幾個(gè)主要的Linux發(fā)行版中使用的一般是powersaved或者cpuspeed。這兩個(gè)daemon程序一般每隔幾秒鐘統計一次CPU在這個(gè)采樣周期內的負載情況，并根據統計結果調整CPU的運行頻率。這種userspacegovernor加用戶(hù)態(tài)daemon程序的變頻方法雖然為用戶(hù)提供了一定的靈活性，但通過(guò)開(kāi)源社區的廣泛使用所得到的意見(jiàn)反饋逐漸暴露了這種方法的兩個(gè)嚴重缺陷。第一個(gè)是性能方面的問(wèn)題。例如powersaved每隔五秒鐘進(jìn)行一次系統負載情況的采樣分析的話(huà)，我們可以分析一下在下面給出的應用場(chǎng)景中的用戶(hù)體驗。假設powersaved的采樣分析剛剛結束，而且由于在剛剛結束的采樣周期內系統負載很低，CPU被設置在最低頻率上運行。這時(shí)用戶(hù)如果打開(kāi)Firefox®等對CPU運算能力要求相當高的程序的話(huà)，powersaved要在下一個(gè)采樣點(diǎn)――大約五秒鐘之后才有機會(huì )觀(guān)察到這種提高CPU運行頻率的需求。也就是說(shuō)，在Firefox啟動(dòng)之初的五秒鐘內CPU的計算能力并沒(méi)有被充分發(fā)揮出來(lái)，這無(wú)疑會(huì )使用戶(hù)體驗大打折扣。第二個(gè)是系統負載情況的采樣分析的準確性問(wèn)題。將監控系統負載情況并對未來(lái)CPU的性能需求做出判斷的任務(wù)交給一個(gè)用戶(hù)態(tài)程序完成實(shí)際上并不合理，一方面是由于一個(gè)用戶(hù)態(tài)程序很難完整的收集到所有需要的信息，因為這些信息大部分都保存在內核空間；另一方面一個(gè)用戶(hù)態(tài)程序如果想要收集這些系統信息，必然需要進(jìn)行用戶(hù)態(tài)與內核態(tài)之間的數據交互，而頻繁的用戶(hù)態(tài)與內核態(tài)之間的數據交互又會(huì )給系統性能帶來(lái)負面影響。

那么這兩個(gè)問(wèn)題有沒(méi)有解決的方法呢？應該講社區中的開(kāi)發(fā)人員就第二個(gè)問(wèn)題比較容易達成一致，既然在用戶(hù)態(tài)對系統的負載情況進(jìn)行采集和分析存在這樣那樣的問(wèn)題，那么更加合理的做法就是應該將這部分工作交由內核負責。但是第一個(gè)問(wèn)題呢？第一個(gè)問(wèn)題最直觀(guān)的解決方案就是降低對系統負載進(jìn)行采樣分析的時(shí)間間隔，這樣powersaved就能盡早的對系統負載的變化做出及時(shí)的響應。然而這種簡(jiǎn)單的降低采樣分析的時(shí)間間隔的方案同樣存在著(zhù)兩方面的問(wèn)題，一方面這意味著(zhù)更加頻繁的用戶(hù)態(tài)與內核態(tài)之間的數據交互，因此必然也就意味著(zhù)對系統性能帶來(lái)更大的負面影響；另一方面的主要原因在于當時(shí)各個(gè)CPU生產(chǎn)廠(chǎng)家的變頻技術(shù)在硬件上仍不完善，具體體現就是在對CPU進(jìn)行變頻設置時(shí)所需的操作時(shí)間過(guò)長(cháng)，例如Intel早期的Speedstep技術(shù)在對CPU進(jìn)行變頻設置時(shí)需要耗時(shí)250微秒，在此過(guò)程中CPU無(wú)法正常執行指令。讀者如果簡(jiǎn)單的計算一下不難發(fā)現，即使對于一個(gè)主頻為1GHz的CPU而言，250微秒也意味著(zhù)250,000個(gè)時(shí)鐘周期，在這期間CPU完全可以執行完上萬(wàn)條指令。因此從這個(gè)角度而言，簡(jiǎn)單的降低采樣分析的時(shí)間間隔對系統性能帶來(lái)的負面影響更加嚴重。幸運的是隨著(zhù)硬件技術(shù)的不斷完善和改進(jìn)，對CPU進(jìn)行變頻設置所需的操作時(shí)間已經(jīng)顯著(zhù)降低，例如Intel最新的EnhancedSpeedstep技術(shù)在對CPU進(jìn)行變頻設置時(shí)耗時(shí)已降至10微秒，下降了不止一個(gè)數量級。正是這種CPU硬件技術(shù)的發(fā)展為內核開(kāi)發(fā)人員解決這些早期的遺留問(wèn)題提供了契機，Venkatesh等人提出并設計實(shí)現了一個(gè)新的名為ondemand的governor，它正是人們長(cháng)期以來(lái)希望看到的一個(gè)完全在內核態(tài)下工作并且能夠以更加細粒度的時(shí)間間隔對系統負載情況進(jìn)行采樣分析的governor。在介紹ondemandgovernor的具體實(shí)現之前，我們先來(lái)看一下如何使用ondemandgovernor及其向用戶(hù)提供了哪些操作接口。通過(guò)cpufreq-set將ondemand設置為當前所使用的governor之后，在/sys/devices/system/cpu/cpuX/cpufreq目錄下會(huì )出現一個(gè)名為ondemand的子目錄

$sudocpufreq-set-gondemand
$ls/sys/devices/system/cpu/cpu0/cpufreq/ondemand/
ignore_nice_load
powersave_bias
sampling_rate
sampling_rate_max
sampling_rate_min
up_threshold
$sudocatsampling_rate_minsampling_ratesampling_rate_max
40000
80000
40000000
$sudocatup_threshold
30



在這個(gè)子目錄下名字以sampling打頭的三個(gè)文件分別給出了ondemandgovernor允許使用的最短采樣間隔，當前使用的采樣間隔以及允許使用的最長(cháng)采樣間隔，三者均以微秒為單位。以筆者的電腦為例，ondemandgovernor每隔80毫秒進(jìn)行一次采樣。另外比較重要的一個(gè)文件是up_threshold，它表明了系統負載超過(guò)什么百分比時(shí)ondemandgovernor會(huì )自動(dòng)提高CPU的運行頻率。以筆者的電腦為例，這個(gè)數值為30%。那么這個(gè)表明系統負載的百分比數值是如何得到的呢？在支持Intel最新的EnhancedSpeedstep技術(shù)的CPU中，在處理器硬件中直接提供了兩個(gè)MSR寄存器（ModelSpecificRegister）供ondemandgovernor采樣分析系統負載情況使用。這兩個(gè)MSR寄存器的名字分別為IA32_MPERF和IA32_APERF[5]，其中IA32_MPERFMSR中的MPERF代表MaximumPerformance，IA32_APERFMSR中的APERF代表ActualPerformance。就像這兩個(gè)MSR的名字一樣，IA32_MPERFMSR寄存器是一個(gè)當CPU處在A(yíng)CPIC0狀態(tài)下時(shí)按照CPU硬件支持的最高運行頻率每隔一個(gè)時(shí)鐘周期加一的計數器；IA32_APERFMSR寄存器是一個(gè)當CPU處在A(yíng)CPIC0狀態(tài)下時(shí)按照CPU硬件當前的實(shí)際運行頻率每隔一個(gè)時(shí)鐘周期加一的計數器。有了這兩個(gè)寄存器的存在，再考慮上CPU處于A(yíng)CPIC0和處于A(yíng)CPIC1、C2、C3三種狀態(tài)下的時(shí)間比例，也就是CPU處于工作狀態(tài)和休眠狀態(tài)的時(shí)間比例，ondemandgovernor就可以準確的計算出CPU的負載情況了。

得到了CPU的負載情況，接下來(lái)的問(wèn)題就是如何選擇CPU合適的運行頻率了。剛剛在前面提到，當系統負載超過(guò)up_threshold所設定的百分比時(shí)，ondemandgovernor將會(huì )自動(dòng)提高CPU的運行頻率，但是具體提高到哪個(gè)頻率上運行呢？在ondemandgovernor監測到系統負載超過(guò)up_threshold所設定的百分比時(shí)，說(shuō)明用戶(hù)當前需要CPU提供更強大的處理能力，因此ondemandgovernor會(huì )將CPU設置在最高頻率上運行，這一點(diǎn)社區中的開(kāi)發(fā)人員和廣大用戶(hù)都沒(méi)有任何異議。但是當ondemandgovernor監測到系統負載下降，可以降低CPU的運行頻率時(shí)，到底應該降低到哪個(gè)頻率呢？ondemandgovernor的最初實(shí)現是在可選的頻率范圍內調低至下一個(gè)可用頻率，例如筆者使用的CPU支持三個(gè)可選頻率，分別為1.67GHz、1.33GHz和1GHz，如果CPU運行在1.67GHz時(shí)ondemandgovernor發(fā)現可以降低運行頻率，那么1.33GHz將被選作降頻的目標頻率。這種降頻策略的主導思想是盡量減小對系統性能的負面影響，從而不會(huì )使得系統性能在短時(shí)間內迅速降低以影響用戶(hù)體驗。但是在ondemandgovernor的這種最初實(shí)現版本在社區發(fā)布后，大量用戶(hù)的使用結果表明這種擔心實(shí)際上是多余的，ondemandgovernor在降頻時(shí)對于目標頻率的選擇完全可以更加激進(jìn)。因此最新的ondemandgovernor在降頻時(shí)會(huì )在所有可選頻率中一次性選擇出可以保證CPU工作在80%以上負荷的頻率，當然如果沒(méi)有任何一個(gè)可選頻率滿(mǎn)足要求的話(huà)則會(huì )選擇CPU支持的最低運行頻率。大量用戶(hù)的測試結果表明這種新的算法可以在不影響系統性能的前提下做到更高效的節能。在算法改進(jìn)后，ondemandgovernor的名字并沒(méi)有改變，而ondemandgovernor最初的實(shí)現也保存了下來(lái)，并且由于其算法的保守性而得名conservative。


支持IntelEnhancedSpeedstep技術(shù)的CPU驅動(dòng)程序的實(shí)現

前文在討論cpufreq的軟件結構時(shí)已經(jīng)指出，cpufreq從設計上將CPU變頻的policy與mechanism分離開(kāi)來(lái)并由上層的governor負責決定CPU合適的工作頻率。但是在governor根據系統負載的變化決定調整CPU的運行頻率時(shí)，最終還是需要底層與CPU相關(guān)的特定驅動(dòng)程序完成設置CPU運行頻率的任務(wù)。這里向讀者介紹一下支持Intel最新的EnhancedSpeedstep技術(shù)的CPU驅動(dòng)程序的實(shí)現原理，關(guān)注的重點(diǎn)是如何對CPU進(jìn)行變頻設置。實(shí)際上支持IntelEnhancedSpeedstep技術(shù)的處理器為用戶(hù)提供了非常簡(jiǎn)單的編程接口，對CPU運行頻率進(jìn)行設置是通過(guò)一個(gè)名為IA32_PERF_CTL的MSR寄存器進(jìn)行的，另外還有一個(gè)名為IA32_PERF_STATUS的MSR寄存器可供檢查CPU當前所處的運行頻率。當用戶(hù)需要對CPU運行頻率進(jìn)行設置時(shí)只需按照Intel開(kāi)發(fā)手冊的說(shuō)明向IA32_PERF_CTLMSR寄存器中寫(xiě)入規定的數值即可。

總結及未來(lái)的發(fā)展方向

本文為讀者介紹了變頻技術(shù)在CPU硬件上的出現以及Linux內核中最初的實(shí)現存在的各種問(wèn)題，并由此導致了cpufreq這一新的內核子系統的誕生。雖然早期的cpufreq模塊所提供的三種governors能夠在一定程度下滿(mǎn)足用戶(hù)的需要并且提供了一定的靈活性，但是由于受到當時(shí)CPU硬件技術(shù)水平的限制，仍然有很多不盡如人意的地方。之后隨著(zhù)CPU變頻硬件技術(shù)的不斷發(fā)展，尤其是IntelEnhancedSpeedstep技術(shù)的出現，原有的技術(shù)障礙被打破，隨之而來(lái)的是cpufreq內核子系統有了一個(gè)全新的更加完善而高效的ondemandgovernor。

由此不難看出，內核中的cpufreq子系統是由于CPU硬件變頻技術(shù)的出現而出現，同時(shí)也在隨著(zhù)CPU硬件變頻技術(shù)的發(fā)展而發(fā)展。這其實(shí)也預示著(zhù)內核中cpufreq子系統未來(lái)的發(fā)展方向，即繼續跟隨CPU硬件變頻技術(shù)的發(fā)展腳步與時(shí)俱進(jìn)。在本文的最后簡(jiǎn)單為讀者介紹一下在Intel最新的CPU中針對硬件變頻支持的一項新技術(shù)。前文提到在支持Intel最新的EnhancedSpeedstep技術(shù)的CPU中提供了名字分別為IA32_MPERF和IA32_APERF的兩個(gè)MSR寄存器，以便為cpufreq模塊所使用的governor動(dòng)態(tài)收集系統的負載情況提供直接的硬件支持。其中IA32_APERFMSR寄存器當CPU處在A(yíng)CPIC0狀態(tài)下時(shí)按照CPU硬件當前的實(shí)際運行頻率每隔一個(gè)時(shí)鐘周期加一。Intel最新的處理器中進(jìn)一步考慮了CPU在運行過(guò)程中由于訪(fǎng)問(wèn)內存或IO等原因可能會(huì )出現流水線(xiàn)停擺的狀況時(shí)，IA32_APERF以前這種簡(jiǎn)單的按照CPU當前實(shí)際運行頻率每隔一個(gè)時(shí)鐘周期加一的做法并不能完全準確的反映CPU的負載情況。在Intel最新的處理器中如果出現流水線(xiàn)停擺的情況，IA32_APERF將暫時(shí)停止累加，而是在對用戶(hù)真正“有用”的時(shí)間周期才會(huì )遞增，這樣CPU硬件就可以為cpufreq模塊所使用的governor提供比以前更加準確的系統負載統計信息。