Pavel Tatashin <pasha.tatashin@xxxxxxxxxx> writes: > 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. Hi Pasha, I see, and I'm curious, do you experience this case where a user has touched the pages before doing a VFIO DMA map, and if so where? The usual situation on my side is that the pages are faulted in during pinning. Daniel
