[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