如何设置 Linux 以获得完整的 AMD APU 电源管理支持:Turbo Core、Cool'n'Quiet、动态电源管理?

Run*_*CMD 11 fglrx radeon cpu-frequency amd turbo-core

我的目标是在空闲模式下设置一个低功耗的迷你服务器(不是 HTPC),但在使用时提供良好的性能。重点是数据安全而不是可用性。换句话说:优质零件,但仅用于存储的冗余。

不认为自己有偏见,经过一些研究,我觉得某些 AMD 台式机 APU 会提供很好的价值。

剩下的问题是:

  • GPU的空闲状态是否会降低功耗并为CPU释放资源?
  • Cool'n'Quiet 和 Turbo Core 是否会在空闲模式下实现预期的低功耗,但在负载下性能良好?
  • Linux 会按预期支持这种情况吗?不少问题和论坛讨论似乎表明情况并非如此。

Run*_*CMD 13

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

  • AMD 与 AMD:
    • Richland 在这方面做得比 Trinity 好得多。
    • Kaveri 无法与 Richland 的空闲模式功耗竞争(至少目前如此)。
    • A10-6700 的 GPU 可能被高估了,但有点遗憾它不会用太多。某些算法可能能够部署其计算能力。不过,不知道这将如何影响处理器的功耗。
    • 我怀疑 A10-6790K 与 A10-6700 是相同的处理器,只是为 Turbo Core 提升设置了不同的参数。如果这是真的,由于其更高的 TDP,A10-6790K 将能够长期提升和/或提供更高的频率。但是你需要一个不同的 CPU 风扇(想想空间和温度/寿命)。
  • AMD A10-6700 与英特尔酷睿 i3-3220:
    • A10-6700 有更多的 GPU 能力,这里没有使用。
    • i3-3220 具有较低的空闲模式功耗。
    • 虽然在典型的基准测试中 i3-3220 的计算速度更快,但我看不出它的两个超线程内核如何能够像四个全功能内核(至少当假设有一些严重的缓存时)。但是,没有找到任何严肃的基准——只有一些迹象。

[编辑:bapm自 Linux 3.16 起,Kaveri、Kabini 和桌面 Trinity、Richland 系统默认设置了免费的 radeon 驱动程序参数]

请参阅[拉] 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

[原帖如下]

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 进行的,据报道它可以执行准确的测量。尽管如此,使用较旧的无名设备验证了合理性。没有发现不一致之处。测得的系统功耗将包括电源在较低负载下的效率降低。

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

在 UEFI BIOS 中,GPU 的初始共享内存设置为 32M。此外,板载 GPU 被选为主要,并启用了 IOMMU。

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

基本

有几件事需要了解。

  • 虽然关于 Cool'n'Quiet 的决定是由处理器之外的软件做出的,但 Turbo Core 是由 APU(或 CPU)上的附加微控制器自主做出的决定。
  • 许多工具,以及/proc/sys地方不报告的Turbo核心活动。cpufreq-aperf,cpupower frequency-infocpupower 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... ondemand 
"cpupower frequency-info" 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 x 3700
压力--cpu 2 | 2 x 3700
压力--cpu 3 | 3 x 3700
压力--cpu 4 | 4 x 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 frequency-info" 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 x 3700
压力--cpu 2 | 2 x 3700
压力--cpu 3 | 3 x 3700
压力--cpu 4 | 4 x 3700

测试用例组 1 总结

基于涡轮增压提升核心在这种情况下是不可能的,因为radeon驱动器当前禁用bapm标志,由于在某些情况下的稳定性问题。因此,跳过了进一步的测试。


测试用例组 2:Linux + bapm-patched radeon

为了使bapm,我开始一个新的的Arch Linux(安装2014年8月1日,内核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.xzpacman -U linux-tc-3.15.8-1-x86_64.pkg.tar.xz)并更新了GRUBgrub-mkconfig -o /boot/grub/grub.cfg当然,YMMV)。

结果,我可以选择 bootlinuxlinux-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... ondemand 
"cpupower frequency-info" 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 x 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 frequency-info" 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 x 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 - 没有 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... ondemand
"cpupower frequency-info" 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 x 3700
压力--cpu 2 | 2 x 3700
压力--cpu 3 | 3 x 3700
压力--cpu 4 | 4 x 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 frequency-info" 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 x 3700
压力--cpu 2 | 2 x 3700
压力--cpu 3 | 3 x 3700
压力--cpu 4 | 4 x 3700

测试用例 2.5:BIOS TC 关闭 - CnQ 开启 / 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... ondemand 
"cpupower frequency-info" 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... n/a
"cpupower frequency-info" 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 x 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 48 radeon,:更高)和空闲模式功耗(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... ondemand 
"cpupower frequency-info" 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 x 4300
压力--cpu 2 | 2 x 4200 .. 3900(核心 chg)
压力--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 的芯片上为 GPU 浪费了 10 到 12W,所以关于可用核心速度的总体结果并不令人印象深刻。因此,没有进行进一步的测试。

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


功耗总结

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

系统@State / -> Transition Delta | 系统功耗
-------------------------------------+------------ -------------
  @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)似乎比预期的要多:当“按需”缩放调节器就位时,与“性能”调节器就位时相比,功耗没有明显差异。我们虽然/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 中功率耗散随时间的减少中看出。
  • 对于主机/服务器场景,A10-6700 长期支持 4 核 @ 3700MHz(3800MHz with Turbo Core),至少在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 表现得像这里测试的那样。您将拥有与使用相同的功耗,ondemand但更快的频率缩放和更少的内核开销来做出缩放决策。

致谢

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

免费radeon驱动程序的质量给我留下了深刻的印象,并要感谢整个团队维护这个看起来经过深思熟虑设计的软件。如果radeon我不这样做,我支持 A10-6700 的决定就大错特错了。