[dm-devel] [PATCH 2/3] dm rq: add DM_MAPIO_DELAY_REQUEUE to delay requeue of blk-mq requests
Mike Snitzer
snitzer at redhat.com
Wed Sep 14 13:51:21 UTC 2016
On Wed, Sep 14 2016 at 2:24am -0400,
Hannes Reinecke <hare at suse.de> wrote:
> On 09/13/2016 06:01 PM, Mike Snitzer wrote:
> > Otherwise blk-mq will immediately dispatch requests that are requeued
> > via a BLK_MQ_RQ_QUEUE_BUSY return from blk_mq_ops .queue_rq.
> >
> > Delayed requeue is implemented using blk_mq_delay_kick_requeue_list()
> > with a delay of 5 secs. In the context of DM multipath (all paths down)
> > it doesn't make any sense to requeue more quickly.
> >
> > Signed-off-by: Mike Snitzer <snitzer at redhat.com>
> > ---
> > drivers/md/dm-rq.c | 35 ++++++++++++++++++++---------------
> > include/linux/device-mapper.h | 1 +
> > 2 files changed, 21 insertions(+), 15 deletions(-)
> >
> Hmm. Not sure if I agree with the reasoning for a 5 seconds delay; this
> seems to be a rather broad estimate.
> Won't it delay I/O resumption when we have intermittent path failure (eg
> on iSCSI)?
Are you saying the path would be reinstated via the 'reinstate_path'
message or by table reload? Table reload will kick the requeue list.
'reinstate_path' doesn't (and there isn't an easy way to have dm-mpath
inform dm-rq core to do so -- could add a new function...)
If I can wire up requeue list kick on reinstate_path then the 5 secs is
perfectly fine and won't hurt how quickly IO is resumed once a path
comes back.
More information about the dm-devel
mailing list