From patchwork Sun Sep 27 16:42:36 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jens Axboe X-Patchwork-Id: 50325 Received: from hormel.redhat.com (hormel1.redhat.com [209.132.177.33]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n8RGh145017229 for ; Sun, 27 Sep 2009 16:43:01 GMT Received: from listman.util.phx.redhat.com (listman.util.phx.redhat.com [10.8.4.110]) by hormel.redhat.com (Postfix) with ESMTP id 45A67618FC7; Sun, 27 Sep 2009 12:43:00 -0400 (EDT) Received: from int-mx03.intmail.prod.int.phx2.redhat.com (nat-pool.util.phx.redhat.com [10.8.5.200]) by listman.util.phx.redhat.com (8.13.1/8.13.1) with ESMTP id n8RGgr1f012630 for ; Sun, 27 Sep 2009 12:42:53 -0400 Received: from mx1.redhat.com (ext-mx08.extmail.prod.ext.phx2.redhat.com [10.5.110.12]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n8RGglxS024508; Sun, 27 Sep 2009 12:42:48 -0400 Received: from kernel.dk (brick.kernel.dk [93.163.65.50]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n8RGgbkF016922; Sun, 27 Sep 2009 12:42:37 -0400 Received: by kernel.dk (Postfix, from userid 1000) id 2D43E37A0B4; Sun, 27 Sep 2009 18:42:36 +0200 (CEST) Date: Sun, 27 Sep 2009 18:42:36 +0200 From: Jens Axboe To: Mike Galbraith Message-ID: <20090927164235.GA23126@kernel.dk> References: <1253820332-10246-1-git-send-email-vgoyal@redhat.com> <4ABC28DE.7050809@datenparkplatz.de> <20090925202636.GC15007@redhat.com> <1253976676.7005.40.camel@marge.simson.net> <1254034500.7933.6.camel@marge.simson.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1254034500.7933.6.camel@marge.simson.net> X-RedHat-Spam-Score: -100.64 (AWL,DNS_FROM_RFC_BOGUSMX,USER_IN_WHITELIST) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.16 X-Scanned-By: MIMEDefang 2.67 on 10.5.110.12 X-loop: dm-devel@redhat.com Cc: dhaval@linux.vnet.ibm.com, peterz@infradead.org, dm-devel@redhat.com, dpshah@google.com, agk@redhat.com, balbir@linux.vnet.ibm.com, paolo.valente@unimore.it, jmarchan@redhat.com, fernando@oss.ntt.co.jp, Ulrich Lukas , mikew@google.com, jmoyer@redhat.com, nauman@google.com, mingo@elte.hu, Vivek Goyal , m-ikeda@ds.jp.nec.com, riel@redhat.com, lizf@cn.fujitsu.com, fchecconi@gmail.com, containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, righi.andrea@gmail.com, torvalds@linux-foundation.org Subject: [dm-devel] Re: IO scheduler based IO controller V10 X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.5 Precedence: junk Reply-To: device-mapper development List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com On Sun, Sep 27 2009, Mike Galbraith wrote: > My dd vs load non-cached binary woes seem to be coming from backmerge. > > #if 0 /*MIKEDIDIT sand in gearbox?*/ > /* > * See if our hash lookup can find a potential backmerge. > */ > __rq = elv_rqhash_find(q, bio->bi_sector); > if (__rq && elv_rq_merge_ok(__rq, bio)) { > *req = __rq; > return ELEVATOR_BACK_MERGE; > } > #endif It's a given that not merging will provide better latency. We can't disable that or performance will suffer A LOT on some systems. There are ways to make it better, though. One would be to make the max request size smaller, but that would also hurt for streamed workloads. Can you try whether the below patch makes a difference? It will basically disallow merges to a request that isn't the last one. We should probably make the merging logic a bit more clever, since the below wont work well for two (or more) streamed cases. I'll think a bit about that. Note this is totally untested! diff --git a/block/elevator.c b/block/elevator.c index 1975b61..d00a72b 100644 --- a/block/elevator.c +++ b/block/elevator.c @@ -497,9 +497,17 @@ int elv_merge(struct request_queue *q, struct request **req, struct bio *bio) * See if our hash lookup can find a potential backmerge. */ __rq = elv_rqhash_find(q, bio->bi_sector); - if (__rq && elv_rq_merge_ok(__rq, bio)) { - *req = __rq; - return ELEVATOR_BACK_MERGE; + if (__rq) { + /* + * If requests are queued behind this one, disallow merge. This + * prevents streaming IO from continually passing new IO. + */ + if (elv_latter_request(q, __rq)) + return ELEVATOR_NO_MERGE; + if (elv_rq_merge_ok(__rq, bio)) { + *req = __rq; + return ELEVATOR_BACK_MERGE; + } } if (e->ops->elevator_merge_fn)