Re: [RFC PATCH 1/2] vfio: Improve DMA mapping performance for huge pages

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Dec 23, 2025 at 11:00:43PM +0000, Aaron Lewis wrote:

> More effort will be needed to see what kind of speed ups can be achieved
> by optimizing iommufd.  Sample profiler results (below) show that it
> isn't the GUP calls that are slowing it down like they were in the
> "vfio_type1_iommu" case.  The majority of the slowdown is coming from
> batch_from_pages(), and the majority of that time is being spent in
> batch_add_pfn_num().

This is probably because vfio is now using num_pages_contiguous()
which seems to be a little bit faster than batch_add_pfn()

Since that is pretty new maybe it explains the discrepancy in reports.

> @@ -598,7 +600,18 @@ static long vaddr_get_pfns(struct mm_struct *mm, unsigned long vaddr,
>  	ret = pin_user_pages_remote(mm, vaddr, pin_pages, flags | FOLL_LONGTERM,
>  				    batch->pages, NULL);
>  	if (ret > 0) {
> +		unsigned long nr_pages = compound_nr(batch->pages[0]);
> +		bool override_size = false;
> +
> +		if (PageHead(batch->pages[0]) && nr_pages > pin_pages &&
> +		    ret == pin_pages) {
> +			override_size = true;
> +			ret = nr_pages;
> +			page_ref_add(batch->pages[0], nr_pages - pin_pages);
> +		}

This isn't right, num_pages_contiguous() is the best we can do for
lists returns by pin_user_pages(). In a VMA context you cannot blindly
assume the whole folio was mapped contiguously. Indeed I seem to
recall this was already proposed and rejected and that is how we ended
up with num_pages_contiguous().

Again, use the memfd path which supports this optimization already.

Jason