[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20210219161305.36522-1-daniel.m.jordan@oracle.com>
Date: Fri, 19 Feb 2021 11:13:02 -0500
From: Daniel Jordan <daniel.m.jordan@...cle.com>
To: Alex Williamson <alex.williamson@...hat.com>,
Cornelia Huck <cohuck@...hat.com>
Cc: Jason Gunthorpe <jgg@...dia.com>,
Matthew Wilcox <willy@...radead.org>,
Pavel Tatashin <pasha.tatashin@...een.com>,
Steven Sistare <steven.sistare@...cle.com>,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
Daniel Jordan <daniel.m.jordan@...cle.com>
Subject: [PATCH v2 0/3] vfio/type1: Batch page pinning
v2:
- Fixed missing error unwind in patch 3 (Alex). After more thought,
the ENODEV case is fine, so it stayed the same.
- Rebased on linux-vfio.git/next (no conflicts).
---
The VFIO type1 driver is calling pin_user_pages_remote() once per 4k page, so
let's do it once per 512 4k pages to bring VFIO in line with other drivers such
as IB and vDPA.
qemu guests with at least 2G memory start about 8% faster on a Xeon server,
with more detailed results in the last changelog.
Thanks to Matthew, who first suggested the idea to me.
Daniel
Test Cases
----------
1) qemu passthrough with IOMMU-capable PCI device
2) standalone program to hit
vfio_pin_map_dma() -> vfio_pin_pages_remote()
3) standalone program to hit
vfio_iommu_replay() -> vfio_pin_pages_remote()
Each was run...
- with varying sizes
- with/without disable_hugepages=1
- with/without LOCKED_VM exceeded
I didn't test vfio_pin_page_external() because there was no readily available
hardware, but the changes there are pretty minimal.
Daniel Jordan (3):
vfio/type1: Change success value of vaddr_get_pfn()
vfio/type1: Prepare for batched pinning with struct vfio_batch
vfio/type1: Batch page pinning
drivers/vfio/vfio_iommu_type1.c | 215 +++++++++++++++++++++++---------
1 file changed, 155 insertions(+), 60 deletions(-)
base-commit: 76adb20f924f8d27ed50d02cd29cadedb59fd88f
--
2.30.1
Powered by blists - more mailing lists