part 2 of (usefull post must see) Everything about overclocking kernels governors, i/o schedulers e.t.c

(First post extended here. )

2. SAMPLE GOVERNOR TWEAKS

III) PARAMETERS & TWEAKS: 

[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 Interval/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.
vi) freq_step - Whenever up-scaling logic is triggered the governor instructs the CPU to raise its frequency by freq_step percentage of max allowed frequency. (max policy * (freq step / 100)). Ex: max policy is 1600 and freq step 21%, it will scale 1600 * 21% = 336. We have a 100MHz grained frequency table so it rounds up to the next 100MHz, hence 336 becomes 400. So say we're idling at 200MHz and the up-scaling logic gets triggered with the above settings, the next frequency will be 600MHz. Note that freq_step and smooth_scaling does pretty much the same thing.

[ SAMPLE TWEAKS ]

i) For battery:-

To bias ondemand towards battery saving, set high up-thresholds and higher sampling-rate. This way, governor polls less often and scales up less often.

Code:

echo "95" /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo "120000" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
echo "1" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
echo "5" > /sys/devices/system/cpu/cpufreq/ondemand/down_differential
echo "10" > /sys/devices/system/cpu/cpufreq/ondemand/freq_step

ii) For performance:-

To bias ondemand towards performance, set low up-thresholds and lower sampling-rate. This way, governor polls more often and scales up quite often.

Code:

echo "70" > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo "50000" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
echo "2" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
echo "15" > /sys/devices/system/cpu/cpufreq/ondemand/down_differential
echo "50" > /sys/devices/system/cpu/cpufreq/ondemand/freq_step

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.

[ SAMPLE TWEAKS ]

Unfortunately, the initial version of lulzactive doesn't give user much control on it's behavior. We can only control how often cpu should scale up and scale down. Use higher down_sampling_time if you experience lag while scrolling through browser, app drawer, etc. Better keep the default up_sampling time (24000) unchanged. And make down_sampling proportional to up_sampling. Like 2x24000=48,000 or 3x24000=72000.

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)

[ SAMPLE TWEAKS ]

i) For battery:-

Code:

echo "90" > /sys/devices/system/cpu/cpufreq/lulzactive/inc_cpu_load
echo "1" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_up_step
echo "2" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_down_step
echo "50000" > /sys/devices/system/cpu/cpufreq/lulzactive/up_sample_time
echo "40000" > /sys/devices/system/cpu/cpufreq/lulzactive/down_sample_time
echo "5" > /sys/devices/system/cpu/cpufreq/lulzactive/screen_off_min_step

This tweak cause lulzactive gradually scale up CPU and rapidly scale down on low load.

ii) For performance:-

Code:

echo "60" > /sys/devices/system/cpu/cpufreq/lulzactive/inc_cpu_load
echo "4" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_up_step
echo "1" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_down_step
echo "10000" > /sys/devices/system/cpu/cpufreq/lulzactive/up_sample_time
echo "70000" > /sys/devices/system/cpu/cpufreq/lulzactive/down_sample_time
echo "5" > /sys/devices/system/cpu/cpufreq/lulzactive/screen_off_min_step

This tweak cause lulzactive scale up CPU rapidly, polling often and scale down gradually.

iii) For balanced-performance:-

Code:

echo "90" > /sys/devices/system/cpu/cpufreq/lulzactive/inc_cpu_load
echo "4" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_up_step
echo "1" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_down_step
echo "10000" > /sys/devices/system/cpu/cpufreq/lulzactive/up_sample_time
echo "40000" > /sys/devices/system/cpu/cpufreq/lulzactive/down_sample_time
echo "5" > /sys/devices/system/cpu/cpufreq/lulzactive/screen_off_min_step

This tweak cause lulzactive to poll more often and scale up 4 steps above current frequency, but only at 90% load. CPU is scaled down normally.

note: If you're lazy to use a script, use lulzactive app from market to tweak the governor. https://market.android.com/details?i...rak.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.

[ SAMPLE TWEAKS ]

i) For battery:-

Code:

echo "500000" > /sys/devices/system/cpu/cpufreq/smartass/awake_ideal_freq;
echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_ideal_freq;
echo "500000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_wakeup_freq
echo "85" > /sys/devices/system/cpu/cpufreq/smartass/max_cpu_load;
echo "70" > /sys/devices/system/cpu/cpufreq/smartass/min_cpu_load;
echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/ramp_up_step;
echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/ramp_down_step;
echo "48000" > /sys/devices/system/cpu/cpufreq/smartass/up_rate_us
echo "49000" > /sys/devices/system/cpu/cpufreq/smartass/down_rate_us

ii) For performance:-

Code:

echo "800000" > /sys/devices/system/cpu/cpufreq/smartass/awake_ideal_freq;
echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_ideal_freq;
echo "800000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_wakeup_freq
echo "75" > /sys/devices/system/cpu/cpufreq/smartass/max_cpu_load;
echo "45" > /sys/devices/system/cpu/cpufreq/smartass/min_cpu_load;
echo "0" > /sys/devices/system/cpu/cpufreq/smartass/ramp_up_step;
echo "0" > /sys/devices/system/cpu/cpufreq/smartass/ramp_down_step;
echo "24000" > /sys/devices/system/cpu/cpufreq/smartass/up_rate_us
echo "99000" > /sys/devices/system/cpu/cpufreq/smartass/down_rate_us

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.

[ SAMPLE TWEAKS ]

i) For battery:- [Set freq_step to lower value to make conservative governor conserve more battery]

Code:

echo "95" > /sys/devices/system/cpu/cpufreq/conservative/up_threshold
echo "120000" > /sys/devices/system/cpu/cpufreq/conservative/sampling_rate
echo "1" > /sys/devices/system/cpu/cpufreq/conservative/sampling_down_factor
echo "40" > /sys/devices/system/cpu/cpufreq/conservative/down_threshold
echo "10" > /sys/devices/system/cpu/cpufreq/conservative/freq_step

ii) For performance:- [Isn't it ironical that we are tuning Conservative to achieve blazing performance!]

Code:

echo "60" > /sys/devices/system/cpu/cpufreq/conservative/up_threshold
echo "40000" > /sys/devices/system/cpu/cpufreq/conservative/sampling_rate
echo "5" > /sys/devices/system/cpu/cpufreq/conservative/sampling_down_factor
echo "20" > /sys/devices/system/cpu/cpufreq/conservative/down_threshold
echo "25" > /sys/devices/system/cpu/cpufreq/conservative/freq_step

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.

[ SAMPLE TWEAKS ]

i) For battery:- [Interactive and battery?!! I'm capping the highspeed_freq in the hope of saving battery]

Code:

echo "95" > /sys/devices/system/cpu/cpufreq/interactive/go_hispeed_load
echo "1000000" > /sys/devices/system/cpu/cpufreq/interactive/hispeed_freq
echo "10000" > /sys/devices/system/cpu/cpufreq/interactive/min_sample_time
echo "40000" > /sys/devices/system/cpu/cpufreq/interactive/timer_rate

ii) For performance:- [Assuming your scaling_max_freq is equal to or above 1400 mhz)

Code:

echo "80" > /sys/devices/system/cpu/cpufreq/interactive/go_hispeed_load
echo "1400000" > /sys/devices/system/cpu/cpufreq/interactive/hispeed_freq
echo "40000" > /sys/devices/system/cpu/cpufreq/interactive/min_sample_time
echo "20000" > /sys/devices/system/cpu/cpufreq/interactive/timer_rate

IV) GUIDE TO INIT.D SCRIPTS 

When I'm writing tweaks all over the thread, it's unfair if i don't cover a small guide to scripts since there are people who does not have any experience or knowledge on init.d scripts. So here are the "WHATs" and "HOWs".

If you're already familiar with init.d scripts, please skip this part.

Android boot-up process can be divided into three parts on a high-level.
1) First stage bootloader runs.
2) Kernel boots and it loads various drivers, prepares hardware and so on.
3) User space programs are invoked. It is in this stage where init.d scripts are executed. (Also various apps and daemons are started to prepare the rom)

• Most of the custom kernels supports init.d scripts. Some developers choose to run init.d scripts whose names starts with an "S". Others choose to execute all the scripts inside init.d directory.
• Init.d script are to be placed inside /system/etc/init.d directory (or /etc/init.d which is a symbolic link to /system/etc/init.d)
• Order of executing init.d scripts are in the increasing order of ASCII values that corresponds to their names. For ex: among two scripts named, "Ascript1" and "Bscript2", "Ascript1" will be executed first. If there is a particular reason that we need one script to be executed before another, make sure you name it properly.

GUIDE:

• First line of any script should invoke a compatible shell/interpreter which is responsible for executing the rest of the script. The compatible shell may be the default shell "sh" or "busybox".
• So first line of any script should look like this:
  #!/sbin/busybox sh or #!/system/xbin/busybox sh [The location of busybox may vary with roms/devices. So please check with root explorer, busybox location and change the path accordingly]
  OR
  #!/system/bin/sh
• From next line, the actual script starts.
  ex: echo "200000" > /sys/devices/system/cpu/spu0cpufreq/scaling_max_freq
• Make sure there are no syntax errors first, (also check for logical errors)
• Most common error is to use a windows-based editor which leaves an extra space at the end of each line or leaves an invisible invalid character when you press carriage return (ENTER key).
• So do not use editors such as notepad or wordpad to create scripts. Use Notepad++, a free GNU editor.
• After finishing the script, check for extra spaces at the beginning and end of each line in the script. If found, remove them.
• Save the script without any extensions (Yes, not even .sh extension).
• Use adb or rootexplorer to push the script into /etc/init.d and set permissions.
  Read this beautiful guide on how to install SDK and setup ADB without any hassle on your PC.
• Using root explorer, copy the script to /etc/init.d and set permissions:
  owner : rwx
  group : r_x
  others : r_x
• Download script manager from market, use it to run the script as root by checking the skull symbol. This is only to check the script for any errors. If exit code= 0, script executed successfully. From now on, your script will be automatically executed on every reboot. But if script manager shows errors, again edit the script (using notepad++ in your PC or using script manager editor itself from your phone), fix the errors and execute again. Repeat this until script is error-free. Remember once again: "A single extra space at the end of a line is a syntax error and script will fail to execute the rest of the lines."
• To add comments you can use "#"
  
  Sample Script:
  
  Code:

  #!/sbin/busybox sh
  
  #No of values echoed to freq table and uvmv table should match the no of steps in your kernel
  echo "1600 1400 1200 1000 800 500 200 100" > /sys/devices/system/cpu/cpu0/cpufreq/freq_table
  echo  "1425 1325 1275 1175 1075 975 950 950"> /sys/devices/system/cpu/cpu0/cpufreq/UV_mV_table
  echo "200" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
  echo "1200" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
  echo "ondemandx" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

To Do:

1) Sample SmartassV2 gov tweaks - DONE
2) Sample Interactive gov tweaks - DONE
3) Technical explanation on working of popular governors by the aid of parameters. - Half done, scattered along Posts
4) More questions in Question Time section - IN PROGRESS


more coming part 3 link will be posted