From: lizhe.67@bytedance.com
To: alex.williamson@redhat.com, akpm@linux-foundation.org,
david@redhat.com, jgg@ziepe.ca, peterx@redhat.com
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, lizhe.67@bytedance.com
Subject: [PATCH v4 0/5] vfio/type1: optimize vfio_pin_pages_remote() and vfio_unpin_pages_remote()
Date: Thu, 10 Jul 2025 16:53:50 +0800 [thread overview]
Message-ID: <20250710085355.54208-1-lizhe.67@bytedance.com> (raw)
From: Li Zhe <lizhe.67@bytedance.com>
This patchset is an integration of the two previous patchsets[1][2].
When vfio_pin_pages_remote() is called with a range of addresses that
includes large folios, the function currently performs individual
statistics counting operations for each page. This can lead to significant
performance overheads, especially when dealing with large ranges of pages.
The function vfio_unpin_pages_remote() has a similar issue, where executing
put_pfn() for each pfn brings considerable consumption.
This patchset primarily optimizes the performance of the relevant functions
by batching the less efficient operations mentioned before.
The first two patch optimizes the performance of the function
vfio_pin_pages_remote(), while the remaining patches optimize the
performance of the function vfio_unpin_pages_remote().
The performance test results, based on v6.16-rc4, for completing the 16G
VFIO MAP/UNMAP DMA, obtained through unit test[3] with slight
modifications[4], are as follows.
Base(6.16-rc4):
./vfio-pci-mem-dma-map 0000:03:00.0 16
------- AVERAGE (MADV_HUGEPAGE) --------
VFIO MAP DMA in 0.047 s (340.2 GB/s)
VFIO UNMAP DMA in 0.135 s (118.6 GB/s)
------- AVERAGE (MAP_POPULATE) --------
VFIO MAP DMA in 0.280 s (57.2 GB/s)
VFIO UNMAP DMA in 0.312 s (51.3 GB/s)
------- AVERAGE (HUGETLBFS) --------
VFIO MAP DMA in 0.052 s (310.5 GB/s)
VFIO UNMAP DMA in 0.136 s (117.3 GB/s)
With this patchset:
------- AVERAGE (MADV_HUGEPAGE) --------
VFIO MAP DMA in 0.027 s (600.7 GB/s)
VFIO UNMAP DMA in 0.045 s (357.0 GB/s)
------- AVERAGE (MAP_POPULATE) --------
VFIO MAP DMA in 0.261 s (61.4 GB/s)
VFIO UNMAP DMA in 0.288 s (55.6 GB/s)
------- AVERAGE (HUGETLBFS) --------
VFIO MAP DMA in 0.031 s (516.4 GB/s)
VFIO UNMAP DMA in 0.045 s (353.9 GB/s)
For large folio, we achieve an over 40% performance improvement for VFIO
MAP DMA and an over 66% performance improvement for VFIO DMA UNMAP. For
small folios, the performance test results show a slight improvement with
the performance before optimization.
[1]: https://lore.kernel.org/all/20250529064947.38433-1-lizhe.67@bytedance.com/
[2]: https://lore.kernel.org/all/20250620032344.13382-1-lizhe.67@bytedance.com/#t
[3]: https://github.com/awilliam/tests/blob/vfio-pci-mem-dma-map/vfio-pci-mem-dma-map.c
[4]: https://lore.kernel.org/all/20250610031013.98556-1-lizhe.67@bytedance.com/
Li Zhe (5):
mm: introduce num_pages_contiguous()
vfio/type1: optimize vfio_pin_pages_remote()
vfio/type1: batch vfio_find_vpfn() in function
vfio_unpin_pages_remote()
vfio/type1: introduce a new member has_rsvd for struct vfio_dma
vfio/type1: optimize vfio_unpin_pages_remote()
drivers/vfio/vfio_iommu_type1.c | 111 ++++++++++++++++++++++++++------
include/linux/mm.h | 23 +++++++
2 files changed, 113 insertions(+), 21 deletions(-)
---
Changelogs:
v3->v4:
- Fix an indentation issue in patch #2.
v2->v3:
- Add a "Suggested-by" and a "Reviewed-by" tag.
- Address the compilation errors introduced by patch #1.
- Resolved several variable type issues.
- Add clarification for function num_pages_contiguous().
v1->v2:
- Update the performance test results.
- The function num_pages_contiguous() is extracted and placed in a
separate commit.
- The phrase 'for large folio' has been removed from the patchset title.
v3: https://lore.kernel.org/all/20250707064950.72048-1-lizhe.67@bytedance.com/
v2: https://lore.kernel.org/all/20250704062602.33500-1-lizhe.67@bytedance.com/
v1: https://lore.kernel.org/all/20250630072518.31846-1-lizhe.67@bytedance.com/
--
2.20.1
next reply other threads:[~2025-07-10 8:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-10 8:53 lizhe.67 [this message]
2025-07-10 8:53 ` [PATCH v4 1/5] mm: introduce num_pages_contiguous() lizhe.67
2025-07-10 8:53 ` [PATCH v4 2/5] vfio/type1: optimize vfio_pin_pages_remote() lizhe.67
2025-07-11 21:35 ` Alex Williamson
2025-07-11 22:36 ` Jason Gunthorpe
2025-07-14 2:44 ` lizhe.67
2025-07-22 16:32 ` Eric Farman
2025-07-22 19:23 ` Alex Williamson
2025-07-23 7:09 ` lizhe.67
2025-07-23 14:41 ` Eric Farman
2025-07-24 2:40 ` lizhe.67
2025-07-24 16:56 ` Alex Williamson
2025-07-25 6:59 ` lizhe.67
2025-07-25 15:58 ` Eric Farman
2025-07-25 7:00 ` [FIXUP] vfio/type1: correct logic of vfio_find_vpfn() lizhe.67
2025-07-28 21:37 ` Alex Williamson
2025-07-10 8:53 ` [PATCH v4 3/5] vfio/type1: batch vfio_find_vpfn() in function vfio_unpin_pages_remote() lizhe.67
2025-07-10 8:53 ` [PATCH v4 4/5] vfio/type1: introduce a new member has_rsvd for struct vfio_dma lizhe.67
2025-07-10 8:53 ` [PATCH v4 5/5] vfio/type1: optimize vfio_unpin_pages_remote() lizhe.67
2025-07-16 20:21 ` [PATCH v4 0/5] vfio/type1: optimize vfio_pin_pages_remote() and vfio_unpin_pages_remote() Alex Williamson
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=20250710085355.54208-1-lizhe.67@bytedance.com \
--to=lizhe.67@bytedance.com \
--cc=akpm@linux-foundation.org \
--cc=alex.williamson@redhat.com \
--cc=david@redhat.com \
--cc=jgg@ziepe.ca \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterx@redhat.com \
/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).