[Verizon Samsung Galaxy S 4] klabit87:
CPU Governors​

Abyssplug:

Abyssplug governor is a modified hotplug governor.

Alucard

A favourite choice and one of the original governors that Alucard_24 made. 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.

ArterActive

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

ConservativeX

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

Darkness

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

IntelliActive

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

1. self-boost capability from input drivers (no need for PowerHAL assist)

2. two phase scheduling (idle/busy phases to prevent from jumping directly to max freq

3. Checks for offline cpus and short circuits some unnecessary checks to improve code execution paths. Therefore, it avoids CPU hotplugging.

Created by Faux

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.

IntelliMM

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

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.

Nightmare

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.

OndemandPlus

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

Optimax

This is based on ONDEMAND, like almost all governors that have arisen from XDA. It contains 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

PegasusQ

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

Smartmax

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

Wheatley:

in short words this govenor is build on “ondemand” but increases the C4 state time of the CPU and doing so trying to save juice.

YankActive

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

Post3:

IO Schedulers​

IO Scheduler Comparison

Overall performance:

Best<------------------------------------------------------------------------->Worst

FIOPS > Noop > ZEN > Tripndroid > SIO > SIOplus > VR > Deadline > CFQ

Multitasking performance:

Less Apps<------------------------------------------------------------>Many Apps

Noop < FIFO < FIOPS < SIO < SIOplus < Tripndroid < ZEN < Deadline < VR < CFQ

Battery life:

Best<-------------------------------------------------------------------------> Worst

Noop > FIFO > FIOPS > SIO > SIOplus > ZEN > Tripndroid > Deadline > VR > CFQ

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.

Advantages:

Considered to deliver a balanced i/o performance.

Easiest to tune.

Excels on multiprocessor systems.

Best database system performance after deadline.

Disadvantages:

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.

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:

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.

Disadvantages:

When system is overloaded, set of processes that may miss deadline is largely unpredictable.

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:

- Serves I/O requests with least number of cpu cycles.

- Is suitable for flash drives because there is no search errors

- Good data throughput on db systems

Disadvantages:

- Reducing the number of CPU cycles corresponds to a simultaneous decline in performance

- Not very good at multitasking

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

- Achieves high read and write speeds in benchmarks

- Faster app launching time and overall UI experience

- Good battery life

Disadvantages:

- Not very common in most kernels

- Not the most responsive IO scheduler (Can make phone lag)

- Not good at heavy multitasking

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.

Advantages:

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.

Disadvantages:

Reduction in number of cpu cycles used is proportional to drop in performance.

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:

Simple, so reliable.

Minimized starvation of requests.

Disadvantages:

Slow random-read speeds on flash drives, compared to other schedulers.

Sequential-read speeds on flash drives also not so good.

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 read and write speeds than previous SIO scheduler

Disadvantages:

- Fluctuations in performance may be observed

- Not found in all kernels

Tripndroid:

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

Benefits:

- Great at IO performance and everyday multitasking

- Well rounded and efficient IO scheduler

- Very responsive I/O scheduler (Compared to FIOPS)

Disadvantages:

- Not found in all kernels

- Performance varies between different devices (Some devices perform really well)

VR

Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request.

Advantages:

May be best for benchmarking because at the peak of it's 'form' VR performs best.

Disadvantages:

Performance fluctuation results in below-average performance at times.

Least reliable/most unstable.

ZEN:

ZEN scheduler is based on the VR Scheduler. 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 no-op blended with VR features.

Benefits:

- Well rounded IO Scheduler

- Very efficient IO Scheduler

- More stable than VR, more polished

Disadvantages:

- Performance variability can lead to different results (Only performs well sometimes)

- Not found in all kernels