From: Max Gurtovoy <mgurtovoy@nvidia.com>
To: Keith Busch <kbusch@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>, <linux-nvme@lists.infradead.org>,
<linux-block@vger.kernel.org>, <axboe@kernel.dk>,
<sagi@grimberg.me>
Subject: Re: [PATCHv2 1/3] block: introduce rq_list_for_each_safe macro
Date: Tue, 4 Jan 2022 14:15:58 +0200 [thread overview]
Message-ID: <ac74ac4c-15f3-997e-ecd2-5e704a5b4573@nvidia.com> (raw)
In-Reply-To: <20220103181552.GA2498980@dhcp-10-100-145-180.wdc.com>
On 1/3/2022 8:15 PM, Keith Busch wrote:
> On Mon, Jan 03, 2022 at 05:23:08PM +0200, Max Gurtovoy wrote:
>> On 12/30/2021 5:30 PM, Keith Busch wrote:
>>> I think it just may work if we export blk_mq_get_driver_tag().
>> do you have a suggestion for the NVMe/PCI driver ?
> The following tests fine with my multi-namespace setups. I have real
> hardware with namespace management capabilities, but qemu can also
> easily emulate it too for anyone who doesn't have one.
>
> ---
> diff --git a/block/blk-mq-tag.h b/block/blk-mq-tag.h
> index 5668e28be0b7..84f2e73d0c7c 100644
> --- a/block/blk-mq-tag.h
> +++ b/block/blk-mq-tag.h
> @@ -41,12 +41,6 @@ static inline struct sbq_wait_state *bt_wait_ptr(struct sbitmap_queue *bt,
> return sbq_wait_ptr(bt, &hctx->wait_index);
> }
>
> -enum {
> - BLK_MQ_NO_TAG = -1U,
> - BLK_MQ_TAG_MIN = 1,
> - BLK_MQ_TAG_MAX = BLK_MQ_NO_TAG - 1,
> -};
> -
> extern bool __blk_mq_tag_busy(struct blk_mq_hw_ctx *);
> extern void __blk_mq_tag_idle(struct blk_mq_hw_ctx *);
>
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index 0d7c9d3e0329..b4540723077a 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -1589,6 +1589,7 @@ bool __blk_mq_get_driver_tag(struct blk_mq_hw_ctx *hctx, struct request *rq)
> hctx->tags->rqs[rq->tag] = rq;
> return true;
> }
> +EXPORT_SYMBOL_GPL(__blk_mq_get_driver_tag);
>
> static int blk_mq_dispatch_wake(wait_queue_entry_t *wait, unsigned mode,
> int flags, void *key)
> @@ -2582,11 +2583,10 @@ void blk_mq_flush_plug_list(struct blk_plug *plug, bool from_schedule)
> * same queue, caller must ensure that's the case.
> *
> * Since we pass off the full list to the driver at this point,
> - * we do not increment the active request count for the queue.
> - * Bypass shared tags for now because of that.
> + * we are counting on the driver to increment the active
> + * request count for the queue.
> */
> - if (q->mq_ops->queue_rqs &&
> - !(rq->mq_hctx->flags & BLK_MQ_F_TAG_QUEUE_SHARED)) {
> + if (q->mq_ops->queue_rqs) {
> blk_mq_run_dispatch_ops(q,
> __blk_mq_flush_plug_list(q, plug));
> if (rq_list_empty(plug->mq_list))
> diff --git a/block/blk-mq.h b/block/blk-mq.h
> index 948791ea2a3e..0f37ae906901 100644
> --- a/block/blk-mq.h
> +++ b/block/blk-mq.h
> @@ -268,21 +268,6 @@ static inline void blk_mq_put_driver_tag(struct request *rq)
> __blk_mq_put_driver_tag(rq->mq_hctx, rq);
> }
>
> -bool __blk_mq_get_driver_tag(struct blk_mq_hw_ctx *hctx, struct request *rq);
> -
> -static inline bool blk_mq_get_driver_tag(struct request *rq)
> -{
> - struct blk_mq_hw_ctx *hctx = rq->mq_hctx;
> -
> - if (rq->tag != BLK_MQ_NO_TAG &&
> - !(hctx->flags & BLK_MQ_F_TAG_QUEUE_SHARED)) {
> - hctx->tags->rqs[rq->tag] = rq;
> - return true;
> - }
> -
> - return __blk_mq_get_driver_tag(hctx, rq);
> -}
> -
> static inline void blk_mq_clear_mq_map(struct blk_mq_queue_map *qmap)
> {
> int cpu;
> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> index 50deb8b69c40..f50483475c12 100644
> --- a/drivers/nvme/host/pci.c
> +++ b/drivers/nvme/host/pci.c
> @@ -992,8 +992,9 @@ static bool nvme_prep_rq_batch(struct nvme_queue *nvmeq, struct request *req)
> return false;
> if (unlikely(!nvme_check_ready(&nvmeq->dev->ctrl, req, true)))
> return false;
> + if (!blk_mq_get_driver_tag(req))
> + return false;
>
> - req->mq_hctx->tags->rqs[req->tag] = req;
> return nvme_prep_rq(nvmeq->dev, req) == BLK_STS_OK;
> }
>
> diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
> index 550996cf419c..8fb544a35330 100644
> --- a/include/linux/blk-mq.h
> +++ b/include/linux/blk-mq.h
> @@ -1072,6 +1072,27 @@ static inline int blk_rq_map_sg(struct request_queue *q, struct request *rq,
> }
> void blk_dump_rq_flags(struct request *, char *);
>
> +enum {
> + BLK_MQ_NO_TAG = -1U,
> + BLK_MQ_TAG_MIN = 1,
> + BLK_MQ_TAG_MAX = BLK_MQ_NO_TAG - 1,
> +};
> +
> +bool __blk_mq_get_driver_tag(struct blk_mq_hw_ctx *hctx, struct request *rq);
> +
> +static inline bool blk_mq_get_driver_tag(struct request *rq)
> +{
> + struct blk_mq_hw_ctx *hctx = rq->mq_hctx;
> +
> + if (rq->tag != BLK_MQ_NO_TAG &&
> + !(hctx->flags & BLK_MQ_F_TAG_QUEUE_SHARED)) {
> + hctx->tags->rqs[rq->tag] = rq;
> + return true;
> + }
> +
> + return __blk_mq_get_driver_tag(hctx, rq);
> +}
> +
> #ifdef CONFIG_BLK_DEV_ZONED
> static inline unsigned int blk_rq_zone_no(struct request *rq)
> {
> --
This patch worked for me with 2 namespaces for NVMe PCI.
I'll check it later on with my RDMA queue_rqs patches as well. There we
have also a tagset sharing with the connect_q (and not only with
multiple namespaces).
But the connect_q is using a reserved tags only (for the connect commands).
I saw some strange things that I couldn't understand:
1. running randread fio with libaio ioengine didn't call nvme_queue_rqs
- expected
*2. running randwrite fio with libaio ioengine did call nvme_queue_rqs -
Not expected !!*
*3. running randread fio with io_uring ioengine (and --iodepth_batch=32)
didn't call nvme_queue_rqs - Not expected !!*
4. running randwrite fio with io_uring ioengine (and --iodepth_batch=32)
did call nvme_queue_rqs - expected
5. *running randread fio with io_uring ioengine (and --iodepth_batch=32
--runtime=30) didn't finish after 30 seconds and stuck for 300 seconds
(fio jobs required "kill -9 fio" to remove refcounts from nvme_core) -
Not expected !!*
*debug pring: fio: job 'task_nvme0n1' (state=5) hasn't exited in 300
seconds, it appears to be stuck. Doing forceful exit of this job.
*
*6. ***running randwrite fio with io_uring ioengine (and
--iodepth_batch=32 --runtime=30) didn't finish after 30 seconds and
stuck for 300 seconds (fio jobs required "kill -9 fio" to remove
refcounts from nvme_core) - Not expected !!**
***debug pring: fio: job 'task_nvme0n1' (state=5) hasn't exited in 300
seconds, it appears to be stuck. Doing forceful exit of this job.***
any idea what could cause these unexpected scenarios ? at least
unexpected for me :)
******
next prev parent reply other threads:[~2022-01-04 12:32 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-27 16:41 [PATCHv2 1/3] block: introduce rq_list_for_each_safe macro Keith Busch
2021-12-27 16:41 ` [PATCHv2 2/3] block: introduce rq_list_move Keith Busch
2021-12-27 18:49 ` kernel test robot
2021-12-29 17:41 ` Christoph Hellwig
2021-12-29 20:59 ` Keith Busch
2021-12-27 16:41 ` [PATCHv2 3/3] nvme-pci: fix queue_rqs list splitting Keith Busch
2021-12-29 17:46 ` Christoph Hellwig
2021-12-29 21:04 ` Keith Busch
2021-12-30 7:53 ` Christoph Hellwig
2022-01-04 19:38 ` Keith Busch
2022-01-05 7:35 ` Christoph Hellwig
2021-12-29 17:39 ` [PATCHv2 1/3] block: introduce rq_list_for_each_safe macro Christoph Hellwig
2021-12-29 20:57 ` Keith Busch
2021-12-30 14:38 ` Max Gurtovoy
2021-12-30 15:30 ` Keith Busch
2022-01-03 15:23 ` Max Gurtovoy
2022-01-03 18:15 ` Keith Busch
2022-01-04 12:15 ` Max Gurtovoy [this message]
2022-01-05 17:26 ` Keith Busch
2022-01-06 11:54 ` Max Gurtovoy
2022-01-06 13:41 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ac74ac4c-15f3-997e-ecd2-5e704a5b4573@nvidia.com \
--to=mgurtovoy@nvidia.com \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox