From: Nilay Shroff <nilay@linux.ibm.com>
To: Daniel Wagner <dwagner@suse.de>, Keith Busch <kbusch@kernel.org>,
Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
Sagi Grimberg <sagi@grimberg.me>
Cc: Ming Lei <ming.lei@redhat.com>,
Surabhi Gogte <sgogte@purestorage.com>,
Hannes Reinecke <hare@kernel.org>,
Frederic Weisbecker <frederic@kernel.org>,
Aaron Tomlin <atomlin@atomlin.com>,
Maurizio Lombardi <mlombard@redhat.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
linux-block@vger.kernel.org, linux-nvme@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] blk-mq: use a housekeeping CPU for passthrough requests on isolated hctxs
Date: Tue, 3 Nov 2026 22:34:44 +0530 [thread overview]
Message-ID: <7f6e7fc6-dd40-4949-9a1b-95200c9680e6@linux.ibm.com> (raw)
In-Reply-To: <20261103-nvme-fabrics-isolcpu-v2-1-95ec70d58254@suse.de>
On 11/3/26 8:27 PM, Daniel Wagner wrote:
> blk_mq_alloc_request_hctx uses the first online CPU in hctx->cpumask to
> select the software context for a request.
>
> Since commit a46c27026da1 ("blk-mq: don't schedule block kworker on
> isolated CPUs"), hctx->cpumask excludes isolated CPUs. If a hardware
> context is mapped only to isolated CPUs, the mask is empty and
> blk_mq_alloc_request_hctx fails with -EXDEV.
>
> The NVMe fabrics transports use blk_mq_alloc_request_hctx to allocate
> the Connect command for each I/O queue. As a result, connecting to a
> controller can fail when using isolcpus=domain or an isolated cpuset
> partition.
>
> Passthrough requests bypass the software queues and go directly to
> hctx->dispatch. Their software context is only used to select the
> completion CPU and as a hint when freeing the tag.
>
> Use the software context of an online housekeeping CPU for passthrough
> requests.
>
> Fixes: a46c27026da1 ("blk-mq: don't schedule block kworker on isolated CPUs")
> Tested-by: Maurizio Lombardi<mlombard@redhat.com>
> Signed-off-by: Daniel Wagner<dwagner@suse.de>
Looks good to me:
Reviewed-by: Nilay Shroff <nilay@linux.ibm.com>
prev parent reply other threads:[~2026-11-03 17:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 14:57 Daniel Wagner
2026-11-03 15:50 ` Aaron Tomlin
2026-11-03 16:37 ` Sebastian Andrzej Siewior
2026-11-03 17:04 ` Nilay Shroff [this message]
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=7f6e7fc6-dd40-4949-9a1b-95200c9680e6@linux.ibm.com \
--to=nilay@linux.ibm.com \
--cc=atomlin@atomlin.com \
--cc=axboe@kernel.dk \
--cc=bigeasy@linutronix.de \
--cc=dwagner@suse.de \
--cc=frederic@kernel.org \
--cc=hare@kernel.org \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=ming.lei@redhat.com \
--cc=mlombard@redhat.com \
--cc=sagi@grimberg.me \
--cc=sgogte@purestorage.com \
/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
all inboxes | Powered by JetHome®