First, let's start with "governors."
OnDemand:
The default governor in almost all stock kernels. One main goal of the ondemand governor is to switch to max frequency as soon as CPU activity is detected to ensure the responsiveness of the system. Effectively, it uses the CPU busy time as the answer to the "how critical is performance right now" question. So Ondemand jumps to maximum frequency when CPU is busy and decreases the frequency gradually when CPU is less loaded/apporaching idle. Even though many of us consider this a reliable governor, it falls short on battery saving and performance on default settings. One potential reason for ondemand governor being not very power efficient is that the governor decides the next target frequency by instant requirement during sampling interval. The instant requirement can respond quickly to workload change, but it does not usually reflect workload real CPU usage requirement in a longer time and it possibly causes frequent changes between highest and lowest frequency.
Smartass2:
Version 2 of the original smartass governor from Erasmux. Another favorite for many people. The governor aims for an "ideal frequency", and ramps 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.
Performance:
Sets min frequency as max frequency. Very useful while benchmarking!
Interactive Governor:
Much like the OnDemand governor, the Interactive governor dynamically scales CPU clockspeed in response to the workload placed on the CPU by the user. This is where the similarities end. Interactive is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Unlike OnDemand, which you'll recall scales clockspeed in the context of a work queue, Interactive scales the clockspeed over the course of a timer set arbitrarily by the kernel developer. In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. This can eliminate the frequency bouncing discussed in the OnDemand section. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. This is another pro-battery life benefit of Interactive.
However, because Interactive is permitted to spend more time at maximum frequency than OnDemand (for device performance reasons), the battery-saving benefits discussed above are effectively negated. Long story short, Interactive offers better performance than OnDemand (some say the best performance of any governor) and negligibly different battery life.
Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.
InteractiveX Governor:
Created by kernel developer "Imoseyon," the InteractiveX governor is based heavily on the Interactive governor, enhanced with tuned timer parameters to better balance battery vs. performance. The InteractiveX governor's defining feature, however, is that it locks the CPU frequency to the user's lowest defined speed when the screen is off.
Hotplug Governor:
The Hotplug governor performs very similarly to the OnDemand governor, with the added benefit of being more precise about how it steps down through the kernel's frequency table as the governor measures the user's CPU load. However, the Hotplug governor's defining feature is its ability to turn unused CPU cores off during periods of low CPU utilization. This is known as "hotplugging."
Obviously, this governor is only available on multi-core devices.
OndemandX:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
Now for the "schedulers."
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 a flash drive). Advantage here is that flash drives do not require reordering of multiple I/O requests unlike in normal hard drives.
*Advantages*
1. Serves I/O requests with least number of cpu cycles. (Battery friendly?)
2. Best for flash drives since there is no seeking penalty.
3. Good throughput on db systems.
*Disadvantages*
1. Reduction in number of cpu cycles used is proportionate to drop in performance.Deadline:
Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.
*Advantages*
1. Nearly a real time scheduler.2. Excels in reducing latency of any given single I/O.
3. Best scheduler for database access and queries.
4. Bandwidth requirement of a process - what percentage of CPU it needs, is easily calculated.
5. Like noop, a good scheduler for solid state/flash drives.
*Disadvantages*
1. When the system is overloaded, the set of processes that may miss deadline is largely unpredictable.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.
*Advantages*
1. Considered to deliver a better balanced i/o performance.2. Easiest to tune.
3. Excels on multiprocessor systems.
4. Best database system performance after deadline.
*Disadvantages*
1. Some users report that media scanning takes longer to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.2. Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.
SIO:
Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. SIO is a mix between noop & deadline. No reordering or sorting of requests.
*Advantages*
1. Simple, very very reliable.2. Minimized starvation of requests.
*Disadvantages*
1. Slow random-read speeds on flash drives, compared to other schedulers.2. Sequential-read speeds on flash drives also not so good.
