[REF][GUIDE]Saber's guide on CPU governors, I/O schedulers and more!
- Thread starter Saber
- Start date
Read this useful post by the OP:
The governor is the profile you select that will manage a great number of kernel related values, hotplugging can be a part of it. Someone smarter than me will correct that if I'm not (entirely) right ^_^
Question (from a noob):
Does anyone know if there´s an option or a rom that has kinda like a built-in option to change governors? not the settings, just the governor per se; something like an option on the battery setting to select a governor, then reboot and work with that governor? (not dealing with the option, just changing the governor on the next reboot.
Also, what is more efficient: to go through each frequency or to go to pre-selected frequency?
I think that; battery wise; a pre-selected frequency would be faster but don´t know if would be efficient regarding the workload.
Does anyone know if there´s an option or a rom that has kinda like a built-in option to change governors? not the settings, just the governor per se; something like an option on the battery setting to select a governor, then reboot and work with that governor? (not dealing with the option, just changing the governor on the next reboot.
Also, what is more efficient: to go through each frequency or to go to pre-selected frequency?
I think that; battery wise; a pre-selected frequency would be faster but don´t know if would be efficient regarding the workload.
That post pretty much sums it all up.
Before the SoC's (complete boards with everything integrated a.k.a your phones motherboard; ex. Qualcomm Snapdragon, Kirin, OMAP, Samsung Exynos) got so efficient people were disabling some of the cores to save power.
But, since the new ones are way more efficient, switching on and off uses more power than leaving it on and so its not done (it became pointless/inefficient saving electricity that way) - hence hotplugging is removed.
Hotplug was (only) switching cores off and back on, governor sets variables and system settings and so on. In the beginning they were separate pieces of code, later (the mentioned X versions) built the hotplugging logic into the kernel (more efficient code-wise and less error-prone because it could be tailored to a specific kernel/device) .
---------- Post added at 10:42 PM ---------- Previous post was at 10:19 PM ----------
Use apps to change govs - you fed root for that.
When the system boots the default settings are used, then, when the app runs it sets the changes (usually after a set and adjustable time out).
When devs create their custom kernels they usually test out various settings and scenarios and will set up the one that works for THEM best (they know very well what and how to test, usually comes down to best user experience unless they state the aim specifically, like say gaming).
They can also set up profiles (purely a set of settings). This if course will become the default that is set while booting the device.
Device vendors aren't spending much time to optimise (read test different sets of settings as it is too time consuming and so foookin expensive) so they'll go with time proven settings and governors, because 'it works best for most average users' and thus creates the least overhead on support departments (and they are right in many ways). Also makes selling new phones easier (newer must be better right?).
Every chip is and behaves different, you can spend endless time searching for the best settings and still not find it. I
Unless you have an older chip (like 3+ wars old) or a castrated (low(er) performance versions of the top end) one, there isn't much of a gain in tweaking it. Just thought you should know. So my answer for your last question is that lots of people spent lots of time debating and proving both, but it all depends (how would you know what freq should be preselected?)
Thanks for the replies. Is quite a handful all the info regarding governors, schedulers and stuff. So far I just changed my interactive to conservative and disabled the touch boost (phone used to get hot while gaming); plus the i/o scheduler. The phone feels more smooth and battery wise it doesn´t eat up as much.
Guide update
Hi all,
Just updated the guide with headings for HMP and EAS CPU governors. I've also added a Multi-Queue I/O scheduler section for people with newer devices.
Will be working on this guide in the next few days.
Saber
Hi all,
Just updated the guide with headings for HMP and EAS CPU governors. I've also added a Multi-Queue I/O scheduler section for people with newer devices.
Will be working on this guide in the next few days.
Saber
Hey, I have a little problem with my Galaxy S7 Edge. It is totally fluid only when playing it stutters something. When I set the CPU Governor to "Performance" everything is smooth. Here are the settings of my "Interactive" Governor. Does anyone have any tips what I should change here so that the games run smoothly? I tried to achieve something with the information in the Startpost, but did not get better. Thank you!
Attachments
Seeing that you are running android 9 one ui u need to flash oreo gpu libs that come with moro 7.0.1 or you can search the BD nfe v4 thread for libs alone
There's a new io scheduler called Depression
Couldn't find any docs about it..
Couldn't find any docs about it..
Similar threads
- Poll
Top Liked Posts
-
There are no posts matching your filters.
-
632Collective guide of CPU governors, I/O schedulers and other kernel variables
I present to you a wonderful collection of descriptions, comparisons and graphs of common kernel variables. Before continuing on the wonderful journey of Linux kernel tuning, please note that I am not responsible for any damage to your device or malfunction. You are in complete control over your device so please do not blindly follow without proper research. While you could use this guide to tune other devices other than a smartphone, I would recommend against doing so.
Guides:
What is a CPU governor?
A CPU governor in Android controls how the CPU raises and lowers its frequency in response to the demands the user is placing on their device. Governors are especially important in smartphones and tablets because they have a large impact on the apparent fluidity of the interface and the battery life of the device over a charge.
NOTE: You cannot change your CPU governor unless your phone is rooted and you have a ROM or app that lets you make a change. Also, different kernels (the intermediary software between your phone's hardware and the operating system) offer different sets of governors.
Available CPU governors:
- OnDemand
- OnDemandX
- Performance
- Powersave
- Conservative
- Userspace
- Min Max
- Interactive
- InteractiveX
- Smartass
- SmartassV2
- Scary
- Lagfree
- Smoothass
- Brazilianwax
- SavageZen
- Lazy
- Lionheart
- LionheartX
- Intellidemand
- Hotplug
- Badass
- Wheatley
- Lulzactive
- PegasusQ\PegasusD
- HotplugX
- Abyssplug
- MSM DCVS
- Intelliactive
- Adaptive
- Nightmare
- ZZmove
- Sleepy
- Hyper
- SmartassH3
- SLP
- NeoX
- ZZmanX
- OndemandPlus
- Dynamic Interactive (DynInteractive)
- Smartmax
- Ktoonservative\KtoonservativeQ
- Performance may cry (PMC)
- Dance Dance
- AbyssPlugv2
- IntelliMM
- InteractivePro
- Slim
- Ondemand EPS
- Smartmax EPS
- Uberdemand
- Yankactive
- Impulse
- Bacon
- Optimax
- Preservative
- Touchdemand
- ElementalX
- Bioshock
- Blu_active
- Umbrella_core
- ConservativeX
- Hyrdxq
- DevilQ
- Yankasusq
- Darkness
- Alucard
- Hellsactive
- Ragingmolasses
- Virtuous
- Sakuractive
- InteractiveX v2
- Alessa
- GallimaufryX
- AggressiveX
- Tripndroid
- Wrexy
- Xperience
- Stockdemand
- Zeneractive
- InteractiveB
- Aggressive
- IntellidemandV2
- Boostactive
- Wave
- Barry-Allen
- Arteractive
- Precognition (PrecoGOV)
- Mythx_plug
- PegasusQPlus
- Yankdemand
- HyperX
- Despair
- Electroactive
- Electrodemand
- Lionfish
- Interextrem
- Cafactive
- Lightning
- ThunderX
- sched-DVFS
- Intel
- Frankenstein
- Cyan
- TheSSJactive
- Chill
- sprdemand
- Kraken
- Ironactive
- Nebula
- Relaxed
- Crazyactive
- thenewbeginning
- Cultivation
- Schedutil
- pwrutilx
- blu_schedutil
Descriptions:
HMP Governors
1: OnDemand:
Description:
Ondemand is one of the original and oldest governors available on the linux kernel. When the load placed on your CPU reaches the set threshold, the governor will quickly ramp up to the maximum CPU frequency. It has excellent fluidity because of this high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand was commonly chosen by smartphone manufacturers in the past because it is well-tested and reliable, but it is outdated now and is being replaced by Google's Interactive governor.
2: OndemandX:
Description:
Basically an ondemand with suspend/wake profiles. No further optimization was done to Ondemand to keep it close to source as possible.
3: Performance:
Description:
The performance governor locks the phone's CPU at maximum frequency.
4: Powersave:
Description:
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
5: Conservative:
Description:
This governor biases the phone to prefer the lowest possible clockspeed as often as possible. In other words, a larger and more persistent load must be placed on the CPU before the conservative governor will be prompted to raise the CPU clockspeed. Depending on how the developer has implemented this governor, and the minimum clockspeed chosen by the user, the conservative governor can introduce choppy performance. On the other hand, it can be good for battery life.
The Conservative Governor is also frequently described as a "slow OnDemand". The original and unmodified conservative is slow and inefficient. Newer and modified versions of conservative (from some kernels) are much more responsive and are better all around for almost any use.
6: Userspace:
Description:
This governor, exceptionally rare for the world of mobile devices, allows any program executed by the user to set the CPU's operating frequency. This governor is more common amongst servers or desktop PCs where an application (like a power profile app) needs privileges to set the CPU clockspeed.
7: Min Max
Description:
Min Max is a governor that makes use of only min & maximum frequency based on workload... no intermediate frequencies are used!
8: Interactive:
Description:
Interactive scales the clockspeed over the course of a timer set by the kernel developer (or user). In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. It is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.
Interactive is the default governor of choice for today's smartphone and tablet manufacturers.
9: InteractiveX:
Description:
Created by kernel developer "Imoseyon," the InteractiveX governor is based heavily on the Interactive governor, enhanced with tuned timer parameters to better balance battery vs. performance. The InteractiveX governor's defining feature, however, is that it locks the CPU frequency to the user's lowest defined speed when the screen is off.
10: Smartass
Description:
Based on interactive, performance is on par with the “old” minmax and smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
Smartass will also cap the max frequency when sleeping to 352Mhz (or if your min frequency is higher than 352 it will cap it to your min frequency).
This governor will slowly ramp down frequency when the screen is off and it could also let the frequency go to low making your phone unusable (if min frequency is not checked).
11: SmartassV2:
Description:
Version 2 of the original smartass governor from Erasmux. The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq when screen is on. There's no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery.
12: Scary
Description:
A new governor wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to whatever the kernel developer sets it too and will still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance.
13: Lagfree:
Description:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.
14: Smoothass:
Description:
The same as the Smartass “governor” But MUCH more aggressive & across the board.
15: Brazilianwax:
Description:
Similar to smartassV2. More aggressive ramping, so more performance, less battery
16: SavagedZen:
Description:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
17: Lazy:
Description:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.
18: Lionheart:
Description:
Lionheart is a conservative-based governor which is based on samsung's update3 source.
The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
19: LionheartX
Description:
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
20: Intellidemand:
Description:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode.
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) by behaving like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off. Faux no longer recommends intellidemand and believes that intellidemand users should switch to intelliactive for better optimizations and performance.
21: Hotplug:
Description:
The Hotplug governor performs very similarly to the OnDemand governor, with the added benefit of being more precise about how it steps down through the kernel's frequency table as the governor measures the user's CPU load. However, the Hotplug governor's defining feature is its ability to turn unused CPU cores off during periods of low CPU utilization. This is known as "hotplugging."
22: BadAss:
Description:
Badass removes all of this "fast peaking" to the max frequency. To trigger a frequency increase, the system must run a bit with high load, then the frequency is bumped. If that is still not enough the governor gives you full throttle. (this transition should not take longer than 1-2 seconds, depending on the load your system is experiencing)
Badass will also take the gpu load into consideration. If the gpu is moderately busy it will bypass the above check and clock the cpu to max frequency, If the gpu is crushed under load, badass will lift the restrictions to the cpu.
23: Wheatley:
Description:
Building on the classic 'ondemand' governor is implemented Wheatley governor. The governor has two additional parameters. Wheatley works as planned and does not hinder the proper C4 usage for task where the C4 can be used properly. So the results show that Wheatley works as intended and ensures that the C4 state is used whenever the task allows a proper efficient usage of the C4 state. For more demanding tasks which cause a large number of wakeups and prevent the efficient usage of the C4 state, the governor resorts to the next best power saving mechanism and scales down the frequency. So with the new highly-flexible Wheatley governor one can have the best of both worlds.
Wheatley is a more performance orientated governor as it scales more aggressively than ondemand and sticks with higher frequencies.
24:Lulzactive\LulzactiveQ:
Description:
It's based on Interactive & Smartass governors.
Old Version: When workload is greater than or equal to 60%, the governor scales up CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step. When screen is off, frequency is locked to global scaling minimum frequency.
New Version: Three more user configurable parameters: inc_cpu_load, pump_up_step, pump_down_step. Unlike older version, this one gives more control for the user. We can set the threshold at which governor decides to scale up/down. We can also set number of frequency steps to be skipped while polling up and down.
When workload greater than or equal to inc_cpu_load, governor scales CPU pump_up_step steps up. When workload is less than inc_cpu_load, governor scales CPU down pump_down_step steps down.
25: Pegasusq/Pegasusd
Description:
The Pegasus-q / d is a multi-core based on the Ondemand governor and governor with integrated hot-plugging. It is quite stable and has the same battery life as ondemand). Ongoing processes in the queue, we know that multiple processes can run simultaneously on. These processes are active in an array, which is a field called "Run Queue" queue that is ongoing, with their priority values arranged (priority will be used by the task scheduler, which then decides which process to run next).
To ensure that each process has its fair share of resources, each will run for a certain period and will eventually stop and then again placed in the queue until it is your turn again. If a program is terminated, so that others can run the program with the highest priority in the current queue is executed.
26: Hotplugx
Description:
It's a modified version of Hotplug and optimized for the suspension in off-screen
27: AbyssPlug
Description:
It's a Governor derived from hotplug, it works the same way, but with the changes in savings for more battery life.
28: MSM DCVS
Description:
A very efficient and wide range of Dynamic Clock and Voltage Scaling (DCVS) which addresses usage models from active standby to mid and high level processing requirements. It makes the phone's CPU smoothly scale from low power, from low leakage mode to blazingly fast performance.Only to be used by Qualcomm CPUs.
MSM is the prefix for the SOC (MSM8960) and DCVS is Dynamic Clock and Voltage Scaling. Makes sense, MSM-DCVS
29: IntelliActive
Description:
Based off Google's Interactive governor with the following enhancements:
1. self-boost capability from input drivers (no need for PowerHAL assist)
2. two phase scheduling (idle/busy phases to prevent from jumping directly to max freq
3. Checks for offline cpus and short circuits some unnecessary checks to improve code execution paths. Therefore, it avoids CPU hotplugging.
Created by Faux
30: Adaptive
Description:
This driver adds a dynamic cpufreq policy governor designed for latency-sensitive workloads and also for demanding performance.
This governor attempts to reduce the latency of clock so that the system is more responsive to interactive workloads in lowest steady-state but to reduce power consumption in middle operation level, level up will be done in step by step to prohibit system from going to
max operation level.
31:Nightmare
Description:
A PegasusQ modified, less aggressive and more stable. A good compromise between performance and battery. In addition to the SoD is a prevention because it usually does not hotplug.
32: ZZmoove
Description:
The ZZmoove Governor by ZaneZam is optimized for low power consumption when the screen off, with particular attention to the limitation of consumption applications in the background with the screen off, such as listening to music. The unique feature with ZZmoove is that it has predefined profiles and allows profile switching.
33: Sleepy
Description:
The Sleepy (formerly known as Solo) is an attempt to strike a balance between performance and battery power to create. It is based on Ondemand. It includes some tweaks like the Down_sampling variable and other features that set by the user through the sysfs of "echo" call. Sleepy is quite similar to Ondemandx.
34: Hyper
Description:
The Hyper (formerly known as kenobi) is an aggressive smart and smooth governor based on the Ondemand and is equipped with several features of Ondemandx suspend profiles. It also has the fast_start deep_sleep variable and detection features. In addition, the maximum frequency is in suspend mode 500Mhz or whatever the kernel developer sets it to. This is a more smoothness oriented governor which means that it is good for performance, without sacrificing much battery life.
35: SmartassH3
Description:
The SmartassH3 governor is designed for battery saving and not pushing the phones performance, since doing that drains battery and that's the one thing people keep asking for more of. Based on SmartassV2.
36: SLP
Description:
It is a mix of pegasusq and ondemand. Therefore, it has a balance between battery savings and performance.
37: NeoX
Description:
An optimized version of the pegasusq governor but with some extra tweaks for better performance. This means slightly more battery drainage than the original PegasusQ but it is still a balanced governor.
38. ZZmanx
Description:
ZZmanx is exactly the same as ZZmoove, but it has been renamed because DorimanX made it into his own version (possibly better performance) . However, it still suffers from below average gaming performance. (Refer to ZZmoove description for guide on profiles)
39. OnDemandPlus
Description:
Ondemandplus is an ondemand and interactive-based governor that has additional power-saving capabilities while maintaining very snappy performance. While the interactive governor provides a modern and sleek framework, the scaling logic has been been re-written completely. Reports have found that users find ondemandplus as a more battery friendly governor. In ondemandplus, the downscaling behavior from ondemand is only very slightly modified. However, the upscaling has been modified to not scale up to maximum frequency immediately.
40. Dynamic Interactive (DynInteractive)
Description:
This governor dynamically adjusts itself according to load. That means it's settings are dynamic (always changing) and not static (not changing). Dyninteractive still obtains the same great balance between battery life and performance found in the original interactive governor and improves it even further. This is not the same as the original interactive governor because of this unique behavior.
41. Smartmax
Description:
Smartmax is a mix between ondemand and smartassv2. It behaves mostly like smartass with the concept of an "ideal" frequency. By default this is configured for battery saving, so this is NOT a gaming or benchmark governor! Additionally, to make it "snappy", smartmax has "touch poke". So input events from the touchscreen will boost the cpu for a specific time to a specific frequency. Developed by XDA user Maxwen.
42. Ktoonservative\KtoonservativeQ
Description:
Ktoonservative is based on the Conservative governor, but with the addition of new tunable variables and hotplugging. It aims to be very responsive while also being good at saving battery. This governor is highly configurable and is found in ktoonsez's kernels.
43. Performance may cry (PMC)
Description:
A governor based on Smartmax except it's heavily tweaked for better and maximum battery life. This is not a gaming governor!
44. Dance Dance
Description:
Based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It is a performance focused governor but also blends with some battery savings.
45. AbyssPlugv2
Description:
AbyssPlugv2 is a rewrite of the original CPU governor. It also fixes the problem where the governor is set only for the first core, but now governs all cores right from whatever utility you use. There have been comments on the lack of stability with this governor.
46. IntelliMM
Description:
A rewrite of the old Min Max governor and has 3 cpu states: Idle, UI and Max. Intelliminmax (intellimm) governor is designed to work with the newer SOCs with fixed voltage rails (ie MSM8974+ SOCs). It is designed to work within those fixed voltage ranges in order to maximize battery performance while creating a smooth UI operations. It is battery friendly and spends most of the time at lower frequencies.
47. Interactive Pro
Description:
A newer (modified) version of interactive which is optimized for devices such as the One Plus One. It is a more efficient than the original Interactive because it continuously re-evaluates the load of each CPU therefore allowing the CPU to scale efficiently.
48. Slim
Description:
A new governor from the cm branch and the slimrom project. This is a performance optimized governor and has been tuned a lot for newer devices such as the One Plus One.
49. Ondemand EPS
Description:
A modified version of Ondemand and is optimized for newer devices. It is based on the Semaphore Kernel's Ondemand which is more optimized for battery life. The EPS at the end stands for Extreme power savings so this governor is biased to power savings!
50. Smartmax EPS
Description:
This governor is based on Smartmax but is optimized for 'Extreme Power Saving' (hence the EPS suffix). This means it uses less battery than the original Smartmax so it is not a very good gaming governor (again!) This is only found on newer devices.43951. Uberdemand
Description:
Uberdemand is Ondemand with 2-phase feature meaning it has a soft cap at 1728 MHz so your cpu won't always go directly to max, made by Chet Kener.
52. Yankactive
Description:
A slightly modified interactive based governor by Yank555.lu. It has battery tweaks added onto it so expect better battery life! Based on user reports, this governor behaves more battery friendly than the original interactive governor without sacrificing performance.
53. Impulse
Description:
An improved version of interactive modified by neobuddy89. Impulse aims to have a balance between battery and performance just like interactive but has some tweaks to save battery.
54. Bacon
Description:
This is nothing but polished interactive governor branded as "bacon" since it was adapted from bacon device thanks to neobuddy89. Most of the tweaks are for performance/latency improvements
55. Optimax governor
Description:
Ondemand based with some enhancements from LG, particularly to freq boost handling so it will boost to a set level, almost like HTC's governor. It has different tunables to the HTC governor but it behaves pretty similar, the tunables it comes with default are a bit more conservative. It originates from Cl3kener's Uber kernel for Nexus 5, where it has quite a reputation for battery life
56. Preservative governor
Description:
Preservative is a conservative based governor. The idea is that it will stay at the step specified (702MHz selected by the creator Bedalus) unless needed. You will notice it will hover around 702 a lot, and not go above too much, and only to min freq when NOTHING is happening at all. This is most beneficial when you are doing something like reading; the screen is static or playing light games that won't need boosting any more. The governor comes from Moob kernel for nexus 4
57. Touchdemand
Description:
Touchdemand is based on the ondemand cpu governor but has been modified for the Tegra 3 chip (tablet only) and has additional tweaks for touchscreen responsiveness.
58. ElementalX
Description:
By default, it is more conservative than Ondemand as it does not ramp up often for most phone activities. If there is a graphics load detected, the governor will switch to a two-phase Ondemand behaviour where different max frequencies are used depending on the load increase. ElementalX comes with input boost enabled by default lowering the sampling rate and increasing the frequency to improve responsiveness.
59. Bioshock
Description:
CPU governor developed by Jamison904. A mix of ConservativeX and Lionheart
60. Blu_active
Description:
A governor developed by eng.stk (featured in his Code_Blue kernels) based on interactive with upstream caf patches and ondemand governor bits too. This governor is mainly focused on performance like the other things the developer creates but it is also well balanced for gaming and general usage.
61. Umbrella_core
Description:
A governor by twisedumbrella based on interactive that is focused on battery life and not performance. It will still ramp up to a set frequency but will not stay at high frequencies for long. This governor tends to stay in high-mid range frequencies during screen_off.
62. ConservativeX
Description:
Developed by Imoseyon (feat. briefly in the Lean Kernel for Galaxy Nexus), the ConservativeX governor behaves like the Conservative governor with the added benefit of locking the CPU frequency to the lowest interval when the screen is off. This governor may additionally perform hotplugging on CPU1, but there is no documentation to confirm that suspicion at this time.
63. HydrxQ
Description:
Simply a lulzactiveq governor with tweaks to performance (thanks to tegrak). This means more performance and less battery life.
64. DevilQ
Description:
An aggressive pegasusq governor which keeps the hotplugging at max 2 cpu cores to offline). This is pretty much a more optimized pegasusq for phone's with quad core processors.
65. YankasusQ
Description:
Yankasusq is another modified pegasusq but with including screen off freq tunable and some other modifications as well. The difference between PegasusQ and YanksusQ is that it doesn't ramp too aggressively when screen turns on (less battery drainage).
66. Darkness
Description:
It's based on nightmare but more simple and fast, basic configs but very complex structure. It is an updated nightmare gov and improved stability, so far it is quite stable in tests
67. Alucard
Description:
Alucard is based on ondemand but has been heavily tweaked to bring better battery life and performance. It has been known to be battery friendly without sacrificing much performance.
68. Hellsactive
Description:
A heavily modified intelliactive governor by @hellsgod that has been tweaked to improve battery life. Hellsactive is less aggressive compared to intelliactive so the battery life will be more like the original interactive.
69. Ragingmolasses
Description:
Besides a gov with an awesome name its a mash up of conservative and ondemand and scales based on load with few tunables. Its meant to be simple, fast, and efficient at keeping the frequency away from the max clock unless it is absolutely needed. it includes gboost for better gaming.
70. Virtuous
Description:
It sets your max cpu for wake and sleep and changes the governor when your device is awake or asleep. It saves battery by lowering cpu frequencies 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 uses 2 governors, one for sleep and other for awake)
71. Sakuractive
Description:
An aggressive hybrid of ondemand and hotplug, which means it will scale like ondemand, except a little more aggressive. But also acts like hotplug as it shuts down multiple CPU cores to save power.
72. InteractiveX V2
Description:
Developed by Imoseyon (feat. in the Lean Kernel for Galaxy Nexus), the InteractiveX V2 governor behaves like InteractiveX, and additionally forces CPU1 into a hotplug state when the screen is off.
73. Alessa
Description:
A less aggressive and more stable ondemand modified by TeamMex. A good compromise between performance and battery. It can be used with the complementary hotplug governor. Please note that this governor is still a WIP!
74. GallimaufryX
Description:
A modded ondemand that is a 2-stage ondemand governor with speed tweaks. It includes imoseyon's screen-off hotplugging code.
75. AggressiveX
Description:
A modded conservative governor but with lots of tweaks to increase snappiness while saving power. It also includes imoseyon's screen-off hotplugging code.
76. Tripndroid
Description:
Tripndroid is based on ondemand with extra tweaks for performance
77. Wrexy
Description:
Wrexy is a conservative based governor but is also similar to the Lionheart gov. It tends to stay out of higher frequencies to favor lower frequencies but performance is not much affected.
78. Xperience
Description:
A tweaked smartassv2 for better performance. Created by TeamMex.
79. Stockdemand
Description:
A heavily modified ondemand for better performance and battery life.
80. Zeneractive
Description:
Based on the interactive governor, it handles frequency scaling the exact same as interactive and has the same tunables as interactive for frequency scaling. However, all of the new hotplugging code is written "from scratch."
81. InteractiveB
Description:
An interactive based governor with a more balanced battery life/performance profile
82. Aggressive
Description:
Like Lionheart, it is based on conservative, but even more aggressive
83. Intellidemandv2
Description:
Much like its predecessor, intellidemandv2 is an intelligent ondemand with browsing detection and scales based on GPU loading. It has been optimized for specific devices and has better battery life and performance.
84. Boostactive
Description:
Based on Interactive but with cpu frequency boosting capabilities. This is performance oriented governor.
85. Wave
Description:
Based on Conservative with some tweaks for speed and battery. This governor was created by zparallax.
86. Barry-Allen
Description:
It's based on interactive. The governor is supposed to be more battery friendly and at the same have good performance.
87. Arteractive
Description:
It is an interactive CPU governor port from newer source code. It has more optimizations for Snapdragon 80x processors.
88. Precognition (PrecoGOV)
Description:
PrecoGOV takes over and dynamically adapts to your usage pattern. To achieve such goal, PrecoGOV manages the frequency, idle & sleep patterns, hotplugging, temperature per core and even gpu and tries to help the scheduler as best as it can, all while taking into account battery and thermal constraints.
89. Mythx_plug
Description:
It's based on an improved Interactive governor and has been modified to scale up slower and scale down faster. It is a battery friendly governor.
90. PegasusQPlus
Description:
PegasusQPlus is a heavily tweaked PegasusQ governor, which has been implemented by AndreiLux in his Perseus kernel. PegasusQPlus should have a better balance between performance and battery usage.
91. Yankdemand
Description:
Full stock (JB) ondemand governor with changed default tunable values aimed at lower battery consumption
92. HyperX
Description:
A tweaked interactive based governor for performance.
93. Despair
Description:
It is a tweaked conservative governor with a couple extra values exposed, it tends to be a bit more conservative with battery than the conservative governor by default. Developed by DespairFactor.
94. Electroactive
Description:
This governor is the replacement over the original electrodemand governor, being much more battery friendly with much smoother transitions compared to the original. It is a hybrid class governor, using a unique way to merge the best of both interactive and ondemand. It includes some extra additions and enhancements to be more battery saving than interactive governor and some boost tunes and additions that allow better power management and performance in games as well as better power saving when in normal use. CPU boost, graphics boost, fast_start deep_sleep and detection features are built in as well as 300 MHz clock speed in suspend.
95. Electrodemand
Description:
Based on the ondemand cpu governor, this is the older governor that was used in the electroactive kernel which uses the same tunables found in the original ondemand governor.
96. Lionfish
Description:
The Lionfish governor combines traits of the conservative, ondemand, and interactive governors. It is designed to maximize battery life without noticeably impacting performance. It responds quickly to heavy loads while staying within the region of optimal CPU performance per watt. With moderate loads, it periodically votes to raise, maintain, or decrease the frequency. When there are enough votes to change the frequency, it is ramped up and down gradually. The voting mechanism reduces frequency jitter compared to ondemand and conservative. squid2's testing had found that this governor uses moderate frequencies (where efficiency is optimal) more effectively than interactive, ondemand, and conservative. This improved frequency distribution results in a moderate reduction in CPU power consumption while maintaining responsiveness comparable to the interactive governor.
97. Interextrem
Description:
A tweaked interactive governor by thehacker911. It is found in hacker kernel s6, where it has been tuned for better performance while still maintaining good battery life.
98. Cafactive
Description:
Found in arter97's kernels, cafactive is the qualcomm optimized version of interactive from CodeAurora. This version promises to bring greatly enhanced performance over samsung's own version of interactive (benchmarks have shown a increase in performance scores), however it may be unstable on some devices and may cause some performance issues under normal and heavy operation.
99. Lightning
Description:
Lightning is modified darkness gov made by @HridayHS
100. ThunderX
Description:
ThunderX is a power saving CPU governor based on SmartAssv2 optimized for Mediatek SoCs.
101. Intel
Description:
It's an interactive based governor that is optimized for Intel devices. It is thought to be more battery friendly than interactive while still having good performance. Found only on intel based SOCs.
102. Frankenstein
Description:
Based on interactive with hotplugging, it is a performance oriented governor but aims to save battery when screen is off. However, it may be unstable on some devices. Found only on intel based SOCs.
103. Cyan
Description:
Cyan is an interactive based CPU governor intended for heavy gaming and processes. It was originally developed for the i9500, but is now found in kernels for devices with intel SOCs.
104. TheSSJactive
Description:
TheSSJactive is based on yankactive but with the addition of hotplugging support for intel SOCs. It is known to be a battery friendly governor.
105. Chill
Description:
A conservative based governor by frap129 (Electron kernel). It's aims to provide more aggressive battery savings while screen is off.
106. sprdemand
Description:
A modded ondemand governor with functionality to offline CPUs when screen is off. It has thermal control logic implemented into the governor.
107. Kraken
Description:
Based on ElementalX but with tweaks for better performance while remaining well balanced. Found in Kraken Kernel by Team OctOS.
108. Ironactive
Description:
Based on the latest CAF 4.4 version of interactive without any additional modifications. It is found in @Tkkg1994's superkernel for the Samsung Galaxy S7.
109. Nebula
Description:
A port of the Interactive governor based on msm-4.4 sources with some mods for the HTC 10, preserving the excellent balance between performance and battery life found in many other Interactive based govs. It originated from Eliminater74's Nebula kernel and was a popular choice prior to the introduction of EAS scheduling to the kernel.
110. Relaxed
Description:
Relaxed is based on chill, and has been altered in order to achieve more gradual frequency boosting providing battery life benefits. Relaxed uses a boost ceiling variable in order to achieve this. Rather than boosting straight to the max frequency, relaxed finds the difference between boost_counter and boost_ceiling, then boosts to max minus that difference. This governor doesn't completely replace chill, but is intended to be used alongside it.
111. Crazyactive
Description:
A modified Interactive governor by @CrazyGamerGR that has been biased more towards performance.
112. thenewbeginning
Description
A modified Alucard governor by varunhardgamer that has been biased more towards performance.
113. Cultivation
Description
A highly modified interactive-based governor with the intention of giving the user more control by providing more tuning options. Based on CAF 4.4 commits with parts coming from blu_active and XDA user Sultanxda.
EAS Governors
114. schedutil
Description:
schedutil is a new EAS governor found in recent versions of the Linux Kernel (4.7+) that aims to integrate better with the Linux Kernel scheduler. It uses the kernel's scheduler to receive CPU utilisation information and make decisions from this input. As a direct result, schedutil can respond to CPU load faster and more accurate than normal governors such as Interactive that rely on timers.
115. pwrutilx
Description:
A new EAS governor based on schedutil that aims to be much more efficient by using a different formula to get next frequency.
116. blu_schedutil
Description:
blu_schedutil is an unmodified version of the Pixel 3 schedutil governor which promises better battery savings over traditional schedutil.
Hotplugging drivers:
1. mpdecision:
Description:
Qualcomm's default hotplugging driver. One of the most widely used hotplug drivers in all android devices.
2.msm_hotplug:
Description:
Great battery life, a custom qualcomm based hotplugging driver by myflux. It is a popular choice for many users.
3. intelliplug:
Description:
A popular hotplug from faux123 that is highly customisable and provides a great balance between battery and performance.
4. Alucard:
Description:
A great hotplugging driver by Alucard. It is known to be very battery friendly on devices.
5. Kt Auto Hotplug:
Description:
A great hotplug driver by Ktoonsez. Pretty much a smarter mpdecision that has been optimized for quad-core devices.
6. Mako Hotplug:
Description:
A popular hotplug driver found in Franco kernel. Franco didn't like how closed sourced MPdecision worked and so he created this driver as a direct replacement. It always keep 2 cores online and will online additional cores based on load conditions.
7. Zen Decision:
Description:
ZEN only onlines all cores when screen is on, it also takes thermal events into account and wont online any core back, if you're under 15% battery, or currently have a thermal event because of heat. So in the end it isn't a "real" hotplug driver, because it doesnt have any code for active hot plugging in it. That means you can't change its behavior.
8. Bricked Hotplug:
Description:
Conservative hotplug driver by @show-p1984. It is based on mpdecision but has been optimized for better balance between battery life and performance.
9. msm_sleeper:
Description:
The main feature with this hotplug is that you can customize the screen off frequency. Two cores are always on, the third and fourth are independent and come online if needed. By default, if the load is over 80 for 400ms another core comes online. The third and/or fourth cores stay online as long as the load demands it or for a minimum of one second. While the screen is off, it goes down to a single core. Created by flar2.
10. Autosmp:
Description:
A highly-efficient hotplug driver by @mrg666, works in-sync with the CPU governor to enable off-line cpu cores when the the CPU frequency reaches a high threshold and still more compute power is needed. Therefore, touch boost bloat is removed.
11. Thunderplug:
Description:
A matured load-based hotplug driver with many tunables written from ground up by varun.chitre15. This hotplug is optimized for octa-core devices and also has support for 64bit CPUs.
12. Blu_plug:
Description:
Dynamic hotplug from eng.stk's shamu kernel with screenoff battery saving.
13. cpuquiet:
Description:
A hotplug driver by NVidia and ported to Snapdragon by maxwen. Originally made for NVidia tegra SOCs. It has a set of governors which keep the CPU running at optimal frequencies for battery and performance.
14. Fast hotplug:
Description:
A hotplug driver from pec0ra's abricot kernel. It aims to be as lightweight as possible while also being highly customizable. However, it is still a WIP as it is known to have some stability issues.
15. Hima hotplug:
Description:
An optimized hotplug driver based on intelliplug for big.LITTLE architecture. Found on chadouming's HTC One (M9) kernel, it takes advantage of the big and LITTLE CPU cores in order to provide 'butter smooth' performance.
16. State Helper:
Description:
A hotplug driver by @neobuddy89 designed with the Nexus 6 in mind. It is highly configurable giving the user control over what CPUs to online based on what battery threshold levels have been set. Another feature that sets state helper apart from other hotplug methods is that it respects the thermal driver.
17. ZZmoove native hotplug:
Description:
The hotplugging logic found in the ZZmoove governor. This isn't a standalone hotplug driver that can be used with other governors, the hotplugging is done by the governor which was common on older devices like the Samsung Galaxy S3. Native hotplugging may offer better stability and the governor should perform better in battery life and performance (your experience may vary) because it was designed for this specific governor.
18. Lazyplug
Description:
A hotplug from arter97 that leaves CPU cores on for most of the time with the exception of some situations where leaving all cores on could be battery draining (e.g. Video playback). The purpose behind this is to improve performance & battery life by removing excess CPU overheads caused by unnecessary hotplugging where similar techniques are already employed in Samsung and Nexus firmwares.
GPU governors
1. Simple:
Description:
An open-source alternative to Qualcomm's closed-sourced governors. Developed by Faux123, it is highly customisable which will allow more fine-grained control over how the GPU scales up and down.
2. simple_ondemand:
Description:
As the name implies, it is a simpler version of the CPU governor ondemand. simple_ondemand will ramp up the frequency when a load is detected. It has a good balance between performance and battery savings.
3. msm-adreno-tz:
Description:
The default GPU governor used by Qualcomm for their adreno GPUs. It is based on the ondemand governor but is biased towards performance, therefore it should give better performance in games but less battery life.
4. Performance:
Description:
As the name suggests, this keeps your GPU running at the max frequency. This is a governor if you want the best possible experience in games but you don't care about your battery life.
5. Powersave:
Description:
Like the CPU governor, this keeps your GPU running at the lowest possible frequency. Best battery life, extreme lag in games.
6. Adreno Idler:
Description:
It is an idling algorithm, an efficient workaround for msm-adreno-tz's overheads. Main goal is to lower the power consumptions while maintaining high-performance. Since msm-adreno-tz tends to *not* use the lowest frequency even on idle, Adreno idler replaces msm-adreno-tz's algorithm when it comes to calculating idle frequency(mostly by ondemand's method). The higher frequencies are not touched with this algorithm, so high-demanding games will (most likely) not suffer from worsened performance.
7. Userspace:
Description:
This governor basically allows the user is able to set a desired frequency for the GPU to run at.
8. cpubw_hwmon:
Description:
A hardware monitor based governor that attempts to determine bandwidth (BW) needed by CPU and other hardware. Because it samples bandwidth using polling intervals, it has been made to be biased towards performance to compensate for the possible slower response times during heavy loads.
9. MSM Cpufreq:
Description:
The MSM CPUfreq governor determines the CPU to DDR bandwidth vote based on the current CPU frequency of all the active CPUs. In other words, this governor scales based on CPU usage which could mean more performance.
Benchmark graphs:
Link to raw data: https://drive.google.com/file/d/0B3ApZsjOd2bzWDRnQjRsUTlLSlE/view?usp=sharing
Here are more graphs (thanks to Haldi!)
Having trouble seeing the graph above? Here is the direct link to the image: http://i.imgur.com/PbtNyab.png
For more info about Haldi's benchmarks, visit here: http://forum.xda-developers.com/showthread.php?t=2768979
Recommendations
Overall:
- Interactive (or balanced variants)
- zzmoove (default or optimized profile)
- Ondemand
- PegasusQ (Works well on some older devices)
- Impulse
Battery Saving:
- Conservative (tuned, or battery saving variants)
- Ondemand (tuned, or battery saving variants)
- Smartmax
- Powersave
- Alucard
- zzmoove (tuned, change to battery profile)
Performance oriented:
- Interactive (tuned, or performance oriented variants)
- Intelliactive (preferred over intellidemand)
- Performance
- Nightmare
- Blu_active
- Lionheart
437I/O Schedulers
Why change your phones I/O Scheduler?
Most phone manufacturers keep your phone's I/O scheduler locked, so users are unable to modify any values which could change the performance of your phone. However, once your phone is rooted, you can change these values allowing the potential to boost your phones performance and even slightly increase battery life. Here is a thorough guide on all of the common i/o schedulers.
What is an 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 minimise time wasted by hard disk seeks.
- To prioritise 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.
Which schedulers are available?
- CFQ
- Deadline
- VR
- Noop
- BFQ
- FIOPS (Fair IOPS)
- SIO (Simple I/O)
- ROW
- ZEN
- SIOplus
- FIFO (First in First Out)
- Tripndroid
- Test
- Maple
I/O Scheduler Descriptions:
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.
Benefits:
- Generally performs the best in throughput tests
- Very stable, is the default Linux kernel I/O scheduler for many desktops and mobile devices
- Performs well on spinning storage and even on solid state storage for mixed workloads
- Generally seen as well balanced
- Processes requiring more I/O resources can be prioritised higher (such as indexing, system maintenance)
Disadvantages:
- I/O latency can be somewhat poor
- There is some scheduling overhead, although probably not too noticeable in tests and real world usage
The bottom line: One of the best all-rounder I/O schedulers available. CFQ is better suited for traditional hard disks, however it may give better throughput under some situations.
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.
Benefits:
- Excels in reducing latency of any given single I/O
- Can perform better than CFQ in certain workloads
- Performs well in (most) benchmarks
- Generally low scheduling overhead
- Very stable, default in recent Linux kernel versions
Disadvantages:
- Less I/O throughput than CFQ
- No ability to prioritise I/O bound processes over others
The bottom line: A good all-round scheduler. If you want good performance, you should try deadline.
ROW:
The ROW I/O 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 I/O 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.
Benefits:
- Low read latency, better for responsiveness and task switching
- Generally stable, has been adopted in many kernels
Disadvantages:
- Potentially higher write latency, reducing write performance
The bottom line: It is a good all-round scheduler despite being biased to read operations. Your device may feel more responsive after selecting ROW because it was designed for mobile devices. Older devices may see more of a boost in performance compared to newer devices.
SIO (Simple I/O):
Simple I/O aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority queue concepts, but only basic merging. SIO is a mix between Noop & deadline. No reordering or sorting of requests.
Benefits:
- Generally low I/O latency, better for responsiveness
- Very stable
Disadvantages:
- Performs poorly in benchmarks
The bottom line: One of my favourite schedulers, it is a good all-round scheduler. People who want better performance should avoid using this.
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.
Benefits:
- Low I/O latency, better responsiveness
- Very low scheduling overhead
- Very stable, used as default for some systems with solid state drives
Disadvantages:
- Performs poorly in benchmarks
The bottom line: Modern smartphones now use Noop as the default scheduler due to the fact that it works quite well with flash based storage. However older devices may experience slower performance when selected. If you want a very simple I/O scheduler algorithm (because of battery life or latency reasons), you can select this.
VR:
Unlike other scheduling software, synchronous and asynchronous requests are not handled separately, but it will impose a fair and balanced within this deadline requests, that the next request to be served is a function of distance from the last request.
Benefits:
- Generally excels in random writes.
Disadvantages:
- Sometimes unstable and unreliable
The bottom line: Not the best scheduler to select. You will probably find that other schedulers are performing better while being more stable.
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.
Benefits:
- Good I/O throughput, sometimes matching CFQ in performance
- Better I/O latency than CFQ, better responsiveness
- Well balanced, even more so than CFQ
- Generally stable, default in some custom kernels and Linux distributions
Disadvantages:
- Performs poorly in benchmarks, sometimes a lot worse in some areas
The bottom line: There are better schedulers out there that will perform better than BFQ. It is quite a complex scheduler that is better designed for traditional hard disks.
ZEN:
ZEN is based on the Noop, Deadline and SIO I/O schedulers. It's an FCFS (First come, first serve) based algorithm, but it's not strictly FIFO. ZEN does not do any sorting. It uses deadlines for fairness, and treats synchronous requests with priority over asynchronous ones. Other than that, it's pretty much the same as Noop blended with VR features.
Benefits:
- Excels in I/O latency, good for responsiveness
- Very stable
- Generally seen as well balanced
Disadvantages:
- There is some scheduling overhead, but less than CFQ
The bottom line: It is pretty much a better version of VR, performs quite well and is stable. Overall this is a good choice for most smartphones.
SIOplus:
Based on the original SIO scheduler with improvements. Functionality for specifying the starvation of async reads against sync reads; starved write requests counter only counts when there actually are write requests in the queue; fixed a bug).
Benefits:
- Better I/O latency than SIO in certain workloads
Disadvantages:
- Still performs about the same as SIO in benchmarks
The bottom line: If you liked SIO, you will like SIOplus. It performs slightly better in some usage case scenarios, but performance seekers should look else where.
FIOPS (Fair IOPS):
This new I/O scheduler is designed around the following assumptions about Flash-based storage devices: no I/O seek time, read and write I/O cost is usually different from rotating media, time to make a request depends upon the request size, and high through-put and higher IOPS with low-latency. FIOPS (Fair IOPS) I/O scheduler tries to fix the gaps in CFQ. It's IOPS based, so it only targets for drive without I/O seek. It's quite similar like CFQ, but the dispatch decision is made according to IOPS instead of slice.
Benefits:
- Generally has good I/O latency, performs well in some benchmarks
- Like CFQ, has some scheduling overhead
Disadvantages:
- On certain configurations, people may experience issues with stutters in day-to-day device usage
- Not the most stable scheduler
The bottom line: Most people who use FIOPS will get a noticeable performance improvement. However, you may get issues with scrolling and general lags.
FIFO (First in First Out):
First in First Out Scheduler. As the name says, it implements a simple priority method based on processing the requests as they come in.
Benefits:
- Low I/O latency, better responsiveness
- Very low scheduling overhead
- Very stable, used as default for some systems with solid state drives
Disadvantages:
- Performs poorly in benchmarks
The bottom line: Like Noop, but is less common. If you want a very simple I/O scheduler algorithm (because of battery life or latency reasons), you can select this.
Tripndroid:
A new I/O scheduler based on Noop, deadline and vr and meant to have minimal overhead. Made by TripNRaVeR
Benefits:
- Excels in I/O latency, good for responsiveness, sometimes better with some tuning
- Should be stable, however is not adopted widely
- Generally seen as well balanced
Disadvantages:
- There is some scheduling overhead, but less than CFQ
The bottom line: Tripndroid isn't very common. There are other schedulers you can choose which may perform similar or better. However it is a good all-round scheduler.
Test:
The test I/O scheduler is a duplicate of the Noop scheduler with addition of test utility. It allows testing a block device by dispatching specific requests according to the test case and declare PASS/FAIL according to the requests completion error code.
Benefits:
- Same as Noop, but can be beneficial to kernel developers
Disadvantages:
- Same as Noop
The bottom line: Shouldn't really be used by anyone. You should be using Noop instead of this.
Maple:
Maple is based on the Zen and Simple I/O schedulers. It uses ZEN's first-come-first-serve style algorithm with separate read/write requests and improved former/latter request handling from SIO. Maple is biased towards handling asynchronous requests before synchronous, and read requests before write. While this can have negative aspects on write intensive tasks like file copying, it slightly improves UI responsiveness. When the device is asleep, maple increases the expiry time of requests so that it can handle them more slowly, causing less overhead.
Benefits:
- Well rounded
- Designed for mobile devices in mind
- Better I/O latency than ZEN in certain workloads
Disadvantages:
- May be unstable on some devices
The bottom line: This is still a very new I/O scheduler which should perform slightly better than ZEN. It will continue to improve with more development.
Anxiety:
Anxiety doesn't separate asynchronous and synchronous requests because asynchronous ones are rarely seen. It prioritizes reads over writes just like Maple, but tends to starve writes more (this is tunable). It is based on noop with a basic first-in-first-out algorithm, whereas Maple is based on deadline with time tracking for expiration. This makes Anxiety better on battery than Maple, as well as fast. It prioritizes latency over throughput which means that requests happen quicker but transfer data slower.
Benefits:
- Designed for mobile devices in mind
- Possibly more battery savings compared to Maple
Disadvantages:
- Data transfers and write speeds may be slower
Multi-queue schedulers:
If you have a fairly recent phone, the chances are that you are able to use multi-queue (MQ) I/O schedulers. It comes from recent works from the upstream Linux kernel as devices are becoming more powerful with better storage and processors. These schedulers in theory should perform better than your traditional schedulers (e.g. noop, SIO, etc), by having better utilisation of multi-core CPUs/SOCs. You can have a view of some of the descriptions here: Arch Linux wiki.
The bottom line: A good well-rounded I/O scheduler that is relatively simple and performs quite well in most scenarios.
I/O Read Ahead Buffer:
If you've used a custom kernel, you probably have heard of a term called Read Ahead Buffer or Cache. It's basically a cache for files that have been opened recently on your mobile device, so that they can be quickly accessed again if needed. By android default, this value has been set to 128kB. Usually having more buffer means that more files can be cached, this can mean higher read and write speeds, but also this can result in more I/O latency. There is a point where increasing the I/O read ahead will have no benefit to read/write speeds.
Have a look at the graph below:
Source: http://andrux-and-me.blogspot.com.au/2014/06/various-conditions-and-io-performance.html
Recommendations:
I/O Read Ahead Buffer is dependent on the size of your flash storage (internal/external) unlike I/O schedulers. Below is the recommended settings for the given size that will yield the best performance (differs between setups).
Less than 8GB - 128KB
8GB - 512KB
16GB - 1024KB
32GB or above - 2048KB
Any setting above what I have recommended may yield no extra performance!
If you have issues such as failed reads and writes after changing these values, try a smaller value. Please note that some SD cards may experience issues after setting a higher buffer value.
What to remember:
- More isn't always better!
- Some SD cards can't handle high read ahead cache values, so make sure you have a genuine high quality SD card
- Default is good enough for most people, but isn't the best for performance
- Performance difference varies between devices
Results :
Setup:
Phone: Sony Xperia Z2
Scheduler: as per indicated
Read Ahead: 512kB
App: AndroBench 4
Here is a graph of the performance of the i/o schedulers. Note: a higher score doesn't mean it is the best io scheduler. These numbers mean nothing in real world performance, so take the following a mere glimpse of the performance of schedulers.
Sequential in MB/sec (Higher is better)
Random in IOPS (Higher is better)
Thanks haldi for the graphs! Link: http://forum.xda-developers.com/showpost.php?p=58807943&postcount=85
Recommended IO schedulers:
Overall:
- CFQ
- BFQ
- FIOPS
- Deadline
Justification: For overall performance, evidence has shown that some form of scheduling such as seen in CFQ or BFQ is beneficial not only for mechanical drives, but also for solid state media [citation needed]. These schedulers are usually configured to understand the differences between the storage devices, and hence for example will not treat Internal Storage as a traditional rotating hard drive(based on seeks). In smartphones, we do a lot of concurrent I/O multitasking, and hence, schedulers that have some logic to impose fairness will help in this situation
For best performance:
- FIOPS
- BFQ
- CFQ
- Deadline
Justification: Results have shown that schedulers such as CFQ (those that impose some form of fairness) achieve excellent throughput, but the cost of increase scheduling overhead and latency. On modern smartphones, added overhead and latency shouldn't have a significant impact to the responsiveness of the system, since we are dealing with much more powerful CPUs than those of the past. Synthetic benchmarks should not be the deciding factor of a scheduler
For least overhead:
- Noop
- FIFO
- Deadline
Justification: If the only thing you value is lower overheads on I/O processing, your best bet is Deadline. Why? Noop has been recommended on some guide found on the internet for solid state media, however there are known cases where Noop has caused issues in some particular workloads [citation needed]
Source: xda-developers, andrux-and-me.blogspot.com.au277CPU Governor tuning guide
NOTE: If you don't have some of these tunables, you might have an older version of the governor/hotplug driver and/or the kernel maintainer has made modifications to it.
CPU governors
1. ONDEMAND
[ PARAMETERS ]
2. LULZACTIVEQ
1. Initial Version:-
[ PARAMETERS ]
2. Second Version (LulzactiveQ):-
[ PARAMETERS ]
3. SMARTASSV2
[ PARAMETERS ]
4. CONSERVATIVE
[ PARAMETERS ]
5. INTERACTIVE
1. Generic Version
[ PARAMETERS ]
2. Qualcomm version/Intelliactive/IntelliMM
[ PARAMETERS ]
6. Wheatley
[ PARAMETERS ]
7. Darkness/Nightmare
[ PARAMETERS ]
8. zzmoove
[ PARAMETERS ]
9. Smartmax/Performance May Cry
[ PARAMETERS ]
