From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: dm-mpath: Work with blk multi-queue drivers Date: Thu, 25 Sep 2014 09:08:23 -0700 Message-ID: <20140925160823.GA3452@infradead.org> References: <1411491802-7356-1-git-send-email-keith.busch@intel.com> <20140924145215.GA26398@infradead.org> <20140924183453.GA23052@redhat.com> <20140924184834.GB23052@redhat.com> <20140925001341.GA25145@redhat.com> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Keith Busch Cc: Christoph Hellwig , Jun'ichi Nomura , dm-devel@redhat.com, Mike Snitzer List-Id: dm-devel.ids 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.