Several reports out there, on distribution forums as well as on kernel.org Bugzilla, gravitate around the point that Turbo Core is not deployed by Linux. While in many cases, people seem to be unaware that /proc/ and /sys/dev/system/cpu/ information will not reflect boosts, doubts remained for me. Using Ubuntu 14.04 Server and an AMD A10-6700, I analysed the phenomenon and came to an interesting observation. The system I set up was a bare server with no X / graphics installed / configured. First, I made sure that "cpupower frequency-info" listed the avalable boost states correctly. 4300 MHz (Pb0), 4200 MHz (Pb1) and 3900 MHz (Pb2) were shown in addition to the regular 3700, 3400, 2700, 2300 and 1800 MHz. Then, I used "stress --cpu 2" and "cpupower monitor". No boost. I also backed this observation by tests with "time dd if=/dev/tero of=/dev/null count=10000000". I installed the "radeon" driver and made sure it was loaded in the kernel. No difference. Finally, I downloaded, compiled and installed the latest AMD Radeon driver. From the results, I only took the "fglrx" module and made sure that it got loaded. And alas, "cpupower monitor" showed boosts as expected. Additionally, the execution time of the "dd" command mentioned above was reduced to 85% as compared to before. My suspicion is that the chips will not make their autonomous boost decision unless the graphics unit is initialised in a certain way, such that all the power dissipation information is available for the decision. The question is, could there be any way how the kernel could initialise these APUs such that they can make boost decisions right away, without having to load the proprietary AMD/ATI driver. Credits go to user M132 over at askubuntu.com who, in a brief comment on May 5, provided an indication that such a correlation may possibly exist.
(moving in the direction of those who would know, and whose code would need to do the GPU setup if there is any)
You can enable it by setting pi->enable_bapm = true; in trinity_dpm_init() in trinity_dpm.c. Unforunately, it's not stable yet on all systems.
This issue isnt new, i filed a bug about it ages ago ( #62861 ). As Alex said, turbo core can be enabled by setting bapm to true. Now this is enabled on MSI boards (seems to me all had A78 chipsets?) only by default because they had reboots right after boot if it was off. Im curious how they fare with enabled bapm. Problem is setting bapm on, at least on my A8-6500/GA-F2A88X-D3H and my former A8-5500/GA-F2A85X-D3H hardware causes random reboots or system hangs with no outputs in the system logs. The setting indeed enables turbo core. Also, a simpler way of seeing the actual working frequency is loading the msr module: modprobe msr Then running: cpufreq-aperf or cpufreq-aperf -o for a single poll. both commands with root rights. This will show the actual frequency in Hz (which sometimes is between the nominal p-states, or maybe the polling does averages). Additionally, even if fglrx eables turbo core boost, sometimes something weird happens and even the nominal speed is reported as maximum, in effect you can have even as low as 1.8 GHz (3.2GHz CPU) after an initial turbo boosted speed which lasts a few seconds. This happened to me sometimes (almost 50% of times) when i was compiling with 4 threads on my older A8-5500. I suppose its some internal downclocking mechanism kicking in at the wrong time because the reported temperatures were ~55C (default cooler). In contrast this never happened with radeon and if one thread was used it could have 4 GHz for hours (runaway flash in browser for example). 4 threads (compile) usually settled all cores at a stable ~3.7-3.8 GHz (temps up to 60C, default cooler). These are values on the A8-6500 (3.5GHz nominal/4.1 GHz turbo speed from which never exceeded 4.0 as long as i monitored it).
(In reply to Alex Deucher from comment #2) > You can enable it by setting pi->enable_bapm = true; in trinity_dpm_init() > in trinity_dpm.c. Unforunately, it's not stable yet on all systems. Thank you for this hint, Alex. A search does not reveal much. Do you have a reference to the problems which this can cause? trinity_dpm.c seems to be a file of the free radeon driver. Actually, I would prefer to go without any HW specific graphics driver. I was hoping for a slight chance for the kernel to detect this annoyance and solve it (in a first step) regardless of any later graphics driver settings.
(In reply to Kertesz Laszlo from comment #3) > This issue isnt new, i filed a bug about it ages ago ( #62861 ). As Alex > said, turbo core can be enabled by setting bapm to true. I cannot see any relation between this bug and #62861. Over there, you stated: > This issue is related to the radeon driver's dpm code. > If i dont append radeon.dpm=1 to the kernel boot options, i have > 0.9-1.34v and correct CPU speeds (including torbo boost). This bug report here is about Linux not supporting Turbo Core on APUs when no specific graphics driver is used. In other words, I'm raising the question whether the kernel should be able to suipport the APU Turbo Core even without any specific graphics driver. > [...] > Also, a simpler way of seeing the actual working frequency is loading the > msr module: > > modprobe msr > > Then running: > > cpufreq-aperf In what regard is this simpler than using cpupower? > Additionally, even if fglrx eables turbo core boost, sometimes something > weird happens and even the nominal speed is reported as maximum, in effect > you can have even as low as 1.8 GHz (3.2GHz CPU) after an initial turbo > boosted speed which lasts a few seconds. This happened to me sometimes > (almost 50% of times) when i was compiling with 4 threads on my older > A8-5500. I suppose its some internal downclocking mechanism kicking in at > the wrong time because the reported temperatures were ~55C (default cooler). I stress tested the A10-6700 with fglrx loaded (but console only video) and two cores with 100 % load can boost to 4300 MHz seemingly forever, three with 100 % load will be boosted to 3900 MHz. > In contrast this never happened with radeon and if one thread was used it > could have 4 GHz for hours (runaway flash in browser for example). Maybe the radeon driver didn't load the GPU as much as the fglrx driver did. But since I'm going for console output only, I don't mind. If there's just one bit controlling this behaviour, we'll have to live with the APU's autonomous decision. Some may be smarter than others and maybe it even depends on cooling. Still, I would appreciate my 3700 -> 4300 MHz boost for two cores.
(In reply to LiNuxXer from comment #5) > > This bug report here is about Linux not supporting Turbo Core on APUs when > no specific graphics driver is used. > > In other words, I'm raising the question whether the kernel should be able > to suipport the APU Turbo Core even without any specific graphics driver. > Turbo Core (bapm) is controlled by a microcontroller on the APU. The same microcontroller also manages the GPU power management. On most APU systems, turbo core is enabled by default by the sbios, but apparently on your system it's not. Maybe there is a bios option to enable it by default on your system. When the GPU driver loads and sets up the GPU power management, it can also enable or disable bapm. When bapm and GPU power mangement (dynamic GPU engine clock and voltage scaling, clock and powergating, etc.) are both enabled, some systems have stability problems (sudden reboots, hangs, graphical corruption, issues when switching between AC and battery).
Hello Alex, (In reply to Alex Deucher from comment #6) > Turbo Core (bapm) is controlled by a microcontroller on the APU. The same > microcontroller also manages the GPU power management. On most APU systems, > turbo core is enabled by default by the sbios, but apparently on your system > it's not. Maybe there is a bios option to enable it by default on your > system. reconsidering everything you wrote and I thought I found out, I think I'll have to start from scratch. Firstly, the BIOS does have Turbo Core and Cool'n'Quiet settings, along with many others. Also. it's the latest version, and the A10-6700 is not brand new. Secondly, I noticed that even Ubuntu Server will install the radeon driver although there is no need to. Thirdly, I made a quick test with a Gentoo installer (which neither loads the radeon module nor sets the ondemand governor) and an amperemeter (to be honest: two amperemeters, because I couldn't believe the results), and this completely confused me. While the system needs 96 W while in the BIOS, this drops to 56 W as soon as Linux boots. And I can't get a lower power consumption even if I set the ondemand governor, with the freq of the four cores shown to drop from 3700 to 1800. Several reviews mention a 35 W system (!) power consumption when the A10-6700 is idle, but in this setup, the changing frequency does not have the slightest effect (which it should even have with an average power supply). I was wondering whether you could shed some additional light on this. How many settings actually influence this behaviour in total (since the BIOS also has "Cool'n'Qiet")? Is there any tool to display them? If not, would you help me to build one? Could we see some incomplete initialisation here? Is there any documentation on these settings? I'm groping in the dark here with no progress, and I may even have to exchange the HW if I don't get near the 35 W and have Turbo Core. > When the GPU driver loads and sets up the GPU power management, it > can also enable or disable bapm. When bapm and GPU power mangement (dynamic > GPU engine clock and voltage scaling, clock and powergating, etc.) are both > enabled, some systems have stability problems (sudden reboots, hangs, > graphical corruption, issues when switching between AC and battery). I would be happy with some fixed low bandwidth setting for the graphics. Saw some indivation for 33 MHz during console mode but am not sure I can rely on this information.
I'm not sure why you don't think you need a GPU driver installed. When the driver is installed it not only allows the GPU to dynamically adjust it clocks and voltages up for performance, but also enables low power states and turns off certain blocks when they are not in use, so overall, you'll probably save more power with the GPU driver loaded than just leaving the GPU in the state set up by the bios.
(In reply to Kertesz Laszlo from comment #3) > [...] > Additionally, even if fglrx eables turbo core boost, sometimes something > weird happens and even the nominal speed is reported as maximum, in effect > you can have even as low as 1.8 GHz (3.2GHz CPU) after an initial turbo > boosted speed which lasts a few seconds. This happened to me sometimes > (almost 50% of times) when i was compiling with 4 threads on my older > A8-5500. I suppose its some internal downclocking mechanism kicking in at > the wrong time because the reported temperatures were ~55C (default cooler). > > In contrast this never happened with radeon and if one thread was used it > could have 4 GHz for hours (runaway flash in browser for example). 4 threads > (compile) usually settled all cores at a stable ~3.7-3.8 GHz (temps up to > 60C, default cooler). These are values on the A8-6500 (3.5GHz nominal/4.1 > GHz turbo speed from which never exceeded 4.0 as long as i monitored it). I can confirm your findings. It looks like using fglrx will lead to longer periods of exceeding the TDP significantly, and then suddenly it takes drastic measures to compensate for that. From my observations I believe that it even manipulates core affinity if only two cores are busy (having them on the same module will save a lot of power if the whole other module can be slowed down). With a bapm-patched radeon driver, nothing similar can be observed. Besides saving up to 12W in console mode as compared to fglrx, the cores are able to run at high frequencies forever with no abrupt measures to be seen. Thank you for pointing this out. I have posted my detailed results at http://unix.stackexchange.com/a/148918/79761 in case you're interested.
(In reply to Alex Deucher from comment #8) > I'm not sure why you don't think you need a GPU driver installed. When the > driver is installed it not only allows the GPU to dynamically adjust it > clocks and voltages up for performance, but also enables low power states > and turns off certain blocks when they are not in use, so overall, you'll > probably save more power with the GPU driver loaded than just leaving the > GPU in the state set up by the bios. 1) You're absolutely right. radeon outperforms fglrx significantly in console mode (in my case 10W up to 12W when disabling the output) (and not to mention the Turbo Core performance which is much smoother). 2) You inspired me to look at all this more systematically. I have posted my detailed results at http://unix.stackexchange.com/a/148918/79761 -- in short, the radeon driver is an excellent piece of software (and is in fact saving my *** regarding processor choice, applying the bapm enabling patch you proposed). 3) One question remains -- can't bapm enabling become at least a parameter? Or is it already?
(In reply to LiNuxXer from comment #10) > > 3) One question remains -- can't bapm enabling become at least a parameter? > Or is it already? Yes, I can add a module parameter to force it on.
Created attachment 145411 [details] add a bapm module parameter
(In reply to Alex Deucher from comment #11) > Yes, I can add a module parameter to force it on. That's great news, thank you! I was beginning to think that I'd have to compile my kernel from now on. BTW, I noticed that /sys/kernel/debug/dri/0/radeon_pm_info will report "power level 1" when /sys/devices/system/cpu/cpufreq/boost is set to 0 (with bapm patch, didn't test the unpatched version), while it always reported "power level 0" in my console scenario under all other circumstances. Since I could not notice any difference in power consumption, I was wondering what this actually means.
The information in radeon_pm_info represents the current GPU power state. It will vary dynamically with GPU load. E.g., if you are rendering stuff on your desktop, the GPU clocks and voltages will ramp up/down on demand. In the console without X running, there is no GPU engine load so the clocks stay low. Note that display requirements can also influence the GPU power state. E.g., if you have a large display that requires higher display clocks, the GPU may have to boost the power state to accomodate the higher voltage requirements of the display.