IO调度策略对上面的块设备层和下面的磁盘驱动起作用，它实质上切断了数据从应用程序到磁盘的路径，从而也就解除了块设备和底层驱动程序之间的耦合，这样的话就可以匹配上下两层之间的不和谐，试想如果磁盘速度很慢，那么就可以在IO调度策略中加入可以避免过多寻道的操作，比如AS预测调度器，比如合并不同的请求，但是对于Flash-DOM之类的可以随机存储的存储器就没有必要采用复杂的调度算法了。对于linux的实现，IO调度模块对上层实际上就是一个入队操作，根据系统管理员的配置或者自适应决断结果将一系列IO请求分配到一系列队列中，入队的策略主要在于怎么排队，比如一共有哪些队列，一个请求应该排入哪个队列，之后的事情就不用管了，而出队操作是IO调度模块下层的接口，它主要负责从哪个队列选择下一个要服务的请求，它不管块设备层是怎么将请求排入队列的，然而到此为止了吗？为了使得一些策略起作用，同时也为了使得“跨层操作”最小化，所谓的队列中必须积攒了一定数量的IO请求的时候才能激发调度，也就是说块设备层不断的将请求加入到策略化的队列中，而驱动程序并不是马上就对队列中的请求进行服务，而是等到队列中的请求积攒到一定数量的时候再开始服务过程。我们知道，计算机中，凡是跨层操作，开销几乎一定大于层内操作，这是因为分层是为了解耦合，是为了机制和策略分离，层与层之间抽象出了接口，而接口需要确保极大的兼容性，所以为了照顾接口的兼容性和其本身的安全性稳定性以及正交性，也就必然需要将问题一般化，因此就需要一个环境的切换，因此性能的牺牲也是必然的，我们常常听说尽量少进行系统调用也就是这个道理，对应到IO调度层也是这个道理，因此我们千万不要要求磁盘驱动程序不断的取得请求不断的服务，让它休息一会也许会取得更好的性能。linux的实现中，用了一个十分形象的方式实现了这个，plug和unplug，这两个词汇从其本意上就能让人理解linux的实现方式，plug是活塞，unplug是拔下活塞的意思，起初，在队列的开头赛上一个活塞(plug)，待到队列中的请求达到一定数量后者塞上活塞已经有一段时间以后，那么拔下活塞(unplug，每个磁盘的请求队列都有一个unplug回调函数)，这么解释就什么都清楚了。
IO调度有很多策略，起初就是linus电梯，这个算法很直观同时也必然很简单，2.6内核之后，添进来很多算法，我总结了一下基本就是两点，其中cfq是按照网络负载均衡算法改造的，而其他的算法都是对linus电梯的改进，deadline算法避免了饥饿，避免了磁盘中临近的区域大量的请求被瞬间提交，从而造成早期提交的一个稍微远一些的请求饥饿，因为deadline算法中每一个请求都有一个饥饿时间限制值，一个请求同时要插入到两个队列，其中一个队列是linus电梯里面的队列，另一个是FIFO的按照到达时间排序的队列，这个FIFO队列也按照read和write进行了区分，read队列的饥饿时间限制要更短一些，因为应用程序对于读请求一般都是同步意义的，并且对于磁盘文件来讲如果顺序读的话，前面的读没有完成后面的读更是无法进行，而写操作就不是这样的，应用程序写文件一般都是异步意义上的，更复杂的，如果很多进程都在写一个文件的一个区域，那么只要最后一个写操作完成就可以了，前面的几个都可以直接抛弃，再者，写入缓存还是写入磁盘，这都不是应用程序所关心的，因此写操作的超时时间要大于读操作，deadline在linus电梯的基础上避免了饥饿，那么引入了另一个问题，试想如果一系列写操作正在进行，这些写操作都是经过linus电梯算法合并和排序过的，这时突然有个读请求饥饿超时到时间了，那么不可避免的，磁头要移动到读请求的位置，这样显然降低了磁盘的吞吐量，然而这个突然的移动还不得不做，读请求完成以后，按照deadline的逻辑，磁盘的磁头又返回刚才被读请求打断的写请求的位置，然后...，这一次又一次的移动，不断降低着磁盘的吞吐量，并且磁头频繁移动，损坏磁盘，AS算法出现了，在不得不服务超时读请求后，不是返回写请求，而是等待一段时间，因为调度策略认为，在等待的这一段时间内，可能会有另一个读请求，将读请求积攒在一起总比来来去去要好，AS调度策略的要点在于到底是否要等待以及等待多久，这些都是按照对进程的统计完成的，算法很复杂，然而思想却很简单，一个不得不做的读请求完成以后，IO调度器在一段时间内等待“相邻”读请求的到来，随着预测得到的等待时间的增长，“相邻”的概念范围越来越宽，并且也能加进来一些写请求，最终如果这个相邻的概念已经扩展到了整个磁盘，那么AS算法也就退化成了deadline算法。实质上，AS算法就是摆脱了deadline算法的弊端，它的弊端就是磁头可能来回移动从而降低了吞吐量，而deadline算法是摆脱了linus电梯的弊端，它的弊端就是会引起饥饿，总而言之，吞吐量和磁头寻道紧密相连，它和饥饿是一对冤家，需要权衡！
本文转自 dog250 51CTO博客，原文链接:http://blog.51cto.com/dog250/1274077
