]> git.kernelconcepts.de Git - karo-tx-linux.git/commit
raid5: only dispatch IO from raid5d for harddisk raid
authorShaohua Li <shli@fb.com>
Wed, 4 Jan 2017 17:33:23 +0000 (09:33 -0800)
committerShaohua Li <shli@fb.com>
Mon, 13 Feb 2017 17:17:50 +0000 (09:17 -0800)
commit765d704db1f583630d52dc14c1ea573db6783459
treebea2268223f268cfc7556a24bd5dd1cae1a09d05
parent03a9e24ef2aaa5f1f9837356aed79c860521407a
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>
drivers/md/raid5.c
drivers/md/raid5.h