From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Snitzer Subject: Re: awful request merge results while simulating high IOPS multipath Date: Wed, 25 Feb 2015 19:11:15 -0500 Message-ID: <20150226001114.GA22484@redhat.com> References: <54ECBA78.6020204@kernel.dk> <20150224181257.GA11444@redhat.com> <54ECC000.40604@kernel.dk> <20150224183256.GA11566@redhat.com> <20150225005608.GA13348@redhat.com> <54EDE62D.7010308@kernel.dk> <20150225221047.GA22281@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: Jens Axboe , dm-devel@redhat.com, shivakrishna.merla@netapp.com, Bart Van Assche , jmoyer@redhat.com List-Id: dm-devel.ids On Wed, Feb 25 2015 at 6:57pm -0500, Keith Busch wrote: > On Wed, 25 Feb 2015, Mike Snitzer wrote: > >On Wed, Feb 25 2015 at 1:17pm -0500, > >Busch, Keith wrote: > >>Our first bottleneck appears to be the device mapper's single lock > >>request queue. > > > >Obviously if we switched dm-multipath over to blk-mq we'd eliminate > >that. I'll see how things go and will share any changes I come up > >with. > > Yes, I'm also looking at blk-mq. It appears conversion helps a lot. Oh, so you've already started a conversion of request-based DM? > I'm not sure though how many tags or h/w contexts to allocate to ensure > there's enough but not too many. You can't use the underlying device's > blk-tagset count (assuming you could even get to it) since those are > potentially shared among many block devices. I'm very new to the blk-mq model so I have some learning to do before I'll be much help. But there really won't be a one size fits all amount for those resources will there? A multipath device can have _a lot_ of underlying paths.