Database Info

[Q] Kernel Governors

Hi, I'm been on Endy 3.3 for some time now and I was just wondering, what's so special about SavageZen, Scary, UserSpace & virtuous governors?
Thanks in Advanced

Asddsads98 said:
Hi, I'm been on Endy 3.3 for some time now and I was just wondering, what's so special about SavageZen, Scary, UserSpace & virtuous governors?
Thanks in Advanced
Click to expand...
Click to collapse
Read below if you have the time!!
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.
Interactive – Available in newer kernels, and becoming the default scaling option in some official Android kernels.
The interactive governor is functionally similar to the ondemand governor with an even greater focus on responsiveness.
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.
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 CPU load.
Powersave – Available in some kernels. It will keep the CPU running at the “min” set value at all times.
Userspace – A method for controlling the CPU speed that isn't currently used by SetCPU. For best results, do not use the userspace governor.
Smartass – Included in some custom kernels. The smartass governor effectively gives the phone an automatic Screen Off profile, keeping speeds at a minimum when the phone is idle.
Virtuous - This is another name for the Smartass v2 governor. Basically it's a better, more tweaked Smartass governor. (I have found this to be the best so far, in my experience)
SavagedZen - SavagedZen is a governor based on the Smartass governor. With tweaks to paramaters which control how much and how fast cpu ramps up/down. Main difference versus Smartass is that cpu ramps down not in fixed steps, but based on cpu load heuristics, i.e. when cpu load falls below threshold (min_cpu_load), cpu immediately ramps down to a frequency derived from the measured load.
InteractiveX - Modified version of interactive with suspend code which locks at lowest clock speed when screen is off. Has a sleep+awake profile, meaning you don't need to set up manual profiles, it will lock at your minimum frequency during screen off
Scary - 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 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 will give the same performance as conservative right now, it will get tweaked over time.
Most of this information is originally copy-pasted from the SetCPU website, while the last three governors were explained by xda member Bewinxed on the Reaper ROM thread. So all credits to him (or her!)

CPU Governors explained

Thanks to deedii for posting this in another forum:
http://forum.xda-developers.com/show...65&postcount=2
Android CPU governors explained
1: OnDemand
2: OndemandX
3: Performance
4: Powersave
5: Conservative
6: Userspace
7: Min Max
8: Interactive
9: InteractiveX
10: Smartass
11: SmartassV2
12: Scary
13: Lagfree
14: Smoothass
15: Brazilianwax
16: SavagedZen
17: Lazy
18: Lionheart
19: LionheartX
20: Intellidemand
21: Hotplug
22: BadAss
23: Wheatley
24: Lulzactive
25: Pegasusq/Pegasusd
26: hotplugx
27: AbissPlug
28: MSM DCVS
29: IntelliActive
30: Adaptive
31: Nightmare
32: ZZmove
INFO I/O Scheduler go here: SCHEDULER
1: OnDemand Governor:
This governor has a hair trigger for boosting clockspeed to the maximum speed set by the user. If the CPU load placed by the user abates, the OnDemand governor will slowly step back down through the kernel's frequency steppings until it settles at the lowest possible frequency, or the user executes another task to demand a ramp.
OnDemand has excellent interface fluidity because of its high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand is commonly chosen by smartphone manufacturers because it is well-tested, reliable, and virtually guarantees the smoothest possible performance for the phone. This is so because users are vastly more likely to ***** about performance than they are the few hours of extra battery life another governor could have granted them.
This final fact is important to know before you read about the Interactive governor: OnDemand scales its clockspeed in a work queue context. In other words, once the task that triggered the clockspeed ramp is finished, OnDemand will attempt to move the clockspeed back to minimum. If the user executes another task that triggers OnDemand's ramp, the clockspeed will bounce from minimum to maximum. This can happen especially frequently if the user is multi-tasking. This, too, has negative implications for battery life.
2: OndemandX:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
3: Performance Governor:
This locks the phone's CPU at maximum frequency. While this may sound like an ugly idea, there is growing evidence to suggest that running a phone at its maximum frequency at all times will allow a faster race-to-idle. Race-to-idle is the process by which a phone completes a given task, such as syncing email, and returns the CPU to the extremely efficient low-power state. This still requires extensive testing, and a kernel that properly implements a given CPU's C-states (low power states).
4: Powersave Governor:
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
5:Conservative Governor:
This 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," if that helps to give you a more complete picture of its functionality.
6: Userspace Governor:
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
well this governor makes use of only min & maximum frequency based on workload... no intermediate frequencies are used.
8: Interactive Governor:
Much like the OnDemand governor, the Interactive governor dynamically scales CPU clockspeed in response to the workload placed on the CPU by the user. This is where the similarities end. Interactive is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Unlike OnDemand, which you'll recall scales clockspeed in the context of a work queue, Interactive scales the clockspeed over the course of a timer set arbitrarily by the kernel developer. 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. This can eliminate the frequency bouncing discussed in the OnDemand section. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. This is another pro-battery life benefit of Interactive.
However, because Interactive is permitted to spend more time at maximum frequency than OnDemand (for device performance reasons), the battery-saving benefits discussed above are effectively negated. Long story short, Interactive offers better performance than OnDemand (some say the best performance of any governor) and negligibly different battery life.
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.
9: InteractiveX Governor:
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
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!"
11: SmartassV2:
Version 2 of the original smartass governor from Erasmux. Another favorite for many a people. 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 (500 mhz for GS2 by default) 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
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 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 will give the same performance as conservative right now, it will get tweaked over time.
13: Lagfree:
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:
The same as the Smartass “governor” But MUCH more aggressive & across the board this one has a better battery life that is about a third better than stock KERNEL
15: Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery
16: SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
17: Lazy:
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:
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
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
20: Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). 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. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors)
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
21: Hotplug Governor:
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 Governor:
Badass removes all of this "fast peaking" to the max frequency. On a typical system the cpu won't go above 918Mhz and therefore stay cool and will use less power. To trigger a frequency increase, the system must run a bit @ 918Mhz with high load, then the frequency is bumped to 1188Mhz. 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 with 1188Mhz. If the gpu is crushed under load, badass will lift the restrictions to the cpu.
23: Wheatley:
Building on the classic 'ondemand' governor is implemented Wheatley governor. The governor has two additional parameters:
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.
Wheatley works as planned and does not hinder the proper C4 usage for task where the C4 can be used properly .
For internet browsing the time spend in C4 has increased by 10% points and the average residency has increased by about 1ms. I guess these differences are mostly due to the different browsing behaviour (I spend the last time more multi-tabbing). But at least we can say that Wheatley does not interfere with the proper use of the C4 state during 'light' tasks. For music playback with screen off the time spend in C4 is practically unchanged, however the average residency is reduced from around 30ms to around 18ms, but this is still more than acceptable.
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.
Obviously, this governor is only available on multi-core devices.
24: Lulzactive:
Lulzactive:
This new find from Tegrak is based on Interactive & Smartass governors and is one of the favorites.
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.
Example:
Consider
inc_cpu_load=70
pump_up_step=2
pump_down_step=1
If current frequency=200, Every up_sampling_time Us if cpu load >= 70%, cpu is scaled up 2 steps - to 800.
If current frequency =1200, Every down_sampling_time Us if cpu load < 70%, cpu is scaled down 1 step - to 1000.
25: Pegasusq/Pegasusd
The Pegasus-q / d is a multi-core based on the Ondemand governor and governor with integrated hot-plugging.
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 running 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
It 'a Hotplug modified and optimized for the suspension in off-screen
27: AbissPlug
It 'a Governor derived hotplug, it works the same way, but with the changes in savings for a better battery.
28: MSM DCVS
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.
A Krait CPU can smoothly scale from low power, low
leakage mode to blazingly fast performance.
Believe it's a governor that is mfg'd by qualcomm to utilize new on chip features.
MSM is the prefix for the SOC (MSM8960) and DCVS is Dynamic Clock and Voltage Scaling. Makes sense, MSM-DCVS
29: IntelliActive
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
30: Adaptive
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
increases so that the system is more responsive to
interactive workloads in loweset steady-state but to
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
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: ZZmove
ZZmove Governor optimized for low power consumption with the screen off, with particular attention to the limitation of consumption applications in the background with the screen off, such as listening to music. It has three settings: battery saver, balanced and performance. In addition to a performance boost, there is also the governor zzmove optimized.
Credits goes to:
http://icrontic.com/discussion/95140...m-tuner-tegrak
http://forum.xda-developers.com/show....php?t=1369817

NICE!

Really nice job there but badass governor is missing
Sent From My Sexy Sensation.

Very informative, thanks..could u also add a description for the new pegasus governor
Sent from my HTC Sensation 4G using Xparent Blue Tapatalk 2

I'll put to work

Where does bricked kernels badass fit in? What is it most similar to?

This was a good read, thanks for taking the time to write it up

kingston73 said:
Where does bricked kernels badass fit in? What is it most similar to?
Click to expand...
Click to collapse
perhaps because the translator, but I can not understand the question

Show-p's bricked kernel has a governer called "badass" and I wanted to know which kernel is most like his?

kingston73 said:
Show-p's bricked kernel has a governer called "badass" and I wanted to know which kernel is most like his?
Click to expand...
Click to collapse
I put badass to the list so you can compare and see which governor is right for you

thanks for the explanations, i was confused about what governor to choose and what each one did, but this explains everything in one place well done!

julio_rdz said:
thanks for the explanations, i was confused about what governor to choose and what each one did, but this explains everything in one place well done!
Click to expand...
Click to collapse
thanks, I'm glad this is useful for users

There are waaay to many governors(incl custom), many actually aren't even significantly different from another. If you ask me I say all we need is conservative, ondemand, and not performance(pointless+battery rape). Although I don't mind the x versions of the ones I listed, but that's just b/c I like the x nomenclature.

Excellent explanation!
Thank you very much!!

Anyone know a mod to keep my device cool-er while on badass
@OP great job on the explanation extremely useful.

Mr.Highway said:
Anyone know a mod to keep my device cool-er while on badass
@OP great job on the explanation extremely useful.
Click to expand...
Click to collapse
reflash the kernel using the below settings
keep 2d and 3d to default (most of the heating issues comes from gpu overclocks) and freq to default
also use battery saver configuration (it handles cpu freq transitions) (its not laggy btw)
on the contrary you can use iba's badass mod's but they are told to be placebo's (by the badass dev itself)

Mr.Highway said:
Anyone know a mod to keep my device cool-er while on badass
@OP great job on the explanation extremely useful.
Click to expand...
Click to collapse
You can also use this mod, it works great :http://forum.xda-developers.com/showthread.php?t=1641605

Several requests by, before long new incoming governor

Can you find an explanation for, and include, the wheatley governor please?

slopra said:
Can you find an explanation for, and include, the wheatley governor please?
Click to expand...
Click to collapse
I'm also working on it, just realized the work I insert

CPU Governors explained

Thanks to deedii for posting this in another forum:
http://forum.xda-developers.com/show...65&postcount=2
Android CPU governors explained
1: OnDemand
2: OndemandX
3: Performance
4: Powersave
5: Conservative
6: Userspace
7: Min Max
8: Interactive
9: InteractiveX
10: Smartass
11: SmartassV2
12: Scary
13: Lagfree
14: Smoothass
15: Brazilianwax
16: SavagedZen
17: Lazy
18: Lionheart
19: LionheartX
20: Intellidemand
21: Hotplug
22: BadAss
23: Wheatley
1: OnDemand Governor:
This governor has a hair trigger for boosting clockspeed to the maximum speed set by the user. If the CPU load placed by the user abates, the OnDemand governor will slowly step back down through the kernel's frequency steppings until it settles at the lowest possible frequency, or the user executes another task to demand a ramp.
OnDemand has excellent interface fluidity because of its high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand is commonly chosen by smartphone manufacturers because it is well-tested, reliable, and virtually guarantees the smoothest possible performance for the phone. This is so because users are vastly more likely to ***** about performance than they are the few hours of extra battery life another governor could have granted them.
This final fact is important to know before you read about the Interactive governor: OnDemand scales its clockspeed in a work queue context. In other words, once the task that triggered the clockspeed ramp is finished, OnDemand will attempt to move the clockspeed back to minimum. If the user executes another task that triggers OnDemand's ramp, the clockspeed will bounce from minimum to maximum. This can happen especially frequently if the user is multi-tasking. This, too, has negative implications for battery life.
2: OndemandX:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
3: Performance Governor:
This locks the phone's CPU at maximum frequency. While this may sound like an ugly idea, there is growing evidence to suggest that running a phone at its maximum frequency at all times will allow a faster race-to-idle. Race-to-idle is the process by which a phone completes a given task, such as syncing email, and returns the CPU to the extremely efficient low-power state. This still requires extensive testing, and a kernel that properly implements a given CPU's C-states (low power states).
4: Powersave Governor:
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
5:Conservative Governor:
This 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," if that helps to give you a more complete picture of its functionality.
6: Userspace Governor:
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
well this governor makes use of only min & maximum frequency based on workload... no intermediate frequencies are used.
8: Interactive Governor:
Much like the OnDemand governor, the Interactive governor dynamically scales CPU clockspeed in response to the workload placed on the CPU by the user. This is where the similarities end. Interactive is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Unlike OnDemand, which you'll recall scales clockspeed in the context of a work queue, Interactive scales the clockspeed over the course of a timer set arbitrarily by the kernel developer. 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. This can eliminate the frequency bouncing discussed in the OnDemand section. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. This is another pro-battery life benefit of Interactive.
However, because Interactive is permitted to spend more time at maximum frequency than OnDemand (for device performance reasons), the battery-saving benefits discussed above are effectively negated. Long story short, Interactive offers better performance than OnDemand (some say the best performance of any governor) and negligibly different battery life.
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.
9: InteractiveX Governor:
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
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!"
11: SmartassV2:
Version 2 of the original smartass governor from Erasmux. Another favorite for many a people. 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 (500 mhz for GS2 by default) 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
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 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 will give the same performance as conservative right now, it will get tweaked over time.
13: Lagfree:
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:
The same as the Smartass “governor” But MUCH more aggressive & across the board this one has a better battery life that is about a third better than stock KERNEL
15: Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery
16: SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
17: Lazy:
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:
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
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
20: Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). 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. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors)
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
21: Hotplug Governor:
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 Governor:
Badass removes all of this "fast peaking" to the max frequency. On a typical system the cpu won't go above 918Mhz and therefore stay cool and will use less power. To trigger a frequency increase, the system must run a bit @ 918Mhz with high load, then the frequency is bumped to 1188Mhz. 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 with 1188Mhz. If the gpu is crushed under load, badass will lift the restrictions to the cpu.
23: Wheatley:
Building on the classic 'ondemand' governor is implemented Wheatley governor. The governor has two additional parameters:
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.
Wheatley works as planned and does not hinder the proper C4 usage for task where the C4 can be used properly .
For internet browsing the time spend in C4 has increased by 10% points and the average residency has increased by about 1ms. I guess these differences are mostly due to the different browsing behaviour (I spend the last time more multi-tabbing). But at least we can say that Wheatley does not interfere with the proper use of the C4 state during 'light' tasks. For music playback with screen off the time spend in C4 is practically unchanged, however the average residency is reduced from around 30ms to around 18ms, but this is still more than acceptable.
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.
Obviously, this governor is only available on multi-core devices.
Credits goes to:
http://icrontic.com/discussion/95140...m-tuner-tegrak
http://forum.xda-developers.com/show....php?t=1369817
__________________

Thanks for posting this man. I've always wanted to know more detailed information and what exactly some governor's do.
Sent from my HTC VLE_U using xda premium

ickedmel said:
Thanks for posting this man. I've always wanted to know more detailed information and what exactly some governor's do.
Sent from my HTC VLE_U using xda premium
Click to expand...
Click to collapse
I'm glad, I think they are useful because we often use governor but in reality we do not really care about how they work

Very, very nice! Subscribed for future use

as governor used most frequently and why?

So whats the best/recommended governor to use?

I believe the ondemand governor is the best. There is a thread about this somewhere on the nexus subfora. The rest of the governors are just gimmicks

wilcoholic said:
I believe the ondemand governor is the best. There is a thread about this somewhere on the nexus subfora. The rest of the governors are just gimmicks
Click to expand...
Click to collapse
I do not think this depends on the type of use that must refer to one and the kernel than it has, for instance, I use the nexus s smartass v2 and works beautifully in sensation and use ondemand intellimand both work well, the first with the performance second best battery life

wilcoholic said:
I believe the ondemand governor is the best. There is a thread about this somewhere on the nexus subfora. The rest of the governors are just gimmicks
Click to expand...
Click to collapse
I don't think the others are gimmicks smart ass is an awesome governer
Sent from my HTC One S using xda premium

Is there an description for wheatley governor?
Sent from my Galaxy Nexus using Tapatalk 2

daggerxXxsin said:
Is there an description for wheatley governor?
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
In parole povere questo govenor è costruita su "ondemand", ma aumenta il tempo C4 stato della CPU e così facendo cercando di salvare il succo ....

daggerxXxsin said:
Is there an description for wheatley governor?
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
soon as I insert full description

Wheatley added

[GUIDE] Advanced Interactive Governor Tweaks; Buttery smooth and insane battery life!

The Introduction
I'm about to tell you how to get buttery smooth, lag free performance with insanely good battery life, using an old school governor featured in practically every kernel... This tweak is applicable to every phone with any ROM or kernel--stock or custom--that provides the Interactive Governor.
Yeah, yeah... everyone promises good battery with great performance, but who actually delivers? Maybe it isn't as smooth as you want, or maybe it requires something your kernel or ROM don't support. Or maybe the battery life promises just aren't what you expected. There's always some awful compromise. Not here!
This isn't a guide to get 36 hour battery life... provided you never use your phone. That's deep sleep optimization, which is lovely and all, but what good is the phone if you can never use it?! And with the new Marshmallow Doze feature, this strategy is becoming a think of the past. What I'm talking about is 7-14 hour screen on, actual hands-on usage times! Without compromising anything, you can get 7-8 hour screen on usage with regular, no-compromise usage habits: daytime visible screen brightness, both radios on, sync on, network location on, all the regular usage features, the whole kit and kaboodle... all smooth as a baby's butt and snappy as a Slim Jim! (Up to 14+ hours if you can stand minimum brightness and WiFi-only with a custom ROM and other stuff turned off! And this is with stock voltages and full frequency range--you'll likely get even more if you choose to optimize those as well!)
However, it should be noted that this does not apply to gaming, heavy camera use, etc. Anything that is an automatic battery killer in and of itself. There's nothing that can be done about anything that forces the phone to utilize its maximum resources all the time. But you should know that by now. Further, this guide is about optimizing the CPU as much as possible. It does not cover things like eliminating wakelocks so your phone sleeps well, removing unnecessary and battery draining stock apps, keeping your screen brightness down*, and all that stuff that's been covered in other posts ad infinitum. Those optimizations are up to you.
*At least on the Mi4i, you shouldn't be turning your screen brightness above about 50%. It should be more than viewable in sunlight at that brightness, and keep in mind that the brightness power requirements increase exponentially, so a 100% bright LCD screen will use about 3.5-4.5x more power than a 60% bright screen. I don't see that fact brought up often, so I thought I'd mention it here.
After a bit of tweaking and experimenting, I developed some settings that provide absolutely incredible battery life, buttery smooth performance, and a lag free experience. And you don't need a fancy governor, or a custom kernel, custom clock rates, or even a Mi4i. This will work on any ROOTed phone with the Interactive governor!
The Nitty Gritty
Before I lay out all the settings so you can blindly enter them into your governor control, I should to explain some of the principals I employed to get the results I did. The primary thing to understand before I do is: little might you know, the settings in the Interactive governor can be tweaked on a clock range basis. That is to say, you can finely control how the governor responds at a variety of clock rates, thus better dictating how it should operate under various loads. This is integral to the configuration, because it means the difference between jumping from the slowest speed to the highest speed under load and sustaining lower clock speeds for tasks that don't really require higher clock speeds.
By default, the Interactive governor will jump from lowest speed to a "nominal" speed under load, and then scale up from that speed as load is sustained. That is lovely, but still too twitchy to provide serious efficiency and power savings. It spends most of its time at 2 or 3 clock speeds and barely hits other clock speeds that are ideal for other tasks or usage patterns.
Instead, what we want to do is configure it to handle different types of loads in different ways. A load suited for scrolling through a webpage is not the same as a load suited for downloading/processing streaming video is not the same as a load suited for snappy loading of an app is not the same as a load suited for high performance gaming. Every kind of load has different tolerances at which their minimal speed is indistinguishable from their maximal speed.
Nominal Clock Rates
Nominal clock rates are the minimum CPU clock rates that perform a given task smoothly and without stuttering or lag. To find the nominal clock rate for a given task, turn on only the first CPU using the Performance governor and turn them both down incrementally until you find the minimum clock rate that works best for what you're trying to do, without introducing hiccups. (If you have a CPU or kernel that hotplugs individual cores, multiply that clock speed by your number of cores.) Keep the 2nd CPU on the Powersave governor with the lowest frequency your kernel supports. (Or turn it off completely if hotplugging allows.)
(Note: If your device supports per-core hotplugging, you might be better off using the old guide to determine your nominal clock rates. The Mi4i and all current kernels only support hotplugging entire CPUs, so your results may vary if you use any other device.)
For example, on my Mi4i, scrolling (not loading, simply scrolling) through a large webpage smoothly will occur when the second CPU clock rates are no less than 460Mhz. (This is on mine without background tasks taking any CPU. Yours may be different depending on services running, the browser you use, your ROM, kernel, etc.) Thus, the nominal clock rate for scrolling a webpage on my Mi4i is 460Mhz.
To understand what's best under a variety of tasks, we have to identify two types of load profiles: nominal clock rates and efficient clock rates.
Efficient Clock Rates
Efficient clock rates are CPU clock rates that are unique in that they are the most optimal frequency given the range of voltage requirements. If you map out the frequency jump and the voltage requirement jump between each of the available clock rates, you will find that occasionally the voltage requirement will jump significantly without the frequency jumping proportionally to the previous differentials. For example, using stock voltages, the EvoLTE's msm8960 chipset clock/voltage ratios jump significantly higher from 702Mhz to 810Mhz than the ratios from 594Mhz to 702Mhz.
This section is INCOMPLETE! If you know the voltages, please post and I can update this guide to include the Mi4i's Efficient Clock Rates.
Clock Rate Biases
Using the information provided above, figure out both your nominal clock rates for the tasks you perform most often and your efficient clock rates depending on your kernel/custom voltage settings. For me, since I cannot determine the efficient clock rates, I use the nominal clock rates listed above. For the tasks I generally perform on my phone, my nominal clock rates are as follows:
Idle - 345Mhz
Page Scrolling - 533Mhz
Video -800Mhz
App Loading - 960Mhz
High Load Processing - 1612Mhz
(Note that you must calculate the values that are optimal for your phone for best battery and performance! Each phone is different because of the ROM, kernel, background tasks, etc!)
With this done, you will want to start the fine tuning phase! Correlate the efficient clock rates with their closest nominal clock rates, similar to below:
(This section of the guide is INCOMPLETE because I do not know the clock rate voltages for the Mi4i. If you know these, please post in the comments and I will update the guide!)
Idle - ???Mhz efficient / 345Mhz nominal
Page Scrolling - ???Mhz efficient / 533Mhz nominal
Video - ???Mhz efficient / 800Mhz nominal
App Loading - ???Mhz efficient / 960Mhz nominal
High Load - ???Mhz efficient / 1651Mhz nominal
Keep these handy, as they're going to be necessary for...
The Set Up
Now that we know what are the most efficient nominal clock rates we want to focus on and what the most optimal are for what we want to do, we will start low and scale up as necessary. It's always better to begin with underperforming and tweak the settings upward until we're satisfied with the performance of our target tasks.
In its default state, the Interactive governor has a hair trigger that will raise and lower the clock rates, which means it spends too much time at unnecessary clock speeds, wasting power, and scales down too quickly, leading to stuttering performance. We will take advantage of a seldom used feature of the Interactive governor. Specifically, that with which it determines when it is okay to scale up to each higher clock rate, on a frequency by frequency basis.
We have two primary goals: respond as quickly as possible to each load request for a lag free experience and exceed the desired clock rate for a given task as little as possible. To do this, we will instruct the Interactive governor to trigger certain clock rates in different ways depending on our expected load.
I won't explain all of the settings of the Interactive governor--there are plenty of summaries all around. (Go search now if you don't know what any of the settings for Interactive governor do. I'll wait here.) However, I will explain an incredibly powerful feature of the Interactive governor that is rarely included in those summaries: multiple frequency adjustments.
The above_highspeed_delay setting, for example, defines how long the governor should wait before escalating the clock rate beyond what's set in highspeed_freq. However, you can define multiple different delays that the governor should use for any specified frequency.
For example, we want the above_highspeed_delay as low as possible to get the CPU out of the idle state as quickly as possible when a significant load is applied. However, we don't want it to jump immediately to the fastest clock rate once it's gotten out of idle, as that may be overkill for the current task. Our target trigger (which you will later adjust to suit your system and usage profile), will begin at 20000μs. That means 20,000μs (or 20ms) after our idle max load has been reached, we want to assume idle has been broken and we want to perform an actual task. (We want this value as low as possible without false positives, because it is one of a few factors that determine how snappy and lag free the CPU's response is.)
But at this point we're not ready to take on a full processing load. We may just be briefly scrolling a webpage and don't need the full power of the CPU now that we've allowed it to break out of idle. So we need it to reach a particular frequency and then hold it there again until we're sure the load is justified before we allow it to push the frequency even higher. To do that, rather than just setting
above_highspeed_delay - 20000​
we will instead use the format "frequency:delay" to set
above_highspeed_delay - 20000 460000:60000 600000:20000​
"Waaaait... What does that do?!"
This tells the Interactive governor to hold out 20ms after our target load when it's at our highspeed_freq (which we're actually using as our idle frequency--not a burst frequency as originally intended), but then it tells the governor to hold for 60ms after it's reached 460Mhz. Once it has exceeded 460Mhz, it then has free reign to scale up without limitation. (This will be optimized with the target_loads setting in a minute. And if you don't know what I'm talking about when I say "highspeed_freq" then you didn't go search for the basic Interactive governor settings and read about it! Go do that before you read any further, because I will not explain the basics of this governor!)
These settings are among the most important, because they limit the phone's clock rates when you are not interacting with it. If it needs to do something in the background, chances are it does not need to run full throttle! Background and idle tasks should be limited to the lowest reasonable clock rate. Generally speaking, if you're just looking at your phone (to read something, for example), you want the phone to use as little CPU power as possible. This includes checking in with Google to report your location or fetching some pull data or... whatever. Things that you don't need performance for.
So now that we know how to specify different settings for different frequency ranges, let's finish it all up with...
What About Touchboost?
Touchboost is a nifty feature in a lot of kernels (including stock on Mi4i) that jumps up the frequency so that you experience minimal lag. However, with all the above settings, touchboost is usally detrimental to the efficiency of the device!
We generally want to keep the CPU on the lowest possible frequency as much as possible, and touchboost interferes with that. Further, because we've set up the maximal and minimal efficient clock rates, as well as burst processing from the 1st CPU core, we don't need touchboost!
If your kernel allows you to shut it off, try to do so and see if the responsiveness of your device is acceptable. On the Mi4i, touchboost adds no perceptual performance gain and only hurts efficiency and battery life. If your kernel doesn't allow you to turn off touchboost, try another one, like the excellent Sensei.
Your battery life will thank you!
The Setup
In the "CPU" section, turn off "Touchboost". (This is crucial!! YOU MUST TURN OFF TOUCHBOOST OR ELSE YOU WILL NOT SEE ANY BATTERY SAVINGS!!!) Make sure the "Max CPU Frequency" is set to the maximum possible value for each CPU. Make sure the "Min CPU Frequency" is set to the minimum possible value for each CPU. Under "CPU Boost", set "input boost milliseconds" to "0". Then set the following values for each CPU under "Governor options" for each CPU respectively:
CPU #1 (aka "Big", aka "has 4 cores", aka "maxes out at 1665Mhz")
target_loads - 1 960000:80 1113600:85 1344000:90
timer_slack - 80000
hispeed_freq - 1113600
timer_rate - 20000
above_hispeed_delay - 20000 1113600:50000
go_hispeed_load - 85
min_sample_time - 50000
CPU #2 (aka "little", aka "has 4 cores", aka "maxes out at 1113Mhz")
target_loads - 1 800000:80
timer_slack - 80000
hispeed_freq - 998400
timer_rate - 40000
above_hispeed_delay - 10000
go_hispeed_load - 90
min_sample_time - 40000
The Conclusion
I have achieved unprecedented performance, smoothness, snappiness, and battery life with the default settings I outlined above. However, your mileage may vary, as every phone, ROM, kernel, installed applications, etc are different. This is a very sensitive governor profile and must be tweaked to just meet the requirements of your system and your usage patterns!
If it is not optimally tuned, performance and battery life will suffer! If you're not seeing buttery smooth, snappy performance, you have not correctly tuned it for your system!! However, if you do have superb performance (and you tweaked the values conservatively and not in large steps), then you will also get the aforementioned battery life.
I will be happy to answer any questions, or provide any guidance I can. However:
You must otherwise optimize your phone first! This will not "fix" a poorly optimized system and will, in fact, reduce performance and battery life without further optimization and proper tweaking.
I will not answer questions about "what is a governor?" There are plenty of resources available already, so search for them.
I will not answer questions about "how can I tweak [some other] governor?" This is about the Interactive governor only.
I will not respond to "nuh uh! show proof!" posts. The fact that I spent 12 hours writing this up should be proof enough that I am satisfied with the results. You can take it or leave it; makes no difference to me. The default settings should work with any fully optimized Mi4i running any kernel, so just try them on your own. If you're not absolutely satisfied (and trust me, either it'll work out-of-the-box with flying colors and you'll know it works for your system, or it'll be an awful experience which means you must tweak it), then you haven't adequately adjusted the settings to suit your system.
Lemme know what you think, and good luck!
Thanks to @soniCron for the original thread here : http://forum.xda-developers.com/nexus-5x/general/guide-advanced-interactive-governor-t3269557

Woah, Will try it soon. Thanks for the awesome thread and work.

The interactive governor from your Sensei kernel already had all these settings tuned.
I will come back in 24-48 hours with results.
One question that I have is: will something like Amplify (deals with wakelocks) interfere with this?

mandarin91 said:
The interactive governor from your Sensei kernel already had all these settings tuned.
I will come back in 24-48 hours with results.
One question that I have is: will something like Amplify (deals with wakelocks) interfere with this?
Click to expand...
Click to collapse
I've dealt with a few wakelocks in the kernel, Amplify won't disturb anything I guess.. Also this is just for future refs for users who are either on stock or any other kernel...

How exactly does this target load list work - why the loads are not progressive, but 85 - 90 - 80? set target to 90% load at 1.1ghz, but then we want 80% at 1.3ghz? Shouldn't the target loads only go up?
target_loads - 1 960000:85 1113600:90 1344000:80

are you sure that above_highspeed_delay for CPU#2 is correct?

danb1974 said:
How exactly does this target load list work - why the loads are not progressive, but 85 - 90 - 80? set target to 90% load at 1.1ghz, but then we want 80% at 1.3ghz? Shouldn't the target loads only go up?
target_loads - 1 960000:85 1113600:90 1344000:80
Click to expand...
Click to collapse
Exactly. And where are the lower frequencies?
The lower frequencies are left untouched. I've been testing this for some time now. Look at the screenshots.

mandarin91 said:
Exactly. And where are the lower frequencies?
The lower frequencies are left untouched. I've been testing this for some time now. Look at the screenshots.
Click to expand...
Click to collapse
bump (?)
Will we get an answer?

I've fixed the settings, target load will now go up rather than up-up-down... Also these settigs are a WIP, right now this is the optimal settings I have that will provide battery life and performance. I will update the settings each time an improvement is made.

Lower frequencies aren't doing much fr me but I'll try to include them into the formula...

haikalizz said:
Lower frequencies aren't doing much fr me but I'll try to include them into the formula...
Click to expand...
Click to collapse
I am talking about these:
Idle - 345Mhz
Page Scrolling - 533Mhz
Video -800Mhz
App Loading - 960Mhz
High Load Processing - 1612Mhz
Click to expand...
Click to collapse
If these "aren't doing much" then there will be only five frequencies: 200, 960, 1113, 1344, and 1651.
And most of the time is spent on 200 or 960. Won't the frequencies between 200 and 960 give better battery life?

How can an awesome thread like this die?

mandarin91 said:
I am talking about these:
If these "aren't doing much" then there will be only five frequencies: 200, 960, 1113, 1344, and 1651.
And most of the time is spent on 200 or 960. Won't the frequencies between 200 and 960 give better battery life?
Click to expand...
Click to collapse
no it doesnt quite work that way. not all lower frequencies will give better battery life. it also depends on the SOC in question and the nature of the SOC. I think hakalizz has mentioned previously of several optimized voltages and frequencies which we don't know for the snapdragon 615. let's use the 615 and some hypothetical values
200mhz - 650mv
400mhz - 650mv
you would have thought that 200mhz would give better battery savings but that isnt the case over here. even though the 400mhz would use more power (even though it is rated the same as 200mhz), technically you get battery savings because 400mhz gets the job done in well, twice the speed of the 200mhz. So you need to either figure out which of your frequencies are optimized in such a way that it can take advantage of the race to idle factor too.
for now i'm still on zzmoove but only to a point where i figure out how to optimize interactive for my own usage (with hotplugging etc)
just to further the point on this advance interactive tweaks - theory-wise and practicality-wise it is sound, you use the best frequencies(Bare minimum that you can stand) and you enjoy battery savings as well. the only issue I see is if you use your phoen differently from the OP. that's why haikalizz says you need to tweak and adjust it on your own

davtse said:
no it doesnt quite work that way. not all lower frequencies will give better battery life. it also depends on the SOC in question and the nature of the SOC. I think hakalizz has mentioned previously of several optimized voltages and frequencies which we don't know for the snapdragon 615. let's use the 615 and some hypothetical values
200mhz - 650mv
400mhz - 650mv
you would have thought that 200mhz would give better battery savings but that isnt the case over here. even though the 400mhz would use more power (even though it is rated the same as 200mhz), technically you get battery savings because 400mhz gets the job done in well, twice the speed of the 200mhz. So you need to either figure out which of your frequencies are optimized in such a way that it can take advantage of the race to idle factor too.
for now i'm still on zzmoove but only to a point where i figure out how to optimize interactive for my own usage (with hotplugging etc)
just to further the point on this advance interactive tweaks - theory-wise and practicality-wise it is sound, you use the best frequencies(Bare minimum that you can stand) and you enjoy battery savings as well. the only issue I see is if you use your phoen differently from the OP. that's why haikalizz says you need to tweak and adjust it on your own
Click to expand...
Click to collapse
Dude, haikalizz mentioned those frequencies in the post but never implemented them in the settings. That is what I'm saying.
Idle - 345Mhz
Page Scrolling - 533Mhz
Video -800Mhz
App Loading - 960Mhz
High Load Processing - 1612Mhz

mandarin91 said:
Dude, haikalizz mentioned those frequencies in the post but never implemented them in the settings. That is what I'm saying.
Idle - 345Mhz
Page Scrolling - 533Mhz
Video -800Mhz
App Loading - 960Mhz
High Load Processing - 1612Mhz
Click to expand...
Click to collapse
dude, i was responding to your question, should these freq inbetween give better battery life

You must otherwise optimize your phone first! This will not "fix" a poorly optimized system and will, in fact, reduce performance and battery life without further optimization and proper tweaking.
Please tell me how to optimize my phone ?

rmusa06 said:
You must otherwise optimize your phone first! This will not "fix" a poorly optimized system and will, in fact, reduce performance and battery life without further optimization and proper tweaking.
Please tell me how to optimize my phone ?
Click to expand...
Click to collapse
Debloat, amplify, things like that...

haikalizz said:
Debloat, amplify, things like that...
Click to expand...
Click to collapse
Thank you sir

What app are you using to implement the changes?

Well I got some nice results applying this technique and have overall 1/2 hours more sot using interactive gov. The only profile that works and follows the normal rules is the Ghostpepper profile. I have a moto x play with the same soc so it should work for the mi4i to. First you must calculate the max and min target loads before you can do something power efficient using this technique.
My advice is try to translate the nexus5x ghostpepper profile and replace your min and max target_loads with the ones in the original profile.
And why is this thread just copied and pasted from the original nexus5 thread and only replaced some words with "mi4i". You also forgot the most important part: calculating the min and max target_loads.

[KERNEL] Twisted Note {BPL1} Graphite Optimized [SaberMod 5.3] 2/12/2017

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
I'm not going to make a colorful thread on this. Just going to run down the basics......
To start off, I do NOT own a Note 5. I have a S6. I built this kernel for @tdunham just to see
if I could without having the device. And it was a success. It has been tested by @tdunham
personally, so I know its good to go.......
There are not alot of features. But it is very stable like stock. In the future when I have time
I will add more features and tweaks. Alot of that depends on YOU.....I built a kernel for a
device I dont have, so some appreciation will go a long ways. A simple Thank you is free,
and goes a long ways with me.......
*FEATURES*
Built with Sprint BPL1 Sources
Compiled with UBERTC 5.3 Toolchain (optimized)
Linux 3.10.101
Set to Permissive
Deep Sleep Fix
Compiled with Graphite Optimizations
21 CPU Governors
11 I/O Schedulers
Optimized I/O Read Speeds
13 TCP Congestion Algrorithms
and more......
Flashing this is pretty simple. Download the zip, go into recovery and flash. There
is no need to wipe. Modules are now built into the kernel. So all that you are flashing is a
boot.img. If for some reason when you flash and it goes back into recovery, let me
know and I will provide a different zip (has different updater-script).
Like I stated above......All I ask is some participation in my thread. A dead thread
gets no attention from me at all. I have 2 kernels and a rom to worry about besides this
thread. Other than that........Enjoy.
Note-5-Kernel-V1
Note-5-Kernel-V2
Note-5-Kernel-V3
Twisted-Note
Code:
May 15
Initial Release
May 16
Fixed reboot issue
June 4
Compiled with UBERTC 6.0 Toolchain
Added 21 CPU Governors
Added 11 I/O Schedulers
Added 13 TCP Congestion Algrorithms
Optimized Read Speeds
June 7
Fixed reboot issue by compiling w/ UBERTC 5.3
August 19
Updated to latest source BPG1
UberTC 5.3
Feb 12
Updated to latest BPL1 source
Added ROW scheduler
All features from previous builds added
*Issues*
See post #13 for the WiFi fix for remembering your password​
XDA:DevDB Information
Stock Sprint Kernel, Kernel for the Sprint Samsung Galaxy Note5
Contributors
The Sickness
Source Code: https://github.com/The-Sickness/Note-5---BPL1
Kernel Special Features:
Version Information
Status: Testing
Stable Release Date: 2016-05-14
Beta Release Date: 2016-05-14
Created 2016-05-15
Last Updated 2016-05-14

UPDATED [KERNEL] *Stock 6.0.1 V2* [Permissive] UBERTC 5.3 [GRAPHITE] BPC3 6/04/2016
Moderator Edit - Second post for additional information

Here is a list of governors (not all are in my kernel) and what they do......
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
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
Bluactive
Umbrella_core
ConservativeX
Hyrdxq
DevilQ
Yankasusq
Darkness
Alucard
Descriptions:
1. OnDemand Governor: This governor has a hair trigger for boosting clockspeed to the maximum speed set by the user. If the CPU load placed by the user abates, the OnDemand governor will slowly step back down through the kernel's frequency steppings until it settles at the lowest possible frequency, or the user executes another task to demand a ramp.
OnDemand has excellent interface fluidity because of its high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand is commonly chosen by smartphone manufacturers because it is well-tested, reliable, and virtually guarantees the smoothest possible performance for the phone.
This final fact is important to know before you read about the Interactive governor: OnDemand scales its clockspeed in a work queue context. In other words, once the task that triggered the clockspeed ramp is finished, OnDemand will attempt to move the clockspeed back to minimum. If the user executes another task that triggers OnDemand's ramp, the clockspeed will bounce from minimum to maximum. This can happen especially frequently if the user is multi-tasking. This, too, has negative implications for battery life.
2. OndemandX: Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors.
3. Performance Governor: This locks the phone's CPU at maximum frequency. While this may sound like an ugly idea, there is growing evidence to suggest that running a phone at its maximum frequency at all times will allow a faster race-to-idle. Race-to-idle is the process by which a phone completes a given task, such as syncing email, and returns the CPU to the extremely efficient low-power state. This still requires extensive testing, and a kernel that properly implements a given CPU's C-states (low power states).
4. Powersave Governor: The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
5. Conservative Governor: This 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," if that helps to give you a more complete picture of its functionality.
6. Userspace Governor: 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 well this governor makes use of only min & maximum frequency based on workload... no intermediate frequencies are used.
8. Interactive Governor: Much like the OnDemand governor, the Interactive governor dynamically scales CPU clockspeed in response to the workload placed on the CPU by the user. This is where the similarities end. Interactive is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Unlike OnDemand, which you'll recall scales clockspeed in the context of a work queue, Interactive scales the clockspeed over the course of a timer set arbitrarily by the kernel developer. 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. This can eliminate the frequency bouncing discussed in the OnDemand section. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. This is another pro-battery life benefit of Interactive.
However, because Interactive is permitted to spend more time at maximum frequency than OnDemand (for device performance reasons), the battery-saving benefits discussed above are effectively negated. Long story short, Interactive offers better performance than OnDemand (some say the best performance of any governor) and negligibly different battery life.
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.
9. InteractiveX Governor: 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 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. Lets take for example the 528/176 kernel, it will sleep at 352/176. No need for sleep profiles any more!"
11. SmartassV2: 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 (500 mhz for GS2 by default) 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 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 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 will give the same performance as conservative right now, it will get tweaked over time.
13. Lagfree: 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: The same as the Smartass “governor” But MUCH more aggressive & across the board this one has a better battery life that is about a third better than stock KERNEL
15. Brazilianwax: Similar to smartassV2. More aggressive ramping, so more performance, less battery
16. SavagedZen: Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
17. Lazy: 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: 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 LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
20. Intellidemand: Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). 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. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time.
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
21. Hotplug Governor:
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 Goveronor:
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 with 1188Mhz. If the gpu is crushed under load, badass will lift the restrictions to the cpu.
23. Wheatley:
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:
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 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. However, it is less stable than HYPER on some devices like the S2 (before the PegasusQ governor was updated). 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 It's a modified version of Hotplug and optimized for the suspension in off-screen
27. AbyssPlug It's a Governor derived from hotplug, it works the same way, but with the changes in savings for a better battery.
28. MSM DCVS 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 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.
This is a more performance oriented CPU governor but isn't that much different from interactive (in terms of code).
30. Adaptive 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 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. ZZmove
The ZZmove 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. ZZmoove is not a good gaming governor as it aims to save battery. This governor is still a WIP as the developer is constantly giving updates! Here are the available profiles:
33. Sleepy
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
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. This is a more smoothness oriented governor which means that it is good for performance, without sacrificing much battery life.
35. SmartassH3
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
It is a mix of pegasusq and ondemand. Therefore, it has a balance between battery savings and performance.
37. NeoX
An optimized version of the pegasusq governor but with some extra tweaks for better performance. This means more battery drainage than the original PegasusQ.
38. ZZmanx
ZZmanx is exactly the same as ZZmove, 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 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. DynInteractive A dynamic interactive Governor. This Governor dynamically adapts it's own CPU frequencies within your parameters based off the system(s) load.
41. Smartmax
This is a new governor which is a mix between ondemand and smartassv2. By default this is configured for battery saving,so this is NOT a gamer governor! This is still WIP!
42. Ktoonservative\KtoonservativeQ
A combination of ondemand and conservative. Ktoonservative contains a hotplugging variable which determines when the second core comes online. The governor shuts the core off when it returns to the second lowest frequency thus giving us a handle on the second performance factor in our CPUs behavior.
43. Performance may cry (PMC)
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
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
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
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
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
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
Once again, 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 and better performance than the traditional ondemand governor.
50. Smartmax EPS
A newer smartmax governor that has been slightly optimized for newer devices.
51. Uberdemand
Uberdemand is Ondemand with 2-phase feature meaning it has a soft cap at 1728 MHz so your cpu won't always go directly to max, made by Chet Kener.
52. Yankactive
A slightly modified interactive based governor by Yank555.lu. It has battery tweaks added onto it so expect better battery life! Based on user reports, this governor behaves more battery friendly than the original interactive governor without sacrificing performance.
53. Impulse
An improved version of interactive modified by neobuddy89. Impulse aims to have a balance between battery and performance just like interactive but has some tweaks to save battery.
54. Bacon
This is nothing but polished interactive governor branded as "bacon" since it was adapted from bacon device thanks to neobuddy89. Most of the tweaks are for performance/latency improvements
55. Optimax governor
This is based on ONDEMAND, like almost all governors that have arisen from XDA. It contains some enhancements from LG, particularly to freq boost handling so it will boost to a set level, almost like HTC's governor. It has different tunables to the HTC governor but it behaves pretty similar, the tunables it comes with default are a bit more conservative.
It originates from Cl3kener's Uber kernel for Nexus 5, where it has quite a reputation for battery life
56. Preservative governor
This is based on the idea that the CPU will consume a lot of power when it changes frequency. It is based on the conservative governor. The idea is that it will stay at the step specified (702MHz selected by the creator Bedalus) unless needed. You will notice it will hover around 702 a lot, and not go above too much, and only to min freq when NOTHING is happening at all. This is most beneficial when you are doing something like reading; the screen is static or playing light games that won't need boosting any more
The governor comes from Moob kernel for nexus 4
57. Touchdemand
Touchdemand is based on the ondemand cpu governor but has been modified for the Tegra 3 chip (tablet only) and has additional tweaks for touchscreen responsiveness.
58. ElementalX
If you are an owner of a nexus device, you probably have heard of a governor named ElementalX. Named after the kernel, elementalX is based on interactive but with some additional performance tweaks. This governor focuses on performance and not battery savings!
59. Bioshock
Not the game, but rather the CPU governor developed by Jamison904. A mix of ConservativeX and Lionheart. Good balance between battery savings and performance.
60. Blueactive
A new cpu governor based on interactive with tweaks to improve battery life. This governor is heavily focused in battery savings while performing decent in multitasking. Not a recommended gaming governor.
61. Umbrella_core
A new cpu governor based on interactive that is focused on battery life and not performance. It will still ramp up to a set frequency but will not stay at high frequencies for long. Users have reported weird behavior with this governor
62. ConservativeX
Essentially, it is a less aggressive version of conservative. More battery life, less performance.
63. HydrxQ
Simply a lulzactiveq governor with tweaks to performance (thanks to tegrak).
64. DevilQ
An aggressive pegasusq governor which keeps the hotplugging at max 2 cpu cores to offline). This is pretty much a more optimized pegasusq for phone's with quad core processors.
65. YankasusQ
Yankasusq is another modified pegasusq but with including screen off freq tunable and some other modifications as well. Possibly better battery life.
66. Darkness
It's based on nightmare but more simple and fast, basic configs but very complex structure. It is an updated nightmare gov and improved stability, so far it is quite stable in tests
67. Alucard
A favourite choice and one of the original governors that Alucard_24 made. Alucard is based on ondemand but has been heavily tweaked to bring better battery life and performance. It has been known to be battery friendly without sacrificing much performance.
Thanks to poondog for some of his governor descriptions!

Got it ?
Sent from my SM-N920P using XDA-Developers mobile app

Awesome man! Downloading now and about to refresh my rom. This came at the perfect time! Thank you so much!

Ill try it out ....thanks man
Sent from my SM-N920P using XDA-Developers mobile app

Thank you my good sir.
Sent from my SM-N920P using XDA-Developers mobile app

I assume it's booting up for everyone....if it wasn't I'm sure I would know by now
Sent from my Samsung Galaxy S6 using XDA Labs

Boots and works perfect, thanks again
Sent from my SM-N920P using XDA-Developers mobile app

The Sickness said:
I assume it's booting up for everyone....if it wasn't I'm sure I would know by now
Sent from my Samsung Galaxy S6 using XDA Labs
Click to expand...
Click to collapse
Working for me! Thank you for putting in the extra time, If I had the know how, I would love to help.
Sent from my SM-N920P using XDA-Developers mobile app

Thanks for doing this for us! I really appreciate your time.
Thanks,
Chaz187

Boots up fine and run butter smooth. Excellent work man. I haven't had an issue all night/ this morning. :good:

Thanks bro ??
Sent from my SM-N920T using XDA-Developers mobile app

Known issue:
Forgetting wifi after a reboot.
Here is a wifi fix for this awesome kernel.
(This is the build.prop from the Moar 3.2 MM build so if you are running an earlier version don't be fooled... just saying )
The change/fix was to modify this line in build.prop:
Code:
ro.securestorage.support=[COLOR="Blue"]false[/COLOR]
Credit @The Sickness for the fix and of course the custom kernel as well. :good:

good kernal so far testing battery drain now. will report back in a couple days . the only thing that i can see so far is Vudu do not play on any kernel that i flash, even this one. but it do play on stock Rom thu. so i dont know if it a rooted phone problem or a kernel problem .

Thanks for sharing ! Awesome work!!
Sent from my SM-N920P using Tapatalk

smiley45 said:
good kernal so far testing battery drain now. will report back in a couple days . the only thing that i can see so far is Vudu do not play on any kernel that i flash, even this one. but it do play on stock Rom thu. so i dont know if it a rooted phone problem or a kernel problem .
Click to expand...
Click to collapse
I cant say. I just installed this and breezed through a couple free tv episodes of something to test it and it seems to be fine.

I want to say Thank you to the person who donated to me....THANK YOU
Sent from my Samsung Galaxy S6 using XDA Labs

tdunham said:
Known issue:
Forgetting wifi after a reboot.
Here is a wifi fix for this awesome kernel.
(This is the build.prop from the Moar 3.2 MM build so if you are running an earlier version don't be fooled... just saying )
The change/fix was to modify this line in build.prop:
Credit @The Sickness for the fix and of course the custom kernel as well. :good:
Click to expand...
Click to collapse
Thanks Charles & The Sickness

I want to say Thank You to another donation. I really do appreciate it.
Yall make the S6 forums look real bad lol...
Sent from my Samsung Galaxy S6 using XDA Labs