Default cpufreq governor: performance vs. interactive/ondemand

284 views
Skip to first unread message

Thomas Kaiser

unread,
Dec 3, 2015, 6:43:55 AM12/3/15
to linux...@googlegroups.com
Hello,

to justify the switch from interactive/ondemand to performance as default
cpufreq governor the following 2 year old sources are cited again and
again:

https://www.mail-archive.com/linux...@googlegroups.com/msg00492.html

https://www.mail-archive.com/linux...@googlegroups.com/msg00678.html
http://www.cubieforums.com/index.php/topic,1413.msg8745.html#msg8745


Unfortunately they miss the dvfs settings used ‹ it seems all cpufreq
operating points shared the same voltage.

Using recent Allwinner SoCs with 3.4 kernel and reasonable dvfs settings
(adjusting core voltage depending on CPU clockspeed) it's obvious that it
makes a difference at which clockspeed the CPU idles since different
voltages lead to different consumption levels.

I have no multimeter that would be precise enough so I rely on the thermal
sensors in the 2 SoCs I used to show the difference the clockspeed makes
depending on dvfs settings.

I let a script walk through scaling_available_frequencies while being idle
and monitored temperature and in A83T's case also Vcore voltage. The
conclusion is obvious: What happens when switching between performance and
interactive/performance depends largely on the *voltage settings* defined
in the dvfs table.

This is a H3 with 'sane' dvfs settings on the left side and the commonly
used overvolted/overclocked settings the Orange Pi manufacturer chose to
advertise the H3 as being a '1.6 Ghz SoC':

http://kaiser-edv.de/tmp/h3vOAh/H3.png (on the left adjusted/sane
settings, on the right after a reboot at 19:15 the overvolted/overclocked
'defaults' every OS image for H3 boards is using ‹ this is where the heat
problems origin from the H3 is blamed for)


With sane settings the difference in idle temperature is 3°C (41°C at 480
Mhz and 44°C at 1200 Mhz), with 'default settings' (only two operating
points defined at the upper limit), the difference is 6°C (45°C at 480 Mhz
and 51°C at 1536 Mhz). Both dvfs tables as reference below [1] [2]

Since the A83T is accompanied by a PMU (AXP813) it's possible to monitor
Vcore voltage through sysfs. Here the core voltage is adjusted between
820mV at 480 Mhz and 1080mV at 1800 Mhz [3] and this results in a
difference of 4°C when being idle:

http://kaiser-edv.de/tmp/h3vOAh/A83T.png

It's obvious that consumption (SoC temperature) depends more on core
voltage than clock speed and therefore the switch to performance as
default governor seems like a waste of energy. A more sane approach would
be to stay with ondemand/interactive and adjust scaling_min_freq to the
operating point with the lowest voltage defined in the dvfs table (since
then no further saving can be achieved when clocking lower).

While I understand that switching to performance seemed like a good idea 2
years ago (OS images with fantasy governor and scaling_min_freq at 60 Mhz
in the wild) I doubt that it's still right when keeping voltage settings
in the dvfs table in mind.

Best regards,

Thomas

[1] Overvolted/overclocked default dvfs settings Xunlong (Orange Pi
manufacturer) used to promote the H3 as being able to clock up to 1.6 Ghz:

extremity_freq = 1536000000

LV1_freq = 1536000000
LV1_volt = 1500
LV2_freq = 1200000000
LV2_volt = 1300


[2] Attempt to define 'normal' dvfs settings for H3. Adjusting voltage
between 980mV at 480 Mhz and 1240mV at 1200 Mhz:

extremity_freq = 1296000000
max_freq = 1200000000
min_freq = 480000000
LV_count = 7
LV1_freq = 1296000000
LV1_volt = 1320
LV2_freq = 1200000000
LV2_volt = 1240
LV3_freq = 1104000000
LV3_volt = 1180
LV4_freq = 1008000000
LV4_volt = 1140
LV5_freq = 960000000
LV5_volt = 1080
LV6_freq = 816000000
LV6_volt = 1020
LV7_freq = 480000000
LV7_volt = 980


[3] A83T dvfs settings: 820mV at 480 Mhz and 1080mV at 1800 Mhz

[dvfs_table]
vf_table_count = 3

[vf_table0]
;little
L_max_freq = 2016000000
L_boot_freq = 1800000000
L_min_freq = 480000000

L_LV_count = 8

L_LV1_freq = 2016000000
L_LV1_volt = 1080

L_LV2_freq = 1800000000
L_LV2_volt = 1000

L_LV3_freq = 1608000000
L_LV3_volt = 920

L_LV4_freq = 1200000000
L_LV4_volt = 840

L_LV5_freq = 0
L_LV5_volt = 840

L_LV6_freq = 0
L_LV6_volt = 840

L_LV7_freq = 0
L_LV7_volt = 840

L_LV8_freq = 0
L_LV8_volt = 840

;big
B_max_freq = 2016000000
B_boot_freq = 1800000000
B_min_freq = 480000000

B_LV_count = 8

B_LV1_freq = 2016000000
B_LV1_volt = 1080

B_LV2_freq = 1800000000
B_LV2_volt = 1000

B_LV3_freq = 1608000000
B_LV3_volt = 920

B_LV4_freq = 1200000000
B_LV4_volt = 840

B_LV5_freq = 0
B_LV5_volt = 840

B_LV6_freq = 0
B_LV6_volt = 840

B_LV7_freq = 0
B_LV7_volt = 840

B_LV8_freq = 0
B_LV8_volt = 840

[vf_table1]
;little
L_max_freq = 2016000000
L_boot_freq = 1800000000
L_min_freq = 480000000

L_LV_count = 8

L_LV1_freq = 2016000000
L_LV1_volt = 1080

L_LV2_freq = 1800000000
L_LV2_volt = 1000

L_LV3_freq = 1608000000
L_LV3_volt = 920

L_LV4_freq = 1200000000
L_LV4_volt = 840

L_LV5_freq = 480000000
L_LV5_volt = 820

L_LV6_freq = 0
L_LV6_volt = 820

L_LV7_freq = 0
L_LV7_volt = 820

L_LV8_freq = 0
L_LV8_volt = 820

;big
;big
B_max_freq = 2016000000
B_boot_freq = 1800000000
B_min_freq = 480000000

B_LV_count = 8

B_LV1_freq = 2016000000
B_LV1_volt = 1080

B_LV2_freq = 1800000000
B_LV2_volt = 1000

B_LV3_freq = 1608000000
B_LV3_volt = 920

B_LV4_freq = 1200000000
B_LV4_volt = 840

B_LV5_freq = 480000000
B_LV5_volt = 820

B_LV6_freq = 0
B_LV6_volt = 820

B_LV7_freq = 0
B_LV7_volt = 820

B_LV8_freq = 0
B_LV8_volt = 820

[vf_table2]
;little
L_max_freq = 2208000000
L_min_freq = 480000000

L_LV_count = 8

L_LV1_freq = 2208000000
L_LV1_volt = 1080

L_LV2_freq = 2016000000
L_LV2_volt = 1000

L_LV3_freq = 1800000000
L_LV3_volt = 920

L_LV4_freq = 1368000000
L_LV4_volt = 840

L_LV5_freq = 0
L_LV5_volt = 840

L_LV6_freq = 0
L_LV6_volt = 840

L_LV7_freq = 0
L_LV7_volt = 840

L_LV8_freq = 0
L_LV8_volt = 840

;big
B_max_freq = 2208000000
B_min_freq = 480000000

B_LV_count = 8

B_LV1_freq = 2208000000
B_LV1_volt = 1080

B_LV2_freq = 2016000000
B_LV2_volt = 1000

B_LV3_freq = 1800000000
B_LV3_volt = 920

B_LV4_freq = 1368000000
B_LV4_volt = 840

B_LV5_freq = 0
B_LV5_volt = 840

B_LV6_freq = 0
B_LV6_volt = 840

B_LV7_freq = 0
B_LV7_volt = 840

B_LV8_freq = 0
B_LV8_volt = 840







Thomas Kaiser

unread,
Dec 4, 2015, 3:17:33 AM12/4/15
to linux-sunxi
Thomas Kaiser wrote:
I have no multimeter that would be precise enough so I rely on the thermal
sensors in the 2 SoCs I used to show the difference the clockspeed makes
depending on dvfs settings.

I bought a powermeter in the meantime and get a difference of ~250mW idle consumption on a Banana Pi M3 (A83T) when switching between interactive and performance (between 2.9/3W with interactive and 3.2W with performance) with the following settings:

scaling_max_freq: 1800000 (@1080 mV defined in dvfs table)
scaling_min_freq: 480000 (@840 mV defined in dvfs table)

Then I defined dvfs settings where all cpufreq operating points share the same 1080mV and tested again. I couldn't measure a difference in consumption realiably but the SoC's internal sensor showed at least some differences. On the left Vcore set statically to 1080mV and on the right the very same test with dynamic voltage frequency scaling and voltage being adjusted between 840mV and 1080mV when walking through _scaling_available_frequencies_:


I still believe that my consumption measurements are too unrealiable to draw any conclusions from. But in the meantime I believe there's some evidence that the whole discussion about power savings or waste of energy due to different cpufreq governors is totally useless if the dvfs settings aren't considered as well. Since based on my tests with A20, H3 and A83T the clockspeed alone wasn't that important regarding consumption and internal SoC temperatures. But the voltage was.

Therefore I find it a bit hard to draw _any_ conclusions from these two sets of practical tests that are referenced here since the used dvfs settings aren't mentioned (or I missed it):


"The practical tests show that there is not much power consumption difference between idling at 60MHz and idling at 1008MHz (a ~1.5x difference on Cortex-A8, almost no difference on Cortex-A7)"

In my tests it made a huge or nearly no difference to switch between both governors -- based on the dvfs settings defined: the higher the voltage difference therein the more difference in consumption. While I still understand that a switch to performance seemed like a good idea two years ago when OS images with 60MHz _scaling_min_freq_ and fantasy or ondemand governor were used, I doubt it's the right approach when taking dvfs settings into account.

IMO a better approach is to choose interactive and adjust scaling_min_freq to the cpufreq with the lowest voltage defined in the dvfs table (or maybe one above). At least my tests made with the H3 recently showed nearly no difference whether the H3 idled at 240 or 720 MHz (both defined with the lowest voltage in the dvfs table) therefore I chose 720 as _scaling_min_freq_ and the system behaves as snappy as with performance:


I can't test that with an A10 board since I don't own one. But might the test results from back then ("a ~1.5x difference on Cortex-A8, almost no difference on Cortex-A7") not be related more to dvfs settings than A8 vs. A7?

Thx,

Thomas
Reply all
Reply to author
Forward
0 new messages