[REF] Governors and I/O schedulers - AT&T Samsung Galaxy S II SGH-I777

I pooled together information on cpu governors and I/O schedulers from several sources. If anyone has any additional information to add, feel free to chime in . Credit goes to Knzo, Pikachu01, HipKat, and Droidphile for this compilation. This will continue to expand as I come across more information.
Apps are the probably the most popular methods for controlling these settings. I won't list them all, but here are the most common:
Voltage Control - I find this to be the best option; its "set at boot" method is faster and more reliable (init.d script created by the app). Doesn't have a widget that I find useful, but has everything SetCPU has and then some (I/O scheduler, GPU control, charging current, etc.)
SetCPU - limited to governors, voltages, sampling rate, etc. but has a very useful widget. I've experienced issues before with it successfully setting values at boot.
*Interested in jumping to a particular governor/scheduler/term? Press Ctrl + F and enter the term.
Post 1 - Governors
Post 2 - I/O Schedulers
Governors
knzo said:
. . .
So, what's a governor?
Code:
Consider a CPU, the processor of Optimus Black. Well, this CPU operates at
different frequencies (on stock: 300, 600, 800 and 1000 Mhz) and we usually
say it's a 1 Ghz (1000 Mhz) processor because that's the max frequency it
can go 100% stable.
Now, a governor is a CPUFreq driver. Like the name suggests, it is what
decides when to be on full speed at max frequency or when to be at min
or mid and how fast should it reach the max/min, should it be almost insta
and provide a good smoothness overall? Should it take longer and go 200
Mhz at a time and preserve battery? This and more is what a governor is.
There are many governors around, some for single-cores, some for dual-cores which I won't even refer to (jRCU). In stock you can find 5 governors, in Quasar kernel you can find much more. Most android and xda users don't even know half of governors I'll list as there is no android kernel out there with more governors than Quasar, only one has the same amount and this is a kernel made by my friend and fellow portuguese franciscofranco.
Listing of knzo-known governors:
Ondemand *&
Powersave *@
Userspace *
Conservative *
Performance *
Interactive +
InteractiveX +
Smartass +
Smoothass +
BrazilianWax +
SavagedZen +
Minmax +&
Scary +
Legend: & - default | @ - disabled by default | * - exists in stock kernel | + - added in Quasar kernel
And now the official summary for each and brief comment by myself:
Ondemand:
Code:
/*
* drivers/cpufreq/cpufreq_ondemand.c
*
* Copyright (C) 2001 Russell King
* (C) 2003 Venkatesh Pallipadi <[email protected]>.
* Jun Nakajima <[email protected]>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
Ondemand is the default choice due to its balanced settings which offers a good compromise between battery and performance. However, it has no suspend profiles and falls a bit short on performance in smartphones.
Powersave:
Code:
/*
* linux/drivers/cpufreq/cpufreq_powersave.c
*
* Copyright (C) 2002 - 2003 Dominik Brodowski <[email protected]>
*
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
*/
Powersave sets the max frequency at the same clock as the min frequency. Impossible for daily usage for obvious reasons. Used usually with SetCPU screen-off profiles in combo with Ondemand.
Userspace:
Code:
/*
* linux/drivers/cpufreq/cpufreq_userspace.c
*
* Copyright (C) 2001 Russell King
* (C) 2002 - 2004 Dominik Brodowski <[email protected]>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
*/
Userspace lets you manually set the frequencies. To be completely honest, I've never used it and I've never heard of anyone who uses it. I'm completely off on how it fares or if it even works or any of its kinks.
Conservative:
Code:
/*
* drivers/cpufreq/cpufreq_conservative.c
*
* Copyright (C) 2001 Russell King
* (C) 2003 Venkatesh Pallipadi <[email protected]>.
* Jun Nakajima <[email protected]>
* (C) 2009 Alexander Clouter <[email protected]>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
Conservative is a slower Ondemand when it comes to ramping. For example, when you turn on the phone and start interacting with it, Ondemand will increase frequency until it reaches max at x speed. Conservative will do the same at x/2. Faster the ramping the more battery it consumes so conservative while a worse governor for performance it's also a good one for battery.
Performance:
Code:
/*
* linux/drivers/cpufreq/cpufreq_performance.c
*
* Copyright (C) 2002 - 2003 Dominik Brodowski <[email protected]>
*
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
*/
If Powersave governor is Yin, this one is Yang. It sets the min frequency the same as max frequency so the phone is always at max power. This is usually used with SetCPU profiles for when charging or plugged to computer. For obvious reasons can't be used in daily usage.
Interactive:
Code:
/*
* drivers/cpufreq/cpufreq_interactive.c
*
* Copyright (C) 2010 Google, Inc.
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
* may be copied, distributed, and modified under those terms.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* Author: Mike Chan ([email protected])
*
*/
While Conservative is a slower Ondemand, Interactive is a faster one. Ramping will be slightly faster so interaction will seem more snappy with battery comsumption just increasing a tiny bit. This has been the most popular governor for the past year.
InteractiveX:
Code:
/*
* drivers/cpufreq/cpufreq_interactive.c
*
* Copyright (C) 2010 Google, Inc.
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
* may be copied, distributed, and modified under those terms.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* Author: Mike Chan ([email protected]) - modified for suspend/wake by imoseyon
*
*/
As you can see in the summary, this is Interactive with some modifications by imoseyon. Now instead of using the dirty SetCPU profiles method of locking the frequency to minimum when phone is asleep, the own governor will do that which is a cleaner method and with a better ramping management when coming out of sleep. Basically, it has Interactive's performance with better battery.
Smartass:
Code:
/*
* drivers/cpufreq/cpufreq_smartass2.c
*
* Copyright (C) 2010 Google, Inc.
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
* may be copied, distributed, and modified under those terms.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* Author: Erasmux
*
* Based on the interactive governor By Mike Chan ([email protected])
* which was adaptated to 2.6.29 kernel by Nadlabak ([email protected])
*
* SMP support based on mod by faux123
*
* requires to add
* EXPORT_SYMBOL_GPL(nr_running);
* at the end of kernel/sched.c
*
*/
This one has been increasingly popular and it's becoming the favorite one for Q3-4 2011. Smartass is based on Interactive but with some modifications, as well as built-in profiles. Recently, Erasmux released this v2 which by what people are saying it's very good. I suggest you go to this link for more informations. It's probably Quasar's best governor at the moment, along with Minmax.
Smoothass:
Code:
/*
* drivers/cpufreq/cpufreq_smoothass.c
*
* Copyright (C) 2010 Google, Inc.
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
* may be copied, distributed, and modified under those terms.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* Author: Erasmux
*
* Based on the interactive governor By Mike Chan ([email protected])
* which was adaptated to 2.6.29 kernel by Nadlabak ([email protected])
*
* requires to add
* EXPORT_SYMBOL_GPL(nr_running);
* at the end of kernel/sched.c
*
*/
One more jewel from Erasmux. As far as I know this is a Smartass v1 tuned for a more aggressive ramping, which means, more performance and snappiness, less battery.
BrazilianWax:
Code:
/*
* drivers/cpufreq/cpufreq_brazilianwax.c
*
* Copyright (C) 2010 Google, Inc.
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
* may be copied, distributed, and modified under those terms.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* Author: Erasmux
*
* Based on the interactive governor By Mike Chan ([email protected])
* which was adaptated to 2.6.29 kernel by Nadlabak ([email protected])
*
* requires to add
* EXPORT_SYMBOL_GPL(nr_running);
* at the end of kernel/sched.c
*
*/
Someone correct me if I'm wrong but this is basically the same as Smoothass.
SavagedZen:
Code:
/*
* drivers/cpufreq/cpufreq_savagedzen.c
*
* Copyright (C) 2010 Google, Inc.
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
* may be copied, distributed, and modified under those terms.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* Author: Joshua Seidel
* Based on the smartass governor by Erasmux
*
* Based on the interactive governor By Mike Chan ([email protected])
* which was adaptated to 2.6.29 kernel by Nadlabak ([email protected])
* --Modifications by arescode--
* adapted to stock (1 GHz) frequency by zacharias.maladroit
*
* requires to add
* EXPORT_SYMBOL_GPL(nr_running);
* at the end of kernel/sched.c
*
*/
Another Smartass-based kernel with many modifications aiming to attain both better battery and performance. And it succeeds in my opinion. I've used it in past devices, it's a very good overall governor, a balanced option.
Minmax:
Code:
/*
* drivers/cpufreq/cpufreq_minmax.c
*
* Copyright (C) 2001 Russell King
* (C) 2003 Venkatesh Pallipadi <[email protected]>.
* Jun Nakajima <[email protected]>
* (C) 2004 Alexander Clouter <[email protected]>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
* This governor is an adapatation of the conservative governor.
* See the Documentation/cpu-freq/governors.txt for more information.
*
* Adapatation from conservative by Erasmux.
*/
This governor was a very pleasant surprise. Although an adaptation of Conservative governor it has probably the best performance of them all. Might fall shorter on battery than Smartass v2 but I owe it my best experiences in terms of snappiness so far, reason why I selected it as default governor for Nova. My personal favorite until I can draw a conclusion from using Smartass v2.
Scary:
Code:
/*
Scary governor based off of conservatives source with some
of smartasses features
For devs - If you're going to port this driver to other devices,
make sure to edit the default sleep frequencies & prev frequencies
or else you might be going outside your devices hardware limits.
*/
This is just a weird governor. It's based on Conservative which has a slower ramping than Ondemand but then again it has Smartass elements which is a governor with one the fastest rampings. I've heard some people like it but alas I never tried it myself.
Click to expand...
Click to collapse
droidphile said:
. . .
lazy:
Basically and ondemand with an additional parameter min_time_state which specifies the minimum time cpu stays on a frequency before scaling up/down. Idea here is to eliminate instabilities caused by fast frequency switching of ondemand. lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step. Lazy also has a screenoff_maxfreq parameter which can be configured to specifiy max frequency while screen is off.
lulzactive:
Based on interactive & smartass governors, this governor tends to be the new favorite for many of us. 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. On screen off, frequency is locked to global scaling minimum frequency.
lagfree:
Similar to ondemand. Difference is optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree doesn't skip frequencies while scaling up or down.
smartassV2:
Modified smartass and one of the favorite governor for many a people. This governor scales down cpu very fast while screen is off and scales up to 500 mhz quickly when screen is on. There's no upper limit for frequency while screen is off. 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. Thus ensuring a balance between performance and battery.
ondemandx:
Basically an ondemand with suspend/wake profile. This governor is a battery friendly ondemand. When screen is off, max frequency is 500 mhz.
. . .
Click to expand...
Click to collapse
droidphile said:
. . .
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' (rather 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 current 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 not busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
lionheart:
Lionheart is a tweaked conservative governor from Knzo. You can simply modify conservative to experience lionheart. Set low up-threshold (60 or something) and lowest possible sampling rate on conservative. Lionheart's motto is extreme responsiveness and performance, at the cost of battery. When it comes to smoothness (not considering battery drain), a tuned conservative delivers more as compared to a tuned ondemand. This could be the reason for lionheart's 'birth'.
. . .
Click to expand...
Click to collapse
HipKat said:
Hotplug Governor:
The “hotplug” governor scales CPU frequency based on load, similar to “ondemand”. It scales up to the highest frequency when “up_threshold” is crossed and scales down one frequency at a time when “down_threshold” is crossed. Unlike those governors, target frequencies are determined by directly accessing the CPUfreq frequency table, instead of taking some percentage of maximum available frequency.
Click to expand...
Click to collapse
Information on the Pegasusq governor
robertobsc said:
LulzactiveQ
I was decided to optimize Lulzactive governor by including the dec_cpu_load parameter.
----
I was going to put it because if the inc_cpu_load is setted at a high value (example: 90%) and the pump_down_steps is also setted high (2 or 3 steps down if load < inc_cpu_load) it would happen a problem:
Suppose the current load is between 80 and 89% all the sampling rate and the pum_down_steps is 2 or 3. Do you think is a good idea to go down 2/3 steps in the load at that high?
This is not a theorical issue, i really felt lag when playing some simple games and my conclusion was that situation was happening in that moment.
Thats why i created dec_cpu_load, in this way we can tell the governor exactly when go down pump_down_steps.
----
I also fixed a little bug as well that the up_sample_time and down_sample_time wasnt been respected (the governor was scaling up and down as soon as the load criteria was matched).
-----
And i added as gokhan requested, the hotplug parameters from pegasusq. So now we have two governors with hotplug queue logic.
To the hotplug part i had to create another sample rate. The name is hotplug_sample_rate. I created that to make the hotplug part completely independent from scale up / down frequencies part. In fact, they are running in different threads.
-----
That's it. I also putted some logs that can be enabled / disabled by the dvfs_debug parameter.
If do you think something was wrong, or a problem apperead please enable this parameter for a while and execute this command in terminal emulator or adb:
dmesg > /sdcard/lulzactiveq.log.txt
----------------------
This is only a battery profile suggestion for the 16 steps. Please explore it!!!!!!
-- Parâmetros Lulzactive
echo "90" > /sys/devices/system/cpu/cpufreq/lulzactiveq/inc_cpu_load
echo "40" > /sys/devices/system/cpu/cpufreq/lulzactiveq/dec_cpu_load
echo "1" > /sys/devices/system/cpu/cpufreq/lulzactiveq/pump_up_step
echo "2" > /sys/devices/system/cpu/cpufreq/lulzactiveq/pump_down_step
echo "50000" > /sys/devices/system/cpu/cpufreq/lulzactiveq/up_sample_time
echo "25000" > /sys/devices/system/cpu/cpufreq/lulzactiveq/down_sample_time
echo "14" > /sys/devices/system/cpu/cpufreq/lulzactiveq/screen_off_min_step
-- Lulzactive - Hotplug Queue parameters
echo "50000" > /sys/devices/system/cpu/cpufreq/lulzactiveq/hotplug_sample_rate
echo "13" > /sys/devices/system/cpu/cpufreq/lulzactiveq/cpu_up_rate
echo "13" > /sys/devices/system/cpu/cpufreq/lulzactiveq/cpu_down_rate
echo "600000" > /sys/devices/system/cpu/cpufreq/lulzactiveq/hotplug_freq_1_1
echo "400000" > /sys/devices/system/cpu/cpufreq/lulzactiveq/hotplug_freq_2_0
echo "350" > /sys/devices/system/cpu/cpufreq/lulzactiveq/hotplug_rq_1_1
echo "300" > /sys/devices/system/cpu/cpufreq/lulzactiveq/hotplug_rq_2_0
echo "0" > /sys/devices/system/cpu/cpufreq/lulzactiveq/hotplug_lock
-- debug on/off
echo "0" > /sys/devices/system/cpu/cpufreq/lulzactiveq/debug_mode
Click to expand...
Click to collapse

---

I/O Schedulers
Every I/O scheduler except Anticipatory has explanations from two perspectives. At the end of the post is a discussion of benchmarking and a brief comparison.
knzo said:
. . .
So, what's a I/O Scheduler?
Code:
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.
There is not so much offer when it comes to I/O Schedulers and the improvements aren't nearly as visible as choosing a gung ho governor but trust me they are there. Just to name one improvement you could see is for example the opening and closing of applications.
Listing of knzo-known I/O Schedulers:
Noop *
Anticipatory *@+
CFQ *&
Deadline *@+
VR +
Simple +&
BFQ #
Legend: & - default | @ - disabled by default | * - exists in stock kernel | + - added in Quasar kernel | # - not included in Quasar kernel
And now a summary for each and brief comment by myself:
Noop:
Code:
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).
NOOP scheduler is best used with solid state devices such as flash memory
or in general with devices that do not depend on mechanical movement to
access data (meaning typical "hard disk" drive technology consisting of seek
time primarily, plus rotational latency). Such non-mechanical devices do not
require re-ordering of multiple I/O requests, a technique that groups together
I/O requests that are physically close together on the disk, thereby reducing
average seek time and the variability of I/O service time.
Noop isn't actually that bad. It's a simple I/O Scheduler and when it comes to Android, the simplest the better.
I think in G1 one known "tweak" was to set Noop as default I/O Scheduler.
pikachu01 said:
NOOP is a simple I/O scheduler without overhead that tries to do each I/O transaction as it comes (FIFO). When a group of transactions is detected, it will try to merge it together to make batches of transactions (makes the whole transaction faster). NOOP doesn't have starvation detection, hence if an I/O transaction takes a painfully long amount of time, it will still continue to do it rather than switch the CPU into doing something else e.g. GUI interrupts (i.e. scrolling lists, flicking screens). All other schedulers also have the "merge" feature. NOOP is the only one that makes the "merge" feature its only feature.
Click to expand...
Click to collapse
Anticipatory:
Code:
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.
"Deceptive idleness" is a situation where a process appears to be finished
reading from the disk when it is actually processing data in preparation of
the next read operation. This will cause a normal work-conserving I/O
scheduler to switch to servicing I/O from an unrelated process. This situation
is detrimental to the throughput of synchronous reads, as it degenerates into
a seeking workload. Anticipatory scheduling overcomes deceptive idleness
by pausing for a short time (a few milliseconds) after a read operation in
anticipation of another close-by read requests.
I have no idea if this fares well in Android devices. It's disabled in stock kernel and also in Quasar kernel since I've never heard of anyone using it or even recommending it. I read it's more in servers and what nots.
CFQ:
Code:
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. While CFQ does not do explicit anticipatory IO
scheduling, it achieves the same effect of having good aggregate throughput for
the system as a whole, by allowing a process queue to idle at the end of
synchronous IO thereby "anticipating" further close IO from that process. It can
be considered a natural extension of granting IO time slices to a process.
Well, like Ondemand is to governors, CFQ is to I/O Schedulers. It's the most balanced one, aiming to perform well in most scenarios. However, in Android since things work differently, it's not the most suitable I/O Schedulers. There are many tweaks spreaded throughout XDA for improving this baby.
pikachu01 said:
CFQ is a complex I/O scheduler that tries to determine the address space of the transaction and applies a cost algorithm in that if the address is close together, it will group them up and perform them. It also tries to make the transaction incremental (i.e. reading/writing through address incrementally so that the disk spindle needs to wind down the least in conventional platter hard disks) The problem is, our flash devices have very little delta between reading a far reaching address space (than the one currently being written/read) or a closer one as it doesn't rely on spindle/rotations. Hence, having this costing algorithm adds overhead and slows down the overall transaction. CFQ has a lot of algorithms to make sure each process gets a fair slice of time on I/O transcations. Too much overhead.
Click to expand...
Click to collapse
Deadline:
Code:
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.
Deadline is actually quite popular along with BFQ. It is used in some known kernels for example Netarchy's for Nexus S. However, even though it's better than CFQ for Android devices it still falls short in comparison with VR.
pikachu01 said:
Deadline has a starvation detector and is simple enough that it doesn't have all the overhead of doing rotational/costing disks algorithm. However, reads are done 2x more likely than writes as it has a algorithm based on weights in that reads must be done first if both a read and a write is detected. It has a 2:1 ratio of read to write weights coded into the scheduler (that can be tweaked - writes_starved, will include it in the next version of system_tweak). Hence it's not a fair scheduler.
Click to expand...
Click to collapse
VR:
Code:
/*
* V(R) I/O Scheduler
*
* Copyright (C) 2007 Aaron Carroll <[email protected]>
*
*
* The algorithm:
*
* 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.
*
* Async and synch requests are not treated seperately. Instead we
* rely on deadlines to ensure fairness.
*
*/
VR is a very good I/O Scheduler with Deadline elements. Probably the best for MTD Android devices and it's used also in known kernels such as IntersectRaven's for Nexus One. It's probably the one who can score the most in benchmarks but it's also one of the most... unstable. Its performance fluctuates, it can peak above average or it can go below it. But when it peaks... it's the best.
pikachu01 said:
V(R) tries to make sure that each transaction has a weight associated with it, being R. And if the seek is reversed, the R will be multiplied by a penalty making it less likely to be processed. Not for flash drives as reverse seek in a flash drive is just as fast as a forward seek.
Click to expand...
Click to collapse
Simple:
Code:
/*
* Simple IO scheduler
* Based on Noop, Deadline and V(R) IO schedulers.
*
* Copyright (C) 2010 Miguel Boton <[email protected]>
*
*
* This algorithm does not do any kind of sorting, as it is aimed for
* aleatory access devices, but it does some basic merging. We try to
* keep minimum overhead to achieve low latency.
*
* Asynchronous and synchronous requests are not treated separately, but
* we relay on deadlines to ensure fairness.
*
*/
Like the name suggests, Simple I/O is a simple one. Remember me saying that I/O Schedulers for Android devices, the simpler the better? This is such a case. Especially for EMMC devices. It's reliable and while not as good as VR when it peaks, it's still one of the best performance-wise. It's at the moment the default one in Quasar kernel.
pikachu01 said:
SIO is Simple I/O that tries to implement a NOOP type scheduler that has starvation detection. Hence, long I/O transactions will be preempted and given CPU time only after other faster transactions are completed, guaranteeing smoothness. Also, it doesn't have overhead of calculating costs. Also, it has a fair number of writes to read, guaranteeing that all transactions are equal.
Click to expand...
Click to collapse
BFQ:
Code:
/*
* BFQ, or Budget Fair Queueing, disk scheduler.
*
* Based on ideas and code from CFQ:
* Copyright (C) 2003 Jens Axboe <[email protected]>
*
* Copyright (C) 2008 Fabio Checconi <[email protected]>
* Paolo Valente <[email protected]>
*
* Licensed under the GPL-2 as detailed in the accompanying COPYING.BFQ file.
*
* 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.
*
*/
Here it is, the wrongly assumed best I/O Scheduler which happens to be the most popular one. It's based in CFQ but it has an inferior performance than VR or Simple, even if it's BFQv2 (although it seems to perform well in USB transfers rate).
pikachu01 said:
BFQ has a lot of algorithms to make sure each process gets a fair slice of bandwidth (Budget Fair Queueing). Too much overhead.
Click to expand...
Click to collapse
Click to expand...
Click to collapse
pikachu01 said:
Here's my assessment of all the schedulers that I know:
SIO> NOOP> Deadline > VR > BFQ > CFQ
. . .
In benchmarking tests, the tests normally consists of testing the time it takes for a contiguous I/O transfer from 1 point to another. NOOP excels at that because it won't let itself get interrupted to perform another I/O task. This would mean that in real life testing, NOOP will let a long arduous task to finish while at the expense of UI functionality (you will get UI lags)
SIO on the other hand will perform badly at benchmarking as it gets pre-empted when the contiguous tasks takes more than 0.5secs (for synchronous tasks as benchmarking tools perform a synchronous I/O task from one point to another) to another more important task like UI interrupt (when you're scrolling) or Kernel interrupt (when your kernel needs to perform garbage collecting or swap memory etc)
The 0.5 secs can be tuned in the SIO tuneables though, but I would think 0.5 secs for synchronous tasks and 5 secs for async tasks is pretty good to maintain a balance between long/short tasks enabling a smoother experience in Android.
Click to expand...
Click to collapse
bbedward said:
Q: What is the zen I/O scheduler?
A: Well, the question that was asked above led me to an analysis of V(R ), deadline, and some others. I already knew, but realized "this is the main feature of V(R), but wait it has no benefit to us smartphone users." So I thought about adjusting the way V(R ) handled requests and how it dispatched them (I chose V(R ) because i'd rather not tinker with a scheduler thats official and widely supported). Then I was looking over it, and realized I might as well just write a new one I don't need any of this stuff. So I came up with something awfully similar to SIO, although its a bit simpler than SIO (closer to no-op) and works just slightly different.
- It's an FCFS (First come, first serve) based algorithm. It's not strictly FIFO. It does not do any sorting. It uses deadlines for fairness, and treats synchronous requests with priority over asynchronous ones. Other than that, pretty much the same as no-op.
Click to expand...
Click to collapse

---

A little more info in the old toolbox

---

Excellent pooling of information. Well done; I have (or now had) several bookmarks to cover this information--and even those were somewhat spotty.
I would also suggest you take it a step further and list out some other apps that control these settings (FauxClock, System Tuner Pro, etc.) that manipulate this information and maybe list some setting to try out for i/o scheduling (cache size, etc.).
Anyway, great post.
I linked this over at the T-mobile Galaxay S II thread. . .

---

Great post. With my less significant amount of experience, I can agree on all opinions too.

---

Nice reference work, Simba. Thanks.

---

I cannot believe something like this went so unnoticed. Consider this added to the FAQ for future reference. Thanks for the great guide.

---

For those looking for more information about these and other kernel-based tweaks, there's droidphile's own posts (1 and 2) from the I9100 forums. I'm sure most of what's in the first one I linked is covered here though it also covers a bit more on other tweaks. Second post is for ICS kernels.

---

Divine_Madcat said:
I cannot believe something like this went so unnoticed. Consider this added to the FAQ for future reference. Thanks for the great guide.
Click to expand...
Click to collapse
+1 Holy cow!! How the hell did I miss this??
Thanks, Simba!
Edit: This should be STICKIED!!

---

Great information, thanks.
Sent from my SGH-I777 using xda premium

---

Can this be a sticky please

---

dirtbikerr450 said:
Can this be a sticky please
Click to expand...
Click to collapse
+1
Sent from my SGH-I777 using xda premium

---

Things don't get stickied in these forums now so there isn't a buildup of sticky threads like there used to be. Instead, one sticky which links to all the important guides and posts exists at the top. It makes the forums cleaner.
Sent from my SGH-I777 using XDA

---

karate104 said:
Things don't get stickied in these forums now so there isn't a buildup of sticky threads like there used to be. Instead, one sticky which links to all the important guides and posts exists at the top. It makes the forums cleaner.
Sent from my SGH-I777 using XDA
Click to expand...
Click to collapse
Only problem is that this thread is NOT linked in the existing sticky

---

eep2378 said:
Only problem is that this thread is NOT linked in the existing sticky
Click to expand...
Click to collapse
Agreed. And it should be.

---

karate104 said:
Agreed. And it should be.
Click to expand...
Click to collapse
PM sent to mod

---

eep2378 said:
PM sent to mod
Click to expand...
Click to collapse
Devine already did it like 7 posts up. Read! Lol
We will sort you out!

---

UltraBeast said:
Devine already did it like 7 posts up. Read! Lol
We will sort you out!
Click to expand...
Click to collapse
Woops! My bad. Its still kinda buried oh well
Red, disregard pm

---

eep2378 said:
Woops! My bad. Its still kinda buried oh well
Red, disregard pm
Click to expand...
Click to collapse
Its ok, I'm used to being overlooked.
As it is, it is linked in the FAQ - it is not on the "main" page, because it is a QA post, rather than guide, etc. This is excellent info though, which is why it is on the FAQ.

---

Divine_Madcat said:
Its ok, I'm used to being overlooked.
As it is, it is linked in the FAQ - it is not on the "main" page, because it is a QA post, rather than guide, etc. This is excellent info though, which is why it is on the FAQ.
Click to expand...
Click to collapse
I feel so bad sometimes because you are! I know you're around and active, but everyone just refers to Red when it comes to moderating XD