From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: iommu@lists.linux.dev, kvm@vger.kernel.org, patches@lists.linux.dev
Subject: Re: [PATCH] vfio/type1: Remove Fine Grained Superpages detection
Date: Wed, 9 Apr 2025 12:50:39 -0300 [thread overview]
Message-ID: <20250409155039.GL1778492@nvidia.com> (raw)
In-Reply-To: <20250408132333.382ab143.alex.williamson@redhat.com>
On Tue, Apr 08, 2025 at 01:23:33PM -0600, Alex Williamson wrote:
> > Remove vfio_test_domain_fgsp() and just rely on a direct 2*PAGE_SIZE check
> > instead so there is no behavior change.
> >
> > Maybe it should always activate the iommu_iova_to_phys(), it shouldn't
> > have a performance downside since split is gone.
>
> We were never looking for splitting here, in fact an IOMMU driver that
> supports splitting would break the fgsp test.
Yes, I thought that was the point as expensive splitting in the driver
would be the main reason not to use the unmap path.
> Nor was the intent ever to look for 2*PAGE_SIZE support.
Maybe, but that is what it ended up doing :)
> I don't recall the optimization being overwhelming in the first place,
> so if it's relegated to AMD v1 maybe we should just remove it
> altogether rather than introducing this confusing notion that
> 2*PAGE_SIZE has some particular importance.
Okay, lets do that instead. We have more and more cases where we can
get smaller orders than 2M now and the iova loop is probably going to
be faster than unmapping a small order page 4k at a time. Only AMDv1
has the ability to store the arbitary orders..
Jason
prev parent reply other threads:[~2025-04-09 15:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-08 17:39 [PATCH] vfio/type1: Remove Fine Grained Superpages detection Jason Gunthorpe
2025-04-08 19:23 ` Alex Williamson
2025-04-09 15:50 ` Jason Gunthorpe [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=20250409155039.GL1778492@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=iommu@lists.linux.dev \
--cc=kvm@vger.kernel.org \
--cc=patches@lists.linux.dev \
/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