• XDA Forums have been migrated to XenForo. We are aware of several issues including missing threads, logins not working, and more. To discuss, use this thread.

[REF][GUIDE]Most up to date guide on CPU governors, I/O schedulers and more!

What CPU governor do you use?

  • Ondemand/OndemandX

    Votes: 267 7.4%
  • Interactive/InteractiveX

    Votes: 1,141 31.6%
  • Conservative/Ktoonservative

    Votes: 139 3.8%
  • Performance

    Votes: 175 4.8%
  • Powersave

    Votes: 94 2.6%
  • ZZMoove

    Votes: 160 4.4%
  • Intelliactive/Intellidemand

    Votes: 100 2.8%
  • Hyper

    Votes: 24 0.7%
  • PegasusQ

    Votes: 47 1.3%
  • Impulse

    Votes: 123 3.4%
  • Smartmax/Performance May Cry

    Votes: 65 1.8%
  • ElementalX

    Votes: 204 5.6%
  • Alucard

    Votes: 227 6.3%
  • Yankactive/YanksusQ/Yankdemand

    Votes: 28 0.8%
  • Darkness/Nightmare/Lightning

    Votes: 97 2.7%
  • Blu_active

    Votes: 271 7.5%
  • SmartassV2/SmartassH3

    Votes: 68 1.9%
  • Other

    Votes: 382 10.6%

  • Total voters


Recognized Contributor
Apr 9, 2014
Collective guide of CPU governors, I/O schedulers and other kernel variables

I present to you a wonderful collection of descriptions, comparisons and graphs of common kernel variables. Before continuing on the wonderful journey of Linux kernel tuning, please note that I am not responsible for any damage to your device or malfunction. You are in complete control over your device so please do not blindly follow without proper research. While you could use this guide to tune other devices other than a smartphone, I would recommend against doing so.


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:

  1. OnDemand
  2. OnDemandX
  3. Performance
  4. Powersave
  5. Conservative
  6. Userspace
  7. Min Max
  8. Interactive
  9. InteractiveX
  10. Smartass
  11. SmartassV2
  12. Scary
  13. Lagfree
  14. Smoothass
  15. Brazilianwax
  16. SavageZen
  17. Lazy
  18. Lionheart
  19. LionheartX
  20. Intellidemand
  21. Hotplug
  22. Badass
  23. Wheatley
  24. Lulzactive
  25. PegasusQ\PegasusD
  26. HotplugX
  27. Abyssplug
  28. MSM DCVS
  29. Intelliactive
  30. Adaptive
  31. Nightmare
  32. ZZmove
  33. Sleepy
  34. Hyper
  35. SmartassH3
  36. SLP
  37. NeoX
  38. ZZmanX
  39. OndemandPlus
  40. Dynamic Interactive (DynInteractive)
  41. Smartmax
  42. Ktoonservative\KtoonservativeQ
  43. Performance may cry (PMC)
  44. Dance Dance
  45. AbyssPlugv2
  46. IntelliMM
  47. InteractivePro
  48. Slim
  49. Ondemand EPS
  50. Smartmax EPS
  51. Uberdemand
  52. Yankactive
  53. Impulse
  54. Bacon
  55. Optimax
  56. Preservative
  57. Touchdemand
  58. ElementalX
  59. Bioshock
  60. Blu_active
  61. Umbrella_core
  62. ConservativeX
  63. Hyrdxq
  64. DevilQ
  65. Yankasusq
  66. Darkness
  67. Alucard
  68. Hellsactive
  69. Ragingmolasses
  70. Virtuous
  71. Sakuractive
  72. InteractiveX v2
  73. Alessa
  74. GallimaufryX
  75. AggressiveX
  76. Tripndroid
  77. Wrexy
  78. Xperience
  79. Stockdemand
  80. Zeneractive
  81. InteractiveB
  82. Aggressive
  83. IntellidemandV2
  84. Boostactive
  85. Wave
  86. Barry-Allen
  87. Arteractive
  88. Precognition (PrecoGOV)
  89. Mythx_plug
  90. PegasusQPlus
  91. Yankdemand
  92. HyperX
  93. Despair
  94. Electroactive
  95. Electrodemand
  96. Lionfish
  97. Interextrem
  98. Cafactive
  99. Lightning
  100. ThunderX
  101. sched-DVFS
  102. Intel
  103. Frankenstein
  104. Cyan
  105. TheSSJactive
  106. Chill
  107. sprdemand
  108. Kraken
  109. Ironactive
  110. Nebula
  111. Relaxed
  112. Crazyactive
  113. thenewbeginning
  114. Cultivation
  115. Schedutil
  116. pwrutilx
  117. blu_schedutil


HMP Governors

1: OnDemand:

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:

Basically an ondemand with suspend/wake profiles. No further optimization was done to Ondemand to keep it close to source as possible.

3: Performance:

The performance governor locks the phone's CPU at maximum frequency.

4: Powersave:

The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.

5: Conservative:

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:

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

Min Max is a governor that makes use of only min & maximum frequency based on workload... no intermediate frequencies are used!

8: Interactive:

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:

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

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:

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

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:

Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.

14: Smoothass:

The same as the Smartass “governor” But MUCH more aggressive & across the board.

15: Brazilianwax:

Similar to smartassV2. More aggressive ramping, so more performance, less battery

16: SavagedZen:

Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.

17: Lazy:

This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.

18: Lionheart:

Lionheart is a conservative-based governor which is based on samsung's update3 source.
The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.

19: LionheartX

LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.

20: Intellidemand:

Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. 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:

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:

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:

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.


It's based on Interactive & Smartass governors.

Old Version: When workload is greater than or equal to 60%, the governor scales up CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step. When screen is off, frequency is locked to global scaling minimum frequency.

New Version: Three more user configurable parameters: inc_cpu_load, pump_up_step, pump_down_step. Unlike older version, this one gives more control for the user. We can set the threshold at which governor decides to scale up/down. We can also set number of frequency steps to be skipped while polling up and down.
When workload greater than or equal to inc_cpu_load, governor scales CPU pump_up_step steps up. When workload is less than inc_cpu_load, governor scales CPU down pump_down_step steps down.

25: Pegasusq/Pegasusd

The Pegasus-q / d is a multi-core based on the Ondemand governor and governor with integrated hot-plugging. It is quite stable and has the same battery life as ondemand). Ongoing processes in the queue, we know that multiple processes can run simultaneously on. These processes are active in an array, which is a field called "Run Queue" queue that is ongoing, with their priority values ​​arranged (priority will be used by the task scheduler, which then decides which process to run next).

To ensure that each process has its fair share of resources, each will run for a certain period and will eventually stop and then again placed in the queue until it is your turn again. If a program is terminated, so that others can run the program with the highest priority in the current queue is executed.

26: Hotplugx

It's a modified version of Hotplug and optimized for the suspension in off-screen

27: AbyssPlug

It's a Governor derived from hotplug, it works the same way, but with the changes in savings for more battery life.


A very efficient and wide range of Dynamic Clock and Voltage Scaling (DCVS) which addresses usage models from active standby to mid and high level processing requirements. It makes the phone's CPU smoothly scale from low power, from low leakage mode to blazingly fast performance.Only to be used by Qualcomm CPUs.

MSM is the prefix for the SOC (MSM8960) and DCVS is Dynamic Clock and Voltage Scaling. Makes sense, MSM-DCVS

29: IntelliActive

Based off Google's Interactive governor with the following enhancements:

1. self-boost capability from input drivers (no need for PowerHAL assist)
2. two phase scheduling (idle/busy phases to prevent from jumping directly to max freq
3. Checks for offline cpus and short circuits some unnecessary checks to improve code execution paths. Therefore, it avoids CPU hotplugging.

Created by Faux

30: Adaptive

This driver adds a dynamic cpufreq policy governor designed for latency-sensitive workloads and also for demanding performance.

This governor attempts to reduce the latency of clock so that the system is more responsive to interactive workloads in lowest steady-state but to reduce power consumption in middle operation level, level up will be done in step by step to prohibit system from going to
max operation level.


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

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

The Sleepy (formerly known as Solo) is an attempt to strike a balance between performance and battery power to create. It is based on Ondemand. It includes some tweaks like the Down_sampling variable and other features that set by the user through the sysfs of "echo" call. Sleepy is quite similar to Ondemandx.

34: Hyper

The Hyper (formerly known as kenobi) is an aggressive smart and smooth governor based on the Ondemand and is equipped with several features of Ondemandx suspend profiles. It also has the fast_start deep_sleep variable and detection features. In addition, the maximum frequency is in suspend mode 500Mhz 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

The SmartassH3 governor is designed for battery saving and not pushing the phones performance, since doing that drains battery and that's the one thing people keep asking for more of. Based on SmartassV2.

36: SLP

It is a mix of pegasusq and ondemand. Therefore, it has a balance between battery savings and performance.

37: NeoX

An optimized version of the pegasusq governor but with some extra tweaks for better performance. This means slightly more battery drainage than the original PegasusQ but it is still a balanced governor.

38. ZZmanx

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

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)

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

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

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)

A governor based on Smartmax except it's heavily tweaked for better and maximum battery life. This is not a gaming governor!

44. Dance Dance

Based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It is a performance focused governor but also blends with some battery savings.

45. AbyssPlugv2

AbyssPlugv2 is a rewrite of the original CPU governor. It also fixes the problem where the governor is set only for the first core, but now governs all cores right from whatever utility you use. There have been comments on the lack of stability with this governor.

46. IntelliMM

A rewrite of the old Min Max governor and has 3 cpu states: Idle, UI and Max. Intelliminmax (intellimm) governor is designed to work with the newer SOCs with fixed voltage rails (ie MSM8974+ SOCs). It is designed to work within those fixed voltage ranges in order to maximize battery performance while creating a smooth UI operations. It is battery friendly and spends most of the time at lower frequencies.

47. Interactive Pro

A newer (modified) version of interactive which is optimized for devices such as the One Plus One. It is a more efficient than the original Interactive because it continuously re-evaluates the load of each CPU therefore allowing the CPU to scale efficiently.

48. Slim

A new governor from the cm branch and the slimrom project. This is a performance optimized governor and has been tuned a lot for newer devices such as the One Plus One.

49. Ondemand EPS

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

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.
Last edited:


Recognized Contributor
Apr 9, 2014
51. Uberdemand

Uberdemand is Ondemand with 2-phase feature meaning it has a soft cap at 1728 MHz so your cpu won't always go directly to max, made by Chet Kener.

52. Yankactive

A slightly modified interactive based governor by Yank555.lu. It has battery tweaks added onto it so expect better battery life! Based on user reports, this governor behaves more battery friendly than the original interactive governor without sacrificing performance.

53. Impulse

An improved version of interactive modified by neobuddy89. Impulse aims to have a balance between battery and performance just like interactive but has some tweaks to save battery.

54. Bacon

This is nothing but polished interactive governor branded as "bacon" since it was adapted from bacon device thanks to neobuddy89. Most of the tweaks are for performance/latency improvements

55. Optimax governor

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

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

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

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

CPU governor developed by Jamison904. A mix of ConservativeX and Lionheart

60. Blu_active

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

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

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

Simply a lulzactiveq governor with tweaks to performance (thanks to tegrak). This means more performance and less battery life.

64. DevilQ

An aggressive pegasusq governor which keeps the hotplugging at max 2 cpu cores to offline). This is pretty much a more optimized pegasusq for phone's with quad core processors.

65. YankasusQ

Yankasusq is another modified pegasusq but with including screen off freq tunable and some other modifications as well. The difference between PegasusQ and YanksusQ is that it doesn't ramp too aggressively when screen turns on (less battery drainage).

66. Darkness

It's based on nightmare but more simple and fast, basic configs but very complex structure. It is an updated nightmare gov and improved stability, so far it is quite stable in tests

67. Alucard

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

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

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

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

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

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

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

A modded ondemand that is a 2-stage ondemand governor with speed tweaks. It includes imoseyon's screen-off hotplugging code.

75. AggressiveX

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

Tripndroid is based on ondemand with extra tweaks for performance

77. Wrexy

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

A tweaked smartassv2 for better performance. Created by TeamMex.

79. Stockdemand

A heavily modified ondemand for better performance and battery life.

80. Zeneractive

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

An interactive based governor with a more balanced battery life/performance profile

82. Aggressive

Like Lionheart, it is based on conservative, but even more aggressive

83. Intellidemandv2

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

Based on Interactive but with cpu frequency boosting capabilities. This is performance oriented governor.

85. Wave

Based on Conservative with some tweaks for speed and battery. This governor was created by zparallax.

86. Barry-Allen

It's based on interactive. The governor is supposed to be more battery friendly and at the same have good performance.

87. Arteractive

It is an interactive CPU governor port from newer source code. It has more optimizations for Snapdragon 80x processors.

88. Precognition (PrecoGOV)

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

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

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

Full stock (JB) ondemand governor with changed default tunable values aimed at lower battery consumption

92. HyperX

A tweaked interactive based governor for performance.

93. Despair

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

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

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

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

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

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

Lightning is modified darkness gov made by @HridayHS

100. ThunderX

ThunderX is a power saving CPU governor based on SmartAssv2 optimized for Mediatek SoCs.

101. Intel

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

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

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

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

A conservative based governor by frap129 (Electron kernel). It's aims to provide more aggressive battery savings while screen is off.

106. sprdemand

A modded ondemand governor with functionality to offline CPUs when screen is off. It has thermal control logic implemented into the governor.

107. Kraken

Based on ElementalX but with tweaks for better performance while remaining well balanced. Found in Kraken Kernel by Team OctOS.

108. Ironactive

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

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

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

A modified Interactive governor by @CrazyGamerGR that has been biased more towards performance.

112. thenewbeginning

A modified Alucard governor by varunhardgamer that has been biased more towards performance.

113. Cultivation

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

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

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

blu_schedutil is an unmodified version of the Pixel 3 schedutil governor which promises better battery savings over traditional schedutil.

Hotplugging drivers:

1. mpdecision:

Qualcomm's default hotplugging driver. One of the most widely used hotplug drivers in all android devices.


Great battery life, a custom qualcomm based hotplugging driver by myflux. It is a popular choice for many users.

3. intelliplug:

A popular hotplug from faux123 that is highly customisable and provides a great balance between battery and performance.

4. Alucard:

A great hotplugging driver by Alucard. It is known to be very battery friendly on devices.

5. Kt Auto Hotplug:

A great hotplug driver by Ktoonsez. Pretty much a smarter mpdecision that has been optimized for quad-core devices.

6. Mako Hotplug:

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:

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:

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:

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:

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:

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:

Dynamic hotplug from eng.stk's shamu kernel with screenoff battery saving.

13. cpuquiet:

A hotplug driver by NVidia and ported to Snapdragon by maxwen. Originally made for NVidia tegra SOCs. It has a set of governors which keep the CPU running at optimal frequencies for battery and performance.

14. Fast hotplug:

A hotplug driver from pec0ra's abricot kernel. It aims to be as lightweight as possible while also being highly customizable. However, it is still a WIP as it is known to have some stability issues.

15. Hima hotplug:

An optimized hotplug driver based on intelliplug for big.LITTLE architecture. Found on chadouming's HTC One (M9) kernel, it takes advantage of the big and LITTLE CPU cores in order to provide 'butter smooth' performance.

16. State Helper:

A hotplug driver by @neobuddy89 designed with the Nexus 6 in mind. It is highly configurable giving the user control over what CPUs to online based on what battery threshold levels have been set. Another feature that sets state helper apart from other hotplug methods is that it respects the thermal driver.

17. ZZmoove native hotplug:

The hotplugging logic found in the ZZmoove governor. This isn't a standalone hotplug driver that can be used with other governors, the hotplugging is done by the governor which was common on older devices like the Samsung Galaxy S3. Native hotplugging may offer better stability and the governor should perform better in battery life and performance (your experience may vary) because it was designed for this specific governor.

18. Lazyplug

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:

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:

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:

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:

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:

Like the CPU governor, this keeps your GPU running at the lowest possible frequency. Best battery life, extreme lag in games.

6. Adreno Idler:

It is an idling algorithm, an efficient workaround for msm-adreno-tz's overheads. Main goal is to lower the power consumptions while maintaining high-performance. Since msm-adreno-tz tends to *not* use the lowest frequency even on idle, Adreno idler replaces msm-adreno-tz's algorithm when it comes to calculating idle frequency(mostly by ondemand's method). The higher frequencies are not touched with this algorithm, so high-demanding games will (most likely) not suffer from worsened performance.

7. Userspace:

This governor basically allows the user is able to set a desired frequency for the GPU to run at.

8. cpubw_hwmon:

A hardware monitor based governor that attempts to determine bandwidth (BW) needed by CPU and other hardware. Because it samples bandwidth using polling intervals, it has been made to be biased towards performance to compensate for the possible slower response times during heavy loads.

9. MSM Cpufreq:

The MSM CPUfreq governor determines the CPU to DDR bandwidth vote based on the current CPU frequency of all the active CPUs. In other words, this governor scales based on CPU usage which could mean more performance.

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


  • 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
Last edited:


Recognized Contributor
Apr 9, 2014
I/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?

  1. CFQ
  2. Deadline
  3. VR
  4. Noop
  5. BFQ
  6. FIOPS (Fair IOPS)
  7. SIO (Simple I/O)
  8. ROW
  9. ZEN
  10. SIOplus
  11. FIFO (First in First Out)
  12. Tripndroid
  13. Test
  14. Maple

I/O Scheduler Descriptions:

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.

- 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)

- 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.

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.

- 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

- 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.

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.

- Low read latency, better for responsiveness and task switching
- Generally stable, has been adopted in many kernels

- 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.

- Generally low I/O latency, better for responsiveness
- Very stable

- 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.

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.

- Low I/O latency, better responsiveness
- Very low scheduling overhead
- Very stable, used as default for some systems with solid state drives

- 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.

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.

- Generally excels in random writes.

- 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.

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.

- 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

- 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 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.

- Excels in I/O latency, good for responsiveness
- Very stable
- Generally seen as well balanced

- 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.

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).

- Better I/O latency than SIO in certain workloads

- 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.

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.

- Generally has good I/O latency, performs well in some benchmarks
- Like CFQ, has some scheduling overhead

- 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.

- Low I/O latency, better responsiveness
- Very low scheduling overhead
- Very stable, used as default for some systems with solid state drives

- 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.

A new I/O scheduler based on Noop, deadline and vr and meant to have minimal overhead. Made by TripNRaVeR

- 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

- 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.

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.

- Same as Noop, but can be beneficial to kernel developers

- Same as Noop

The bottom line: Shouldn't really be used by anyone. You should be using Noop instead of this.

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.

- Well rounded
- Designed for mobile devices in mind
- Better I/O latency than ZEN in certain workloads

- 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 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.

- Designed for mobile devices in mind
- Possibly more battery savings compared to Maple

- 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


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 :
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:

- 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:
- 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
- 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.au
Last edited:


Recognized Contributor
Apr 9, 2014
CPU 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


i) sampling_rate - Measured in uS , this is how often the kernel look at the CPU usage and make decisions on what to do about the frequency. Higher values means CPU polls less often. For lower frequencies, this could be considered an advantage since it might not jump to next frequency very often, but for higher frequencies, the scale-down time will be increased.

ii) up_threshold - defines what the average CPU usage between the samplings of 'sampling_rate' needs to be for the kernel to make a decision on whether it should increase the frequency. For example when it is set to its default value of '95' it means that between the checking intervals the CPU needs to be on average more than 95% in use to then
decide that the CPU frequency needs to be increased.

iii) powersave_bias - Default value is 0. Setting a higher value will bias the governor towards lower frequency steps. Use this if you want CPU to spend less time on higher frequencies. A better alternative would be to underclock to a lower frequency than using powersave bias.

iv) sampling_down_factor - Determines how often CPU should stay at higher frequencies when truly busy. Default behavior is fast switching to lower frequencies (1). Having sampling_down_factor set to 1 makes no changes from existing behavior (for the non-modified ondemand), but having sampling_down_factor set to a value greater than 1 causes it to act as a multiplier for the scheduling interval for re-evaluating the load when the CPU is at its highest clock frequency (which is scaling_max_freq) due to high load. T

v) down_differential - Indirectly calculates the 'down-threshold' of Ondemand. After completing sampling-down-factor*sampling-rate at max frequency because of high load, governor samples the load again to calculate an estimate of the new target frequency in a way that the lowest frequency will be chosen that would not trigger up_threshold in the next sample. Because triggering up-threshold will again cause CPU to scale up to max frequency. During this choice down_differential is taken into account as a breathing room value. Target frequency is calculated as max_load_freq / (up_threshold - down_differential).

vi) freq_step - Whenever up-scaling logic is triggered the governor instructs the CPU to raise its frequency by freq_step percentage of max allowed frequency. (max policy * (freq step / 100)). Ex: max policy is 1600 and freq step 21%, it will scale 1600 * 21% = 336.

vii) ignore_nice_load - this parameter takes a value of '0' or '1'. When set to '0' (its default), all processes are counted towards the 'cpu utilisation' value. When set to '1', the processes that are run with a 'nice' value will not count (and thus be ignored) in the overall usage calculation. This is useful if you are running a CPU intensive calculation on your laptop that you do not care how long it takes to complete as you can 'nice' it and prevent it from taking part in the deciding process of whether to increase your CPU frequency.

viii) sampling_rate_min -
The sampling rate is limited by the HW transition latency:
transition_latency * 100
Or by kernel restrictions:
If CONFIG_NO_HZ is set, the limit is 10ms fixed.
If CONFIG_NO_HZ is not set or nohz=off boot parameter is used, the
limits depend on the CONFIG_HZ option:
HZ=1000: min=20000us (20ms)
HZ=250: min=80000us (80ms)
HZ=100: min=200000us (200ms)
The highest value of kernel and HW latency restrictions is shown and
used as the minimum sampling rate.

1. Initial Version:-

i) down_sampling_time - Sampling time to scale cpu down.

ii) up_sampling_time - Sampling time to scale cpu up.
2. Second Version (LulzactiveQ):-

i) inc_cpu_load - In previous version, this was 'hard-coded' to 60. Now it's user-configurable. The frequency at which governor scales CPU up/down. Load < inc_cpu_load: cpu scaled down. Load >= inc_cpu_load: cpu scaled up

ii) pump_up_step - No of scale up steps when load >= inc_cpu_load

iii) pump_down_step - No of scale down steps when load < inc_cpu_load

iv) screen_off_min_step - Steps in frequency table to be used when screen-off. Example: If available freqs are 1600 1400 1200 1000 800 500 200 100 (L0 to L7) and screen_off_min_step=5 then 100,200 and 500 (L5 to L7) will be used during screen-off depending on the demand.

v) up_sample_time - Sampling time to scale cpu up. (Allowed values 10,000 to 50,000)

vi) down_sample_time - Sampling time to scale cpu down. (Allowed values 10,000 to 100,000)

i) awake_ideal_freq - The frequency until which CPU is scaled up rapidly on screen-awake (from sleep). Thereafter, scaling up is less aggressive.

ii) sleep_ideal_freq - The frequency until which CPU is scaled down rapidly when screen is turned off. Thereafter, scaling down is less aggressive.

iii) up_rate_us - The minimum amount of time to spend at a frequency before we can ramp up. (Ignored below awake-ideal frequency since governor needs to rapidly scale up to awake_ideal_freq when below it)

iv) down_rate_us - The minimum amount of time to spend at a frequency before we can ramp down. (Ignored above sleep-ideal frequency since governor needs to rapidly scale down to sleep_ideal_freq when above it)

v) max_cpu_load - Same as up_threshold in other governors.

vi) min_cpu_load - Same as down_threshold in other governors.

vii) ramp_down_step - Frequency delta when ramping down below the ideal frequency. Zero disables and will calculate ramp down according to load heuristic. When above the ideal frequency we always ramp down to the ideal freq.

viii) ramp_up_step - Frequency when ramping up above the ideal frequency. Zero disables and causes to always jump straight to max frequency. When below the ideal frequency we always ramp up to the ideal freq.

ix) sleep_wakeup_freq - The frequency to set when waking up from sleep. When sleep_ideal_freq=0 this will have no effect.

Ondemand and conservative have some tunables in common, but with a few extras:

i) freq_step - this describes what percentage steps the cpu freq should be increased and decreased smoothly by. By default the cpu frequency will increase in 5% chunks of your maximum cpu frequency. You can change this value to anywhere between 0 and 100 where '0' will effectively lock your CPU at a speed regardless of its load whilst '100' will, in theory, make
it behave identically to the "ondemand" governor.

ii) down_threshold - same as the 'up_threshold' found for the "ondemand" governor but for the opposite direction. For example when set to its default value of '20' it means that if the CPU usage needs to be below 20% between samples to have the frequency decreased.

1. Generic Version

i) hispeed_freq - An intermediate "hi speed" at which to initially ramp when CPU load hits the value specified in go_hispeed_load. If load stays high for the amount of time specified in above_hispeed_delay, then speed may be bumped higher. Default is the maximum speed allowed by the policy at governor initialization time.

ii) go_hispeed_load - The CPU load at which to ramp to hispeed_freq. Default is 99%.

iii) min_sample_time - The minimum amount of time to spend at the current frequency before ramping down. Default is 80000 uS.

iv) timer_rate - Sample rate for reevaluating CPU load when the CPU is not idle. A deferrable timer is used, such that the CPU will not be woken from idle to service this timer until something else needs to run. (The maximum time to allow deferring this timer when not running at
minimum speed is configurable via timer_slack.) Default is 20000 uS.

v) target_loads - CPU load values used to adjust speed to influence the current CPU load toward that value. In general, the lower the target load, the more often the governor will raise CPU speeds to bring load below the target. The format is a single target load, optionally followed by pairs of CPU speeds and CPU loads to target at or above those speeds. Colons can be used between the speeds and associated target loads for readability. For example:

85 1000000:90 1700000:99

targets CPU load 85% below speed 1GHz, 90% at or above 1GHz, until 1.7GHz and above, at which load 99% is targeted. If speeds are specified these must appear in ascending order. Higher target load values are typically specified for higher speeds, that is, target load values also usually appear in an ascending order. The default is target load 90% for all speeds.

vi) above_highspeed_delay - When speed is at or above hispeed_freq, wait for this long before raising speed in response to continued high load. The format is a single delay value, optionally followed by pairs of CPU speeds and the delay to use at or above those speeds. Colons can be used between the speeds and associated delays for readability. For example:

80000 1300000:200000 1500000:40000

uses delay 80000 uS until CPU speed 1.3 GHz, at which speed delay 200000 uS is used until speed 1.5 GHz, at which speed (and above) delay 40000 uS is used. If speeds are specified these must appear in ascending order. Default is 20000 uS.

vii) timer_slack - Maximum additional time to defer handling the governor sampling timer beyond timer_rate when running at speeds above the minimum. For platforms that consume additional power at idle when CPUs are running at speeds greater than minimum, this places an upper bound on how long the timer will be deferred prior to re-evaluating load and dropping speed. For example, if timer_rate is 20000uS and timer_slack is 10000uS then timers will be deferred for up to 30msec when not at lowest speed. A value of -1 means defer timers
indefinitely at all speeds. Default is 80000 uS.

viii) boost - If non-zero, immediately boost speed of all CPUs to at least hispeed_freq until zero is written to this attribute. If zero, allow CPU speeds to drop below hispeed_freq according to load as usual. Default is zero.

ix) boostpulse - On each write, immediately boost speed of all CPUs to hispeed_freq for at least the period of time specified by boostpulse_duration, after which speeds are allowed to drop below hispeed_freq according to load as usual.

x) boostpulse_duration - Length of time to hold CPU speed at hispeed_freq on a write to boostpulse, before allowing speed to drop according to load as usual. Default is 80000 uS.
2. Qualcomm version/Intelliactive/IntelliMM

Has some tunables in common with the generic version but with a few extras:

i) Sync_freq Feature - This feature will cause a CPU frequency to stay above a particularvalue sync_freq) if certain conditions (determined by the two nodes up_threshold_any_cpu_freq and up_threshold_any_cpu_load) are satisfied

ii) Sync_freq - Only when both of the above conditions are satisfied will the CPU not drop below this frequency value. The higher this value, the higher the frequency to jump will be when the above conditions are satisfied.

iii) Up_threshold_any_cpu_freq - If the maximum frequency across all the CPUs is higher than or equal to this frequency value, do not let the current CPU fall below sync_freq. The higher this value, the fewer the chances to go to sync_freq.

iv) Up_threshold_any_cpu_load - If the maximum load across all the CPUs is higher than or equal to this load value, do not let the current CPU fall below sync_freq. The higher this value, the fewer the chances to go to sync_freq.

v) up_threshold_multi_core - When the up_threshold_multi_core is crossed, the cpu is ramped up to optimal_freq.

vi) optimal_freq - When more than one CPU is online and if up_threshold_multi_core has exceeded, the governor will ramp up the CPU to this frequency. This value should be less than your device's max CPU frequency.

6. Wheatley

target_residency - The minimum average residency in µs which is considered acceptable for a proper efficient usage of the C4 state. Default is 10000 = 10ms.

allowed_misses - The number sampling intervals in a row the average residency is allowed to be lower than target_residency before the governor reduces the frequency. This ensures that the governor is not too aggressive in scaling down the frequency and reduces it just because some background process was temporarily causing a larger number of wakeups. The default is 5.
7. Darkness/Nightmare

cpu_up_rate - No of samples to evaluate load to scale CPU frequency up. Increasing this value will increase the time spent on a frequency.

cpu_down_rate - No of samples to evaluate load to scale CPU frequency down. Increasing this value will increase the time spent on a frequency

inc_cpu_load_at_min_freq - This threshold is used as up threshold while sampling at frequencies is less than freq_for_responsiveness.

inc_cpu_load - The frequency at which governor scales CPU up.

dec_cpu_load - The frequency at which governor scales CPU down.
8. zzmoove

sampling_rate_sleep_multiplier -> sampling rate multiplier on early suspend (possible values 1 or 2, default: 2)

up_threshold_sleep -> up threshold on early suspend (possible range from above 'down_threshold_sleep' up to 100, default: 90)

down_threshold_sleep -> down threshold on early suspend (possible range from 11 to 'under up_threshold_sleep', default: 44)

smooth_up -> smooth up scaling when screen is on (possible range from 1 to 100, default: 100)

smooth_up_sleep -> smooth up scaling on early suspend (possible range from 1 to 100, default: 100)

up_threshold_hotplug x -> hotplug threshold for cpu core x (0 disable core, possible range from 'down_threshold' up to 100, default: 68)

down_threshold_hotplug x -> hotplug threshold for cpu core x (possible range from 1 to under 'up_threshold', default: 55)

block_down_multiplier_hotplug x -> block down multiplier for core x

block_up_multiplier_hotplug x -> block up multiplier for core x

sampling_down_max_momentum -> max sampling down factor which should be set by momentum (0 disable momentum, possible range from sampling_down_factor up to MAX_SAMPLING_DOWN_FACTOR, default 0 disabled)

sampling_down_momentum_sensitivity -> how fast the sampling down factor should be switched (possible values from 1 to 500, default 50)

sampling_down_factor -> depending on which mode is active the factor for sampling rate multiplier which influences the whole sampling rate or the value for stock 'down skip' functionality which influences only the down scaling mechanism (possible values are from 1 to MAX_SMPLING_DOWN_FACTOR, default 1 disabled)

freq_limit_sleep-> limit freqency at early suspend (possible values 0 disable limit, 200-1600, default: 0)

freq_limit -> limit freqency at awake (possible values 0 disable limit, 200-1600, default: 0)

scaling_proportional -> if enabled load-proportional frequencies will be calculated in parallel and will be used in decision for next freq step. after a comparison between normal system table step and proportional step the lowest of these two frequencies will be used for next freq step in both directions. (0 to disable, any value above 0 to enable)

scaling_block_temp -> CPU temperature threshold from where governors freq 'holding' should start. if the given temperature (if CPU temp reading is enabled) is reached the frequency used in tunable 'scaling_block_freq' will be forced targeted and scaling stays on this freq till the temperature is under the threshold again. at the same time hotplugging up work is blocked so in this throttling phase offline cores are staying offline even if the hotplug up thresholds are reached (0 to disable, values between 30 and 80 in °C)

scaling_up_block_cycles -> similar to scaling fastdown but here for a slowdown of up scaling

scaling_up_block_freq -> similar to scaling fastdown but here for a slowdown of up scaling

fast_scaling_up -> Number of scaling jumps only for upscaling when screen on (skip 0-4 frequency steps) or 5 to use autoscaling.

fast_scaling_down -> Number of scaling jumps only for downscaling when screen on (skip 0-4 frequency steps) or 5 to use autoscaling.

fast_scaling_sleep_up -> Number of scaling jumps only for upscaling when screen off (skip 0-4 frequency steps) or 5 to use autoscaling.

fast_scaling_sleep_down -> Number of scaling jumps only for downscaling when screen off (skip 0-4 frequency steps) or 5 to use autoscaling.

disable_hotplug -> switch to enable/disable hotplugging (possible values are any value above 0 to disable hotplugging and 0 to enable it, default 0)

auto_adjust_freq_thresholds -> if enabled all freq thresholds used by the governor will be adjusted accordingly to the new scaling max policy. in particular the thresholds will be increased/decreased by the actual changed max freq step if that change will undercut/exceed the actual min/max freq policy it will stop at the max possible frequency step before undercutting/exceeding min/max freq policy (0 to disable, any value above 0 to enable)

early_demand -> switch to enable/disable early demand functionality (possible values 0 disable or 1 enable, default: 0)

grad_up_threshold -> scale up frequency if the load goes up in one step of grad up value (possible range from 1 to 100, default 50) little example for understanding: when the load rises up in one big 50% step then the frequency will be scaled up immediately instead of wating till up_threshold is reached.

early_demand_sleep -> same function as early demand on awake but in addition combined with fast scaling and sampling rate switch and only active at sleep. (possible values 0 disable or 1 enable, default is 1)

grad_up_threshold_sleep -> 2 way functionality: early demand sleep grad up (load gradient) threshold and at the same time load threshold for switching internally (tuneables are staying at set values!) sampling_rate_sleep_multiplier to 2 and fast_scaling to 2 (possible values from 1 to 100, default is 35)

hotplug_block_up_cycles -> (replaces hotplug_block_cycles) slow down up hotplugging by waiting a given amount of cycles before plugging. possible values 0 disable, any values above 0 (default is 0)

hotplug_block_down_cycles -> (replaces hotplug_block_cycles) slow down down hotplugging by waiting a given amount of cycles before plugging. possible values 0 disbale, any values above 0 (default is 0)

hotplug_idle_freq -> freq at which the idle should be active (possible values 0 disable and any possible scaling freq, default is 0)

sampling_rate_current -> read only and shows currently active sampling rate

sampling_rate_idle -> sampling rate which should be used at 'idle times' (possible values are any sampling rate > 'min_sampling_rate', 0 to disable whole function, default is 0)

sampling_rate_idle_delay -> delay in cycles for switching from idle to normal sampling rate and vice versa (possible values are any value and 0 to disable delay, default is 0)

sampling_rate_idle_threshold -> threshold under which idle sampling rate should be active (possible values 1 to 100, 0 to disable function, default is 0)

scaling_block_cycles -> amount of gradients which should be counted (if block threshold is set) and at the same time up scaling should be blocked and after that a forced down scaling should happen (possible values are any value, 0 to disable that function, default is 0)

scaling_block_freq -> frequency at and above the blocking should be active (possible values are any possible scaling freq, 0 to enable blocking permanently at every frequency, default is 0)

scaling_block_threshold -> gradient (min value) of load in both directions (up/down) to count-up cycles (possible value are 1 to 100, 0 to disable gradient counting)

scaling_block_force_down -> multiplier for the maximal amount of forced down scaling cycles (force down cycles = block_cycles * force_down) therefore the forced down scaling duration (possible value are 2 to any value, 0 to disable forced down scaling and use only scaling up blocks)

profile_number ->
1) for Default (set governor defaults)
2) for Yank Battery -> old untouched setting (a very good battery/performance balanced setting DEV-NOTE: highly recommended!)
3) for Yank Battery Extreme -> old untouched setting (like yank battery but focus on battery saving)
4) for ZaneZam Battery -> old untouched setting (a more 'harsh' setting strictly focused on battery saving DEV-NOTE: might give some lags!)
5) for ZaneZam Battery Plus -> NEW! reworked 'faster' battery setting (DEV-NOTE: recommended too! )
6) for ZaneZam Optimized -> old untouched setting (balanced setting with no focus in any direction DEV-NOTE: relict from back in the days, even though some people still like it!)
7) for ZaneZam Moderate -> NEW! setting based on 'zzopt' which has mainly (but not strictly only!) 2 cores online
8) for ZaneZam Performance -> old untouched setting (all you can get from zzmoove in terms of performance but still has the fast down scaling/hotplugging behaving)
9) for ZaneZam InZane -> NEW! based on performance with new auto fast scaling active. a new experience!
10) for ZaneZam Gaming -> NEW! based on performance with new scaling block enabled to avoid cpu overheating during gameplay
11) for ZaneZam Relax -> NEW! based on moderate (except hotplug settings) with relaxed sleep settings
(since version 0.9 beta4: cpu temperature threshold of 65°C enabled if exynos4 cpu temperature reading support was compiled with the governor)​

scaling_fastdown_freq -> will be enabled once this frequency has been met or exceeded (0 to disable, all possible system frequencies, default is 0)

scaling_fastdown_up_threshold -> once the above frequency threshold has been met, this will become the new up_threshold until we fall below the scaling_fastdown_freq again. (range from over fastdown_down_threshold to 100, default is 95)

scaling_fastdown_down_threshold -> once the above frequency threshold has been met, this will become the new down_threshold until we fall below the scaling_fastdown_freq again. (range from 11 to under fastdown_up_threshold, default is 90)

scaling_responsiveness_freq -> will be enabled once this frequency has been met or exceeded (0 to disable, all possible system frequencies, default is 0)

scaling_responsiveness_up_threshold -> the up_threshold that will take effect if scaling_responsiveness_freq is set (range from 11 to 100, default is 30)

hotplug_engage_freq -> will not bring any cores online until this frequency is met or exceeded
(0 to disable, all possible system frequencies, default is 0)

music_max_freq -> maximum frequency for CPU when governor is on music mode

music_min_cores -> minimum CPU cores used when governor is on music mode

music_min_freq -> minimum frequency for CPU when governor is on music mode

afs_threshold 1,2,3 -> Auto fast scaling for step one to three respectively (range from 1 to 100)
9. Smartmax/Performance May Cry

boost_duration - how long you want the governor to boost your CPU in seconds.

down_rate - The minimum amount of time in nsecs to spend at a frequency before we can ramp down. Notice we ignore this when we are above the ideal frequency.

io_is_busy - Consider if IO is busy

max_cpu_load - CPU freq will be increased if measured load > max_cpu_load

min_cpu_load - CPU freq will be decreased if measured load < min_cpu_load

ramp_up_during_boost - should ramp_up steps during boost be possible

ramp_up_step - Frequency delta when ramping up above the ideal frequency. Zero disables and causes to always jump straight to max frequency. When below the ideal freqeuncy we always ramp up to the ideal freq.

Touch_poke_freq - Also known as the touch boost frequency. This is the frequency that you CPU jumps to when touching screen.
Last edited:


Recognized Contributor
Apr 9, 2014
I/O scheduler tuning guide

Deadline and SIO:

fifo_batch: This parameter controls the maximum number of requests per batch.It tunes the balance between per-request latency and aggregate throughput. When low latency is the primary concern, smaller is better (where a value of 1 yields first-come first-served behavior). Increasing fifo_batch generally improves throughput, at the cost of latency variation. The default is 16.

front_merges: A request that enters the scheduler is possibly contiguous to a request that is already on the queue. Either it fits in the back of that request, or it fits at the front. Hence it’s called either a back merge candidate or a front merge candidate. Typically back merges are much more common than front merges. You can set this tunable to 0 if you know your workload will never generate front merges. Otherwise leave it at its default value 1.

read_expire: In all 3 schedulers, there is some form of deadline to service each Read Request. The focus is read latencies. When a read request first enters the io scheduler, it is assigned a deadline that is the current time + the read_expire value in units of milliseconds. The default value is 500 ms.

write_expire: Similar to Read_Expire, this applies only to the Write Requests. The default value is 5000 ms.

writes_starved: Typically more attention is given to the Read requests over write requests. But this can’t go on forever. So after the expiry of this value, some of the pending write requests get the same priority as the Reads. Default value is 1.
This tunable controls how many read batches can be processed before processing a single write batch. The higher this is set, the more preference is given to reads.


In some cases, the overhead of I/O events contributing to the entropy pool for /dev/random is measurable. In such cases, it may be desirable to set this value to 0.


This tunable is primarily a debugging aid. Most workloads benefit from request merging (even on faster storage such as SSDs). In some cases, however, it is desirable to disable merging, such as when you want to see how many IOPS a storage back-end can process without disabling read-ahead or performing random I/O.


If you have a latency-sensitive application, then you should consider lowering the value of nr_requests in your request queue and limiting the command queue depth on the storage to a low number (even as low as 1), so that writeback I/O cannot allocate all of the available request descriptors and fill up the device queue with write I/O. Once nr_requests have been allocated, all other processes attempting to perform I/O will be put to sleep to wait for requests to become available. This makes things more fair, as the requests are then distributed in a round-robin fashion (instead of letting one process consume them all in rapid succession).


In some circumstances, the underlying storage will report an optimal I/O size. This is most common in hardware and software RAID, where the optimal I/O size is the stripe size. If this value is reported, applications should issue I/O aligned to and in multiples of the optimal I/O size whenever possible.


Traditional hard disks have been rotational (made up of spinning platters). SSDs, however, are not. Most SSDs will advertise this properly. If, however, you come across a device that does not advertise this flag properly, it may be necessary to set rotational to 0 manually; when rotational is disabled, the I/O elevator does not use logic that is meant to reduce seeks, since there is little penalty for seek operations on non-rotational media.

I/O completions can be processed on a different CPU from the one that issued the I/O. Setting rq_affinity to 1 causes the kernel to deliver completions to the CPU on which the I/O was issued. This can improve CPU data caching effectiveness.

back_seek_max: The scheduler tries to guess that the next request for access requires going backwards from current position on the Disc. Given that such going back can be time consuming. So in anticipation, may move back on the disc prior to the next request. This setting, given in Kb, determines the max distance to go back. Default value is set to 16 Kb.
Do note that in a cellphone or tablet, the storage is actually Flash Memory technology. There is Disk head to be re-positioned. As such this is not that effective as backward reads are not that bad.

back_seek_penalty: This parameter is used to compute the cost of backward seeking. If the backward distance of a request is just 1 from a front request, then the seeking cost of the two requests is considered equivalent and the scheduler will not bias toward one or the other. This parameter defaults to 2 so if the distance is only 1/2 of the forward distance, CFQ will consider the backward request to be close enough to the current head location to be “close”. Therefore it will consider it as a forward request.

fifo_expire_async & fifo_expire_sync : This particular parameter is used to set the timeout of asynchronous requests. CFQ maintains a fifo (first-in, first-out) list to manage timeout requests. The default value is 250 ms. A smaller value means the timeout is considered much more quickly than a larger value. Similarly, fifo_expire_sync applies to the Synchronous requests. The default is 125 ms.

group_idle: If this is set, CFQ will idle before executing the last process issuing I/O in a cgroup. This should be set to 1 along with using proportional weight I/O cgroups and setting slice_idle to 0 as Flash memory is a fast storage mechanism.

group_isolation: If set (to 1), there is a stronger isolation between groups at the expense of throughput. If disabled, Scheduler is biased towards sequential requests. When enabled group isolation provides balance for both sequential and random workloads. The default value is 0 (disabled).

low_latency: When set (to 1), CFQ attempts to build a backlog of write requests. It will give a maximum wait time of 300 ms for each process issuing I/O on a device. This offers fairness over throughput. When disabled (set to 0), it will ignore target latency, allowing each process in the system to get a full time slice. This is enabled by default.

Quantum: This option controls the maximum number of requests being processed at a time. The default value is 8. Increasing the value can improve performance; the latency of some I/O may be increased due to more requests being buffered inside the storage.

slice_async: This parameter controls Maximum number of asynchronous requests at a time. The default value is set to 40 ms.

slice_idle: When a task has no more requests to submit in its time slice, the scheduler waits for a while before scheduling the next thread to improve locality. The default value is 0 indicating no idling. However, a zero value increases the overall number of seeks. Hence a Non-zero number may be beneficial.

slice_sync: This setting determines the time slice allotted to a process I/O. The default is 100 ms.

timeout_sync & timeout_async: These parameters determine maximum disk time given to a task, respectively for synchronous and asynchronous queues. It allows the user to control the latencies imposed by the scheduler.

max_budget: This determines, how much of the queue request is serviced based on number of sectors on disc. A larger value increases the throughput for the single tasks and for the system, in proportion to the percentage of sequential requests issued. Consequence is increasing the maximum latency a request may incur in. The default value is 0, which enables auto-tuning

max_budget_async_rq: This setting determines number of async queues served for a maximum number of requests, before selecting a new queue.

low_latency: When this is set to 1 (default is 1), interactive and soft real-time applications experience a lower latency.

hp_read_quantum: Dispatch quantum for the high priority READ queue. Default: 10

rp_read_quantum: Dispatch quantum for the regular priority READ queue. Default: 100

hp_swrite_quantum: Dispatch quantum for the high priority Synchronous WRITE queue. Default: 1

rp_swrite_quantum: Dispatch quantum for the regular priority Synchronous WRITE queue. Default: 1

rp_write_quantum: Dispatch quantum for the regular priority WRITE queue. Default: 1

lp_read_quantum: Dispatch quantum for the low priority READ queue. Default: 1

lp_swrite_quantum: Dispatch quantum for the low priority Synchronous WRITE queue. Default: 1

read_idle: Determines length of idle on read queue in Msec (in case idling is enabled on that queue). Default: 5ms

read_idle_freq: Determines the frequency of inserting READ requests that will trigger idling. This is the time in Msec between inserting two READ requests. Default: 5ms
VR and Zen:

rev_penalty: Penalty for reversing head direction.

fifo_batch: Number of requests to issue before checking for expired requests.

sync_expire: Deadline for synchronous requests.

async_expire: Deadline for asynchronous requests.
Last edited:


Recognized Contributor
Apr 9, 2014
Hotplug tunables guide

NOTE: If you don't have some of these tunables, you might have an older version of the hotplug driver and/or the kernel maintainer has made modifications to it.

Mako Hotplug:

load_threshold: system load threshold to decide when online or offline cores from 0 to 100

high_load_counter: counter to filter online/offline calls. The load needs to be above load_threshold X high_load_counter times for the cores to go online otherwise they stay offline

max_load_counter: max number of samples counters allowed to be counted. The higher thevalue the longer it will take the driver to offline cores after a period of high and continuous load

cpufreq_unplug_limit: if the current CPU freq is above this limit don't offline the cores for a couple of extra samples

min_time_cpu_online: minimum time in seconds that a core stays online to avoid too many online/offline calls

int timer: sample timer in seconds. The default value of 1 equals to 10 samples every second. The higher the value the less samples per second it runs
msm_mpdecision/bricked hotplug

startdelay = time until mpdecision starts doing it's magic (20000)

delay = time between checks (70)

pause = if something else plugs in the cpu, fall asleep for 10000ms (10 secs)

scroff_single_core = if the screen is off, don't plug in cpu1/2/3. Additionally: Unplug all cpus except cpu0 when screen is turned off (1)

enabled = enable(1) or disable(0) mpdecision. This does not affect scroff_single_core!

min_cpus = min cpus to be online, cannot be < 1.

max_cpus = max cpus to be online (if you set it to 2 and min_cpus to 1 you will basically have a dualcore)

idle_freq = a value against that will be checked if a core +/- is requested.

nwns_threshold_x = runqueue threshold, if this is reached cpuX will be hot/unplugged

twts_threshold_x = time threshold, this amount of time must have passed for the related action to be taken (hot/unplug)

max_cpus, min_cpus, scroff_single_core, delay: Look at description above

enabled: Enable/Disable AutoSMP. Y ( for enabled). N (for disabled)

cpufreq_down: Percentage values for downrate limit (range from 0 - 100)

cpufreq_up: Percentage values for uprate limits (range from 0 - 100)

cycle_down: Cycles to wait after the last hotplug event to unplug another core (values 0 1 2 3 4)

cycle_up: Cycles to wait after the last hotplug event to plug another core (values 0 1 2 3 4)
(sourced from defconoi's kernel guide)

Sampling Interval, measured in ms. This factor determines how often the governor should poll for CPU usage in terms of frequency and load percentage to make hotplugging decisions. (Default: 30 ms)

Number of samples to evaluate cpu x hotplug in, where x is greater than or equal to 1.

Number of samples to evaluate cpu x hotplug out

Up threshold frequency to turn core x On, when some other conditions is also met. ie If (minimum frequency greater than or equal to hotplug_freq x 1) Hotplug IN Second Core. Higher value corresponds to delay in turning on second core.

Down threshold frequency to turn core x Off, when some other conditions is also met. ie If (maximum frequency less than hotplug_freq (x+1) 0) Hotplug OUT Second Core. Lower value corresponds to delay in turning off second core.

The CPU load at which governor scales CPU up. Current Load equal or greater than up_load: CPU Hotplug IN. Value corresponding to 101 causes not HOTPLUG IN.

The CPU load at which governor scales CPU down. Current Load less than down_load and CPU online greater than 1: CPU Hotplug OUT. Value corresponding to 101 causes immediately HOTPLUG OUT.

Threshold run queue length for core x to turn on. (Default: 100)

Threshold run queue length for core x to turn off. (Default: 100)

Max CPU's hotplugging limit.

Max CPU's hotplugging limit.
Last edited:


Recognized Contributor
Apr 9, 2014
TCP algorithms guide

What are TCP algorithms?
Congestion control strategies (or algorithms) are used by TCP, the data transmission protocol used by many Internet applications. The main goal of a TCP algorithm is to avoid sending more data than the network is capable of transmitting, that is, to avoid causing network congestion. Different algorithms respond differently to network loads, but they are all based on the same principle of avoiding network congestion.

Things to look out for in TCP algorithms include (but not exclusively):
- Download/Upload speeds - The higher the number, the better
- Latency - The lower the number, the better

TCP Algorithm Descriptions


Limits unknown packets being received. Limits the congestion window, and reset itself to a slow-start state.

Basically the same as Tahoe, but if 3 of the same packets are received, it will halve the window, instead of reducing it to one. It changes the slow start threshold equal to that of the congestion window.

One of the smoothest TCP algorithms(next to cubic), it increases the timeout delay for packets, which allows more to be received, but at a higher rate. It also has set timeouts, which helps with speed because it's constantly being refreshed.

Penalizes connections that use satellite radio. Not usually used with phones.

One of the best, most recommended TCP options available. Less aggressive, Inflects the windows prior to the event. Used in Linux.

A newer version of Reno, and another commonly used one. It controls parameters better, helping out streaming and overall quality of browsing the internet. One of the most 'fair' algorithms out there, and is one of the most efficient algorithms to date.
Low Priority (LP):

A distributed algorithm whose goal is to utilize only the excess network bandwidth as compared to the "fair share" of bandwidth as targeted by TCP. The key mechanisms unique to TCP-LP congestion control are the use of one-way packet delays for early congestion indications and a TCP-transparent congestion avoidance policy.
Binary Increase Congestion control (BIC):

BIC is optimized for high speed networks with high latency: so-called "long fat networks". It has a unique congestion window (cwnd) algorithm. This algorithm tries to find the maximum where to keep the window at for a long period of time, by using a binary search algorithm.

Scalable calls for congestion window to be halved for each packet lost. Effectively, this process keeps halving the throughput until packet loss stops. Once the packet loss subsides, slow start kicks in to ramp the speed back up.
Hamilton TCP (HTCP):

HTCP is designed for high-speed, long distance networks that increases aggressiveness as the time since the previous loss increases. It is thought to be a more efficient TCP algorithm than BIC and HSTCP.

Veno is closely related to Vegas, it is a combination of Vegas and Reno in order to enhance TCP performance over Wireless networks.

Illinois is designed for high-speed, long-distance networks. A sender side modification to the standard TCP congestion control algorithm, it achieves a higher average throughput than the standard TCP and allocates the network resource fairly as the standard TCP.
High speed (HSTCP):

High Speed TCP (HSTCP) is a new congestion control algorithm protocol for TCP. Standard TCP performs poorly in networks with a large bandwidth delay product. It is unable to fully utilize available bandwidth. HSTCP makes minor modifications to standard TCP's congestion control mechanism to overcome this limitation.

A high speed TCP congestion control algorithm which uses a mixed loss/delay approach to calculate congestion windows. Its purpose is to target high efficiency, fairness, and minimizing link loss while keeping network elements load as low as possible.
CAIA-Delay Gradient (CDG) is a new hybrid congestion control algorithm which reacts to both packet loss and queuing delay. It attempts to operate as a delay-based algorithm where possible, but detects loss-based TCP traffic and will switch if required. CDG performs similarly to NewReno and Cubic, but is better at latency.


Latency - Download - Upload


1st run: 15ms - 10,75Mbps - 7,82Mbps
2nd run: 14ms - 10,84Mbps - 8,06Mbps

1st run: 13ms - 15,51Mbps - 6,73Mbps
2nd run: 13ms - 14,73Mbps - 8,51Mbps

1st run: 12ms - 10,38Mbps - 8,61Mbps
2nd run: 13ms - 10,78Mbps - 8,62Mbps

1st run: 11ms - 17,65Mbps - 8,30Mbps
2nd run: 13ms - 13,28Mbps - 8,29Mbps

1st run: 13ms - 10,76Mbps - 7,94Mbps
2nd run: 16ms - 14,42Mbps - 8,52Mbps

1st run: 14ms - 11,19Mbps - 7,44Mbps
2nd run: 14ms - 13,47Mbps - 7,56Mbps

1st run: 14ms - 13,24Mbps - 7,03Mbps
2nd run: 15ms - 10,85Mbps - 8,00Mbps

1st run: 14ms - 8,49Mbps - 6,62Mbps
2nd run: 14ms - 12,00Mbps - 7,07Mbps


1st run: 13ms - 9,58Mbps - 8,13Mbps
2nd run: 13ms - 8,50Mbps - 7,64Mbps

1st run: 18ms - 12,01Mbps - 8,73Mbps
2nd run: 14ms - 13,96Mbps - 8,23Mbps

1st run: 14ms - 14,90Mbps - 8,68Mbps
2nd run: 14ms - 13,44Mbps - 8,72Mbps

1st run: 14ms - 13,37Mbps - 8,28Mbps
2nd run: 17ms - 13,89Mbps - 8,14Mbps

1st run: 13ms - 12,93Mbps - 8,24Mbps
2nd run: 16ms - 13,97Mbps - 6,46Mbps


For speed:
- Westwood - Best
- Highspeed
- LP

For stability:

- Cubic - Best
- Reno

For high latency networks:

- Westwood - Best

For general usage:
- Cubic - Best
- Westwood - Best
- Reno


The only TCP algorithms I would recommend are Cubic or Westwood as they are the most stable and efficient for mobile devices. Real world usage would show little difference when comparing between algorithms, so everyone's experience will vary! There are myths that changing algorithms will affect battery life, this is not true!!!!!

Also, don't be surprised if you end up using Cubic or Westwood!
Last edited:


Recognized Contributor
Apr 9, 2014
Conditions of use

Before everyone starts to copy all of my information I've provided in this guide, please note that I've spend countless hours collecting and refining all of the descriptions and details found from various other guides and comments around the net. I'm not too fussed if people forget to mention credits, but straight copy and pasting the whole guide (verbatim) is what I'm "not OK with". Its not like I can license this information anyway or forcefully prevent others from doing this, but keep this in mind anyway :)

Remember that this info is for free and can be used for your own help and for others if you follow XDA rules and under my conditions!


- Added CPU governor section headings (HMP and EAS)
- Added Multi-queue I/O scheduler section

- Added Anxiety IO scheduler
- Added pwrutilx and blu_schedutil

- Added improved CPU governor recommendations

- Updated I/O scheduler recommendations

- Added description for Cultivation CPU governor
- Added missing governors from governor list on the OP

- Removed governor summaries 
- Adapted the hotplug and GPU governor layout to be the same as the CPU governor layout (no more one liners)
- Added info on the thenewbeginning governor

- Added lazyplug description
- Added crazyactive governor description
- Removed hotplug recommendations (outdated, inaccurate)

- Minor additions to I/O scheduler advantages/disadvantages breakdown
- Minor rewording of I/O scheduler summaries

- Cleaned up the starting paragraphs of the OP (Shortened but also gets the same message that I want)

- Removed multi-core CPU governor selection guide 
- Added EAS governor section
- Simplified I/O scheduler benefits and disadvantages. Removed non-relevant information, added some new ones as well.  

- Removed "what to look out for" sections
- Removed kernel app recommendations
- Removed governor classifications
- Removed generic looking IO sched and TCP alg comparisons - Non-realistic and variable, YMMV
- Made the CPU hotplug guide simpler and easier to read. Updated with better recommendations
- Moved zzmoove profile number info into CPU gov tunable section
- Added a new summary section under all CPU governors to help give a basic comparison between governors - Don't take these indicators as your only deciding factor, ask around as well before using!

- Remove sig from main posts
- Added precaution to recommended governor guide

- Removed some governors from recommended list

- Added descriptions for Nebula and Relaxed CPU governors

- Minor update to Mako hotplug description
- Updated description for Ktoonservative

- Updated description on mako hotplug

- Updated multi-core CPU governor selection guide as per website changes

- Changed recommended I/O read-ahead buffer values for 32GB+ to a more sensible value

- Updated summaries for I/O schedulers

- Updated ElementalX CPU governor description

- Improved 'what to look out for' sections for the CPU governor and I/O scheduler guide

- Added ZZmoove native hotplug description
- Fixed sprdemand governor description

- Huge cleanup to the formatting of this guide. Headings now have bigger font size, excessive bold use removed, minor fixes everywhere else

- Updated interactive tuning guide with additional tunable information

- Added Ironactive CPU governor description

- Added Kraken CPU governor description

- Small correction to 8GB internal/external storage recommended I/O read ahead value

- Updated guide on I/O read ahead buffer 

- Corrected 'ondemand' GPU governor name to 'simple_ondemand'

- Added more detailed and accurate descriptions of existing GPU governors. More GPU governor descriptions will be added later. 

- Minor fixes to ZEN I/O scheduler description
- Added ZEN v2 I/O scheduler description
- Minor update to recommended I/O scheduler list
- Added very detailed description of Maple I/O scheduler thanks to @frap129
- Remove Anticipatory I/O scheduler description
- Updated credits list. Added new credits where applicable. 

- Added sprdemand governor description

- Added Maple I/O scheduler description
- Minor modifications to I/O scheduler summaries

- Added general comments on each scheduler
- Small cleanup to scheduler descriptions

- Added State Helper hotplug information 

- Updated list of recommended apps. Removed all paid options

- Added Chill CPU governor description
- Added Hima hotplug description

- Updated description for Cyan governor 

- Added Intel, Frankenstein, TheSSJactive and Cyan governor descriptions

- Added sched-DVFS governor description 

- Updated recommended CPU governors, removed rating system, combined single-core and multi-core recommended governors into general lists
- Updated recommended I/O schedulers, a few cosmetic fixes
- Simplified CDG TCP algorithm description
- Added Fast hotplug description

- Cleanup to I/O scheduler descriptions. Removed battery factors from advantages. 

- Added ThunderX CPU governor description 

- Added information about cpuquiet

- Initial reorganization of content - Tuning guides have been separated and will soon include examples of profiles
- I/O tuning guide is back! 
- Initial guide for TCP algorithms
- More to come soon ;)

- Many updated tunable descriptions for interactive, ondemand and conservative cpu governors (sourced from the generic android kernel documentation)
- Removed I/O scheduler tuning guide (look at my website link instead)
- Minor changes to zzmoove tunable descriptions

- Added description for lightning governor, thunderplug hotplug and blu_plug hotplug

- Added a bit of info on some tunables for Alucard hotplug. Due to space limitations, you must use my website for the rest of the info.
- Some tunable info was removed either because it was too long (now it would be simplified) or was not used. 

- Added Cafactive governor description

- Added interextrem governor description

- Added descriptions for Despair, Electroactive, Electrodemand and Lionfish CPU governors

- Fixed up ElementalX cpu governor description (was totally wrong before)

- Added HyperX CPU governor description

- Added more info about smartmax and Dyninteractive CPU governor

- Many changes to existing CPU governor descriptions. A lot of irrelevant statements removed

- Added yankdemand CPU governor description
- Fixed credits for intelliplug hotplug

- Added hotplug tunable guide for mako hotplug, msm_mpdecision, bricked hotplug and AutoSMP
- Lots of cleanup to tunable post. All irrelevant information deleted! Now there is more room for more tunable explanations!
- Removed all irrelevant messages in OP. I think it is pretty self-explanatory to use this guide. 
- Added AutoSMP hotplug description from mrg666

- Many changes to IO scheduler information. Most spelling mistakes and incomplete sentences should be fixed now. I removed irrelevant information on some schedulers.  

- Added description for PegasusQPlus CPU governor

- Recommended apps sections improved now with more details on what is free and what is a paid feature
- Recommended apps added to tuning section
- Added more zzmoove variable explanations

- Updated recommended apps to change CPU governors and IO schedulers

- Multiple changes to recommended CPU governors

- Added a few GPU governor descriptions 

- Added information about Mythx_plug CPU governor and msm_sleeper hotplug driver

- Added tunable info for VR io scheduler
- Fixed up Zen io scheduler tunable info (now with VR)
- Updated I/O read ahead section to match with website (Recommendations, rearrange layout)

- Removed sample tweaks to CPU governors
- Added a huge list of zzmoove tunables
- Updated Smartmax tunable info

- Added descriptions for new governors (Arteractive and Precognition)

- Added Adreno Idler GPU governor description
- Bolded GPU governor names

- As requested, I've updated the recommended CPU governors

- Added Barry-Allen CPU governor description

- Multiple changes to hotplug section
- Added a new zzmoove profile descriptions
- Fixed spelling mistake with zzmoove (it is NOT zzmove!)

- Added 1 CPU governor description (Wave)

- Added more hotplug driver descriptions and improved existing hotplug descriptions

- Added Nightmare/Darkness CPU governor tunable descriptions 
- Cleanup to tunable samples 

- More updates to I/O scheduler descriptions

- Most I/O scheduler descriptions have been updated

- Cleanup to recommended CPU governors
- Cleanup of I/O scheduler recommendations 
- Bolded CPU governor names (finally!!!!)

- Fixed misleading information on blu_active governor (Thanks the eng.stk for providing some clarification!)
- Updated a few other CPU governor descriptions

- Cleanup to summary of sections in the posts

- Added a guide for things to look at in CPU governors and I/O schedulers

- Added a few new CPU governor descriptions
- Minor changes to recommended CPU governors

- Added more information on I/O schedulers
- Added a CPU governor
- Added test IO scheduler

- Multiple changes to I/O scheduler advantages and disadvantages
- Links to apps now working now

- Multiple changes to CPU governor descriptions

- Small cleanup to CPU governor names
- Added a CPU governor description
- Small changes to CPU governor descriptions
- Updates to I/O scheduler descriptions

- Cleanup of CPU governor descriptions 
- General fixes to layout for CPU governor hotplugging descriptions

- Added guide to mixed CPU governor arrangements

- Added some CPU governors 
- Updated tweaks guide with some tweak examples of I/O scheduler (sorry for the late change)
- Updated CPU benchmark graphs (Once again, thanks to haldi)

- Cleanup and updates to recommended CPU governors
Things to do:
- Revamp CPU governor guide so it is easier to find governor tweaks (possible with the use of linking) - Shouldn't be too hard
- Update recommendation guides for CPU govs and I/O schedulers so they are more informative, while also having a section for people who can't decide :) 
- Links to governor/IO source code for potential help to kernel developers - Some effort required IMO, possibly not worth doing as it is beyond the scope of this guide
- Group governor description according to their scaling behaviour (e.g. Ondemand-like, conservative-like, etc.) - Will take time, but I will see 
- More that I forgot, but these are the ones that came from the top of my head
- Why don't you ask for me to add something new! :)
Q: Why doesn't my kernel has XYZ governor/scheduler/feature?
A: I wouldn't have a clue. Ask your kernel maintainer. They haven't added it yet or maybe they don't plan on doing so.

Q: I've found similar guides on the net with almost or exactly the same wording, who should I trust?
A: This guide along with my blogger website are the only official guides that should only have this information.

Q: Why are you ripping off other peoples guides?
A: Credits are given where due as detailed in the credits list below.

Q: Can you please add XYZ governor/scheduler/feature to your guide?
A: Sure. Either post in this forum (ehm, please don't quote the whole OP), or throw me a PM.

Q: Man. Your formatting sucks? When will you fix it?
A: Coming soon tm... Kidding, I'm still working on it :)

The credits list:
Stempox - Most old cpu governor descriptions was sourced from his guide
Droidphile - Basically the one of the first people to start these guides. Template for tweak guides.
Haldi - Without haldi, there wouldn't be these awesome graphs :D
Matmutant(Andrux&me) - For his I/O scheduler guides and graphs
Perseus - For several I/O scheduler tweak guides
franciscofranco - For TCP algorithm benchmarks
And all of the other XDA members and other people who came up with some other descriptions that haven't been mentioned.
Last edited:


New member
Apr 17, 2011
can you post some info on governor tuning? specifically ROW... like what all the options are that are available and what they do, and recommended settings?
Sep 17, 2010
Found this informations on a google search yesterday on your site, and i saw alot of it is copied from other places on the net like :
and :
another :
But alot of updated info and i thank you alot for that :good:

But normaly dont we need a source list and a thank you on XDA like links? when something posted that you did not write 100% your self?
  • Like
Reactions: stovo06