[T-Mobile Samsung Galaxy Note 3] cun7:
Many people have tried this governor out, but few have tested it in the 3 most important categories that should be considered when deciding which governor is the best for you:

=====================

UPDATED 2/23 - I have been getting a lot of PMs about what settings I specifically use for for the interactive governor and the deadline IO scheduler. See the end of this post for those settings.

=====================

Performance

Battery Life

CPU times

First, let’s talk about the MAIN reason this governor stands out above the default “ondemand” for probably most if not all Android devices….. TIME. Yes, time. The main difference between the two governors is that interactive operates more on timed values instead of actually calculating load and trying to compensate for the ever changing size and number of operations being asked of the CPU to execute. Always adjusting based upon load, determining that load, and compensating for it costs you two things – TIME (again this word is used, but in the dynamic of the ondemand governor, I reference it in a negative way – a cost or penalty) and latency. Ondemand uses up and down threshold values to figure out how to bring the CPU out of idle or back down to idle, etc. A predetermined “tick” of 50,000 ms to check what kind of load is being placed on the CPU. This is done going up AND going down.

Interactive uses timers to adjust. There is a “tick” much like ondemand, but it is significantly shorter and the way it responds is a bit more clever. Rather than try to play cat and mouse with your operation requests, it uses timers to more aggressively respond and handle a work queue. From android.googlesource.com:

“The CPUfreq governor "interactive" is designed for latency-sensitive,
interactive workloads. This governor sets the CPU speed depending on
usage, similar to "ondemand" and "conservative" governors. However,
the governor is more aggressive about scaling the CPU speed up in
response to CPU-intensive activity."

Now let’s look at the brains of the governor:

[U]min_sample_time:[/U] The minimum amount of time to spend at the current
frequency before ramping down. This is to ensure that the governor has
seen enough historic cpu load data to determine the appropriate
workload. Default is 80000 uS.

[U]hispeed_freq:[/U] An intermediate "hi speed" at which to initially ramp
when CPU load hits the value specified in go_hispeed_load. If load
stays high for the amount of time specified in above_hispeed_delay,
then speed may be bumped higher. Default is maximum speed.

[U]go_hispeed_load:[/U] The CPU load at which to ramp to the intermediate "hi
speed". Default is 85%.

[U]above_hispeed_delay:[/U] Once speed is set to hispeed_freq, wait for this
long before bumping speed higher in response to continued high load.
Default is 20000 uS.

[U]timer_rate:[/U] Sample rate for reevaluating cpu load when the system is
not idle. Default is 20000 uS.

And here we even have the option to use hispeed_freq as a touch module:

[U]input_boost:[/U] If non-zero, boost speed of all CPUs to hispeed_freq on
touchscreen activity. Default is 0.

What you can clearly see here is the distinction of making operations time sensitive instead of load sensitive. Rather brilliant. What this does is removes the “calculation” factor from the equation and allows the user to completely take control of the device in terms of (remember those 3) performance, battery life, CPU times! The last two are closely related and could be thought of as one.

Studying these values, and testing them individually myself, I have found that the trick is to set the hispeed_freq to approximately 70-75% of the CPU’s STOCK speed. So for a note 3, right around 1.72 GHz (if you do not use the touch boost module). And what we want to do is make this parameter extremely aggressive by inputting a value right around 60-65 for go_hispeed_load.

What this does is give you a very snappy response mechanism for medium intensive tasks without spinning the CPU up unnecessarily. Most things you do on a day to day basis will not require the processor to be ramped to max. Ondemand, however, shows behavior patterns in CPU times that are FAR more aggressive – the reason is the latency issue with ondemand (playing cat and mouse as I stated earlier) and not being as capable of keeping up with your ever changing dynamic work queues.

I would rather not write a novel, all of this just rolled off the keys just now because I was bored, but any questions about comparisons between the two governors, please feel free to post here and I will do my best to reply with something useful to you. For a reference, here are my personal settings for this governor:

My personal settings for

interactive:

above_hispeed_delay: 15000

boost: 0

boostpulse_duration: 60000

go_hispeed_load: 70

hispeed_freq: 1728000

io_is_busy: 0

min_sampling_time: 60000

target_loads: 90

timer_rate: 15000

timer_slack: 60000

My personal settings for

deadline:

add_random: 1

iostats: 1

nomerges: 0

rotational: 0

rq_affinity: 1

fifo_batch: 4

front_merges: 1

read_expire: 500

write_expire: 3000

writes_starved: 3