Database Info

[SHARE] CPU Governors and I/O Schedulers Explained 12/23

Hey guys. Thanks to stealthware, -Grift- , and stempox for these information. However, I geared it so that it applies more to the SkyRocket users.
Thanks Appreciated!
CPU Governors Explained:
THE USUAL GOVERNORS
1- OnDemand
2- Interactive
3- Performance
4- Powersave
5- Conservative
6- Userspace
THE OTHER AWESOME GOVERNORS
1- OnDemandX
2- InteractiveX
3- Badass
4- Lagfree
5- Scary
6- Lazy
7- Lionheart
8- SmartassV2
9- Wheatley
10- Intellidemand
11- Lulzactive
I/O Scheduler explained in bottom part of post-
THE USUAL GOVERNORS
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: 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.
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.
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.
NOW THE OTHER AWESOME GOVERNORS
1: 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.
2: InteractiveX:
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.
3: Badass
Badass removes all of this "fast peaking" to the max frequency. On a typical system the cpu won't go above 1080Mhz and therefore use less power. To trigger a frequency increase, the system must run a bit @ 1080MHz with high load, then the frequency is bumped to 1350MHz. If that is still not enough the governor gives you full throttle. (this transition should not take longer than 2-5 seconds, depending on the load your system is experiencing).
You can tweak the Phase 2 (1080MHz) and Phase 3 (1350MHz) via sysfs (if you don't know, then just leave it alone)
4: 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.
5: 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.
6: 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.
7: 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.
8: 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.
9: Wheatley:
in short words this govenor is build on “ondemand” but increases the C4 (the sleep state) state time of the CPU and doing so trying to save juice. 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.
10: 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.
11: 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.
I/O Schedulers Explained
1: Noop:
Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.
Advantages:
Serves I/O requests with least number of cpu cycles. (Battery friendly?)
Best for flash drives since there is no seeking penalty.
Good throughput on db systems.
Disadvantages:
Reduction in number of cpu cycles used is proportional to drop in performance.
2: Deadline:
Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.
Advantages:
Nearly a real time scheduler.
Excels in reducing latency of any given single I/O.
Best scheduler for database access and queries.
Bandwidth requirement of a process - what percentage of CPU it needs, is easily calculated.
Like noop, a good scheduler for solid state/flash drives.
Disadvantages:
When system is overloaded, set of processes that may miss deadline is largely unpredictable.
3: CFQ:
Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.
Advantages:
Considered to deliver a balanced i/o performance.
Easiest to tune.
Excels on multiprocessor systems.
Best database system performance after deadline.
Disadvantages:
Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.
5: SIO:
Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.
Advantages:
Simple, so reliable.
Minimized starvation of requests.
Disadvantages:
Slow random-read speeds on flash drives, compared to other schedulers.
Sequential-read speeds on flash drives also not so good.
6: V(R):
Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request.
Advantages:
May be best for benchmarking because at the peak of it's 'form' VR performs best.
Disadvantages:
Performance fluctuation results in below-average performance at times.
Least reliable/most unstable.

Beats finding it in the other forum lol
Sent from my Paranoid SGH-T989

Kernel updated with badass. Can that be added? Is it battery oriented? I know it's a popular choice and I've used it but never knew why
Sent from my SGH-I727 using Tapatalk 2

kchen96 said:
Kernel updated with badass. Can that be added? Is it battery oriented? I know it's a popular choice and I've used it but never knew why
Sent from my SGH-I727 using Tapatalk 2
Click to expand...
Click to collapse
This is copied straight from InstigatorX's post.
Badass removes all of this "fast peaking" to the max frequency. On a typical system the cpu won't go above 1080Mhz and therefore use less power. To trigger a frequency increase, the system must run a bit @ 1080MHz with high load, then the frequency is bumped to 1350MHz. If that is still not enough the governor gives you full throttle. (this transition should not take longer than 2-5 seconds, depending on the load your system is experiencing).

jee'sgalaxy said:
Hey guys. Thanks to stealthware, -Grift- , and stempox for these information. However, I geared it so that it applies more to the SkyRocket users who has an AWESOME NEW KERNEL from DAGr8. I'm only relaying the information that applies to this kernel.
CPU Governors Explained:
THE USUAL GOVERNORS
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: 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).
3: Powersave Governor:
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
4: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.
5: 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: 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.
NOW THE OTHER AWESOME GOVERNORS
1: Badass
Badass removes all of this "fast peaking" to the max frequency. On a typical system the cpu won't go above 1080Mhz and therefore use less power. To trigger a frequency increase, the system must run a bit @ 1080MHz with high load, then the frequency is bumped to 1350MHz. If that is still not enough the governor gives you full throttle. (this transition should not take longer than 2-5 seconds, depending on the load your system is experiencing).
You can tweak the Phase 2 (1080MHz) and Phase 3 (1350MHz) via sysfs (if you don't know, then just leave it alone)
2: InteractiveX:
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.
3: 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.
4: 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.
5: 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.
6: 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.
7: Wheatley:
in short words this govenor is build on “ondemand” but increases the C4 state time of the CPU and doing so trying to save juice. 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.
8: 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.
9: 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.
I/O Schedulers Explained
1: Noop:
Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.
Advantages:
Serves I/O requests with least number of cpu cycles. (Battery friendly?)
Best for flash drives since there is no seeking penalty.
Good throughput on db systems.
Disadvantages:
Reduction in number of cpu cycles used is proportional to drop in performance.
2: Deadline:
Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.
Advantages:
Nearly a real time scheduler.
Excels in reducing latency of any given single I/O.
Best scheduler for database access and queries.
Bandwidth requirement of a process - what percentage of CPU it needs, is easily calculated.
Like noop, a good scheduler for solid state/flash drives.
Disadvantages:
When system is overloaded, set of processes that may miss deadline is largely unpredictable.
3: CFQ:
Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.
Advantages:
Considered to deliver a balanced i/o performance.
Easiest to tune.
Excels on multiprocessor systems.
Best database system performance after deadline.
Disadvantages:
Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.
5: SIO:
Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.
Advantages:
Simple, so reliable.
Minimized starvation of requests.
Disadvantages:
Slow random-read speeds on flash drives, compared to other schedulers.
Sequential-read speeds on flash drives also not so good.
6: V(R):
Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request.
Advantages:
May be best for benchmarking because at the peak of it's 'form' VR performs best.
Disadvantages:
Performance fluctuation results in below-average performance at times.
Least reliable/most unstable.
Click to expand...
Click to collapse
Thank alot for this info it really helped with my overheating,

crashpsycho said:
Thank alot for this info it really helped with my overheating,
Click to expand...
Click to collapse
Glad to have helped man!

Found some extra info you might want to add to the op here... http://forum.xda-developers.com/showthread.php?t=1767797
Sent from my SAMSUNG-SGH-I727 using Tapatalk 2

bps119 said:
Found some extra info you might want to add to the op here... http://forum.xda-developers.com/showthread.php?t=1767797
Sent from my SAMSUNG-SGH-I727 using Tapatalk 2
Click to expand...
Click to collapse
Thanks. Updated OP

What about 'row' scheduler?
First post ever!
What bout the row I/O scheduler? I saw it on every CM10.1 based ROM I tried.
Thank you.

Bleedos said:
First post ever!
What bout the row I/O scheduler? I saw it on every CM10.1 based ROM I tried.
Thank you.
Click to expand...
Click to collapse
Bit more information on different schedulers, including ROW:
http://forum.xda-developers.com/showthread.php?p=23885668

thnx alot maaan
thnx alot bro...
from the above list, can anyone suggest the best cpu settings, or the one you use now...

thx
thx alot
u really demonstrated all the info in a easy way
:good::good::good::good::good:

Super superb! Well done and thanks.

Great article! :good:
I also have Zen I/O Scheduler which is not explained in this thread!?

psydex said:
Great article! :good:
I also have Zen I/O Scheduler which is not explained in this thread!?
Click to expand...
Click to collapse
Look at my thread: http://forum.xda-developers.com/general/general/ref-to-date-guide-cpu-governors-o-t3048957

Good jobs!! Thanks alot

Thanks bro.
Sent from my SM-N910C using Tapatalk

CPU Governors and I/O Schedulers Explanation!!!

Hi friends I want to explain about: CPU Governors and I/O Schedulers...
Just Re Posting a thread found in ace forum.. May be useful..
CPU Governors:
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. 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).
3. Powersave Governor:
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
4. 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.
5. 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.
6. Min Max
Well this governor makes use of only min & maximum frequency based on workload... no intermediate frequencies are used.
7. 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.
8. InteractiveX Governor:
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.
9. 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.
10. 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.
11. 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
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.
13. Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery
14. SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
15. 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.
16. 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.
I/O Schedulers:
1) Noop
Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.
Advantages:
Serves I/O requests with least number of cpu cycles. (Battery friendly?)
Best for flash drives since there is no seeking penalty.
Good throughput on db systems.
Disadvantages:
Reduction in number of cpu cycles used is proportional to drop in performance.
2) Deadline
Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.
Advantages:
Nearly a real time scheduler.
Excels in reducing latency of any given single I/O.
Best scheduler for database access and queries.
Bandwidth requirement of a process - what percentage of CPU it needs, is easily calculated.
Like noop, a good scheduler for solid state/flash drives.
Disadvantages:
When system is overloaded, set of processes that may miss deadline is largely unpredictable.
3) CFQ
Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.
Advantages:
Considered to deliver a balanced i/o performance.
Easiest to tune.
Excels on multiprocessor systems.
Best database system performance after deadline.
Disadvantages:
Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.
5) SIO
Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.
Advantages:
Simple, so reliable.
Minimized starvation of requests.
Disadvantages:
Slow random-read speeds on flash drives, compared to other schedulers.
Sequential-read speeds on flash drives also not so good.
6) V(R)
Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request.
Advantages:
May be best for benchmarking because at the peak of it's 'form' VR performs best.
Disadvantages:
Performance fluctuation results in below-average performance at times.
Least reliable/most unstable. :good:

Hey thanx a lot for this usefully thread..
can u tell me which CPU Governors and I/O Schedulers are good amongst these all to set? i am using Official CM7.

Rohit02 said:
Hey thanx a lot for this usefully thread..
can u tell me which CPU Governors and I/O Schedulers are good amongst these all to set? i am using Official CM7.
Click to expand...
Click to collapse
That depends on ur kernel Pal....:highfive:
Mention it...will try......

nightwing90 said:
That depends on ur kernel Pal....:highfive:
Mention it...will try......
Click to expand...
Click to collapse
Kernel version : 2.6.35.14_CM+Tjstyle
Baseband : DDKQ5
:good:

thank you,helped me so much

[INFO] ***Kernel 101***

If you spend any time reading Android forums, blogs, how-to posts or online discussion you'll soon hear people talking about the kernel. A kernel isn't something unique to Android -- iOS and MacOS have one, Windows has one, BlackBerry's QNX has one, in fact all high level operating systems have one. The one we're interested in is Linux, as it's the one Android uses. Let's try to break down what it is and what it does.
Android devices use the Linux kernel, but it's not the exact same kernel other Linux-based operating systems use. There's a lot of Android specific code built in, and Google's Android kernel maintainers have their work cut out for them. OEMs have to contribute as well, because they need to develop hardware drivers for the parts they're using for the kernel version they're using. This is why it takes a while for independent Android developers and hackers to port new versions to older devices and get everything working. Drivers written to work with the Gingerbread kernel on a phone won't necessarily work with the Ice Cream Sandwich kernel. And that's important, because one of the kernel's main functions is to control the hardware. It's a whole lot of source code, with more options while building it than you can imagine, but in the end it's just the intermediary between the hardware and the software.
When software needs the hardware to do anything, it sends a request to the kernel. And when we say anything, we mean anything. From the brightness of the screen, to the volume level, to initiating a call through the radio, even what's drawn on the display is ultimately controlled by the kernel. For example -- when you tap the search button on your phone, you tell the software to open the search application. What happens is that you touched a certain point on the digitizer, which tells the software that you've touched the screen at those coordinates. The software knows that when that particular spot is touched, the search dialog is supposed to open. The kernel is what tells the digitizer to look (or listen, events are "listened" for) for touches, helps figure out where you touched, and tells the system you touched it. In turn, when the system receives a touch event at a specific point from the kernel (through the driver) it knows what to draw on your screen. Both the hardware and the software communicate both ways with the kernel, and that's how your phone knows when to do something. Input from one side is sent as output to the other, whether it's you playing Angry Birds, or connecting to your car's Bluetooth.
It sounds complicated, and it is. But it's also pretty standard computer logic -- there's an action of some sort generated for every event. Without the kernel to accept and send information, developers would have to write code for every single event for every single piece of hardware in your device. With the kernel, all they have to do is communicate with it through the Android system API's, and hardware developers only have to make the device hardware communicate with the kernel. The good thing is that you don't need to know exactly how or why the kernel does what it does, just understanding that it's the go-between from software to hardware gives you a pretty good grasp of what's happening under the glass.

Governors
Kernel Governers
1) Ondemand
2) Ondemandx
3) Conservative
4) Interactive
5) Interactivex
6) Lulzactive
7) Lulzactiveq
8) Smartass
9) SmartassV2
10) Intellidemand
11) Lazy
12) Lagfree
13) Lionheart
14) LionheartX
15) Brazilianwax
16) SavagedZen
17) Userspacce
18) Powersave
19) Performance
1) Ondemand:
Default governor in almost all stock kernels. One main goal of the ondemand governor is to switch to max frequency as soon as there is a CPU activity detected to ensure the responsiveness of the system. (You can change this behavior using smooth scaling parameters, refer Siyah tweaks at the end of 3rd post.) Effectively, it uses the CPU busy time as the answer to "how critical is performance right now" question. So Ondemand jumps to maximum frequency when CPU is busy and decreases the frequency gradually when CPU is less loaded/apporaching idle. Even though many of us consider this a reliable governor, it falls short on battery saving and performance on default settings. One potential reason for ondemand governor being not very power efficient is that the governor decide the next target frequency by instant requirement during sampling interval. The instant requirement can response quickly to workload change, but it does not usually reflect workload real CPU usage requirement in a small longer time and it possibly causes frequently change between highest and lowest frequency.
Click to expand...
Click to collapse
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.
Click to expand...
Click to collapse
3) Conservative:
A slower Ondemand which scales up slowly to save battery. The conservative governor is based on the ondemand governor. It functions like the Ondemand governor by dynamically adjusting frequencies based on processor utilization. However, the conservative governor increases and decreases CPU speed more gradually. Simply put, this governor increases the frequency step by step on CPU load and jumps to lowest frequency on CPU idle. Conservative governor aims to dynamically adjust the CPU frequency to current utilization, without jumping to max frequency. The sampling_down_factor value acts as a negative multiplier of sampling_rate to reduce the frequency that the scheduler samples the CPU utilization. For example, if sampling_rate equal to 20,000 and sampling_down_factor is 2, the governor samples the CPU utilization every 40,000 microseconds.
Click to expand...
Click to collapse
4) Interactive:
Can be considered a faster ondemand. So more snappier, less battery. Interactive is designed for latency-sensitive, interactive workloads. Instead of sampling at every interval like ondemand, it determines how to scale up when CPU comes out of idle. The governor has the following advantages: 1) More consistent ramping, because existing governors do their CPU load sampling in a workqueue context, but interactive governor does this in a timer context, which gives more consistent CPU load sampling. 2) Higher priority for CPU frequency increase, thus giving the remaining tasks the CPU performance benefit, unlike existing governors which schedule ramp-up work to occur after your performance starved tasks have completed. Interactive It's an intelligent Ondemand because of stability optimizations. Why??
Sampling the CPU load every X ms (like Ondemand) can lead to under-powering the CPU for X ms, leading to dropped frames, stuttering UI, etc. Instead of sampling the CPU at a specified rate, the interactive governor will check whether to scale the CPU frequency up soon after coming out of idle. When the CPU comes out of idle, a timer is configured to fire within 1-2 ticks. If the CPU is very busy between exiting idle and when the timer fires, then we assume the CPU is underpowered and ramp to max frequency.
Click to expand...
Click to collapse
5) Interactivex:
This is an Interactive governor with a wake profile. More battery friendly than interactive.
Click to expand...
Click to collapse
6) 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.
Click to expand...
Click to collapse
7) Lulzactiveq:
Lulzactiveq is a modified lulzactive governor authored by XDA member robertobsc and is adapted in Siyah kernel for GS2 and GS3. Lulzactiveq aims to optimize the second version of luzactive from Tegrak by a) providing an extra parameter (dec_cpu_load) to make scaling down more sensible, and b) incorporating hotplug logic to the governor. Luzactiveq is the first ever interactive based governor with hotplugging logic inbuilt (atleast the first of its kind for the exynos platform). When CPU comes out of idle loop and it's time to make a scaling decision, if load >= inc_cpu_load CPU is scaled up (like original luzactiveq) and if load <dec_cpu_load, CPU is scaled down. This possibly eliminates the strict single cut-off frequency for luzactiveq to make CPU scaling decisions. Also, stand hotplug logic runs as a separate thread with the governor so that external hotplugging logic is not required to control hotplug in and out (turn On and Off) CPU cores in multi core devices like GS2 or GS3. Only a multi core aware governor makes real sense on muti-core devices. Lulzactiveq and pegasusq aims to do that.
Click to expand...
Click to collapse
8) Smartass:
Result of Erasmux rewriting the complete code of interactive governor. Main goal is to optimize battery life without comprising performance. Still, not as battery friendly as smartassV2 since screen-on minimum frequency is greater than frequencies used during screen-off. Smartass would jump up to highest frequency too often as well.
Click to expand...
Click to collapse
9) 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.
Click to expand...
Click to collapse
10) 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.
Click to expand...
Click to collapse
11) 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.
Click to expand...
Click to collapse
12) 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.
Click to expand...
Click to collapse
13) Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source. Tweaks comes from 1) Knzo 2) Morfic. The original idea comes from Netarchy. See here. 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.
To 'experience' Lionheart using conservative, try these tweaks:
sampling_rate:10000 or 20000 or 50000, whichever you feel is safer. (transition latency of the CPU is something below 10ms/10,000uS hence using 10,000 might not be safe).
up_threshold:60
down_threshold:30
freq_step:5
Lionheart goes well with deadline i/o scheduler. When it comes to smoothness (not considering battery drain), a tuned conservative delivers more as compared to a tuned ondemand.
Click to expand...
Click to collapse
14) LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
Click to expand...
Click to collapse
15) Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery.
Click to expand...
Click to collapse
16) SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
Click to expand...
Click to collapse
17) Userspace:
Instead of automatically determining frequencies, lets user set frequencies.
Click to expand...
Click to collapse
18) Powersave:
Locks max frequency to min frequency. Can not be used as a screen-on or even screen-off (if scaling min frequency is too low).
Click to expand...
Click to collapse
19) Performance:
Sets min frequency as max frequency.
2. I/O SCHEDULERS
Q. "What purposes does an i/o scheduler serve?" A.
Minimize hard disk seek latency.
Prioritize I/O requests from processes.
Allocate disk bandwidth for running processes.
Guarantee that certain requests will be served before a deadline.
So in the simplest of simplest form: Kernel controls the disk access using I/O Scheduler.
Q. "What goals every I/O scheduler tries to balance?" A.
Fairness (let every process have its share of the access to disk)
Performance (try to serve requests close to current disk head position first, because seeking there is fastest)
Real-time (guarantee that a request is serviced in a given time)
Q. "Description, advantages, disadvantages of each I/O Scheduler?" A.
1) Noop
Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.
Advantages:
Serves I/O requests with least number of cpu cycles. (Battery friendly?)
Best for flash drives since there is no seeking penalty.
Good throughput on db systems.
Disadvantages:
Reduction in number of cpu cycles used is proportional to drop in performance.
2) Deadline
Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.
Advantages:
Nearly a real time scheduler.
Excels in reducing latency of any given single I/O.
Best scheduler for database access and queries.
Bandwidth requirement of a process - what percentage of CPU it needs, is easily calculated.
Like noop, a good scheduler for solid state/flash drives.
Disadvantages:
When system is overloaded, set of processes that may miss deadline is largely unpredictable.
3) CFQ
Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.
Advantages:
Considered to deliver a balanced i/o performance.
Easiest to tune.
Excels on multiprocessor systems.
Best database system performance after deadline.
Disadvantages:
Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.
4) BFQ
Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.
Advantages:
Believed to be very good for usb data transfer rate.
Believed to be the best scheduler for HD video recording and video streaming. (because of less jitter as compared to CFQ and others)
Considered an accurate i/o scheduler.
Achieves about 30% more throughput than CFQ on most workloads.
Disadvantages:
Not the best scheduler for benchmarking.
Higher budget assigned to a process can affect interactivity and increased latency.
5) SIO
Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.
Advantages:
Simple, so reliable.
Minimized starvation of requests.
Disadvantages:
Slow random-read speeds on flash drives, compared to other schedulers.
Sequential-read speeds on flash drives also not so good.
6)
V(R)
Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request.
Advantages:
May be best for benchmarking because at the peak of it's 'form' VR performs best.
Disadvantages:
Performance fluctuation results in below-average performance at times.
Least reliable/most unstable.
Q. "Best I/O Scheduler?"
A.There is nothing called "best" i/o scheduler. Depending on your usage environment and tasks/apps been run, use different schedulers. That's the best i can suggest.
However, considering the overall performance, battery, reliability and low latency, it is believed that
SIO > Noop > Deadline > VR > BFQ > CFQ, given all schedulers are tweaked and the storage used is a flash device.
Credits
Internet
This thread http://forum.xda-developers.com/showthread.php?t=1369817

Nice info dude.......
Sent from my GT-I9100 using xda premium

Brilliant work buddy!!

Thanks
Started from the bottom

So, what next..??
BTW, you must made a Thread in General section of android. Containing all links of your work.:highfive:

Disturbed™ said:
So, what next..??
BTW, you must made a Thread in General section of android. Containing all links of your work.:highfive:
Click to expand...
Click to collapse
Guys, you all have made me Tha TechnoCrat from kartiknnn. I am forever indebted to you all. Especially vikesh. My elder brother.
:thumbup:
Started from the bottom

Nice write up
TEAM MiK
MikROMs Since 3/13/11

Good Work Buddy... :good:

Some useful Info about Android Kernel Governors and I/O SCHEDULERS

Hi Guys,
Now that we have multiple number of Custom Kernels its good to know about what kind of benefits we can get from the available Governors & I/O Schedulers
After googling for a while I found some good info which I am sharing with you Guys
1. Kernel Governors
These are the 19 governors we’re talking about.
1) Ondemand
2) Conservative
3) Interactivex
4) Smartass
5) SmartassV2
6) Lagfree
7) Brazilianwax
8) SavagedZen
9) Userspacce
10) Powersave
11) Performance
12)Minmax
13)Scary
14)Lulzactive
15)intellidemand
16)badass
17)Lionheart
18)Lionheartx
19)Virtuous
1) 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
2) Conservative:
A slower Ondemand which scales up slowly to save battery. 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.
3) Interactivex:
This is an Interactive governor with a wake profile. More battery friendly than interactive.
4) Smartass:
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.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
5) SmartassV2:
SmartassV2 is a governor (controls the frequency of the CPU at each give moment) which like the first smartass is generally based on the implementation of interactive with some major changes and the addition of a built in sleep profile (behaves a bit differently when screen is off vs. on).The smartassV2 improves the very naive scheme which the first smartass had
6) 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.
7) Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery.
8) SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
9) Userspace:
Instead of automatically determining frequencies, lets user set frequencies.
10) Powersave:
runs minimum speed all the time (good for low battery/high temp situations)
11) Performance:
Top speed all the time(better for benchmarking/speed test)
12)Minmax
stays at minimum speed until more speed is needed then goes straight to highest speed
13)Scary
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.
14) 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.
15) 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.
16)badass
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 2-5 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.
17)Lionheart
Lionheart is a conservative-based governor which is based on samsung’s update3 source. Tweaks comes from 1) Knzo 2) Morfic. The original idea comes from Netarchy. See here. 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.
To ‘experience’ Lionheart using conservative, try these tweaks: sampling_rate:10000 or 20000 or 50000, whichever you feel is safer. (transition latency of the CPU is something below 10ms/10,000uS hence using 10,000 might not be safe). up_threshold:60 down_threshold:30 freq_step:5 Lionheart goes well with deadline i/o scheduler. When it comes to smoothness (not considering battery drain), a tuned conservative delivers more as compared to a tuned ondemand.
18)Lionheartx
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
19)virtuous governor
It set your max cpu for wake and sleep and changes the governor when your device is awake or asleep. It saves battery by lowering cpu frequencys while the device sleeps, when it awakes it automatically speeds it up again. Or alternately you can set the cpu.It is based on smartassV2(It use 2 governors.one for sleep and other for awake)
Governor which is for performance and battery life-smartassV2(To get maximum performance, use ondemand or conservative)
2. I/O SCHEDULERS
Q. “What purposes does an i/o scheduler serve?”
A.
 Minimize hard disk seek latency.
 Prioritize I/O requests from processes.
 Allocate disk bandwidth for running processes.
 Guarantee that certain requests will be served before a deadline.
So in the simplest of simplest form: Kernel controls the disk access using I/O Scheduler.
Q. “What goals every I/O scheduler tries to balance?”
A.
 Fairness (let every process have its share of the access to disk)
 Performance (try to serve requests close to current disk head position first, because seeking there is fastest)
 Real-time (guarantee that a request is serviced in a given time)
Q. “Description, advantages, disadvantages of each I/O Scheduler?”
A.
1) Noop
Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.
Advantages:
 Serves I/O requests with least number of cpu cycles. (Battery friendly?)
 Best for flash drives since there is no seeking penalty.
 Good throughput on db systems.
Disadvantages:
 Reduction in number of cpu cycles used is proportional to drop in performance.
2) Deadline
Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.
Advantages:
 Nearly a real time scheduler.
 Excels in reducing latency of any given single I/O.
 Best scheduler for database access and queries.
 Bandwidth requirement of a process – what percentage of CPU it needs, is easily calculated.
 Like noop, a good scheduler for solid state/flash drives.
Disadvantages:
 When system is overloaded, set of processes that may miss deadline is largely unpredictable.
3) CFQ
Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the ‘parent’ process. V2 of CFQ has some fixes which solves process’ i/o starvation and some small backward seeks in the hope of improving responsiveness.
Advantages:
 Considered to deliver a balanced i/o performance.
 Easiest to tune.
 Excels on multiprocessor systems.
 Best database system performance after deadline.
Disadvantages:
 Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
 Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.
4) BFQ
Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it’s budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it’s behavior.
Advantages:
 Believed to be very good for usb data transfer rate.
 Believed to be the best scheduler for HD video recording and video streaming. (because of less jitter as compared to CFQ and others)
 Considered an accurate i/o scheduler.
 Achieves about 30% more throughput than CFQ on most workloads.
Disadvantages:
 Not the best scheduler for benchmarking.
 Higher budget assigned to a process can affect interactivity and increased latency.
5) SIO
Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.
Advantages:
 Simple, so reliable.
 Minimized starvation of requests.
Disadvantages:
 Slow random-read speeds on flash drives, compared to other schedulers.
 Sequential-read speeds on flash drives also not so good.
6) V(R)
Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it’s distance from last request.
Advantages:
 May be best for benchmarking because at the peak of it’s ‘form’ VR performs best.
Disadvantages:
 Performance fluctuation results in below-average performance at times.
 Least reliable/most unstable.
Q. “Best I/O Scheduler?”
A.There is nothing called “best” i/o scheduler. Depending on your usage environment and tasks/apps been run, use different schedulers. That’s the best i can suggest.
However, considering the overall performance, battery, reliability and low latency, it is believed that
SIO > Noop > Deadline > VR > BFQ > CFQ, given all schedulers are tweaked and the storage used is a flash device.

At least give proper credits To "Original OP"
And btw Nice thread. It is a useful one

icoolguy1995 said:
At least give proper credits To "Original OP"
And btw Nice thread. It is a useful one
Click to expand...
Click to collapse
I agree with you Bro, but could'nt find proper credits, it was just a page on google mate

OP by @droidphile :
http://forum.xda-developers.com/showthread.php?t=1369817&styleid=16
Sent from my Micromax A110 using xda app-developers app

Thanks
Thanks for posting it here. But i guess it would mean a lot if it will all work in custom kernels. :victory:
The new custom kernels in original dev have issues.

click.here said:
Thanks for posting it here. But i guess it would mean a lot if it will all work in custom kernels. :victory:
The new custom kernels in original dev have issues.
Click to expand...
Click to collapse
Our Developers are working hard to get close to perfection.
As we all know intially all we had were huge amount of Custom Themed Roms (Ofcourse it takes good amount of time & hard work to create a Themed Rom too) but as time passed by there has been a great development & I am sure our dear Developers will keep working at their best to give us the best.
Patience Pays
Thanks to all the Developers :good::good::good:

@Amit_timA
Ask moderators to stick this thread.

[KERNEL][5.1.1][TW][N910C] Simplicity Kernel v1.3 [04-04-2016][CUSTOM]

Welcome to Simplicity Kernel thread!
Samsung Galaxy Note 4 SM-N910C
N910CXXU1COI4 TW 5.1.1
{
"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"
}
Simpl, where Performance, Speed, Stability and Battery life have no limits.
THREAD INDEX:
I. INTRODUCTION
II. FEATURES
III. DOWNLOADS
IV. CREDITS
Second Post. Some Kernel Knowledge
Third Post. FAQ & CHANGELOG
#_____________________________#​
Code:
#include <std_disclaimer.h>
/*
* Your warranty is now void.
*
* I am not responsible for any bricked devices, dead SD cards,
* or any kind of damage to your phone whether soft or hard brick
*/
I. INTRODUCTION
Simplicity Kernel, Provides a great balance between performance and battery consumption. I have created 2 Editions of the Kernel, in order to satisfy most users.
Simplicity SimplEdition.
Simplicity UltimatEdition.
Simplicity SimplEdition
This Edition is for those who want the kernel to work great right out of the box. It's for those who don't want to tune the kernel, but instead, they want it working perfectly right after flashing it, Simpl as that. It can be controlled through kernel Auditor.
Simplicity UltimatEdition
This Edition is for those who like to draw the lines and cross the edges with their phones. It is for those who love to switch between one option to another, for those who want their phones highly customizable with a great administrative access.
It can be controlled through Synapse.
Both Kernels are the same but UltimatEdition has some extra more features.
II. FEATURES
Common Features:
These are the common features for both Editions.
Based on N910CXXU1COI4 Samsung Lollipop Source.
Patched to latest Linux 3.10.98.
CPU Voltage control (+/- 100 mV).
CPU Clock control.
(A53: 200MHz Up to 1800MHz / A57: 500MHz Up to 2100 Mhz)
Wolfson sound engine.
SELinux set to permissive.
TCP congestion controls.
(Westwood, reno, bic, cubic, highspeed hybla, htcp, vegas, veno, scalable, lp, yeah, illinois)
gentle fair sleepers switchable.
Fixed Google Play Services battery drain.
USB OTG Support.
CIFS Support.
KSM Support.
Reduced Wlan Wakelocks.
switchable logger.
Switchable init.d execution.
Fixed memory leaks.
Enabled NTFS R/W support.
Improved overall performance.
higher battery optimization.
low Memory Killer tuners.
Schedulers.
(Zen, Fifo, V(R), FIOPS, SIO, BFQ, ROW, DEADLINE)
CPU Governors.
(smartmax, bluactive, intelliactive, smartassV2, interactive_pro, adaptive, alucard, bioshock, conservative, conservativex, dancedance, darkness, interllidemand, intellimm, lionheart, nightmare, ondemand (modified), ondemandplus, powersave, umbrella_core, userspace, wheatley, yankactive, Preservative)
Simplicity UltimatEdition Extra Features
Full GPU Control.
GPU Voltage control (+/- 100 mV)
GPU Clock control (200MHz Up to 800MHz)
GPU Thermal throttling control
LED Control.
HMP Threshold ratio control.
Input Booster.
SimplTweaks Control.
Memory Control.
Battery Control.
Adaptive low memory killer.
KSM Control.
ARK Power Control.
SimplDVFS Disabler.
Google Play Services Battery Drain Control.
Wakelock Control
(Wlan_rx, Wlan_ctrl, SensorHub, SSP, Motion Sensor, temperature humidity sensor, proximity, bcm4773 GPS)
Power Suspend
Full Headphone and Speaker Control.
LCD Power Control.
Sweep2Sleep.
MDNIE Settings.
Nertwork Control.
SimplFirewall.
USB Mode Control (DriveDroid).
SimplBattery Calibration.
Fuel Gauge Calibration (by UpInTheAir).
File System Control.
SimplCleaner.
SYSCTL (FS, Kernel, NET, VM)
III. DOWNLOAD
Warning before you download: Some users have reported a loss of data (apps), after flashing UltimatEdition v1.2.
Flash at your own risk, until I fix this issue.
Download Link - AFH
Download Link - Google Drive
IV. CREDITS
Special thanks to my amazing testers, without whom, this wouldn't be possible: (random order):
@nsidd
@phil.o
@randykzc
Special thanks to all the great developers, who inspired me to cherry-pick from such as UpInTheAir, AndreiLux, halaszk88 and others (credits in github), and I'd like to specially thank those who supported me directly, in particular Pafcholini and djmax81.
:good: Enjoy and feedback is always appreciated :good:​
-
XDA:DevDB Information
Simplicity, Kernel for the Samsung Galaxy Note 4
Contributors
Hani K.
Source Code: https://github.com/Hani-K
Kernel Special Features:
Version Information
Status: Stable
Current Stable Version: 1
Stable Release Date: 2016-03-13
Created 2016-03-13
Last Updated 2016-04-04

Some Kernel Knowledge
These are some kernel concepts that will help you customize your kernel.
What is HMP?
The load_avg_period_ms period is the time in ms to go from 0 to 0.5 load average while running or the time from 1 to 0.5 while sleeping. For examples, with load_avg_period_ms = 128 and up_threshold = 512, a running task will migrate to a bigger CPU after 128ms, because after 128ms its load_avg_ratio is 0.5 and which matches the up_threshold is 0.5.
What the hell? ok, I will re-explain the example..
Now, let's suppose you have set the up_threshold = 512.
Now as I told you before the value of the threshold is divided by 1024. This means, 512/1024= 0.5
which means that.. when the load average reaches to 0.5, the CPU will migrate this task to a higher cluster.
the UP Threshold migrate the task to a higher core. The Down Threshold migrate the task to a slower core.
by increasing the value, you're increasing the delay in that process.
What is a CPU governor?
A CPU governor in Android controls how the CPU raises and lowers its frequency in response to the demands the user is placing on their device. Governors are especially important in smartphones and tablets because they have a large impact on the apparent fluidity of the interface and the battery life of the device over a charge.
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.
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.
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).
Powersave Governor:
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
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.
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.
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.
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.
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.
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.
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.
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.
IntelliActive:
Based off Google's Interactive governor with the following enhancements:
self-boost capability from input drivers. (no need for PowerHAL assist)
two phase scheduling (idle/busy phases to prevent from jumping directly to max freq.
Checks for offline cpus and short circuits some unnecessary checks to improve code execution paths. Therefore, it avoids CPU hotplugging.
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.
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.
OnDemandPlus
A governor based off of OnDemand and Interactive. It provides a balance between performance, and saving battery.
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!
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 will give the same performance as conservative right now, it will get tweaked over time.
Min Max
well this governor makes use of only min & maximum frequency based on workload... no intermediate frequencies are used.
IntelliMM
A rewrite of the old Min Max governor and has 3 cpu states: Idle, UI and Max. Pretty much a smarter Min Max governor.
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.
Yankactive
A slightly modified interactive based governor by Yank555.lu. Possibly better performance or battery life.
What is I/O Scheduler
I/O: short form of Input & Output
I/O Scheduler: Input/output (I/O) scheduling is a term used to describe the method computer operating systems decide the order that block I/O operations will be submitted to storage volumes. I/O Scheduling is sometimes called disk scheduling.
I/O schedulers can have many purposes depending on the goal of the I/O scheduler, some common goals are:
To minimize time wasted by hard disk seeks.
To prioritize a certain processes’ I/O requests.
To give a share of the disk bandwidth to each running process.
To guarantee that certain requests will be issued before a particular deadline.
ROW
ROW stands for READ Over WRITE which is the main requests dispatch policy of this algorithm. The ROW IO scheduler was developed with the mobile devices needs in mind. In mobile devices we favor user experience upon everything else, thus we want to give READ IO requests as much priority as possible. In mobile devices we won’t have as much parallel threads as on desktops. Usually it’s a single thread or at most 2 simultaneous working threads for read & write. Favoring READ requests over WRITEs decreases the READ latency greatly.
The main idea of the ROW scheduling policy is: If there are READ requests in pipe – dispatch them but don’t starve the WRITE requests too much. Bellow you’ll find a small comparison of ROW to existing schedulers. The test that was run for these measurements is parallel read and write.
FIOS
Flash-based solid-state drives (SSDs) have the potential to eliminate the I/O bottlenecks in data-intensive applications However the large performance discrepancy between Flash reads and writes introduces challenges for fair resource usage. Further, existing fair queuing and quanta-based I/O schedulers poorly manage the I/O anticipation for Flash I/O fairness and efficiency. Some also suppress the I/O parallelism which causes substantial performance degradation on Flash. This paper develops FIOS, a new Flash I/O scheduler that attains fairness and high efficiency at the same time. FIOS employs a fair I/O time-slice management with mechanisms for read preference, parallelism, and fairness-oriented I/O anticipation. Evaluation demonstrates that FIOS achieves substantially better fairness and efficiency compared to the Linux CFQ scheduler, the SFQ(D) fair queuing scheduler, and the Argon quanta-based scheduler on several Flash-based storage devices (including a CompactFlash card in a low-power wimpy node). In particular, FIOS reduces the worst-case slowdown bya factor of 2.3 or more when the read-only SPECweb workload runs together with the write-intensive TPC-C.
SIO
SIO scheduler is based on the deadline scheduler but it’s more like a mix between no-op and deadline.In other words, SIO is like a lighter version of deadline but it doesn’t do any kind of sorting, so it’s aimed mainly for random-access devices (like SSD hard disks) where request sorting is no needed (as any sector can be accesed in a constant time, regardless of its physical location).
NOOP
The NOOP scheduler inserts all incoming I/O requests into a simple, unordered FIFO queue and implements request merging.
The scheduler assumes I/O performance optimization will be handled at some other layer of the I/O hierarchy; e.g., at the block device; by an intelligent HBA such as a Serial Attached SCSI (SAS) RAID controller or by an externally attached controller such as a storage subsystem accessed through a switched Storage Area Network.
CFQ
CFQ, also known as Completely Fair Queuing, is an I/O scheduler for the Linux kernel which was written in 2003 by Jens Axboe.
CFQ works by placing synchronous requests submitted by processes into a number of per-process queues and then allocating timeslices for each of the queues to access the disk. The length of the time slice and the number of requests a queue is allowed to submit depends on the IO priority of the given process. Asynchronous requests for all processes are batched together in fewer queues, one per priority.
DEADLINE
The goal of the Deadline scheduler is to attempt to guarantee a start service time for a request. It does that by imposing a deadline on all I/O operations to prevent starvation of requests. It also maintains two deadline queues, in addition to the sorted queues (both read and write). Deadline queues are basically sorted by their deadline (the expiration time), while the sorted queues are sorted by the sector number.
Before serving the next request, the Deadline scheduler decides which queue to use. Read queues are given a higher priority, because processes usually block on read operations. Next, the Deadline scheduler checks if the first request in the deadline queue has expired. Otherwise, the scheduler serves a batch of requests from the sorted queue. In both cases, the scheduler also serves a batch of requests following the chosen request in the sorted queue.
V(R)
The next request is decided based on its distance from the last request, with a multiplicative penalty of rev_penalty applied for reversing the head direction. A rev_penalty of 1 means SSTF behaviour. As this variable is increased, the algorithm approaches pure SCAN. Setting rev_penalty to 0 forces SCAN.
BFQ
BFQ is a proportional share disk scheduling algorithm based on the slice-by-slice service scheme of CFQ. But BFQ assigns budgets, measured in number of sectors, to tasks instead of time slices. The disk is not granted to the active task for a given time slice, but until it has exahusted its assigned budget. This change from the time to the service domain allows BFQ to distribute the disk bandwidth among tasks as desired, without any distortion due to ZBR, workload fluctuations or other factors. BFQ uses an ad hoc internal scheduler, called B-WF2Q , to schedule tasks according to their budgets. Thanks to this accurate scheduler, BFQ can afford to assign high budgets to disk-bound non-seeky tasks (to boost the throughput), and yet guarantee low latencies to interactive and soft real-time applications.
Sources: Governors, Schedulers.

FAQ & ChangeLog
FAQ:
I took a backup but I cannot see it?
Press on restart Synapse.
I went to restore my backup but its showing "None". Where are my backups?
Take a backup, click on restart Synapse, and there you go.
How do I use someone else's backup?
Copy it to your internal storage in Simplicity kernel folder.
/storage/emulated/0/SimplicityKernel/Synapse/saved_profiles.
Installed BusyBox, and now Synapse shows no UCI?
Updating BusyBox removes UCI file from xbin folder in the ROM. Flash UCI Fixer from tools folder.
I want to flash some other kernel, but some leftover files stay after flashing another kernel?
Flash Synapse Remover from tools folder.
When I take a logcat, the file turns out to be empty?
Set Android Logger to Auto.
How to remount EXT4 with noauto_da_alloc?
Flash EXT4 Remount from Tools folder.
I cannot access AFH download link from my phone?
This is a Server/DNS problem. Change you phone's DNS to Google's.
Changelog:
v1.3 - 04/04/2016
Patched upto 3.10.101.
Optimized Kernel Flags.
Compiled and added kernel's own dt.img.
Modified the Ramdisk to fit SeLinux, with correct permissions.
Added Root Access to the kernel.
Updated Busybox to the latest version
Remounted all system, Data and cache the stock way.
Added a custom option for EXT4 remount in FS. (Default: Disabled).
FS Trim Fixed.
Hotspot issue fixed. (NET SYSCTL)
Fixed Apps coming back after a reboot. (Still need your confirmation).
Added Wifi passwords backup.
Re-optimized All system permissions.
Micro-Optimized HMP with extra features.
Fixed Min Frequency Stick issue.
Added Touch to input boost.
Added interextrem governor.
Enabled SimplBattery Tweaks by default.
Optimized and improved power efficiency.
Optimized IO.
v1.2 - 17/03/2016
Fixed remount /system issue on both Editions.
Fixed min/max GPU default levels (160-600).
Improved battery optimization.
Re-Adjusted Wolfson sound engine for better sound.
Fixed Min/Max CPU Frequency issue.
Changed CPU Core Control into Exynos A57 Core Control for better control.
Added SD-card Scheduler and Read-Ahead Control.
Included Base optimization values for Stock users.
Increased Charging Speed (slightly).
15/03/2016
Fixed Google Play issue in SimplEdition.
14/03/2016
Updated Busybox to the latest version.
Fixed Google Play Store issue. (Can't install apps)
Fixed IPv6 Protocol issue in Simpl-Firewall.
Fixed Logs saving location.

First! Thank U! i'll test this
Why not Synapse-based? oh i get it

Wooow! Loving this UltimatEdition kernel installed here! Thanks for your great work <3

Hi hani.... i try this now... but i wanna say something... i want use this kernel with simple v6

suat6027 said:
Hi hani.... i try this now... but i wanna say something... i want use this kernel with simple v6
Click to expand...
Click to collapse
We are month away from MM wait...

Thanks for your wonderful kernel with lots of customizations on ultimate edition! Already using it since half hour! smooth and good battery Sir!

Happy to know that you like it guys.
Will keep updating the kernel as soon as possible.

hi
can i use this kernel with DN5 or sixprince6 ?

@Hani K. Good job mate

djmax81 said:
@Hani K. Good job mate
Click to expand...
Click to collapse
Thanks a lot mate
I appreciate your continuous support

aref_sh said:
hi
can i use this kernel with DN5 or sixprince6 ?
Click to expand...
Click to collapse
Yes

SGOD said:
Thanks for your wonderful kernel with lots of customizations on ultimate edition! Already using it since half hour! smooth and good battery Sir!
Click to expand...
Click to collapse
Hani K. said:
Happy to know that you like it guys.
Will keep updating the kernel as soon as possible.
Click to expand...
Click to collapse
@Hani K. Phone doesnt go in deep sleep.. should I give it a more time?

SGOD said:
@Hani K. Phone doesnt go in deep sleep.. should I give it a more time?
Click to expand...
Click to collapse
First. If you have flashed 20 minutes ago. Then give your battery sometime to settle down.
Second. If you have flashed the UltimatEdition, you need to tune the kernel through Synapse the way you need it to be. This is the main reason I included a SimplEdition. So you get good battery stats as soon as you flash it.
Third. I have included a different ways to help calibrate the batter, and I have actually mentioned on many instances if a setting helps optimizing the battery or not.
Fourth. I will upload a Battery profile tomorrow, to make it easier for you to tune it. So you can also learn from my settings how to set yours.
Powered by SimplTeam

Hani K. said:
First. If you have flashed 20 minutes ago. Then give your battery sometime to settle down.
Second. If you have flashed the UltimatEdition, you need to tune the kernel through Synapse the way you need it to be. This is the main reason I included a SimplEdition. So you get good battery stats as soon as you flash it.
Third. I have included a different ways to help calibrate the batter, and I have actually mentioned on many instances if a setting helps optimizing the battery or not.
Fourth. I will upload a Battery profile tomorrow, to make it easier for you to tune it. So you can also learn from my settings how to set yours.
Powered by SimplTeam
Click to expand...
Click to collapse
Thanks a lot! Ill give it a time..

Hani K. said:
First. If you have flashed 20 minutes ago. Then give your battery sometime to settle down.
Second. If you have flashed the UltimatEdition, you need to tune the kernel through Synapse the way you need it to be. This is the main reason I included a SimplEdition. So you get good battery stats as soon as you flash it.
Third. I have included a different ways to help calibrate the batter, and I have actually mentioned on many instances if a setting helps optimizing the battery or not.
Fourth. I will upload a Battery profile tomorrow, to make it easier for you to tune it. So you can also learn from my settings how to set yours.
Powered by SimplTeam
Click to expand...
Click to collapse
triple thanks!

This kernel have support for custom batteries like zerolemon?

Hani K. said:
First. If you have flashed 20 minutes ago. Then give your battery sometime to settle down.
Second. If you have flashed the UltimatEdition, you need to tune the kernel through Synapse the way you need it to be. This is the main reason I included a SimplEdition. So you get good battery stats as soon as you flash it.
Third. I have included a different ways to help calibrate the batter, and I have actually mentioned on many instances if a setting helps optimizing the battery or not.
Fourth. I will upload a Battery profile tomorrow, to make it easier for you to tune it. So you can also learn from my settings how to set yours.
Powered by SimplTeam
Click to expand...
Click to collapse
Frash installation DN5 Rom, GPlay does not open
To be precise it did not want to update to 6.0.5 version. just stuck on 5.10

Nice , but what about battery & heating up in the phone ? It is this kernel distinct from the rest kernels in this regard ?!
أرسلت من SM-N920C بإستخدام تاباتلك