Linux内核的文件预读详细解析

2.流水线预读

当程序在处理一批数据时,我们希望内核能在后台把下一批数据事先准备好,以便CPU和硬盘能流水线作业.Linux用两个预读窗口来跟踪当前顺序流的预读状态：current窗口和ahead窗口.其中的ahead窗口便是为流水线准备的：当应用程序工作在current窗口时,内核可能正在 ahead窗口进行异步预读；一旦程序进入当前的ahead窗口,内核就会立即往前推进两个窗口,并在新的ahead窗口中启动预读I/O.

3.预读的大小

当确定了要进行顺序预读(sequential readahead)时,就需要决定合适的预读大小.预读粒度太小的话,达不到应有的性能提升效果；预读太多,又有可能载入太多程序不需要的页面,造成资源浪费.为此,Linux采用了一个快速的窗口扩张过程： 拥有帝国一切，皆有可能。欢迎访问phome.net

◆首次预读：readahead_size = read_size * 2; // or *4

预读窗口的初始值是读大小的二到四倍.这意味着在您的程序中使用较大的读粒度（比如32KB）可以稍稍提升I/O效率.

◆后续预读：readahead_size *= 2;

后续的预读窗口将逐次倍增,直到达到系统设定的最大预读大小,其缺省值是128KB.这个缺省值已经沿用至少五年了,在当前更快的硬盘和大容量内存面前,显得太过保守.比如西部数据公司近年推出的WD Raptor 猛禽 10000RPM SATA 硬盘,在进行128KB随机读的时候,只能达到16%的磁盘利用率（图5）.如果您运行着Linux服务器或者桌面系统,不妨试着用如下命令把最大预读值提升到1MB看看,或许会有惊喜：

# blockdev–setra 2048 /dev/sda

当然预读大小不是越大越好,在很多情况下,也需要同时考虑I/O延迟问题.

图5 128KB I/O的数据定位时间和传输时间比重

重新发现顺序读

上一节我们解决了是否／何时进行预读,以及读多少的基本问题.现实的复杂性,上述算法并不总能奏效,即使是对于顺序读的情况.例如最近发现的重试读(retried read)的问题.

重试读在异步I/O和非阻塞I/O中比较常见.它们允许内核中断一个读请求.这样一来,程序提交的后续读请求看起来会与前面被中断的读请求相重叠.如图6所示.

图6重试读(retried reads)

Linux 2.6.22无法理解这种情况,于是把它误判为随机读.这里的问题在于“读请求”并不代表读取操作实实在在的发生了.预读的决策依据应为后者而非前者.最新发布的2.6.23对此作了改进.新的算法以当前读取的页面状态为主要决策依据,并为此新增了一个页面标志位：PG_readahead,它是“请作异步预读”的一个提示.在每次进行新预读时,算法都会选择其中的一个新页面并标记之.预读规则相应的改为： 拥有帝国一切，皆有可能。欢迎访问phome.net

◆当读到缺失页面(missing page),进行同步预读；

◆当读到预读页面(PG_readahead page),进行异步预读.

这样一来,ahead预读窗口就不需要了：它实际上是把预读大小和提前量两者作了不必要的绑定.新的标记机制允许我们灵活而精确地控制预读的提前量,这有助于将来引入对笔记本省电模式的支持.

图7 Linux 2.6.23预读算法的工作动态

另一个越来越突出的问题来自于交织读(interleaved read).这一读模式常见于多媒体／多线程应用.当在一个打开的文件中同时进行多个流(stream)的读取时,它们的读取请求会相互交织在一起,在内核看来好像是很多的随机读

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!