[dm-devel] [PATCH] dm-mpath: Improve handling of busy paths

Ming Lei ming.lei at redhat.com
Thu Sep 21 01:41:06 UTC 2017


On Wed, Sep 20, 2017 at 11:26:09PM +0000, Bart Van Assche wrote:
> On Thu, 2017-09-21 at 06:36 +0800, Ming Lei wrote:
> > Actually with GFP_ATOMIC, dispatch in dm-rq can't move on and no request
> > will be dequeued from IO scheduler queue if this allocation fails, that
> > means IO merge is still working at that time if the patchset of
> > 'blk-mq-sched: improve SCSI-MQ performance' is applied.
> > 
> > As my test done, the sequential I/O performance is still not good
> > even though the patchset is applied.
> > 
> > That isn't strange because queue depth of IO scheduler queue can be
> > much bigger than either q->queue_depth or .cmd_per_lun, that means
> > the underlying queue has been busy for a while before the allocation
> > fails.
> 
> Hello Ming,
> 
> This patch is intended as an alternative for your patch series "dm-mpath:
> improve I/O schedule". I wanted to show that it is possible to reduce

Hi Bart,

As I explained, this patch can't fix the I/O merge issue since it is easy
to trigger queue busy before running out of requests, that is why I
changes the 'nr_request' in the patch 5 of 'dm-mpath: improve I/O schedule'.

> dm-mpath request submission latency if the underlying driver returns
> "busy" frequently without touching the "return DM_MAPIO_DELAY_REQUEUE"

I already explained, the DM_MAPIO_DELAY_REQUEUE can be changed
to DM_MAPIO_REQUEUE at least for dm-rq-mq via SCHED_RESTART, even
for dm-rq-sq, it should be possible but need to make sure there
is in-flight requests because we run queue in rq_completed().

-- 
Ming




More information about the dm-devel mailing list