影响IO性能的request queue

 

最近一段时间在做IO性能对比测试分析的时候发现Linux-3.2的IO性能要比Linux-2.6.23差。在内核中，并发顺序读的情况下（绕过设备的buffer cache），Linux-3.2的性能比Linux-2.6.23有很大差别，性能降低了15%左右。这是为什么呢?

 

首先看一下 Linux-3.2中测试的IO Stack模型，如下图所示：

 

这个IO Stack由DM设备和SD设备堆叠而成，DM设备完成multipath的功能，SD设备是一个SCSI块设备。从这个模型中可以看出Linux-3.2的DM-Multipath设备层拥有一个磁盘SD设备相同的request Queue，BIO达到该层之后需要进行IO的调度处理。这个request Queue是Linux-3.2与Linux-2.6.23不同的地方。Linux-2.6.23中的device mapper机制仅仅起到转发BIO的作用，具体功能由device mapper的target完成。不同之处在于Linux-3.2中的device mapper机制提供了两种类型的转发机制：一种是REQUEST_BASED的转发机制；另一种是BIO_BASED的转发机制。这两种转发机制的差别在于REQUEST_BASED类型会采用request queue进行IO调度，然后统一处理request中的BIO。BIO_BASED类型和传统的device mapper中的转发机制是一样的。

 

在一般的存储设备上，如果在DM层再做一层request queue进行IO调度，必然会导致读请求处理比Linux-2.6.23中的延迟长，因此，会导致读IO性能的剧降。我的测试结果是在并发多流顺序读的情况下，Linux-3.2内核的读性能降低了15%左右。写性能的影响并不十分明显，但是，如果调度算法选择不好，写性能还是有一定影响。

 

由于我采用的是系统默认的DM-multipath驱动，在Linux-3.2中该multipath只支持REQUEST_BASED类型，因此，如果想要把这一层的request Queue移除，那么只能修改Linux-3.2中的代码将DM-multipath改成BIO_BASED类型。个人认为Linux中的Multipath驱动应该保留BIO_BASED的模式，这样对基于磁盘的multipath应用会有一定的性能提升。