[Droid Eris Android Development] Izeltokatl:
NOOP scheduler

For those having difficulties finding out which scheduler to use:

-----------------------------------

The NOOP scheduler is the simplest I/O scheduler for the Linux kernel.

This scheduler was developed by Jens Axboe.

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.

source: http://en.wikipedia.org/wiki/Noop_scheduler

XDA posts: http://xdaforums.com/showpost.php?p=4810429&postcount=14

----------------------

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.

Anticipatory scheduling yields significant improvements in disk utilization for some workloads. In some situations the Apache web server may achieve up to 71% more throughput from using anticipatory scheduling.

The Linux anticipatory scheduler may reduce performance on disks using TCQ, high performance disks, and hardware RAID arrays.[5] An anticipatory scheduler (AS) was the default Linux kernel scheduler between 2.6.0 and 2.6.18, by which time it was replaced by the CFQ scheduler.

source: http://en.wikipedia.org/wiki/Anticipatory_scheduling

--------------------------------

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 resource starvation. 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.

By default, read requests have an expiration time of 500 ms, write requests expire in 5 seconds.

source: http://en.wikipedia.org/wiki/Deadline_scheduler

--------------------------

BFQ

We are working [on] a new I/O scheduler based on CFQ, aiming at improved predictability and fairness of the service, while maintaining the high throughput it already provides," began Fabio Checconi, announcing the BFQ I/O scheduler. "The Budget Fair Queueing (BFQ) scheduler turns the CFQ Round-Robin scheduling policy of time slices into a fair queuing scheduling of sector budgets," he continued, "more precisely, each task is assigned a budget measured in number of sectors instead of amount of time, and budgets are scheduled using a slightly modified version of WF2Q+. The budget assigned to each task varies over time as a function of its behaviour. However, one can set the maximum value of the budget that BFQ can assign to any task." Fabio went on to explain:

"The time-based allocation of the disk service in CFQ, while having the desirable effect of implicitly charging each application for the seek time it incurs, suffers from unfairness problems also towards processes making the best possible use of the disk bandwidth. In fact, even if the same time slice is assigned to two processes, they may get a different throughput each, as a function of the positions on the disk of their requests. On the contrary, BFQ can provide strong guarantees on bandwidth distribution because the assigned budgets are measured in number of sectors. Moreover, due to its Round Robin policy, CFQ is characterized by an O(N) worst-case delay (jitter) in request completion time, where N is the number of tasks competing for the disk. On the contrary, given the accurate service distribution of the internal WF2Q+ scheduler, BFQ exhibits O(1) delay.

previously posted source: http://kerneltrap.org/taxonomy/term/1231

here is a nice article on "choosing the right I/O Scheduler"

http://www.redhat.com/magazine/008jun05/features/schedulers/