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

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

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

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

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

　　總結及未來的發展方向

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

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