From: Robin Murphy <robin.murphy@arm.com>
To: Ming Lei <ming.lei@redhat.com>,
linux-nvme@lists.infradead.org, Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org,
iommu@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [bug report] iommu_dma_unmap_sg() is very slow then running IO from remote numa node
Date: Fri, 9 Jul 2021 11:26:53 +0100 [thread overview]
Message-ID: <23e7956b-f3b5-b585-3c18-724165994051@arm.com> (raw)
In-Reply-To: <YOgK8fdv7dOQtkET@T590>
On 2021-07-09 09:38, Ming Lei wrote:
> Hello,
>
> I observed that NVMe performance is very bad when running fio on one
> CPU(aarch64) in remote numa node compared with the nvme pci numa node.
>
> Please see the test result[1] 327K vs. 34.9K.
>
> Latency trace shows that one big difference is in iommu_dma_unmap_sg(),
> 1111 nsecs vs 25437 nsecs.
Are you able to dig down further into that? iommu_dma_unmap_sg() itself
doesn't do anything particularly special, so whatever makes a difference
is probably happening at a lower level, and I suspect there's probably
an SMMU involved. If for instance it turns out to go all the way down to
__arm_smmu_cmdq_poll_until_consumed() because polling MMIO from the
wrong node is slow, there's unlikely to be much you can do about that
other than the global "go faster" knobs (iommu.strict and
iommu.passthrough) with their associated compromises.
Robin.
> [1] fio test & results
>
> 1) fio test result:
>
> - run fio on local CPU
> taskset -c 0 ~/git/tools/test/nvme/io_uring 10 1 /dev/nvme1n1 4k
> + fio --bs=4k --ioengine=io_uring --fixedbufs --registerfiles --hipri --iodepth=64 --iodepth_batch_submit=16 --iodepth_batch_complete_min=16 --filename=/dev/nvme1n1 --direct=1 --runtime=10 --numjobs=1 --rw=randread --name=test --group_reporting
>
> IOPS: 327K
> avg latency of iommu_dma_unmap_sg(): 1111 nsecs
>
>
> - run fio on remote CPU
> taskset -c 80 ~/git/tools/test/nvme/io_uring 10 1 /dev/nvme1n1 4k
> + fio --bs=4k --ioengine=io_uring --fixedbufs --registerfiles --hipri --iodepth=64 --iodepth_batch_submit=16 --iodepth_batch_complete_min=16 --filename=/dev/nvme1n1 --direct=1 --runtime=10 --numjobs=1 --rw=randread --name=test --group_reporting
>
> IOPS: 34.9K
> avg latency of iommu_dma_unmap_sg(): 25437 nsecs
>
> 2) system info
> [root@ampere-mtjade-04 ~]# lscpu | grep NUMA
> NUMA node(s): 2
> NUMA node0 CPU(s): 0-79
> NUMA node1 CPU(s): 80-159
>
> lspci | grep NVMe
> 0003:01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983
>
> [root@ampere-mtjade-04 ~]# cat /sys/block/nvme1n1/device/device/numa_node
> 0
>
>
>
> Thanks,
> Ming
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
next prev parent reply other threads:[~2021-07-09 10:27 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-09 8:38 [bug report] iommu_dma_unmap_sg() is very slow then running IO from remote numa node Ming Lei
2021-07-09 10:16 ` Russell King (Oracle)
2021-07-09 14:21 ` Ming Lei
2021-07-09 10:26 ` Robin Murphy [this message]
2021-07-09 11:04 ` John Garry
2021-07-09 12:34 ` Robin Murphy
2021-07-09 14:24 ` Ming Lei
2021-07-19 16:14 ` John Garry
2021-07-21 1:40 ` Ming Lei
2021-07-21 9:23 ` John Garry
2021-07-21 9:59 ` Ming Lei
2021-07-21 11:07 ` John Garry
2021-07-21 11:58 ` Ming Lei
2021-07-22 7:58 ` Ming Lei
2021-07-22 10:05 ` John Garry
2021-07-22 10:19 ` Ming Lei
2021-07-22 11:12 ` John Garry
2021-07-22 12:53 ` Marc Zyngier
2021-07-22 13:54 ` John Garry
2021-07-22 15:54 ` Ming Lei
2021-07-22 17:40 ` Robin Murphy
2021-07-23 10:21 ` Ming Lei
2021-07-26 7:51 ` John Garry
2021-07-28 1:32 ` Ming Lei
2021-07-28 10:38 ` John Garry
2021-07-28 15:17 ` Ming Lei
2021-07-28 15:39 ` Robin Murphy
2021-08-10 9:36 ` John Garry
2021-08-10 10:35 ` Ming Lei
2021-07-27 17:08 ` Robin Murphy
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=23e7956b-f3b5-b585-3c18-724165994051@arm.com \
--to=robin.murphy@arm.com \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=ming.lei@redhat.com \
--cc=will@kernel.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;
as well as URLs for NNTP newsgroup(s).