2

I plan to set up an AMD APU system using Debian, but I cannot find hints how to achieve maximum energy efficiency and successful use of Turbo Core. In particular, the Debian Wiki HowTo on CPU Frequency Scaling is not very helpful for AMD systems.

How do I have to set up my Debian system to deploy my AMD APU's features?

7

Basics

With an AMD APU, the following factors are of interest.

  • If your system will only use console output, you will want to use the radeon driver for it. An active console handled by the radeon driver will save 8 W as compared to both the fallback driver and fglrx on an A10-6700 (Richland). If the console is idle, radeon will save an additional 2 W.

  • The AMD APU's Turbo Core feature must be enabled one way or the other. Contrary to what some people believe, Turbo Core (which, once enabled, is an autonomous APU feature) works excellently on APU level and has reasonable use cases. But either the radeon or the fglrx driver must be present and in both cases, care must be taken.

If you feel that it's worth reducing the idle power consumption of a complete A10-6700 Richland system (including fans, DDR3-1866 RAM and a single SSD) from 40 W to 30 W, or if you want to have full Turbo Core speed for longer (the available Turbo Core frequency is based on total chip power consumption including graphics, as well as temperature) then you should care.

All above statements relate to my former analysis How to set up Linux for full AMD APU power management support: Turbo Core, Cool'n'Quiet, Dynamic Power Management?

Be aware that you cannot necessarily rely on information from /proc and /sys regarding the actual frequencies of your AMD APU's cores. To be on the safe side, use cpufreq-aperf (or either cpupower frequency-info or cpupower monitor) after modprobe msr.

Sadly, up to and including Debian Jessie 8.2, you will not get everything out of an AMD APU with a Debian installation out of the box.

Debian Option 1: The fglrx Diver

AMD's Linux fglrx driver enables Turbo Core, which should not come as a surpirse.

However, while the APUs show a very reasonable and useful Turbo Core behaviour with the free Linux radeon driver, this is not necessarily the case when you use fglrx. The fglrx driver appears to manipulate the core affinity of processes. Maybe it even replaces microcode in the APU. But regardless of how fglrx works on detail level, you'll get this:

  • On an APU with four cores, if you have two processes requiring full performance, Linux will start them on the two separate APU modules. (E.g. the A10-6700 has two modules with two cores each, and while each core has a small individual L3 cache, both cores on the same module share the a single L2 cache.) This initial setup will give you maximum performance and also high power consumtion. (The A10-6700 power consumption will increase by 70 W in this example.)

  • But fglrx will relocate one of the porcesses to the second core of the other module if the APU gets too hot. (This will reduce A10-6700 power consumption by 25 W as compared to using both APU modules.) It presumably does this to demonstrate a high core frequency for a longer time. However, the migrated process is very likely to effectively stop for a moment due to the L2 cache not having any of the required data at hand, and usually, performance after the migration will be lower due to the shared L2 cache.

  • Since fglrx does not take any proactive measures to slightly reduce core frequencies before the APU's limits are reached, it consequently reduces core speeds drastically if the processes run for a longer time. This means that after the burst, you'll have to live with lower frequencies until your APU has cooled down.

Other than for core frequency demonstration, the behaviour of fglrx is somewhat questionable in my view; I believe you'll get a better overall performance with radeon. But if you want a 2D/3D system and find this abrupt frequency scaling behaviour acceptable, you can choose fglrx up to and including Debian 7. You can additionally choose fglrx for Debian 8 if you don't intend to use the GNOME desktop.

Debian Option 2: The radeon Driver

As mentioned, the radeon driver offers a much lower console mode power consumption and a much smoother Turbo Core experience. The price you'll have to pay is its worse 3D support.

  • Debian 6 (Squeeze): Even with the Linux 3.2 available as a backport, the radeon driver will not handle your APU's Turbo Core feature.

  • Debian 7 (Wheezy): Linux 3.16 is available as a backport. Upgrade to Linux 3.16 (if no other requirements prevent it) and see below.

  • Debian 8 (Jessie): Based on Linux 3.16. See below.

The flag responsible for Turbo Core handling is called bapm; it is located in the trinity_dpm.c file of the radeon driver. Before Linux 3.16, it was always disabled due to stability issues with some configurations. As of Linux 3.16, two changes were planned:

  • The value for bapm can be provided as a module parameter (see here).

  • The value of bapm is set to 1 by default for Kaveri, Kabini and desktop Trinity, Richland systems (see here), resulting in Turbo Core being enabled.

This means that with current Linux kernels, you'll most likely get best value (Turbo Core, energy efficient console) out of the box (this is e.g. true for current ArchLinux installers).

Much to my surprise, even with the Debian Jessie 8.2 installer, you need to take care of two things:

  • Following its policies, Debian will not provide the required microcode by default. You'll want to provide it: Append non-free and contrib to the relevant entries in /etc/apt/sources.list and run sudo apt-get update as well as sudo apt-get install firmware-linux-nonfree

  • Interestingly, despite the 3.16 defaults, Turbo Core does not work on the same system where a recent ArchLinux succeeded. It could be that the Debian 3.16 kernel is too old to incorporate the defaults, or that the Debian patch to isolate the microcode has some side effect. Either way, Turbo Core can be enabled for Debian Jessie in the presence of the microcode by providing a bapm value at boot time: Append radeon.bapm=1 to the value of GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub and run sudo update-grub

After these two changes, Turbo Core and the low console power consumption worked for me like a charm.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.