First off, you all should know that EVERYTHING pretty much has a kernel.
Second, there are a total of about 20-25 Governors in total about now, maybe 21-22.
List that One V currently have
- 1) Ondemand
- 3) Interactive
- 4) Interactivex
- 5) SmartassV2
- 6) Lionheart
- 7) SavagedZen
- 8) Powersave
- 9) Performance
- 10) Scary
Default governor in almost all stock kernels. One main goal of the ondemand governor is to switch to max frequency as soon as there is a CPU activity detected to ensure the responsiveness of the system. Effectively, it uses the CPU busy time as the answer to “how critical is performance right now” question. So Ondemand jumps to maximum frequency when CPU is busy and decreases the frequency gradually when CPU is less loaded/apporaching idle.
A slower Ondemand which scales up slowly to save battery. The conservative governor is based on the ondemand governor. It functions like the Ondemand governor by dynamically adjusting frequencies based on processor utilization. However, the conservative governor increases and decreases CPU speed more gradually. Simply put, this governor increases the frequency step by step on CPU load and jumps to lowest frequency on CPU idle.
Can be considered a faster ondemand. So more snappier, less battery. Interactive is designed for latency-sensitive, interactive workloads. Instead of sampling at every interval like ondemand, it determines how to scale up when CPU comes out of idle.
This is an Interactive governor with a wake profile. More battery friendly than interactive.
Version 2 of the original smartass governor from Erasmux. Another favorite for many a people. The governor aim for an “ideal frequency”, and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for GS2 by default) when screen is on. There’s no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery
Lionheart is a conservative-based governor which is based on samsung’s update3 source. Tweaks comes from 1) Knzo 2) Morfic. The original idea comes from Netarchy. The governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
Sets min frequency as max frequency. Use this while benchmarking!.
Locks max frequency to min frequency. Can not be used as a screen-on or even screen-off (if scaling min frequency is too low).
Scary – A new governor wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it’s above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It will give the same performance as conservative right now, it will get tweaked over time.
That’s all for Governors. Now, if you want to read more, you can read on: Here
Q. “What purposes does an i/o scheduler serve?”
- Minimize hard disk seek latency.
- Prioritize I/O requests from processes.
- Allocate disk bandwidth for running processes.
- Guarantee that certain requests will be served before a deadline.
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.
- Serves I/O requests with least number of cpu cycles. (Battery friendly?)
- Best for flash drives since there is no seeking penalty.
- Good throughput on db systems.
- Reduction in number of cpu cycles used is proportional to drop in performance.
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.
- Nearly a real time scheduler.
- Excels in reducing latency of any given single I/O.
- Best scheduler for database access and queries.
- Bandwidth requirement of a process – what percentage of CPU it needs, is easily calculated.
- Like noop, a good scheduler for solid state/flash drives.
- When system is overloaded, set of processes that may miss deadline is largely unpredictable.
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.
- Considered to deliver a balanced i/o performance.
- Easiest to tune.
- Excels on multiprocessor systems.
- Best database system performance after deadline.
- Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
- Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.
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.
- Believed to be very good for usb data transfer rate.
- Believed to be the best scheduler for HD video recording and video streaming. (because of less jitter as compared to CFQ and others)
- Considered an accurate i/o scheduler.
- Achieves about 30% more throughput than CFQ on most workloads.
- Not the best scheduler for benchmarking.
- Higher budget assigned to a process can affect interactivity and increased latency.
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.
- Simple, so reliable.
- Minimized starvation of requests.
- Slow random-read speeds on flash drives, compared to other schedulers.
- Sequential-read speeds on flash drives also not so good.
And that be all…. All credits to DroidPhile. Give his thread a look for more.