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. > dm_mod's 'reserved_rq_based_ios' module_param governs the minimum number > of requests in the md->rq_pool (and defaults to 256 requests per > request-based DM request_queue). Whereas blk_init_rl()'s > mempool_create_node() uses BLKDEV_MIN_RQ (4) yet q->nr_requests = > BLKDEV_MAX_RQ (128). Also, this patch eliminates the utility of > 'reserved_rq_based_ios' module_param without actually removing it. It's still used for the bio pool, so I couldn't simply remove it. > Anyway, should blk-core evolve to allow drivers to specify a custom > min_nr of requests in the old request_fn request_queue's mempool? Or is > my concern overblown? Thanks to mempool_resize we could add that functionality. I just don't see an actual need for it. > p.s. dm.c:dm_alloc_md_mempools() could be cleaned up a bit more since > only bio-based DM will have a pools->io_pool moving forward; but I can > circle back to that cleanup after. If you're fine with doing more than the necessary changes in a patch that needs to got into the block tree I'd be happy to apply my usual cleanup magic to it. -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
