On Wed, Sep 14 2016 at 2:24am -0400, Hannes Reinecke <[email protected]> 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 <[email protected]> > > --- > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
