linux-kernel - Re: [PATCHv2 1/3] block: Requeue req as head if driver touched it

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAPDyKFooANh5Jj1tjG+JriK2vrC4DxK0JGiR5bEtJ1iCMu78QA@mail.gmail.com>
Date:   Wed, 16 Nov 2022 13:52:06 +0100
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Christian Löhle <CLoehle@...erstone.com>
Cc:     "axboe@...nel.dk" <axboe@...nel.dk>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        Avri Altman <Avri.Altman@....com>,
        "adrian.hunter@...el.com" <adrian.hunter@...el.com>,
        "vincent.whitchurch@...s.com" <vincent.whitchurch@...s.com>
Subject: Re: [PATCHv2 1/3] block: Requeue req as head if driver touched it

On Mon, 14 Nov 2022 at 16:29, Christian Löhle <CLoehle@...erstone.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@...erstone.com>

Thanks for updating the commit message!

Reviewed-by: Ulf Hansson <ulf.hansson@...aro.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, false);
>         }
> --
> 2.37.3
> Hyperstone GmbH | Reichenaustr. 39a  | 78467 Konstanz
> Managing Director: Dr. Jan Peter Berns.
> Commercial register of local courts: Freiburg HRB381782
>