Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3428849ybb; Mon, 23 Mar 2020 00:29:58 -0700 (PDT) X-Google-Smtp-Source: ADFU+vt1DpjVIf1a14CZSFC5yQm9hcE49k4ABP6pjJ0jeskMaGJ+kDGsvar+UGD0PvkVJ2pd5pbQ X-Received: by 2002:a9d:30c7:: with SMTP id r7mr16529825otg.289.1584948597913; Mon, 23 Mar 2020 00:29:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584948597; cv=none; d=google.com; s=arc-20160816; b=jmxEyllxB7I5eTyr0LqIlVG65eFxHb6okOwps7Sgm2djOqOBebKNKEe4BdYTS6p4Nh 6LloZjcl7EaFrjkMYzLuhrMIDJp81HxBnTp8t9+J6UlewuUicV31MRylqd+Tiwx9W4xx CR4YbcqJ419PFdXqiYtP7c52qpAg0UPw8dOuHYd6izoHGCMMrMNB+MZJ/LK60MmRww2t +KIXMtae2c05kozID9lScujaoqq84R7xozK0Vb8dS7SwNk8rXbi0roxp3WSpah3PhOPV ELJLkdGdcwh2TIqyX9tFmuPDCDbfMNmRnnT8vN1EOq+3LhGlF4KGTMipQiswfjtuukuW KYaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=Ltwtkd73erXYh5KTAgz8fGitRPodOxM8n4dck2JV1fs=; b=OK9FGJX/37qffS1PdUNdFZesfHVZTwRfLyT/6gU0UJxUty9W/icMHkaHdOm6KqNNjJ S74hDMJsXdR1pIygUe7qgd78A8E7TUg8fhVjKZz9dZuHE1yq9/mp5fDv59Ozvc1oJhRw udW7CcYBicGLbdxy1cKbpaVQIBUr0SNT9hOsHGUpOVyu+1knOzbLnVPdLW3HgOq+QFJI lMx6r6aLLrIYl4qZbC/RBc4NMwh3rhLJe2cRlZEawEXoJJk6bMORWczdsnQmb4pVWHm9 JkZQY2GtyJfR+XK36SIQztj7LZfY1fKmXXznH3oaPpL5Grx7SL8VbAIGaCIuDW/nuuHD KDgQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=V3rq1AhK; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t5si1195138otl.193.2020.03.23.00.29.45; Mon, 23 Mar 2020 00:29:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=V3rq1AhK; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727432AbgCWH1i (ORCPT + 99 others); Mon, 23 Mar 2020 03:27:38 -0400 Received: from us-smtp-delivery-74.mimecast.com ([63.128.21.74]:25715 "EHLO us-smtp-delivery-74.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727422AbgCWH1h (ORCPT ); Mon, 23 Mar 2020 03:27:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1584948456; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Ltwtkd73erXYh5KTAgz8fGitRPodOxM8n4dck2JV1fs=; b=V3rq1AhKmSmijrlCFX9s7wirC5aZdbCiD4WFFDsCaBhP9uT8Inyl8bs1XfLGE4jLCYaL+U HtTjw3GYMsOfEFlbKAA/ftKosdPm9L41yVi9sCSbe9jBEhlY81aMpj2PjFiWXpeIXXW32a GQJBbbC+W3rWRF4oJ8Fxb2CNT+A5ONk= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-198-WwCStCK7Ol2aFoK0F6dkwQ-1; Mon, 23 Mar 2020 03:27:32 -0400 X-MC-Unique: WwCStCK7Ol2aFoK0F6dkwQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C0764DB60; Mon, 23 Mar 2020 07:27:30 +0000 (UTC) Received: from ming.t460p (ovpn-8-41.pek2.redhat.com [10.72.8.41]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E61FF60BF1; Mon, 23 Mar 2020 07:26:53 +0000 (UTC) Date: Mon, 23 Mar 2020 15:26:40 +0800 From: Ming Lei To: Baolin Wang Cc: axboe@kernel.dk, Paolo Valente , Ulf Hansson , Adrian Hunter , Arnd Bergmann , Linus Walleij , Orson Zhai , Chunyan Zhang , linux-mmc , linux-block , LKML Subject: Re: [RESEND RFC PATCH 2/8] block: Allow sending a batch of requests from the scheduler to hardware Message-ID: <20200323072640.GA4767@ming.t460p> References: <20200318100123.GA27531@ming.t460p> <20200323034432.GA27507@ming.t460p> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 23, 2020 at 01:36:34PM +0800, Baolin Wang wrote: > On Mon, Mar 23, 2020 at 11:44 AM Ming Lei wrote: > > > > On Fri, Mar 20, 2020 at 06:27:41PM +0800, Baolin Wang wrote: > > > Hi Ming, > > > > > > On Wed, Mar 18, 2020 at 6:26 PM Baolin Wang wrote: > > > > > > > > Hi Ming, > > > > > > > > On Wed, Mar 18, 2020 at 6:01 PM Ming Lei wrote: > > > > > > > > > > On Mon, Mar 16, 2020 at 06:01:19PM +0800, Baolin Wang wrote: > > > > > > As we know, some SD/MMC host controllers can support packed request, > > > > > > that means we can package several requests to host controller at one > > > > > > time to improve performence. So the hardware driver expects the blk-mq > > > > > > can dispatch a batch of requests at one time, and driver can use bd.last > > > > > > to indicate if it is the last request in the batch to help to combine > > > > > > requests as much as possible. > > > > > > > > > > > > Thus we should add batch requests setting from the block driver to tell > > > > > > the scheduler how many requests can be dispatched in a batch, as well > > > > > > as changing the scheduler to dispatch more than one request if setting > > > > > > the maximum batch requests number. > > > > > > > > > > > > > > > > I feel this batch dispatch style is more complicated, and some other > > > > > drivers(virtio blk/scsi) still may get benefit if we can pass real 'last' flag in > > > > > .queue_rq(). > > > > > > > > > > So what about the following way by extending .commit_rqs() to this usage? > > > > > And you can do whatever batch processing in .commit_rqs() which will be > > > > > guaranteed to be called if BLK_MQ_F_FORCE_COMMIT_RQS is set by driver. > > > > > > > > I'm very appreciated for your good suggestion, which is much simpler than mine. > > > > It seems to solve my problem, and I will try it on my platform to see > > > > if it can work and give you the feadback. Thanks again. > > > > > > I tried your approach on my platform, but met some problems, see below. > > > > > > > > > > > > diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c > > > > > index 856356b1619e..cd2bbe56f83f 100644 > > > > > --- a/block/blk-mq-sched.c > > > > > +++ b/block/blk-mq-sched.c > > > > > @@ -85,11 +85,12 @@ void blk_mq_sched_restart(struct blk_mq_hw_ctx *hctx) > > > > > * its queue by itself in its completion handler, so we don't need to > > > > > * restart queue if .get_budget() returns BLK_STS_NO_RESOURCE. > > > > > */ > > > > > -static void blk_mq_do_dispatch_sched(struct blk_mq_hw_ctx *hctx) > > > > > +static bool blk_mq_do_dispatch_sched(struct blk_mq_hw_ctx *hctx) > > > > > { > > > > > struct request_queue *q = hctx->queue; > > > > > struct elevator_queue *e = q->elevator; > > > > > LIST_HEAD(rq_list); > > > > > + bool ret = false; > > > > > > > > > > do { > > > > > struct request *rq; > > > > > @@ -112,7 +113,10 @@ static void blk_mq_do_dispatch_sched(struct blk_mq_hw_ctx *hctx) > > > > > * in blk_mq_dispatch_rq_list(). > > > > > */ > > > > > list_add(&rq->queuelist, &rq_list); > > > > > - } while (blk_mq_dispatch_rq_list(q, &rq_list, true)); > > > > > + ret = blk_mq_dispatch_rq_list(q, &rq_list, true); > > > > > + } while (ret); > > > > > + > > > > > + return ret; > > > > > } > > > > > > > > > > static struct blk_mq_ctx *blk_mq_next_ctx(struct blk_mq_hw_ctx *hctx, > > > > > @@ -131,11 +135,12 @@ static struct blk_mq_ctx *blk_mq_next_ctx(struct blk_mq_hw_ctx *hctx, > > > > > * its queue by itself in its completion handler, so we don't need to > > > > > * restart queue if .get_budget() returns BLK_STS_NO_RESOURCE. > > > > > */ > > > > > -static void blk_mq_do_dispatch_ctx(struct blk_mq_hw_ctx *hctx) > > > > > +static bool blk_mq_do_dispatch_ctx(struct blk_mq_hw_ctx *hctx) > > > > > { > > > > > struct request_queue *q = hctx->queue; > > > > > LIST_HEAD(rq_list); > > > > > struct blk_mq_ctx *ctx = READ_ONCE(hctx->dispatch_from); > > > > > + bool ret = false; > > > > > > > > > > do { > > > > > struct request *rq; > > > > > @@ -161,10 +166,12 @@ static void blk_mq_do_dispatch_ctx(struct blk_mq_hw_ctx *hctx) > > > > > > > > > > /* round robin for fair dispatch */ > > > > > ctx = blk_mq_next_ctx(hctx, rq->mq_ctx); > > > > > - > > > > > - } while (blk_mq_dispatch_rq_list(q, &rq_list, true)); > > > > > + ret = blk_mq_dispatch_rq_list(q, &rq_list, true); > > > > > + } while (ret); > > > > > > > > > > WRITE_ONCE(hctx->dispatch_from, ctx); > > > > > + > > > > > + return ret; > > > > > } > > > > > > > > > > void blk_mq_sched_dispatch_requests(struct blk_mq_hw_ctx *hctx) > > > > > @@ -173,6 +180,7 @@ void blk_mq_sched_dispatch_requests(struct blk_mq_hw_ctx *hctx) > > > > > struct elevator_queue *e = q->elevator; > > > > > const bool has_sched_dispatch = e && e->type->ops.dispatch_request; > > > > > LIST_HEAD(rq_list); > > > > > + bool dispatch_ret; > > > > > > > > > > /* RCU or SRCU read lock is needed before checking quiesced flag */ > > > > > if (unlikely(blk_mq_hctx_stopped(hctx) || blk_queue_quiesced(q))) > > > > > @@ -206,20 +214,26 @@ void blk_mq_sched_dispatch_requests(struct blk_mq_hw_ctx *hctx) > > > > > */ > > > > > if (!list_empty(&rq_list)) { > > > > > blk_mq_sched_mark_restart_hctx(hctx); > > > > > - if (blk_mq_dispatch_rq_list(q, &rq_list, false)) { > > > > > + dispatch_ret = blk_mq_dispatch_rq_list(q, &rq_list, false); > > > > > + if (dispatch_ret) { > > > > > if (has_sched_dispatch) > > > > > - blk_mq_do_dispatch_sched(hctx); > > > > > + dispatch_ret = blk_mq_do_dispatch_sched(hctx); > > > > > > If we dispatched a request successfully by blk_mq_dispatch_rq_list(), > > > and got dispatch_ret = true now. Then we will try to dispatch more > > > reuqests from scheduler by blk_mq_do_dispatch_sched(), but if now no > > > more requests in scheduler, then we will got dispatch_ret = false. In > > > > 'dispatch_ret' always holds result of the last blk_mq_do_dispatch_sched(). > > When any one request has been dispatched successfully, 'dispatch_ret' > > is true. New request is always added to list before calling > > blk_mq_do_dispatch_sched(), so once blk_mq_do_dispatch_sched() returns > > false, it means that .commit_rqs() has been called. > > Not really, if no requests int the IO cheduler, we will break the loop > in blk_mq_do_dispatch_sched() and return false without calling > .commit_rqs(). If there isn't any request to dispatch, false is returned. Otherwise, always return the return value of last 'blk_mq_dispatch_rq_list'. > > So in this case, blk_mq_do_dispatch_sched() will return 'false', which > overlapped the return value of 'true' from blk_mq_dispatch_rq_list(), > and did not call .commit_rqs(). Then the IO processing will be stuck. See below. > > static void blk_mq_do_dispatch_sched(struct blk_mq_hw_ctx *hctx) > { > struct request_queue *q = hctx->queue; > struct elevator_queue *e = q->elevator; > LIST_HEAD(rq_list); > bool ret = false; The above initialization is just done once. > > do { > struct request *rq; > > if (e->type->ops.has_work && !e->type->ops.has_work(hctx)) > break; > > ....... ret = blk_mq_dispatch_rq_list(q, list, ...); list includes one request, so blk_mq_dispatch_rq_list() won't return false in case of no request in list. > } while (ret); > > return ret; 'ret' is always updated by return value of last blk_mq_dispatch_rq_list() if at least one request is dispatched. So if it becomes false, the loop breaks, that means .commit_rqs() has been called cause 'list' does include one request for blk_mq_dispatch_rq_list(). Otherwise, true is still returned. thanks, Ming