哪个IO控制器最公平

Which I/O controller is the fairest of them all?

简单翻译：

I/O controller 用来调度对存储设备的访问——根据系统管理员的配置，对不同类型的进程指定不同级别的访问策略。它可以避免I/O密集型的访问不合理的占用资源，显然，对于那些运行很多个虚拟机的系统，这个非常有用的特性。但是，现在Linux的主线版本，还没有加入I/O controller.

看这么一张磁盘I/O的过程图

 
首先是请求Virtual block，是设备映射层，比如 MD RAID Layer，把请求映射到真正的物理设备；但在实际请求物理设备之前还要通过 I/O scheduler，它应用某种策略以提高磁盘访问效率，尽量避免来回的seek；最后才是硬件访问.

I/O controller可以在block layer里面（上面这个蓝框）的任意一层实现

【具体技术实现细节就不翻译了】
1. ，在Virtual Block Layer 实现。这里有两个问题，一个是没有用现成的control group 机制；另外就是它的控制是基于进程的，而对于内核的I/O，比如VM管理，它没有对应的策略。于是原作者又弄了一个 patch，解决了这两个问题。

它的缺点在于，a. 必须要使用设备映射, b. 对底层的I/O scheduler有影响, c. 没有提供任何 QoS 保证，只是做固定的I/O带宽比例分配

2. , 它利用了control group，这样策略参数可以通过 cgroup filesystem来配置。

它的配置模式中，每个cgroup只能联系一个设备，一方面多个设备就必须配置多个group，但另一方面对不同的设备可以配置不同的策略。

一个最有意思的设计是它在I/O请求初始化的地方实现，包括内存管理子系统、文件系统、异步I/O的writeback、块设备处理...这样控制 带宽的方法之一是让进程去sleep一段时间，看起来这样做比维护一个块IO队列要强。

io-throttle 的好处在于代码相对来说比较简单，可以通过让进程睡眠的方法来控制流量；它没有真正的 QoS，但在某种程度上有点接近。它的问题在代码侵入性是最强的，涉及的子系统太多，另外它同样会影响I/O scheduler策略

3. , 解决了上述两个方案共同的缺点——它在 I/O scheduler那里实现了一个基于cgroup的I/O controller。虽然支持所有的主线 scheduler：CFQ、Deadline、Anticipatory、no-op，但看起来好像主要是针对 CFG 做的优化。

它弥补了前两个 patch 的缺点，但它不能针对不同的设备配置策略（这是io-throttel的优点），而且并不是在所有 scheduler 下都可靠工作。

Linux 不太可能引入多个 controller，那它最终会选择哪一个？ io-controller 最受青睐，但相信其它两个方案也会继续改进直到最后幸运者胜出