Android CPU Frequency Interactive Governor

The interactive governor is similar to ondemand in that it will try to scale the frequency to the load, but interactive is quite a bit more complex on the tuning.

You can check if you’re using interactive in cpufreq this way:

root@:/ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
interactive

If you’re not using interactive then echo interactive to the scaling_governor. Then check again to make sure you have that governor.

Here’s a list of the parameters we have to play with in the /sys/devices/system/cpu/cpufreq/interactive directory.

above_hispeed_delay
boost
boostpulse
boostpulse_duration
go_hispeed_load
hispeed_freq
min_sample_time
timer_rate
timer_slack

above_hispeed_delay Once the governor hits the hispeed_freq, it should wait at least this many useconds before increasing the frequency again due to high load. Making this number higher will make it so your device will hit frequencies higher than hispeed_freq less often. You can also add more than one cpu frequency delay combination like this: 80000 1200000:200000 1300000:40000 Which would make the default delay 80ms, but 200ms if the cpu frequency is above 1.2ghz and 40ms if the frequency is above 1.3ghz.

boost This is the hacky interface applications can use to artificially increase the cpu frequency; even though the load might not be high enough to warrant it. Set this to 1 and all CPUs will have their minimum frequency set to hispeed_freq. Set it back to 0 to disable boost.

boostpulse Similar to boost but is only effective for a limited time. Each write to this node increases the minimum frequency for all CPUs to hispeed_freq for a boostpulse_duration amount of time.

boostpulse_duration The time boostpulse can keep the CPU frequency high.

go_hispeed_load The CPU load that will immediately bump up the CPU frequency to hispeed_freq. For loads less than go_hispeed_load the governor will try to calculate the optimal frequency for the given load, but once the CPU gets busy enough to cross the go_hispeed_load threshold it will immediately increase the frequency.

hispeed_freq This is the frequency that you assume will adequately handle performance situations, but isn’t especially good for power. You use the other parameters for selectively choosing situations where this frequency should be used.

min_sample_time The minimum amount of time the governor must wait at a given frequency until it can decide to reduce the frequency.

timer_rate The sampling time the governor operates at. If this was 20ms there would be a timer that fires every 20ms to calculate how busy the CPU is and if the frequency should be increased/decreased.

timer_slack This is for handling special corner cases related to power. You see the timer_rate timer is usually a deferrable timer — that means that the timer won’t wake up the CPU if it is completely idle. Imagine that a CPU is running at near 100% load and interactive increases the frequency to maximum, then the load is suddenly taken away and the CPU is completely idle. Because it’s idle the interactive governor won’t run again which means the CPU is stuck at the maximum frequency and is leaking a great deal of power. The solution here is to have a threshold where after timer_slack amount of time the interactive governor will definitely run and reduce the frequency if necessary.

Since the interactive governor has more capabilities than ondemand I expect it to be used more frequently in the future. Many Android devices already have it as the default governor.