A Scheduling Framework that Makes any Disk Schedulers Non-work-conserving solely based on...——论文泛读

FAST 2011 Paper 论文阅读笔记整理

背景

断续工作型（Non-work-conserving）磁盘调度器：当前请求执行完时，从当前挂起的请求和未来的请求中选出一个请求执行，选未来请求时则保留磁盘头位置等待。因为即将到达的请求可能比当前挂起的请求更接近磁盘头。如果这样的请求很快到达，并且避免长距离磁盘寻道的好处超过了空闲等待的成本，则保留磁盘头的决定可能是合理的。例如同步请求，只有在请求执行后才能看到其下一个请求，此时进行等待可以利用其空间局部性。

问题

利用空间局部性对于磁盘调度器实现高吞吐量至关重要。由于磁盘头查找的高成本和请求服务的不可抢占性，最先进的断续工作型磁盘调度器会考虑未来请求的位置，例如预期调度器（AS）[16]、完全公平队列（CFQ）[1]。

但面临三个问题：

• 如果对磁盘的请求来自多个进程，则调度决策是根据这些进程组合I/O行为。对单独的进程局部性分析限制可能会低估实际可用的局部性，并失去减少寻道的机会。

• 当有关进程的知识不可用时，例如在虚拟机环境、网络、并行文件系统、SAN中，使得断续工作型磁盘调度器效率低。

• 断续工作型调度器只是判断下一个请求发出所需时间。因此，进程的两个连续I/O调用之间的时间，被视为进程的一个属性，并使用进程的历史信息来估计和预测。如果磁盘是在其上进行条带化的磁盘阵列的成员，则该进程的下几个请求可能会转到阵列中的其他磁盘。因此，I/O间隔时间不仅取决于进程，还取决于阵列上的数据条带模式，以及其他磁盘的调度决策。导致磁盘的调度器效率低。

挑战

根据以上分析，需要设计不依赖进程信息的调度器，面临三个挑战：

• 必须根据一些标准对请求进行分组，以跟踪每组请求的位置。然而，如果没有进程信息，任何人工分组方法，都很难准确预测。例如，一种看似有效的方法是将磁盘划分为不同的区域，然后跟踪每个区域的局部性。然而，如果区域设置得太小，一个进程的同步请求可能会跨越多个区域，从而使每个区域的局部性太弱。如果区域设置得太大，这使得测量的局部性由于请求间距离大而变弱。此外，区域大小必须根据磁盘上不断变化的请求分布进行动态调整。

• 局部性是相对的。当有相对靠近当前磁盘头的挂起请求时，调度程序必须仅评估强局部性请求的概率，而忽略相对较远的请求。相反，如果挂起的请求相对较远，则需要包括一些不太接近的请求来进行位置分析。这将显著增加算法的复杂性和成本。

• 对于磁盘阵列上条带化的数据，即使连读I/O间隔时间足够短，但在每个磁盘上看到的连续请求时间间隔也可能太大，单个磁盘上的调度器无法利用。在这种情况下，是否可以通过协调单个磁盘的调度来减少时间间隔，从而使磁盘有价值等待未来的请求。

本文方法

本文提出了一种轻量级的磁盘调度框架，不需要任何进程知识来分析请求位置，仅基于请求本身的特性，以充分利用局部性。

• 分析请求到达时间、到达请求位置、挂起请求位置。在观察一致模式后，调度框架指导调度器在做出下一个决定时遵循趋势。同时，该框架保留了连续工作型调度器的机制，以避免请求服务中的长延迟甚至饥饿。

• 提出了磁盘阵列断续工作型调度方案。创建了一个与磁盘阵列相对应的虚拟磁盘，并在其上应用框架，以评估针对特定请求流跨磁盘协调调度的潜在好处。当评估结果为肯定时，将对所有磁盘进行协调调度。

• 在Linux 2.6.31和Linux软件RAID MD中实现并评估了单磁盘和磁盘阵列的调度框架，统称为流调度。

通过对具有代表性的基准进行广泛的实验，并在Xen虚拟机和PVFS并行文件系统等各种环境中，表明所提出的调度框架可以将性能提高3.2倍。

总结

针对断续工作型磁盘调度器的优化，现有方法在无法获取进程信息时、面对磁盘阵列时，效果不佳。本文提出流调度，只基于请求本身局部性。（1）分析请求到达时间、到达请求位置、挂起请求位置。在观察到一致模式后，调度框架指导调度器遵循模式。同时，保留了连续工作型调度器的机制，以避免请求服务中的长延迟甚至饥饿。（2）提出了磁盘阵列断续工作型调度方案。创建了一个与磁盘阵列相对应的虚拟磁盘，并在其上应用框架，以评估针对特定请求流跨磁盘协调调度的潜在好处。当评估结果为肯定时，将对所有磁盘进行协调调度。