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:     Ming Lei <ming.lei@redhat.com>
CC:     Jens Axboe <axboe@kernel.dk>, Bart Van Assche <bvanassche@acm.org>,
        Damien Le Moal <Damien.LeMoal@wdc.com>,
        Paolo Valente <paolo.valente@linaro.org>,
        "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 1/2] blk-mq: don't call callbacks for requests that
 bypassed the scheduler
Thread-Topic: [RFC PATCH 1/2] blk-mq: don't call callbacks for requests that
 bypassed the scheduler
Thread-Index: AQHXm0DcNbCoMv+LuUuRBM4IFE0DyKuHWDyAgAR5gwA=
Date:   Mon, 30 Aug 2021 09:48:06 +0000
Message-ID: <YSypVLe8vxmA+pUn@x1-carbon>
References: <20210827124100.98112-1-Niklas.Cassel@wdc.com>
 <20210827124100.98112-2-Niklas.Cassel@wdc.com> <YSjoZ/cul4w2l8tG@T590>
In-Reply-To: <YSjoZ/cul4w2l8tG@T590>
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?AcsS8hLUbCyf1SJUHGnX1piRkEmXIXplBj8HktpSbLz64domCYgrl6JtVMhz?=
 =?us-ascii?Q?Fuaqxh3TNEyfU0UH9krP3YfY+a5yRe579e1JoWdXV+PbiDCcCqYPd2sPUkTj?=
 =?us-ascii?Q?jVBpnPe7d858/3h/l85BKnCUnwyniqU3Wc+U3du+6ftN8K5jV0XfQpjeySAw?=
 =?us-ascii?Q?ZXlpZkzkwDvH50900nrco5xIeDL5m7P9kMrd3/7MbaWSk9M1AO8JYQYqXRcm?=
 =?us-ascii?Q?GISh/+p0LiPglCYObrWQyXhp11Mob8guZUetVXrgFqMfpR+6OYOzY6JR8bkv?=
 =?us-ascii?Q?OxeJZzVduRUnYriYH6Uc42GqoWxFPWrwyH1/Mi2jshvXS5tY6Iu44EmRJYHM?=
 =?us-ascii?Q?M9qJbCwlGEAh6GqzgZpWScZc5f5Prsp8yQVvEoz+0ZmhS1so7xdX+WzLYOeT?=
 =?us-ascii?Q?3QLPOukUOkDc+0+yFL5w1Kyhyl5vSL/FEkVxFepARzB7qVBHaCjyJwdRXWlJ?=
 =?us-ascii?Q?y7OCfkYR5qe6XEn0+s/XuclhQf37U2OmgP2Bw7iwBp2M6zj7mwboTLvy3Ftw?=
 =?us-ascii?Q?7amvoZRwKhZuWhD7ZnSD1OAPEttS0Mjg/BtUNRLdQ0GQcDqzjHZMQ47GfexP?=
 =?us-ascii?Q?OoFI3Pq9S9jgFBP73lgzkVS/Bki9pPFOjmLlctEruK7FJfipCt1ITLOyopVX?=
 =?us-ascii?Q?+PUpmsZ45g+msq/ZsYvP8Fud3Bfkd5WNx+X6zOgv6ujf35XXflKBgejVjG3v?=
 =?us-ascii?Q?5lh0UmEDH8h3BBs5fwxv5sJ9dl9BzEitiQMGtQYflYLkU080JZyv4yDEYU4l?=
 =?us-ascii?Q?1uRQPZ+QFmTmZ6t2BObpRTAtUz1HXAyuAyTKQjuqsDr7dOBaFeMcFkDMy/R2?=
 =?us-ascii?Q?74K8APY/s2ywU1Vu0lAa2oIbzuA0KB3fAbfASFIvlgW5a1Le8f9E6VzIr+Am?=
 =?us-ascii?Q?H/7wBNdELh57pYmyaF5TgEHthFRJxqbZr2PqAtpi/MfFYzgVHmHmrwIXhWUy?=
 =?us-ascii?Q?/zm24fx4nuyeRLH0TSd9JMsseZ64xNqcjZYJFk7Q4o8SKYPKYZwE62pO2pEc?=
 =?us-ascii?Q?pxV6GYjYkVfrlicGojZ8Okton9OAEdQTg9bv0q9RWgEdDYhUAMUAqENOURnY?=
 =?us-ascii?Q?6bbDiFtn5AT/3agV1wJBRbKWVqIM5i+/ijUzUyO0vonV6B5SThFR4ienbzjD?=
 =?us-ascii?Q?6qFYuK3vIk/o1YkXPcDEC9Cx9VgAfJxVQBl/Je9MsSJqZBVpYCONwDQTC88V?=
 =?us-ascii?Q?z9pdct7mwwitGzslLzL9nOgqsqoNKeMnAgNQiQaFXEiwRY1acHDMGg9xt+Wo?=
 =?us-ascii?Q?6ZwaRs9nc50tA9Zjr1NHVRwnkwYNVHBp2BWiuqfZdykHYLCeBuszqZPNLtXB?=
 =?us-ascii?Q?JXv4l0czrsdHONPJBxvVHIQaxkqfnr+snYjnPIiOrw3XMQ=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B181402553EE2B42BA03F7E60E7F5168@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: 01d93346-b962-457b-a704-08d96b9b4485
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2021 09:48:06.1476
 (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: TVRkSV8FgnbFE3sJvufGyWVX2yzCUsYB1zEn862FBfqg51mRtH+DHQyVz4+qbmxN2sQPJOc0YaTFF5Op29fS8w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR04MB7623
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Aug 27, 2021 at 09:28:07PM +0800, Ming Lei wrote:
> On Fri, Aug 27, 2021 at 12:41:31PM +0000, Niklas Cassel wrote:
> > From: Niklas Cassel <niklas.cassel@wdc.com>
> >=20
> > Currently, __blk_mq_alloc_request() calls ops.prepare_request and sets
> > RQF_ELVPRIV.
> >=20
> > Therefore, (if the request is not a flush) the RQF_ELVPRIV flag will be
> > set for the request in blk_mq_submit_bio(), regardless if the request
> > was submitted to a scheduler, or bypassed the scheduler.
> >=20
> > Later, blk_mq_free_request() checks if the RQF_ELVPRIV flag is set,
> > if it is, the ops.finish_request callback will be called.
> >=20
> > The problem with this is that the finish_request scheduler callback
> > will be called for requests that bypassed the scheduler.
> >=20
> > Fix this by calling the scheduler ops.prepare_request callback, and
> > set the RQF_ELVPRIV flag only immediately before calling the insert
> > callback.
>=20
> One request could be inserted more than one times, such as requeue,
> however __blk_mq_alloc_request() is just run once, so is it fine to
> call ->prepare_request more than one time for same request?

Calling ->prepare_request multiple times is fine.
All the different I/O schedulers (BFQ, mq-deadline, kyber)
simply use .prepare_request to clear/set elv->priv to a fixed value.

>=20
> Or I am wondering why not call ->prepare_request when the following
> check is true?
>=20
> 	if (e && e->type->ops.prepare_request && !op_is_flush(data->cmd_flags) &=
&
> 		!blk_op_is_passthrough(data->cmd_flags))
> 		e->type->ops.prepare_request()


That might work, and might be a nicer solution indeed.

If a request got plugged, it will be inserted to the scheduler through
blk_flush_plug_list() -> blk_mq_flush_plug_list() -> blk_mq_sched_insert_re=
quests()
which will insert them unconditionally.
In this case. we know that !op_is_flush() (because if it was, blk_mq_submit=
_bio()
would have inserted directly.)


If we didn't plug, we do blk_mq_sched_insert_request(), which will add it i=
f
blk_mq_sched_bypass_insert() returns false:

blk_mq_sched_bypass_insert() is defined as:

        if ((rq->rq_flags & RQF_FLUSH_SEQ) || blk_rq_is_passthrough(rq))
                return true;
Also in this case. we know that !op_is_flush() (blk_mq_submit_bio() would h=
ave
inserted directly.)


So, we could easily add && !blk_op_is_passthrough(data->cmd_flags) to the
->prepare_request condition in blk_mq_rq_ctx_init() like you suggested,
but since the bypass condition also seems to look at RQF_FLUSH_SEQ, wouldn'=
t
we need to add RQF_FLUSH_SEQ to the condition in blk_mq_rq_ctx_init() as we=
ll?

This flag is set after blk_mq_rq_ctx_init(). Are we sure that RQF_FLUSH_SEQ
flag will only be set for a request which op_is_flush() returned true?

(If so, then only adding  && !blk_op_is_passthrough(data->cmd_flags) should
be fine.)


Kind regards,
Niklas=