Linux2.6內核中的最新電源管理技術(shù)綜述

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

　　# cpufreq-set -g userspace

　　# cat cpuinfo_cur_freq

　　1000000

　　# cat scaling_available_frequencies

　　1667000 1333000 1000000

　　# echo 1333000 》scaling_setspeed

　　# cat cpuinfo_cur_freq

　　1333000

　　剛剛提到在使用 userspace governor 時(shí)，系統將變頻策略的決策權交給了用戶(hù)態(tài)應用程序。該用戶(hù)態(tài)應用程序一般是一個(gè) daemon 程序，每隔一定的時(shí)間間隔收集一次系統信息并根據系統的負載情況使用 userspace governor 提供的 scaling_setspeed 接口動(dòng)態(tài)調整 CPU 的運行頻率。作為這個(gè)daemon 程序，當時(shí)在幾個(gè)主要的 Linux 發(fā)行版中使用的一般是 powersaved 或者 cpuspeed。這兩個(gè) daemon 程序一般每隔幾秒鐘統計一次 CPU 在這個(gè)采樣周期內的負載情況，并根據統計結果調整 CPU 的運行頻率。這種 userspace governor 加用戶(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 最新的 Enhanced Speedstep 技術(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。在介紹 ondemand governor 的具體實(shí)現之前，我們先來(lái)看一下如何使用 ondemand governor 及其向用戶(hù)提供了哪些操作接口。通過(guò) cpufreq-set 將 ondemand 設置為當前所使用的 governor 之后，在 /sys/devices/system/cpu/cpuX/cpufreq 目錄下會(huì )出現一個(gè)名為 ondemand 的子目錄

　　$ sudo cpufreq-set -g ondemand

　　$ ls /sys/devices/system/cpu/cpu0/cpufreq/ondemand/

　　ignore_nice_load

　　powersave_bias

　　sampling_rate

　　sampling_rate_max

　　sampling_rate_min

　　up_threshold

　　$ sudo cat sampling_rate_min sampling_rate

　　sampling_rate_max

　　40000

　　80000

　　40000000

　　$ sudo cat up_threshold

　　30

　　在這個(gè)子目錄下名字以 sampling 打頭的三個(gè)文件分別給出了ondemand governor 允許使用的最短采樣間隔，當前使用的采樣間隔以及允許使用的最長(cháng)采樣間隔，三者均以微秒為單位。

　　以筆者的電腦為例， ondemand governor 每隔 80 毫秒進(jìn)行一次采樣。另外比較重要的一個(gè)文件是 up_threshold ，它表明了系統負載超過(guò)什么百分比時(shí)ondemand governor 會(huì )自動(dòng)提高CPU 的運行頻率。以筆者的電腦為例，這個(gè)數值為 30% 。那么這個(gè)表明系統負載的百分比數值是如何得到的呢？在支持Intel 最新的 Enhanced Speedstep 技術(shù)的 CPU 中，在處理器硬件中直接提供了兩個(gè) MSR 寄存器（Model Specific Register）供 ondemand governor 采樣分析系統負載情況使用。這兩個(gè) MSR 寄存器的 名字分別為 IA32_MPERF 和 IA32_APERF［5］ ，其中 IA32_MPERF MSR 中的 MPERF 代表Maximum Performance ， IA32_APERF MSR 中的 APERF 代表Actual Performance 。就像這兩個(gè) MSR 的名字一樣， IA32_MPERF MSR 寄存器是一個(gè)當 CPU 處在 ACPI C0 狀態(tài)下時(shí)按照 CPU 硬件支持的最高運行頻率每隔一個(gè)時(shí)鐘周期加一的計數器；IA32_APERF MSR 寄存器是一個(gè)當 CPU 處在 ACPI C0 狀態(tài)下時(shí)按照 CPU 硬件當前的實(shí)際運行頻率每隔一個(gè)時(shí)鐘周期加一的計數器。有了這兩個(gè)寄存器的存在，再考慮上 CPU 處于A(yíng)CPI C0 和處于 ACPI C1、C2、C3 三種狀態(tài)下的時(shí)間比例，也就是 CPU 處于工作狀態(tài)和休眠狀態(tài)的時(shí)間比例， ondemand governor 就可以準確的計算出 CPU 的負載情況了。

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

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