[LG Optimus Me P350] Ron G:
HERE THE INFO OF ANDROID GOV

ALL CREDITS GO TO Deedii

Android CPU governors explained

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

17: Lazy

18: Lionheart

19: LionheartX

20: Intellidemand

21: Hotplug

​

1: OnDemand Governor:

This governor has a hair trigger for boosting clockspeed to the maximum speed set by the user. If the CPU load placed by the user abates, the OnDemand governor will slowly step back down through the kernel's frequency steppings until it settles at the lowest possible frequency, or the user executes another task to demand a ramp.

OnDemand has excellent interface fluidity because of its high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand is commonly chosen by smartphone manufacturers because it is well-tested, reliable, and virtually guarantees the smoothest possible performance for the phone. This is so because users are vastly more likely to ***** about performance than they are the few hours of extra battery life another governor could have granted them.

This final fact is important to know before you read about the Interactive governor: OnDemand scales its clockspeed in a work queue context. In other words, once the task that triggered the clockspeed ramp is finished, OnDemand will attempt to move the clockspeed back to minimum. If the user executes another task that triggers OnDemand's ramp, the clockspeed will bounce from minimum to maximum. This can happen especially frequently if the user is multi-tasking. This, too, has negative implications for battery life.
​

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

​

3: Performance Governor:

This locks the phone's CPU at maximum frequency. While this may sound like an ugly idea, there is growing evidence to suggest that running a phone at its maximum frequency at all times will allow a faster race-to-idle. Race-to-idle is the process by which a phone completes a given task, such as syncing email, and returns the CPU to the extremely efficient low-power state. This still requires extensive testing, and a kernel that properly implements a given CPU's C-states (low power states).
​

4: Powersave Governor:

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

​

5:Conservative Governor:

This 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," if that helps to give you a more complete picture of its functionality.
​

6: Userspace Governor:

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

well this governor makes use of only min & maximum frequency based on workload... no intermediate frequencies are used.
​

8: 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.
​

9: 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.
​

10: Smartass

Is based on the concept of the interactive governor.

I have always agreed that in theory the way interactive works – by taking over the idle loop – is very attractive. I have never managed to tweak it so it would behave decently in real life. Smartass is a complete rewrite of the code plus more. I think its a success. Performance is on par with the “old” minmax and I think 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 – why?! – it will cap it to your min frequency). Lets take for example the 528/176 kernel, it will sleep at 352/176. No need for sleep profiles any more!"
​

11: SmartassV2:

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

12: Scary

A new governor wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 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.
​

13: Lagfree:

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

14: Smoothass:

The same as the Smartass “governor” But MUCH more aggressive & across the board this one has a better battery life that is about a third better than stock KERNEL
​

15: Brazilianwax:

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

16: SavagedZen:

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

17: Lazy:

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

18: Lionheart:

Lionheart is a conservative-based governor which is based on samsung's update3 source.

The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
​

19: LionheartX

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

20: Intellidemand:

Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). 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. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors)

To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.

​

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

=============================================

ALL CREDITS GO TO THE USERS OF XDA WHO CREATED DIFF THREADS ABOUT I/O, THIS I/O INFO FROM ALL THREADS

I/O:- short form of Input & Output
​

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 minimize time wasted by hard disk seeks.

- To prioritize 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.
​

Info on I/O Scheduler

SIO:- cheduler is based on the deadline scheduler but it's more like a mix between no-op and deadline.In other words, SIO is like a lighter version of deadline but it doesn't do any kind of sorting, so it's aimed mainly for random-access devices (like SSD hard disks) where request sorting is no needed (as any sector can be accesed in a constant time, regardless of its physical location).
​

NOOP:- The NOOP scheduler inserts all incoming I/O requests into a simple, unordered FIFO queue and implements request merging.

The scheduler assumes I/O performance optimization will be handled at some other layer of the I/O hierarchy; e.g., at the block device; by an intelligent HBA such as a Serial Attached SCSI (SAS) RAID controller or by an externally attached controller such as a storage subsystem accessed through a switched Storage Area Network.
​

ANTICIPATORY:- Anticipatory scheduling is an algorithm for scheduling hard disk input/output.

It seeks to increase the efficiency of disk utilization by "anticipating" synchronous read operations.

ADAPTIVE ANTICIPATORY SCHEDULER:- For the anticipatory scheduler, we scale up the anticipation timeout (antic expire) using the latency scaling factor over time. When the virtual disk latencies are low a small scaling of the timeout is sucient to prevent deceptive idleness, whereas when the latencies are high a larger scaling of the timeout value may be required to achieve the same. Note that such dynamic setting of the timeout value ensures that we attain a good trade-o between throughput (lost due to idling) and deceptive idleness mitigation. Setting a high value for the scaling factor (increasing idling time) only happens when the disk service latencies themselves are higher. This may not necessarily cause a signicant loss in throughput, because submitting a request from another process instead of idling is not going to improve throughput if the virtual disk itself does not get any faster than it is at the current period. A higher anticipation timeout might also be capable of absorbing process scheduling eects inside the VM. The results for the adaptive anticipatory scheduler are shown in Figure 2. The read time with our modied implementation (third bar in the dierent scheduler combi- nations) shows that it is possible to mitigate the eects of deceptive idleness by adapting the timeout. An interesting related observation is that the level to which the improve- ment is possible varies for dierent Domain-0 schedulers; noop - 39%, anticipatory - 67% and cfq - 36%. This again points to the fact that the I/O scheduler used in Domain-0 is important for the VM's ability in enforcing I/O scheduling guarantees. Dierent Domain-0 I/O schedulers likely have a dierent service latency footprint inside the VMs, contributing to dierent levels of improvement.
​

CFQ:-CFQ, also known as "Completely Fair Queuing", is an I/O scheduler for the

Linux kernel which was written in 2003 by Jens Axboe.

CFQ works by placing synchronous requests submitted by processes into a number of per-process queues and then allocating timeslices for each of the queues to access the disk. The length of the time slice and the number of requests a queue is allowed to submit depends on the IO priority of the given process. Asynchronous requests for all processes are batched together in fewer queues, one per priority.
​

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

V(R):- The next request is decided based on its distance from the last request, with a multiplicative penalty of `rev_penalty' applied for reversing the head direction. A rev_penalty of 1 means SSTF behaviour. As this variable is increased, the algorithm approaches pure SCAN. Setting rev_penalty to 0 forces SCAN.

​

SIMPLE:- Does not do any kind of sorting, as it is aimed foraleatory access devices, but it does some basic merging. We try to keep minimum overhead to achieve low latency.
​

BFQ:- BFQ is a proportional share disk scheduling algorithm based on the slice-by-slice service scheme of CFQ. But BFQ assigns budgets, measured in number of sectors, to tasks instead of time slices. The disk is not granted to the active task for a given time slice, but until it has exahusted its assigned budget. This change from the time to the service domain allows BFQ to distribute the disk bandwidth among tasks as desired, without any distortion due to ZBR, workload fluctuations or other factors. BFQ uses an ad hoc internal scheduler, called B-WF2Q+, to schedule tasks according to their budgets. Thanks to this accurate scheduler, BFQ can afford to assign high budgets to disk-bound non-seeky tasks (to boost the throughput), and yet guarantee low latencies to interactive and soft real-time applications.
​