On Thu, Jan 20 2011 at 2:32am -0500, Hannes Reinecke <hare@xxxxxxx> wrote: > On 01/19/2011 10:30 PM, Malahal Naineni wrote: > > The value of 1000 is good for bio based multipath. Seen 50% increase in > > I/O ops by setting it to 1 in request based multipath configuration. > > This patch would give poor performance for people still using the bio > > based multipath! > > > > Is it possible to detect request based multipath and change only for > > those configurations? > > > > diff -r e504a50b0db5 -r 91d6dae7d882 libmultipath/defaults.h > > --- a/libmultipath/defaults.h Wed Jan 19 13:16:40 2011 -0800 > > +++ b/libmultipath/defaults.h Wed Jan 19 13:29:52 2011 -0800 > > @@ -5,7 +5,7 @@ > > #define DEFAULT_ALIAS_PREFIX "mpath" > > #define DEFAULT_FEATURES "0" > > #define DEFAULT_HWHANDLER "0" > > -#define DEFAULT_MINIO 1000 > > +#define DEFAULT_MINIO 1 > > #define DEFAULT_PGPOLICY FAILOVER > > #define DEFAULT_FAILBACK -FAILBACK_MANUAL > > #define DEFAULT_RR_WEIGHT RR_WEIGHT_NONE > > > Heh, that was the main reason for using request-based multipathing :-) Exactly, since I/O merging occurs before entering request-based multipath, frequent round-robin path switching doesn't cause the number of overall requests to increase (like it did for bio-based). Given the data from the 2007 Linux Symposim request-based DM paper (see [1], figure 7), a safer rr_min_io default for both bio-based and request-based might be 50 or 100. But regardless of the default, no one size fits all. Depending on the FC storage backend, a rr_min_io of 1 may not _always_ be ideal for request-based DM. But clearly additional testing would be needed. > So yes, changing the behaviour is a good idea. But we should equally > be able to detect if request-based multipathing is present; maybe > we can key off the version number of dm-multipath? Unfortunately, the multipath target version wasn't bumped when request-based mpath was introduced (commit f40c67f0f7e2767f). Similarly, the DM ioctl version wasn't bumped when the DM core was updated to support request-based (primarily via commits e6ee8c0b767540 and cec47e3d4a861e). Fortunately, the DM ioctl version was bumped in a release (therefore a dedicated version bump related to request-based DM changes was deemed unnecessary). $ git log --tags --source --oneline include/linux/dm-ioctl.h ... 60935eb v2.6.31-rc1 dm ioctl: support cookies for udev $ git log --tags --source --oneline drivers/md/dm.c ... a77e28c v2.6.31-rc9 dm multipath: fix oops when request based io fails when no paths a732c20 v2.6.31-rc5 dm: remove queue next_ordered workaround for barriers 7878cba v2.6.31-rc2 block: Create bip slabs with embedded integrity vectors 523d929 v2.6.31-rc1 dm: disable interrupt when taking map_lock 5d67aa2 v2.6.31-rc1 dm: do not set QUEUE_ORDERED_DRAIN if request based e6ee8c0 v2.6.31-rc1 dm: enable request based option cec47e3 v2.6.31-rc1 dm: prepare for request based option Long story short, it seems we _could_ use the DM ioctl version bump that occurred for 2.6.31 (from commit 60935eb): 4.15.0-ioctl (2009-04-01) Mike [1] http://www.linuxsymposium.org/archives/OLS/Reprints-2007/ueda-Reprint.pdf -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
