From: Christoph Hellwig <hch@lst.de>
To: Jens Axboe <axboe@kernel.dk>
Cc: Liu Song <liusong@linux.alibaba.com>,
kbusch@kernel.org, hch@lst.de, sagi@grimberg.me,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] nvme: request remote is usually not involved for nvme devices
Date: Mon, 19 Sep 2022 16:35:56 +0200 [thread overview]
Message-ID: <20220919143556.GA28122@lst.de> (raw)
In-Reply-To: <894e18a4-4504-df48-6429-a04c222ca064@kernel.dk>
On Mon, Sep 19, 2022 at 08:10:31AM -0600, Jens Axboe wrote:
> I'm not disagreeing with any of that, my point is just that you're
> hacking around this in the nvme driver. This is problematic whenever
> core changes happen, because now we have to touch individual drivers.
> While the expectation is that there are no remote IPI completions for
> NVMe, queue starved devices do exist and those do see remote
> completions.
>
> This optimization belongs in the blk-mq core, not in nvme. I do think it
> makes sense, you just need to solve it in blk-mq rather than in the nvme
> driver.
I'd also really see solid numbers to justify it.
And btw, having more than one core per queue is quite common in
nvme. Even many enterprise SSDs only have 64 queues, and some of
the low-end consumers ones have very low number of queues that are
not enough for the number of cores in even mid-end desktop CPUs.
next prev parent reply other threads:[~2022-09-19 14:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-17 16:40 [RFC PATCH] nvme: request remote is usually not involved for nvme devices Liu Song
2022-09-17 16:50 ` Jens Axboe
2022-09-18 16:10 ` Liu Song
2022-09-19 14:10 ` Jens Axboe
2022-09-19 14:35 ` Christoph Hellwig [this message]
2022-09-21 3:40 ` Liu Song
2022-09-21 3:32 ` [RFC PATCH] blk-mq: hctx has only one ctx mapping is no need to redirect the completion Liu Song
2022-09-22 6:20 ` Christoph Hellwig
2022-09-22 7:17 ` Liu Song
2022-09-22 8:27 ` [RFC PATCH v2] " Liu Song
2022-09-24 15:03 ` [RFC PATCH] " 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=20220919143556.GA28122@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=liusong@linux.alibaba.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: 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