On Thu, Sep 25, 2014 at 09:57:41AM -0600, Keith Busch wrote: > Thank you for all the background information. This definitely gives me > a lot more to think about. > > 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? I fully agree with going for the stop gap for now. I tried going the long way when I gave it a try and got stuck. If people believe the get_request in the map path is harmful for the old code we might have to make your change conditional just for blk-mq. For blk-mq request allocation never dips into the general purpose memory pool, so it should be fine for that case. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
