如何設置 Linux 以獲得完整的 AMD APU 電源管理支持：Turbo Core、Cool’n’Quiet、動態電源管理？
我的目標是在空閒模式下建立一個低功耗的迷你伺服器（不是 HTPC），但在使用時提供良好的性能。重點更多的是數據安全而不是可用性。換句話說：優質零件，但僅用於儲存的冗餘。
不認為自己有偏見，經過一些研究，我覺得一些 AMD 桌面 APU 會提供很好的價值。
剩下的問題是：
- GPU的空閒狀態是否會降低功耗並為CPU釋放資源？
- Cool’n’Quiet 和 Turbo Core 是否會在空閒模式下實現預期的低功耗，但在負載下表現出色？
- Linux 會按預期支持這種情況嗎？相當多的問題和論壇討論似乎表明情況並非如此。
$$ Edit: Concluding thoughts regarding the processor choice $$
AMD 與 AMD：
- Richland 在這裡做得比 Trinity 好得多。
- Kaveri 無法與 Richland 的空閒模式功耗競爭（至少目前如此）。
- A10-6700的GPU可能被高估了，但它不會被太多使用有點遺憾。一些算法可能能夠部署其計算能力。不過，不知道這將如何影響處理器的功耗。
- 我懷疑 A10-6790K 是與 A10-6700 相同的處理器，只是用於 Turbo Core 提升的參數設置不同。如果這是真的，A10-6790K 由於其更高的 TDP 將能夠在長期內提升更長的時間和/或提供更高的頻率。但是你需要一個不同的 CPU 風扇（想想空間和溫度/壽命）。
AMD A10-6700 與英特爾酷睿 i3-3220：
- A10-6700 有更多的 GPU 能力，這裡沒有用到。
- i3-3220 具有較低的空閒模式功耗。
- 雖然在典型的基準測試中，i3-3220 的計算速度更快，但我看不出它的兩個超執行緒核心如何能夠以四個全功能核心（至少當假設一些嚴重的記憶體時）。不過，沒有找到任何嚴肅的基準——只有一些跡象。
[編輯：自 Linux 3.16 起，免費 radeon 驅動程序的
bapm參數預設設置為 Kaveri、Kabini 和桌面 Trinity、Richland 系統]看$$ pull $$radeon drm-fixes-3.16。
但是，對於基於 3.16 的 Debian，預設值（還沒有？）似乎不起作用，而 boot 參數則起作用。請參閱如何使用 AMD Turbo Core APU 設置 Debian 系統（專注於 2D 或控制台/伺服器）以獲得最大的能源和計算效率？
[編輯：免費的 radeon 驅動程序很快就會有一個
bapm參數]由於下面的底線是在
radeon您的 APU 上使用免費驅動程序的修補版本來支持 Turbo Core 並儘可能充分利用它（3D 圖形除外）（啟用bapm可能會導致某些配置不穩定)，好消息是radeon 的未來版本將有一個參數來啟用 bapm。$$ Original post follows $$
AMD A10-6700 (Richland) APU 體驗
處理器選擇
我的第一台 PC 是 486DX2-66，由幾十個包含 Slackware 源包的 3.5" 磁片組成。從那時起，很多事情都發生了變化，目前很多行業似乎仍處於增加數量的階段產品變體。
這種情況和 AMD 在最近的一些不幸決定並沒有讓我更容易決定微型伺服器的平台。但最後，我決定 A10-6700 將是一個不錯的選擇：
- 一些評論表明，（仍然廣泛不可用的）Kaveri 在空閒模式下會比 Richland 或 Trinity 消耗更多的電量
- Richland A10-6700 相對於 Trinity A10-5700 的優勢似乎很顯著：更低的最低頻率和更高的最高頻率，更細粒度的 Turbo Core（還要考慮溫度——當 GPU 空閒時這是一個相當大的優勢）
- 據說A10-6700的GPU被高估了（行銷驅動的命名），APU的定價似乎還算公道
其他組件和設置
儘管有無數處理器可供選擇，但可用的 Mini-ITX 板並不多。華擎 FM2A78M-ITX+ 似乎是一個合理的選擇。測試是使用韌體 V1.30 完成的（在我寫這篇文章時沒有可用的更新）。
僅應消耗電源標稱輸出的 80%。另一方面，許多在低於 50% 的負載下無法有效工作。對於估計功耗範圍為 35W 至 120W 的系統，很難找到一種節能電源。我使用 Seasonic G360 80+ Gold 進行了這些測試，因為它在低負載效率方面的表現優於大多數競爭對手。
兩個 8GB DDR3-1866 RAM（這樣配置——與 1333 相比確實有所不同）、一個 SSD 驅動器和一個 PWM 控制質量的 CPU 風扇也是測試設置的一部分。
使用 AVM Fritz!DECT 200 進行測量，據報導該 AVM Fritz!DECT 200 可以進行準確的測量。儘管如此，使用舊的無名設備驗證了合理性。沒有發現不一致的地方。測得的系統功耗將包括電源在較低負載下的效率降低。
一種
$$ W $$QHD 螢幕通過 HDMI 連接。 GPU 的初始共享記憶體在 UEFI BIOS 中設置為 32M。此外，板載 GPU 被選為主要，並啟用了 IOMMU。
沒有安裝或配置 X 或其他圖形系統。影片輸出僅限於控制台模式。
基本
有幾件事需要知道。
- 雖然關於 Cool’n’Quiet 的決定是由處理器之外的軟體做出的，但 Turbo Core 是由 APU（或 CPU）上的附加微控制器自主做出的決定。
- 許多工具
/proc和/sys地方都不會報告 Turbo Core 活動。cpufreq-aperf,cpupower frequency-info並且cpupower monitor做，但只在 之後modprobe msr。測試案例組 1：Linux + radeon
我從全新的 Arch Linux（安裝程序 2014.08.01，核心 3.15.7）開始。這裡的關鍵因素是
acpi_cpufreq（核心 CPU 縮放）和radeon（核心 GPU 驅動程序）的存在以及修補radeon.測試案例 1.1：BIOS TC on - CnQ on / Linux OnDemand - Boost
UEFI BIOS Turbo Core 設置.......................... 已啟用 UEFI BIOS Cool'n'Quiet 設置.......................... 已啟用 /sys/devices/system/cpu/cpufreq/boost....... 1 /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor...按需“cpupower 頻率資訊” Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800 觀察到“/proc/cpuinfo”cpu MHz 範圍... 1800 - 3700 觀察到的“cpupower monitor”頻率範圍... 1800 - 3700 /sys/kernel/debug/dri/0/radeon_pm_info... 功率等級 0載入 | 核心頻率 ---------------+----------- 壓力--cpu 1 | 1×3700 壓力--cpu 2 | 2×3700 壓力--cpu 3 | 3×3700 壓力--cpu 4 | 4×3700測試案例 1.2：BIOS TC on - CnQ on / Linux Performance - Boost
UEFI BIOS Turbo Core 設置.......................... 已啟用 UEFI BIOS Cool'n'Quiet 設置.......................... 已啟用 /sys/devices/system/cpu/cpufreq/boost....... 1 /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... 性能“cpupower 頻率資訊” Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800 觀察到“/proc/cpuinfo”cpu MHz 範圍... 3700 觀察到的“cpupower monitor”頻率範圍... 2000 - 3700 /sys/kernel/debug/dri/0/radeon_pm_info... 功率等級 0載入 | 核心頻率 ---------------+----------- 壓力--cpu 1 | 1×3700 壓力--cpu 2 | 2×3700 壓力--cpu 3 | 3×3700 壓力--cpu 4 | 4×3700測試案例組 1 總結
在這種情況下，基於 Turbo Core 的提升是不可能的，因為在某些情況下，由於穩定性問題，
radeon驅動程序目前禁用了該bapm標誌。因此，跳過了進一步的測試。測試案例組 2：Linux + bapm-patched radeon
為了啟用
bapm，我從一個全新的 Arch Linux（安裝程序 2014.08.01，核心 3.15.7）開始，corelinux通過 (3.15.8) 獲得了包ABS，編輯了PKGBUILD要使用的pkgbase=linux-tc，使用 提取源，makepkg --nobuild更改pi->enable_bapm = true;為用. 然後，我安裝了它（和）並更新了（當然是 YMMV）。trinity_dpm_init()``src/linux-3.15/drivers/gpu/drm/radeon/trinity_dpm.c``makepkg --noextract``pacman -U linux-tc-headers-3.15.8-1-x86_64.pkg.tar.xz``pacman -U linux-tc-3.15.8-1-x86_64.pkg.tar.xz``GRUB``grub-mkconfig -o /boot/grub/grub.cfg結果，我可以選擇 boot
linux或linux-tc，以下測試指的是後者。測試案例 2.1：BIOS TC on - CnQ on / Linux OnDemand - Boost
UEFI BIOS Turbo Core 設置.......................... 已啟用 UEFI BIOS Cool'n'Quiet 設置.......................... 已啟用 /sys/devices/system/cpu/cpufreq/boost....... 1 /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor...按需“cpupower 頻率資訊” Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800 觀察到“/proc/cpuinfo”cpu MHz 範圍... 1800 - 3700 觀察到的“cpupower monitor”頻率範圍... 1800 - 4300 /sys/kernel/debug/dri/0/radeon_pm_info... 功率等級 0載入 | 核心頻率 ---------------+----------------- 壓力--cpu 1 | 1×4300 壓力--cpu 2 | 2 x 4200 .. 4100 壓力--cpu 3 | 3 x 4100 .. 3900 壓力--cpu 4 | 4 x 4000 .. 3800測試案例 2.2：BIOS TC on - CnQ on / Linux Performance - Boost
UEFI BIOS Turbo Core 設置.......................... 已啟用 UEFI BIOS Cool'n'Quiet 設置.......................... 已啟用 /sys/devices/system/cpu/cpufreq/boost....... 1 /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... 性能“cpupower 頻率資訊” Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800 觀察到“/proc/cpuinfo”cpu MHz 範圍... 3700 觀察到的“cpupower monitor”頻率範圍... 2000 - 4300 /sys/kernel/debug/dri/0/radeon_pm_info... 功率等級 0載入 | 核心頻率 ---------------+----------------- 壓力--cpu 1 | 1×4300 壓力--cpu 2 | 2 x 4200 .. 4100 壓力--cpu 3 | 3 x 4100 .. 3900 壓力--cpu 4 | 4 x 4000 .. 3800測試案例 2.3：BIOS TC on - CnQ on / Linux OnDemand - No Boost
UEFI BIOS Turbo Core 設置.......................... 已啟用 UEFI BIOS Cool'n'Quiet 設置.......................... 已啟用 /sys/devices/system/cpu/cpufreq/boost....... 0 /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor...按需“cpupower 頻率資訊” Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800 觀察到“/proc/cpuinfo”cpu MHz 範圍... 1800 - 3700 觀察到的“cpupower monitor”頻率範圍... 1800 - 3700 /sys/kernel/debug/dri/0/radeon_pm_info... 功率等級 1載入 | 核心頻率 ---------------+----------- 壓力--cpu 1 | 1×3700 壓力--cpu 2 | 2×3700 壓力--cpu 3 | 3×3700 壓力--cpu 4 | 4×3700測試案例 2.4：BIOS TC on - CnQ on / Linux Performance - No Boost
UEFI BIOS Turbo Core 設置.......................... 已啟用 UEFI BIOS Cool'n'Quiet 設置.......................... 已啟用 /sys/devices/system/cpu/cpufreq/boost....... 0 /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... 性能“cpupower 頻率資訊” Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800 觀察到“/proc/cpuinfo”cpu MHz 範圍... 3700 觀察到的“cpupower monitor”頻率範圍... 2000 - 3700 /sys/kernel/debug/dri/0/radeon_pm_info... 功率等級 1載入 | 核心頻率 ---------------+----------- 壓力--cpu 1 | 1×3700 壓力--cpu 2 | 2×3700 壓力--cpu 3 | 3×3700 壓力--cpu 4 | 4×3700測試案例 2.5：BIOS TC off - CnQ on / Linux OnDemand - Boost
UEFI BIOS Turbo Core 設置.......................... 禁用 UEFI BIOS Cool'n'Quiet 設置.......................... 已啟用 /sys/devices/system/cpu/cpufreq/boost....... 1 /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor...按需“cpupower 頻率資訊” Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800 觀察到“/proc/cpuinfo”cpu MHz 範圍... 1800 - 3700 觀察到的“cpupower monitor”頻率範圍... 1800 - 3700 /sys/kernel/debug/dri/0/radeon_pm_info... 功率等級 0換句話說，如果在 BIOS 中禁用 Turbo Core，則修補程序
radeon不會將其打開。測試案例 2.6：BIOS TC 開啟 - CnQ 關閉 / Linux 不適用
UEFI BIOS Turbo Core 設置.......................... 已啟用 UEFI BIOS Cool'n'Quiet 設置.......................... 已禁用 /sys/devices/system/cpu/cpufreq/boost.... 不適用 /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... 不適用“cpupower 頻率資訊” Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800 觀察到“/proc/cpuinfo”cpu MHz 範圍... 3700 觀察到的“cpupower monitor”頻率範圍... 2000 - 4300 /sys/kernel/debug/dri/0/radeon_pm_info... 功率等級 0載入 | 核心頻率 ---------------+----------------- 壓力--cpu 1 | 1×4300 壓力--cpu 2 | 2 x 4100 .. 4000 壓力--cpu 3 | 3 x 4000 .. 3800 壓力--cpu 4 | 4 x 3900 .. 3700禁用 Cool’n’Qiet 後，Linux 核心將不提供任何調節器選擇，並且（錯誤地）假設核心以固定頻率執行。有趣的是，得到的 Turbo Core 頻率是測試案例組 2 中所有測試組合中最差的。
測試案例組 2 總結
使用修補的
radeon驅動程序，Turbo Core 可以工作。bapm到目前為止，還沒有發現任何不穩定性（這就是那裡禁用 aka Turbo Core 的原因）。測試案例組 3：Linux + fglrx（催化劑）
我從全新的 Ubuntu（14.04 伺服器，核心 3.13）安裝開始，由於存在
acpi_cpufreq（核心 CPU 擴展）和radeon（核心 GPU 驅動程序），我認為它與 Arch Linux（安裝程序 2014.08.01，核心 3.15.7）相當）。切換到 Ubuntu 的原因是易於安裝fglrx. 我使用全新安裝驗證了功耗和行為，它使用radeon.我
fglrx從命令行（sudo apt-get install linux-headers-generic,sudo apt-get install fglrx）安裝並重新啟動系統。從radeon到的變化fglrx在控制台外觀（fglrx：128 x 48radeon，：更高）和空閒模式功耗（fglrx：40W，radeon：30W）方面都非常明顯。但是 Turbo Core 可以立即工作。測試案例 3.1：BIOS TC on - CnQ on / Linux OnDemand - Boost
UEFI BIOS Turbo Core 設置.......................... 已啟用 UEFI BIOS Cool'n'Quiet 設置.......................... 已啟用 /sys/devices/system/cpu/cpufreq/boost....... 1 /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor...按需“cpupower 頻率資訊” Pstates........ 4300 4200 3900 3700 3400 2700 2300 1800 觀察到“/proc/cpuinfo”cpu MHz 範圍... 1800 - 3700 觀察到的“cpupower monitor”頻率範圍... 1800 - 4300 /sys/kernel/debug/dri/0/radeon_pm_info... 不適用載入 | 核心頻率 ---------------+---------------------------- 壓力--cpu 1 | 1×4300 壓力--cpu 2 | 2 x 4200 .. 3900（核心充電） 壓力--cpu 3 | 3 x 4100 .. 3700 壓力--cpu 4 | 4 x 4000 .. 3600這種
fglrx行為絕對很有趣。當為任何測試案例組中的任何測試案例呼叫“stress –cpu 2”時，兩個載入的核心始終位於不同的模組上。但是使用 時fglrx，突然發生了重新分配，因此使用了單個模組（這節省了相當多的電量，見下文）。一段時間後，載入的核心移回另一個模組。這在radeon. 會不會是在fglrx操縱流程的核心親和力？測試案例組 3 總結
優點
fglrx是它可以立即啟用 Turbo Core，而無需對其進行任何修補。因為
fglrx在我們的場景中，在具有 65W TDP 的晶片上浪費了 10 到 12W 的 GPU，所以關於可用核心速度的總體結果並不令人印象深刻。因此，沒有進行進一步的測試。同樣從工程的角度來看， 的行為
fglrx似乎有點可悲。將兩個繁忙的核心中的一個重新分配給另一個模組以保持更高的頻率可能不是一個好主意，因為在這一步之前，兩個核心都有自己的二級記憶體，而之後，它們必須共享一個。是否fglrx考慮任何指標（例如記憶體命中未命中）來支持其決定將不得不單獨澄清，但還有其他關於其突然行為的報告。功耗總結
下表中的一些 delta 值會隨著溫度的升高而略微變差；有人可能會說 PWM 控制的風扇和晶片都在那裡發揮作用。
系統 @State / -> 轉換增量 | 系統功耗 -------------------------------------+------------------------- @BIOS | @ 95 .. 86W @Bootloader | @108 .. 89W @Ubuntu 安裝程序空閒 | @ 40W @Linux radeon 空閒點播 | @ 30W @Linux radeon 空閒性能 | @ 30W @Linux fglrx 空閒按需 | @ 40W 1 模組 1800 -> 3700 | + 13W 1 模組 1800 -> 4300 | + 25W 1 核 1800 -> 3700 | + 5W 1 核 1800 -> 4300 | + 10W “radeon”影片輸出->禁用| - 2W 'fglrx" 影片輸出 -> 變暗 | +- 0W @Linux radeon 最大值 | @103 .. 89W @Linux fglrx 最大值 | @105 .. 92W
Turbo Core（至少對於 Richland APU 而言）似乎比預期的要多：與“性能”調節器到位相比，“按需”縮放調節器到位時的功耗沒有明顯差異。Althouth
/proc/cpuinfo總是會在性能調節器下報告 37000MHz，cpupower monitor會顯示核心確實變慢了。在某些情況下，顯示的頻率低至 2000MHz；內部也可能使用 1800MHz。A10-6700 由兩個模組組成，每個模組有兩個核心。例如，如果兩個核心處於空閒狀態，而兩個核心處於繁忙狀態並得到加速，則係統行為將根據繁忙核心是否位於同一模組上而有所不同。
- 加速模組比加速核心更耗能。
- L2 記憶體是按模組分配的。
在同一模組上加速與在不同模組上加速的兩個核心的功耗之間的差異是通過替換
stress --cpu 2（這總是導致兩個模組之間的分佈）來確定的。taskset -c 0 stress --cpu 1andtaskset -c 1 stress --cpu 1A10-6700 似乎對 APU 有一個總功耗限制（92W 連同其他組件），僅為 GPU 保留了一點點（3 W）。使用
radeon，它將在短時間內允許更多，並非常平穩地降低到最大值，而使用fglrx，已經觀察到這些限制被更明顯地超過，然後功耗突然降低。雖然許多人聲稱 Kaveri 可用性的延遲是 AMD 的意圖，因為它會殺死他們目前的 APU，但我不敢苟同。Richland A10 展現了出色的電源管理，Kaveri 無法與其低空閒狀態功耗競爭（Kaveri 的晶片複雜度幾乎是 Richland 的兩倍，因此還需要一兩個開發步驟）。
總體結論
- 在 Turbo Core 邏輯中包含溫度（正如 Trinity -> Richland 步驟所報告的那樣）似乎是有道理的並且似乎執行良好，這可以從 BIOS 和 Bootloader 中的功率耗散隨著時間的推移而減少中看出。
- 對於主機/伺服器場景，A10-6700 長期支持 4 核 @3700MHz（Turbo Core 為 3800MHz），至少在
radeon驅動方面是這樣。當 GPU 有一些工作要做時，可能沒有太多機會保持這個性能水平。- 在滿載情況下，似乎可以永久超過 65W TDP，但很難判斷，因為電源在 30W 時的效率較低。由於有明確的跡象表明考慮了溫度（在開始降低到 90W 之前觀察到幾乎 110W 的峰值功耗，並且有一段時間報告了 4300 MHz 的 2 個核心），投資 APU 冷卻可能是好主意。但是，僅限於 65W TDP 的主機板只能提供這麼大的電流，因此 APU 肯定會有硬性限制。
- 如果您打算在 Linux 下使用 Richland APU 進行計算，那麼您肯定需要使用打更新檔的
radeon驅動程序（如果您沒有遇到不穩定性——特別是與啟用動態電源管理相結合）。否則，您將無法獲得全部價值。- 奇怪的是，似乎最好的設置是在 BIOS 中同時啟用 Turbo Core 和 Cool’n’Quiet，然後選擇
performance縮放調節器——至少如果你的 APU 表現得像這裡測試的那樣。您將擁有與 with 相同的功耗，ondemand但更快的頻率縮放和更少的核心成本來做出縮放決策。致謝
特別感謝 Alex Deucher，他在 bugzilla.kernel.org 將我推向了正確的方向。
免費驅動程序的質量給我留下了深刻的印象，
radeon並感謝整個團隊維護這個軟體，它似乎是經過深思熟慮的設計。如果radeon不這樣做，那麼我支持 A10-6700 的決定就大錯特錯了。