On Fri, Dec 4, 2020 at 3:06 PM Daniel Jordan <daniel.m.jordan@xxxxxxxxxx> wrote: > > Jason Gunthorpe <jgg@xxxxxxxx> writes: > > > On Wed, Dec 02, 2020 at 08:34:32PM -0500, Pavel Tatashin wrote: > >> What I meant is the users of the interface do it incrementally not in > >> large chunks. For example: > >> > >> vfio_pin_pages_remote > >> vaddr_get_pfn > >> ret = pin_user_pages_remote(mm, vaddr, 1, flags | > >> FOLL_LONGTERM, page, NULL, NULL); > >> 1 -> pin only one pages at a time > > > > I don't know why vfio does this, it is why it so ridiculously slow at > > least. > > Well Alex can correct me, but I went digging and a comment from the > first type1 vfio commit says the iommu API didn't promise to unmap > subpages of previous mappings, so doing page at a time gave flexibility > at the cost of inefficiency. > > Then 166fd7d94afd allowed the iommu to use larger pages in vfio, but > vfio kept pinning pages at a time. I couldn't find an explanation for > why that stayed the same. > > Yesterday I tried optimizing vfio to skip gup calls for tail pages after > Matthew pointed out this same issue to me by coincidence last week. > Currently debugging, but if there's a fundamental reason this won't work > on the vfio side, it'd be nice to know. Hi Daniel, I do not think there are any fundamental reasons why it won't work. I have also thinking increasing VFIO chunking for a different reason: If a client touches pages before doing a VFIO DMA map, those pages might be huge, and pinning a small page at a time and migrating a small page at a time can break-up the huge pages. So, it is not only inefficient to pin, but it can also inadvertently slow down the runtime. Thank you, Pasha
