From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:56354 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933341AbeAKWmw (ORCPT ); Thu, 11 Jan 2018 17:42:52 -0500 Date: Thu, 11 Jan 2018 17:42:49 -0500 From: Mike Snitzer To: Ming Lei Cc: Jens Axboe , linux-block@vger.kernel.org, Christoph Hellwig , dm-devel@redhat.com, Bart Van Assche Subject: Re: [PATCH V3 5/5] blk-mq: issue request directly for blk_insert_cloned_request Message-ID: <20180111224249.GD31944@redhat.com> References: <20180111060159.12991-1-ming.lei@redhat.com> <20180111060159.12991-6-ming.lei@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20180111060159.12991-6-ming.lei@redhat.com> Sender: linux-block-owner@vger.kernel.org List-Id: linux-block@vger.kernel.org On Thu, Jan 11 2018 at 1:01am -0500, Ming Lei wrote: > blk_insert_cloned_request() is called in fast path of dm-rq driver, and > in this function we append request to hctx->dispatch_list of the underlying > queue directly. > > 1) This way isn't efficient enough because hctx lock is always required > > 2) With blk_insert_cloned_request(), we bypass underlying queue's IO scheduler > totally, and depend on DM rq driver to do IO schedule completely. But DM > rq driver can't get underlying queue's dispatch feedback at all, and this > information is extreamly useful for IO merge. Without that IO merge can't > be done basically by blk-mq, and causes very bad sequential IO performance. > > This patch makes use of blk_mq_try_issue_directly() to dispatch rq to > underlying queue and provides disptch result to dm-rq and blk-mq, and > improves the above situations very much. > > With this patch, seqential IO is improved by 3X in my test over > mpath/virtio-scsi. > > Signed-off-by: Ming Lei Tested-by: Mike Snitzer Reviewed-by: Mike Snitzer