Related
Hi guys,
Please clarify on the following points:
1. Are there any major differences among the CPU governers??? I use Smartass because I see a major group of people using it.
2. What are the optimal values for Min and Max CPU speed? And are there any factors based on which we have to decide the values or we can keep anything we wish?
Thanks in advance
Frequencies and their effect on battery here
^Pretty much what you're looking for. Just analyze the chart and test it for yourself too. Also read, read
For governors:
smartass governor - is based on the concept of the interactive governor.
I have always agreed that in theory the way interactive works - by taking over the idle loop - is very attractive. I have never managed to tweak it so it would behave decently in real life. Smartass is a complete rewrite of the code plus more. I think its a success. Performance is on par with the "old" minmax and I think smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
Smartass will also cap the max frequency when sleeping to 352Mhz (or if your min frequency is higher than 352 - why?! - it will cap it to your min frequency). Lets take for example the 528/176 kernel, it will sleep at 352/176. No need for sleep profiles any more.
ondemand
Available in most kernels, and the default governor in most kernels. When the CPU load reaches a certain point (see "up threshold" in Advanced Settings), ondemand will rapidly scale the CPU up to meet demand, then gradually scale the CPU down when it isn't needed. - SetCPU website
conservative
Available in some kernels. It is similar to the ondemand governor, but will scale the CPU up more gradually to better fit demand. Conservative provides a less responsive experience than ondemand, but can save battery. - SetCPU website
performance
Available in most kernels. It will keep the CPU running at the "max" set value at all times. This is a bit more efficient than simply setting "max" and "min" to the same value and using ondemand because the system will not waste resources scanning for the CPU load. This governor is recommended for stable benchmarking. - SetCPU website
powersave
Available in some kernels. It will keep the CPU running at the "min" set value at all times. - SetCPU website
userspace
A method for controlling the CPU speed that isn't currently used by SetCPU. For best results, do not use the userspace governor. - SetCPU website
interactive
Advantages:
+ significantly more responsive to ramp cpu up when required (UI interaction)
+ more consistent ramping, existing governors do their cpu load sampling in a workqueue context, the 'interactive' governor does this in a timer context, which gives more consistent cpu load sampling.
+ higher priority for cpu frequency increase, rt_workqueue is used for scaling up, giving the remaining tasks the cpu performance benefit, unlike existing governors which schedule rampup work to occur after your performance starved tasks have completed.
Click to expand...
Click to collapse
I hope that makes it clearer
Kira.Lawliet said:
Frequencies and their effect on battery here
^Pretty much what you're looking for. Just analyze the chart and test it for yourself too. Also read, read
I hope that makes it clearer
Click to expand...
Click to collapse
Wonderful post! Thank you.. even though the post was too technical for a n00b like me, I could grasp info out of it. Sure it helped me.
I am wondering if anyone knows how to tune the controls that are included in the Simple GPU Algorithm and Adreno Idler that are on custom kernels.
I am wanting to know what each thing does and what happens when you put the value higher or lower on each control .
Simple GPU Algorithm
Ram Thresold
Lazieness:
Adreno Idler
Down Differential:
Idle Wait:
Workload:
I want to know how to turn it for saving battery and or performance. Im trying to fine tune my settings to get longer SOT and less heat.
CPU Governors, Hotplug drivers and GPU governors Explained Part 3 (Updated 23/12/16)
--------------------------------------------------------------------------------------------------------------------------------------------
Official XDA thread Of The Contributer: http://forum.xda-developers.com/member.php?u=5811506
Edited By ShivaY: http://forum.xda-developers.com/member.php?u=6704044
Guide Part 1 Link: http://forum.xda-developers.com/lenovo-a6000/how-to/cpu-governors-hotplug-drivers-gpu-t3528762
Guide Part 2 Link: http://forum.xda-developers.com/lenovo-a6000/how-to/cpu-governors-hotplug-drivers-gpu-t3528766
Guide Part 4 Link : http://forum.xda-developers.com/lenovo-a6000/how-to/cpu-governors-hotplug-drivers-gpu-t3528772
Here I've gathered some info for newcomers to the Android world.I've tried to keep it relatively simple. So if you want more info Comment Below
Recommended apps for manipulating kernel values:
1. Kernel Adiutor (Free to change governor and tune variables)
2. Kernel Adiutor-Mod (Free to change governor and tune variables)
3. Compatible kernel managers (e.g Stweaks, Synapse, UKM, etc.)
Hotplug drivers:
------------------------
mpdecision: Qualcomm's default hotplugging driver. One of the most widely used hotplug drivers in all android devices.
msm_hotplug: Great battery life, a custom qualcomm based hotplugging driver by myflux. It is a popular choice for many users.
intelliplug: Great balance between battery life and performance. It is also a popular hotplug driver from faux123.
Alucard: A great hotplugging driver by Alucard. It is known to be very battery friendly on devices.
Kt Auto Hotplug: A great hotplug driver by Ktoonsez. Pretty much a smarter mpdecision that has been optimized for quad-core devices.
Mako Hotplug: A new popular hotplugging driver found in Francokernel. This is a highly configurable driver that can be configured to use dual core for light-loads and quad-core for heavy loads.
Zen Decision: ZEN only onlines all cores when screen is on, it also takes thermal events into account and wont online any core back, if you're under 15% battery, or currently have a thermal event because of heat. So in the end it isn't a "real" hotplug driver, because it doesnt have any code for active hot plugging in it. That means you can't change its behavior.
Bricked Hotplug: Conservative hotplug driver by @showp1984. It is based on mpdecision but has been optimized for better balance between battery life and performance.
msm_sleeper: The main feature with this hotplug is that you can customize the screen off frequency. Two cores are always on, the third and fourth are independent and come online if needed. By default, if the load is over 80 for 400ms another core comes online. The third and/or fourth cores stay online as long as the load demands it or for a minimum of one second. While the screen is off, it goes down to a single core. Created by flar2.
Autosmp: A highly-efficient hotplug driver by @mrg666, works in-sync with the CPU governor to enable off-line cpu cores when the the CPU frequency reaches a high threshold and still more compute power is needed. Therefore, touch boost bloat is removed.
Thunderplug: A matured load-based hotplug driver with many tunables written from ground up by varun.chitre15. This hotplug is optimized for octa-core devices and also has support for 64bit CPUs.
Blu_plug: Dynamic hotplug from eng.stk's shamu kernel with screenoff battery saving.
cpuquiet: A hotplug driver by NVidia and ported to Snapdragon by maxwen. Originally made for NVidia tegra SOCs. It has a set of governors which keep the CPU running at optimal frequencies for battery and performance.
Fast hotplug: A hotplug driver from pec0ra's abricot kernel. It aims to be as lightweight as possible while also being highly customizable. However, it is still a WIP as it is known to have some stability issues.
Hima hotplug: An optimized hotplug driver based on intelliplug for big.LITTLE architecture. Found on chadouming's HTC One (M9) kernel, it takes advantage of the big and LITTLE CPU cores in order to provide 'butter smooth' performance.
State Helper: A hotplug driver by @neobuddy89 designed with the Nexus 6 in mind. It is highly configurable giving the user control over what CPUs to online based on what battery threshold levels have been set. Another feature that sets state helper apart from other hotplug methods is that it respects the thermal driver.
ZZmoove native hotplug: The hotplugging logic found in the ZZmoove governor. This isn't a standalone hotplug driver that can be used with other governors, the hotplugging is done by the governor which was common on older devices like the Samsung Galaxy S3. Native hotplugging may offer better stability and the governor should perform better in battery life and performance (your experience may vary) because it was designed for this specific governor.
Custom kernels may have their own hotplugging drivers but they are usually based on these ones.
Battery life:
mpdecision
Mako Hotplug
Intelliplug
Alucard
For performance:
mpdecision
For balanced:
Bricked Hotplug
Mako Hotplug
Intelliplug
mpdecision
GPU governors
-----------------------
Simple: An open-source alternative to Qualcomm's closed-sourced governors. Developed by Faux123, it is highly customisable which will allow more fine-grained control over how the GPU scales up and down.
simple_ondemand: As the name implies, it is a simpler version of the CPU governor ondemand. simple_ondemand will ramp up the frequency when a load is detected. It has a good balance between performance and battery savings.
msm-adreno-tz: The default GPU governor used by Qualcomm for their adreno GPUs. It is based on the ondemand governor but is biased towards performance, therefore it should give better performance in games but less battery life.
Performance: As the name suggests, this keeps your GPU running at the max frequency. This is a governor if you want the best possible experience in games but you don't care about your battery life.
Powersave: Like the CPU governor, this keeps your GPU running at the lowest possible frequency. Best battery life, extreme lag in games.
Adreno Idler: It is an idling algorithm, an efficient workaround for msm-adreno-tz's overheads. Main goal is to lower the power consumptions while maintaining high-performance. Since msm-adreno-tz tends to *not* use the lowest frequency even on idle, Adreno idler replaces msm-adreno-tz's algorithm when it comes to calculating idle frequency(mostly by ondemand's method). The higher frequencies are not touched with this algorithm, so high-demanding games will (most likely) not suffer from worsened performance.
Userspace: This governor basically allows the user is able to set a desired frequency for the GPU to run at.
cpubw_hwmon: A hardware monitor based governor that attempts to determine bandwidth (BW) needed by CPU and other hardware. Because it samples bandwidth using polling intervals, it has been made to be biased towards performance to compensate for the possible slower response times during heavy loads.
MSM Cpufreq: The MSM CPUfreq governor determines the CPU to DDR bandwidth vote based on the current CPU frequency of all the active CPUs. In other words, this governor scales based on CPU usage which could mean more performance.
Governor types:
----------------------
All governors are coded to behave on certain principles which can affect the performance, battery life, stability of your device. I won't be updating this guide often because there is simply too many governors.
1) Ondemand Based:
Works on "ramp-up on high load" principle. CPU busy-time is taken into consideration for scaling decisions. Members: Ondemand, OndemandX, Intellidemand, Lazy, Lagfree, PegasusQ, HYPER, Wheatley, Hotplug, HotplugX, AbyssPlug, AbyssPlugv2, Nightmare, Sleepy.
2) Conservative Based:
Works by biasing the phone to prefer the lowest possible clockspeed as often as possible. Members: Conservative, Lionheart, LionheartX
3) Interactive Based:
Works on "make scaling decision when CPU comes out of idle-loop" principle. Members: Interactive, InteractiveX, Intelliactive, Lulzactive, Luzactiveq, Smartass, SmartassV2, SmartassH3, Brazilianwax, SavagedZen, Dyninteractive, Interactive Pro
4) Unique Category:
These do not fall into any other category above and/or possess unique attributes. Members: Userspace, Powersave, Performance, Min Max, ZZmove, MSM DCVS, IntelliMM
5) Hybrid Category:
These have a mix of two (or more) CPU governor behaviors. Members: Smartmax, Dancedance, Performance May Cry(PMC), Ktoonservative, KtoonservativeQ
Recommendations:
-----------------------------
For performance:
Interactive/InteractiveX
Intelliactive
Performance
ElementalX
HYPER
Lionheart/LionheartX
Blu_active
For battery life:
Ondemand
Conservative
Perfomance may cry (PMC)
Powersave
Smartmax
Intellimm
Alucard
For balanced battery life and performance:
Interactive/InteractiveX
Intelliactive
Ondemand/Ondemand
ElementalX
Yankactive/YanksusQ
PegasusQ
HYPER
Impulse
ZZMoove
For gaming:
Interactive/InteractiveX
Intelliactive
Performance
Lionheart/LionheartX
PegasusQ
ElementalX
Ondemand/OndemandX
HYPER
Individual-core CPU governor selection
Some kernels will allow you to set a governor on a per-core basis. This can introduce a wider range of configurations which can alter the scaling of specific part of the CPU. While there is no definite guidelines on how to achieve optimal settings, here are some configurations you can do:
All cores running the same governor:
This will give the best stability and the CPU will behave as expected. This is the stock default on all devices.
All cores running different governors:
You should probably avoid this because it can cause stabilities and can significantly affect the performance and battery life of your CPU. Most kernel developers may not even provide support because there are too many combinations to choose from and because of the risks associated with this setup.
big.LITTLE cores running two different governors:
Similar to the previous setup, this could cause instabilities on your device and could affect how well your CPU performs. It is better just to use the same governor across all cores but there have been some setups like this.
CPU governor tunables
--------------------------------
NOTE: If you don't have some of these tunables, you might have an older version of the governor/hotplug driver and/or the kernel maintainer has made modifications to it.
1. ONDEMAND
[ PARAMETERS ]
Quote:
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 - defines what the average CPU usage between the samplings of 'sampling_rate' needs to be for the kernel to make a decision on whether it should increase the frequency. For example when it is set to its default value of '95' it means that between the checking intervals the CPU needs to be on average more than 95% in use to then
decide that the CPU frequency needs to be increased.
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 - 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. T
v) down_differential - Indirectly calculates 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).
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.
vii) ignore_nice_load - this parameter takes a value of '0' or '1'. When set to '0' (its default), all processes are counted towards the 'cpu utilisation' value. When set to '1', the processes that are run with a 'nice' value will not count (and thus be ignored) in the overall usage calculation. This is useful if you are running a CPU intensive calculation on your laptop that you do not care how long it takes to complete as you can 'nice' it and prevent it from taking part in the deciding process of whether to increase your CPU frequency.
viii) sampling_rate_min -
The sampling rate is limited by the HW transition latency:
transition_latency * 100
Or by kernel restrictions:
If CONFIG_NO_HZ is set, the limit is 10ms fixed.
If CONFIG_NO_HZ is not set or nohz=off boot parameter is used, the
limits depend on the CONFIG_HZ option:
HZ=1000: min=20000us (20ms)
HZ=250: min=80000us (80ms)
HZ=100: min=200000us (200ms)
The highest value of kernel and HW latency restrictions is shown and
used as the minimum sampling rate.
2. LULZACTIVE/LULZACTIVEQ
1. Initial Version:-
[ PARAMETERS ]
Quote:
i) down_sampling_time - Sampling time to scale cpu down.
ii) up_sampling_time - Sampling time to scale cpu up.
2. Second Version (LulzactiveQ):-
[ PARAMETERS ]
Quote:
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)
3. SMARTASSV2
[ PARAMETERS ]
Quote:
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 ]
Quote:
Ondemand and conservative have some tunables in common, but with a few extras:
i) freq_step - this describes what percentage steps the cpu freq should be increased and decreased smoothly by. By default the cpu frequency will increase in 5% chunks of your maximum cpu frequency. You can change this value to anywhere between 0 and 100 where '0' will effectively lock your CPU at a speed regardless of its load whilst '100' will, in theory, make
it behave identically to the "ondemand" governor.
ii) down_threshold - same as the 'up_threshold' found for the "ondemand" governor but for the opposite direction. For example when set to its default value of '20' it means that if the CPU usage needs to be below 20% between samples to have the frequency decreased.
5. INTERACTIVE
1. Generic Version
[ PARAMETERS ]
Quote:
i) hispeed_freq - 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 the maximum speed allowed by the policy at governor initialization time.
ii) go_hispeed_load - The CPU load at which to ramp to hispeed_freq. Default is 99%.
iii) min_sample_time - The minimum amount of time to spend at the current frequency before ramping down. Default is 80000 uS.
iv) timer_rate - Sample rate for reevaluating CPU load when the CPU is not idle. A deferrable timer is used, such that the CPU will not be woken from idle to service this timer until something else needs to run. (The maximum time to allow deferring this timer when not running at
minimum speed is configurable via timer_slack.) Default is 20000 uS.
v) target_loads - CPU load values used to adjust speed to influence the current CPU load toward that value. In general, the lower the target load, the more often the governor will raise CPU speeds to bring load below the target. The format is a single target load, optionally followed by pairs of CPU speeds and CPU loads to target at or above those speeds. Colons can be used between the speeds and associated target loads for readability. For example:
85 1000000:90 1700000:99
targets CPU load 85% below speed 1GHz, 90% at or above 1GHz, until 1.7GHz and above, at which load 99% is targeted. If speeds are specified these must appear in ascending order. Higher target load values are typically specified for higher speeds, that is, target load values also usually appear in an ascending order. The default is target load 90% for all speeds.
vi) above_highspeed_delay - When speed is at or above hispeed_freq, wait for this long before raising speed in response to continued high load. The format is a single delay value, optionally followed by pairs of CPU speeds and the delay to use at or above those speeds. Colons can be used between the speeds and associated delays for readability. For example:
80000 1300000:200000 1500000:40000
uses delay 80000 uS until CPU speed 1.3 GHz, at which speed delay 200000 uS is used until speed 1.5 GHz, at which speed (and above) delay 40000 uS is used. If speeds are specified these must appear in ascending order. Default is 20000 uS.
vii) timer_slack - Maximum additional time to defer handling the governor sampling timer beyond timer_rate when running at speeds above the minimum. For platforms that consume additional power at idle when CPUs are running at speeds greater than minimum, this places an upper bound on how long the timer will be deferred prior to re-evaluating load and dropping speed. For example, if timer_rate is 20000uS and timer_slack is 10000uS then timers will be deferred for up to 30msec when not at lowest speed. A value of -1 means defer timers
indefinitely at all speeds. Default is 80000 uS.
viii) boost - If non-zero, immediately boost speed of all CPUs to at least hispeed_freq until zero is written to this attribute. If zero, allow CPU speeds to drop below hispeed_freq according to load as usual. Default is zero.
ix) boostpulse - On each write, immediately boost speed of all CPUs to hispeed_freq for at least the period of time specified by boostpulse_duration, after which speeds are allowed to drop below hispeed_freq according to load as usual.
x) boostpulse_duration - Length of time to hold CPU speed at hispeed_freq on a write to boostpulse, before allowing speed to drop according to load as usual. Default is 80000 uS.
2. Qualcomm Version/Intelliactive/IntelliMM
[ PARAMETERS ]
Quote:
Has some tunables in common with the generic version but with a few extras:
i) Sync_freq Feature - This feature will cause a CPU frequency to stay above a particular
value sync_freq) if certain conditions (determined by the two nodes
up_threshold_any_cpu_freq and up_threshold_any_cpu_load) are satisfied
ii) Sync_freq - Only when both of the above conditions are satisfied will the CPU not drop
below this frequency value. The higher this value, the higher the frequency to jump will
be when the above conditions are satisfied.
iii) Up_threshold_any_cpu_freq - If the maximum frequency across all the CPUs is higher
than or equal to this frequency value, do not let the current CPU fall below sync_freq.
The higher this value, the fewer the chances to go to sync_freq.
iv) Up_threshold_any_cpu_load - If the maximum load across all the CPUs is higher than
or equal to this load value, do not let the current CPU fall below sync_freq. The higher
this value, the fewer the chances to go to sync_freq.
v) up_threshold_multi_core - When the up_threshold_multi_core is crossed, the cpu is ramped up to optimal_freq.
vi) optimal_freq - When more than one CPU is online and if up_threshold_multi_core has exceeded, the governor will ramp up the CPU to this frequency. This value should be less than your device's max CPU frequency.
6. Wheatley
[ PARAMETERS ]
Quote:
target_residency - The minimum average residency in µs which is considered acceptable for a proper efficient usage of the C4 state. Default is 10000 = 10ms.
allowed_misses - The number sampling intervals in a row the average residency is allowed to be lower than target_residency before the governor reduces the frequency. This ensures that the governor is not too aggressive in scaling down the frequency and reduces it just because some background process was temporarily causing a larger number of wakeups. The default is 5.
7. Darkness/Nightmare
[ PARAMETERS ]
Quote:
cpu_up_rate - No of samples to evaluate load to scale CPU frequency up. Increasing this value will increase the time spent on a frequency.
cpu_down_rate - No of samples to evaluate load to scale CPU frequency down. Increasing this value will increase the time spent on a frequency
inc_cpu_load_at_min_freq - This threshold is used as up threshold while sampling at frequencies is less than freq_for_responsiveness.
inc_cpu_load - The frequency at which governor scales CPU up.
dec_cpu_load - The frequency at which governor scales CPU down.
Guide Part 1 Link: http://forum.xda-developers.com/lenovo-a6000/how-to/cpu-governors-hotplug-drivers-gpu-t3528762
Guide Part 2 Link: http://forum.xda-developers.com/lenovo-a6000/how-to/cpu-governors-hotplug-drivers-gpu-t3528766
Guide Part 4 Link : http://forum.xda-developers.com/lenovo-a6000/how-to/cpu-governors-hotplug-drivers-gpu-t3528772
Please Press Thanks Button If It Helped . It Will Encourage Me to Work More For You Guys
THANK YOU:good:
CPU Governors, Hotplug drivers and GPU governors Explained Part 3 (Updated 30/12/16)
--------------------------------------------------------------------------------------------------------------------------------------------
Official XDA thread Of The Contributer: http://forum.xda-developers.com/member.php?u=5811506
Edited By ShivaY: http://forum.xda-developers.com/member.php?u=6704044
Guide Part 1 Link: http://forum.xda-developers.com/lenovo-a6000/how-to/cpu-governors-hotplug-drivers-gpu-t3528762
Guide Part 2 Link: http://forum.xda-developers.com/lenovo-a6000/how-to/cpu-governors-hotplug-drivers-gpu-t3528766
Guide Part 4 Link : http://forum.xda-developers.com/lenovo-a6000/how-to/cpu-governors-hotplug-drivers-gpu-t3528772
Here I've gathered some info for newcomers to the Android world.I've tried to keep it relatively simple. So if you want more info Comment Below
Recommended apps for manipulating kernel values:
1. Kernel Adiutor (Free to change governor and tune variables)
2. Kernel Adiutor-Mod (Free to change governor and tune variables)
3. Compatible kernel managers (e.g Stweaks, Synapse, UKM, etc.)
Hotplug drivers:
------------------------
mpdecision: Qualcomm's default hotplugging driver. One of the most widely used hotplug drivers in all android devices.
msm_hotplug: Great battery life, a custom qualcomm based hotplugging driver by myflux. It is a popular choice for many users.
intelliplug: Great balance between battery life and performance. It is also a popular hotplug driver from faux123.
Alucard: A great hotplugging driver by Alucard. It is known to be very battery friendly on devices.
Kt Auto Hotplug: A great hotplug driver by Ktoonsez. Pretty much a smarter mpdecision that has been optimized for quad-core devices.
Mako Hotplug: A new popular hotplugging driver found in Francokernel. This is a highly configurable driver that can be configured to use dual core for light-loads and quad-core for heavy loads.
Zen Decision: ZEN only onlines all cores when screen is on, it also takes thermal events into account and wont online any core back, if you're under 15% battery, or currently have a thermal event because of heat. So in the end it isn't a "real" hotplug driver, because it doesnt have any code for active hot plugging in it. That means you can't change its behavior.
Bricked Hotplug: Conservative hotplug driver by @showp1984. It is based on mpdecision but has been optimized for better balance between battery life and performance.
msm_sleeper: The main feature with this hotplug is that you can customize the screen off frequency. Two cores are always on, the third and fourth are independent and come online if needed. By default, if the load is over 80 for 400ms another core comes online. The third and/or fourth cores stay online as long as the load demands it or for a minimum of one second. While the screen is off, it goes down to a single core. Created by flar2.
Autosmp: A highly-efficient hotplug driver by @mrg666, works in-sync with the CPU governor to enable off-line cpu cores when the the CPU frequency reaches a high threshold and still more compute power is needed. Therefore, touch boost bloat is removed.
Thunderplug: A matured load-based hotplug driver with many tunables written from ground up by varun.chitre15. This hotplug is optimized for octa-core devices and also has support for 64bit CPUs.
Blu_plug: Dynamic hotplug from eng.stk's shamu kernel with screenoff battery saving.
cpuquiet: A hotplug driver by NVidia and ported to Snapdragon by maxwen. Originally made for NVidia tegra SOCs. It has a set of governors which keep the CPU running at optimal frequencies for battery and performance.
Fast hotplug: A hotplug driver from pec0ra's abricot kernel. It aims to be as lightweight as possible while also being highly customizable. However, it is still a WIP as it is known to have some stability issues.
Hima hotplug: An optimized hotplug driver based on intelliplug for big.LITTLE architecture. Found on chadouming's HTC One (M9) kernel, it takes advantage of the big and LITTLE CPU cores in order to provide 'butter smooth' performance.
State Helper: A hotplug driver by @neobuddy89 designed with the Nexus 6 in mind. It is highly configurable giving the user control over what CPUs to online based on what battery threshold levels have been set. Another feature that sets state helper apart from other hotplug methods is that it respects the thermal driver.
ZZmoove native hotplug: The hotplugging logic found in the ZZmoove governor. This isn't a standalone hotplug driver that can be used with other governors, the hotplugging is done by the governor which was common on older devices like the Samsung Galaxy S3. Native hotplugging may offer better stability and the governor should perform better in battery life and performance (your experience may vary) because it was designed for this specific governor.
Custom kernels may have their own hotplugging drivers but they are usually based on these ones.
Battery life:
mpdecision
Mako Hotplug
Intelliplug
Alucard
For performance:
mpdecision
For balanced:
Bricked Hotplug
Mako Hotplug
Intelliplug
mpdecision
GPU governors
-----------------------
Simple: An open-source alternative to Qualcomm's closed-sourced governors. Developed by Faux123, it is highly customisable which will allow more fine-grained control over how the GPU scales up and down.
simple_ondemand: As the name implies, it is a simpler version of the CPU governor ondemand. simple_ondemand will ramp up the frequency when a load is detected. It has a good balance between performance and battery savings.
msm-adreno-tz: The default GPU governor used by Qualcomm for their adreno GPUs. It is based on the ondemand governor but is biased towards performance, therefore it should give better performance in games but less battery life.
Performance: As the name suggests, this keeps your GPU running at the max frequency. This is a governor if you want the best possible experience in games but you don't care about your battery life.
Powersave: Like the CPU governor, this keeps your GPU running at the lowest possible frequency. Best battery life, extreme lag in games.
Adreno Idler: It is an idling algorithm, an efficient workaround for msm-adreno-tz's overheads. Main goal is to lower the power consumptions while maintaining high-performance. Since msm-adreno-tz tends to *not* use the lowest frequency even on idle, Adreno idler replaces msm-adreno-tz's algorithm when it comes to calculating idle frequency(mostly by ondemand's method). The higher frequencies are not touched with this algorithm, so high-demanding games will (most likely) not suffer from worsened performance.
Userspace: This governor basically allows the user is able to set a desired frequency for the GPU to run at.
cpubw_hwmon: A hardware monitor based governor that attempts to determine bandwidth (BW) needed by CPU and other hardware. Because it samples bandwidth using polling intervals, it has been made to be biased towards performance to compensate for the possible slower response times during heavy loads.
MSM Cpufreq: The MSM CPUfreq governor determines the CPU to DDR bandwidth vote based on the current CPU frequency of all the active CPUs. In other words, this governor scales based on CPU usage which could mean more performance.
Governor types:
----------------------
All governors are coded to behave on certain principles which can affect the performance, battery life, stability of your device. I won't be updating this guide often because there is simply too many governors.
1) Ondemand Based:
Works on "ramp-up on high load" principle. CPU busy-time is taken into consideration for scaling decisions. Members: Ondemand, OndemandX, Intellidemand, Lazy, Lagfree, PegasusQ, HYPER, Wheatley, Hotplug, HotplugX, AbyssPlug, AbyssPlugv2, Nightmare, Sleepy.
2) Conservative Based:
Works by biasing the phone to prefer the lowest possible clockspeed as often as possible. Members: Conservative, Lionheart, LionheartX
3) Interactive Based:
Works on "make scaling decision when CPU comes out of idle-loop" principle. Members: Interactive, InteractiveX, Intelliactive, Lulzactive, Luzactiveq, Smartass, SmartassV2, SmartassH3, Brazilianwax, SavagedZen, Dyninteractive, Interactive Pro
4) Unique Category:
These do not fall into any other category above and/or possess unique attributes. Members: Userspace, Powersave, Performance, Min Max, ZZmove, MSM DCVS, IntelliMM
5) Hybrid Category:
These have a mix of two (or more) CPU governor behaviors. Members: Smartmax, Dancedance, Performance May Cry(PMC), Ktoonservative, KtoonservativeQ
Recommendations:
-----------------------------
For performance:
Interactive/InteractiveX
Intelliactive
Performance
ElementalX
HYPER
Lionheart/LionheartX
Blu_active
For battery life:
Ondemand
Conservative
Perfomance may cry (PMC)
Powersave
Smartmax
Intellimm
Alucard
For balanced battery life and performance:
Interactive/InteractiveX
Intelliactive
Ondemand/Ondemand
ElementalX
Yankactive/YanksusQ
PegasusQ
HYPER
Impulse
ZZMoove
For gaming:
Interactive/InteractiveX
Intelliactive
Performance
Lionheart/LionheartX
PegasusQ
ElementalX
Ondemand/OndemandX
HYPER
Individual-core CPU governor selection
Some kernels will allow you to set a governor on a per-core basis. This can introduce a wider range of configurations which can alter the scaling of specific part of the CPU. While there is no definite guidelines on how to achieve optimal settings, here are some configurations you can do:
All cores running the same governor:
This will give the best stability and the CPU will behave as expected. This is the stock default on all devices.
All cores running different governors:
You should probably avoid this because it can cause stabilities and can significantly affect the performance and battery life of your CPU. Most kernel developers may not even provide support because there are too many combinations to choose from and because of the risks associated with this setup.
big.LITTLE cores running two different governors:
Similar to the previous setup, this could cause instabilities on your device and could affect how well your CPU performs. It is better just to use the same governor across all cores but there have been some setups like this.
CPU governor tunables
--------------------------------
NOTE: If you don't have some of these tunables, you might have an older version of the governor/hotplug driver and/or the kernel maintainer has made modifications to it.
1. ONDEMAND
[ PARAMETERS ]
Quote:
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 - defines what the average CPU usage between the samplings of 'sampling_rate' needs to be for the kernel to make a decision on whether it should increase the frequency. For example when it is set to its default value of '95' it means that between the checking intervals the CPU needs to be on average more than 95% in use to then
decide that the CPU frequency needs to be increased.
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 - 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. T
v) down_differential - Indirectly calculates 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).
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.
vii) ignore_nice_load - this parameter takes a value of '0' or '1'. When set to '0' (its default), all processes are counted towards the 'cpu utilisation' value. When set to '1', the processes that are run with a 'nice' value will not count (and thus be ignored) in the overall usage calculation. This is useful if you are running a CPU intensive calculation on your laptop that you do not care how long it takes to complete as you can 'nice' it and prevent it from taking part in the deciding process of whether to increase your CPU frequency.
viii) sampling_rate_min -
The sampling rate is limited by the HW transition latency:
transition_latency * 100
Or by kernel restrictions:
If CONFIG_NO_HZ is set, the limit is 10ms fixed.
If CONFIG_NO_HZ is not set or nohz=off boot parameter is used, the
limits depend on the CONFIG_HZ option:
HZ=1000: min=20000us (20ms)
HZ=250: min=80000us (80ms)
HZ=100: min=200000us (200ms)
The highest value of kernel and HW latency restrictions is shown and
used as the minimum sampling rate.
2. LULZACTIVE/LULZACTIVEQ
1. Initial Version:-
[ PARAMETERS ]
Quote:
i) down_sampling_time - Sampling time to scale cpu down.
ii) up_sampling_time - Sampling time to scale cpu up.
2. Second Version (LulzactiveQ):-
[ PARAMETERS ]
Quote:
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)
3. SMARTASSV2
[ PARAMETERS ]
Quote:
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 ]
Quote:
Ondemand and conservative have some tunables in common, but with a few extras:
i) freq_step - this describes what percentage steps the cpu freq should be increased and decreased smoothly by. By default the cpu frequency will increase in 5% chunks of your maximum cpu frequency. You can change this value to anywhere between 0 and 100 where '0' will effectively lock your CPU at a speed regardless of its load whilst '100' will, in theory, make
it behave identically to the "ondemand" governor.
ii) down_threshold - same as the 'up_threshold' found for the "ondemand" governor but for the opposite direction. For example when set to its default value of '20' it means that if the CPU usage needs to be below 20% between samples to have the frequency decreased.
5. INTERACTIVE
1. Generic Version
[ PARAMETERS ]
Quote:
i) hispeed_freq - 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 the maximum speed allowed by the policy at governor initialization time.
ii) go_hispeed_load - The CPU load at which to ramp to hispeed_freq. Default is 99%.
iii) min_sample_time - The minimum amount of time to spend at the current frequency before ramping down. Default is 80000 uS.
iv) timer_rate - Sample rate for reevaluating CPU load when the CPU is not idle. A deferrable timer is used, such that the CPU will not be woken from idle to service this timer until something else needs to run. (The maximum time to allow deferring this timer when not running at
minimum speed is configurable via timer_slack.) Default is 20000 uS.
v) target_loads - CPU load values used to adjust speed to influence the current CPU load toward that value. In general, the lower the target load, the more often the governor will raise CPU speeds to bring load below the target. The format is a single target load, optionally followed by pairs of CPU speeds and CPU loads to target at or above those speeds. Colons can be used between the speeds and associated target loads for readability. For example:
85 1000000:90 1700000:99
targets CPU load 85% below speed 1GHz, 90% at or above 1GHz, until 1.7GHz and above, at which load 99% is targeted. If speeds are specified these must appear in ascending order. Higher target load values are typically specified for higher speeds, that is, target load values also usually appear in an ascending order. The default is target load 90% for all speeds.
vi) above_highspeed_delay - When speed is at or above hispeed_freq, wait for this long before raising speed in response to continued high load. The format is a single delay value, optionally followed by pairs of CPU speeds and the delay to use at or above those speeds. Colons can be used between the speeds and associated delays for readability. For example:
80000 1300000:200000 1500000:40000
uses delay 80000 uS until CPU speed 1.3 GHz, at which speed delay 200000 uS is used until speed 1.5 GHz, at which speed (and above) delay 40000 uS is used. If speeds are specified these must appear in ascending order. Default is 20000 uS.
vii) timer_slack - Maximum additional time to defer handling the governor sampling timer beyond timer_rate when running at speeds above the minimum. For platforms that consume additional power at idle when CPUs are running at speeds greater than minimum, this places an upper bound on how long the timer will be deferred prior to re-evaluating load and dropping speed. For example, if timer_rate is 20000uS and timer_slack is 10000uS then timers will be deferred for up to 30msec when not at lowest speed. A value of -1 means defer timers
indefinitely at all speeds. Default is 80000 uS.
viii) boost - If non-zero, immediately boost speed of all CPUs to at least hispeed_freq until zero is written to this attribute. If zero, allow CPU speeds to drop below hispeed_freq according to load as usual. Default is zero.
ix) boostpulse - On each write, immediately boost speed of all CPUs to hispeed_freq for at least the period of time specified by boostpulse_duration, after which speeds are allowed to drop below hispeed_freq according to load as usual.
x) boostpulse_duration - Length of time to hold CPU speed at hispeed_freq on a write to boostpulse, before allowing speed to drop according to load as usual. Default is 80000 uS.
2. Qualcomm Version/Intelliactive/IntelliMM
[ PARAMETERS ]
Quote:
Has some tunables in common with the generic version but with a few extras:
i) Sync_freq Feature - This feature will cause a CPU frequency to stay above a particular
value sync_freq) if certain conditions (determined by the two nodes
up_threshold_any_cpu_freq and up_threshold_any_cpu_load) are satisfied
ii) Sync_freq - Only when both of the above conditions are satisfied will the CPU not drop
below this frequency value. The higher this value, the higher the frequency to jump will
be when the above conditions are satisfied.
iii) Up_threshold_any_cpu_freq - If the maximum frequency across all the CPUs is higher
than or equal to this frequency value, do not let the current CPU fall below sync_freq.
The higher this value, the fewer the chances to go to sync_freq.
iv) Up_threshold_any_cpu_load - If the maximum load across all the CPUs is higher than
or equal to this load value, do not let the current CPU fall below sync_freq. The higher
this value, the fewer the chances to go to sync_freq.
v) up_threshold_multi_core - When the up_threshold_multi_core is crossed, the cpu is ramped up to optimal_freq.
vi) optimal_freq - When more than one CPU is online and if up_threshold_multi_core has exceeded, the governor will ramp up the CPU to this frequency. This value should be less than your device's max CPU frequency.
6. Wheatley
[ PARAMETERS ]
Quote:
target_residency - The minimum average residency in �s which is considered acceptable for a proper efficient usage of the C4 state. Default is 10000 = 10ms.
allowed_misses - The number sampling intervals in a row the average residency is allowed to be lower than target_residency before the governor reduces the frequency. This ensures that the governor is not too aggressive in scaling down the frequency and reduces it just because some background process was temporarily causing a larger number of wakeups. The default is 5.
7. Darkness/Nightmare
[ PARAMETERS ]
Quote:
cpu_up_rate - No of samples to evaluate load to scale CPU frequency up. Increasing this value will increase the time spent on a frequency.
cpu_down_rate - No of samples to evaluate load to scale CPU frequency down. Increasing this value will increase the time spent on a frequency
inc_cpu_load_at_min_freq - This threshold is used as up threshold while sampling at frequencies is less than freq_for_responsiveness.
inc_cpu_load - The frequency at which governor scales CPU up.
dec_cpu_load - The frequency at which governor scales CPU down.
Guide Part 1 Link: http://forum.xda-developers.com/lenovo-a6000/how-to/cpu-governors-hotplug-drivers-gpu-t3528762
Guide Part 2 Link: http://forum.xda-developers.com/lenovo-a6000/how-to/cpu-governors-hotplug-drivers-gpu-t3528766
Guide Part 4 Link : http://forum.xda-developers.com/lenovo-a6000/how-to/cpu-governors-hotplug-drivers-gpu-t3528772
Please Press Thanks Button If It Helped . It Will Encourage Me to Work More For You Guys
THANK YOU:good:
Hi, how to set default GPU governor in device config file?
Hi there. So I have used my mido for two years now and experimented with a lot of things to achieve optimal performance and speed, balance. However as much as I wanted to know moré about GPU governors the guides online are way too superficial. Not to mention most of them are outdated.
Could somebody, like anyone who knows a bit about them help me understand their differences and uses?
These are the most common governors that are almost always present in custom kernels:
spdm_bw_hyp
bw_hwmon
venus-ddr-gov
msm-vidc-vmem
msm-vidc-vmem+
msm-vidc-ddr
bw_vbif
gpubw_mon
msm_adreno_tz
cpufreq
userspace
simple_ondemand
powersave
performance
Msm_adreno_tz, cpufreq, cpufreq, userspace, simple_ondemand, powersave and performance are the ones that I could figure out myself. The others are mostly a mistery to me and can't seem to find detailed info on them. I'd appreciate any help. Thanks.
Im looking for the same info.
Saber said:
Collective guide of CPU governors, I/O schedulers and other kernel variables
I present to you a wonderful collection of descriptions, comparisons and graphs of common kernel variables. Before continuing on the wonderful journey of Linux kernel tuning, please note that I am not responsible for any damage to your device or malfunction. You are in complete control over your device so please do not blindly follow without proper research. While you could use this guide to tune other devices other than a smartphone, I would recommend against doing so.
Guides:
Governors - Part 1: Post 1Governors - Part 2: Post 2I/O Schedulers: Post 3CPU Governor Tuning Guide: Post 4I/O Scheduler Tuning Guide: Post 5Hotplug Driver Tuning Guide: Post 6TCP Algorithms: Post 7Other Important Information: Post 8
What is a CPU governor?
A CPU governor in Android controls how the CPU raises and lowers its frequency in response to the demands the user is placing on their device. Governors are especially important in smartphones and tablets because they have a large impact on the apparent fluidity of the interface and the battery life of the device over a charge.
NOTE: You cannot change your CPU governor unless your phone is rooted and you have a ROM or app that lets you make a change. Also, different kernels (the intermediary software between your phone's hardware and the operating system) offer different sets of governors.
Available CPU governors:
OnDemand
OnDemandX
Performance
Powersave
Conservative
Userspace
Min Max
Interactive
InteractiveX
Smartass
SmartassV2
Scary
Lagfree
Smoothass
Brazilianwax
SavageZen
Lazy
Lionheart
LionheartX
Intellidemand
Hotplug
Badass
Wheatley
Lulzactive
PegasusQ\PegasusD
HotplugX
Abyssplug
MSM DCVS
Intelliactive
Adaptive
Nightmare
ZZmove
Sleepy
Hyper
SmartassH3
SLP
NeoX
ZZmanX
OndemandPlus
Dynamic Interactive (DynInteractive)
Smartmax
Ktoonservative\KtoonservativeQ
Performance may cry (PMC)
Dance Dance
AbyssPlugv2
IntelliMM
InteractivePro
Slim
Ondemand EPS
Smartmax EPS
Uberdemand
Yankactive
Impulse
Bacon
Optimax
Preservative
Touchdemand
ElementalX
Bioshock
Blu_active
Umbrella_core
ConservativeX
Hyrdxq
DevilQ
Yankasusq
Darkness
Alucard
Hellsactive
Ragingmolasses
Virtuous
Sakuractive
InteractiveX v2
Alessa
GallimaufryX
AggressiveX
Tripndroid
Wrexy
Xperience
Stockdemand
Zeneractive
InteractiveB
Aggressive
IntellidemandV2
Boostactive
Wave
Barry-Allen
Arteractive
Precognition (PrecoGOV)
Mythx_plug
PegasusQPlus
Yankdemand
HyperX
Despair
Electroactive
Electrodemand
Lionfish
Interextrem
Cafactive
Lightning
ThunderX
sched-DVFS
Intel
Frankenstein
Cyan
TheSSJactive
Chill
sprdemand
Kraken
Ironactive
Nebula
Relaxed
Crazyactive
thenewbeginning
Cultivation
Schedutil
pwrutilx
blu_schedutil
Descriptions:
HMP Governors
1: OnDemand:
Description:
Ondemand is one of the original and oldest governors available on the linux kernel. When the load placed on your CPU reaches the set threshold, the governor will quickly ramp up to the maximum CPU frequency. It has excellent fluidity because of this high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand was commonly chosen by smartphone manufacturers in the past because it is well-tested and reliable, but it is outdated now and is being replaced by Google's Interactive governor.
2: OndemandX:
Description:
Basically an ondemand with suspend/wake profiles. No further optimization was done to Ondemand to keep it close to source as possible.
3: Performance:
Description:
The performance governor locks the phone's CPU at maximum frequency.
4: Powersave:
Description:
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
5: Conservative:
Description:
This governor biases the phone to prefer the lowest possible clockspeed as often as possible. In other words, a larger and more persistent load must be placed on the CPU before the conservative governor will be prompted to raise the CPU clockspeed. Depending on how the developer has implemented this governor, and the minimum clockspeed chosen by the user, the conservative governor can introduce choppy performance. On the other hand, it can be good for battery life.
The Conservative Governor is also frequently described as a "slow OnDemand". The original and unmodified conservative is slow and inefficient. Newer and modified versions of conservative (from some kernels) are much more responsive and are better all around for almost any use.
6: Userspace:
Description:
This governor, exceptionally rare for the world of mobile devices, allows any program executed by the user to set the CPU's operating frequency. This governor is more common amongst servers or desktop PCs where an application (like a power profile app) needs privileges to set the CPU clockspeed.
7: Min Max
Description:
Min Max is a governor that makes use of only min & maximum frequency based on workload... no intermediate frequencies are used!
8: Interactive:
Description:
Interactive scales the clockspeed over the course of a timer set by the kernel developer (or user). In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. It is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.
Interactive is the default governor of choice for today's smartphone and tablet manufacturers.
9: InteractiveX:
Description:
Created by kernel developer "Imoseyon," the InteractiveX governor is based heavily on the Interactive governor, enhanced with tuned timer parameters to better balance battery vs. performance. The InteractiveX governor's defining feature, however, is that it locks the CPU frequency to the user's lowest defined speed when the screen is off.
10: Smartass
Description:
Based on interactive, performance is on par with the “old” minmax and smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
Smartass will also cap the max frequency when sleeping to 352Mhz (or if your min frequency is higher than 352 it will cap it to your min frequency).
This governor will slowly ramp down frequency when the screen is off and it could also let the frequency go to low making your phone unusable (if min frequency is not checked).
11: SmartassV2:
Description:
Version 2 of the original smartass governor from Erasmux. The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq when screen is on. There's no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery.
12: Scary
Description:
A new governor wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to whatever the kernel developer sets it too and will still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance.
13: Lagfree:
Description:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.
14: Smoothass:
Description:
The same as the Smartass “governor” But MUCH more aggressive & across the board.
15: Brazilianwax:
Description:
Similar to smartassV2. More aggressive ramping, so more performance, less battery
16: SavagedZen:
Description:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
17: Lazy:
Description:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.
18: Lionheart:
Description:
Lionheart is a conservative-based governor which is based on samsung's update3 source.
The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
19: LionheartX
Description:
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
20: Intellidemand:
Description:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode.
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) by behaving like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off. Faux no longer recommends intellidemand and believes that intellidemand users should switch to intelliactive for better optimizations and performance.
21: Hotplug:
Description:
The Hotplug governor performs very similarly to the OnDemand governor, with the added benefit of being more precise about how it steps down through the kernel's frequency table as the governor measures the user's CPU load. However, the Hotplug governor's defining feature is its ability to turn unused CPU cores off during periods of low CPU utilization. This is known as "hotplugging."
22: BadAss:
Description:
Badass removes all of this "fast peaking" to the max frequency. To trigger a frequency increase, the system must run a bit with high load, then the frequency is bumped. If that is still not enough the governor gives you full throttle. (this transition should not take longer than 1-2 seconds, depending on the load your system is experiencing)
Badass will also take the gpu load into consideration. If the gpu is moderately busy it will bypass the above check and clock the cpu to max frequency, If the gpu is crushed under load, badass will lift the restrictions to the cpu.
23: Wheatley:
Description:
Building on the classic 'ondemand' governor is implemented Wheatley governor. The governor has two additional parameters. Wheatley works as planned and does not hinder the proper C4 usage for task where the C4 can be used properly. So the results show that Wheatley works as intended and ensures that the C4 state is used whenever the task allows a proper efficient usage of the C4 state. For more demanding tasks which cause a large number of wakeups and prevent the efficient usage of the C4 state, the governor resorts to the next best power saving mechanism and scales down the frequency. So with the new highly-flexible Wheatley governor one can have the best of both worlds.
Wheatley is a more performance orientated governor as it scales more aggressively than ondemand and sticks with higher frequencies.
24:Lulzactive\LulzactiveQ:
Description:
It's based on Interactive & Smartass governors.
Old Version: When workload is greater than or equal to 60%, the governor scales up CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step. When screen is off, frequency is locked to global scaling minimum frequency.
New Version: Three more user configurable parameters: inc_cpu_load, pump_up_step, pump_down_step. Unlike older version, this one gives more control for the user. We can set the threshold at which governor decides to scale up/down. We can also set number of frequency steps to be skipped while polling up and down.
When workload greater than or equal to inc_cpu_load, governor scales CPU pump_up_step steps up. When workload is less than inc_cpu_load, governor scales CPU down pump_down_step steps down.
25: Pegasusq/Pegasusd
Description:
The Pegasus-q / d is a multi-core based on the Ondemand governor and governor with integrated hot-plugging. It is quite stable and has the same battery life as ondemand). Ongoing processes in the queue, we know that multiple processes can run simultaneously on. These processes are active in an array, which is a field called "Run Queue" queue that is ongoing, with their priority values arranged (priority will be used by the task scheduler, which then decides which process to run next).
To ensure that each process has its fair share of resources, each will run for a certain period and will eventually stop and then again placed in the queue until it is your turn again. If a program is terminated, so that others can run the program with the highest priority in the current queue is executed.
26: Hotplugx
Description:
It's a modified version of Hotplug and optimized for the suspension in off-screen
27: AbyssPlug
Description:
It's a Governor derived from hotplug, it works the same way, but with the changes in savings for more battery life.
28: MSM DCVS
Description:
A very efficient and wide range of Dynamic Clock and Voltage Scaling (DCVS) which addresses usage models from active standby to mid and high level processing requirements. It makes the phone's CPU smoothly scale from low power, from low leakage mode to blazingly fast performance.Only to be used by Qualcomm CPUs.
MSM is the prefix for the SOC (MSM8960) and DCVS is Dynamic Clock and Voltage Scaling. Makes sense, MSM-DCVS
29: IntelliActive
Description:
Based off Google's Interactive governor with the following enhancements:
1. self-boost capability from input drivers (no need for PowerHAL assist)
2. two phase scheduling (idle/busy phases to prevent from jumping directly to max freq
3. Checks for offline cpus and short circuits some unnecessary checks to improve code execution paths. Therefore, it avoids CPU hotplugging.
Created by Faux
30: Adaptive
Description:
This driver adds a dynamic cpufreq policy governor designed for latency-sensitive workloads and also for demanding performance.
This governor attempts to reduce the latency of clock so that the system is more responsive to interactive workloads in lowest steady-state but to reduce power consumption in middle operation level, level up will be done in step by step to prohibit system from going to
max operation level.
31:Nightmare
Description:
A PegasusQ modified, less aggressive and more stable. A good compromise between performance and battery. In addition to the SoD is a prevention because it usually does not hotplug.
32: ZZmoove
Description:
The ZZmoove Governor by ZaneZam is optimized for low power consumption when the screen off, with particular attention to the limitation of consumption applications in the background with the screen off, such as listening to music. The unique feature with ZZmoove is that it has predefined profiles and allows profile switching.
33: Sleepy
Description:
The Sleepy (formerly known as Solo) is an attempt to strike a balance between performance and battery power to create. It is based on Ondemand. It includes some tweaks like the Down_sampling variable and other features that set by the user through the sysfs of "echo" call. Sleepy is quite similar to Ondemandx.
34: Hyper
Description:
The Hyper (formerly known as kenobi) is an aggressive smart and smooth governor based on the Ondemand and is equipped with several features of Ondemandx suspend profiles. It also has the fast_start deep_sleep variable and detection features. In addition, the maximum frequency is in suspend mode 500Mhz or whatever the kernel developer sets it to. This is a more smoothness oriented governor which means that it is good for performance, without sacrificing much battery life.
35: SmartassH3
Description:
The SmartassH3 governor is designed for battery saving and not pushing the phones performance, since doing that drains battery and that's the one thing people keep asking for more of. Based on SmartassV2.
36: SLP
Description:
It is a mix of pegasusq and ondemand. Therefore, it has a balance between battery savings and performance.
37: NeoX
Description:
An optimized version of the pegasusq governor but with some extra tweaks for better performance. This means slightly more battery drainage than the original PegasusQ but it is still a balanced governor.
38. ZZmanx
Description:
ZZmanx is exactly the same as ZZmoove, but it has been renamed because DorimanX made it into his own version (possibly better performance) . However, it still suffers from below average gaming performance. (Refer to ZZmoove description for guide on profiles)
39. OnDemandPlus
Description:
Ondemandplus is an ondemand and interactive-based governor that has additional power-saving capabilities while maintaining very snappy performance. While the interactive governor provides a modern and sleek framework, the scaling logic has been been re-written completely. Reports have found that users find ondemandplus as a more battery friendly governor. In ondemandplus, the downscaling behavior from ondemand is only very slightly modified. However, the upscaling has been modified to not scale up to maximum frequency immediately.
40. Dynamic Interactive (DynInteractive)
Description:
This governor dynamically adjusts itself according to load. That means it's settings are dynamic (always changing) and not static (not changing). Dyninteractive still obtains the same great balance between battery life and performance found in the original interactive governor and improves it even further. This is not the same as the original interactive governor because of this unique behavior.
41. Smartmax
Description:
Smartmax is a mix between ondemand and smartassv2. It behaves mostly like smartass with the concept of an "ideal" frequency. By default this is configured for battery saving, so this is NOT a gaming or benchmark governor! Additionally, to make it "snappy", smartmax has "touch poke". So input events from the touchscreen will boost the cpu for a specific time to a specific frequency. Developed by XDA user Maxwen.
42. Ktoonservative\KtoonservativeQ
Description:
Ktoonservative is based on the Conservative governor, but with the addition of new tunable variables and hotplugging. It aims to be very responsive while also being good at saving battery. This governor is highly configurable and is found in ktoonsez's kernels.
43. Performance may cry (PMC)
Description:
A governor based on Smartmax except it's heavily tweaked for better and maximum battery life. This is not a gaming governor!
44. Dance Dance
Description:
Based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It is a performance focused governor but also blends with some battery savings.
45. AbyssPlugv2
Description:
AbyssPlugv2 is a rewrite of the original CPU governor. It also fixes the problem where the governor is set only for the first core, but now governs all cores right from whatever utility you use. There have been comments on the lack of stability with this governor.
46. IntelliMM
Description:
A rewrite of the old Min Max governor and has 3 cpu states: Idle, UI and Max. Intelliminmax (intellimm) governor is designed to work with the newer SOCs with fixed voltage rails (ie MSM8974+ SOCs). It is designed to work within those fixed voltage ranges in order to maximize battery performance while creating a smooth UI operations. It is battery friendly and spends most of the time at lower frequencies.
47. Interactive Pro
Description:
A newer (modified) version of interactive which is optimized for devices such as the One Plus One. It is a more efficient than the original Interactive because it continuously re-evaluates the load of each CPU therefore allowing the CPU to scale efficiently.
48. Slim
Description:
A new governor from the cm branch and the slimrom project. This is a performance optimized governor and has been tuned a lot for newer devices such as the One Plus One.
49. Ondemand EPS
Description:
A modified version of Ondemand and is optimized for newer devices. It is based on the Semaphore Kernel's Ondemand which is more optimized for battery life. The EPS at the end stands for Extreme power savings so this governor is biased to power savings!
50. Smartmax EPS
Description:
This governor is based on Smartmax but is optimized for 'Extreme Power Saving' (hence the EPS suffix). This means it uses less battery than the original Smartmax so it is not a very good gaming governor (again!) This is only found on newer devices.
Click to expand...
Click to collapse
You can find all the info in this thread