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

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

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

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

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

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

$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的由來及其實現(xiàn)

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

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

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



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

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



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

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


支持IntelEnhancedSpeedstep技術(shù)的CPU驅(qū)動程序的實現(xiàn)

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

總結(jié)及未來的發(fā)展方向

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

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