Linuxを完全なAMDに設定する方法APU電源管理サポート：Turbo Core、Cool'n'Quiet、Dynamic Power Management？
私の目的は、アイドルモードでの消費電力が少なく、使用時に優れたパフォーマンスを提供する（HTPCではなく）ミニサーバーをセットアップすることです。焦点は可用性よりもデータの安全性にあります。つまり、高品質のパーツですが、冗長性はストレージのみです。
偏見があるとは考えていませんでしたが、いくつかの調査の結果、AMDデスクトップAPUの中には優れた価値を提供するものがあると感じました。
残りの質問は次のとおりです。
- GPUのアイドル状態は、電力消費を削減し、CPUのリソースを解放しますか？
- Cool'n'QuietとTurbo Coreは、アイドルモードでは意図した低消費電力を実現しますが、負荷がかかった状態ではパフォーマンスを発揮しますか？
- Linuxはこのシナリオを意図したとおりにサポートしますか？かなりの数の質問とフォーラムのディスカッションは、これが必ずしもそうではないことを示唆しているようです。
[編集：プロセッサの選択に関する結論]
- AMD対AMD：
- リッチランドはトリニティよりもはるかに優れた仕事をしています。
- カベリはリッチランドのアイドルモードの電力消費と競合することはできません（少なくとも現時点では）。
- A10-6700のGPUは過大評価されている可能性がありますが、あまり使用されないのは少し悲しいです。一部のアルゴリズムは、その計算能力を活用できる場合があります。しかし、それがプロセッサの電力消費にどのように影響するかはわかりません。
- A10-6790Kは、ターボコアブースト用に設定されたパラメーターが異なるだけで、A10-6700と同じプロセッサーであると思います。これが本当である場合、A10-6790KはTDPが高いため、長期的にブーストしたり、長期的に高い周波数を提供したりできます。ただし、そのためには別のCPUファンが必要になります（スペースと温度/寿命を考えてください）。
- AMD A10-6700対Intel Core i3-3220：
- A10-6700には、ここでは使用されていない、より多くのGPUパワーがあります。
- I3-3220のアイドルモード消費電力は低くなっています。
- 典型的なベンチマークでは、i3-3220の方が計算は高速ですが、2つのハイパースレッディングコアが4つのフル機能のコア（少なくとも、Webフロントエンドを備えたデータベース）と同じくらい高速に並列リクエストを処理する方法を確認できません深刻なキャッシングを想定している場合）。ただし、深刻なベンチマークは見つかりませんでした-一部の兆候のみ。
[編集：無料のradeonドライバのbapmパラメータは、Linux 3.16以降のKaveri、KabiniおよびデスクトップTrinity、Richlandシステムに対してデフォルトで設定されています]
[pull] radeon drm-fixes-3.16 を参照してください。
ただし、3.16ベースのDebianに関しては、ブートパラメータは機能しますが、デフォルトは（まだ？）機能していないようです。 AMD Turbo CoreでDebianシステムをセットアップする方法（2Dまたはコンソール/サーバーに焦点を当てる方法）APUエネルギーと計算効率を最大化するには？
[編集：無料のradeonドライバーにはまもなくbapmパラメーターが追加されます]
以下の一番下の行は、あなたのAPUで無料のradeonドライバーのパッチバージョンを使用してターボコアをサポートし、それを最大限に活用することです（3Dグラフィックスを除く）できます（bapmを有効にすると、構成によっては不安定になる可能性があります）、 radeonの将来のバージョンには、bapmを有効にするパラメーターがあります です。
[元の投稿が続きます]
AMD A10-6700（リッチランド）APU経験
プロセッサーの選択
私の最初のPCは、Slackwareソースパッケージを含む3.5インチの数十枚のフロッピーディスクからセットアップされた486DX2-66でした。その後、多くの変化があり、現在多くの業界がまだ数を増やしている段階にあるようです製品バリエーションの。
このような状況と、最近のAMDの不幸な決定の一部により、ミニサーバーのプラットフォームを決定するのは簡単ではありませんでした。しかし最後に、私はA10-6700が良い選択であると決めました：
- いくつかのレビューでは、（まだ広く利用できない）Kaveriは、RichlandやTrinityよりもアイドルモードでより多くの電力を消費することが示されています
- Trinity A10-5700に対するRichland A10-6700の利点は重要であると思われます。最低周波数と最高周波数が低く、粒度が細かいターボコア（温度も考慮すると、GPUがアイドル状態になると非常に有利です）
- A10-6700のGPUは過大評価されている（マーケティング主導のネーミング）と言われており、APUの価格設定は公平に見える
その他のコンポーネントとセットアップ
プロセッサの数は無数ですが、利用できるMini-ITXボードはそれほど多くありません。 ASRock FM2A78M-ITX +が妥当な選択であるように思われました。テストはファームウェアV1.30で行われました（これを書いているので、アップデートはありません）。
電源の公称出力の80％だけが消費されます。一方、50％未満の負荷では、多くが効率的に機能しません。 35Wから120Wの推定消費電力範囲を持つシステム用のエネルギー効率の高い電源を見つけることは非常に困難です。私はこれらのテストをSeasonic G360 80+ Goldで行いました。これは、低負荷での効率に関して、ほとんどの競合他社よりも優れているためです。
2つの8 GB DDR3-1866 RAM（そのように構成されている-これは1333と比較して違いがあります）、1つのSSDドライブ、およびPWM制御品質のCPUファンもテストセットアップの一部でした。
測定は、正確な測定を行うことが報告されている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オン-CnQオン/ Linux OnDemand-ブースト
UEFI BIOS Turbo Core設定................................................有効 UEFI BIOS Cool'n '静かな設定..........................有効 /sys/devices/system/cpu/cpufreq/boost .... ............... 1 /sys/devices/system/cpu/cpu */cpufreq/scaling_governor ... ondemand
"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800 「/ proc/cpuinfo」cpu MHz範囲の観測... 1800-3700 観測された「cpupowerモニター」の周波数範囲... 1800-3700 /sys/kernel/debug/dri/0/radeon_pm_info ...電力レベル0
ロード| Core Freqs --------------- + ----------- stress --cpu 1 | 1 x 3700 stress --cpu 2 | 2 x 3700 stress --cpu 3 | 3 x 3700 stress --cpu 4 | 4 x 3700
テストケース1.2：BIOS TCオン-CnQオン/ Linuxパフォーマンス-ブースト
UEFI BIOS Turbo Core設定................................................有効 UEFI BIOS Cool'n '静かな設定..........................有効 /sys/devices/system/cpu/cpufreq/boost .... ............... 1 /sys/devices/system/cpu/cpu */cpufreq/scaling_governor ...パフォーマンス
"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800 「/ proc/cpuinfo」cpu MHz範囲の観測... 3700 観測された「cpupowerモニター」の周波数範囲... 2000-3700 /sys/kernel/debug/dri/0/radeon_pm_info ...電力レベル0
ロード| Core Freqs --------------- + ----------- stress --cpu 1 | 1 x 3700 stress --cpu 2 | 2 x 3700 stress --cpu 3 | 3 x 3700 stress --cpu 4 | 4 x 3700
テストケースグループ1の概要
radeonドライバは現在、一部のシナリオでの安定性の問題のためにbapmフラグを無効にするため であるため、このシナリオではターボコアベースのブーストは不可能です。したがって、それ以上のテストはスキップされました。
テストケースグループ2：Linux + bapm-patched radeon
bapmを有効にするために、新しいArch Linux（インストーラー2014.08.01、カーネル3.15.7）から始めて、core（3.15.8）を介してlinuxABSパッケージを取得し、PKGBUILDを編集して_pkgbase=linux-tc_を使用しましたでソースを引っ張った makepkg --nobuild、_pi->enable_bapm = true;_の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 しかし、もちろん、YMMV）。
その結果、linuxまたは_linux-tc_を起動するという選択肢が与えられ、以下のテストでは後者を参照しています。
テストケース2.1：BIOS TCオン-CnQオン/ Linux OnDemand-ブースト
UEFI BIOS Turbo Core設定................................................有効 UEFI BIOS Cool'n '静かな設定..........................有効 /sys/devices/system/cpu/cpufreq/boost .... ............... 1 /sys/devices/system/cpu/cpu */cpufreq/scaling_governor ... ondemand
"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800 「/ proc/cpuinfo」cpu MHz範囲の観測... 1800-3700 観測された「cpupowerモニター」の周波数範囲... 1800-4300 /sys/kernel/debug/dri/0/radeon_pm_info ...電力レベル0
ロード|コア周波数 --------------- + ----------------- stress --cpu 1 | 1 x 4300 stress --cpu 2 | 2 x 4200 .. 4100 stress --cpu 3 | 3 x 4100 .. 3900 stress --cpu 4 | 4 x 4000 .. 3800
テストケース2.2：BIOS TCオン-CnQオン/ Linuxパフォーマンス-ブースト
UEFI BIOS Turbo Core設定................................................有効 UEFI BIOS Cool'n '静かな設定..........................有効 /sys/devices/system/cpu/cpufreq/boost .... ............... 1 /sys/devices/system/cpu/cpu */cpufreq/scaling_governor ... performace
"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800 「/ proc/cpuinfo」cpu MHz範囲の観測... 3700 観測された「cpupowerモニター」の周波数範囲... 2000-4300 /sys/kernel/debug/dri/0/radeon_pm_info ...電力レベル0
ロード|コア周波数 --------------- + ----------------- stress --cpu 1 | 1 x 4300 stress --cpu 2 | 2 x 4200 .. 4100 stress --cpu 3 | 3 x 4100 .. 3900 stress --cpu 4 | 4 x 4000 .. 3800
テストケース2.3：BIOS TCオン-CnQオン/ Linux OnDemand-ブーストなし
UEFI BIOS Turbo Core設定................................................有効 UEFI BIOS Cool'n '静かな設定..........................有効 /sys/devices/system/cpu/cpufreq/boost .... ............... 0 /sys/devices/system/cpu/cpu */cpufreq/scaling_governor ... ondemand
"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800 「/ proc/cpuinfo」cpu MHz範囲の観測... 1800-3700 観測された「cpupowerモニター」の周波数範囲... 1800-3700 /sys/kernel/debug/dri/0/radeon_pm_info ...電力レベル1
ロード| Core Freqs --------------- + ----------- stress --cpu 1 | 1 x 3700 stress --cpu 2 | 2 x 3700 stress --cpu 3 | 3 x 3700 stress --cpu 4 | 4 x 3700
テストケース2.4：BIOS TCオン-CnQオン/ Linuxパフォーマンス-ブーストなし
UEFI BIOS Turbo Core設定................................................有効 UEFI BIOS Cool'n '静かな設定..........................有効 /sys/devices/system/cpu/cpufreq/boost .... ............... 0 /sys/devices/system/cpu/cpu */cpufreq/scaling_governor ... performace
"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800 「/ proc/cpuinfo」cpu MHz範囲の観測... 3700 観測された「cpupowerモニター」の周波数範囲... 2000-3700 /sys/kernel/debug/dri/0/radeon_pm_info ...電力レベル1
ロード| Core Freqs --------------- + ----------- stress --cpu 1 | 1 x 3700 stress --cpu 2 | 2 x 3700 stress --cpu 3 | 3 x 3700 stress --cpu 4 | 4 x 3700
テストケース2.5：BIOS TCオフ-CnQオン/ Linux OnDemand-ブースト
UEFI BIOS Turbo Core設定............................無効 UEFI BIOS Cool'n '静かな設定..........................有効 /sys/devices/system/cpu/cpufreq/boost .... ............... 1 /sys/devices/system/cpu/cpu */cpufreq/scaling_governor ... ondemand
"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800 「/ proc/cpuinfo」cpu MHz範囲の観測... 1800-3700 観測された「cpupowerモニター」の周波数範囲... 1800-3700 /sys/kernel/debug/dri/0/radeon_pm_info ...電力レベル0
つまり、BIOSでTurbo Coreが無効になっている場合、パッチを適用したradeonはそれを有効にしません。
テストケース2.6：BIOS TCオン-CnQオフ/ Linux n/a
UEFI BIOS Turbo Core設定................................................有効 UEFI BIOS Cool'n '静かな設定..........................無効 /sys/devices/system/cpu/cpufreq/boost .... ............... n/a /sys/devices/system/cpu/cpu */cpufreq/scaling_governor ... n/a
"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800 「/ proc/cpuinfo」cpu MHz範囲の観測... 3700 観測された「cpupowerモニター」の周波数範囲... 2000-4300 /sys/kernel/debug/dri/0/radeon_pm_info ...電力レベル0
ロード|コア周波数 --------------- + ----------------- stress --cpu 1 | 1 x 4300 stress --cpu 2 | 2 x 4100 .. 4000 stress --cpu 3 | 3 x 4000 .. 3800 stress --cpu 4 | 4 x 3900 .. 3700
Cool'n'Qietを無効にすると、Linuxカーネルはガバナーの選択を提供せず、（誤って）コアが固定周波数で実行されると想定します。興味深いことに、結果として得られるターボコア周波数は、テストケースグループ2でテストされたすべての組み合わせの中で最悪です。
テストケースグループ2の概要
パッチを当てたradeonドライバーを使用すると、Turbo Coreが機能します。これまで、不安定性（bapm別名Turbo Coreがそこで無効にされている理由）は確認されていません。
テストケースグループ3：Linux + fglrx（触媒）
_acpi_cpufreq_（カーネルCPUスケーリング）が存在するため、Ubuntu（14.04サーバー、カーネル3.13）の新規インストールから始めました。およびradeon（カーネルGPUドライバー）。 Ubuntuに切り替える理由は、fglrxを簡単にインストールできることです。 radeonを使用する新規インストールで消費電力と動作を検証しました。
コマンドラインからfglrxをインストールしました（Sudo apt-get install linux-headers-generic、 Sudo apt-get install fglrx）、システムを再起動しました。 radeonからfglrxへの変更は、コンソールの外観（fglrx：128 x 48、radeon：はるかに高い）とアイドルモードの電力消費（fglrx：40W、radeon：30W）の両方に関してすぐにわかります。しかし、Turbo Coreはすぐに動作します。
テストケース3.1：BIOS TCオン-CnQオン/ Linux OnDemand-ブースト
UEFI BIOS Turbo Core設定................................................有効 UEFI BIOS Cool'n '静かな設定..........................有効 /sys/devices/system/cpu/cpufreq/boost .... ............... 1 /sys/devices/system/cpu/cpu */cpufreq/scaling_governor ... ondemand
"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800 観測された「/ proc/cpuinfo」cpu MHz範囲... 1800-3700 観測された「cpupowerモニター」の周波数範囲... 1800-4300 /sys/kernel/debug/dri/0/radeon_pm_info ... n/a
ロード|コア周波数 --------------- + --------------------------- - stress --cpu 1 | 1 x 4300 stress --cpu 2 | 2 x 4200 .. 3900（コア変更） stress --cpu 3 | 3 x 4100 .. 3700 stress --cpu 4 | 4 x 4000 .. 3600
fglrxの動作は間違いなく興味深いものです。 'stress --cpu 2'が任意のテストケースグループのいずれかのtesケースに対して呼び出されたとき、2つのロードされたコアは常に別々のモジュールに配置されていました。しかし、fglrxを使用すると、単一のモジュールが使用されるような突然の再割り当てが発生しました（これにより、以下のかなりの電力が節約されます）。しばらくすると、ロードされたコアが他のモジュールに戻りました。これはradeonでは見られませんでした。 fglrxがプロセスのコアアフィニティを操作しているのでしょうか？
テストケースグループ3の概要
fglrxの利点は、パッチを適用する必要なく、Turbo Coreをすぐに有効にすることです。
65ワットTDPのチップ上のシナリオでは、fglrxはGPUに10〜12 Wを浪費するため、使用可能なコア速度に関する全体的な結果は印象的ではありません。したがって、それ以上のテストは行われませんでした。
また、エンジニアリングの観点からは、fglrxapperの動作は少し悲しいようです。より高い周波数を維持するために2つのビジーコアの1つを他のモジュールに再割り当てすることは良い考えかもしれませんし、そうでないかもしれません。そのステップの前に、両方のコアは独自のL2キャッシュを持っていましたが、その後、それらは1つを共有する必要があるためです。 fglrxが判断をサポートするためにメトリック（キャッシュヒットミスなど）を考慮するかどうかは、個別に明確にする必要がありますが、 その突然の動作に関する他のレポートがあります 。
消費電力のまとめ
次の表の一部のデルタ値は、温度が上昇するにつれてわずかに悪化します。 PWM制御のファンとチップの両方がそこで役割を果たすと言う人もいるかもしれません。
システム@状態/->移行デルタ|システム消費電力 ------------------------------------- + ---- --------------------- @BIOS | @ 95 .. 86W @Bootloader | @ 108 .. 89W @Ubuntuインストーラーアイドル| @ 40W @Linux radeon Idle ondemand | @ 30W @Linux radeonアイドルパフォーマンス| @ 30W @Linux fglrx Idle ondemand | @ 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は、それぞれ2つのコアを持つ2つのモジュールで構成されています。たとえば2つのコアがアイドルで、2つのコアがビジーで加速されている場合、ビジーなコアが同じモジュール上にあるかどうかによって、システムの動作は異なります。
- モジュールの高速化は、コアの高速化よりもエネルギー集約型です。
- L2キャッシュはモジュールごとに割り当てられます。
- 同じモジュールと異なるモジュールで加速する2つのコアの消費電力の違いは、 stress --cpu 2 （これにより、常に2つのモジュール間の配布につながりました） taskset -c 0 stress --cpu 1
andtaskset -c 1 stress --cpu 1。 - A10-6700には、APU（他のコンポーネントと合わせて92W）の合計電力消費制限があるようですが、GPUのみ（3 W）のために小さなビットが予約されています。
radeonを使用すると、fglrxを使用すると、これらの制限を大幅に超え、電力損失が急激に減少することが観察されていますが、短期間でより多くを許容し、非常にスムーズに最大値まで減少します。 - 多くの人が、Kaveriの可用性の遅延は現在のAPUを殺すためにAMDが意図したものであると主張していますが、私は違います。リッチランドA10は優れた電力管理を実証しており、カヴェリは低アイドル状態の電力消費と競合することができません（カヴェリのチップの複雑さはリッチランドのチップの複雑さのほぼ2倍であるため、さらに1つまたは2つの開発ステップが必要になります）。
全体的な結論
- （Trinity-> Richlandステップで報告されているように）Turbo Coreロジックに温度を含めることは、時間の経過に伴うBIOSおよびブートローダーの電力消費の減少からわかるように、理にかなっており、うまく機能しているようです。
- Cosole/serverシナリオの場合、A10-6700は、少なくとも
radeonドライバーを使用して、長期にわたって4700コア@ 3700MHz（ターボコアでは3800MHz）をサポートします。 GPUが処理を行うときに、このパフォーマンスレベルを維持する可能性はあまりありません。 - 65W TDPは、全負荷時にわずかに超える可能性があるように見えますが、電源装置の30Wでの効率が低いため、判別が困難です。温度が考慮されていることが明確に示されているため（90Wに低下し始める前に、ほぼ110Wのピーク電力損失が観察され、4300 MHzで2つのコアがしばらく報告されました）、APU冷却は良い考えかもしれませんが、65W TDPに制限されたメインボードは、それほど多くの電流しか供給できないので、APUによって課されるハード制限があります。
- リッチランドAPUをLinuxでのコンピューティングに使用する場合は、パッチを適用した
radeonドライバーを使用することをお勧めします（特に、ダイナミックパワーマネージメントの有効化と組み合わせて不安定性が発生しない場合）それ以外の場合は、完全な値を取得できません。 - 奇妙なことに、BIOSでTurbo CoreとCool'n'Quietの両方を有効にするのが最良の設定のようですが、少なくとも
performanceスケーリングガバナーを選択します-少なくともAPUがondemandと同じ消費電力になりますが、スケーリングを決定するための周波数スケーリングが高速になり、カーネルオーバーヘッドが少なくなります。
謝辞
bugzilla.kernel.orgで正しい方向に進んでくれた のAlex Deucherに特に感謝します。
無料のradeonドライバーの品質には感銘を受けており、慎重に設計されたように見えるこのソフトウェアをメンテナンスしてくれたチーム全体に感謝します。 radeonがそのように動作しない場合、A10-6700を支持する私の決定は実質的に間違っていたでしょう。