Re: [PATCH 2/3] dm rq: add DM_MAPIO_DELAY_REQUEUE to delay requeue of blk-mq requests

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Sep 14 2016 at  2:24am -0400,
Hannes Reinecke <hare@xxxxxxx> 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@xxxxxxxxxx>
> > ---
> >  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.

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel



[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux