電子發(fā)燒友App
前言
本系列文章將結(jié)合近年來不斷在各種硬件（包括 CPU、芯片組、PCI Express 等各種最新總線標準以及外設）上新增的節(jié)能技術(shù)。
從 Linux? 2.6內(nèi)核及整個 software stack （包括 kernel、middleware 以及各種用戶態(tài) utility）如何添加對這些創(chuàng)新的節(jié)能技術(shù)的支持這一角度，為讀者介紹 Linux 操作系統(tǒng)近幾年來在電源管理方面所取得的長足進步以及未來的發(fā)展方向。
作為本系列文章的開篇之作，首先要向大家介紹的是 cpufreq，它是 Linux 2.6內(nèi)核為了更好的支持近年來在各款主流CPU 處理器中出現(xiàn)的變頻技術(shù)而新增的一個內(nèi)核子系統(tǒng)。
Cpufreq 的由來
隨著 energy efficient computing 和 performance per watt 等概念的推廣以及高級配置與電源接口ACPI（Advanced Configuration and Power Interface）標準的發(fā)展，目前市場上的主流 CPU 都提供了對變頻（frequency scaling）技術(shù)的支持。例如Intel?處理器所支持的 Enhanced SpeedStep? 技術(shù)和 AMD? 處理器所支持的 PowerNow！ ? 技術(shù)，另外像最新的PowerPC?、ARM?、SPARC? 和 SuperH? 等處理器中也提供了類似的支持。參考資料中列出了當前 Linux 2.6內(nèi)核所支持的具備變頻技術(shù)的處理器。需要注意的是，這里要討論的變頻技術(shù)與大家以前所熟知的超頻是兩個不同的概念。超頻是指通過提高核心電壓等手段讓處理器工作在非標準頻率下的行為，這往往會造成 CPU 使用壽命縮短以及系統(tǒng)穩(wěn)定性下降等嚴重后果。
而變頻技術(shù)是指CPU硬件本身支持在不同的頻率下運行，系統(tǒng)在運行過程中可以根據(jù)隨時可能發(fā)生變化的系統(tǒng)負載情況動態(tài)在這些不同的運行頻率之間進行切換，從而達到對性能和功耗做到二者兼顧的目的。
雖然多個處理器生產(chǎn)廠家都提供了對變頻技術(shù)的支持，但是其硬件實現(xiàn)和使用方法必然存在著細微甚至巨大的差別。這就使得每個處理器生產(chǎn)廠家都需要按照其特殊的硬件實現(xiàn)和使用方法向內(nèi)核中添加代碼，從而讓自己產(chǎn)品中的變頻技術(shù)在 Linux 中得到支持和使用。然而，這種內(nèi)核開發(fā)模式所導致的后果是各個廠家的實現(xiàn)代碼散落在 Linux 內(nèi)核代碼樹的各個角落里，各種不同的實現(xiàn)之間沒有任何代碼是共享的，這給內(nèi)核的維護以及將來添加對新的產(chǎn)品的支持都帶來了巨大的開銷，并直接導致了 cpufreq 內(nèi)核子系統(tǒng)的誕生。實際上，正如前文所說，發(fā)明變頻技術(shù)的目的是為了能夠讓系統(tǒng)在運行過程中隨時根據(jù)系統(tǒng)負載的變化動態(tài)調(diào)整 CPU 的運行頻率。這件事情可以分為兩個部分，一部分是“做什么”的問題，另一部分是“怎么做”的問題?！白鍪裁础笔侵溉绾胃鶕?jù)系統(tǒng)負載的動態(tài)變化挑選出 CPU 合適的運行頻率，而“怎么做”就是要按照選定的運行頻率在選定的時間對 CPU 進行設置，使之真正工作在這一頻率上。這也就是我們在軟件設計中經(jīng)常會遇到的機制 mechanism 與策略 policy 的問題，而設計良好的軟件會在架構(gòu)上保證二者是被清晰的隔離開的并通過規(guī)范定義的接口進行通信。
Cpufreq 的設計和使用
為了解決前文所提到的問題，一個新的內(nèi)核子系統(tǒng)—— cpufreq 應運而生了。Cpufreq 為在Linux 內(nèi)核中更好的支持不同 CPU 的變頻技術(shù)提供了一個統(tǒng)一的設計框架，其軟件結(jié)構(gòu)如圖 1 所示。
圖 1. Cpufreq 的軟件結(jié)構(gòu)
?????? 如圖 1 所示，cpufreq 在設計上主要分為以下三個模塊：
Cpufreq 模塊（cpufreq module）對如何在底層控制各種不同CPU 所支持的變頻技術(shù)以及如何在上層根據(jù)系統(tǒng)負載動態(tài)選擇合適的運行頻率進行了封裝和抽象，并在二者之間定義了清晰的接口，從而在設計上完成了前文所提到的對 mechanism 與policy 的分離。
在 cpufreq 模塊的底層，各個CPU 生產(chǎn)廠商只需根據(jù)其變頻技術(shù)的硬件實現(xiàn)和使用方法提供與其 CPU 相關(guān)的變頻驅(qū)動程序（CPU-specific drivers），例如 Intel 需要提供支持Enhanced SpeedStep 技術(shù)的 CPU 驅(qū)動程序，而 AMD 則需要提供支持 PowerNow！ 技術(shù)的 CPU 驅(qū)動程序。
在 cpufreq 模塊的上層，governor 作為選擇合適的目標運行頻率的決策者，根據(jù)一定的標準在適當?shù)臅r刻選擇出 CPU 適合的運行頻率，并通過 cpufreq 模塊定義的接口操作底層與 CPU 相關(guān)的變頻驅(qū)動程序，將 CPU 設置運行在選定的運行頻率上。
目前最新的 Linux 內(nèi)核中提供了 performance 、powersave 、userspace、conservative 和 ondemand 五種 governors 供用戶選擇使用，它們在選擇 CPU 合適的運行頻率時使用的是各自不同的標準并分別適用于不同的應用場景。用戶在同一時間只能選擇其中一個 governor 使用，但是可以在系統(tǒng)運行過程中根據(jù)應用需求的變化而切換使用另一個 governor 。
這種設計帶來的好處是使得 governor 和 CPU 相關(guān)的變頻驅(qū)動程序的開發(fā)可以相互獨立進行，并在最大限度上實現(xiàn)代碼重用，內(nèi)核開發(fā)人員在編寫和試驗新的 governor 時不會再陷入到某款特定 CPU 的變頻技術(shù)的硬件實現(xiàn)細節(jié)中去，而 CPU 生產(chǎn)廠商在向 Linux 內(nèi)核中添加支持其特定的 CPU 變頻技術(shù)的代碼時只需提供一個相對來說簡單了很多的驅(qū)動程序，而不必考慮在各種不同的應用場景中如何選擇合適的運行頻率這些復雜的問題。
內(nèi)核中的 cpufreq 子系統(tǒng)通過 sysfs 文件系統(tǒng)向上層應用提供了用戶接口，對于系統(tǒng)中的每一個 CPU 而言，其 cpufreq 的 sysfs 用戶接口位于 /sys/devices/system/cpu/cpuX/cpufreq/ 目錄下，其中 X 代表 processor id ，與 /proc/cpuinfo 中的信息相對應。以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 當前所處的運行頻率。雖然 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 當前運行頻率，而不會對 CPU 硬件寄存器進行檢查。 scaling_available_governors 會告訴用戶當前有哪些 governors 可供用戶使用，而 scaling_driver 則會顯示該 CPU 所使用的變頻驅(qū)動程序。 Stats 目錄下給出了對 CPU 各種運行頻率的使用統(tǒng)計情況，例如 CPU 在各種頻率下的運行時間以及在各種頻率之間的變頻次數(shù)。 Ondemand 目錄則與 ondemand governor 相關(guān)，在后文會進行相應的介紹。
通過以上的介紹，大家對如何使用 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
cpufrequtils 002： cpufreq-info （C） Dominik Brodowski
2004-2006
Report errors and bugs to linux@brodo.de， please.
analyzing CPU 0：
driver： acpi-cpufreq
CPUs which need to switch frequency at the same time：
0 1
hardware limits： 1000 MHz - 1.67 GHz
available frequency steps： 1.67 GHz， 1.33 GHz， 1000
MHz
available cpufreq governors： userspace， conservative，
ondemand， powersave， performance
current policy： frequency should be within 1000 MHz
and 1.67 GHz.
The governor “ondemand” may decide which
speed to use
within this range.
current CPU frequency is 1000 MHz.
analyzing CPU 1：
driver： acpi-cpufreq
CPUs which need to switch frequency at the same time：
0 1
hardware limits： 1000 MHz - 1.67 GHz
available frequency steps： 1.67 GHz， 1.33 GHz， 1000
MHz
available cpufreq governors： userspace， conservative，
ondemand， powersave， performance
current policy： frequency should be within 1000 MHz
and 1.67 GHz.
The governor “ondemand” may decide which
speed to use
within this range.
current CPU frequency is 1000 MHz.
Ondemand governor 的由來及其實現(xiàn)剛剛我們在 cpufreq-info 的輸出中可以看到 cpufreq 子系統(tǒng)一共提供了五種 governors 供用戶選擇使用，它們分別是 userspace，conservative，ondemand，powersave 和performance。在最新的內(nèi)核中如果用戶不進行額外設置的話，ondemand 會被作為默認的 governor 使用。為了理解是什么原因造成了這種現(xiàn)狀，我們在這里帶領讀者回顧一下 cpufreq 子系統(tǒng)中的governor在內(nèi)核中的開發(fā)歷史。
Cpufreq 作為一個子系統(tǒng)最早被加入到 Linux 內(nèi)核中時只配備了三個governors ，分別是performance、powersave 和userspace。當用戶選擇使用 performance governor 時，CPU會固定工作在其支持的最高運行頻率上；當用戶選擇使用powersave governor 時，CPU會固定工作在其支持的最低運行頻率上。因此這兩種 governors 都屬于靜態(tài) governor ，即在使用它們時 CPU 的運行頻率不會根據(jù)系統(tǒng)運行時負載的變化動態(tài)作出調(diào)整。這兩種 governors 對應的是兩種極端的應用場景，使用 performance governor 體現(xiàn)的是對系統(tǒng)高性能的最大追求，而使用 powersave governor 則是對系統(tǒng)低功耗的最大追求。雖然這兩種應用需求確實存在，但大多數(shù)用戶在大部分時間里需要的是更加靈活的變頻策略。最早的 cpufreq 子系統(tǒng)通過 userspace governor 為用戶提供了這種靈活性。正如它的名字一樣，使用 userspace governor 時，系統(tǒng)將變頻策略的決策權(quán)交給了用戶態(tài)應用程序，并提供了相應的接口供用戶態(tài)應用程序調(diào)節(jié) CPU 運行頻率使用。通過使用 cpufrequtils 工具包中的 cpufreq-set 將 userspace 設置為 cpufreq 子系統(tǒng)所使用的 governor 后，我們可以看到與之前相比在 /sys/devices/system/cpu/cpuX/cpufreq/ 目錄下多出了一個名為 scaling_setspeed 的文件，這正是 userspace governor 所提供的特殊用戶接口。用戶可以通過向該文件寫入任何一個 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 時，系統(tǒng)將變頻策略的決策權(quán)交給了用戶態(tài)應用程序。該用戶態(tài)應用程序一般是一個 daemon 程序，每隔一定的時間間隔收集一次系統(tǒng)信息并根據(jù)系統(tǒng)的負載情況使用 userspace governor 提供的 scaling_setspeed 接口動態(tài)調(diào)整 CPU 的運行頻率。作為這個daemon 程序，當時在幾個主要的 Linux 發(fā)行版中使用的一般是 powersaved 或者 cpuspeed。這兩個 daemon 程序一般每隔幾秒鐘統(tǒng)計一次 CPU 在這個采樣周期內(nèi)的負載情況，并根據(jù)統(tǒng)計結(jié)果調(diào)整 CPU 的運行頻率。這種 userspace governor 加用戶態(tài) daemon 程序的變頻方法雖然為用戶提供了一定的靈活性，但通過開源社區(qū)的廣泛使用所得到的意見反饋逐漸暴露了這種方法的兩個嚴重缺陷。第一個是性能方面的問題。例如powersaved 每隔五秒鐘進行一次系統(tǒng)負載情況的采樣分析的話，我們可以分析一下在下面給出的應用場景中的用戶體驗。假設 powersaved 的采樣分析剛剛結(jié)束，而且由于在剛剛結(jié)束的采樣周期內(nèi)系統(tǒng)負載很低，CPU 被設置在最低頻率上運行。這時用戶如果打開 Firefox? 等對 CPU 運算能力要求相當高的程序的話，powersaved 要在下一個采樣點——大約五秒鐘之后才有機會觀察到這種提高 CPU 運行頻率的需求。也就是說，在Firefox 啟動之初的五秒鐘內(nèi) CPU 的計算能力并沒有被充分發(fā)揮出來，這無疑會使用戶體驗大打折扣。第二個是系統(tǒng)負載情況的采樣分析的準確性問題。將監(jiān)控系統(tǒng)負載情況并對未來 CPU 的性能需求做出判斷的任務交給一個用戶態(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)性能帶來負面影響。
?????
工商網(wǎng)監(jiān)
評論