[编辑：关于处理器选择的总结性想法]

AMD vs AMD：
- Richland在这方面的工作比Trinity好得多。
- Kaveri无法与Richland的空闲模式功耗相抗衡（至少目前如此）。
- A10-6700的GPU可能被高估了，但令人遗憾的是它不会被大量使用。一些算法可能能够部署其计算能力。但是，不知道这将如何影响处理器的功耗。
- 我怀疑A10-6790K是与A10-6700相同的处理器，只是Turbo Core Boost的参数设置不同。如果属实，A10-6790K的TDP较高，因此能够长期提高频率和/或提供更高的频率。但是，您需要为此使用不同的CPU风扇（请考虑空间和温度/寿命）。
AMD A10-6700和Intel Core i3-3220：
- A10-6700具有更多的GPU功能，此处未使用。
- i3-3220的空闲模式功耗较低。
- 尽管在典型的基准测试中，i3-3220的计算速度更快，但我看不出它的两个超线程内核如何能够像四个功能齐全的内核（至少具有四个）一样快地处理并行请求（例如，对具有Web前端的数据库）。假设有一些严重的缓存时）。不过，没有找到任何严格的基准测试-只有一些迹象。

[编辑：bapm默认情况下，从Linux 3.16开始，为Kaveri，Kabini和桌面Trinity，Richland系统设置免费的radeon驱动程序参数。

但是，对于基于3.16的Debian，默认值似乎还不起作用，但boot参数却可以。请参阅如何使用AMD Turbo Core APU设置Debian系统（专注于2D或控制台/服务器）以获得最大的能量和计算效率？

[编辑：免费的radeon驱动程序将很快有一个bapm参数]

由于以下内容的底线是radeon在APU 上使用免费驱动程序的补丁版本来支持Turbo Core，并在可能的情况下充分利用（除非是3D图形）（启用bapm可能导致某些配置不稳定）），好消息是radeon的未来版本将具有启用bapm的参数。

[后接原文]

AMD A10-6700（Richland）APU体验

处理器选择

我的第一台PC是从数十个包含Slackware源软件包的3.5英寸软盘上安装的486DX2-66。然后，很多事情发生了变化，许多行业目前似乎仍处于增加数量的阶段产品变体。

这种情况以及最近AMD的一些不幸决定并没有使我更容易决定迷你服务器平台。但最后，我认为A10-6700将是一个不错的选择：

多项评论表明，（仍然广泛不可用的）Kaveri在空闲模式下将比Richland或Trinity消耗更多功率。
与三位一体A10-5700相比，Richland A10-6700的优势似乎很明显：更低的最低频率和更高的最高频率，更细粒度的Turbo Core（还考虑到温度-当GPU处于空闲状态时，这是一个优势）
据说A10-6700的GPU被高估了（市场驱动的命名），APU的价格似乎还算合理

其他组件和设置

尽管有无数的处理器可供选择，但Mini-ITX板并不多。华擎FM2A78M-ITX +似乎是一个合理的选择。测试是使用固件V1.30完成的（在撰写本文时没有可用的更新）。

仅应消耗电源标称输出的80％。另一方面，许多负载在50％负载以下无法有效工作。对于估计功耗范围为35W至120W的系统，很难找到一种节能电源。我使用Seasonal G360 80+ Gold进行了这些测试，因为它在低负载下的效率优于大多数竞争对手。

测试设置还包括两个8GB DDR3-1866 RAM（如此配置-与1333相比确实有所不同），一个SSD驱动器和一个PWM可控制质量的CPU风扇。

使用AVM Fritz！DECT 200进行测量，据报道该设备执行了精确的测量。尽管如此，使用较旧的无名设备验证了真实性。没有发现不一致之处。测得的系统功耗将包括电源为降低负载而降低的效率。

通过HDMI连接了[W] QHD屏幕。

在UEFI BIOS中，GPU的初始共享内存设置为32M。此外，还将板载GPU选为主处理器，并启用了IOMMU。

没有安装或配置X或其他图形系统。视频输出仅限于控制台模式。

基本

有一些事情需要知道。

关于Cool'n'Quiet的决定是由处理器之外的软件决定的，而Turbo Core是由APU（或CPU）上的附加微控制器自主决定的。
许多工具，以及/proc和/sys地方不报告的Turbo核心活动。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 Setting .................................已启用
UEFI BIOS Cool'n'Quiet Setting ......................................已启用
/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范围... 1800-3700
观察到“ cpupower监视器”的频率范围... 1800-3700
/ sys /内核/调试/ dri / 0 / radeon_pm_info ...功率等级0

加载| 核心频率
--------------- + -----------
压力--cpu 1 | 1 x 3700
压力--cpu 2 | 2 x 3700
压力--cpu 3 | 3 x 3700
压力--cpu 4 | 4 x 3700

测试案例1.2：启用BIOS TC-启用CnQ / Linux性能-Boost

UEFI BIOS Turbo Core Setting .................................已启用
UEFI BIOS Cool'n'Quiet Setting ......................................已启用
/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 /内核/调试/ dri / 0 / radeon_pm_info ...功率等级0

加载| 核心频率
--------------- + -----------
压力--cpu 1 | 1 x 3700
压力--cpu 2 | 2 x 3700
压力--cpu 3 | 3 x 3700
压力--cpu 4 | 4 x 3700

测试用例组1摘要

在这种情况下，基于Turbo Core的增强是不可能的，因为在某些情况下，radeon驱动程序当前会bapm由于稳定性问题而禁用该标志。因此，跳过了进一步的测试。

测试案例组2：Linux + bapm修补的radeon

为了启用该功能bapm，我从全新的Arch Linux（安装程序2014.08.01，内核3.15.7）开始，core linux通过ABS（3.15.8）获取了该软件包，将其编辑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 Setting .................................已启用
UEFI BIOS Cool'n'Quiet Setting ......................................已启用
/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范围... 1800-3700
观察到“ cpupower监视器”的频率范围... 1800-4300
/ sys /内核/调试/ dri / 0 / radeon_pm_info ...功率等级0

加载| 核心频率
--------------- + -----------------
压力--cpu 1 | 1 x 4300
压力--cpu 2 | 2 x 4200 .. 4100
压力--cpu 3 | 3 x 4100 .. 3900
压力--cpu 4 | 4 x 4000 .. 3800

测试案例2.2：启用BIOS TC-启用CnQ / Linux性能-Boost

UEFI BIOS Turbo Core Setting .................................已启用
UEFI BIOS Cool'n'Quiet Setting ......................................已启用
/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 /内核/调试/ dri / 0 / radeon_pm_info ...功率等级0

加载| 核心频率
--------------- + -----------------
压力--cpu 1 | 1 x 4300
压力--cpu 2 | 2 x 4200 .. 4100
压力--cpu 3 | 3 x 4100 .. 3900
压力--cpu 4 | 4 x 4000 .. 3800

测试案例2.3：启用BIOS TC-启用CnQ / Linux OnDemand-无增强

UEFI BIOS Turbo Core Setting .................................已启用
UEFI BIOS Cool'n'Quiet Setting ......................................已启用
/sys/devices/system/cpu/cpufreq/boost...................0
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ...按需

“ 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

加载| 核心频率
--------------- + -----------
压力--cpu 1 | 1 x 3700
压力--cpu 2 | 2 x 3700
压力--cpu 3 | 3 x 3700
压力--cpu 4 | 4 x 3700

测试案例2.4：启用BIOS TC-启用CnQ / Linux性能-无增强

UEFI BIOS Turbo Core Setting .................................已启用
UEFI BIOS Cool'n'Quiet Setting ......................................已启用
/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

加载| 核心频率
--------------- + -----------
压力--cpu 1 | 1 x 3700
压力--cpu 2 | 2 x 3700
压力--cpu 3 | 3 x 3700
压力--cpu 4 | 4 x 3700

测试案例2.5：BIOS TC关闭-CnQ打开/ Linux OnDemand-增强

UEFI BIOS Turbo Core设置............................禁用
UEFI BIOS Cool'n'Quiet Setting ......................................已启用
/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范围... 1800-3700
观察到“ cpupower监视器”的频率范围... 1800-3700
/ sys /内核/调试/ dri / 0 / radeon_pm_info ...功率等级0

换句话说，如果在BIOS中禁用了Turbo Core，则打补丁的软件radeon将不会打开它。

测试案例2.6：BIOS TC开启-CnQ关闭/ Linux不适用

UEFI BIOS Turbo Core Setting .................................已启用
UEFI BIOS Cool'n'Quiet设置................................禁用
/ sys / devices / system / cpu / cpufreq / boost ...................
/ 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 /内核/调试/ dri / 0 / radeon_pm_info ...功率等级0

加载| 核心频率
--------------- + -----------------
压力--cpu 1 | 1 x 4300
压力--cpu 2 | 2 x 4100 .. 4000
压力--cpu 3 | 3 x 4000 .. 3800
压力--cpu 4 | 4 x 3900 .. 3700

在禁用Cool'n'Qiet的情况下，Linux内核将不提供任何调控器选择，并且（错误地）假定内核以固定频率运行。有趣的是，在测试用例组2中，得到的Turbo Core频率是所有测试组合中最差的。

测试用例组2摘要

使用修补的radeon驱动程序，Turbo Core可以工作。bapm到目前为止，还没有发现不稳定因素（这就是在那里禁用了Turbo Core 的原因）。

测试案例组3：Linux + fglrx（催化剂）

我从全新的Ubuntu（14.04 Server，内核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 48 radeon，：更高）和空闲模式功耗（fglrx：40W，radeon：30W）上都是显而易见的。但是Turbo Core可以立即工作。

测试案例3.1：启用BIOS TC-启用CnQ / Linux OnDemand-增强

UEFI BIOS Turbo Core Setting .................................已启用
UEFI BIOS Cool'n'Quiet Setting ......................................已启用
/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范围... 1800-3700
观察到“ cpupower监视器”的频率范围... 1800-4300
/ sys /内核/调试/ dri / 0 / radeon_pm_info ... n / a

加载| 核心频率
--------------- + ----------------------------
压力--cpu 1 | 1 x 4300
压力--cpu 2 | 2 x 4200 .. 3900（核心CHG）
压力--cpu 3 | 3 x 4100 .. 3700
压力--cpu 4 | 4 x 4000 .. 3600

这种fglrx行为肯定很有趣。当在任何测试用例组中的任何tes用例中调用'stress --cpu 2'时，两个加载的核心始终位于单独的模块上。但是，随着fglrx发生了突然的重新分配，从而使用了单个模块（这节省了相当多的功能，请参阅下文）。一段时间后，已加载的内核又移回另一个模块。看不到用radeon。难道是fglrx操纵流程的核心亲和力？

测试用例组3摘要

优点fglrx是它可以立即启用Turbo Core，而无需对其进行修补。

因为fglrx在我们的方案中，在具有65W TDP的芯片上为GPU浪费了10至12W的功率，所以有关可用核心速度的总体结果并不令人印象深刻。因此，没有进行进一步的测试。

同样从工程学的角度来看，的行为fglrx似乎有些可悲。将两个繁忙的内核之一重新分配给另一个模块以保持较高的频率可能不是一个好主意，因为在此步骤之前，两个内核都有自己的L2缓存，而在此之后，它们必须共享一个。是否fglrx考虑使用任何衡量指标（例如高速缓存命中率未命中）来支持其决定，将需要单独澄清，但是还有其他有关其突然行为的报告。

耗电量汇总

下表中的某些增量值会随着温度的升高而稍微变差。可能有人说PWM控制的风扇和芯片都在其中起作用。

系统@State /->过渡增量| 系统功耗
------------------------------------- + ------------ -------------
  @BIOS | @ 95 .. 86W
  @Bootloader | @ 108 .. 89W
  @Ubuntu安装程序空闲| @ 40瓦
  @Linux radeon Idle按需| @ 30瓦
  @Linux radeon空闲性能| @ 30瓦
  @Linux fglrx空闲按需| @ 40瓦
  1个模块1800-> 3700 | + 13瓦
  1个模块1800-> 4300 | + 25瓦
  1核心1800-> 3700 | + 5瓦
  1核心1800-> 4300 | + 10瓦
  “ radeon”视频输出->禁用| -2W
  'fglrx“视频输出->变暗| +-0W
  @Linux radeon最大值| @ 103 .. 89W
  @Linux fglrx最大值| @ 105 .. 92W

Turbo Core（至少对于Richland APU而言）似乎比预期要多：与“性能”调速器相比，“按需”缩放调速器到位时的功耗没有明显差异。我们虽然/proc/cpuinfo会始终报告37000MHz下的性能州长，cpupower monitor就会发现，内核实际上做放缓。在某些情况下，显示的频率低至2000MHz。内部可能还会使用1800MHz。
A10-6700包含两个模块，每个模块具有两个内核。例如，如果两个内核处于空闲状态并且两个内核处于忙碌状态并加速运行，则系统行为将有所不同，具体取决于忙碌的内核是否位于同一模块上。
- 加速模块比加速内核耗能更多。
- L2高速缓存按模块分配。
通过用替换stress --cpu 2（始终导致两个模块之间的分配）来确定在相同模块和不同模块上加速的两个内核的功耗之间的差异。taskset -c 0 stress --cpu 1andtaskset -c 1 stress --cpu 1
A10-6700似乎具有APU的总功耗限制（92W以及其他组件），而仅为GPU保留了少量功耗（3 W）。有了radeon，它将在短期内提供更多，并非常平稳地减小到最大值，而有了fglrx，已经观察到，这些限制被更明显地超过了，然后功耗急剧减小。
尽管许多人声称Kaveri可用性的延迟是AMD故意造成的，因为这会杀死他们当前的APU，但我要有所不同。Richland A10具有出色的电源管理能力，Kaveri无法以其低的空闲状态功耗进行竞争（Kaveri的芯片复杂度几乎是Richland的两倍，因此将需要另外一两个开发步骤）。

总体结论

将温度包括在Turbo Core逻辑中（如Trinity-> Richland步骤所报道）似乎是合理的，并且似乎运行良好，这可以从BIOS和Bootloader随时间的功耗减少而看出。
对于Cosole /服务器场景，A10-6700至少在radeon驱动程序上可以长期支持4个内核@ 3700MHz（Turbo Core为3800MHz）。当GPU要做一些工作时，维持这种性能水平的机会可能不大。
在满载情况下，似乎可以永久超过65W TDP，但是很难断定，因为电源在30W时效率较低。由于有明确的迹象表明考虑了温度（在将峰值功率降低至90W之前观察到峰值功率消耗将近110W，并且一段时间内还报告了2个4300 MHz的内核），因此投资APU冷却可能好主意。但是，限于65W TDP的主板将只能提供这么大的电流，因此APU肯定会有硬限制。
如果打算在Linux下使用Richland APU进行计算，则一定要使用修补的radeon驱动程序（如果您没有遇到不稳定的情况，特别是与启用动态电源管理结合使用）。否则，您将无法获得全部价值。
奇怪的是，最好的设置似乎是在BIOS中同时启用Turbo Core和Cool'n'Quiet，然后选择performance缩放调节器-至少如果您的APU的行为类似于此处测试的那样。您将拥有与之相同的功耗，ondemand但可以更快地进行频率缩放，并减少内核开销来做出缩放决定。

致谢

特别感谢Alex Deucher，他在bugzilla.kernel.org上将我推向了正确的方向。

免费radeon驱动程序的质量给我留下了深刻的印象，并感谢整个团队维护此软件的精心设计。如果radeon行为不尽如人意，我赞成A10-6700的决定将是错误的。

— 运行CMD
source

作为对空闲功耗效率感兴趣的Arch用户，我发现本文是我在Arch上优化AMD APU的最佳资源之一。谢谢！这应该发布在Arch Wiki中。

— b10hazard 2015年

感谢您的反馈@ b10hazard，这听起来是个好主意。将其集成到Arch Wiki的步骤是什么？我是Arch的新手。直到最近，我还是在Debian方面。

— 运行CMD

我不确定。很少有人对PC的低功耗感兴趣，而获得有关该主题的大量信息的人就更少了。如果不将其中的某些内容合并到Wiki中，将是很可惜的。也许您可以在论坛上询问某人？希望我能提供更多帮助，我从未在Wiki上创建过页面，仅在编辑现有页面时。

— b10hazard

如何为完整的AMD APU电源管理支持设置Linux：Turbo Core，Cool'n'Quiet，动态电源管理？