[ONE Android Development] hhp_211:
clips from some favorite bookmarked I/O Scheduler links

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.

Q: What is this Aaron Carol stuff you added (V(r ), no-op changes, fifo (I wrote a detailed answer already, so wanted to include it in FAQ)

A:

1.) V(R ) is similar to deadline (uses deadlines for fairness). Basically, requests are based on on the distance from the last request/I.E: the next closest request comes first (with penalty of rev_penalty). Naturally, we don't care about the distance from the last request because we're using flash memory (in our case, handling the closest request is nothing but overhead since there is no travel delay) so it doesn't matter where the next request is. I'd say in a nutshell it would be a higher thoroughput/higher latency version of deadline in a typical desktop environment. On our phones, not sure where it would fall. (I removed some unnecessary parts of the algorithm, like choosing closest request/changing head direction, etc.) You may say "Oh, why would you add an I/O scheduler that handles requests like that?" Well, it's not the only one. Deadline/CFQ/BFQ will all sort requests. But the difference between them, in my experience, is usually negligible for real-world tests.

2.) FIFO: Ok, so no-op stands for "no operation". Essentially that means handle requests in order, don't sort them, don't merge them, don't do anything except handle the next request in line. In reality, it actually does some sorting (sorts dispatches, and some requests i think). FIFO is a true "no-op" scheduler. Doesn't do anything, strictly FCFS.

* e.g. We could have 3 requests in the queue. the first one could be very small, second one could be astronomically large, third one can be extremely small. Some schedulers may say, lets do #3 before #2 because it is right next to where we're at and it's very short. Some schedulers may say, lets combine #3 and #2 to make it 1 large request. Fifo doesn't do any of that, it goes in order. Literally first in , first out.

3.) No-op: No-op already exists in the kernel obviously, now it does a bit more stuff. Like I said above, no-op isn't entirely no-op. I have a patch from AC that makes no-op do full merging and sorting. Meaning, it actually will merge some requests if applicable and sort them based on things like priority, size, distance, etc. Other change to no-op is that dispatches are all back-inserted. Meaning added to the back of a stack. Normally no-op sorts dispatches.

Q: What I/O scheduler should I use?

A: I haven't really found any real-world difference between any of them. I personally prefer the simpler algorithms of Zen/SIO.

Q. "Best I/O Scheduler?"

A.There is nothing called "best" i/o scheduler. Depending on your usage environment and tasks/apps been run, use different schedulers. That's the best i can suggest.

However, considering the overall performance, battery, reliability and low latency, it is believed that

SIO > Noop > Deadline > VR > BFQ > CFQ, given all schedulers are tweaked and the storage used is a flash device.

and These Here::

http://xdaforums.com/showthread.php?t=1989824

http://xdaforums.com/showthread.php?t=1558153

.