• Mike Snitzer's avatar
    dm: impose configurable deadline for dm_request_fn's merge heuristic · 0ce65797
    Mike Snitzer authored
    Otherwise, for sequential workloads, the dm_request_fn can allow
    excessive request merging at the expense of increased service time.
    
    Add a per-device sysfs attribute to allow the user to control how long a
    request, that is a reasonable merge candidate, can be queued on the
    request queue.  The resolution of this request dispatch deadline is in
    microseconds (ranging from 1 to 100000 usecs), to set a 20us deadline:
      echo 20 > /sys/block/dm-7/dm/rq_based_seq_io_merge_deadline
    
    The dm_request_fn's merge heuristic and associated extra accounting is
    disabled by default (rq_based_seq_io_merge_deadline is 0).
    
    This sysfs attribute is not applicable to bio-based DM devices so it
    will only ever report 0 for them.
    
    By allowing a request to remain on the queue it will block others
    requests on the queue.  But introducing a short dequeue delay has proven
    very effective at enabling certain sequential IO workloads on really
    fast, yet IOPS constrained, devices to build up slightly larger IOs --
    yielding 90+% throughput improvements.  Having precise control over the
    time taken to wait for larger requests to build affords control beyond
    that of waiting for certain IO sizes to accumulate (which would require
    a deadline anyway).  This knob will only ever make sense with sequential
    IO workloads and the particular value used is storage configuration
    specific.
    
    Given the expected niche use-case for when this knob is useful it has
    been deemed acceptable to expose this relatively crude method for
    crafting optimal IO on specific storage -- especially given the solution
    is simple yet effective.  In the context of DM multipath, it is
    advisable to tune this sysfs attribute to a value that offers the best
    performance for the common case (e.g. if 4 paths are expected active,
    tune for that; if paths fail then performance may be slightly reduced).
    
    Alternatives were explored to have request-based DM autotune this value
    (e.g. if/when paths fail) but they were quickly deemed too fragile and
    complex to warrant further design and development time.  If this problem
    proves more common as faster storage emerges we'll have to look at
    elevating a generic solution into the block core.
    Tested-by: default avatarShiva Krishna Merla <shivakrishna.merla@netapp.com>
    Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
    0ce65797
dm.c 77.9 KB