On 09/26/14 01:12, Mike Snitzer wrote: > On Thu, Sep 25 2014 at 11:57am -0400, > Keith Busch <keith.busch@xxxxxxxxx> wrote: >> For my part, the goal was to change as little as possible to get basic >> blk-mq support working safely without regressing, and performance is >> not even on my radar yet. I purposefully did not try to understand the >> existing design well enough to propose re-arching. If we can address the >> 'request' life cycle management duality issue, would this be acceptable >> as a stopgap for blk-mq support? > > We can ignore my desire to cleanup existing request-based DM's bio > cloning for now. And yes, resolving the duality issue would need to > happen. But your proposed change still has the issue of no longer using > a dedicated mempool per rq-based DM device to allocate requests from. > If we were to do that I'm pretty sure this new dm.c:dm_get_request() > wrapper would need to call blk_get_request() with GFP_ATOMIC. > > Either GFP_ATOMIC or I think we _could_ relax to GFP_NOWAIT if and only > if we were willing to explicitly disallow stacking request-based DM > devices (which nothing uses at this point). So I'd like to get Junichi > and Alasdair's feedback on the implications. Junichi and/or Alasdair? The problem with "stacking request-based DM devices" is caused by shared mempool (i.e. the pool gets emptied by upper layer and we can't make forward progress). So it should be ok if request has per-device mempool (I think it does.) However, using blk_get_request() in map function will require more changes in the code as blk_get_request() assumes interrupt-enabled context. -- Jun'ichi Nomura, NEC Corporation -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
