[Galaxy Note 4 Android Development (Snapdragon)] ph03n!x:
Great thread!! Thanks for taking time to compiling this stuff :) And glad to see someone from my home time (Nagercoil is where I grew up!)!!

A couple of suggestions though:

What this will do is hold frequencies from 300 MHz till 422 MHz until 98% CPU load (that is, hold 300 MHz until the load is 98%, then ramp up to 345 MHz, hold till 98% and then ramp to 422 MHz), ramp from 422 MHz till 729 MHz at 5% CPU load (jump from 422 MHz to 499% at 5% load and so on), ramp from 729 MHz to 1190 MHz at 15% load, ramp from 1190 MHz to 1344 MHz at 30% load, and so on. This will of course be overruled by go hi-speed load, which means at 95%, the CPU will jump to 499 MHz and then ramp according to above after 499 MHz, or the input boost freq when a touch is sensed (for example).

While the setting for this purely based on individual use case, as well as depends on how other sysfs for interactive governor is configured (timer rate, slack, etc.), my settings for target_load are:

75 883200:85 1267200:95 2035200:99

This is based on two logic:

- Voltage from 300 MHz to 883 MHz varies from 680 mV to 760 mV in 10 mV increments, and jumps to 830 mV at 960 MHz and increments at 10 mV till 2035 MHz (970 mV). It jumps to 985 mV at 2112 MHz and scales at 15 mV for each step there on. I am trying to keep most light loads at 883 MHz or below (scale from 300 MHz to 345 MHz when the load touches 75% and so on till 883 MHz, and then ramp till 1267 MHz when the load touches 85%.

- This will keep almost all day to day tasks - reading XDA or news or some website after it is loaded, messages etc. at mostly under 883 MHz. Note that my high speed load is 1267 MHz, at 80% go hispeed load, timer rate of 30000, time slack of 80000 and min sample time of 50000 (all 'boost' disabled). I hike my min sample time till 80000 in case I face stutter in high end loads (Asphalt, for instance).

What this does is hold on to frequencies (before scaling up to a higher freq when a target load is achieved based on the timer rate) between 499 MHz till 729 MHz (499 MHz being your hispeed freq) for 20000 uS, and between 729 MHz till 1190 MHz, and so on (all groups having the same delay of 20000) until 1497 MHz where it will hold for 30000 uS until 1574 MHz, falls back to 20000 uS until 2035 MHz and hold freq for 15000 uS till 2265 MHz and so on.

A simpler sysfs that would do the same will be

20000 1497600:30000 1574400:20000 2035200:15000 2265600:20000

Again, my values for this vary- I ramp up every freq until my hispeed freq of 1267 MHz with a timer rate of 40000 uS, and hold for 50000 uS before ramping down (min sample time). After the hispeed freq, I use this for above hispeed delay

60000 1457600:80000 2035200:100000

This ties with the logic I explained earlier on the optimal frequencies based on voltage, ramp till 1267 MHz based on the timer rate/ slack, spend at least 60000 uS at each step between 1267 MHz and 1457 MHz, 80000 uS at each step between 1457 MHz and 2035 MHz and so on, if the load still exists after spending so much time at the frequency groups.

In other words, spend more time in frequencies that are more economical for power consumption and ramp up only with sustained load instead of spiking up (and spending 50000 uS, the min sample time, at the higher freq).

Important to note - these are my economy settings. It wont be 'snappy', and may stutter a wee bit now and then. I am using these values just to explain the settings.

More interesting reads on the governors, including interactive, here.

With that said, can anyone help me help with understanding what these values do? I ain't going to look up the source code until later this week, these are not part of the "standard" interactive and seem to be Sammy's addition to interactive, primarily targeted at the octacore in the 2015 flagships:

bimc_hispeed_freq
bk_locked
enforced_mode
mode
multi_enter_mode
multi_enter_time
multi_exit_load
multi_exit_time
param_index
single_enter_mode
single_enter_time
single_exit_load
single_exit_time
sync_freq
up_threshold_any_cpu_freq
up_threshold_any_cpu_load