Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <2c8d249c6bb74d688a625654559bacbb@hyperstone.com>
In-Reply-To: <2c8d249c6bb74d688a625654559bacbb@hyperstone.com>
From:   Ulf Hansson <ulf.hansson@linaro.org>
Date:   Wed, 16 Nov 2022 13:52:06 +0100
Message-ID: <CAPDyKFooANh5Jj1tjG+JriK2vrC4DxK0JGiR5bEtJ1iCMu78QA@mail.gmail.com>
Subject: Re: [PATCHv2 1/3] block: Requeue req as head if driver touched it
To:     =?UTF-8?Q?Christian_L=C3=B6hle?= <CLoehle@hyperstone.com>
Cc:     "axboe@kernel.dk" <axboe@kernel.dk>,
        "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
        Avri Altman <Avri.Altman@wdc.com>,
        "adrian.hunter@intel.com" <adrian.hunter@intel.com>,
        "vincent.whitchurch@axis.com" <vincent.whitchurch@axis.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, 14 Nov 2022 at 16:29, Christian L=C3=B6hle <CLoehle@hyperstone.com>=
 wrote:
>
> In case the driver set RQF_DONTPREP flag, requeue the request as head as
> it is likely that the backing storage already had a request to an
> adjacent region, so getting the requeued request out as soon as possible
> may give us some performance benefit.
>
> The are various reasons a driver may requeue a request
> (and therefore RQF_DONTPREP being set).
> One reason may be that the driver or the hardware cannot satisfy
> the block layer alignment/sizes.
>
> This for example is the case with mmcblk with a host driver that
> cannot deal with multiple block transfers.
> Consider a request for lba 42 for one page so 4K or 8 blocks.
> mmcblk will do a single block request for lba 42 and requeue for
> the rest if the host can only perform single block transfers.
> In this case the device only delivered 512 bytes of data at lba 42,
> but may have performed a readahead itself for the following lbas,
> or do an 'implicit' readahead as it only deals with larger block
> size mappings itself.
> In that case it would be beneificial if the request for lba 43 and
> the rest of the remaining blocks follow immediately after the initial
> lba 42 request.
> Requeueing already partially processed requests as head preserves the
> intended request order (unless the driver has a queue of its own)
> and therefore mitigates this problem .
>
> Signed-off-by: Christian Loehle <cloehle@hyperstone.com>

Thanks for updating the commit message!

Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>

As I said for v1, this seems reasonable to me, but I am deferring to
Jens to get his opinion. Beyond that, I will have a look at pacth2 and
patch3 too.

Kind regards
Uffe

> ---
> -v2: Extended commit message with example use case, no code change
>
>  block/blk-mq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index 33292c01875d..d863c826fb23 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -1429,7 +1429,7 @@ static void blk_mq_requeue_work(struct work_struct =
*work)
>                  * merge.
>                  */
>                 if (rq->rq_flags & RQF_DONTPREP)
> -                       blk_mq_request_bypass_insert(rq, false, false);
> +                       blk_mq_request_bypass_insert(rq, true, false);
>                 else
>                         blk_mq_sched_insert_request(rq, true, false, fals=
e);
>         }
> --
> 2.37.3
> Hyperstone GmbH | Reichenaustr. 39a  | 78467 Konstanz
> Managing Director: Dr. Jan Peter Berns.
> Commercial register of local courts: Freiburg HRB381782
>