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)?
Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage [email protected] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
