From: Alexander Shumakovitch <shurik@jhu.edu>
To: "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Subject: Re: Read speed for a PCIe NVMe SSD is ridiculously slow on a multi-socket machine.
Date: Fri, 24 Mar 2023 21:38:38 +0000 [thread overview]
Message-ID: <ZB4YXKctoJ2DYfd7@hornet> (raw)
In-Reply-To: <ZB37W2dfqR4sgQWt@kbusch-mbp.dhcp.thefacebook.com>
Thank you, Keith. As I have just written to Damien, I've started testing
this hardware from a live USB stick distro, which included 'taskset', but
not 'numactl'. But given the large amount of RAM on the server in question,
the kernel should have taken care of the memory pinning anyway.
In any case, it looks like the main issue is indeed with access to the read
cache, so now I have to figure out what to do about it.
Thanks,
--- Alex.
On Fri, Mar 24, 2023 at 01:34:51PM -0600, Keith Busch wrote:
> When writing host->dev, there is no cache coherency to consider so it'll
> always be faster in NUMA situations. Reading dev->host does, and can have
> considerable overhead, though 10x seems a bit high.
>
> Retrying with Damien's O_DIRECT suggestion is a good idea.
>
> Also, 'taskset' only pins the CPUs the process schedules on, but not the
> memory node it allocates from. Try 'numactl' instead for local node
> allocations.
prev parent reply other threads:[~2023-03-24 21:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ZB1JgJ2DxyTMVUHB@hornet>
2023-03-24 8:43 ` Read speed for a PCIe NVMe SSD is ridiculously slow on a multi-socket machine Damien Le Moal
2023-03-24 21:19 ` Alexander Shumakovitch
2023-03-25 1:52 ` Damien Le Moal
2023-03-31 7:53 ` Alexander Shumakovitch
2023-03-25 0:33 ` Alexander Shumakovitch
2023-03-25 1:56 ` Damien Le Moal
2023-03-24 19:34 ` Keith Busch
2023-03-24 21:38 ` Alexander Shumakovitch [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=ZB4YXKctoJ2DYfd7@hornet \
--to=shurik@jhu.edu \
--cc=linux-nvme@lists.infradead.org \
/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