On 01/25/17 01:39, Mike Snitzer wrote: > On Tue, Jan 24 2017 at 9:20am -0500, Christoph Hellwig <hch@xxxxxx> wrote: >> On Tue, Jan 24, 2017 at 05:05:39AM -0500, Mike Snitzer wrote: >>> possible and is welcomed cleanup. The only concern I have is that using >>> get_request() for the old request_fn request_queue eliminates the >>> guaranteed availability of requests to allow for forward progress (on >>> path failure or for the purposes of swap over mpath, etc). This isn't a >>> concern for blk-mq because as you know we have a fixed set of tags (and >>> associated preallocated requests). >>> >>> So I'm left unconvinced old request_fn request-based DM multipath isn't >>> regressing in how request resubmission can be assured a request will be >>> available when needed on retry in the face of path failure. >> >> Mempool only need a size where we can make guaranteed requests, so for >> get_request based drivers under dm the theoretical minimum size would be >> one as we never rely on a second request to finish the first one, >> and each request_queue has it's own mempool(s) to start with. > > Fair enough. Cc'ing Junichi just in case he sees anything we're > missing. DM multipath could not use blk_get_request() because the function was not callable from interrupt-disabled context. E.g. request_fn. However, since the current code no longer calls blk_get_request() from such a context, the change should be ok. -- Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
