From: Daniel Wagner <dwagner@suse.de> To: linux-nvme@lists.infradead.org Cc: linux-kernel@vger.kernel.org, James Smart <james.smart@broadcom.com>, Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@fb.com>, Ming Lei <ming.lei@redhat.com>, Sagi Grimberg <sagi@grimberg.me>, Daniel Wagner <dwagner@suse.de> Subject: [PATCH v2 0/5] Handle update hardware queues and queue freeze more carefully Date: Thu, 8 Jul 2021 11:27:50 +0200 [thread overview] Message-ID: <20210708092755.15660-1-dwagner@suse.de> (raw) Hi, I've tested this on top of Ming's patches 'blk-mq: fix blk_mq_alloc_request_hctx'[1] which fixes all problems (including the hanger in nvme_wait_freeze()). Thanks, Danie [1] https://lore.kernel.org/linux-nvme/20210629074951.1981284-1-ming.lei@redhat.com/ v1: - https://lore.kernel.org/linux-nvme/20210625101649.49296-1-dwagner@suse.de/ v2: - reviewed tags collected - added 'update hardware queues' for all transport - added fix for fc hanger in nvme_wait_freeze_timeout Initial cover letter: this is a followup on the crash I reported in https://lore.kernel.org/linux-block/20210608183339.70609-1-dwagner@suse.de/ By moving the hardware check up the crash was gone. Unfortuntatly, I don't understand why this fixes the crash. The per-cpu access is crashing but I can't see why the blk_mq_update_nr_hw_queues() is fixing this problem. Even though I can't explain why it fixes it, I think it makes sense to update the hardware queue mapping bevore we recreate the IO queues. Thus I avoided in the commit message to say it fixes something. Also during testing I observed the we hang indivinetly in blk_mq_freeze_queue_wait(). Again I can't explain why we get stuck there but given a common pattern for the nvme_wait_freeze() is to use it with a timeout I think the timeout should be used too :) Anyway, someone with more undertanding of the stack can explain the problems. Daniel Wagner (4): nvme-fc: Update hardware queues before using them nvme-rdma: Update number of hardware queues before using them nvme-fc: Wait with a timeout for queue to freeze nvme-fc: Freeze queues before destroying them Hannes Reinecke (1): nvme-tcp: Update number of hardware queues before using them drivers/nvme/host/fc.c | 26 +++++++++++++++++--------- drivers/nvme/host/rdma.c | 13 ++++++------- drivers/nvme/host/tcp.c | 14 ++++++-------- 3 files changed, 29 insertions(+), 24 deletions(-) -- 2.29.2
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Wagner <dwagner@suse.de> To: linux-nvme@lists.infradead.org Cc: linux-kernel@vger.kernel.org, James Smart <james.smart@broadcom.com>, Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@fb.com>, Ming Lei <ming.lei@redhat.com>, Sagi Grimberg <sagi@grimberg.me>, Daniel Wagner <dwagner@suse.de> Subject: [PATCH v2 0/5] Handle update hardware queues and queue freeze more carefully Date: Thu, 8 Jul 2021 11:27:50 +0200 [thread overview] Message-ID: <20210708092755.15660-1-dwagner@suse.de> (raw) Hi, I've tested this on top of Ming's patches 'blk-mq: fix blk_mq_alloc_request_hctx'[1] which fixes all problems (including the hanger in nvme_wait_freeze()). Thanks, Danie [1] https://lore.kernel.org/linux-nvme/20210629074951.1981284-1-ming.lei@redhat.com/ v1: - https://lore.kernel.org/linux-nvme/20210625101649.49296-1-dwagner@suse.de/ v2: - reviewed tags collected - added 'update hardware queues' for all transport - added fix for fc hanger in nvme_wait_freeze_timeout Initial cover letter: this is a followup on the crash I reported in https://lore.kernel.org/linux-block/20210608183339.70609-1-dwagner@suse.de/ By moving the hardware check up the crash was gone. Unfortuntatly, I don't understand why this fixes the crash. The per-cpu access is crashing but I can't see why the blk_mq_update_nr_hw_queues() is fixing this problem. Even though I can't explain why it fixes it, I think it makes sense to update the hardware queue mapping bevore we recreate the IO queues. Thus I avoided in the commit message to say it fixes something. Also during testing I observed the we hang indivinetly in blk_mq_freeze_queue_wait(). Again I can't explain why we get stuck there but given a common pattern for the nvme_wait_freeze() is to use it with a timeout I think the timeout should be used too :) Anyway, someone with more undertanding of the stack can explain the problems. Daniel Wagner (4): nvme-fc: Update hardware queues before using them nvme-rdma: Update number of hardware queues before using them nvme-fc: Wait with a timeout for queue to freeze nvme-fc: Freeze queues before destroying them Hannes Reinecke (1): nvme-tcp: Update number of hardware queues before using them drivers/nvme/host/fc.c | 26 +++++++++++++++++--------- drivers/nvme/host/rdma.c | 13 ++++++------- drivers/nvme/host/tcp.c | 14 ++++++-------- 3 files changed, 29 insertions(+), 24 deletions(-) -- 2.29.2 _______________________________________________ Linux-nvme mailing list Linux-nvme@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-nvme
next reply other threads:[~2021-07-08 9:28 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-08 9:27 Daniel Wagner [this message] 2021-07-08 9:27 ` [PATCH v2 0/5] Handle update hardware queues and queue freeze more carefully Daniel Wagner 2021-07-08 9:27 ` [PATCH v2 1/5] nvme-fc: Update hardware queues before using them Daniel Wagner 2021-07-08 9:27 ` Daniel Wagner 2021-07-08 10:08 ` Hannes Reinecke 2021-07-08 10:08 ` Hannes Reinecke 2021-07-08 9:27 ` [PATCH v2 2/5] nvme-tcp: Update number of " Daniel Wagner 2021-07-08 9:27 ` Daniel Wagner 2021-07-08 9:27 ` [PATCH v2 3/5] nvme-rdma: " Daniel Wagner 2021-07-08 9:27 ` Daniel Wagner 2021-07-08 9:27 ` [PATCH v2 4/5] nvme-fc: Wait with a timeout for queue to freeze Daniel Wagner 2021-07-08 9:27 ` Daniel Wagner 2021-07-08 10:12 ` Hannes Reinecke 2021-07-08 10:12 ` Hannes Reinecke 2021-07-08 9:27 ` [PATCH v2 5/5] nvme-fc: Freeze queues before destroying them Daniel Wagner 2021-07-08 9:27 ` Daniel Wagner 2021-07-08 10:14 ` Hannes Reinecke 2021-07-08 10:14 ` Hannes Reinecke 2021-07-09 16:14 ` James Smart 2021-07-09 16:14 ` James Smart 2021-07-09 16:42 ` Daniel Wagner 2021-07-09 16:42 ` Daniel Wagner
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=20210708092755.15660-1-dwagner@suse.de \ --to=dwagner@suse.de \ --cc=axboe@fb.com \ --cc=james.smart@broadcom.com \ --cc=kbusch@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-nvme@lists.infradead.org \ --cc=ming.lei@redhat.com \ --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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.