Find Your Device:
Or Continue to Thread: [REF][GUIDE]Most up to date gu…
8th March 2015, 05:54 AM
Saber's Avatar
OP Recognized Contributor
Flag Melbourne
Thanks Meter: 8,440
Donate to Me
I/O Schedulers

Why change your phones I/O Scheduler?

Most phone manufacturers keep your phone's I/O scheduler locked, so users are unable to modify any values which could change the performance of your phone. However, once your phone is rooted, you can change these values allowing the potential to boost your phones performance and even slightly increase battery life. Here is a thorough guide on all of the common i/o schedulers.
What is an 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 minimise time wasted by hard disk seeks.
- To prioritise 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.

Which schedulers are available?
  1. CFQ
  2. Deadline
  3. VR
  4. Noop
  5. BFQ
  6. FIOPS (Fair IOPS)
  7. SIO (Simple I/O)
  8. ROW
  9. ZEN
  10. SIOplus
  11. FIFO (First in First Out)
  12. Tripndroid
  13. Test
  14. Maple

I/O Scheduler Descriptions:

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.

- Generally performs the best in throughput tests
- Very stable, is the default Linux kernel I/O scheduler for many desktops and mobile devices
- Performs well on spinning storage and even on solid state storage for mixed workloads
- Generally seen as well balanced
- Processes requiring more I/O resources can be prioritised higher (such as indexing, system maintenance)

- I/O latency can be somewhat poor
- There is some scheduling overhead, although probably not too noticeable in tests and real world usage

The bottom line: One of the best all-rounder I/O schedulers available. CFQ is better suited for traditional hard disks, however it may give better throughput under some situations.

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.

- Excels in reducing latency of any given single I/O
- Can perform better than CFQ in certain workloads
- Performs well in (most) benchmarks
- Generally low scheduling overhead
- Very stable, default in recent Linux kernel versions

- Less I/O throughput than CFQ
- No ability to prioritise I/O bound processes over others

The bottom line: A good all-round scheduler. If you want good performance, you should try deadline.

The ROW I/O scheduler was developed with the mobile devices needs in mind. In mobile devices, we favor user experience upon everything else, thus we want to give READ I/O requests as much priority as possible. In mobile devices we won't have as much parallel threads as on desktops. Usually it's a single thread or at most 2 simultaneous working threads for read & write. Favoring READ requests over WRITEs decreases the READ latency greatly. The main idea of the ROW scheduling policy is: If there are READ requests in pipe - dispatch them but don't starve the WRITE requests too much.

- Low read latency, better for responsiveness and task switching
- Generally stable, has been adopted in many kernels

- Potentially higher write latency, reducing write performance

The bottom line: It is a good all-round scheduler despite being biased to read operations. Your device may feel more responsive after selecting ROW because it was designed for mobile devices. Older devices may see more of a boost in performance compared to newer devices.

SIO (Simple I/O):
Simple I/O aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority queue concepts, but only basic merging. SIO is a mix between Noop & deadline. No reordering or sorting of requests.

- Generally low I/O latency, better for responsiveness
- Very stable

- Performs poorly in benchmarks

The bottom line: One of my favourite schedulers, it is a good all-round scheduler. People who want better performance should avoid using this.

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.

- Low I/O latency, better responsiveness
- Very low scheduling overhead
- Very stable, used as default for some systems with solid state drives

- Performs poorly in benchmarks

The bottom line: Modern smartphones now use Noop as the default scheduler due to the fact that it works quite well with flash based storage. However older devices may experience slower performance when selected. If you want a very simple I/O scheduler algorithm (because of battery life or latency reasons), you can select this.

Unlike other scheduling software, synchronous and asynchronous requests are not handled separately, but it will impose a fair and balanced within this deadline requests, that the next request to be served is a function of distance from the last request.

- Generally excels in random writes.

- Sometimes unstable and unreliable

The bottom line: Not the best scheduler to select. You will probably find that other schedulers are performing better while being more stable.

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.

- Good I/O throughput, sometimes matching CFQ in performance
- Better I/O latency than CFQ, better responsiveness
- Well balanced, even more so than CFQ
- Generally stable, default in some custom kernels and Linux distributions

- Performs poorly in benchmarks, sometimes a lot worse in some areas

The bottom line: There are better schedulers out there that will perform better than BFQ. It is quite a complex scheduler that is better designed for traditional hard disks.

ZEN is based on the Noop, Deadline and SIO I/O schedulers. 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 Noop blended with VR features.

- Excels in I/O latency, good for responsiveness
- Very stable
- Generally seen as well balanced

- There is some scheduling overhead, but less than CFQ

The bottom line: It is pretty much a better version of VR, performs quite well and is stable. Overall this is a good choice for most smartphones.

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

- Better I/O latency than SIO in certain workloads

- Still performs about the same as SIO in benchmarks

The bottom line: If you liked SIO, you will like SIOplus. It performs slightly better in some usage case scenarios, but performance seekers should look else where.

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) I/O scheduler 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.

- Generally has good I/O latency, performs well in some benchmarks
- Like CFQ, has some scheduling overhead

- On certain configurations, people may experience issues with stutters in day-to-day device usage
- Not the most stable scheduler

The bottom line: Most people who use FIOPS will get a noticeable performance improvement. However, you may get issues with scrolling and general lags.

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.

- Low I/O latency, better responsiveness
- Very low scheduling overhead
- Very stable, used as default for some systems with solid state drives

- Performs poorly in benchmarks

The bottom line: Like Noop, but is less common. If you want a very simple I/O scheduler algorithm (because of battery life or latency reasons), you can select this.

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

- Excels in I/O latency, good for responsiveness, sometimes better with some tuning
- Should be stable, however is not adopted widely
- Generally seen as well balanced

- There is some scheduling overhead, but less than CFQ

The bottom line: Tripndroid isn't very common. There are other schedulers you can choose which may perform similar or better. However it is a good all-round scheduler.

The test I/O scheduler is a duplicate of the Noop scheduler with addition of test utility. It allows testing a block device by dispatching specific requests according to the test case and declare PASS/FAIL according to the requests completion error code.

- Same as Noop, but can be beneficial to kernel developers

- Same as Noop

The bottom line: Shouldn't really be used by anyone. You should be using Noop instead of this.

Maple is based on the Zen and Simple I/O schedulers. It uses ZEN's first-come-first-serve style algorithm with separate read/write requests and improved former/latter request handling from SIO. Maple is biased towards handling asynchronous requests before synchronous, and read requests before write. While this can have negative aspects on write intensive tasks like file copying, it slightly improves UI responsiveness. When the device is asleep, maple increases the expiry time of requests so that it can handle them more slowly, causing less overhead.

- Well rounded
- Designed for mobile devices in mind
- Better I/O latency than ZEN in certain workloads

- May be unstable on some devices

The bottom line: This is still a very new I/O scheduler which should perform slightly better than ZEN. It will continue to improve with more development.


Anxiety doesn't separate asynchronous and synchronous requests because asynchronous ones are rarely seen. It prioritizes reads over writes just like Maple, but tends to starve writes more (this is tunable). It is based on noop with a basic first-in-first-out algorithm, whereas Maple is based on deadline with time tracking for expiration. This makes Anxiety better on battery than Maple, as well as fast. It prioritizes latency over throughput which means that requests happen quicker but transfer data slower.

- Designed for mobile devices in mind
- Possibly more battery savings compared to Maple

- Data transfers and write speeds may be slower

Multi-queue schedulers:

If you have a fairly recent phone, the chances are that you are able to use multi-queue (MQ) I/O schedulers. It comes from recent works from the upstream Linux kernel as devices are becoming more powerful with better storage and processors. These schedulers in theory should perform better than your traditional schedulers (e.g. noop, SIO, etc), by having better utilisation of multi-core CPUs/SOCs. You can have a view of some of the descriptions here: Arch Linux wiki.

The bottom line: A good well-rounded I/O scheduler that is relatively simple and performs quite well in most scenarios.

I/O Read Ahead Buffer:

If you've used a custom kernel, you probably have heard of a term called Read Ahead Buffer or Cache. It's basically a cache for files that have been opened recently on your mobile device, so that they can be quickly accessed again if needed. By android default, this value has been set to 128kB. Usually having more buffer means that more files can be cached, this can mean higher read and write speeds, but also this can result in more I/O latency. There is a point where increasing the I/O read ahead will have no benefit to read/write speeds.

Have a look at the graph below:



I/O Read Ahead Buffer is dependent on the size of your flash storage (internal/external) unlike I/O schedulers. Below is the recommended settings for the given size that will yield the best performance (differs between setups).

Less than 8GB - 128KB
8GB - 512KB
16GB - 1024KB
32GB or above - 2048KB

Any setting above what I have recommended may yield no extra performance!

If you have issues such as failed reads and writes after changing these values, try a smaller value. Please note that some SD cards may experience issues after setting a higher buffer value.

What to remember:
- More isn't always better!
- Some SD cards can't handle high read ahead cache values, so make sure you have a genuine high quality SD card
- Default is good enough for most people, but isn't the best for performance
- Performance difference varies between devices

Results :
Phone: Sony Xperia Z2
Scheduler: as per indicated
Read Ahead: 512kB
App: AndroBench 4

Here is a graph of the performance of the i/o schedulers. Note: a higher score doesn't mean it is the best io scheduler. These numbers mean nothing in real world performance, so take the following a mere glimpse of the performance of schedulers.

Sequential in MB/sec (Higher is better)

Random in IOPS (Higher is better)

Thanks haldi for the graphs! Link:

Recommended IO schedulers:

- Deadline

Justification: For overall performance, evidence has shown that some form of scheduling such as seen in CFQ or BFQ is beneficial not only for mechanical drives, but also for solid state media [citation needed]. These schedulers are usually configured to understand the differences between the storage devices, and hence for example will not treat Internal Storage as a traditional rotating hard drive(based on seeks). In smartphones, we do a lot of concurrent I/O multitasking, and hence, schedulers that have some logic to impose fairness will help in this situation

For best performance:
- Deadline

Justification: Results have shown that schedulers such as CFQ (those that impose some form of fairness) achieve excellent throughput, but the cost of increase scheduling overhead and latency. On modern smartphones, added overhead and latency shouldn't have a significant impact to the responsiveness of the system, since we are dealing with much more powerful CPUs than those of the past. Synthetic benchmarks should not be the deciding factor of a scheduler

For least overhead:
- Noop
- Deadline

Justification: If the only thing you value is lower overheads on I/O processing, your best bet is Deadline. Why? Noop has been recommended on some guide found on the internet for solid state media, however there are known cases where Noop has caused issues in some particular workloads [citation needed]

Source: xda-developers,
The Following 431 Users Say Thank You to Saber For This Useful Post: [ View ] Gift Saber Ad-Free