Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Niklas Cassel <Niklas.Cassel@wdc.com>
To:     Bart Van Assche <bvanassche@acm.org>
CC:     Jens Axboe <axboe@kernel.dk>,
        Damien Le Moal <Damien.LeMoal@wdc.com>,
        Paolo Valente <paolo.valente@linaro.org>,
        Ming Lei <ming.lei@redhat.com>,
        "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] Revert "mq-deadline: Fix request accounting"
Thread-Topic: [PATCH 2/2] Revert "mq-deadline: Fix request accounting"
Thread-Index: AQHXo/O2L+LBuS/YJECb1WaT3ju4YKuYqIWAgAAUnIA=
Date:   Tue, 7 Sep 2021 16:07:57 +0000
Message-ID: <YTeOW+GoW/Ps2NXq@x1-carbon>
References: <20210907142145.112096-1-Niklas.Cassel@wdc.com>
 <20210907142145.112096-3-Niklas.Cassel@wdc.com>
 <d544384b-617f-b7a4-f895-72adc900f41b@acm.org>
In-Reply-To: <d544384b-617f-b7a4-f895-72adc900f41b@acm.org>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?uCYm7FXc/LP4CUuxmNCWEzXptW8FEjiIBTJ4TP0gbiUIdHnWO+/4YyQ/g+gs?=
 =?us-ascii?Q?Qysa36zQfzcGki4mD7TeMb2lsHj9Vjnd64loxy92xJrzk8TUx1wgPwl11ozY?=
 =?us-ascii?Q?nHZquei5KrJbXXejfN4TynXBqklKtSslba5VulHekfNfeUpjf5giqB1sxUO4?=
 =?us-ascii?Q?hUNe+vBJevmxrThTwz3c/h0VugTufOrhaUjjVJxQrXqbpf68Jjj+BLaA2NTx?=
 =?us-ascii?Q?QMwGBm5PY45rS2NhKOpOZ4ZFSdZqWyMgiB9YbboCoYSlufKeli3/Y8E6Wly5?=
 =?us-ascii?Q?A/4FokQ99KfX/1tfpsIDoEzn/cjCjQq0Dj0PdU1ZjvK2d6XD/DMLSSC/HsvR?=
 =?us-ascii?Q?HsuUAcuhB+YxqraMJth+HDqQrSzqGkmdDxD2tYkzqJlXuRLfa8xcBHrSVDN7?=
 =?us-ascii?Q?6Ogl3TbH40UUKnwNjKnLo9Urt2VIH4efa2U3cn3e6hmGWa5nwCUsJTxQ/U0a?=
 =?us-ascii?Q?QCaLQyN/7eKUsyLQTiCWAxcZPhEsq8yk3iuEz6We0x1SxK1U6E6HIBC71Phf?=
 =?us-ascii?Q?7VP48ViY3UqEtwO+vWwbYoFEtJqXH9bpJ4eshkx3j5GG2ydXOX4YEGD/BRvk?=
 =?us-ascii?Q?9t4DDnbBBy10jlxRw3fveWLh7CfUS2exQhNQMMIToXn9DcqRwwyCzpKHXkop?=
 =?us-ascii?Q?NIcLSwrG11bA5uYheoAj9tHg5PJQKOG/HbDr522wJQl3cONzo7UyQ2Ia0mMT?=
 =?us-ascii?Q?l5bmr/0Otr0E1PiihME1YCchOdD8mCxofwNWwC7iz1QegjvTKsITnpzm8O/L?=
 =?us-ascii?Q?oSvTJ/mHve/6eAPg94TAbC/U0Nq+3KMhGTIqKeXScId9rDBJ0DOUcHmK8sh/?=
 =?us-ascii?Q?8x7EqmevHDsUj6H0niuTQA4/JpLiAikzKnEztsaltNxo4gLxuwZEYkPL4dkR?=
 =?us-ascii?Q?R+8RE4+Aaa4yhe5THyFiJdT7XgRbuzZPjl7UBAiigVUkaP8HLLMPBbH+5CeV?=
 =?us-ascii?Q?rLpca38oPZYYv8tvUyx+3LIwJGmOAZzYrVlC9PYoAk3vxZpah2sMqHcHZ6L8?=
 =?us-ascii?Q?VMdP7CW0sdpOpJMstbrRBAzMinG8OgNdxQfgbBkVS7hR60Jk55uEoGCqAdyu?=
 =?us-ascii?Q?7ktPS6hH4JndKpv9KzWvzhsgs7+psWSvzNpm9J9TwPwWig+EqQMnn6uc1LYX?=
 =?us-ascii?Q?I18Xndp0TTnigCzdsCpg8JFtB1yXJXYGw86FkEEyfs0yyaGxQYHGa3k0X3sH?=
 =?us-ascii?Q?ET6qWrXqkFzonp/ps5xzsaBinXcdEUrpXydA4BS7Gy/gh2xHQUGXZK5U7vys?=
 =?us-ascii?Q?XLFR4v6g6kBWhN324n72CXUEbnEeLdWRLuO+Vg9qFl00P06f0AEtGh/2Cv9D?=
 =?us-ascii?Q?xOln4df6/9ctuaiBB75EI4NXqB2TmiWkkGSyj16BrmxvYA=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <E2F03432B74834479D310D66FD0CF990@namprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: wdc.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR04MB7158.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ff834ed0-96df-427d-8a1b-08d97219a8b2
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2021 16:07:57.7885
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: y+XSYRz4dFf/zDARUK/UEpcNlJ07zzANZqJsWDvOrz9pAeNq6QQuw7P/Rh7KfVmNaRW+tEIHq8COBTam9yuCFw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR04MB7525
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Sep 07, 2021 at 07:54:09AM -0700, Bart Van Assche wrote:
> On 9/7/21 7:21 AM, Niklas Cassel wrote:
> > From: Niklas Cassel <niklas.cassel@wdc.com>
> >=20
> > This reverts commit b6d2b054e8baaee53fd2d4854c63cbf0f2c6262a.
> >=20
> > blk-mq will no longer call the I/O scheduler .finish_request() callback
> > for requests that were never inserted to the I/O scheduler.
> >=20
> > Therefore, we can remove the logic inside mq-deadline that was added to
> > workaround the (no longer existing) quirky behavior of blk-mq.
> >=20
> > Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
> > ---
> >   block/mq-deadline.c | 16 +++++-----------
> >   1 file changed, 5 insertions(+), 11 deletions(-)
> >=20
> > diff --git a/block/mq-deadline.c b/block/mq-deadline.c
> > index 7f3c3932b723..b2d1e3adcb39 100644
> > --- a/block/mq-deadline.c
> > +++ b/block/mq-deadline.c
> > @@ -678,7 +678,6 @@ static void dd_insert_request(struct blk_mq_hw_ctx =
*hctx, struct request *rq,
> >   	prio =3D ioprio_class_to_prio[ioprio_class];
> >   	dd_count(dd, inserted, prio);
> > -	rq->elv.priv[0] =3D (void *)(uintptr_t)1;
> >   	if (blk_mq_sched_try_insert_merge(q, rq, &free)) {
> >   		blk_mq_free_requests(&free);
> > @@ -727,10 +726,12 @@ static void dd_insert_requests(struct blk_mq_hw_c=
tx *hctx,
> >   	spin_unlock(&dd->lock);
> >   }
> > -/* Callback from inside blk_mq_rq_ctx_init(). */
> > +/*
> > + * Nothing to do here. This is defined only to ensure that .finish_req=
uest
> > + * method is called upon request completion.
> > + */
> >   static void dd_prepare_request(struct request *rq)
> >   {
> > -	rq->elv.priv[0] =3D NULL;
> >   }
>=20
> Please take a look at
> https://lore.kernel.org/linux-block/18594aff-4a94-8a48-334c-f21ae32120c6@=
acm.org/
> If dd_prepare_request() is removed I will have to reintroduce it.

dd_prepare_request() itself is not removed, just the
rq->elv.priv[0] =3D NULL; inside dd_prepare_request().

If you need to modify dd_prepare_request() in a future
commit, that should be fine, no?

Without patch 1/2, e->type->ops.requeue_request() can get called
both for requests that bypassed the I/O scheduler, and for requests
that were inserted in the I/O scheduler.

See:
block/blk-mq-sched.h:blk_mq_sched_requeue_request()
If the RQF_ELVPRIV flag is not set, e->type->ops.requeue_request()
will not be called.

Perhaps you are having issues with requests that were inserted
in the scheduler, but later requeued?

If so, shouldn't these fixes help you, since you do not need to
worry about passthrough requests resulting in spurious calls to
the I/O scheduler callbacks?


Kind regards,
Niklas=