Default sampling_down_factor setting for ondemand governor cripples Intel turbo boost

[Obrouni]

Description: Ubuntu oneiric (development branch)
Release: 11.10

By default, or at least what is default on my machine the ondemand governor has the sampling_down_factor set to 1. In testing this seems to show that the turbo boost on my Intel CPU never gets a chance to boost up properly.

It seems by the time you set it to about 10, turbo can work as expected, with only a minor increase in speed above that. This problem only seems to appear, or becomes more apparent once the CPU has had its turbo overclocked a few multipliers above stock.

Looking at the current scaling frequency you can see with a sampling_down_factor setting of 1 that it keeps jumping between 1600Mhz and the max freq, with higher settings it is static.

eg:-

cat /sys/devices/system/cpu/cpu*/ondemand/sampling_down_factor
1

Start of PI calculation up to 1048576 decimal digits
 End of initialization. Time= 0.168 Sec.
 I= 1 L= 0 Time= 0.492 Sec.
 I= 2 L= 0 Time= 0.568 Sec.
 I= 3 L= 1 Time= 0.552 Sec.
 I= 4 L= 2 Time= 0.568 Sec.
 I= 5 L= 5 Time= 0.560 Sec.
 I= 6 L= 10 Time= 0.560 Sec.
 I= 7 L= 21 Time= 0.560 Sec.
 I= 8 L= 43 Time= 0.560 Sec.
 I= 9 L= 87 Time= 0.568 Sec.
 I=10 L= 174 Time= 0.556 Sec.
 I=11 L= 349 Time= 0.568 Sec.
 I=12 L= 698 Time= 0.556 Sec.
 I=13 L= 1396 Time= 0.556 Sec.
 I=14 L= 2794 Time= 0.564 Sec.
 I=15 L= 5588 Time= 0.556 Sec.
 I=16 L= 11176 Time= 0.556 Sec.
 I=17 L= 22353 Time= 0.540 Sec.
 I=18 L= 44707 Time= 0.524 Sec.
 I=19 L= 89415 Time= 0.488 Sec.
 End of main loop
 End of calculation. Time= 11.041 Sec.
 End of data output. Time= 0.068 Sec.
 Total calculation(I/O) time= 11.109( 0.356) Sec.

echo 10 > /sys/devices/system/cpu/cpu*/ondemand/sampling_down_factor

 ------ Started super_pi run : Thu Sep 29 22:04:10 BST 2011
 Start of PI calculation up to 1048576 decimal digits
 End of initialization. Time= 0.124 Sec.
 I= 1 L= 0 Time= 0.356 Sec.
 I= 2 L= 0 Time= 0.404 Sec.
 I= 3 L= 1 Time= 0.396 Sec.
 I= 4 L= 2 Time= 0.404 Sec.
 I= 5 L= 5 Time= 0.400 Sec.
 I= 6 L= 10 Time= 0.396 Sec.
 I= 7 L= 21 Time= 0.404 Sec.
 I= 8 L= 43 Time= 0.400 Sec.
 I= 9 L= 87 Time= 0.400 Sec.
 I=10 L= 174 Time= 0.400 Sec.
 I=11 L= 349 Time= 0.400 Sec.
 I=12 L= 698 Time= 0.396 Sec.
 I=13 L= 1396 Time= 0.404 Sec.
 I=14 L= 2794 Time= 0.400 Sec.
 I=15 L= 5588 Time= 0.392 Sec.
 I=16 L= 11176 Time= 0.400 Sec.
 I=17 L= 22353 Time= 0.388 Sec.
 I=18 L= 44707 Time= 0.372 Sec.
 I=19 L= 89415 Time= 0.340 Sec.
 End of main loop
 End of calculation. Time= 7.884 Sec.
 End of data output. Time= 0.052 Sec.
 Total calculation(I/O) time= 7.936( 0.284) Sec.

echo 100 > /sys/devices/system/cpu/cpu*/ondemand/sampling_down_factor

Start of PI calculation up to 1048576 decimal digits
 End of initialization. Time= 0.120 Sec.
 I= 1 L= 0 Time= 0.336 Sec.
 I= 2 L= 0 Time= 0.380 Sec.
 I= 3 L= 1 Time= 0.392 Sec.
 I= 4 L= 2 Time= 0.384 Sec.
 I= 5 L= 5 Time= 0.384 Sec.
 I= 6 L= 10 Time= 0.384 Sec.
 I= 7 L= 21 Time= 0.384 Sec.
 I= 8 L= 43 Time= 0.380 Sec.
 I= 9 L= 87 Time= 0.384 Sec.
 I=10 L= 174 Time= 0.380 Sec.
 I=11 L= 349 Time= 0.388 Sec.
 I=12 L= 698 Time= 0.380 Sec.
 I=13 L= 1396 Time= 0.380 Sec.
 I=14 L= 2794 Time= 0.384 Sec.
 I=15 L= 5588 Time= 0.376 Sec.
 I=16 L= 11176 Time= 0.380 Sec.
 I=17 L= 22353 Time= 0.364 Sec.
 I=18 L= 44707 Time= 0.356 Sec.
 I=19 L= 89415 Time= 0.336 Sec.
 End of main loop
 End of calculation. Time= 7.540 Sec.
 End of data output. Time= 0.044 Sec.
 Total calculation(I/O) time= 7.584( 0.276) Sec.

[Daniel Hollocher (chogydan)]

I can comment on this. First off, sampling_down_factor = 1 disables the feature, so it is a bit the opposite of what you describe. I believe what's happening is that ondemand can fail for certain cpu's (including mine), and instead of amping up the frequency under heavy load, it will resonate the frequency, switching it up and down.

sampling_down_factor delays, geometrically, how fast ondemand will down scale the frequency, and can thus reduce this issue.

From the patch author: "Set to 1 it makes no changes from existing behavior, but set to greater than 1 (e.g. 100) it acts as a multiplier for the scheduling interval for reevaluating load when the CPU is at its top speed due to high load. This improves
performance by reducing the overhead of load evaluation and helping the CPU stay at its top speed when truly busy, rather than shifting back and forth in speed. This tunable has no effect on behavior at lower speeds/lower CPU loads."

It's been awhile since I've looked at this, but running a few javascript tests, it looks like I still have this issue. I guess I need to work this tunable myself!

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel Hollocher (chogydan)]

im looking into a possible work around by adding the tunable setting into /etc/init.d/ondemand

[penalvch (penalvch)]

Obrouni, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available (not the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.13-rc3

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]