diff options
author | Shaohua Li <shli@kernel.org> | 2012-07-31 10:03:53 +1000 |
---|---|---|
committer | NeilBrown <neilb@suse.de> | 2012-07-31 10:03:53 +1000 |
commit | 12cee5a8a29e7263e39953f1d941f723c617ca5f (patch) | |
tree | 8aaf2fe512cf82e0640656640335ea2d7f0b2ec0 /samples/Makefile | |
parent | 9dedf60313fa4dddfd5b9b226a0ef12a512bf9dc (diff) |
md/raid1: prevent merging too large request
For SSD, if request size exceeds specific value (optimal io size), request size
isn't important for bandwidth. In such condition, if making request size bigger
will cause some disks idle, the total throughput will actually drop. A good
example is doing a readahead in a two-disk raid1 setup.
So when should we split big requests? We absolutly don't want to split big
request to very small requests. Even in SSD, big request transfer is more
efficient. This patch only considers request with size above optimal io size.
If all disks are busy, is it worth doing a split? Say optimal io size is 16k,
two requests 32k and two disks. We can let each disk run one 32k request, or
split the requests to 4 16k requests and each disk runs two. It's hard to say
which case is better, depending on hardware.
So only consider case where there are idle disks. For readahead, split is
always better in this case. And in my test, below patch can improve > 30%
thoughput. Hmm, not 100%, because disk isn't 100% busy.
Such case can happen not just in readahead, for example, in directio. But I
suppose directio usually will have bigger IO depth and make all disks busy, so
I ignored it.
Note: if the raid uses any hard disk, we don't prevent merging. That will make
performace worse.
Signed-off-by: Shaohua Li <shli@fusionio.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Diffstat (limited to 'samples/Makefile')
0 files changed, 0 insertions, 0 deletions