[REF][GUIDE]Saber's guide on CPU governors, I/O schedulers and more!

What CPU governor do you use?

  • Ondemand/OndemandX

    Votes: 291 7.4%
  • Interactive/InteractiveX

    Votes: 1,210 30.8%
  • Conservative/Ktoonservative

    Votes: 166 4.2%
  • Performance

    Votes: 224 5.7%
  • Powersave

    Votes: 104 2.6%
  • ZZMoove

    Votes: 162 4.1%
  • Intelliactive/Intellidemand

    Votes: 109 2.8%
  • Hyper

    Votes: 25 0.6%
  • PegasusQ

    Votes: 49 1.2%
  • Impulse

    Votes: 125 3.2%
  • Smartmax/Performance May Cry

    Votes: 72 1.8%
  • ElementalX

    Votes: 209 5.3%
  • Alucard

    Votes: 232 5.9%
  • Yankactive/YanksusQ/Yankdemand

    Votes: 28 0.7%
  • Darkness/Nightmare/Lightning

    Votes: 100 2.5%
  • Blu_active

    Votes: 290 7.4%
  • SmartassV2/SmartassH3

    Votes: 73 1.9%
  • Other

    Votes: 459 11.7%

  • Total voters
    3,928
Search This thread

Viva La Android R.I.P.

Recognized Contributor
Jul 31, 2019
1,648
751
Northeastern Tennessee
LG G Pad 8.3
Moto G
This is perhaps the most comprehensive, informative and factually concise thread I've ever read on XDA. I can certainly tell you spent a great deal of time researching the material and preparing the presentation of the thread. Exceptional work. I just wanted to take a moment to thank you for your hard work and contributions. It is well done.
 

trottling

Member
May 12, 2022
36
27
Russia
Here I don't understand at all, where do kernel developers get planners/governors/hoplugs from?

I'm making my own kernel and I have to use probably already outdated features from other kernels or github commits, because I can't find new ones

Please explain to me
 

aoleary

Senior Member
Nov 16, 2012
1,160
1,053
LG G4c
Redmi K20 Pro
Here I don't understand at all, where do kernel developers get planners/governors/hoplugs from?

I'm making my own kernel and I have to use probably already outdated features from other kernels or github commits, because I can't find new ones

Please explain to me
If you're kernel is 4.x then yeah, most of this stuff is probably a bit out of date.
It's still applicable to 3.x kernels though.
But stay away from the hotplugs. They are totally incompatible now, in my opinion
 

trottling

Member
May 12, 2022
36
27
Russia
I also have links to kernels with governors for my Leeco Le 2 phone for android 9 and 11 on the 3,10,108 core, it just seems to me that they could already be outdated:





And a collection from six years ago:
 

trottling

Member
May 12, 2022
36
27
Russia
Yes, Play4NoobWin, Anubioz and anonymous2ch made good commits, I would also recommend commits to the core from FireLord

Never add new features if you don't fully understand what they do and how they work, and do not forget about the specificity of some to the device

 

varunpilankar

Senior Member
Jul 8, 2012
266
69
Sony Xperia SP
Moto X
Not able find right file/directory to change I/O scheduler on my OnePlus 7

Old command
echo "noop" > /sys/block/mmcblk0/queue/scheduler

Things are very different on modern phones, it's more like legacy linux.

I found multiple directories holding scheduler file


/sys/block/sda/queue/scheduler - (I think this the one, but not sure)
/sys/block/sdb/queue/scheduler
/sys/block/sdc/queue/scheduler
/sys/block/sdd/queue/scheduler
/sys/block/sde/queue/scheduler
/sys/block/sdf/queue/scheduler

Which one to edit? Or edit all of them?
 
Last edited:

aoleary

Senior Member
Nov 16, 2012
1,160
1,053
LG G4c
Redmi K20 Pro
Not able find right file/directory to change I/O scheduler on my OnePlus 7

Old command
echo "noop" > /sys/block/mmcblk0/queue/scheduler

Things are very different on modern phones, it's more like legacy linux.

I found multiple directories holding scheduler file


/sys/block/sda/queue/scheduler - (I think this the one, but not sure)
/sys/block/sdb/queue/scheduler
/sys/block/sdc/queue/scheduler
/sys/block/sdd/queue/scheduler
/sys/block/sde/queue/scheduler
/sys/block/sdf/queue/scheduler

Which one to edit? Or edit all of them?
You could do this (well, the reverse of what I did here) : https://github.com/aoleary/device_lge_g4-common/commit/c47acfeac11de17c411cc0b7f5d299471b0a784f

Or you could just change it in the kernel : https://github.com/aoleary/G4-Titan-Kernel/commit/b16a4db867ca5146cc20b4ccb6df8d667d7cfa8d
 

varunpilankar

Senior Member
Jul 8, 2012
266
69
Sony Xperia SP
Moto X
I'm trying to do it using shell script, as I don't use kernel app.

Also I'm trying find the right i/o scheduler in aim to reduce my android system alarms, check the below screenshot.

After reading more about this issue online, it is mainly coz of jobscheduler queue and schedule_deadline

Also with some log analysis I noticed rouge alarm from

wake: qpnp_rtc_alarm

Am I in the right direction?
 

Attachments

  • Screenshot_20220729-130459.jpg
    Screenshot_20220729-130459.jpg
    272.2 KB · Views: 97
Last edited:

lolvatveo

Senior Member
Nov 1, 2020
314
29
Biên Hòa city
how to edit mpdecision to enable unplug/hotplug cpu core? mpdecision hotplug seems to be disabled in kernel source for my phone.
this is mpdecision info:
Here are all configuration features and their meanings:

  • Single core in standby: Enable or disable to have all cores except one offline while screen's off.
  • Enabled: or disable MPDecision hotplug/unplug control.
  • Start delay: Defines the delay before MPDecision starts controlling cores
  • Interval: Time between each checks
  • Pause: If another app plug a core, MPDecision will stop controlling cores for 10 seconds.
  • Hotplug freq: Min/max frequency to authorize hotplug/unplug
I don't like to add any hotplug driver to my kernel, my kernel aim to be as stock as possible, I just want to edit kernel source code, compile it and add to boot.img then flash.
 

trottling

Member
May 12, 2022
36
27
Russia
are you using OOS with a stock kernel?
as far as I remember there seems to be no noop
I'm trying to do it using shell script, as I don't use kernel app.

Also I'm trying find the right i/o scheduler in aim to reduce my android system alarms, check the below screenshot.

After reading more about this issue online, it is mainly coz of jobscheduler queue and schedule_deadline

Also with some log analysis I noticed rouge alarm from

wake: qpnp_rtc_alarm

Am I in the right direction?
 

Hasan1122behj

Member
Aug 26, 2021
25
1
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:

CFQ:
Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.

Benefits:
- Generally performs the best in throughput tests
- Very stable, is the default Linux kernel I/O scheduler for many desktops and mobile devices
- Performs well on spinning storage and even on solid state storage for mixed workloads
- Generally seen as well balanced
- Processes requiring more I/O resources can be prioritised higher (such as indexing, system maintenance)

Disadvantages:
- I/O latency can be somewhat poor
- There is some scheduling overhead, although probably not too noticeable in tests and real world usage

The bottom line: One of the best all-rounder I/O schedulers available. CFQ is better suited for traditional hard disks, however it may give better throughput under some situations.

Deadline:
The goal of the Deadline scheduler is to attempt to guarantee a start service time for a request. It does that by imposing a deadline on all I/O operations to prevent starvation of requests. It also maintains two deadline queues, in addition to the sorted queues (both read and write). Deadline queues are basically sorted by their deadline (the expiration time), while the sorted queues are sorted by the sector number.

Before serving the next request, the Deadline scheduler decides which queue to use. Read queues are given a higher priority, because processes usually block on read operations. Next, the Deadline scheduler checks if the first request in the deadline queue has expired. Otherwise, the scheduler serves a batch of requests from the sorted queue. In both cases, the scheduler also serves a batch of requests following the chosen request in the sorted queue.

Benefits:
- Excels in reducing latency of any given single I/O
- Can perform better than CFQ in certain workloads
- Performs well in (most) benchmarks
- Generally low scheduling overhead
- Very stable, default in recent Linux kernel versions

Disadvantages:
- Less I/O throughput than CFQ
- No ability to prioritise I/O bound processes over others

The bottom line: A good all-round scheduler. If you want good performance, you should try deadline.


ROW:
The ROW I/O scheduler was developed with the mobile devices needs in mind. In mobile devices, we favor user experience upon everything else, thus we want to give READ I/O requests as much priority as possible. In mobile devices we won't have as much parallel threads as on desktops. Usually it's a single thread or at most 2 simultaneous working threads for read & write. Favoring READ requests over WRITEs decreases the READ latency greatly. The main idea of the ROW scheduling policy is: If there are READ requests in pipe - dispatch them but don't starve the WRITE requests too much.

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

Disadvantages:
- Potentially higher write latency, reducing write performance

The bottom line: It is a good all-round scheduler despite being biased to read operations. Your device may feel more responsive after selecting ROW because it was designed for mobile devices. Older devices may see more of a boost in performance compared to newer devices.

SIO (Simple I/O):
Simple I/O aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority queue concepts, but only basic merging. SIO is a mix between Noop & deadline. No reordering or sorting of requests.

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

Disadvantages:
- Performs poorly in benchmarks

The bottom line: One of my favourite schedulers, it is a good all-round scheduler. People who want better performance should avoid using this.

Noop:
Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.

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

Disadvantages:
- Performs poorly in benchmarks

The bottom line: Modern smartphones now use Noop as the default scheduler due to the fact that it works quite well with flash based storage. However older devices may experience slower performance when selected. If you want a very simple I/O scheduler algorithm (because of battery life or latency reasons), you can select this.

VR:
Unlike other scheduling software, synchronous and asynchronous requests are not handled separately, but it will impose a fair and balanced within this deadline requests, that the next request to be served is a function of distance from the last request.

Benefits:
- Generally excels in random writes.

Disadvantages:
- Sometimes unstable and unreliable

The bottom line: Not the best scheduler to select. You will probably find that other schedulers are performing better while being more stable.

BFQ:
Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.

Benefits:
- Good I/O throughput, sometimes matching CFQ in performance
- Better I/O latency than CFQ, better responsiveness
- Well balanced, even more so than CFQ
- Generally stable, default in some custom kernels and Linux distributions

Disadvantages:
- Performs poorly in benchmarks, sometimes a lot worse in some areas

The bottom line: There are better schedulers out there that will perform better than BFQ. It is quite a complex scheduler that is better designed for traditional hard disks.

ZEN:
ZEN is based on the Noop, Deadline and SIO I/O schedulers. It's an FCFS (First come, first serve) based algorithm, but it's not strictly FIFO. ZEN does not do any sorting. It uses deadlines for fairness, and treats synchronous requests with priority over asynchronous ones. Other than that, it's pretty much the same as Noop blended with VR features.

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

Disadvantages:
- There is some scheduling overhead, but less than CFQ


The bottom line: It is pretty much a better version of VR, performs quite well and is stable. Overall this is a good choice for most smartphones.

SIOplus:
Based on the original SIO scheduler with improvements. Functionality for specifying the starvation of async reads against sync reads; starved write requests counter only counts when there actually are write requests in the queue; fixed a bug).

Benefits:
- Better I/O latency than SIO in certain workloads

Disadvantages:
- Still performs about the same as SIO in benchmarks

The bottom line: If you liked SIO, you will like SIOplus. It performs slightly better in some usage case scenarios, but performance seekers should look else where.

FIOPS (Fair IOPS):
This new I/O scheduler is designed around the following assumptions about Flash-based storage devices: no I/O seek time, read and write I/O cost is usually different from rotating media, time to make a request depends upon the request size, and high through-put and higher IOPS with low-latency. FIOPS (Fair IOPS) I/O scheduler tries to fix the gaps in CFQ. It's IOPS based, so it only targets for drive without I/O seek. It's quite similar like CFQ, but the dispatch decision is made according to IOPS instead of slice.

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

Disadvantages:
- On certain configurations, people may experience issues with stutters in day-to-day device usage
- Not the most stable scheduler

The bottom line: Most people who use FIOPS will get a noticeable performance improvement. However, you may get issues with scrolling and general lags.

FIFO (First in First Out):
First in First Out Scheduler. As the name says, it implements a simple priority method based on processing the requests as they come in.

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

Disadvantages:
- Performs poorly in benchmarks


The bottom line: Like Noop, but is less common. If you want a very simple I/O scheduler algorithm (because of battery life or latency reasons), you can select this.

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

Benefits:
- Excels in I/O latency, good for responsiveness, sometimes better with some tuning
- Should be stable, however is not adopted widely
- Generally seen as well balanced

Disadvantages:
- There is some scheduling overhead, but less than CFQ

The bottom line: Tripndroid isn't very common. There are other schedulers you can choose which may perform similar or better. However it is a good all-round scheduler.

Test:
The test I/O scheduler is a duplicate of the Noop scheduler with addition of test utility. It allows testing a block device by dispatching specific requests according to the test case and declare PASS/FAIL according to the requests completion error code.

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

Disadvantages:
- Same as Noop

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

Maple:
Maple is based on the Zen and Simple I/O schedulers. It uses ZEN's first-come-first-serve style algorithm with separate read/write requests and improved former/latter request handling from SIO. Maple is biased towards handling asynchronous requests before synchronous, and read requests before write. While this can have negative aspects on write intensive tasks like file copying, it slightly improves UI responsiveness. When the device is asleep, maple increases the expiry time of requests so that it can handle them more slowly, causing less overhead.

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

Disadvantages:
- May be unstable on some devices

The bottom line: This is still a very new I/O scheduler which should perform slightly better than ZEN. It will continue to improve with more development.

Anxiety:

Anxiety doesn't separate asynchronous and synchronous requests because asynchronous ones are rarely seen. It prioritizes reads over writes just like Maple, but tends to starve writes more (this is tunable). It is based on noop with a basic first-in-first-out algorithm, whereas Maple is based on deadline with time tracking for expiration. This makes Anxiety better on battery than Maple, as well as fast. It prioritizes latency over throughput which means that requests happen quicker but transfer data slower.

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

Disadvantages:
- Data transfers and write speeds may be slower

Multi-queue schedulers:

If you have a fairly recent phone, the chances are that you are able to use multi-queue (MQ) I/O schedulers. It comes from recent works from the upstream Linux kernel as devices are becoming more powerful with better storage and processors. These schedulers in theory should perform better than your traditional schedulers (e.g. noop, SIO, etc), by having better utilisation of multi-core CPUs/SOCs. You can have a view of some of the descriptions here: Arch Linux wiki.

The bottom line: A good well-rounded I/O scheduler that is relatively simple and performs quite well in most scenarios.

I/O Read Ahead Buffer:

If you've used a custom kernel, you probably have heard of a term called Read Ahead Buffer or Cache. It's basically a cache for files that have been opened recently on your mobile device, so that they can be quickly accessed again if needed. By android default, this value has been set to 128kB. Usually having more buffer means that more files can be cached, this can mean higher read and write speeds, but also this can result in more I/O latency. There is a point where increasing the I/O read ahead will have no benefit to read/write speeds.

Have a look at the graph below:

IO_cache-size.png

Source: http://andrux-and-me.blogspot.com.au/2014/06/various-conditions-and-io-performance.html

Recommendations:

I/O Read Ahead Buffer is dependent on the size of your flash storage (internal/external) unlike I/O schedulers. Below is the recommended settings for the given size that will yield the best performance (differs between setups).

Less than 8GB - 128KB
8GB - 512KB
16GB - 1024KB
32GB or above - 2048KB

Any setting above what I have recommended may yield no extra performance!

If you have issues such as failed reads and writes after changing these values, try a smaller value. Please note that some SD cards may experience issues after setting a higher buffer value.

What to remember:
- More isn't always better!
- Some SD cards can't handle high read ahead cache values, so make sure you have a genuine high quality SD card
- Default is good enough for most people, but isn't the best for performance
- Performance difference varies between devices


Results :
Setup:
Phone: Sony Xperia Z2
Scheduler: as per indicated
Read Ahead: 512kB
App: AndroBench 4

Here is a graph of the performance of the i/o schedulers. Note: a higher score doesn't mean it is the best io scheduler. These numbers mean nothing in real world performance, so take the following a mere glimpse of the performance of schedulers.

Sequential in MB/sec (Higher is better)
bCRBXZi.png



Random in IOPS (Higher is better)
XUlhWl6.png


Thanks haldi for the graphs! Link: http://xdaforums.com/showpost.php?p=58807943&postcount=85

Recommended IO schedulers:

Overall:
- CFQ
- BFQ
- FIOPS
- Deadline

Justification: For overall performance, evidence has shown that some form of scheduling such as seen in CFQ or BFQ is beneficial not only for mechanical drives, but also for solid state media [citation needed]. These schedulers are usually configured to understand the differences between the storage devices, and hence for example will not treat Internal Storage as a traditional rotating hard drive(based on seeks). In smartphones, we do a lot of concurrent I/O multitasking, and hence, schedulers that have some logic to impose fairness will help in this situation

For best performance:
- FIOPS
- BFQ
- CFQ
- Deadline

Justification: Results have shown that schedulers such as CFQ (those that impose some form of fairness) achieve excellent throughput, but the cost of increase scheduling overhead and latency. On modern smartphones, added overhead and latency shouldn't have a significant impact to the responsiveness of the system, since we are dealing with much more powerful CPUs than those of the past. Synthetic benchmarks should not be the deciding factor of a scheduler

For least overhead:
- Noop
- FIFO
- Deadline

Justification: If the only thing you value is lower overheads on I/O processing, your best bet is Deadline. Why? Noop has been recommended on some guide found on the internet for solid state media, however there are known cases where Noop has caused issues in some particular workloads [citation needed]

Source: xda-developers, andrux-and-me.blogspot.com.au
excuse me.
soory to asking this amateur question.🙏
i dont understand the "overhead" means here and dont understand what does " lowering the over head mean 🤷‍♂️
i searched it online but didn't get it ?
may you help me
If the only thing you value is lower overheads on I/O processing, your best bet is Deadline
 

Saber

Inactive Recognized Contributor
Apr 9, 2014
4,046
8,485
Melbourne
joshualay.xyz
Xiaomi Poco F3
excuse me.
soory to asking this amateur question.🙏
i dont understand the "overhead" means here and dont understand what does " lowering the over head mean 🤷‍♂️
i searched it online but didn't get it ?
may you help me
Typically this means that you may see a drop in read/write speeds, although this might not be obvious in your day-to-day phone usage.
 
  • Like
Reactions: aoleary

Hasan1122behj

Member
Aug 26, 2021
25
1
Typically this means that you may see a drop in read/write speeds, although this might not be obvious in your day-to-day phone usage.
thanks . i guess i get part of it 🤔🙏
i just want my phone create less freezing in daily life activity🤔
so does it mean i should practice i/o for performance like cfq or i/o for least overhead
thats what i dont get 🤷
sorry for long question 😔🙏
 

Meshok

Senior Member
Dec 13, 2015
54
2
Could someone explain how the following schedutil tunables affect CPU frequency adjusting in detail, please?

down_rate_limit_us
up_rate_limit_us
hispeed_load
hispeed_freq
target_loads
pl
 

Top Liked Posts

  • There are no posts matching your filters.
  • 633
    Collective guide of CPU governors, I/O schedulers and other kernel variables

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

    Guides:

    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

    Descriptions:

    HMP Governors

    1: OnDemand:

    Description:
    Ondemand is one of the original and oldest governors available on the linux kernel. When the load placed on your CPU reaches the set threshold, the governor will quickly ramp up to the maximum CPU frequency. It has excellent fluidity because of this high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand was commonly chosen by smartphone manufacturers in the past because it is well-tested and reliable, but it is outdated now and is being replaced by Google's Interactive governor.


    2: OndemandX:

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


    3: Performance:

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


    4: Powersave:

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


    5: Conservative:

    Description:
    This governor biases the phone to prefer the lowest possible clockspeed as often as possible. In other words, a larger and more persistent load must be placed on the CPU before the conservative governor will be prompted to raise the CPU clockspeed. Depending on how the developer has implemented this governor, and the minimum clockspeed chosen by the user, the conservative governor can introduce choppy performance. On the other hand, it can be good for battery life.

    The Conservative Governor is also frequently described as a "slow OnDemand". The original and unmodified conservative is slow and inefficient. Newer and modified versions of conservative (from some kernels) are much more responsive and are better all around for almost any use.


    6: Userspace:

    Description:
    This governor, exceptionally rare for the world of mobile devices, allows any program executed by the user to set the CPU's operating frequency. This governor is more common amongst servers or desktop PCs where an application (like a power profile app) needs privileges to set the CPU clockspeed.


    7: Min Max

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


    8: Interactive:

    Description:
    Interactive scales the clockspeed over the course of a timer set by the kernel developer (or user). In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. It is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.

    Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.

    Interactive is the default governor of choice for today's smartphone and tablet manufacturers.

    9: InteractiveX:

    Description:
    Created by kernel developer "Imoseyon," the InteractiveX governor is based heavily on the Interactive governor, enhanced with tuned timer parameters to better balance battery vs. performance. The InteractiveX governor's defining feature, however, is that it locks the CPU frequency to the user's lowest defined speed when the screen is off.


    10: Smartass

    Description:
    Based on interactive, performance is on par with the “old” minmax and smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
    Smartass will also cap the max frequency when sleeping to 352Mhz (or if your min frequency is higher than 352 it will cap it to your min frequency).

    This governor will slowly ramp down frequency when the screen is off and it could also let the frequency go to low making your phone unusable (if min frequency is not checked).

    11: SmartassV2:

    Description:
    Version 2 of the original smartass governor from Erasmux. The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq when screen is on. There's no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery.

    12: Scary

    Description:
    A new governor wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to whatever the kernel developer sets it too and will still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance.


    13: Lagfree:

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


    14: Smoothass:

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


    15: Brazilianwax:

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


    16: SavagedZen:

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


    17: Lazy:

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


    18: Lionheart:

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


    19: LionheartX

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


    20: Intellidemand:

    Description:
    Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode.

    To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) by behaving like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off. Faux no longer recommends intellidemand and believes that intellidemand users should switch to intelliactive for better optimizations and performance.


    21: Hotplug:

    Description:
    The Hotplug governor performs very similarly to the OnDemand governor, with the added benefit of being more precise about how it steps down through the kernel's frequency table as the governor measures the user's CPU load. However, the Hotplug governor's defining feature is its ability to turn unused CPU cores off during periods of low CPU utilization. This is known as "hotplugging."

    22: BadAss:

    Description:
    Badass removes all of this "fast peaking" to the max frequency. To trigger a frequency increase, the system must run a bit with high load, then the frequency is bumped. If that is still not enough the governor gives you full throttle. (this transition should not take longer than 1-2 seconds, depending on the load your system is experiencing)
    Badass will also take the gpu load into consideration. If the gpu is moderately busy it will bypass the above check and clock the cpu to max frequency, If the gpu is crushed under load, badass will lift the restrictions to the cpu.

    23: Wheatley:

    Description:
    Building on the classic 'ondemand' governor is implemented Wheatley governor. The governor has two additional parameters. Wheatley works as planned and does not hinder the proper C4 usage for task where the C4 can be used properly. So the results show that Wheatley works as intended and ensures that the C4 state is used whenever the task allows a proper efficient usage of the C4 state. For more demanding tasks which cause a large number of wakeups and prevent the efficient usage of the C4 state, the governor resorts to the next best power saving mechanism and scales down the frequency. So with the new highly-flexible Wheatley governor one can have the best of both worlds.

    Wheatley is a more performance orientated governor as it scales more aggressively than ondemand and sticks with higher frequencies.

    24:Lulzactive\LulzactiveQ:

    Description:
    It's based on Interactive & Smartass governors.

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

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

    25: Pegasusq/Pegasusd

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

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

    26: Hotplugx

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

    27: AbyssPlug

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

    28: MSM DCVS

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

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

    29: IntelliActive

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

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

    Created by Faux

    30: Adaptive

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

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

    31:Nightmare

    Description:
    A PegasusQ modified, less aggressive and more stable. A good compromise between performance and battery. In addition to the SoD is a prevention because it usually does not hotplug.

    32: ZZmoove

    Description:
    The ZZmoove Governor by ZaneZam is optimized for low power consumption when the screen off, with particular attention to the limitation of consumption applications in the background with the screen off, such as listening to music. The unique feature with ZZmoove is that it has predefined profiles and allows profile switching.

    33: Sleepy

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

    34: Hyper

    Description:
    The Hyper (formerly known as kenobi) is an aggressive smart and smooth governor based on the Ondemand and is equipped with several features of Ondemandx suspend profiles. It also has the fast_start deep_sleep variable and detection features. In addition, the maximum frequency is in suspend mode 500Mhz or whatever the kernel developer sets it to. This is a more smoothness oriented governor which means that it is good for performance, without sacrificing much battery life.

    35: SmartassH3

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

    36: SLP

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

    37: NeoX

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

    38. ZZmanx

    Description:
    ZZmanx is exactly the same as ZZmoove, but it has been renamed because DorimanX made it into his own version (possibly better performance) . However, it still suffers from below average gaming performance. (Refer to ZZmoove description for guide on profiles)

    39. OnDemandPlus

    Description:
    Ondemandplus is an ondemand and interactive-based governor that has additional power-saving capabilities while maintaining very snappy performance. While the interactive governor provides a modern and sleek framework, the scaling logic has been been re-written completely. Reports have found that users find ondemandplus as a more battery friendly governor. In ondemandplus, the downscaling behavior from ondemand is only very slightly modified. However, the upscaling has been modified to not scale up to maximum frequency immediately.

    40. Dynamic Interactive (DynInteractive)

    Description:
    This governor dynamically adjusts itself according to load. That means it's settings are dynamic (always changing) and not static (not changing). Dyninteractive still obtains the same great balance between battery life and performance found in the original interactive governor and improves it even further. This is not the same as the original interactive governor because of this unique behavior.

    41. Smartmax

    Description:
    Smartmax is a mix between ondemand and smartassv2. It behaves mostly like smartass with the concept of an "ideal" frequency. By default this is configured for battery saving, so this is NOT a gaming or benchmark governor! Additionally, to make it "snappy", smartmax has "touch poke". So input events from the touchscreen will boost the cpu for a specific time to a specific frequency. Developed by XDA user Maxwen.

    42. Ktoonservative\KtoonservativeQ

    Description:
    Ktoonservative is based on the Conservative governor, but with the addition of new tunable variables and hotplugging. It aims to be very responsive while also being good at saving battery. This governor is highly configurable and is found in ktoonsez's kernels.

    43. Performance may cry (PMC)

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

    44. Dance Dance

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

    45. AbyssPlugv2

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

    46. IntelliMM

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

    47. Interactive Pro

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

    48. Slim

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

    49. Ondemand EPS

    Description:
    A modified version of Ondemand and is optimized for newer devices. It is based on the Semaphore Kernel's Ondemand which is more optimized for battery life. The EPS at the end stands for Extreme power savings so this governor is biased to power savings!

    50. Smartmax EPS

    Description:
    This governor is based on Smartmax but is optimized for 'Extreme Power Saving' (hence the EPS suffix). This means it uses less battery than the original Smartmax so it is not a very good gaming governor (again!) This is only found on newer devices.
    440
    51. Uberdemand

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

    52. Yankactive

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

    53. Impulse

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

    54. Bacon

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

    55. Optimax governor

    Description:
    Ondemand based with some enhancements from LG, particularly to freq boost handling so it will boost to a set level, almost like HTC's governor. It has different tunables to the HTC governor but it behaves pretty similar, the tunables it comes with default are a bit more conservative. It originates from Cl3kener's Uber kernel for Nexus 5, where it has quite a reputation for battery life

    56. Preservative governor

    Description:
    Preservative is a conservative based governor. The idea is that it will stay at the step specified (702MHz selected by the creator Bedalus) unless needed. You will notice it will hover around 702 a lot, and not go above too much, and only to min freq when NOTHING is happening at all. This is most beneficial when you are doing something like reading; the screen is static or playing light games that won't need boosting any more. The governor comes from Moob kernel for nexus 4

    57. Touchdemand

    Description:
    Touchdemand is based on the ondemand cpu governor but has been modified for the Tegra 3 chip (tablet only) and has additional tweaks for touchscreen responsiveness.

    58. ElementalX

    Description:
    By default, it is more conservative than Ondemand as it does not ramp up often for most phone activities. If there is a graphics load detected, the governor will switch to a two-phase Ondemand behaviour where different max frequencies are used depending on the load increase. ElementalX comes with input boost enabled by default lowering the sampling rate and increasing the frequency to improve responsiveness.

    59. Bioshock

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

    60. Blu_active

    Description:
    A governor developed by eng.stk (featured in his Code_Blue kernels) based on interactive with upstream caf patches and ondemand governor bits too. This governor is mainly focused on performance like the other things the developer creates but it is also well balanced for gaming and general usage.

    61. Umbrella_core

    Description:
    A governor by twisedumbrella based on interactive that is focused on battery life and not performance. It will still ramp up to a set frequency but will not stay at high frequencies for long. This governor tends to stay in high-mid range frequencies during screen_off.

    62. ConservativeX

    Description:
    Developed by Imoseyon (feat. briefly in the Lean Kernel for Galaxy Nexus), the ConservativeX governor behaves like the Conservative governor with the added benefit of locking the CPU frequency to the lowest interval when the screen is off. This governor may additionally perform hotplugging on CPU1, but there is no documentation to confirm that suspicion at this time.

    63. HydrxQ

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

    64. DevilQ

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

    65. YankasusQ

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

    66. Darkness

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

    67. Alucard

    Description:
    Alucard is based on ondemand but has been heavily tweaked to bring better battery life and performance. It has been known to be battery friendly without sacrificing much performance.

    68. Hellsactive

    Description:
    A heavily modified intelliactive governor by @hellsgod that has been tweaked to improve battery life. Hellsactive is less aggressive compared to intelliactive so the battery life will be more like the original interactive.

    69. Ragingmolasses

    Description:
    Besides a gov with an awesome name its a mash up of conservative and ondemand and scales based on load with few tunables. Its meant to be simple, fast, and efficient at keeping the frequency away from the max clock unless it is absolutely needed. it includes gboost for better gaming.

    70. Virtuous

    Description:
    It sets your max cpu for wake and sleep and changes the governor when your device is awake or asleep. It saves battery by lowering cpu frequencies while the device sleeps, when it awakes it automatically speeds it up again. Or alternately you can set the cpu. It is based on smartassV2(It uses 2 governors, one for sleep and other for awake)

    71. Sakuractive

    Description:
    An aggressive hybrid of ondemand and hotplug, which means it will scale like ondemand, except a little more aggressive. But also acts like hotplug as it shuts down multiple CPU cores to save power.

    72. InteractiveX V2

    Description:
    Developed by Imoseyon (feat. in the Lean Kernel for Galaxy Nexus), the InteractiveX V2 governor behaves like InteractiveX, and additionally forces CPU1 into a hotplug state when the screen is off.

    73. Alessa

    Description:
    A less aggressive and more stable ondemand modified by TeamMex. A good compromise between performance and battery. It can be used with the complementary hotplug governor. Please note that this governor is still a WIP!

    74. GallimaufryX

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

    75. AggressiveX

    Description:
    A modded conservative governor but with lots of tweaks to increase snappiness while saving power. It also includes imoseyon's screen-off hotplugging code.

    76. Tripndroid

    Description:
    Tripndroid is based on ondemand with extra tweaks for performance

    77. Wrexy

    Description:
    Wrexy is a conservative based governor but is also similar to the Lionheart gov. It tends to stay out of higher frequencies to favor lower frequencies but performance is not much affected.

    78. Xperience

    Description:
    A tweaked smartassv2 for better performance. Created by TeamMex.

    79. Stockdemand

    Description:
    A heavily modified ondemand for better performance and battery life.

    80. Zeneractive

    Description:
    Based on the interactive governor, it handles frequency scaling the exact same as interactive and has the same tunables as interactive for frequency scaling. However, all of the new hotplugging code is written "from scratch."

    81. InteractiveB

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

    82. Aggressive

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

    83. Intellidemandv2

    Description:
    Much like its predecessor, intellidemandv2 is an intelligent ondemand with browsing detection and scales based on GPU loading. It has been optimized for specific devices and has better battery life and performance.

    84. Boostactive

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

    85. Wave

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

    86. Barry-Allen

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

    87. Arteractive

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

    88. Precognition (PrecoGOV)

    Description:
    PrecoGOV takes over and dynamically adapts to your usage pattern. To achieve such goal, PrecoGOV manages the frequency, idle & sleep patterns, hotplugging, temperature per core and even gpu and tries to help the scheduler as best as it can, all while taking into account battery and thermal constraints.

    89. Mythx_plug

    Description:
    It's based on an improved Interactive governor and has been modified to scale up slower and scale down faster. It is a battery friendly governor.

    90. PegasusQPlus

    Description:
    PegasusQPlus is a heavily tweaked PegasusQ governor, which has been implemented by AndreiLux in his Perseus kernel. PegasusQPlus should have a better balance between performance and battery usage.

    91. Yankdemand

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

    92. HyperX

    Description:
    A tweaked interactive based governor for performance.

    93. Despair

    Description:
    It is a tweaked conservative governor with a couple extra values exposed, it tends to be a bit more conservative with battery than the conservative governor by default. Developed by DespairFactor.

    94. Electroactive

    Description:
    This governor is the replacement over the original electrodemand governor, being much more battery friendly with much smoother transitions compared to the original. It is a hybrid class governor, using a unique way to merge the best of both interactive and ondemand. It includes some extra additions and enhancements to be more battery saving than interactive governor and some boost tunes and additions that allow better power management and performance in games as well as better power saving when in normal use. CPU boost, graphics boost, fast_start deep_sleep and detection features are built in as well as 300 MHz clock speed in suspend.

    95. Electrodemand

    Description:
    Based on the ondemand cpu governor, this is the older governor that was used in the electroactive kernel which uses the same tunables found in the original ondemand governor.

    96. Lionfish

    Description:
    The Lionfish governor combines traits of the conservative, ondemand, and interactive governors. It is designed to maximize battery life without noticeably impacting performance. It responds quickly to heavy loads while staying within the region of optimal CPU performance per watt. With moderate loads, it periodically votes to raise, maintain, or decrease the frequency. When there are enough votes to change the frequency, it is ramped up and down gradually. The voting mechanism reduces frequency jitter compared to ondemand and conservative. squid2's testing had found that this governor uses moderate frequencies (where efficiency is optimal) more effectively than interactive, ondemand, and conservative. This improved frequency distribution results in a moderate reduction in CPU power consumption while maintaining responsiveness comparable to the interactive governor.

    97. Interextrem

    Description:
    A tweaked interactive governor by thehacker911. It is found in hacker kernel s6, where it has been tuned for better performance while still maintaining good battery life.

    98. Cafactive

    Description:
    Found in arter97's kernels, cafactive is the qualcomm optimized version of interactive from CodeAurora. This version promises to bring greatly enhanced performance over samsung's own version of interactive (benchmarks have shown a increase in performance scores), however it may be unstable on some devices and may cause some performance issues under normal and heavy operation.

    99. Lightning

    Description:
    Lightning is modified darkness gov made by @HridayHS

    100. ThunderX

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

    101. Intel

    Description:
    It's an interactive based governor that is optimized for Intel devices. It is thought to be more battery friendly than interactive while still having good performance. Found only on intel based SOCs.

    102. Frankenstein

    Description:
    Based on interactive with hotplugging, it is a performance oriented governor but aims to save battery when screen is off. However, it may be unstable on some devices. Found only on intel based SOCs.

    103. Cyan

    Description:
    Cyan is an interactive based CPU governor intended for heavy gaming and processes. It was originally developed for the i9500, but is now found in kernels for devices with intel SOCs.

    104. TheSSJactive

    Description:
    TheSSJactive is based on yankactive but with the addition of hotplugging support for intel SOCs. It is known to be a battery friendly governor.

    105. Chill

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

    106. sprdemand

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

    107. Kraken

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

    108. Ironactive

    Description:
    Based on the latest CAF 4.4 version of interactive without any additional modifications. It is found in @Tkkg1994's superkernel for the Samsung Galaxy S7.

    109. Nebula

    Description:
    A port of the Interactive governor based on msm-4.4 sources with some mods for the HTC 10, preserving the excellent balance between performance and battery life found in many other Interactive based govs. It originated from Eliminater74's Nebula kernel and was a popular choice prior to the introduction of EAS scheduling to the kernel.

    110. Relaxed

    Description:
    Relaxed is based on chill, and has been altered in order to achieve more gradual frequency boosting providing battery life benefits. Relaxed uses a boost ceiling variable in order to achieve this. Rather than boosting straight to the max frequency, relaxed finds the difference between boost_counter and boost_ceiling, then boosts to max minus that difference. This governor doesn't completely replace chill, but is intended to be used alongside it.

    111. Crazyactive

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

    112. thenewbeginning

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

    113. Cultivation

    Description
    A highly modified interactive-based governor with the intention of giving the user more control by providing more tuning options. Based on CAF 4.4 commits with parts coming from blu_active and XDA user Sultanxda.

    EAS Governors

    114. schedutil

    Description:
    schedutil is a new EAS governor found in recent versions of the Linux Kernel (4.7+) that aims to integrate better with the Linux Kernel scheduler. It uses the kernel's scheduler to receive CPU utilisation information and make decisions from this input. As a direct result, schedutil can respond to CPU load faster and more accurate than normal governors such as Interactive that rely on timers.

    115. pwrutilx

    Description:
    A new EAS governor based on schedutil that aims to be much more efficient by using a different formula to get next frequency.

    116. blu_schedutil

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

    Hotplugging drivers:

    1. mpdecision:

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

    2.msm_hotplug:

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

    3. intelliplug:

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

    4. Alucard:

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

    5. Kt Auto Hotplug:

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

    6. Mako Hotplug:

    Description:
    A popular hotplug driver found in Franco kernel. Franco didn't like how closed sourced MPdecision worked and so he created this driver as a direct replacement. It always keep 2 cores online and will online additional cores based on load conditions.

    7. Zen Decision:

    Description:
    ZEN only onlines all cores when screen is on, it also takes thermal events into account and wont online any core back, if you're under 15% battery, or currently have a thermal event because of heat. So in the end it isn't a "real" hotplug driver, because it doesnt have any code for active hot plugging in it. That means you can't change its behavior.

    8. Bricked Hotplug:

    Description:
    Conservative hotplug driver by @show-p1984. It is based on mpdecision but has been optimized for better balance between battery life and performance.

    9. msm_sleeper:

    Description:
    The main feature with this hotplug is that you can customize the screen off frequency. Two cores are always on, the third and fourth are independent and come online if needed. By default, if the load is over 80 for 400ms another core comes online. The third and/or fourth cores stay online as long as the load demands it or for a minimum of one second. While the screen is off, it goes down to a single core. Created by flar2.

    10. Autosmp:

    Description:
    A highly-efficient hotplug driver by @mrg666, works in-sync with the CPU governor to enable off-line cpu cores when the the CPU frequency reaches a high threshold and still more compute power is needed. Therefore, touch boost bloat is removed.

    11. Thunderplug:

    Description:
    A matured load-based hotplug driver with many tunables written from ground up by varun.chitre15. This hotplug is optimized for octa-core devices and also has support for 64bit CPUs.

    12. Blu_plug:

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

    13. cpuquiet:

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

    14. Fast hotplug:

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

    15. Hima hotplug:

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

    16. State Helper:

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

    17. ZZmoove native hotplug:

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

    18. Lazyplug

    Description:
    A hotplug from arter97 that leaves CPU cores on for most of the time with the exception of some situations where leaving all cores on could be battery draining (e.g. Video playback). The purpose behind this is to improve performance & battery life by removing excess CPU overheads caused by unnecessary hotplugging where similar techniques are already employed in Samsung and Nexus firmwares.


    GPU governors

    1. Simple:

    Description:
    An open-source alternative to Qualcomm's closed-sourced governors. Developed by Faux123, it is highly customisable which will allow more fine-grained control over how the GPU scales up and down.

    2. simple_ondemand:

    Description:
    As the name implies, it is a simpler version of the CPU governor ondemand. simple_ondemand will ramp up the frequency when a load is detected. It has a good balance between performance and battery savings.

    3. msm-adreno-tz:

    Description:
    The default GPU governor used by Qualcomm for their adreno GPUs. It is based on the ondemand governor but is biased towards performance, therefore it should give better performance in games but less battery life.

    4. Performance:

    Description:
    As the name suggests, this keeps your GPU running at the max frequency. This is a governor if you want the best possible experience in games but you don't care about your battery life.

    5. Powersave:

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

    6. Adreno Idler:

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

    7. Userspace:

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

    8. cpubw_hwmon:

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

    9. MSM Cpufreq:

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


    Benchmark graphs:

    cpu_benchmark1.png


    Link to raw data: https://drive.google.com/file/d/0B3ApZsjOd2bzWDRnQjRsUTlLSlE/view?usp=sharing

    Here are more graphs (thanks to Haldi!)

    PbtNyab.png

    Having trouble seeing the graph above? Here is the direct link to the image: http://i.imgur.com/PbtNyab.png

    y9W3Z2T.png


    For more info about Haldi's benchmarks, visit here: http://xdaforums.com/showthread.php?t=2768979

    Recommendations

    Overall:
    • Interactive (or balanced variants)
    • zzmoove (default or optimized profile)
    • Ondemand
    • PegasusQ (Works well on some older devices)
    • Impulse

    Battery Saving:
    • Conservative (tuned, or battery saving variants)
    • Ondemand (tuned, or battery saving variants)
    • Smartmax
    • Powersave
    • Alucard
    • zzmoove (tuned, change to battery profile)

    Performance oriented:
    • Interactive (tuned, or performance oriented variants)
    • Intelliactive (preferred over intellidemand)
    • Performance
    • Nightmare
    • Blu_active
    • Lionheart
    437
    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:

    CFQ:
    Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.

    Benefits:
    - Generally performs the best in throughput tests
    - Very stable, is the default Linux kernel I/O scheduler for many desktops and mobile devices
    - Performs well on spinning storage and even on solid state storage for mixed workloads
    - Generally seen as well balanced
    - Processes requiring more I/O resources can be prioritised higher (such as indexing, system maintenance)

    Disadvantages:
    - I/O latency can be somewhat poor
    - There is some scheduling overhead, although probably not too noticeable in tests and real world usage

    The bottom line: One of the best all-rounder I/O schedulers available. CFQ is better suited for traditional hard disks, however it may give better throughput under some situations.

    Deadline:
    The goal of the Deadline scheduler is to attempt to guarantee a start service time for a request. It does that by imposing a deadline on all I/O operations to prevent starvation of requests. It also maintains two deadline queues, in addition to the sorted queues (both read and write). Deadline queues are basically sorted by their deadline (the expiration time), while the sorted queues are sorted by the sector number.

    Before serving the next request, the Deadline scheduler decides which queue to use. Read queues are given a higher priority, because processes usually block on read operations. Next, the Deadline scheduler checks if the first request in the deadline queue has expired. Otherwise, the scheduler serves a batch of requests from the sorted queue. In both cases, the scheduler also serves a batch of requests following the chosen request in the sorted queue.

    Benefits:
    - Excels in reducing latency of any given single I/O
    - Can perform better than CFQ in certain workloads
    - Performs well in (most) benchmarks
    - Generally low scheduling overhead
    - Very stable, default in recent Linux kernel versions

    Disadvantages:
    - Less I/O throughput than CFQ
    - No ability to prioritise I/O bound processes over others

    The bottom line: A good all-round scheduler. If you want good performance, you should try deadline.


    ROW:
    The ROW I/O scheduler was developed with the mobile devices needs in mind. In mobile devices, we favor user experience upon everything else, thus we want to give READ I/O requests as much priority as possible. In mobile devices we won't have as much parallel threads as on desktops. Usually it's a single thread or at most 2 simultaneous working threads for read & write. Favoring READ requests over WRITEs decreases the READ latency greatly. The main idea of the ROW scheduling policy is: If there are READ requests in pipe - dispatch them but don't starve the WRITE requests too much.

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

    Disadvantages:
    - Potentially higher write latency, reducing write performance

    The bottom line: It is a good all-round scheduler despite being biased to read operations. Your device may feel more responsive after selecting ROW because it was designed for mobile devices. Older devices may see more of a boost in performance compared to newer devices.

    SIO (Simple I/O):
    Simple I/O aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority queue concepts, but only basic merging. SIO is a mix between Noop & deadline. No reordering or sorting of requests.

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

    Disadvantages:
    - Performs poorly in benchmarks

    The bottom line: One of my favourite schedulers, it is a good all-round scheduler. People who want better performance should avoid using this.

    Noop:
    Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.

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

    Disadvantages:
    - Performs poorly in benchmarks

    The bottom line: Modern smartphones now use Noop as the default scheduler due to the fact that it works quite well with flash based storage. However older devices may experience slower performance when selected. If you want a very simple I/O scheduler algorithm (because of battery life or latency reasons), you can select this.

    VR:
    Unlike other scheduling software, synchronous and asynchronous requests are not handled separately, but it will impose a fair and balanced within this deadline requests, that the next request to be served is a function of distance from the last request.

    Benefits:
    - Generally excels in random writes.

    Disadvantages:
    - Sometimes unstable and unreliable

    The bottom line: Not the best scheduler to select. You will probably find that other schedulers are performing better while being more stable.

    BFQ:
    Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.

    Benefits:
    - Good I/O throughput, sometimes matching CFQ in performance
    - Better I/O latency than CFQ, better responsiveness
    - Well balanced, even more so than CFQ
    - Generally stable, default in some custom kernels and Linux distributions

    Disadvantages:
    - Performs poorly in benchmarks, sometimes a lot worse in some areas

    The bottom line: There are better schedulers out there that will perform better than BFQ. It is quite a complex scheduler that is better designed for traditional hard disks.

    ZEN:
    ZEN is based on the Noop, Deadline and SIO I/O schedulers. It's an FCFS (First come, first serve) based algorithm, but it's not strictly FIFO. ZEN does not do any sorting. It uses deadlines for fairness, and treats synchronous requests with priority over asynchronous ones. Other than that, it's pretty much the same as Noop blended with VR features.

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

    Disadvantages:
    - There is some scheduling overhead, but less than CFQ


    The bottom line: It is pretty much a better version of VR, performs quite well and is stable. Overall this is a good choice for most smartphones.

    SIOplus:
    Based on the original SIO scheduler with improvements. Functionality for specifying the starvation of async reads against sync reads; starved write requests counter only counts when there actually are write requests in the queue; fixed a bug).

    Benefits:
    - Better I/O latency than SIO in certain workloads

    Disadvantages:
    - Still performs about the same as SIO in benchmarks

    The bottom line: If you liked SIO, you will like SIOplus. It performs slightly better in some usage case scenarios, but performance seekers should look else where.

    FIOPS (Fair IOPS):
    This new I/O scheduler is designed around the following assumptions about Flash-based storage devices: no I/O seek time, read and write I/O cost is usually different from rotating media, time to make a request depends upon the request size, and high through-put and higher IOPS with low-latency. FIOPS (Fair IOPS) I/O scheduler tries to fix the gaps in CFQ. It's IOPS based, so it only targets for drive without I/O seek. It's quite similar like CFQ, but the dispatch decision is made according to IOPS instead of slice.

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

    Disadvantages:
    - On certain configurations, people may experience issues with stutters in day-to-day device usage
    - Not the most stable scheduler

    The bottom line: Most people who use FIOPS will get a noticeable performance improvement. However, you may get issues with scrolling and general lags.

    FIFO (First in First Out):
    First in First Out Scheduler. As the name says, it implements a simple priority method based on processing the requests as they come in.

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

    Disadvantages:
    - Performs poorly in benchmarks


    The bottom line: Like Noop, but is less common. If you want a very simple I/O scheduler algorithm (because of battery life or latency reasons), you can select this.

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

    Benefits:
    - Excels in I/O latency, good for responsiveness, sometimes better with some tuning
    - Should be stable, however is not adopted widely
    - Generally seen as well balanced

    Disadvantages:
    - There is some scheduling overhead, but less than CFQ

    The bottom line: Tripndroid isn't very common. There are other schedulers you can choose which may perform similar or better. However it is a good all-round scheduler.

    Test:
    The test I/O scheduler is a duplicate of the Noop scheduler with addition of test utility. It allows testing a block device by dispatching specific requests according to the test case and declare PASS/FAIL according to the requests completion error code.

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

    Disadvantages:
    - Same as Noop

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

    Maple:
    Maple is based on the Zen and Simple I/O schedulers. It uses ZEN's first-come-first-serve style algorithm with separate read/write requests and improved former/latter request handling from SIO. Maple is biased towards handling asynchronous requests before synchronous, and read requests before write. While this can have negative aspects on write intensive tasks like file copying, it slightly improves UI responsiveness. When the device is asleep, maple increases the expiry time of requests so that it can handle them more slowly, causing less overhead.

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

    Disadvantages:
    - May be unstable on some devices

    The bottom line: This is still a very new I/O scheduler which should perform slightly better than ZEN. It will continue to improve with more development.

    Anxiety:

    Anxiety doesn't separate asynchronous and synchronous requests because asynchronous ones are rarely seen. It prioritizes reads over writes just like Maple, but tends to starve writes more (this is tunable). It is based on noop with a basic first-in-first-out algorithm, whereas Maple is based on deadline with time tracking for expiration. This makes Anxiety better on battery than Maple, as well as fast. It prioritizes latency over throughput which means that requests happen quicker but transfer data slower.

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

    Disadvantages:
    - Data transfers and write speeds may be slower

    Multi-queue schedulers:

    If you have a fairly recent phone, the chances are that you are able to use multi-queue (MQ) I/O schedulers. It comes from recent works from the upstream Linux kernel as devices are becoming more powerful with better storage and processors. These schedulers in theory should perform better than your traditional schedulers (e.g. noop, SIO, etc), by having better utilisation of multi-core CPUs/SOCs. You can have a view of some of the descriptions here: Arch Linux wiki.

    The bottom line: A good well-rounded I/O scheduler that is relatively simple and performs quite well in most scenarios.

    I/O Read Ahead Buffer:

    If you've used a custom kernel, you probably have heard of a term called Read Ahead Buffer or Cache. It's basically a cache for files that have been opened recently on your mobile device, so that they can be quickly accessed again if needed. By android default, this value has been set to 128kB. Usually having more buffer means that more files can be cached, this can mean higher read and write speeds, but also this can result in more I/O latency. There is a point where increasing the I/O read ahead will have no benefit to read/write speeds.

    Have a look at the graph below:

    IO_cache-size.png

    Source: http://andrux-and-me.blogspot.com.au/2014/06/various-conditions-and-io-performance.html

    Recommendations:

    I/O Read Ahead Buffer is dependent on the size of your flash storage (internal/external) unlike I/O schedulers. Below is the recommended settings for the given size that will yield the best performance (differs between setups).

    Less than 8GB - 128KB
    8GB - 512KB
    16GB - 1024KB
    32GB or above - 2048KB

    Any setting above what I have recommended may yield no extra performance!

    If you have issues such as failed reads and writes after changing these values, try a smaller value. Please note that some SD cards may experience issues after setting a higher buffer value.

    What to remember:
    - More isn't always better!
    - Some SD cards can't handle high read ahead cache values, so make sure you have a genuine high quality SD card
    - Default is good enough for most people, but isn't the best for performance
    - Performance difference varies between devices


    Results :
    Setup:
    Phone: Sony Xperia Z2
    Scheduler: as per indicated
    Read Ahead: 512kB
    App: AndroBench 4

    Here is a graph of the performance of the i/o schedulers. Note: a higher score doesn't mean it is the best io scheduler. These numbers mean nothing in real world performance, so take the following a mere glimpse of the performance of schedulers.

    Sequential in MB/sec (Higher is better)
    bCRBXZi.png



    Random in IOPS (Higher is better)
    XUlhWl6.png


    Thanks haldi for the graphs! Link: http://xdaforums.com/showpost.php?p=58807943&postcount=85

    Recommended IO schedulers:

    Overall:
    - CFQ
    - BFQ
    - FIOPS
    - Deadline

    Justification: For overall performance, evidence has shown that some form of scheduling such as seen in CFQ or BFQ is beneficial not only for mechanical drives, but also for solid state media [citation needed]. These schedulers are usually configured to understand the differences between the storage devices, and hence for example will not treat Internal Storage as a traditional rotating hard drive(based on seeks). In smartphones, we do a lot of concurrent I/O multitasking, and hence, schedulers that have some logic to impose fairness will help in this situation

    For best performance:
    - FIOPS
    - BFQ
    - CFQ
    - Deadline

    Justification: Results have shown that schedulers such as CFQ (those that impose some form of fairness) achieve excellent throughput, but the cost of increase scheduling overhead and latency. On modern smartphones, added overhead and latency shouldn't have a significant impact to the responsiveness of the system, since we are dealing with much more powerful CPUs than those of the past. Synthetic benchmarks should not be the deciding factor of a scheduler

    For least overhead:
    - Noop
    - FIFO
    - Deadline

    Justification: If the only thing you value is lower overheads on I/O processing, your best bet is Deadline. Why? Noop has been recommended on some guide found on the internet for solid state media, however there are known cases where Noop has caused issues in some particular workloads [citation needed]

    Source: xda-developers, andrux-and-me.blogspot.com.au
    277
    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

    1. ONDEMAND

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

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

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

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

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

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

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

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

    2. LULZACTIVEQ

    1. Initial Version:-

    [ PARAMETERS ]
    i) down_sampling_time - Sampling time to scale cpu down.

    ii) up_sampling_time - Sampling time to scale cpu up.

    2. Second Version (LulzactiveQ):-

    [ PARAMETERS ]
    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)
    3. SMARTASSV2

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

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

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

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

    v) max_cpu_load - Same as up_threshold in other governors.

    vi) min_cpu_load - Same as down_threshold in other governors.

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

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

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

    4. CONSERVATIVE

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

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

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

    5. INTERACTIVE

    1. Generic Version

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

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

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

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

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

    85 1000000:90 1700000:99

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

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

    80000 1300000:200000 1500000:40000

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

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

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

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

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

    2. Qualcomm version/Intelliactive/IntelliMM

    [ PARAMETERS ]
    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

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

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

    7. Darkness/Nightmare

    [ PARAMETERS ]
    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

    [ PARAMETERS ]
    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

    [ PARAMETERS ]
    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.
    263
    I/O scheduler tuning guide

    Deadline and SIO:

    [ PARAMETERS ]
    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.

    Noop:

    [ PARAMETERS ]
    add_random

    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.

    nomerges

    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.

    nr_requests

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

    optimal_io_size

    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.

    rotational

    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.

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

    CFQ:

    [ PARAMETERS ]
    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.

    BFQ:

    [ PARAMETERS ]
    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.

    ROW:

    [ PARAMETERS ]
    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:

    [ PARAMETERS ]
    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.