From: Baolu Lu <baolu.lu@linux.intel.com>
To: Ioanna Alifieraki <ioanna-maria.alifieraki@canonical.com>,
kevin.tian@intel.com, jroedel@suse.de, robin.murphy@arm.com,
will@kernel.org, joro@8bytes.org, dwmw2@infradead.org,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
regressions@lists.linux.dev, stable@vger.kernel.org
Subject: Re: [REGRESSION][BISECTED] Performance Regression in IOMMU/VT-d Since Kernel 6.10
Date: Wed, 2 Jul 2025 13:14:12 +0800 [thread overview]
Message-ID: <7d2214f3-3b54-4b74-a18b-aca1fdf4fdb4@linux.intel.com> (raw)
In-Reply-To: <20250701171154.52435-1-ioanna-maria.alifieraki@canonical.com>
On 7/2/25 01:11, Ioanna Alifieraki wrote:
> #regzbot introduced: 129dab6e1286
>
> Hello everyone,
>
> We've identified a performance regression that starts with linux
> kernel 6.10 and persists through 6.16(tested at commit e540341508ce).
> Bisection pointed to commit:
> 129dab6e1286 ("iommu/vt-d: Use cache_tag_flush_range_np() in iotlb_sync_map").
>
> The issue occurs when running fio against two NVMe devices located
> under the same PCIe bridge (dual-port NVMe configuration). Performance
> drops compared to configurations where the devices are on different
> bridges.
>
> Observed Performance:
> - Before the commit: ~6150 MiB/s, regardless of NVMe device placement.
> - After the commit:
> -- Same PCIe bridge: ~4985 MiB/s
> -- Different PCIe bridges: ~6150 MiB/s
>
>
> Currently we can only reproduce the issue on a Z3 metal instance on
> gcp. I suspect the issue can be reproducible if you have a dual port
> nvme on any machine.
> At [1] there's a more detailed description of the issue and details
> on the reproducer.
This test was running on bare metal hardware instead of any
virtualization guest, right? If that's the case,
cache_tag_flush_range_np() is almost a no-op.
Can you please show me the capability register of the IOMMU by:
#cat /sys/bus/pci/devices/[pci_dev_name]/iommu/intel-iommu/cap
>
> Could you please advise on the appropriate path forward to mitigate or
> address this regression?
>
> Thanks,
> Jo
>
> [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2115738
Thanks,
baolu
next prev parent reply other threads:[~2025-07-02 5:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-01 17:11 [REGRESSION][BISECTED] Performance Regression in IOMMU/VT-d Since Kernel 6.10 Ioanna Alifieraki
2025-07-02 5:14 ` Baolu Lu [this message]
2025-07-02 9:00 ` Baolu Lu
2025-07-02 16:45 ` Ioanna Alifieraki
2025-07-03 2:03 ` Baolu Lu
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=7d2214f3-3b54-4b74-a18b-aca1fdf4fdb4@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=ioanna-maria.alifieraki@canonical.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=jroedel@suse.de \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=regressions@lists.linux.dev \
--cc=robin.murphy@arm.com \
--cc=stable@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.