PAGE_CACHE_SIZE对md raid5的影响

目前md中关于raid5的stipe大小，内核都是PAGE_SIZE，对于x86而言都是4K。由于对kernel的内存管理不熟悉，从没有考虑到如果改变PAGE_SIZE是否对性能有改善。

最近同事拿了PMC的一款MIPS 4core 系统，过来说。PMC调整PAGE_SIZE从4K到16K，整个raid5初始化从55MB/s增加到100MB/S。PMC的工程师说这是因为增加PAGE_SIZE后，xor加快导致的。

我感觉PAGE_SIZE增加，和xor速度应该没有关系。正好我也没有接触过PAGE_SIZE非4K的情况，就想了解下这方面的知识。

查询了发现，MIPS支持4K/16k/64k的PAGE_SIZE。我想这是不是所谓的hugepage，但是查了查这个和hugepage不是同一个概念，应该是由硬件决定的。

http://www.linux-mips.org/wiki/Page_size 中描述不同MIPS的所支持的PAGE_SIZE大小。

回到重点为什么PAGE_SIZE变大后，resync速率增加如此明显。

内核：2.6.35

cpu：MIPS 1004Kc V2.8（4 core）

• bio merge

首先用bblktrace跟踪发现某段时间内的统计：

• PAGE_SIZE=4k

Total (8,48):
 Reads Queued:           0,        0KiB     Writes Queued:           0,        0KiB
 Read Dispatches:        0,        0KiB     Write Dispatches:        0,        0KiB
 Reads Requeued:         0         Writes Requeued:         0
 Reads Completed:     2273,    89052KiB     Writes Completed:        0,        0KiB
 Read Merges:            0,        0KiB     Write Merges:            0,        0KiB
 IO unplugs:             0             Timer unplugs:           0

• PAGE_SIZE=16K

Total (8,48):
 Reads Queued:           0,        0KiB     Writes Queued:           0,        0KiB
 Read Dispatches:        0,        0KiB     Write Dispatches:        0,        0KiB
 Reads Requeued:         0         Writes Requeued:         0
 Reads Completed:      506,   161232KiB     Writes Completed:        0,        0KiB
 Read Merges:            0,        0KiB     Write Merges:            0,        0KiB
 IO unplugs:             0             Timer unplugs:           0

通过比较completed，发现16K的request明显比4K要大很多，由于内核是2.6.35，block层的biomerge并没有目前内核的好，所以尽量理论上request最大是512K，但是对于4K的request最大是256个扇区。这是md代码md_do_sync中的window=32×（PAGE_SIZE/512），而且每执一个window都会unplug md设备，合并最大是256扇区。

但是由于16K情况下，PAGE_SIZE增加4倍，导致window大小增加4K，达到最大值即512K。

为了验证这个想法，我增加window到128，并同时增加stripe数目，这样就不会因为缺少stripe而导致unplug。在这种情况下resync速率也会达到100MB/s。

数据验证了速率提高不是因为xor速率增加，而仅仅是因为request变大，导致resync速率提高了。硬盘是机械硬盘，合并的多少直接决定resync速率的高低。

• CPU 利用率

在测试中发现一个问题，4K情况下100MB/s cpu利用率明显高于16K情况下。

4k,100MB/s:20%左右；16K,100MB/s：低于15%。

对于这个现象我的理解是，相同阵列情况下由于PAGE_SIZE增加，导致相同的函数执行减少了3倍，所以16Kcpu低是正常的。这也许是使用16K的最大优点就是在相同情况下，明显减少IO路径执行次数，降低CPU利用率。

当然为什么执行次数减少3倍，CPU的效果却没有这么明显？或许可以这样理解，XOR的计算占CPU太大，导致函数执行次数变小后，CPU不明显

cpu占有率=(函数执行时间+XOR)/总时间；XOR比重很大的情况下，函数执行时间变化就没有那么大的影响。

当然这个没有用数据说话，我想可以用perf执行的来统计xor的CPU占有率来说明这个问题。

• 结论
  

增大PAGE_SIZE，减少IO路径的执行次数，进而导致CPU使用率减少。如果修改raid5的实现在x86下实现，可以评论测CPU是否有明显提高。