[HTC EVO 3D] mnomaanw:
(First post extended here. )

2.GOVERNOR PARAMETERS ​

[Only Ondemand, Conservative, SmartassV2, Lulzactive and Interactive; being the most preferred governors.]

Different governors has different parameters. But it's easy to understand a governor. Ideally, a governor will have:-

1) Sampling Time/Rate measured in uS by which the polling function determines how often to poll and decide if frequency should be scaled-down or scaled-up. [Some governors will have different sampling time for scaling-up and scaling-down]

2) Thresholds measured in percentage. When CPU load reaches this point, governor scales up or scales down the CPU. [Most of the governors will have down-threshold and up-threshold, for which CPU is scaled down or up respectively.

There are various other parameters/factors too, but all are in someway related to these two parameters.

1.ONDEMAND

[ PARAMETERS ]

i) sampling_rate - Measured in uS , this is how often the kernel look at the CPU usage and make decisions on what to do about the frequency. Higher values means CPU polls less often. For lower frequencies, this could be considered an advantage since it might not jump to next frequency very often, but for higher frequencies, the scale-down time will be increased.

ii) up_threshold - Measured in percentage 1-100, When CPU load reaches this point, governor will scale CPU up. Higher value means less responsiveness and lower values corresponds to more responsiveness at the cost of battery.

iii) powersave_bias - Default value is 0. Setting a higher value will bias the governor towards lower frequency steps. Use this if you want CPU to spend less time on higher frequencies. A better alternative would be to underclock to a lower frequency than using powersave bias.

iv) sampling_down_factor - In the simplest form, sampling_down_factor determines how often CPU should stay at higher frequencies when truly busy. Default behavior is fast switching to lower frequencies (1). Having sampling_down_factor set to 1 makes no changes from existing behavior (for the non-modified ondemand), but having sampling_down_factor set to a value greater than 1 causes it to act as a multiplier for the scheduling interval for re-evaluating the load when the CPU is at its highest clock frequency (which is scaling_max_freq) due to high load. This improves performance by reducing the overhead of load evaluation and helping the CPU stay at its highest clock frequency when it is truly busy, rather than shifting back and forth in speed. This tunable has no effect on behavior at lower frequencies/lower CPU loads.

v) down_differential - This factor indirectly calculate the 'down-threshold' of Ondemand. After completing sampling-down-factor*sampling-rate at max frequency because of high load, governor samples the load again to calculate an estimate of the new target frequency in a way that the lowest frequency will be chosen that would not trigger up_threshold in the next sample. Because triggering up-threshold will again cause CPU to scale up to max frequency. During this choice down_differential is taken into account as a breathing room value. Target frequency is calculated as max_load_freq / (up_threshold - down_differential). The obtained value might be a non-existent value in the freq_table and CPU driver will round it off to a value in freq_table. max_load_freq is the theoretical frequency at which CPU can handle 100% workload. It is usually a value below scaling_max_freq. See this post by AndereiLux for more info.​

2.LULZACTIVE

1. Initial Version:-

[ PARAMETERS ]

i) down_sampling_time - Sampling time to scale cpu down.

ii) up_sampling_time - Sampling time to scale cpu up.​

2. Second Version:-

[ PARAMETERS ]

i) inc_cpu_load - In previous version, this was 'hard-coded' to 60. Now it's user-configurable. The frequency at which governor scales CPU up/down. Load < inc_cpu_load: cpu scaled down. Load >= inc_cpu_load: cpu scaled up

ii) pump_up_step - No of scale up steps when load >= inc_cpu_load

iii) pump_down_step - No of scale down steps when load < inc_cpu_load

iv) screen_off_min_step - Steps in frequency table to be used when screen-off. Example: If available freqs are 1600 1400 1200 1000 800 500 200 100 (L0 to L7) and screen_off_min_step=5 then 100,200 and 500 (L5 to L7) will be used during screen-off depending on the demand.

v) up_sample_time - same as initial version. (Allowed values 10,000 to 50,000)

vi) down_sample_time - same as older version. (Allowed values 10,000 to 100,000)​

note: If you're lazy to use a script, use lulzactive app from market to tweak the governor. https://market.android.com/details?id=com.tegrak.lulzactive

3.SMARTASSV2

[ PARAMETERS ]

i) awake_ideal_freq - The frequency until which CPU is scaled up rapidly on screen-awake (from sleep). Thereafter, scaling up is less aggressive.

ii) sleep_ideal_freq - The frequency until which CPU is scaled down rapidly when screen is turned off. Thereafter, scaling down is less aggressive.

iii) up_rate_us - The minimum amount of time to spend at a frequency before we can ramp up. (Ignored below awake-ideal frequency since governor needs to rapidly scale up to awake_ideal_freq when below it)

iv) down_rate_us - The minimum amount of time to spend at a frequency before we can ramp down. (Ignored above sleep-ideal frequency since governor needs to rapidly scale down to sleep_ideal_freq when above it)

v) max_cpu_load - Same as up_threshold in other governors.

vi) min_cpu_load - Same as down_threshold in other governors.

vii) ramp_down_step - Frequency delta when ramping down below the ideal frequency. Zero disables and will calculate ramp down according to load heuristic. When above the ideal frequency we always ramp down to the ideal freq.

viii) ramp_up_step - Frequency when ramping up above the ideal frequency. Zero disables and causes to always jump straight to max frequency. When below the ideal frequency we always ramp up to the ideal freq.

ix) sleep_wakeup_freq - The frequency to set when waking up from sleep. When sleep_ideal_freq=0 this will have no effect.​

4.CONSERVATIVE

[ PARAMETERS ]

i) down_threshold, ii) up_threshold, iii) sampling_down_factor, iv) sampling_rate - Refer above governors.

v) freq_step - Defines how much (as a percentage of the maximum CPU speed) the conservative governor will increase the CPU speed by each time the CPU load reaches the Up Threshold.
​

5.INTERACTIVE

[ PARAMETERS ]

i) hispeed_freq - Hi speed to bump to from lo speed when load burst. (Default value is scaling max freq)

ii) go_hispeed_load - Go to hi speed when CPU load at or above this value. (Similar to Up-Threshold in other governors)

iii) min_sample_time - The minimum amount of time to spend at a frequency before we can ramp down. (Sounds like Lazy governor?!)

iv) timer_rate - The sample rate of the timer used to increase frequency.
​