1. 18 Jul, 2016 4 commits
  2. 06 Jul, 2016 1 commit
  3. 02 Jul, 2016 1 commit
  4. 01 Jul, 2016 2 commits
  5. 16 Jun, 2016 1 commit
  6. 14 Jun, 2016 20 commits
  7. 13 Jun, 2016 6 commits
  8. 10 Jun, 2016 5 commits
    • Mike Snitzer's avatar
      dm mpath: add optional "queue_mode" feature · e83068a5
      Mike Snitzer authored
      Allow a user to specify an optional feature 'queue_mode <mode>' where
      <mode> may be "bio", "rq" or "mq" -- which corresponds to bio-based,
      request_fn rq-based, and blk-mq rq-based respectively.
      
      If the queue_mode feature isn't specified the default for the
      "multipath" target is still "rq" but if dm_mod.use_blk_mq is set to Y
      it'll default to mode "mq".
      
      This new queue_mode feature introduces the ability for each multipath
      device to have its own queue_mode (whereas before this feature all
      multipath devices effectively had to have the same queue_mode).
      
      This commit also goes a long way to eliminate the awkward (ab)use of
      DM_TYPE_*, the associated filter_md_type() and other relatively fragile
      and difficult to maintain code.
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      e83068a5
    • Mike Snitzer's avatar
    • Mike Snitzer's avatar
      dm mpath: reinstate bio-based support · 76e33fe4
      Mike Snitzer authored
      Add "multipath-bio" target that offers a bio-based multipath target as
      an alternative to the request-based "multipath" target -- but in a
      following commit "multipath-bio" will immediately be replaced by a new
      "queue_mode" feature for the "multipath" target which will allow
      bio-based mode to be selected.
      
      When DM multipath was originally converted from bio-based to
      request-based the motivation for the change was better dynamic load
      balancing (by leveraging block core's request-based IO schedulers, for
      merging and sorting, _before_ DM multipath would make the decision on
      where to steer the IO -- based on path load and/or availability).
      
      More background is available in this "Request-based Device-mapper
      multipath and Dynamic load balancing" paper:
      https://www.kernel.org/doc/ols/2007/ols2007v2-pages-235-244.pdf
      
      But we've now come full circle where significantly faster storage
      devices no longer need IOs to be made larger to drive optimal IO
      performance.  And even if they do there have been changes to the block
      and filesystem layers that help ensure upper layers are constructing
      larger IOs.  In addition, SCSI's differentiated IO errors will propagate
      through to bio-based IO completion hooks -- so that eliminates another
      historic justiciation for request-based DM multipath.  Lastly, the block
      layer's immutable biovec changes have made bio cloning cheaper than it
      has ever been; whereas request cloning is still relatively expensive
      (both on a CPU usage and memory footprint level).
      
      As such, bio-based DM multipath offers the promise of a more efficient
      IO path for high IOPs devices that are, or will be, emerging.
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      76e33fe4
    • Mike Snitzer's avatar
      dm: move request-based code out to dm-rq.[hc] · 4cc96131
      Mike Snitzer authored
      Add some seperation between bio-based and request-based DM core code.
      
      'struct mapped_device' and other DM core only structures and functions
      have been moved to dm-core.h and all relevant DM core .c files have been
      updated to include dm-core.h rather than dm.h
      
      DM targets should _never_ include dm-core.h!
      
      [block core merge conflict resolution from Stephen Rothwell]
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      4cc96131
    • Ming Lei's avatar
      block: bio: kill BIO_MAX_SIZE · 1a89694f
      Ming Lei authored
      No one need this macro now, so remove it. Basically
      only how many bvecs in one bio matters instead
      of how many bytes in this bio.
      
      The motivation is for supporting multipage bvecs, in
      which we only know what the max count of bvecs is supported
      in the bio.
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarMing Lei <ming.lei@canonical.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      1a89694f