From: Christoph Hellwig <hch@lst.de>
To: Sagi Grimberg <sagi@grimberg.me>
Cc: Keith Busch <kbusch@kernel.org>,
Pratyush Yadav <ptyadav@amazon.de>, Jens Axboe <axboe@kernel.dk>,
Christoph Hellwig <hch@lst.de>,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] nvme-pci: do not set the NUMA node of device if it has none
Date: Wed, 26 Jul 2023 15:14:08 +0200 [thread overview]
Message-ID: <20230726131408.GA15909@lst.de> (raw)
In-Reply-To: <50a125da-95c8-3b9b-543a-016c165c745d@grimberg.me>
On Wed, Jul 26, 2023 at 10:58:36AM +0300, Sagi Grimberg wrote:
>>> For example, AWS EC2's i3.16xlarge instance does not expose NUMA
>>> information for the NVMe devices. This means all NVMe devices have
>>> NUMA_NO_NODE by default. Without this patch, random 4k read performance
>>> measured via fio on CPUs from node 1 (around 165k IOPS) is almost 50%
>>> less than CPUs from node 0 (around 315k IOPS). With this patch, CPUs on
>>> both nodes get similar performance (around 315k IOPS).
>>
>> irqbalance doesn't work with this driver though: the interrupts are
>> managed by the kernel. Is there some other reason to explain the perf
>> difference?
>
> Maybe its because the numa_node goes to the tagset which allocates
> stuff based on that numa-node ?
Yeah, the only explanation I could come up with is that without this
the allocations gets spread, and that somehow helps. All of this
is a little obscure, but so is the NVMe practice of setting the node id
to first_memory_node, which no other driver does. I'd really like to
understand what's going on here first. After that this patch probably
is the right thing, I'd just like to understand why.
next prev parent reply other threads:[~2023-07-26 13:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-25 11:06 [PATCH] nvme-pci: do not set the NUMA node of device if it has none Pratyush Yadav
2023-07-25 14:35 ` Keith Busch
2023-07-26 7:58 ` Sagi Grimberg
2023-07-26 13:14 ` Christoph Hellwig [this message]
2023-07-26 15:30 ` Pratyush Yadav
2023-07-26 16:17 ` Keith Busch
2023-07-26 19:32 ` Pratyush Yadav
2023-07-26 22:25 ` Keith Busch
2023-07-28 18:09 ` Pratyush Yadav
2023-07-28 19:34 ` Keith Busch
2023-08-04 14:50 ` Pratyush Yadav
2023-08-04 15:19 ` Keith Busch
2023-08-08 15:51 ` Pratyush Yadav
2023-08-08 16:35 ` Keith Busch
2024-07-23 9:49 ` Maurizio Lombardi
2024-07-23 14:39 ` Christoph Hellwig
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=20230726131408.GA15909@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=ptyadav@amazon.de \
--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