summaryrefslogtreecommitdiffstats
path: root/lib
diff options
context:
space:
mode:
authorShaohua Li <shli@fb.com>2017-01-04 09:33:23 -0800
committerShaohua Li <shli@fb.com>2017-02-13 09:17:50 -0800
commit765d704db1f583630d52dc14c1ea573db6783459 (patch)
treebea2268223f268cfc7556a24bd5dd1cae1a09d05 /lib
parent03a9e24ef2aaa5f1f9837356aed79c860521407a (diff)
downloadlinux-765d704db1f583630d52dc14c1ea573db6783459.tar.gz
linux-765d704db1f583630d52dc14c1ea573db6783459.tar.xz
raid5: only dispatch IO from raid5d for harddisk raid
We made raid5 stripe handling multi-thread before. It works well for SSD. But for harddisk, the multi-threading creates more disk seek, so not always improve performance. For several hard disks based raid5, multi-threading is required as raid5d becames a bottleneck especially for sequential write. To overcome the disk seek issue, we only dispatch IO from raid5d if the array is harddisk based. Other threads can still handle stripes, but can't dispatch IO. Idealy, we should control IO dispatching order according to IO position interrnally. Right now we still depend on block layer, which isn't very efficient sometimes though. My setup has 9 harddisks, each disk can do around 180M/s sequential write. So in theory, the raid5 can do 180 * 8 = 1440M/s sequential write. The test machine uses an ATOM CPU. I measure sequential write with large iodepth bandwidth to raid array: without patch: ~600M/s without patch and group_thread_cnt=4: 750M/s with patch and group_thread_cnt=4: 950M/s with patch, group_thread_cnt=4, skip_copy=1: 1150M/s We are pretty close to the maximum bandwidth in the large iodepth iodepth case. The performance gap of small iodepth sequential write between software raid and theory value is still very big though, because we don't have an efficient pipeline. Cc: NeilBrown <neilb@suse.com> Cc: Song Liu <songliubraving@fb.com> Signed-off-by: Shaohua Li <shli@fb.com>
Diffstat (limited to 'lib')
0 files changed, 0 insertions, 0 deletions