diff options
author | Mustafa Mesanovic <mume@linux.vnet.ibm.com> | 2011-03-24 13:54:35 +0000 |
---|---|---|
committer | Alasdair G Kergon <agk@redhat.com> | 2011-03-24 13:54:35 +0000 |
commit | 29915202006c2e7bafe81348eb498ff9a724ac61 (patch) | |
tree | 0fc9b1fb5c58ed148316d7a5718de1b290dcde18 /drivers/md/raid10.c | |
parent | a490a07a67b7a37f588021410e06b721a752fc34 (diff) |
dm stripe: implement merge method
Implement a merge function in the striped target.
When the striped target's underlying devices provide a merge_bvec_fn
(like all DM devices do via dm_merge_bvec) it is important to call down
to them when building a biovec that doesn't span a stripe boundary.
Without the merge method, a striped DM device stacked on DM devices
causes bios with a single page to be submitted which results
in unnecessary overhead that hurts performance.
This change really helps filesystems (e.g. XFS and now ext4) which take
care to assemble larger bios. By implementing stripe_merge(), DM and the
stripe target no longer undermine the filesystem's work by only allowing
a single page per bio. Buffered IO sees the biggest improvement
(particularly uncached reads, buffered writes to a lesser degree). This
is especially so for more capable "enterprise" storage LUNs.
The performance improvement has been measured to be ~12-35% -- when a
reasonable chunk_size is used (e.g. 64K) in conjunction with a stripe
count that is a power of 2.
In contrast, the performance penalty is ~5-7% for the pathological worst
case stripe configuration (small chunk_size with a stripe count that is
not a power of 2). The reason for this is that stripe_map_sector() is
now called once for every call to dm_merge_bvec(). stripe_map_sector()
will use slower division if stripe count isn't a power of 2.
Signed-off-by: Mustafa Mesanovic <mume@linux.vnet.ibm.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Diffstat (limited to 'drivers/md/raid10.c')
0 files changed, 0 insertions, 0 deletions